Hiya, This is a little tracker to keep an eye on bugs for programs that are both incompatible with bluez-4 or compatible but are missing the appropriate DEPEND flag...
And what about the upgrade path? Portage won't see bluez-4 as an update for bluez-{libs,utils}...
I have modified the following ebuilds to make them compatible with the last bluez-4. They won't need bluez-{libs,utils} family any more. ./media-sound/pulseaudio/pulseaudio-0.9.13.ebuild ./gnome-base/gvfs/gvfs-1.0.3.ebuild ./dev-python/pybluez/pybluez-0.15.ebuild ./app-mobilephone/gnome-phone-manager/gnome-phone-manager-0.60.ebuild ./app-mobilephone/gammu/gammu-1.22.1.ebuild ./app-mobilephone/obexftp/obexftp-0.22.ebuild ./net-libs/libpcap/libpcap-1.0.0-r1.ebuild ./net-wireless/gnome-bluetooth/gnome-bluetooth-0.11.0.ebuild ./net-wireless/bluez-gnome/bluez-gnome-1.8.ebuild ./net-wireless/libbtctl/libbtctl-0.10.0.ebuild ./net-wireless/bluez/bluez-4.26.ebuild ./gnome-extra/gnome-vfs-obexftp/gnome-vfs-obexftp-0.4.ebuild moreover wammu refuses to run until python-gammu is built with the LDFLAGS="-lbluetooth" flag. The python helper needs Cores.so and bluetooth.so library. Also, libbtctl needs a new patch libbtctl-hci_remote_name.patch to compile
Created attachment 178234 [details, diff] /bluez-4.26.ebuild
Created attachment 178235 [details, diff] bluez-gnome-1.8.ebuild
Created attachment 178237 [details, diff] gammu-1.22.1.ebuild
Created attachment 178239 [details, diff] gnome-bluetooth-0.11.0.ebuild
Created attachment 178240 [details, diff] gnome-phone-manager-0.60.ebuild
Created attachment 178242 [details, diff] gnome-vfs-obexftp-0.4.ebuild
Created attachment 178243 [details, diff] gvfs-1.0.3.ebuild
Created attachment 178244 [details, diff] libbtctl-0.10.0.ebuild
Created attachment 178246 [details, diff] libpcap-1.0.0-r1.ebuild
Created attachment 178248 [details, diff] obexftp-0.22.ebuild
Created attachment 178250 [details, diff] pulseaudio-0.9.13.ebuild
Created attachment 178252 [details, diff] pybluez-0.15.ebuild
Created attachment 178254 [details, diff] libbtctl-hci_remote_name.patch
Created attachment 178295 [details, diff] wammu-0.29.ebuild.diff
Your bluez ebuild should go to http://bugs.gentoo.org/show_bug.cgi?id=236357
*** Bug 256922 has been marked as a duplicate of this bug. ***
Would a bluez4 USE flag solve most of the dependency / resolve issues blocking bluez-4* from the portage tree? I've just now noticed the whole bluez-4* issue, and probably enough work has been done to make my idea obsolete. I put the comment here, simply because it affects these ebuilds, not bluez-4* itself.
Okay, now that the bugs blocking this are fixed, here's a list of stuff that still uses only bluez-libs || utils ------------------ # Bump to 0.12 faw bluez-4 support sys-fs/obexfs # Obsolete gnome-extra/gnome-vfs-obexftp -> gvfs[bluetooth] net-wireless/bluez-bluefw -> net-wireless/bluez-firmware net-wireless/bluez-hciemu net-wireless/kdebluetooth -> kdebluetooth4 # Unmaintained net-wireless/blueproxy app-mobilephone/scmxx app-mobilephone/x70talk net-misc/asterisk-chan_bluetooth x11-plugins/gkrellm-bluez sys-auth/pam_blue (homepage gone) net-wireless/ussp-push (and obsolete) # Status Unknown app-accessibility/brltty app-pda/libopensync-plugin-irmc app-pda/multisync app-pda/pilot-link
(In reply to comment #20) > Okay, now that the bugs blocking this are fixed, here's a list of stuff that > still uses only bluez-libs || utils > > ------------------ > # Bump to 0.12 faw bluez-4 support > sys-fs/obexfs > Its changelog says that it shouldn't depend on bluez since 0.11 > # Obsolete > gnome-extra/gnome-vfs-obexftp -> gvfs[bluetooth] > net-wireless/bluez-bluefw -> net-wireless/bluez-firmware > net-wireless/bluez-hciemu > net-wireless/kdebluetooth -> kdebluetooth4 > ... > # Unmaintained > net-wireless/blueproxy I think that it can be masked for removal > app-mobilephone/scmxx Cannot get bluetooth USE flag dropped? > app-mobilephone/x70talk > net-misc/asterisk-chan_bluetooth No upstream updates since 2004, I think that it could be masked for removal > x11-plugins/gkrellm-bluez I have been unable to find any patch for bluez-4, maybe it should be masked also > sys-auth/pam_blue (homepage gone) > net-wireless/ussp-push (and obsolete) > Not sure about its status, seems that debian still provides them: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=534320 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=530359 But I am not sure if they really can work with bluez-4 :-/ > # Status Unknown > app-accessibility/brltty 4.0 is from May 15, 2009, then, it seems to have an active upstream > app-pda/libopensync-plugin-irmc This seems to be being tracker in bug 272737 (maybe should be marked as a blocker of this one) > app-pda/multisync Shouldn't opensync replace it?: http://multisync.sourceforge.net/news.php > app-pda/pilot-link > I am not sure if bug 271473 includes bluez-4 support, anyway USE flag should be dropped also :-/
(In reply to comment #20) > x11-plugins/gkrellm-bluez 20 May 2009; Robin H. Johnson <robbat2@gentoo.org> gkrellm-bluez-0.2-r1.ebuild: Update for bluez split. Works here. Solved :-) > net-wireless/ussp-push (and obsolete) > 15 Jun 2009; Zac Medico <zmedico@gentoo.org> +ussp-push-0.9-r1.ebuild: Pull in bluez instead of bluez-libs, and call hci_read_remote_name instead of hci_remote_name in obex_socket.c. > # Status Unknown > app-accessibility/brltty 11 Jun 2009; William Hubbs <williamh@gentoo.org> brltty-3.10.ebuild, brltty-4.0.ebuild: Fixed bluetooth dependency for bug #272735. > app-pda/pilot-link > 19 May 2009; Robin H. Johnson <robbat2@gentoo.org> pilot-link-0.12.3.ebuild, pilot-link-0.12.3-r1.ebuild, pilot-link-0.12.3-r2.ebuild: Update bluez dependancies per bug #269440.
I have been checking tree for bluez-utils and bluez-libs and seems that, after solving remaining bugs blocking this, transition would be completed
Everything done. Bug 276455 is open, but PMASKED.
