[MIR] banshee

[Didier Roche-Tolomelli]

Binary package hint: banshee

Followed the https://wiki.ubuntu.com/MainInclusionProcess and all requirements are complete for Main Inclusion of banshee.

Availability: in universe
Rationale: Banshee will be the default media in UNE in maverick.
Security: 2 candidates CVE opened (one in 2005, another one in 2009): http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=banshee
Quality assurance: the package was mostly tracked before by debian. There are quite some bug reports, but a hug day will be setup first week of August by pedro.
UI standards: Fits better than rhythmbox on small screen, GNOME standard.
Dependencies: some bindings needs to be promoted. All are added there as bug tasks (libboo-cil-dev, libgdata-cil-dev, libmono-zeroconf-cil-dev, libnotify-cil-dev, libtaglib-cil-dev, gtk-sharp-beans, gio-sharp, gudev-sharp-1.0)
There is a recommends on podsleuth, but as the hal-free (udev backend branch) will be there before mid-august.
Standards compliance: follow FHS guidelines
Maintenance: ubuntu-desktop team will maintain it as soon as it's the UNE default
Description of the package:
Media Management and Playback application
 Banshee is a media management and playback application for the GNOME
 desktop, allowing users to import audio from CDs, search their library,
 create playlists of selections of their library, sync music to/from iPods
 and other media devices, play and manage video files and burn selections
 to a CD.

[Alexander Sack (asac)]

I have to get some data from arm team about the status of mono on arm in maverick. Not saying i would deny MIR because of that ... just that I need RC bugs for arm before pushing this in, so we can have proper selected bugs assigned to our toolchain group for fixing.

[Alexander Sack (asac)]

subscribed ubuntu-armel folks to get input on the current status of mono on armel. I won't hold the MIR back because of this, but I want proper RC bugs to be filed if there are problem and the bug ids dropped here ;). Thanks!

[Tobin Davis (gruemaster)]

Sorry so late. Platform issues on arm.

Unfortunately, banshee crashed in it's current state. Bug 619981 has been filed accordingly.

[Alexander Sack (asac)]

taglib-sharp is ok.

[Alexander Sack (asac)]

notify-sharp MIR is OK too.

[Alexander Sack (asac)]

do we really need/want zeroconf support in banshee? does that support mainstream use cases enough to justify putting it in main/image?

[Alexander Sack (asac)]

boo: i would prefer not to get another language into main. If technically this can be split up, lets do that (together with zeroconf). Thanks!

[Alexander Sack (asac)]

setting banshee to incomplete until boo and zeroconf are split out.

[Alexander Sack (asac)]

question came up why banshee moved to mono-zeroconf. we already have libavahi1.0-cil in main.

[Alexander Sack (asac)]

ok after discussing in #ubuntu-desktop we said that we will rip out boo and the rest is fine.

[Alexander Sack (asac)]

any progress on the things i asked above?

[Iain Lane (laney)]

Packaging work (disabling boo) done. Inclusion by default for UNE is deferred to Natty. There are however new dependencies that will need to be promoted: gio-sharp gudev-sharp-1.0 gtk-sharp-beans.

[Iain Lane (laney)]

gkeyfile-sharp too

[Didier Roche-Tolomelli (didrocks)]

@asac: do you prefer we add the tasks there and wait for natty or closing this one and opening a new one?

For reference:
https://lists.ubuntu.com/archives/ubuntu-desktop/2010-September/002644.html

[Didier Roche-Tolomelli (didrocks)]

boo is not needed anymore

[Iain Lane (laney)]

I invalidated all of the tasks that were build-depends of banshee-community-extensions. These will be tracked in bug #607291.

MIR information for libkarma as this is not just a binding.

Rationale: Enables support for rio karma devices in Banshee
Security: No vulnerabilities reported
QA: Maintained in Debian, in sync. New upstream release available.
Deps: All in main
Standards compliance: Follows FHS guidelines
Description: libkarma is a C language library that provides (read/write) access to the Rio Karma music player using either the usb (with OMFS) or network (PEARL) interface.

[Iain Lane (laney)]

I mean bug #607304 obviously.

[Michael Terry (mterry)]

libkarma is kind of a mess.

 * lintian messages:

E: libkarma source: patch-modifying-debian-files 20_install_playlist_show_as_example.dpatch debian/libkarma-dev.examples
W: libkarma source: patch-system-but-no-source-readme
W: libkarma source: patch-system-but-direct-changes-in-diff tools/karma_helper.c
W: libkarma source: debhelper-but-no-misc-depends libkarma-dev
W: libkarma source: out-of-date-standards-version 3.8.0 (current is 3.9.1)
W: libkarma-cil: wrong-section-according-to-package-name libkarma-cil => cli-mono
W: libkarma-cil-dev: wrong-section-according-to-package-name libkarma-cil-dev => libdevel

 * A watch file (and homepage setting) that 404s

 * No symbols file or -V arg to dh_makeshlibs

 * Bug 296737 seems bad

 * New upstream version available but unpackaged for 3 and a half years

 * A bad memcpy and strncat for amd64:

In file included from /usr/include/string.h:642:0,
                 from karmaLan.c:18:
In function ‘memcpy’,
    inlined from ‘lk_karmaLan_get_protocol_version’ at karmaLan.c:198:11:
/usr/include/bits/string3.h:52:3: warning: call to __builtin___memcpy_chk will always overflow destination buffer

 * Lots of errors like the following representative sample:

properties.c:350:18: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result
properties.c:296:9: warning: ignoring return value of ‘read’, declared with attribute warn_unused_result
mp3.c:206:18: warning: ignoring return value of ‘fread’, declared with attribute warn_unused_result
riocp.c:652:22: warning: ignoring return value of ‘scanf’, declared with attribute warn_unused_result
karma.c:49:5: warning: ISO C90 forbids specifying subobject to initialize

 * And to top it off, upstream no longer has a working Karma and is looking for a new maintainer, so no new fixes from that direction.

Since neither upstream nor Debian are very active in this package, it looks like we'd be on our own. And there is definitely work to be done for this one. Is it necessary for banshee?

[Chow Loong Jin (hyperair)]

On Friday 10,December,2010 02:08 AM, Michael Terry wrote:
> libkarma is kind of a mess.
>
> * lintian messages:
>
> E: libkarma source: patch-modifying-debian-files 20_install_playlist_show_as_example.dpatch debian/libkarma-dev.examples
> W: libkarma source: patch-system-but-no-source-readme
> W: libkarma source: patch-system-but-direct-changes-in-diff tools/karma_helper.c
> W: libkarma source: debhelper-but-no-misc-depends libkarma-dev
> W: libkarma source: out-of-date-standards-version 3.8.0 (current is 3.9.1)
> W: libkarma-cil: wrong-section-according-to-package-name libkarma-cil => cli-mono
> W: libkarma-cil-dev: wrong-section-according-to-package-name libkarma-cil-dev => libdevel
>
> * A watch file (and homepage setting) that 404s
>
> * No symbols file or -V arg to dh_makeshlibs
>
> * Bug 296737 seems bad
>
> * New upstream version available but unpackaged for 3 and a half years
>
> * A bad memcpy and strncat for amd64:
>
> In file included from /usr/include/string.h:642:0,
> from karmaLan.c:18:
> In function ‘memcpy’,
> inlined from ‘lk_karmaLan_get_protocol_version’ at karmaLan.c:198:11:
> /usr/include/bits/string3.h:52:3: warning: call to __builtin___memcpy_chk will always overflow destination buffer
>
> * Lots of errors like the following representative sample:
>
> properties.c:350:18: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result
> properties.c:296:9: warning: ignoring return value of ‘read’, declared with attribute warn_unused_result
> mp3.c:206:18: warning: ignoring return value of ‘fread’, declared with attribute warn_unused_result
> riocp.c:652:22: warning: ignoring return value of ‘scanf’, declared with attribute warn_unused_result
> karma.c:49:5: warning: ISO C90 forbids specifying subobject to initialize
>
> * And to top it off, upstream no longer has a working Karma and is
> looking for a new maintainer, so no new fixes from that direction.
>
> Since neither upstream nor Debian are very active in this package, it
> looks like we'd be on our own. And there is definitely work to be done
> for this one. Is it necessary for banshee?

I could probably take care of bringing the package up to date, at least to the
latest upstream version (though after the 16th, when my exams end).

As for whether it's necessary, I doubt anyone would notice if we dropped support
for Rio Karma players, considering that it was left broken for a number of
months (or even years, who knows) due to a missing .pc file and Banshee's build
system silently disabling Karma support when it didn't detect the .pc file.

It would be a nice touch to have though, for anyone who happens to discover an
old Rio Karma lying around and wanting to sync music to it. I don't have one,
but I hear it was pretty awesome during its time.

--
Kind regards,
Loong Jin

[Michael Terry (mterry)]

gudev-sharp-1.0 is approved. Good maintainership and simple. Some nits:
 * debian/copyright has a bad Source field, should be https://www.launchpad.net/gudev-sharp/+download
 * Someone/Some team should be subscribed to Ubuntu bugmail
 * Using shlibs.local is odd, not sure why it was needed, but isn't harmful

[Michael Terry (mterry)]

gtk-sharp-beans is approved. Though again, it would be nice to see a bug subscriber in Ubuntu.

[Michael Terry (mterry)]

gkeyfile-sharp is mostly good, but I couldn't approve because debian/copyright isn't correct. It doesn't mention the copyright or MIT license of GKeyFile/GKeyFile.custom.

Other (non-blocking) nits:
 * Should be synced from Debian experimental. I filed bug 688201 for that.
 * Someone should subscribe to Ubuntu bugmail.

[Michael Terry (mterry)]

Approved. Bug 650536 deserves some watching, but seems not-actionable right now. As always, it would be nice to see an Ubuntu bugmail subscriber.

[Michael Terry (mterry)]

I looked ever-so-briefly at banshee itself, and I noticed that debian/copyright nicely lists copyright statements, but has no license information at all except for some CC stuff for the help. The source looks like a mix of MIT and GPL-2. That should be mentioned and is likely a blocker.

[Chow Loong Jin (hyperair)]

On Friday 10,December,2010 03:58 AM, Michael Terry wrote:
> I looked ever-so-briefly at banshee itself, and I noticed that
> debian/copyright nicely lists copyright statements, but has no license
> information at all except for some CC stuff for the help. The source
> looks like a mix of MIT and GPL-2. That should be mentioned and is
> likely a blocker.
>

It looks more like a mix of MIT, LGPL-2+ and LGPL-2.1+. I don't see any GPL-2
code within it. At least not from a quick licensecheck probe.

--
Kind regards,
Loong Jin

[Kate Stewart (kate.stewart)]

Those still pending fixes have been move to natty-alpha-2 to track since natty-alpha-1 has been released.

[Michael Terry (mterry)]

OK, I uploaded a new banshee that doesn't build against libkarma. I filed bug 691573 about the libkarma issues so that they don't get forgotten and maybe we can re-enable it in the future. But this stops libkarma from being a blocker for now.

[Michael Terry (mterry)]

I uploaded a new gkeyfile-sharp that fixes debian/copyright. I also sent my changes to Debian, so hopefully we can resync this later.

[David Nielsen (davidnielsen-deactivatedaccount)]

Regarding Banshee on ARM I recall directhex saying he had that running in our IRC channel (#banshee on GIMPNet) which unfortunately doesn't appear to be logged so I can't reference currently. Perhaps someone could ping him to expand?

[Alexander Sack (asac)]

ok approved. there still are issues on ARM though that need to be fixed (bug 619981) ... marked them as RC for natty now.

[Matthias Klose (doko)]

taglib-sharp notify-sharp mono-zeroconf gudev-sharp-1.0 gtk-sharp-beans gkeyfile-sharp gio-sharp gdata-sharp banshee promoted.

[Matthias Klose (doko)]

banshee needs to be seeded

[Alexander Sack (asac)]

needs to be seeded != incomplete MIR bug ....

didrocks can you get this seeded please?