Bluez have released new major version of their libs and apps, can someone create ebuilds for them? Reproducible: Always Steps to Reproduce:
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.
Big f** (fat) BUMP. Is it really too hard to be done?
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...
(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?
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... ;)
Created attachment 166835 [details] files/4.6/bluetooth-conf.d
Created attachment 166837 [details] files/4.6/bluetooth-init.d
Created attachment 166838 [details] net-wireless/bluez-gnome-1.4.ebuild
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
(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.
> (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?
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
How about updating them to replace old bluez?
Sorry, missed, that ebuild has already been renamet to bluez-libs. How about naming it bluez and making it replace libs and utils?
>>> 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
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;
(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..
(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.
(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
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?
(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
(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?
> 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.
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)
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.
(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'
(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?
(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?
(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....
(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"
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
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!
(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.
(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}.
> 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.
(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.
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
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!
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!
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 =)
Created attachment 171714 [details] bluez-gnome/bluez-gnome-1.8.ebuild ebuild with patching
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.
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.
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...
*** Bug 246989 has been marked as a duplicate of this bug. ***
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 :)
Created attachment 173997 [details, diff] bluez-4.19 ebuild patch I was using this patch locally. Please consider it for inclusion. Thanks.
BTW, bluez-4.21 has been released.
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.
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
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.
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. ------------
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.
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.
Could you please push a new release with the fix included?
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.
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.
ok, I'll try to check that too. But first I have to take care of that bug concerning PAN.
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
(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.
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...
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?
(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.
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...".
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."
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.
(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.
re comment 67: Ah, I see, bluez-* have been merged into one! :) Thanks.
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?
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.
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.
Any plans to move to bluez-4 and to stabilize it?
bluez-4.x has been in portage for months, why is this bug still open?
I also think that this bug should be closed
(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
