Re: upload/transition of bluez 4.x
Filippo Giunchedi wrote:
> [please CC, I'm not subscribed]
>
> On Thu, May 21, 2009 at 06:43:11PM +0200, Filippo Giunchedi wrote:
>> Hi,
>> I'm planning to upload bluez 4.x to unstable shortly, though this release bumps
>> the soname for libbluetooth from 2 to 3, these packages build-depend on
>> libbluetooth2-dev and I intend to file bugs suggesting to switch to
>> libbluetooth-dev:
>
> upload done, fortunately libbluetooth2 come from bluez-libs while libbluetooth3
> from bluez so it didn't disappear.
>
>> multisync
>> ussp-push
>> bluemon
>> scmxx
>> transfermii
>> libopensync-plugin-irmc
>> libpam-blue
>> btscanner
>> brltty
>
> done, see
> http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=filippo@debian.org;tag=bluez4-transition
> and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=527503
>
>> for these a (binNMU) rebuild should be sufficient provided they don't break:
>>
>> obexpushd
>
> FTBFS #527726
>
>> kdebase-workspace
>> libnet-bluetooth-perl
>> python2.5
>> python2.4
>> amora-server
>> gnokii
>> obexftp
>> libopenobex
>> freej
>> gpe-bluetooth
>> pilot-link
>> gammu
>> pybluez
>> totem
>> anyremote
>> bluez-hcidump
>> qemu
>> osso-gwconnect
>> cwiid
>
> these still stand for a binNMU to rebuild against libbluetooth3
>
>> obex-data-server
>> gnome-bluetooth
>
> not needed
>
>> libbtctl
>> gnome-vfs-obexftp
>
> shall be removed, will file bugs
>
> what's the best way to proceed?
binNMUs scheduled.
Best way is to track the binNMUs and the packages that need an updated
build dependency to make sure they all transition to libbluetooth3 (or
are removed).
Cheers
Luk
Reply to: