Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 236357 - net-wireless/bluez-* version bump to 4.*
Summary: net-wireless/bluez-* version bump to 4.*
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Tiziano Müller
URL:
Whiteboard:
Keywords:
: 246989 (view as bug list)
Depends on: 250909
Blocks:
  Show dependency tree
 
Reported: 2008-09-01 14:18 UTC by Mieszko Ślusarczyk
Modified: 2009-09-12 08:08 UTC (History)
41 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
net-wireless/bluez-4.6.ebuild (bluez-4.6.ebuild,3.73 KB, text/plain)
2008-09-30 15:34 UTC, Laurento Frittella (mrfree)
Details
files/4.6/bluetooth-conf.d (bluetooth-conf.d,257 bytes, text/plain)
2008-09-30 15:34 UTC, Laurento Frittella (mrfree)
Details
files/4.6/bluetooth-init.d (bluetooth-init.d,963 bytes, text/plain)
2008-09-30 15:34 UTC, Laurento Frittella (mrfree)
Details
net-wireless/bluez-gnome-1.4.ebuild (bluez-gnome-1.4.ebuild,1.25 KB, text/plain)
2008-09-30 15:35 UTC, Laurento Frittella (mrfree)
Details
app-mobilephone/obex-data-server-0.3.4.ebuild (obex-data-server-0.3.4.ebuild,723 bytes, text/plain)
2008-09-30 15:40 UTC, Laurento Frittella (mrfree)
Details
ebuilds for bluez-4* (bluez.tar.gz,4.58 KB, application/octet-stream)
2008-09-30 20:15 UTC, Martin Jansa
Details
bluez-4.17 ebuild and related ebuilds (bluez.tar.gz,3.94 KB, application/octet-stream)
2008-10-26 15:36 UTC, R. Bosch
Details
ebuild for net-wireless/bluez-4.17, with a few other packages (bluez+obex+pybluez.tar.gz,6.38 KB, application/octet-stream)
2008-10-31 13:45 UTC, Alexandre Hamelin
Details
bluez-gnome/files/bluez-gnome-1.8-ODS-API.patch (bluez-gnome-1.8-ODS-API.patch,5.17 KB, patch)
2008-11-14 13:38 UTC, Paul Philippov
Details | Diff
bluez-gnome/bluez-gnome-1.8.ebuild (bluez-gnome-1.8.ebuild,1.42 KB, text/plain)
2008-11-14 13:39 UTC, Paul Philippov
Details
bluez-4.19 ebuild patch (bluez-ebuild.patch,2.61 KB, patch)
2008-12-01 20:28 UTC, Davide Pesavento
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mieszko Ślusarczyk 2008-09-01 14:18:19 UTC
Bluez have released new major version of their libs and apps, can someone create ebuilds for them?

Reproducible: Always

Steps to Reproduce:
Comment 1 Luca Barbato gentoo-dev 2008-09-10 02:41:20 UTC
4.4 has been released recently, yet feels that the whole thing is still shaky.
I'm afraid it will take a bit of time. Summary updated accordingly.
Comment 2 Mieszko Ślusarczyk 2008-09-23 10:07:02 UTC
Big f** (fat) BUMP.
Is it really too hard to be done?
Comment 3 Laurento Frittella (mrfree) 2008-09-23 15:12:47 UTC
I've wrote bluez-4.6 bluez-gnome-1.4 and obexd-0.4 ebuilds this afternoon but the problem (not real a problem) is in obex-data-server. We need to wait for version 0.3.5 to have a working push obex with bluez-4 so I forced a wait() on myself waiting for a notify() from obex-data-server dev :)

obex-data-server-0.3.5 should be released in days...
Comment 4 Mieszko Ślusarczyk 2008-09-23 15:41:40 UTC
(In reply to comment #3)
> I've wrote bluez-4.6 bluez-gnome-1.4 and obexd-0.4 ebuilds this afternoon but
> the problem (not real a problem) is in obex-data-server. We need to wait for
> version 0.3.5 to have a working push obex with bluez-4 so I forced a wait() on
> myself waiting for a notify() from obex-data-server dev :)
> 
> obex-data-server-0.3.5 should be released in days...
> 

But what would be missing if you wouldn't wait for it?
Can you release here what you have at th moment?
Comment 5 Laurento Frittella (mrfree) 2008-09-30 15:34:06 UTC
Created attachment 166833 [details]
net-wireless/bluez-4.6.ebuild

Wow! I received a notityAll() via email from Martin Jansa so I attach the ebuilds... it's a work-in-progress (a work I've suspended for now) so maybe inaccurate maybe not. But if you want something to test... ;)
Comment 6 Laurento Frittella (mrfree) 2008-09-30 15:34:31 UTC
Created attachment 166835 [details]
files/4.6/bluetooth-conf.d
Comment 7 Laurento Frittella (mrfree) 2008-09-30 15:34:56 UTC
Created attachment 166837 [details]
files/4.6/bluetooth-init.d
Comment 8 Laurento Frittella (mrfree) 2008-09-30 15:35:35 UTC
Created attachment 166838 [details]
net-wireless/bluez-gnome-1.4.ebuild
Comment 9 Laurento Frittella (mrfree) 2008-09-30 15:40:27 UTC
Created attachment 166841 [details]
app-mobilephone/obex-data-server-0.3.4.ebuild

Imho the only useful ebuild in this set is the obex-data-server one. This version solves a very annoying bug (UTF encoding)

Another little thing... I forgot to add blocks in the bluez ebuild, starting from version 4 this is a all-in-one package so please remember to unmerge net-wireless/bluez-utils and net-wireless/bluez-libs
Comment 10 Martin Jansa 2008-09-30 18:40:45 UTC
(In reply to comment #9)
> Created an attachment (id=166841) [edit]
> app-mobilephone/obex-data-server-0.3.4.ebuild

Thanks, 

I've bumped locally bluez-4.9.ebuild and bluez-gnome-1.7 with only small changes of your ebuilds.

obex-data-server also build sucessfully with patch from 0.3.4 to svn-trunk revision 1983, with this small change:

--- configure.in        (revision 1983)
+++ configure.in        (working copy)
@@ -134,7 +134,7 @@
        AC_SUBST(GTHREAD_CFLAGS)
        AC_SUBST(GTHREAD_LIBS)

-       PKG_CHECK_MODULES(IMAGEMAGICK, ImageMagick >= $IMAGEMAGICK_REQUIRED)
+       PKG_CHECK_MODULES(IMAGEMAGICK, MagickWand >= $IMAGEMAGICK_REQUIRED)
        AC_SUBST(IMAGEMAGICK_CFLAGS)
        AC_SUBST(IMAGEMAGICK_LIBS)
 fi

You have to run autogen.sh before generating diff between 0.3.4 and svn-trunk or run autogen directly from ebuild.

It seems working, but my bluetooth headset is still not working (http://wiki.bluez.org/wiki/HOWTO/AudioDevices). Still errors from mplayer (I suppose simillar from skype etc.).

MPlayer interrupted with signal 2 in module ao2_init.
[AO_ALSA] alsa-lib: pcm_bluetooth.c:464:(bluetooth_hsp_hw_params) BT_SETCONFIGURATION failed : Input/output error(5)
[AO_ALSA] Cannot set hw parameters: Input/output error
Failed to initialize audio driver 'alsa:device=headset'
Cannot open/initialize audio device -> no sound.
Comment 11 Mieszko Ślusarczyk 2008-09-30 19:14:46 UTC
> (In reply to comment #9)
> I've bumped locally bluez-4.9.ebuild and bluez-gnome-1.7 with only small
> changes of your ebuilds.
> 
> obex-data-server also build sucessfully with patch from 0.3.4 to svn-trunk

Where are these ebuilds?
Comment 12 Martin Jansa 2008-09-30 20:15:15 UTC
Created attachment 166865 [details]
ebuilds for bluez-4*

Here it is

bluez/
bluez/app-mobilephone/
bluez/app-mobilephone/obex-data-server/
bluez/app-mobilephone/obex-data-server/Manifest
bluez/app-mobilephone/obex-data-server/files/
bluez/app-mobilephone/obex-data-server/files/ImageMagickWand.configure.patch
bluez/app-mobilephone/obex-data-server/obex-data-server-0.3.90_p1983.ebuild
bluez/app-mobilephone/obex-data-server/obex-data-server-9999.ebuild
bluez/net-wireless/
bluez/net-wireless/bluez-gnome/
bluez/net-wireless/bluez-gnome/Manifest
bluez/net-wireless/bluez-gnome/bluez-gnome-1.7.ebuild
bluez/net-wireless/bluez-libs/
bluez/net-wireless/bluez-libs/Manifest
bluez/net-wireless/bluez-libs/files/
bluez/net-wireless/bluez-libs/files/4/
bluez/net-wireless/bluez-libs/files/4/bluetooth-conf.d
bluez/net-wireless/bluez-libs/files/4/bluetooth-init.d
bluez/net-wireless/bluez-libs/bluez-libs-4.9.ebuild
Comment 13 Mieszko Ślusarczyk 2008-09-30 20:22:45 UTC
How about updating them to replace old bluez?
Comment 14 Mieszko Ślusarczyk 2008-09-30 20:28:44 UTC
Sorry, missed, that ebuild has already been renamet to bluez-libs.
How about naming it bluez and making it replace libs and utils?
Comment 15 Mieszko Ślusarczyk 2008-09-30 20:29:47 UTC
>>> Compiling source in /var/tmp/portage/net-wireless/bluez-libs-4.9/work ...
 * 
 * ERROR: net-wireless/bluez-libs-4.9 failed.
 * Call stack:
 * ebuild.sh, line   49:  Called src_compile
 * environment, line 2168:  Called econf '--enable-gstreamer' '--enable-alsa' '--enable-usb' '--enable-netlink' '--enable-tools' '--enable-bccmd' '--enable-hid2hci' '--enable-dfutool' '--disable-hidd' '--disable-pand' '--disable-dund' '--enable-cups' '--enable-manpages' '--enable-configfiles' '--disable-initscripts' '--disable-pcmciarules' '--disable-debug' '--localstatedir=/var'
 * ebuild.sh, line  546:  Called die
 * The specific snippet of code:
 * die "no configure script found"
 * The die message:
 * no configure script found
Comment 16 Mieszko Ślusarczyk 2008-09-30 20:33:10 UTC
And the older ebuild:

cp: nie można wykonać stat na `/home/mieszko/overlay/mieszko/net-wireless/bluez/files/bluez-utils-3.10.1-udev.rules': Nie ma takiego pliku ani katalogu
 * 
 * ERROR: net-wireless/bluez-4.6 failed.
 * Call stack:
 * ebuild.sh, line   49:  Called src_install
 * environment, line 2191:  Called die
 * The specific snippet of code:
 * newins "${FILESDIR}/bluez-utils-3.10.1-udev.rules" 70-bluetooth.rules || die;
Comment 17 Martin Jansa 2008-09-30 21:44:39 UTC
(In reply to comment #15)
> >>> Compiling source in /var/tmp/portage/net-wireless/bluez-libs-4.9/work ...
>  * 
>  * ERROR: net-wireless/bluez-libs-4.9 failed.

Sorry I forgot to add
S=${P/-libs}
in ebuild..
Comment 18 Mieszko Ślusarczyk 2008-09-30 22:26:46 UTC
(In reply to comment #17)

> Sorry I forgot to add
> S=${P/-libs}
> in ebuild..

But where should I add it?
Can you make a diff or brand new ebuild?
How about naming it (propely) bluez, and making it replace bluez-libs and bluez-utils.
Comment 19 Martin Jansa 2008-10-01 05:11:55 UTC
(In reply to comment #18)
> (In reply to comment #17)
> 
> > Sorry I forgot to add
> > S=${P/-libs}
> > in ebuild..
> 
> But where should I add it?
> Can you make a diff or brand new ebuild?
> How about naming it (propely) bluez, and making it replace bluez-libs and
> bluez-utils.

Put it ie. just after IUSE.

The problem with net-wireless/bluez-4.6 is because you haven't copied the udev files (bluez-utils-3.10.1-udev.rules, bluez-utils-3.10.1-udev.script) from portage-tree net-wireless/bluez-utils/files/, or you can comment that part of ebuild as I did, because I dont know if this script still work with bluez-4.

I used name bluez-libs-4.9 intentionally, because in portage tree are ebuilds depending on bluez-libs (ie obexftp, solid, obex-data-server), well even or bluez-utils (ie bluez-gnome). So you had to replace their dependency on bluez like this
bluetooth? ( net-wireless/bluez-libs )
bluetooth? ( || ( net-wireless/bluez-libs net-wireless/bluez ) )
similar with bluez-utils.

If you have a problem with applying this changes to ebuild, you should wait for proper ebuilds and not use this work-in-progress.

JaMa
Comment 20 Mieszko Ślusarczyk 2008-10-15 23:31:44 UTC
I've added it just after IUSE, so it looks like:


IUSE="alsa cups debug gstreamer old-daemons usb"
S=${P/-libs} 
RDEPEND="

and it still fails with the same error.

Can you correct me if I'm wrong?
Comment 21 Lukas Tischler 2008-10-16 07:40:21 UTC
(In reply to comment #20)
> IUSE="alsa cups debug gstreamer old-daemons usb"
> S=${P/-libs} 
> RDEPEND="

for me it worked with a
---- snip ----
S="${WORKDIR}/bluez-4.9"
---- snip 
---
after IUSE... but there is a lot of trouble with apps linked against the old bluez-libs
Comment 22 Mieszko Ślusarczyk 2008-10-16 10:27:17 UTC
(In reply to comment #21)
> (In reply to comment #20)
> > IUSE="alsa cups debug gstreamer old-daemons usb"
> > S=${P/-libs} 
> > RDEPEND="
> 
> for me it worked with a
> ---- snip ----
> S="${WORKDIR}/bluez-4.9"
> ---- snip 
> ---
> after IUSE... but there is a lot of trouble with apps linked against the old
> bluez-libs
> 
A lot of problems?
Such as?
Have you seen any advantages?
Maybe developers should try to install it parallell to old bluez?
Comment 23 Lukas Tischler 2008-10-16 10:34:01 UTC
> A lot of problems?
> Such as?
> Have you seen any advantages?
> Maybe developers should try to install it parallell to old bluez?

for me it didn't worked as expected but maybe for someone it works.
the only thing is, that it will break all packages depending on bluez-libs and some of them do not compile against the new version.
Comment 24 Martin Jansa 2008-10-16 10:40:24 UTC
I've noticed only problems with ebuilds depending on bluez-utils where change to depend on bluez-utils-3* or bluez-libs-4*, solved the problem. (I'm using version 4.13)

But I still have problem with headset :(
http://bugzilla.kernel.org/show_bug.cgi?id=11514(In reply to comment #22)
Comment 25 John W Eckhart 2008-10-16 19:33:33 UTC
I've added the very latest bluez-4.13 and bluez-gnome-1.8 to my portage overlay (along with updates to various other ebuilds to get them all to work).

You can either:
   Add https://git.lightning.homelinux.com/lightning-overlay.xml to the overlays list in /etc/layman/layman.cfg and then run layman -a jeckhart-overlay
   Or pull directly from git://git.lightning.homelinux.com/jeckhart-overlay.git

The bluez team moved from separate bluez-libs and bluez-utils to a single bluez release, which is what my overlay parallels.

This is the first release that worked with my BT keyboard and mouse via the dbus/ui integration rather than the manual hidd integration of the past, so I give it high marks for functionality. I haven't tested it on audio yet.
Comment 26 Mieszko Ślusarczyk 2008-10-16 20:36:32 UTC
(In reply to comment #25)

Can you make bluez completely replace bluez-libs and bluez-utils, and uninstall these?

Besides, there is a problem with init script:

~ # /etc/init.d/bluetooth start
/etc/init.d/bluetooth: line 44: syntax error: unexpected end of file
 * Starting Bluetooth ...
 *     Starting bluetoothd ...
Unknown option -s
 * start-stop-daemon: failed to start `/usr/sbin/bluetoothd'
Comment 27 Mieszko Ślusarczyk 2008-10-16 21:07:43 UTC
(In reply to comment #25)

BTW: it of course conflicts bluez-libs, so please make your bluez ebuild remove old ones.

How should I tell other ebuilds, that bluez provides what bluez-libs/bluez-utils provided?
Comment 28 R. Bosch 2008-10-25 19:30:45 UTC
(In reply to comment #27)
> (In reply to comment #25)
> 
> How should I tell other ebuilds, that bluez provides what
> bluez-libs/bluez-utils provided?

media-sound/pulseaudio has exactly that problem. It wants bluez-utils for the init script. Wasn't there a "provided" or "provides" rule?
Comment 29 R. Bosch 2008-10-25 21:05:38 UTC
(In reply to comment #28)
> (In reply to comment #27)
> media-sound/pulseaudio has exactly that problem. It wants bluez-utils for the
> init script. Wasn't there a "provided" or "provides" rule?
> 

How about combining the packages for starters (3.*)?
Next grep the portage tree for bluez-libs/utils and replace them with something like bluez-4.*
This way we keep backwards compatibility since we need utils to run the init script, and we can start adding 4.* releases to the portage tree.
Just my 2cents....
Comment 30 R. Bosch 2008-10-25 21:10:22 UTC
(In reply to comment #29)
> Next grep the portage tree for bluez-libs/utils and replace them with something
> like bluez-4.*
> This way we keep backwards compatibility since we need utils to run the init

Sorry, I meant that we could place ">=net-wireless/bluez-3" instead of ">=net-wireless/bluez-utils-3" or ">=net-wireless/bluez-libs-3"
Comment 31 R. Bosch 2008-10-26 10:35:11 UTC
affected apps in portage tree:
app-mobilephone/sobexsrv
app-pda/multisync
gnome-extra/gnome-vfs-obexftp
media-sound/pulseaudio
net-wireless/bluez-gnome
net-wireless/kdebluetooth
net-wireless/libbtctl
Comment 32 R. Bosch 2008-10-26 15:36:58 UTC
Created attachment 169935 [details]
bluez-4.17 ebuild and related ebuilds

File list:
app-mobilephone/
app-mobilephone/obex-data-server/
app-mobilephone/obex-data-server/obex-data-server-0.4.1.ebuild
app-mobilephone/obex-data-server/Manifest
net-wireless/
net-wireless/bluez-libs/
net-wireless/bluez-libs/Manifest
net-wireless/bluez-libs/bluez-libs-4.17.ebuild
net-wireless/bluez-libs/files/
net-wireless/bluez-libs/files/4/
net-wireless/bluez-libs/files/4/bluetooth-init.d
net-wireless/bluez-libs/files/4/bluetooth-conf.d
net-wireless/bluez-gnome/
net-wireless/bluez-gnome/bluez-gnome-1.8.ebuild
net-wireless/bluez-gnome/Manifest

Enjoy!
Comment 33 John W Eckhart 2008-10-26 17:58:01 UTC
(In reply to comment #32)

I dont think we should combine bluez-libs and bluez-utils to bluez-libs. Instead we should mirror the bluez teams scheme of naming the new package bluez (as I have done in my overlay). You'll notice I've updated a few packages depending on bluez in my overlay. When i get the chance I'll update the rest to depend on || ( net-wireless/bluez:4 ( net-wireless/bluez-utils net-wireless/bluez-libs ) ) or the appropriate equivalent.

I could be wrong about slotting ver 4 because the current ebuild doesn't coexist with the version 3 ebuilds but I think its the right move looking ahead.
Comment 34 R. Bosch 2008-10-26 19:57:17 UTC
(In reply to comment #33)
> I could be wrong about slotting ver 4 because the current ebuild doesn't
> coexist with the version 3 ebuilds but I think its the right move looking
> ahead.

No slots needed IMHO. Here's what I did for libbtctl:

------ DIFF ------
--- /usr/portage/net-wireless/libbtctl/libbtctl-0.9.0.ebuild    2007-11-17 14:36:28.000000000 +0100
+++ net-wireless/libbtctl/libbtctl-0.9.0.ebuild 2008-10-26 19:27:02.000000000 +0100
@@ -16,8 +16,8 @@
 IUSE="mono doc"
 
 RDEPEND=">=dev-libs/glib-2
-       >=net-wireless/bluez-utils-2.25
-       >=net-wireless/bluez-libs-2.25
+       || ( ( >=net-wireless/bluez-libs-2.25
+       >=net-wireless/bluez-utils-2.25 )  >=net-wireless/bluez-4 )
        >=dev-libs/openobex-1.2
        >=dev-lang/python-2.3
        >=dev-python/pygtk-2.0
------ END DIFF ------

Just check what version is installed. Worked fine here.
For the bluez package we could add a blockage with a note for the user to let him/her uninstall bluez-{libs,utils}.
Comment 35 Mieszko Ślusarczyk 2008-10-26 20:14:31 UTC
> No slots needed IMHO.
> Just check what version is installed. Worked fine here.
> For the bluez package we could add a blockage with a note for the user to let
> him/her uninstall bluez-{libs,utils}.
> 

That's exactly  what needs to be done.
Comment 36 Davide Pesavento gentoo-dev 2008-10-26 20:16:35 UTC
(In reply to comment #34)
> For the bluez package we could add a blockage with a note for the user to let
> him/her uninstall bluez-{libs,utils}.
> 

Recent versions of portage (>= 2.1.5 iirc) are able to handle the majority of cases where the depgraph has blockers by automatically uninstalling the conflicting packages (bluez-{libs,utils} in this case). We just have to set the appropriate blocker atoms in DEPEND.

I don't think bluez will ever support parallel installation of different major versions anyway, so the slotting seems a bit useless to me.
Comment 37 Alexandre Hamelin 2008-10-31 13:45:46 UTC
Created attachment 170402 [details]
ebuild for net-wireless/bluez-4.17, with a few other packages

Hi, after reading through this page I noticed that no one actually attached an updated ebuild for "net-wireless/bluez" to it. I decided to go ahead with it. Also included are a few other packages I had installed that I also updated:

app-mobilephone/obexftp
net-wireless/bluez-hcidump
sys-fs/obexfs
dev-python/pybluez

I didn't include all ebuilds for those packages so someone might want to add others.

Basically,

# tar -vxzf bluez+obex+pybluez.tar.gz -C /usr/local/portage/
# emerge -C bluez-utils bluez-libs bluez-hcidump pybluez obexfs obexftp
# echo 'net-wireless/bluez ~x86' >> /etc/portage/package.keywords
# echo 'net-wireless/bluez-hcidump ~x86' >> /etc/portage/package.keywords
# echo 'net-wireless/bluez-libs' >> /etc/portage/package.mask
# echo 'net-wireless/bluez-utils' >> /etc/portage/package.mask
# emerge -va bluez bluez-hcidump pybluez obexfs obexftp
Comment 38 Davide Pesavento gentoo-dev 2008-11-02 17:35:29 UTC
Please everyone:
- do not attach tarballs, they make reviewing difficult.
- this bug is about net-wireless/bluez-{libs,utils} (which will probably become net-wireless/bluez) and nothing else (the summary needs to be fixed); please file different bugs for packages like bluez-gnome, pybluez, obexd, etc...

Thanks!
Comment 39 Davide Pesavento gentoo-dev 2008-11-02 17:44:30 UTC
Also:
- do not attach the ebuild for version N+1 if it doesn't have any differences compared to version N, apart from the ebuild name.
- a unified diff is usually more useful and easier to review than the whole ebuild.

Thanks again!
Comment 40 Paul Philippov 2008-11-14 13:38:03 UTC
Created attachment 171712 [details, diff]
bluez-gnome/files/bluez-gnome-1.8-ODS-API.patch

Patch for bluez-gnome-1.8 to make it work with object-data-server 0.4 API
See http://wiki.muiline.com/obex-data-server/migrating_to_0.4

Incorporates patches from Mario_Limonciello (http://marc.info/?l=linux-bluetooth&m=122256527621027)

Now I can send files from Bluetooth applet without errors =)
Comment 41 Paul Philippov 2008-11-14 13:39:44 UTC
Created attachment 171714 [details]
bluez-gnome/bluez-gnome-1.8.ebuild

ebuild with patching
Comment 42 Mike Auty gentoo-dev 2008-11-14 14:06:15 UTC
Paul, thanks very much for your patches.

Betelgeuse/PDA herd/Mobile herd, this bug is beginning to build up and the larger it gets the harder it will be to make progress when the time comes to give people access to the newer versions.

As a start to that, would it be possible to get a masked version of the new combined bluez-4 ebuild into the tree?  Once that's there we can start a tracker of packages whose dependencies need changing, and spread the work out making it much easier to manage.  We can split out the bluez-gnome package request/patches/etc, and get a grip on updating all the relevant extra packages one at a time...

The tracker will probably have to track the following packages, which all seem to have some form of bluez- dependency.  I think that'll be a lot easier to do in many small bugs and in the main tree, rather than people creating overlays and trying to track all the packages that have issues and report all their results into this one bug...

ikelos ~ # qgrep -H bluez- | cut -d/ -f1-2 | sort -u
app-accessibility/brltty
app-mobilephone/gammu
app-mobilephone/gnokii
app-mobilephone/gnome-phone-manager
app-mobilephone/kmobiletools
app-mobilephone/obex-data-server
app-mobilephone/obexftp
app-mobilephone/scmxx
app-mobilephone/sobexsrv
app-mobilephone/x70talk
app-pda/libopensync-plugin-irmc
app-pda/libsyncml
app-pda/multisync
app-pda/pilot-link
dev-python/pybluez
gnome-base/gvfs
gnome-extra/gnome-vfs-obexftp
kde-base/solid
media-sound/pulseaudio
media-video/totem
net-analyzer/netcat6
net-misc/asterisk-chan_bluetooth
net-wireless/blueproxy
net-wireless/bluez-bluefw
net-wireless/bluez-firmware
net-wireless/bluez-gnome
net-wireless/bluez-hcidump
net-wireless/bluez-hciemu
net-wireless/bluez-libs
net-wireless/bluez-utils
net-wireless/bss
net-wireless/gnome-bluetooth
net-wireless/kdebluetooth
net-wireless/libbtctl
net-wireless/opd
net-wireless/ussp-push
sec-policy/selinux-bluez
sys-auth/pam_blue
sys-fs/obexfs
x11-plugins/gkrellm-bluez

Do you guys need any help is getting this sorted?  I'd be happy to commit a masked version of bluez-4, if it will help progress this bug?

John (from comment 33), if the two packages can't live side-by-side, I'd suggest they not be slotted.  I understand the desire to be able to easily differentiate on the major changes between 2/3 and 4, but slotting has a specific use and I'd advise against without very strong reasons for misusing it.
Comment 43 Davide Pesavento gentoo-dev 2008-11-14 17:46:46 UTC
IMHO we should think a bit about the upgrade path from v3 to v4, to make it as smooth and painless as possible for users.

I've done a few tests in a local overlay and portage (2.2_rc*) does not seem to be able to automatically resolve blockers by uninstalling net-wireless/bluez-{libs,utils}-3* and installing the newer net-wireless/bluez-4*.

zmedico says:
"In order for portage to resolve the blockers automatically in a case
like this, it's best to exclude the old bluez-libs and bluez-utils
packages from the new reverse dependencies. That makes it easier for
the dependency resolver to know that it should uninstall those
packages rather than try to choose them to satisfy the dependency."

In other words, every reverse dependency must be revbumped and the new revision must only contain atoms involving bluez-4 or later among its dependencies, if compatible of course. This can become a nightmare to maintain in the future.

Another possible solution (probably better but still untested) could be a pkgmove bluez-utils -> bluez.
Comment 44 Mike Auty gentoo-dev 2008-11-14 18:09:27 UTC
The package move idea would be a bit of mess and my guess is it would only confuse everybody.  On the one hand we can have consistent naming with upstream for a one-off payment of changing the deps on at most 40 packages, or having to support an inconsistent naming convention and confusion for users at the cost of a fairly trivial package move.

Given that it's just a one off dep change without any particularly long lasting effects, I'd vote for that one, but I guess the maintainers will best know how much user confusion is likely to come of a package move.

The revision bumps are about as painful as changing the dependencies.  One will force bluez-4 to be unmasked (or pairs of tracking ebuilds one for bluez-3, one for bluez-4), the other method doesn't offer a smooth upgrade and would require an upgrade guide (just like gcc) and require users to uninstall packages (just like they have to with the current portage).

My problem with the revision bump is that it removes the possibility of swapping between the bluez versions.  If someone wants to install a program that only supports bluez-3, they'll have to downgrade all their other bluez-4 versioned programs to the last revision that supported bluez-3, even though they may all build fine with bluez-3.  I don't know how easy portage would make the transition in this situation.  Again it's a trade off only the maintainers can make.

Either way, I'd like to get this moving before we get our first program that only works with bluez-4 and it's nowhere near tree-ready.  I'm happy to offer my dev time to help work on some of the ebuilds to get them into the tree if time is the issue...
Comment 45 Tiziano Müller gentoo-dev 2008-11-28 21:28:01 UTC
*** Bug 246989 has been marked as a duplicate of this bug. ***
Comment 46 Tiziano Müller gentoo-dev 2008-11-28 21:54:34 UTC
Hmm, should have done the re-assign a bit earlier.
bluez-4.19 is now in the tree, together with bluez-gnome-1.8.
Still p.masked though :)
Comment 47 Davide Pesavento gentoo-dev 2008-12-01 20:28:55 UTC
Created attachment 173997 [details, diff]
bluez-4.19 ebuild patch

I was using this patch locally. Please consider it for inclusion. Thanks.
Comment 48 Davide Pesavento gentoo-dev 2008-12-01 20:30:12 UTC
BTW, bluez-4.21 has been released.
Comment 49 Norman Jonas 2008-12-11 11:37:56 UTC
For sending files to work app-mobilephone/obex-data-server has to be built without --enable-system-config. This works for me and I found this solution at http://bugs.archlinux.org/task/11502#comment33860

If wanted I can create an extra bug for this issue.
Comment 50 Norman Jonas 2008-12-11 13:33:32 UTC
I created an ebuild for gvfs-1.0.3 which adds support for browsing bluetooth devices using bluez-4 / bluez-gnome-1.8 in bug #250615
Comment 51 James Le Cuirot gentoo-dev 2008-12-22 21:13:04 UTC
The ebuild for 4.21 currently in the tree fails with test-programs enabled. input/test-input no longer exists and neither does test/auth-agent. test/passkey-agent has been renamed to just test/agent. This name seems a little too generic to me though and could potentially conflict with other packages. I think at least supporting the test passkey agent is important because it's the only command line agent available.
Comment 52 Alexandre Ghisoli 2009-02-06 08:55:21 UTC
Bluez-4.28 is out and contain interresting fixes as well :

------------
This release contains mostly fixes for the audio support. The SBC encoder should now produce a much better audio quality and its performance should increase noticeably on ARM and x86 platforms.

The ALSA plugin now contains a fix to avoid invalid memory access. This might break some audio players that make assumption on some ALSA API calls that are ambigue. Please report any problems you might encounter.
------------
Comment 53 Christian Schmitt 2009-02-14 00:10:22 UTC
If I am not mistaken, we need to change the /etc/dbus-1/system.d/bluetooth.conf file to contain "<policy group="plugdev">" instead of "at_console", just like we do it with networkmanager config files.
At least this helped here to get kbluetooth4 starting again.
Comment 54 James Le Cuirot gentoo-dev 2009-02-14 08:05:42 UTC
I've seen a fair few permission errors so you're probably right. Someone posted an alternative version in bug #214554, which fixed some of the errors but not all of them. It still only says at_console rather than plugdev.
Comment 55 Christian Schmitt 2009-02-16 12:49:23 UTC
Could you please push a new release with the fix included?
Comment 56 Tiziano Müller gentoo-dev 2009-02-16 19:42:36 UTC
no, at_console is a functionality of dbus and was broken since the the removal of pam_console. Since we added patches & scripts to ConsoleKit to replace pam_console's functionality to make it work again, bluez will depend on sys-auth/pambase[consolekit] beginning from the next version.
If you want to test it out, install sys-auth/pambase with USE=consolekit set (make sure you sync before), restart your computer and it should work again.
Comment 57 Jory A. Pratt gentoo-dev 2009-02-17 04:09:20 UTC
version 4.30 has been released with more major updates. I still have not seen a working setup that allows obex file push or file browsing but who can say what lays ahead with the new update.
Comment 58 Tiziano Müller gentoo-dev 2009-02-17 06:26:32 UTC
ok, I'll try to check that too. But first I have to take care of that bug concerning PAN.
Comment 59 Mike Auty gentoo-dev 2009-02-17 10:02:07 UTC
Gentoobugsie, what method are you using to try OBEX reads and OBEX file writes?

OBEX reads should require USE="bluetooth" gvfs (for the latest versions of gnome, or gnome-vfs-obexftp for older versions), and the latest gvfs only very recently got support for file writing (see gnome bug 519071 at [1]).  Gentoo bug 249314 is relevant to that.

The other method is the "send files to device..." but I believe that requires a fairly recent version of obex-data-sever (and not obexd as produced by bluez officially, since they collide in the Dbus namespace).

Finally, there are other tools (such as obexftp) that should let you manually push files out.  Which of those were you trying to use?

[1] http://bugzilla.gnome.org/show_bug.cgi?id=519071
Comment 60 Jory A. Pratt gentoo-dev 2009-02-17 13:39:40 UTC
(In reply to comment #59)
> Gentoobugsie, what method are you using to try OBEX reads and OBEX file writes?
> 
> OBEX reads should require USE="bluetooth" gvfs (for the latest versions of
> gnome, or gnome-vfs-obexftp for older versions), and the latest gvfs only very
> recently got support for file writing (see gnome bug 519071 at [1]).  Gentoo
> bug 249314 is relevant to that.
> 
> The other method is the "send files to device..." but I believe that requires a
> fairly recent version of obex-data-sever (and not obexd as produced by bluez
> officially, since they collide in the Dbus namespace).
> 
> Finally, there are other tools (such as obexftp) that should let you manually
> push files out.  Which of those were you trying to use?
> 
> [1] http://bugzilla.gnome.org/show_bug.cgi?id=519071
> 

[ebuild   R   ] dev-libs/openobex-1.4  USE="bluetooth usb -debug -irda -syslog" 0 kB [0]
[ebuild   R   ] gnome-base/gvfs-1.0.3-r11  USE="bluetooth gnome gnome-keyring hal -archive -avahi -bash-completion -cdda -debug -doc -fuse -gphoto2 -samba" 0 kB [0]
[ebuild   R   ] app-mobilephone/obex-data-server-0.4.2  USE="gtk -debug -imagemagick" 0 kB [0]
[ebuild   R   ] net-wireless/bluez-gnome-1.8  USE="gnome -debug" 0 kB

I am trying directly threw the tray icon so not sure which method it is attempting at the moment. I will check the logs latter tonight and see what they have to say.
Comment 61 Mike Auty gentoo-dev 2009-02-17 13:47:14 UTC
The bluetooth-applet from bluez-gnome has the "Send files to the device" option.  It probably should work, although I just tried it and it apparently didn't locate any nearby devices, so probably the D-Bus perms are a bit messed up...
Comment 62 Tiziano Müller gentoo-dev 2009-02-17 14:01:03 UTC
ikelos: do you have pambase built with USE=consolekit? If yes, is consolekit started before a user logs in? If yes, do you have consolekit-2.10-r1 installed (which should create a file /var/run/console/<USER> where <USER> is a user logged in on a local console) which includes a fix for dbus' at_console?
Comment 63 Jory A. Pratt gentoo-dev 2009-02-17 14:47:56 UTC
(In reply to comment #61)
> The bluetooth-applet from bluez-gnome has the "Send files to the device"
> option.  It probably should work, although I just tried it and it apparently
> didn't locate any nearby devices, so probably the D-Bus perms are a bit messed
> up...
> 

Neither work from the app here. I recieve an error 255 for browsing or sending a file.

Browse device returns exactly -

Error: Launch helper exited with unknown return code 255
Please select another viewer and try again.

Send file to device -

Error: Launch helper exited with unknown return code 255

I have scim'd threw my logs and do not see anything with regaurds to what is causing the error.
Comment 64 Mike Auty gentoo-dev 2009-02-17 15:05:10 UTC
Ok, first off apparently I didn't have USE="consolekit" (although I was running consolekit).  Now it turns out that because I use the gnome overlay, I'm using consolekit-0.3.0-r1, and that consolekit-0.2.10-r1 is different to the one in the main tree.  Consolekit-0.3.0-r1 doesn't seem to create /var/run/console/<USER> so it may be worth mentioning to Gilles, to keep the tree and gnome overlay in sync...

Once all that was in place, I could see other devices, but also got "Launch helper exited...".
Comment 65 Jesse Adelman 2009-03-08 23:48:43 UTC
4.32 is out. Is there a "official" gentoo layman overlay for bluetooth available which tracks these upstream updates? Thanks.

"Release of bluez-4.32
2nd March 2009, 03:00 am by Marcel Holtmann

The previous release fixed many SDP memory leaks, but unfortunately one of these fixes resulted in a segmentation fault in certain cases. This has been fixed now.

Release of bluez-4.31
26th February 2009, 12:30 am by Marcel Holtmann

This release contains the new BtIO helper functions and all plugins have been converted to use it. In addition it contains fixes for various issues and memory leaks."
Comment 66 James Le Cuirot gentoo-dev 2009-03-08 23:54:11 UTC
I just renamed 4.31 to 4.32 and that worked.

It may be of interest to some of you that I've managed to get my machine to run as a NAP without having to run any applets like Blueman or even having to make any D-Bus calls. I just create a pan1 bridge in the usual Gentoo way and have dhcpd listen on it. It works very well.

I've not had any luck in the other direction though. I've been digging through the Bluez source and I think I've found some problems that I've just mentioned on the mailing list.
Comment 67 Tiziano Müller gentoo-dev 2009-03-09 06:02:44 UTC
(In reply to comment #65)
> 4.32 is out. Is there a "official" gentoo layman overlay for bluetooth
> available which tracks these upstream updates? Thanks.
The Gentoo portage tree? It's all there... you just have to unmask it.
Comment 68 Jesse Adelman 2009-03-09 06:39:58 UTC
re comment 67: Ah, I see, bluez-* have been merged into one! :) Thanks.
Comment 69 Erik Boritsch 2009-04-11 01:54:19 UTC
I get followings while trying to get bluetooth-applet to work:

Agent registration failed: A security policy in place prevents this sender from sending this message to this recipient, see message bus configuration file (rejected message had interface "org.bluez.Adapter" member "RegisterAgent" error name "(unset)" destination "org.bluez")

Could it be that dbus config has changed or do I need to file a new bug?
Comment 70 Maciej Józiewicz 2009-04-20 20:57:29 UTC
I have the same dbus problem. For the time being I added:
  <policy group="plugdev">
    <allow send_destination="org.bluez"/>
  </policy>
to bluetooth.conf and it seems to work.
Comment 71 Bernard Cafarelli gentoo-dev 2009-04-24 08:04:35 UTC
With consolekit-enabled pambase (as dep of bluez), a pulseaudio ebuild tweak to depend on bluez, and after a few service restarts (dbus bluetooth X ...), latest packages work quite well for me, with blueman (did not test bluetooth-applet a lot, it segfaults with nvidia-drivers), and without needing to modify dbus configuration for bluetooth.

Comment 72 Oldrich Jedlicka 2009-05-05 07:34:39 UTC
Any plans to move to bluez-4 and to stabilize it?
Comment 73 Davide Pesavento gentoo-dev 2009-07-21 22:02:21 UTC
bluez-4.x has been in portage for months, why is this bug still open?
Comment 74 Pacho Ramos gentoo-dev 2009-07-22 11:01:29 UTC
I also think that this bug should be closed
Comment 75 Nirbheek Chauhan (RETIRED) gentoo-dev 2009-09-12 08:08:22 UTC
(In reply to comment #73)
> bluez-4.x has been in portage for months, why is this bug still open?
> 

Marking FIXED, stabilization bug is bug 284661