[FFe] New upstream version: 0.3.0.1

the exaile developers have setup a ppa at https://launchpad.net/~exaile-devel/+archive/ppa, which also contains karmic packages.

As this is a complete rewrite and we are past Feature Freeze, this would need a exception for Karmic. See:

https://wiki.ubuntu.com/FreezeExceptionProcess#Exceptions%20for%20Universe/Multiverse

We already packaged it before FF but there were too many packages, according to the MOTU I talked to. I would just like to say that apparently, the two debian maintainers of exaile (who I never saw in #exaile) considered it a good idea for 0.2.x to put all the plugins into the core package and to forget half of the dependencies, so that users would have to manually find the deps when they wanted to enable a plugin.

For the FFE, Exaile's inclusion is a Xubuntu Karmic spec goal, so that should be dealable in due time. The next release of Exaile is planned around 20th of September, and will be a bugfix release.

On Mon, Aug 31, 2009 at 4:28 PM, Steve Dodier<email address hidden> wrote:
> We already packaged it before FF but there were too many packages,
> according to the MOTU I talked to. I would just like to say that

I just took a quick look at the package in the PPA, and I see what
s/he meant. I certainly don't think it is a blocker, but you might
want to consider simply having an exaile-plugins package for the
Recommended plugins. We install them all by default as it is anyways.
Perhaps even putting all the Suggested plugins in an
exaile-plugins-extras package as well.

> apparently, the two debian maintainers of exaile (who I never saw in
> #exaile) considered it a good idea for 0.2.x to put all the plugins into
> the core package and to forget half of the dependencies, so that users
> would have to manually find the deps when they wanted to enable a
> plugin.

There were certainly some issues with the plugins in 0.2.x....

> For the FFE, Exaile's inclusion is a Xubuntu Karmic spec goal, so that
> should be dealable in due time. The next release of Exaile is planned
> around 20th of September, and will be a bugfix release.

I'd heard that rumor going around. I'm not involved with the Xubuntu
team, but if you need any help with filing an exception and/or a
sponsor for the upload let me know if I can be of assistance.

Hey Andrew,

Do you think that this would be acceptable as a package list ?

 * exaile
CORE + alarmclock amazoncovers audioscrobbler bookmarks desktopcover lastfmcovers lastfmdynamic librivox
massstorage minimode mpris multialarmclock podcasts replaygain shoutcast tagcovers notify notifyosd xkeys cd
Depends:
python (>= 2.5),
    python-gst0.10,
    gstreamer0.10-plugins-base,
    gstreamer0.10-plugins-good,
    python-mutagen,
    python-dbus,
    python-gtk2,
    python-glade2
Recommends: hal,
    python-sexy,
    python-notify,
    python-mmkeys,
    python-cddb
Suggests: gstreamer0.10-plugins-bad,
    gstreamer0.10-plugins-ugly,
    gstreamer0.10-ffmpeg,
    python-pyinotify

 * exaile-plugin-streamripper
Depends:
    exaile
    streamripper

 * exaile-plugin-contextinfo
contextinfo lyricsfly lyricswiki
Depends:
    exaile
    libwebkit-1.0-1 (>= 1.0.1)
    python-webkit (>= 1.1.2)

 * exaile-plugin-ipod
ipod
Depends:
    exaile
    python-gpod

 * exaile-plugin-ipconsole
ipconsole
Depends:
    exaile
    inotify

 * exaile-plugin-moodbar (Requires repackaging moodbar, not relevant otherwise)
moodbar
Depends:
    exaile
    moodbar

 * exaile-plugins-gnome (only relevant to gnome users)
gnomemmkeys screensaverpause
Recommands:
    gnome-settings-daemon
    gnome-screensaver | kscreensaver

If so then I can bring the necessary fixes to the debian files and setup a branch. I don't know anything about packaging, so there may be errors here & there. :) Also, what should be done with the maintainer field of the debian/copyright file (esp. maintainer field) ?

Sidenote : the description of the package also needs to be rewritten.

ipconsole depends ipython and not inotify, and contextinfo also depends python-imaging (thanks Johannes).

On Mon, Aug 31, 2009 at 6:29 PM, Steve Dodier<email address hidden> wrote:
> Hey Andrew,
>
> Do you think that this would be acceptable as a package list ?
>

I think that looks quite a bit cleaner. It allows for users to not
have to install dependencies for things they would never use.
Certainly better than the plugin situation currently in Debian/Ubuntu.

The key is to hopefully getting this right the first time. It begins
to get messy if plugins get moved around and Conflicts need to be
used....

>
> If so then I can bring the necessary fixes to the debian files and setup
> a branch. I don't know anything about packaging, so there may be errors
> here & there. :) Also, what should be done with the maintainer field of
> the debian/copyright file (esp. maintainer field) ?

 The maintainer field in debian/copyright refers to the upstream
maintainer(s). The maintainer field in debian/control would be set to
Ubuntu Developers.

I'll try to give the current package a full, proper review this week
end. I'm a bit short on time.

Who have you been working with on the Xubuntu side? Do they have their
own packaging work or are they planning on using the upstream
packaging in the PPA? Just want to make sure we're not duplicating
work...

Also, I'm subscribing Cody Somerville, the Xubuntu motu-release
delegate to weigh in on the feasibility of getting the exception.

Forwarding my message to xubuntu-devel as it's still waiting for
moderation there, and it is relevant to this report.

---------- Forwarded message ----------
From: Andrew SB <email address hidden>
Date: Fri, Sep 11, 2009 at 12:18 AM
Subject: Plans for Exaile 0.3.x in Karmic?
To: <email address hidden>

Hi all,

I'm looking for some clarification on Exaile's status for Karmic.
(see: https://bugs.edge.launchpad.net/ubuntu/+source/exaile/+bug/420019)
Does the Xubuntu team still plan on getting the 0.3.x series into
Karmic? As a sometimes Exaile user and uploader to Ubuntu, I'm willing
to help. I just want to make sure that I'm not duplicating efforts and
that it just isn't simply too late as we have past Feature Freeze and
UI Freeze.

Are you on track for this goal? Has it been defered? Are you confident
that a freeze exception will be granted (any comment Cory as the
Xubuntu motu-release delegate)?

Has there been any contact with the Debian Maintainers about this? I
know upstream has had issues with them in the past, but if our
packaging diverges too much we'll likely run into issues in the
future.

Here's a quick review of the packaging found at
lp:~exaile-packagers/exaile/ubuntu. It's mostly trivial issues.

1) debian/changelog has diverged from the package in Ubuntu.

2) Lintian tells us:
  W: exaile source: debhelper-but-no-misc-depends exaile
  W: exaile source: debhelper-but-no-misc-depends exaile-plugin-moodbar
  W: exaile source: debhelper-but-no-misc-depends exaile-plugin-ipod
  W: exaile source: debhelper-but-no-misc-depends exaile-plugin-contextinfo
  N:
  N:    The source package uses debhelper but it does not use
${misc:Depends} in
  N:    the given binary package's debian/control entry. This is
required so the
  N:    dependencies are set correctly in case the result of a call to any of
  N:    the dh_ commands cause the package to depend on another package.
  N:
  N:    Refer to the debhelper(7) manual page for details.
  N:
  N:    Severity: normal, Certainty: certain

3) Vcs-Bzr field has an improper format.

  It currently is: Vcs-Bzr:
bzr+ssh://bazaar.launchpad.net/~exaile-devel/exaile/0.3.0.x

  It should be: Vcs-Bzr:
https://code.launchpad.net/~exaile-devel/exaile/0.3.0.x

  Although, both the Vcs-Bzr and Vcs-Browser currently point to the
upstream bzr branch.  lp:~exaile-packagers/exaile/ubuntu might be more
appropriate? What is the location of the packaging branch that will be
uploaded to Ubuntu?

4) There is no debian/watch file.

5) debian/control: Standards-Version should be 3.8.3

6) There is a patch using quilt, but there is no build-depends on
quilt. Quilt also isn't included in debian/rules. Is this patch even
needed/used?

7) debian/control: Unnessesary Uploaders field with "Uploaders: NAME <EMAIL>"

8) debian/copyright points to the versionless symlink at
usr/share/common-licenses/GPL when it should use the exact version.

9) debian/menu uses /usr/share/pixmaps/exaile.png This doesn't effect
Ubuntu, but icons in the Debian menu system should be in XPM format.

As this is essentially a complete repackaging, has there been any
testing of the dist-upgrade from the Jaunty version?

I'd be happy to work on ...

Hey Andrew,
Thanks for your effort to review our wonderful package. As you could see we
really aren't experts on Debian packaging (but the debian/rules do work
since the packages build ^_^). Just before I get into the details, feel free
to join #exaile or #xubuntu-devel anytime to discuss this with us (i'm SiDi
on freenode).

2009/9/12 Andrew Starr-Bochicchio <email address hidden>

> Forwarding my message to xubuntu-devel as it's still waiting for
> moderation there, and it is relevant to this report.
>
>
> Hi all,
>
> I'm looking for some clarification on Exaile's status for Karmic.
> (see: https://bugs.edge.launchpad.net/ubuntu/+source/exaile/+bug/420019)
> Does the Xubuntu team still plan on getting the 0.3.x series into
> Karmic? As a sometimes Exaile user and uploader to Ubuntu, I'm willing
> to help. I just want to make sure that I'm not duplicating efforts and
> that it just isn't simply too late as we have past Feature Freeze and
> UI Freeze.
>

It of course would have been much easier to justify the upcoming 0.3.0.2
release if I had managed to properly package 0.3.0 and 0.3.0.1 before the
Feature and UI Freezes :] There is no duplicate effort as the official
maintainer have vanished and noone is working on Exaile in debian / ubuntu.

>
> Are you on track for this goal? Has it been defered? Are you confident
> that a freeze exception will be granted (any comment Cory as the
> Xubuntu motu-release delegate)?
>

I think Cory told me he would allow the FF exception for Exaile. Given the
shape of the Exaile 0.2 package and the longstanding bugs in it, I think it
is more than welcome.

>
> Has there been any contact with the Debian Maintainers about this? I
> know upstream has had issues with them in the past, but if our
> packaging diverges too much we'll likely run into issues in the
> future.
>

I have directly pinged him on Freenode and had no answer. Exaile 0.3.0 was
released a few weeks ago, and has been immediately packaged by our gentoo /
arch packagers who keep in touch with us on #exaile and who are subscribed
to our RSS release feed. We also advertised the release on Identi.ca and
mentioned a coming release in the Ubuntu planet.

>
> Here's a quick review of the packaging found at
> lp:~exaile-packagers/exaile/ubuntu. It's mostly trivial issues.
>
> 1) debian/changelog has diverged from the package in Ubuntu.

I indeed removed some names in the Maintainer line, since there is no
maintainer anymore. This may have been an error from me.

>

> 2) Lintian tells us:
> W: exaile source: debhelper-but-no-misc-depends exaile
> W: exaile source: debhelper-but-no-misc-depends exaile-plugin-moodbar
> W: exaile source: debhelper-but-no-misc-depends exaile-plugin-ipod
> W: exaile source: debhelper-but-no-misc-depends exaile-plugin-contextinfo
> N:
> N: The source package uses debhelper but it does not use
> ${misc:Depends} in
> N: the given binary package's debian/control entry. This is
> required so the
> N: dependencies are set correctly in case the result of a call to any
> of
> N: the dh_ commands cause the package to depend on another package.
> N:
> N: Refer to the debhelper(7) manual page for det...

Hi Andrew,

As Steve noted, we are very much non-experts when it comes to debian packaging. The current packaging in the bzr branch is a combination of my half-remembered packaging skills from back when I used to use Ubuntu, and Steve's own inexperienced efforts. Any tips/patches/etc. you can give to help us get it into shape for karmic would be great. (If you want commit access to the packaging branch that can be arranged) Additionally, if you know of any package maintainers who would be interested in maintaining exaile in ubuntu and/or debian we would love to have someone who can handle this long-term for us.

I've set up a branch where I fixed all of the above as well as set the package up to use python-support so that it properly follows Debian Python Policy (http://wiki.debian.org/DebianPython/NewPolicy).

Attached are a successful build log and a diff.gz for the proposed package. I have successfully upgraded from the current Ubuntu version with this package. The upstream migration code works as expected, all my library information was intact.

Here is the merge proposal for merging my branch into lp:~exaile-packagers/exaile/ubuntu:

https://code.launchpad.net/~andrewsomething/exaile/karmic/+merge/11653

The one real issue left is with the exaile-plugin-moodbar package. It Depends on moodbar, which while still in Debian was removed (incorrectly perhaps?) from Ubuntu. See Bug #316262 and Bug #388915. It might be too late for this in Karmic, though I'll try to get it readded if we get this uploaded.

I'd certainly be willing to take over "maintainership" of Exaile in Ubuntu. I'll attempt to contact the Debian Maintainer about his intentions. If he's no longer interested (as it seems might be the case), I'd also be interested in adopting the package there as well.

(PS: My message to xubuntu-devel still seems to be awaiting moderation. Steve, you might want to poke Cody to give a ruling on the Freeze Exception with his Xubuntu MOTU-Release delegate hat on.)

I merged your branch, but i put streamripper into suggests instead of recommends since we don't enable it by default. I've also added you to the exaile-packaging team, so you can commit directly to the packaging branch now.

Thanks Aren.

Attached is a new diff.gz reflecting the streamripper move.

Since exaile is the default media player provided with Xubuntu, we want this new version, so that's ok for me. I don't remember exactly whether two +1 are needed or not. If that's the case, please poke Cody.

Though, it seems that moodbar won't be readded to karmic, so I guess you should drop exaile-plugin-moodbar prior to uploading.

On Sat, Sep 19, 2009 at 6:30 PM, Lionel Le Folgoc <email address hidden> wrote:
> Since exaile is the default media player provided with Xubuntu, we want
> this new version, so that's ok for me. I don't remember exactly whether
> two +1 are needed or not. If that's the case, please poke Cody.

I'll double check before uploading, but I think for derivative
specific packages only one ACK from a release delegate is enough.

> Though, it seems that moodbar won't be readded to karmic, so I guess you
> should drop exaile-plugin-moodbar prior to uploading.

I have a package ready for upload. moodbar is still present in Debian
and if you ready the removal report linked above you'll see that it
wasn't removed due to any technical reason. It was removed due to the
fact that at the time it was only useful for Amarok 1.4's moodbar
plugin and we moved to Amarok 2.0 which didn't port the plugin.

 moodbar (0.1.2-2ubuntu2) karmic; urgency=low

  * Re-add to Ubuntu as it is a dependency of exaile-plugins-moodbar.
  * debian/control:
   - Drop Recommends/Enchances on Amarok as it doesn't have
     a moodbar plugin anymore.
   - Drop Recommends on gstreamer0.10-plugins-really-bad
     as it no longer exists.

I have built the package and can confirm that it works for the exaile
moodbar plugin. Would you be willing to ACK this as well? Should I
open a separate bug?

Thanks!

- Andrew Starr-Bochicchio

moobar will need its own FFe.

Moodbar FFe request located in Bug #433567

Thanks!

This bug was fixed in the package exaile - 0.3.0.1-0ubuntu1

---------------
exaile (0.3.0.1-0ubuntu1) karmic; urgency=low

  * New upstream release, complete rewrite. (LP: #420019)
  * debian/*: Packaging rewrite based on upstream packaging.

 -- Andrew Starr-Bochicchio <email address hidden> Sat, 12 Sep 2009 17:02:32 -0400

Arrg... It's FTBFS on the buildd as pkgstriptranslations chokes on the empty PO files. I wish pbuilder and the buildds always behaved the same. New uploaded removing the empty files shortly.

pkgstriptranslations: processing control file: ./debian/exaile/DEBIAN/control, package exaile, directory ./debian/exaile
./debian/exaile/usr/share/applications/exaile.desktop: does not have gettext domain, not stripping
pkgstriptranslations: The following PO/POT files are empty. This is known to
cause trouble in the translation importer and generally indicates a package
bug:

./po/mr.po
./po/ps.po
./po/br.po
./po/an.po
dh_builddeb: dpkg-deb returned exit code 1
make: *** [binary-makedeb-IMPL/exaile] Error 1
dpkg-buildpackage: error: /usr/bin/fakeroot debian/rules binary gave error exit status 2
******************************************************************************
Build finished at 20090922-1707
FAILED [dpkg-buildpackage died]

This bug was fixed in the package exaile - 0.3.0.1-0ubuntu2

---------------
exaile (0.3.0.1-0ubuntu2) karmic; urgency=low

  * debian/rules: Remove empty PO files to resolve FTBFS. (LP: #420019)

 -- Andrew Starr-Bochicchio <email address hidden> Tue, 22 Sep 2009 12:40:59 -0400

Hi there,

It looks like the recommends on python-mmkeys is missing (for the xkeys plugin). I very likely forgot it in my list :)

Also, if you want to disable the default OSD, you should add

[osd]
enabled = B: False
hover_tray = B: False

and not only enabled = B: False to the settings.ini file. I also recommend you add

[covers]
preferred_order = L: ['local', 'lastfm']

[cd_import]
format = S: FLAC

to the settings.ini file. The first part will avoid users' local covers to be erased by the lastfm plugin until they visit the preferences. The second one is because currently a bug in the CD plugin's preferences make it have no default import format.

On Sat, Oct 3, 2009 at 7:20 PM, Steve Dodier <email address hidden> wrote:
> Hi there,
>
> It looks like the recommends on python-mmkeys is missing (for the xkeys
> plugin). I very likely forgot it in my list :)
>
> Also, if you want to disable the default OSD, you should add
>
> [osd]
> enabled = B: False
> hover_tray = B: False
>
> and not only enabled = B: False to the settings.ini file. I also
> recommend you add
>
> [covers]
> preferred_order = L: ['local', 'lastfm']
>
> [cd_import]
> format = S: FLAC
>
> to the settings.ini file. The first part will avoid users' local covers
> to be erased by the lastfm plugin until they visit the preferences. The
> second one is because currently a bug in the CD plugin's preferences
> make it have no default import format.
>

Thanks Steve. I'll get all that in the next upload. I opened Bug
#441845 to keep it on my TODO.