--- This release contains a fix for memory allocation with the creation of PDUs inside the SDP handling. It also fixes various race conditions inside some D-Bus method calls. With this release the HID proxy switching is changed to use udev rules and also adds support for Dell based devices. ---
Created attachment 192141 [details] ebuild change from 4.39 to 4.40
index.sgml is not found during install, but no fatal error
Please also see the changes regarding pam (bug 269373) that should be made to the bluez-4.40 ebuild.
bluez-4.44 has been released. Note that version 4.43 "removes the full support for starting bluetoothd from init process. The provided preferred method is now to start it from udev once a Bluetooth adapter is present." (from the release announcement)
Created attachment 197141 [details] bluez-4.45.ebuild I've bumped the ebuild from portage up to newest version. I tried removing a lot of the old deprecated stuff like init.d daemons. I have it working well and starting automatically with udev. Please fix any problems and clean it up, so it can be added to portage!
Hmm.. I just realized that bluetoothd isn't started with udev at boot. I have to run "/etc/init.d/udev restart" and then it works fine. I see that there were some udev rule adjustments in the old ebuild, but I think too much as changed to reuse them. I don't really understand how udev works, so someone else will have to fix this.
(In reply to comment #5) > Created an attachment (id=197141) [edit] > bluez-4.45.ebuild > > I've bumped the ebuild from portage up to newest version. I tried removing a > lot of the old deprecated stuff like init.d daemons. I have it working well > and starting automatically with udev. Please fix any problems and clean it up, > so it can be added to portage! > Why have you removed the dep on pambase[consolekit]?
Created attachment 197275 [details] bluez-4.45.ebuild Forgot to add the pambase dependency as a use flag.
(In reply to comment #6) > Hmm.. I just realized that bluetoothd isn't started with udev at boot. I have > to run "/etc/init.d/udev restart" and then it works fine. bluetoothd requires dbus, which isn't running at that time. No need to restart udevd though, `udevadm trigger --subsystem-match=bluetooth` is enough to start bluetoothd later, when dbus is running.
This is interesting: http://www.linux-archive.org/fedora-development/316405-heads-up-bluetoothd-demand-startup.html
Created attachment 197621 [details, diff] diff 4.39 -> 4.45 *) Added consolekit and pcmcia USE flags. *) The --as-needed patch is not necessary, it compiles fine here. *) Removed some obsolete ewarns and elogs. *) Don't install useless .la files. *) I've kept the old-daemons USE flag, but it's totally untested.
(In reply to comment #11) > Created an attachment (id=197621) [edit] > diff 4.39 -> 4.45 > > *) Added consolekit and pcmcia USE flags. > *) The --as-needed patch is not necessary, it compiles fine here. > *) Removed some obsolete ewarns and elogs. > *) Don't install useless .la files. > *) I've kept the old-daemons USE flag, but it's totally untested. > Your ebuild is lot better, but could you add a pam use flag as per Bug #269373?
Well, the conditional dep on pambase[consolekit] is under the 'consolekit' USE flag, but it can be changed to 'pam' of course... dunno which one is better...
(In reply to comment #13) > Well, the conditional dep on pambase[consolekit] is under the 'consolekit' USE > flag, but it can be changed to 'pam' of course... dunno which one is better... > Ah of course, missed that. Makes sense the way you did it.
(In reply to comment #9) > (In reply to comment #6) > > Hmm.. I just realized that bluetoothd isn't started with udev at boot. I have > > to run "/etc/init.d/udev restart" and then it works fine. > > bluetoothd requires dbus, which isn't running at that time. > No need to restart udevd though, `udevadm trigger --subsystem-match=bluetooth` > is enough to start bluetoothd later, when dbus is running. > Even better: udevadm trigger --type=failed I think this command should be added by default to an init script which is run later on in the boot sequence (at least after dbus).
Created attachment 199029 [details, diff] 4.46-conditional_libsbc.patch
Created attachment 199031 [details, diff] diff 4.39 -> 4.46 No changes apart from the updated libsbc patch.
(In reply to comment #15) > (In reply to comment #9) > > (In reply to comment #6) > > > Hmm.. I just realized that bluetoothd isn't started with udev at boot. I have > > > to run "/etc/init.d/udev restart" and then it works fine. > > > > bluetoothd requires dbus, which isn't running at that time. > > No need to restart udevd though, `udevadm trigger --subsystem-match=bluetooth` > > is enough to start bluetoothd later, when dbus is running. > > > > Even better: udevadm trigger --type=failed > I think this command should be added by default to an init script which is run > later on in the boot sequence (at least after dbus). > Well, udevadm trigger --type=failed doesn't work. There has been a lot of confusion about this between the various devs and distros maintainers. It's currently unclear whether udev will be fixed or bluetoothd will be reverted to the old startup method (init script). Meanwhile some distros like Fedora are shipping an (ugly) script which unconditionally re-triggers all bluetooth events after dbus has been started. BTW, bluez-4.48 has been released, though I suggest not to bump the package until the startup issue is resolved.
(In reply to comment #18) > (In reply to comment #15) > > (In reply to comment #9) > > > (In reply to comment #6) > > > > Hmm.. I just realized that bluetoothd isn't started with udev at boot. I have > > > > to run "/etc/init.d/udev restart" and then it works fine. > > > > > > bluetoothd requires dbus, which isn't running at that time. > > > No need to restart udevd though, `udevadm trigger --subsystem-match=bluetooth` > > > is enough to start bluetoothd later, when dbus is running. > > > > > > > Even better: udevadm trigger --type=failed > > I think this command should be added by default to an init script which is run > > later on in the boot sequence (at least after dbus). > > > > Well, udevadm trigger --type=failed doesn't work. > > There has been a lot of confusion about this between the various devs and > distros maintainers. It's currently unclear whether udev will be fixed or > bluetoothd will be reverted to the old startup method (init script). Meanwhile > some distros like Fedora are shipping an (ugly) script which unconditionally > re-triggers all bluetooth events after dbus has been started. > > BTW, bluez-4.48 has been released, though I suggest not to bump the package > until the startup issue is resolved. > Make that 4.49 as of today.
current bluez version is 4.5 , patches applied in 4.39 are no longer necessary. 4.46 fixed these: This release fixes many memory leaks and wrong pointer usages. It should make the daemon overall more stable than ever. In addition the support for A2DP sinks got merged. Any kind of feedback is more than welcome.
Patches are still needed, they just don't apply because the build system was overhauled in version 4.49.
Created attachment 202435 [details, diff] 4.50-conditional-libsbc.patch Updated patch.
Created attachment 202437 [details, diff] 4.50-cups-location.patch Updated patch.
Created attachment 202439 [details, diff] diff 4.39 -> 4.50 Added a couple of missing deps; removed 'doc' USE flag (dropped upstream); --enable-manpages is no longer necessary (manpages are always installed now).
Perhaps emerald or someone should rename this bug to bump to 4.5? Also anything stopping 4.5 getting into portage?
(In reply to comment #25) > Also anything stopping 4.5 getting into portage? > Yes. IMHO we should wait for udev-146 (recently released), which actually has a working implementation of failed RUNs tracking (please read the above comments), then add a new init script, installed by udev, which runs 'udevadm trigger --type=failed', and add it near the end of the boot sequence. Then finally we can bump bluez, adjusting the udev dependency to >=sys-fs/udev-146.
Created attachment 202935 [details, diff] Patch for kitless systems, makes consolekits dependency unnecessary Solves #279616 and #276993
(In reply to comment #27) > Created an attachment (id=202935) [edit] > Patch for kitless systems, makes consolekits dependency unnecessary > > Solves #279616 and #276993 > Post unified diffs please (diff -u). Doesn't your patch also require the creation of a 'bluetooth' group?
(In reply to comment #26) > (In reply to comment #25) > > Also anything stopping 4.5 getting into portage? > > > > Yes. IMHO we should wait for udev-146 (recently released), which actually has a > working implementation of failed RUNs tracking (please read the above > comments), then add a new init script, installed by udev, which runs 'udevadm > trigger --type=failed', and add it near the end of the boot sequence. Then > finally we can bump bluez, adjusting the udev dependency to >=sys-fs/udev-146. > Add udevadm "trigger --type=failed" to the end of the boot runlevel or the default runlevel?
default runlevel, it needs dbus, which is usually started in the default runlevel.
Created attachment 203250 [details] bluez-4.50.ebuild This ebuild integrates the changes from the recently released 4.39-r1 ebuild. It also draws from the goal of bug 269373. It now depends on udev-146 which you'll have to get from bug 283414. The new version of udev now comes with an init script to run a failed udev trigger after dbus inits. I would have made this ebuild 4.51 or 4.52 but apparently those builds are failing to compile right now due to a permissions problem.
Uh? I have 4.52 working fine locally... (I had to drop the conditional-libsbc patch though)
Created attachment 203296 [details] build.log bluez-4.52 compile failure on x86.
(In reply to comment #32) > Uh? I have 4.52 working fine locally... (I had to drop the conditional-libsbc > patch though) > I also dropped that patch in testing but the compilation fails about half way in the make process.
Created attachment 203582 [details, diff] diff 4.39-r1 -> 4.52
Please bump to 4.53
(In reply to comment #36) > Please bump to 4.53 I tested bluez-4.53 using the patchs here, with pulseaudio 0.9.16-r51 and: 1. works well, 2. seems that when I increase the distance from my headphones to the receiver the pitch doesnt chance as much as it used to. it either stops playing or plays in the right tune. this issue was present since bluez began and is finally fixed! by the way I had to use d-feet after the upgrade to connect, as gnome-bluetooth had issues. Niv
Created attachment 206861 [details, diff] bluez-4.56.patch Patches 4.39-r2 to 4.56. Compiles fine now on x86 and amd64.
(In reply to comment #35) > Created an attachment (id=203582) [details] > diff 4.39-r1 -> 4.52 > btw, bison and flex are base packages.
Is the startup/udev issue supposed to be fixed now? I have udev-146-r1 but bluetoothd still does not start on boot when I have a dongle plugged in. I have to replug it to make it work. I've tried bluez 4.39-r2 and 4.56.
(In reply to comment #40) > Is the startup/udev issue supposed to be fixed now? Unfortunately not. udev init scripts still don't run `udevadm trigger --type=failed`.
(In reply to comment #39) > btw, bison and flex are base packages. But flex shouldn't be, it must be defined it deps so we can remove it from the system set. There's a tracker for that.
Created attachment 207755 [details, diff] diff 4.39-r2 -> 4.56 Another version bump. Support for POSIX capabilities dropping was added, however >=libcap-ng-0.6.2 is required which isn't currently available in portage. Also most keywords were dropped because of this new dependency.
Created attachment 208827 [details, diff] bluez 4.39-r2 -> 4.56
Created attachment 208829 [details, diff] bluez 4.39-r2 -> 4.56
Created attachment 208914 [details, diff] bluez 4.39-r2 -> 4.56
Created attachment 209213 [details, diff] Bump to 4.57 and fix udevadm postinst command
Created attachment 209232 [details, diff] bluez 4.39-r2 -> 4.57 Integrated 4.56 -> 4.57 patch.
(In reply to comment #48) > Created an attachment (id=209232) [details] > bluez 4.39-r2 -> 4.57 > > Integrated 4.56 -> 4.57 patch. > Why did you drop caps support?
Created attachment 209238 [details, diff] bluez 4.39-r2 -> 4.57 Added caps back in.
I have the following error when I build bluez-4.57 libtool: install: /usr/bin/install -c compat/.libs/dund /var/tmp/portage/net-wireless/bluez-4.57/image//usr/bin/dund !!! newconfd: /usr/local/portage/net-wireless/bluez/files/4.18/conf.d-hidd does not exist I emerge following way [ebuild U ] net-wireless/bluez-4.57 [4.39-r2] USE="alsa consolekit cups old-daemons usb -debug -doc -gstreamer -test-programs" 0 kB [0=>1]
Sorry. I forgot copy files from partage. Everything works.
Version 4.58 is out. This release contains a few minor fixes within the Bluetooth pairing and bonding handling.
The udev fixes have been applied now but bluetoothd still doesn't start. I have another machine now with a built-in adapter. I have to rmmod btusb and then reload it in order to make it start. I can start it manually, of course, but that's not the point.
(In reply to comment #54) > The udev fixes have been applied now but bluetoothd still doesn't start. I have > another machine now with a built-in adapter. I have to rmmod btusb and then > reload it in order to make it start. I can start it manually, of course, but > that's not the point. > Yes, I noticed that... Unfortunately I don't have the time right now to investigate whether it's a udev bug or bluez bug.
The udev-postmount script contains the required startup code but somehow bluetooth still doesn't start if the adapter is builtin or plugged in on boot. I've used the udev-postmount script ad 'template' for a small script, which runudevadm trigger --subsystem-match=bluetooth and bluetooth is working correctly afterwards. The same line can also be added to local(.start). The udevadm trigger --type=failed line seems not to trigger the correct bluetooth activation (with udev-147, udev-149 not yet tested), more details i didn't check for now.
Goodness, they are prolific. Happy New Year. They had a Xmas release of 4.59. Summary of changes since last Portage update (4.39-r2): "ver 4.59: Add values for Bluetooth 4.0 specification. Add SDP functions for HDP support. Add test scripts for input and audio. Fix missing close on BtIO create_io function. Fix sending incorrect AVDTP commands after timeout occurs. Fix timer removal when device disconnects unexpectedly. Fix Extended Inquiry Response record for Device ID. ver 4.58: Fix crash when adapter agent exists during authentication. Fix CK-20W quirks for play and pause events. ver 4.57: Fix unloading of drivers for uninitialized adapters. Fix debug message to use requested and not opened SEID. Fix codec selection for GStreamer plugin. Fix deleting of SDP records during service updates. Fix deleting of SDP records when a device is removed. Fix handling when the SDP record is modified on remote device. Fix potential buffer overflow by using snprintf instead of sprintf. Fix const declarations for some storage function parameters. ver 4.56: Add missing values from Bluetooth 3.0 specification. Add proper tracking of device paired status. Fix tracking of devices without permanently stored link key. Fix issue with link key removal after connection failures. Fix legacy pairing information based on remote host features. Fix off-by-one issue with AVDTP capability parsing. Fix AVRCP, AVCTP, AVDTP, A2DP and HFP version numbers. Fix agent canceling before calling agent_destroy. Fix service record parsing with an empty UUID list. Fix various SDP related memory leaks. ver 4.55: Add support for POSIX capabilities dropping. Add special quirk for the Nokia CK-20W car kit. Fix error code handling for AVDTP SetConfiguration response. Fix updating out of range list when RSSI hasn't changed. Fix various memory leaks and unnecessary error checks. ver 4.54: Add introspection interface to output of introspection calls. Fix stream handling when media transport disconnects prematurely. Fix command timeout handling when there's no stream. Fix headset_suspend_stream behavior for invalid states Fix issue with AVDTP ABORTING state transition. Fix issue with AVDTP suspend while closing. ver 4.53: Fix issue with telephony connection state notifications. Fix AVDTP stream leak for invalid media transport config. Fix audio connection authorization handling with timeouts. Fix race condition in authorizing audio connections. Fix device authorized setting for AVRCP-only connections. Fix duplicate attempts from device to connect signal channel. ver 4.52: Add AVCTP support to test utility. Fix AVDTP Abort when transport closes before response. Fix authorization when the audio profiles are slow to connect. Fix potential AVDTP reference leaks. ver 4.51: Add utility for basic AVDTP testing. Add support for configuring L2CAP FCS option. Fix discovery mode for CUPS 1.4.x and later. Fix global state tracking of audio service. Fix last issues with the new build system. ver 4.50: Fix issue with missing manual pages in distribution. Fix issue with the configuration and state directories. Fix issue with creating include directory. Fix dependencies of include file generation. ver 4.49: Add simple test program for basic GAP testing. Add support for confirmation requests to agent example. Add support for full non-recursive build. Add five millisecond delay for Simple Pairing auto-accept. Fix Class of Device setting when InitiallyPowered=false. ver 4.48: Add library function for comparing UUID values. Add support for creating all plugins as builtins. Add support for async handling of service class changes. Add support for source interface to audio IPC. Fix device name settings when device is off or down. Fix issue with enabled SCO server when not necessary. Fix missing D-Bus access policy for CUPS backend. Fix discovery results of CUPS backend. Fix initialization handling of Maemo telephony. ver 4.47: Add support for RFKILL unblock handling. Add support for serial proxy configurations. Add support for caching service class updates. Fix issues with updating SDP service records. Fix usage of limited discoverable mode. Remove deprecated methods and signals for AudioSource. ver 4.46: Add support for A2DP sink role. Fix clearing svc_cache before the adapter is up. Fix various pointer after free usages. Fix various memory leaks. ver 4.45: Fix UDEV_DATADIR fallback if pkg-config fails. Fix adapter cleanup and setup prototypes. Fix double-free with out-of-range devices. Fix inband ring setting to be per-headset. Fix handling of Maemo CSD startup. ver 4.44: Add some missing manual pages. Fix missing number prefix when installing udev rules. Fix program prefix used in Bluetooth udev rules. Fix three-way calling indicator order. Fix downgrade/upgrade of callheld indicator. Fix +CIEV sending when indicator value changes. Fix signal handling for Maemo telephony driver. Fix parsing issues with messages from Maemo CSD. Fix issue with duplicate active calls. ver 4.43: Add support for udev based on-demand startup. Fix verbose error reporting of CUPS backend. Fix various string length issues. Fix issues with Maemo telephony driver. Fix another device setup and temporary flag issue. Fix and update example agent implementation. ver 4.42: Add TI WL1271 to Texas Instruments chip list. Add special udev mode to bluetoothd. Fix regression when there is no agent registered. Fix error return when bonding socket hang up. Fix SCO server socket for HFP handsfree role. Fix shutdown on SCO socket before closing. Fix shutdown on A2DP audio stream channel before closing. Fix issue with asserting on AVDTP reference count bugs. Fix authorization denied issue with certain headsets. Fix AVRCP UNITINFO and SUBUNIT INFO responses. Fix discovery cancel issues in case SDP discovery fails. ver 4.41: Fix pairing even if the ACL gets dropped before successful SDP. Fix regression which caused device to be removed after pairing. Fix HSP record fetching when remote device doesn't support it. Fix SDP discovery canceling when clearing hs->pending. Fix headset never connecting on the first attempt. Fix headset state tracking if bt_search_service() fails. Fix maximum headset connection count check. Fix AVDTP Discover timeout handling. Fix also UI_SET_KEYBIT for the new pause and play key codes. ver 4.40: Add telephony driver for oFono telephony stack. Add support for Dell specific HID proxy switching. Add support for running hid2hci from udev. Add mapping for AVRCP Play and Pause to dedicated key codes. Fix AVRCP keycodes to better match existing X keymap support. Fix various quoting issues within telephony support. Fix memory allocation issue when generating PDUs for SDP. Fix race condition on device removal. Fix non-cancelable issue with CreateDevice method. Fix non-working CancelDiscovery method call."
OK, tried to bump in local overlay. Copied bluez-4.39-r2.ebuild to bluez-4.59.ebuild. Had to comment out: #epatch \ # "${FILESDIR}/4.31-as_needed.patch" \ # "${FILESDIR}/4.34-conditional_libsbc.patch" and #if use cups; then # epatch "${FILESDIR}/4.18/cups-location.patch" #fi to allow the compile. But now I get bit by bug #293349. *sigh*
I have another version of this ebuild in my overlay. I use bluetooth rather extensively with my Droid, so most functionality is tested. I am using blueman as my manager (new version also in my overlay), and I am able to use my laptop as a sink source for the Droid.
Created attachment 215212 [details] bluez 4.59 patch Bump to bluez 4.59. It also adds a udev useflag and remove the useless doc flag.
(In reply to comment #56) > The udev-postmount script contains the required startup code but somehow > bluetooth still doesn't start if the adapter is builtin or plugged in on boot. > I've used the udev-postmount script ad 'template' for a small script, which > runudevadm trigger --subsystem-match=bluetooth > and bluetooth is working correctly afterwards. > The same line can also be added to local(.start). > The > udevadm trigger --type=failed > line seems not to trigger the correct bluetooth activation (with udev-147, > udev-149 not yet tested), more details i didn't check for now. > if I put just 'udevadm trigger' without the --type=failed bluetoothd starts correctly. But I think that this is not the right fix for this bugs. I don't know too much about udev and it initscripts. The problem is on udev, I think. What do you think?
Created attachment 215868 [details] bluez 4.60 ebuild bluez 4.60 was released one hour ago. ver 4.60: Fix voice mailbox number reading from SIM. Fix some races with D-Bus mainloop integration. Add helpers for D-Bus signal watches.
BTW, I wanna help with the bluez ebuild and maybe other bluetooth ebuilds, but no one is helping me. We need to solve the udev trigger problem to release this ebuild ASAP. Release 4.39 is from May: commit 045ef6816f55aba855eefd39d5e86d7f0cac8f25 Author: Marcel Holtmann <marcel@holtmann.org> Date: Sat May 9 11:18:19 2009 -0700 Release 4.39 So, gentoo is very late. :(
Can you please summarize the udev related problem? Also, would be interesting to attach a diff between current in-tree ebuild and newer one :-) I have also read fedora's init script and they seem to refer to an udev bug for doing this changes: http://cvs.fedoraproject.org/viewvc/devel/bluez/bluetooth.init?r1=1.4&r2=1.5 * Wed Aug 05 2009 Bastien Nocera <bnocera@redhat.com> 4.47-2 - Remove hid2hci calls, they're in udev now - Work-around udev bug, bluetoothd wasn't getting enabled on coldplug Also opensuse is doing the same (running udevadm trigger --subsystem-match=bluetooth) in their init.d script for starting it, but, under gentoo, maybe it would need to get udev rules always installed (well, I would also need to investigate more on it, the problem is that now I don't have much time :-( )
What do you mean about the udev rules always being installed? The workaround has worked for me on two Gentoo machines.
+ if ! use udev ; then + newinitd "${FILESDIR}/4.18/bluetooth-init.d" bluetooth || die + newconfd "${FILESDIR}/4.18/bluetooth-conf.d" bluetooth || die + fi Umm, then, the idea would be to provide also an init script for udev (like opensuse, ubuntu, fedora do) for running "udevadm trigger --subsystem-match=bluetooth" at start and the same than the other init.d script (start-stop-daemon --stop --quiet --exec /usr/sbin/bluetoothd) in stop On ubuntu's init.d file I found an explanation about the problem: #currently this init script exists only because of what appears to be #an egg and chicken problem # bluetoothd normally starts up by udev rules. it needs dbus to function, # but dbus doesn't start up until after udev finishes triggering But I also add udev team to CC list for letting them know about this problem and give their opinion (since I don't know much about udev)
Would you really need to stop the bluetoothd started by udev? It isn't stopped when removing the last Bluetooth adapter but does this matter? For the startup trigger, udev-postmount seems like the right place to me. Even if you have no Bluetooth stuff installed, it'll just silently do nothing.
Created attachment 216255 [details, diff] bluez 4.60 ebuild I changed the ebuild and added an "udevadm trigger --subsystem-match=bluetooth" to the init script. You can get it here too: http://littlechina.org/code/cgit/padovan/padovan-overlay/
Thanks a lot for your work, only a few doubts: - epatch \ - "${FILESDIR}/4.31-as_needed.patch" \ Makefiles have changed a lot since then, then, that patch cannot be used, and people seem to have tested that it's no longer needed - "${FILESDIR}/4.34-conditional_libsbc.patch" In that patch I have read the following in its header: The configure stuff is a inconsequent: "- even if neither alsa nor gstreamer support is enabled, SBC_LIBS gets substituted by libsbc.la which doesn't get build without alsa or gstreamer. Making this conditional helps." Have you tried then that it's now working with some alsa/gstreamer combinations? "- ipctest needs both libipc.la and libsbc.la and fails if SBC_LIBS/SBC_CFLAGS are empty" I have also seen that seems that you are now removing .la files: + # don't install useless .la files + find "${D}" -type f -name '*.la' -delete || die "failed to remove .la files" Are you sure they are useless then? Also, what does occur after removing that .la files and running "revdep-rebuild" (*before* running "lafilefixer --justfixit") ? - # bug #84431 - insinto /etc/udev/rules.d/ - newins "${FILESDIR}/${PN}-4.18-udev.rules" 70-bluetooth.rules || die - newins "${S}/scripts/bluetooth.rules" 70-bluetooth-pcmcia.rules || die - - exeinto /$(get_libdir)/udev/ - newexe "${FILESDIR}/${PN}-4.18-udev.script" bluetooth.sh || die - doexe "${S}/scripts/bluetooth_serial" || die I guess bug #84431 is finally solved then, great :-) - udevadm control --reload_rules && udevadm trigger + udevadm control --reload-rules && udevadm trigger --subsystem-match=bluetooth Isn't "udevadm trigger" enough then for pkg_postinst() then? (I guess that, when installing the package, dbus is properly running and so...) Thanks a lot :-)
This is also probably old: + if use udev; then + elog "" + elog "You selected the udev USE flag. This make bluetoothd starts when a" + elog "bluetooth device is plugged in. Also the init scripts are not" + elog "installed when udev USE flag is selected." + fi since attached diff installs init scripts unconditionally and doesn't even list "udev" in "IUSE" ;-)
(In reply to comment #69) > Thanks a lot for your work, only a few doubts: > - epatch \ > - "${FILESDIR}/4.31-as_needed.patch" \ > > Makefiles have changed a lot since then, then, that patch cannot be used, and > people seem to have tested that it's no longer needed > > - "${FILESDIR}/4.34-conditional_libsbc.patch" > > In that patch I have read the following in its header: > The configure stuff is a inconsequent: > "- even if neither alsa nor gstreamer support is enabled, SBC_LIBS gets > substituted by libsbc.la > which doesn't get build without alsa or gstreamer. Making this conditional > helps." > > Have you tried then that it's now working with some alsa/gstreamer > combinations? > > "- ipctest needs both libipc.la and libsbc.la and fails if SBC_LIBS/SBC_CFLAGS > are empty" > > I have also seen that seems that you are now removing .la files: > + # don't install useless .la files > + find "${D}" -type f -name '*.la' -delete || die "failed to remove .la > files" > > Are you sure they are useless then? Also, what does occur after removing that > .la files and running "revdep-rebuild" (*before* running "lafilefixer > --justfixit") ? The patches were removed into comments #11 and #32. And revdep-rebuild reported nothing > > - udevadm control --reload_rules && udevadm trigger > + udevadm control --reload-rules && udevadm trigger > --subsystem-match=bluetooth > > Isn't "udevadm trigger" enough then for pkg_postinst() then? (I guess that, > when installing the package, dbus is properly running and so...) "udevadm trigger" triggers all devices, we just need trigger bluetooth subsystem.
> since attached diff installs init scripts unconditionally and doesn't even list > "udev" in "IUSE" ;-) > I'll send the patch for that later today.
Created attachment 216291 [details, diff] bluez 4.60 patch Removed the old udev comments.
(In reply to comment #73) > Created an attachment (id=216291) [details] > bluez 4.60 patch > > Removed the old udev comments. > just a small QA notice I got * QA Notice: USE Flag 'caps' not in IUSE for net-wireless/bluez-4.60
(In reply to comment #74) > just a small QA notice I got > > * QA Notice: USE Flag 'caps' not in IUSE for net-wireless/bluez-4.60 > It is not in net-wireless/bluez-4.39-r2 too. What is this USE flag for?
Excuse me if I'm not making any sense here, I have one hell of a hangover but... why would you add the udev trigger to the init script? The whole point of this udev stuff is getting rid of the init script and just starting bluetoothd when a device is inserted. Running it in the ebuild certainly isn't the way to go either. This isn't something you only need to run once.
(In reply to comment #76) > Excuse me if I'm not making any sense here, I have one hell of a hangover > but... why would you add the udev trigger to the init script? The whole point > of this udev stuff is getting rid of the init script and just starting > bluetoothd when a device is inserted. Running it in the ebuild certainly isn't > the way to go either. This isn't something you only need to run once. > Yes, but we have a bug. When the bluetooth device is built-in bluetoothd doesn't start. So we need to trigger it again on bluetooh init.d script. You can read more about that on the previous comments.
I've been following this all along. I've added the line to udev-postmount under the regular udevadm trigger line as was suggested above. This seems like the right place for it.
(In reply to comment #75) > (In reply to comment #74) > > just a small QA notice I got > > > > * QA Notice: USE Flag 'caps' not in IUSE for net-wireless/bluez-4.60 > > > > It is not in net-wireless/bluez-4.39-r2 too. What is this USE flag for? > I added caps support a long time ago, see comment #43. Your subsequent patches broke it. Do you actually read/test the ebuild patches you're attaching? Anyway, the QA notice means that the ebuild uses a flag which isn't declared in IUSE.
Created attachment 216446 [details, diff] bluez 4.60 patch I added the caps USE flag to IUSE. Ebuild tested and working. I've also changed to cups patch to use the file files/4.18/ dir, but I think we can't maintain that patch there because 4.39 also uses the same file. Btw, what do you think about removing the 4.18 dir and placing the files there in the files dir?
(In reply to comment #80) > I've also changed to cups patch to use the file files/4.18/ dir, but I think we > can't maintain that patch there because 4.39 also uses the same file. As new init.d daemon is only for upcoming bluez versions and not current versions in tree, new init.d should be under files/4.60 (for example), not the same because, otherwise, people would get the new init.d script with older bluez versions also
Created attachment 216560 [details] bluez 4.60 ebuild and patches I moved the files to a 4.60 dir. The ebuild is the same (except the s/4.18/4.60/ change). It's tarball with the ebuild and files. I thought this was the better way to send these files. You can get it here too: http://littlechina.org/code/cgit/padovan/padovan-overlay/
Great, thanks a lot, I will review and test them as soon as I have enough time (I am now too busy at real life) Regards
(In reply to comment #82) > Created an attachment (id=216560) [details] > bluez 4.60 ebuild and patches > > I moved the files to a 4.60 dir. The ebuild is the same (except the > s/4.18/4.60/ change). It's tarball with the ebuild and files. I thought this > was the better way to send these files. > > You can get it here too: > http://littlechina.org/code/cgit/padovan/padovan-overlay/ > Last time I checked, ebuilds are text files. You might want to have a look at the ebuild file in your tar archive.
Created attachment 216737 [details] bluez 4.60 ebuild Updated tarball. The other one had a problem.
Created attachment 216971 [details] bluez 4.60 ebuild Fix alsa-lib bug reported in bug #289578. I just applied the patch in that bug as you can se here: http://littlechina.org/code/cgit/padovan/padovan-overlay/ diff --git a/net-wireless/bluez/bluez-4.60.ebuild b/net-wireless/bluez/bluez-4.60.ebuild index ed1cf81..4a28f8a 100644 --- a/net-wireless/bluez/bluez-4.60.ebuild +++ b/net-wireless/bluez/bluez-4.60.ebuild @@ -15,7 +15,9 @@ KEYWORDS="~amd64 ~arm ~hppa ~ppc ~ppc64 ~x86" IUSE="alsa caps +consolekit cups debug gstreamer old-daemons pcmcia test-programs usb" -CDEPEND="alsa? ( media-libs/alsa-lib ) +CDEPEND="alsa? ( + media-libs/alsa-lib[alsa_pcm_plugins_extplug,alsa_pcm_plugins_ioplug] + ) caps? ( >=sys-libs/libcap-ng-0.6.2 ) gstreamer? ( >=media-libs/gstreamer-0.10 ps: Has anyone reviewed my last ebuild? I would like to see it in portage soon.
Closing this bug we close these bugs too: #269373 #283057 #289578 #292464
> ps: Has anyone reviewed my last ebuild? I would like to see it in portage soon. Agreed, or are we waiting for this bug to have a 1 year old birthday? If the package maintainer doesn't have any time, maybe he should hand it off to some other package maintainer? At the very least put it in there masked.
I have tried it but I manually need to start bluetooth (new) init.d file while, with current stable, init.d daemon is automatically started (as I have RC_COLDPLUG="yes" on my /etc/conf.d/rc) :-/
Umm, well, it probably is simply caused by the "udev" issue commented before
(In reply to comment #89) > I have tried it but I manually need to start bluetooth (new) init.d file while, > with current stable, init.d daemon is automatically started (as I have > RC_COLDPLUG="yes" on my /etc/conf.d/rc) :-/ > So, do we need to fix that? Or just use 'rc-update add bluetooth' is fine?
Would be nice to try to fix it (since it's a regression over current version), but I don't know where is the problem, also, I am really really busy until 11Feb or so, then, I won't be able to investigate the problem, then, any help on what is failing there is highly appreciated
(In reply to comment #69) > - # bug #84431 > - insinto /etc/udev/rules.d/ > - newins "${FILESDIR}/${PN}-4.18-udev.rules" 70-bluetooth.rules || die > - newins "${S}/scripts/bluetooth.rules" 70-bluetooth-pcmcia.rules || die > - > - exeinto /$(get_libdir)/udev/ > - newexe "${FILESDIR}/${PN}-4.18-udev.script" bluetooth.sh || die We probably still need this one, and I will have to check the rest also :-/ > - doexe "${S}/scripts/bluetooth_serial" || die > > I guess bug #84431 is finally solved then, great :-) > > - udevadm control --reload_rules && udevadm trigger > + udevadm control --reload-rules && udevadm trigger > --subsystem-match=bluetooth > > Isn't "udevadm trigger" enough then for pkg_postinst() then? (I guess that, > when installing the package, dbus is properly running and so...) > > Thanks a lot :-) >
(In reply to comment #93) > (In reply to comment #69) > > - exeinto /$(get_libdir)/udev/ > > - newexe "${FILESDIR}/${PN}-4.18-udev.script" bluetooth.sh || die > > We probably still need this one, and I will have to check the rest also :-/ I re-added this script, It's not working unless I add bluetooth to the default runlevel. :( Any other idea on how to fix that?
Just commited to the tree with some modifications (for example, I still let ebuild install .la files since, from time to time I see some threads on gentoo-dev mailing list with discussions about when is better to drop them or not, and, even if I, as a user, have no problem on running lafilefixer if needed, since this package is not maintained by me, I prefer to be conservative :-)) (In reply to comment #94) > (In reply to comment #93) > > (In reply to comment #69) > > > > - exeinto /$(get_libdir)/udev/ > > > - newexe "${FILESDIR}/${PN}-4.18-udev.script" bluetooth.sh || die > > > > We probably still need this one, and I will have to check the rest also :-/ > > I re-added this script, It's not working unless I add bluetooth to the default > runlevel. :( > Any other idea on how to fix that? > We simply needed to still install: exeinto /$(get_libdir)/udev/ newexe "${FILESDIR}/${PN}-4.18-udev.script" bluetooth.sh || die I really appreciate your work and the work done by all people here but, Padovan, next time, please, double check if you really can "drop" or "remove" things ;-) Best regards and thanks a lot :-)
Hi, I've experienced a problem with the RUN+=bluetooth.sh inside of /etc/udev/rules.d/70-bluetooth.rules of bluez-4.39 and bluez-4.61. /etc/init.d/bluetooth is in none of the runlevels as i understand that this should be called by the /lib64/udev/blue... I have CONFIG_DEVTMPFS=y and CONFIG_DEVTMPFS_MOUNT=y and the activation of this RUN line seams to smash the kernel. I see a events/ process consuming one processor and a system with very bad response times. Just tried to (1) call rfkill block bluetooth (thinkpad R61 where built-in usb bluetooth dissapears from the usb bus) then (2) reactivate the RUN line (still init.d/bluetooth stopped) and (3) call rfkill unblock bluetooth. This results in a working system. => RUN+=bluetooth.sh creates problems with DEVTMPFS Can somebody give me an advice? I'll remove the RUN, add bluetooth to runlevel default and start/stop the service as I spare battery power.
(In reply to comment #96) erm, sorry. the events/ process may be a problem with the crappy e1000e eth0 card.
(In reply to comment #97) Ok, what I can tell for sure is the fact, that the init.d/bluetooth service isn't started by the udev rule at bootup (device is built-in and active) with DEVTMPFS. I have to rfkill block bluetooth && rfkill unblock bluetooth to re-connect the usb device and trigger the udev-rules for init.d/bluetooth invocation. Is there a chance to debug this early bootup behavior?
