Bug#806302: systemd does not start bluetooth.service if bluetooth soft rfkilled in the previous boot
On 11/26/2015 04:01 PM, Michael Biebl wrote: > Am 26.11.2015 um 09:53 schrieb Mattia Belluco: >> Package: systemd >> Version: 228-2 >> Arch:amd64 >> >> If bluetooth is disabled by soft rfkill (blueman applet) the status >> survives reboot and systemd no longer loads bluetoothd (which in turn >> prevent blueman from loading) because: >> >> ● bluetooth.service - Bluetooth service >>Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; >> vendor preset: enabled) >>Active: inactive (dead) >> Condition: start condition failed at Thu 2015-11-26 09:33:14 CET; 49s ago >>ConditionPathIsDirectory=/sys/class/bluetooth was not met >> Docs: man:bluetoothd(8) >> >> from my understanding /sys/class/bluetooth appears only if rfkill is >> disabled and in fact if I issue: >> >> rfkill unblock tpacpi_bluetooth_sw >> >> the relevant directory appears and I can manually start the deamon with >> >> systemctl start bluetooth.service > > I'm confused, why is this a bug in particular (you disabled bluetooth) > and systemd specifically (bluetooth.service is not shipped by systemd)? > > You ought to be. For some reasons I was convinced the bug originated from a systemd upgrade but that seems not to be the case. Thanks for your quick reply anyway. Mattia
Bug#806302: systemd does not start bluetooth.service if bluetooth soft rfkilled in the previous boot
On 12/02/2015 09:53 PM, Michael Biebl wrote: > Am 02.12.2015 um 20:30 schrieb Mattia Belluco: >> On 11/26/2015 04:01 PM, Michael Biebl wrote: >>> Am 26.11.2015 um 09:53 schrieb Mattia Belluco: >>> I'm confused, why is this a bug in particular (you disabled bluetooth) >>> and systemd specifically (bluetooth.service is not shipped by systemd)? > >> You ought to be. For some reasons I was convinced the bug originated >> from a systemd upgrade but that seems not to be the case. > > So I guess we can close this bug report then? > > Michael > sure Mattia
Bug#806302: systemd does not start bluetooth.service if bluetooth soft rfkilled in the previous boot
Package: systemd Version: 228-2 Arch: amd64 If bluetooth is disabled by soft rfkill (blueman applet) the status survives reboot and systemd no longer loads bluetoothd (which in turn prevent blueman from loading) because: ● bluetooth.service - Bluetooth service Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor preset: enabled) Active: inactive (dead) Condition: start condition failed at Thu 2015-11-26 09:33:14 CET; 49s ago ConditionPathIsDirectory=/sys/class/bluetooth was not met Docs: man:bluetoothd(8) from my understanding /sys/class/bluetooth appears only if rfkill is disabled and in fact if I issue: rfkill unblock tpacpi_bluetooth_sw the relevant directory appears and I can manually start the deamon with systemctl start bluetooth.service regards Mattia Belluco
Bug#711757: [PATCH] Wired connection, static IP profile: immediately disconnects
Package: wicd Version: 1.7.2.4-4.1 Severity: normal Apparently the wired connection process is too fast in setting the ip address and issuing an update_connection_status() . When using a static ip the function CheckPluggedIn() in wicd_daemon.py initially returns a 0 even if the cable is connected and the ip properly set: I believe that is due to some kind of delay having put the interface down and then up before connecting and the extra time dhcp takes to get/set an address could explain why the issue is not present when not using static IPs. As a patch/workaround I added a time.sleep(1) at the beginning of check_for_wired_connection() and now everything works like a charm if you don't mind the extra second delay, of course. Here is the update_connection_status() in monitor.py: def check_for_wired_connection(self, wired_ip): Checks for a wired connection. Checks for two states: 1) A wired connection is not in use, but a cable is plugged in, and the user has chosen to switch to a wired connection whenever its available, even if already connected to a wireless network. 2) A wired connection is currently active. time.sleep(1) self.trigger_reconnect = False if not wired_ip and daemon.GetPreferWiredNetwork(): if not daemon.GetForcedDisconnect() and wired.CheckPluggedIn(): self.trigger_reconnect = True elif wired_ip and wired.CheckPluggedIn(): # Only change the interface if it's not already set for wired if not self.still_wired: daemon.SetCurrentInterface(daemon.GetWiredInterface()) self.still_wired = True return True # Wired connection isn't active elif wired_ip and self.still_wired: # If we still have an IP, but no cable is plugged in # we should disconnect to clear it. wired.DisconnectWired() self.still_wired = False return False The issue is here: elif wired_ip and wired.CheckPluggedIn() -- it is not verified because of wired.CheckPluggedIn() returning 0 before settling to 1. Mattia Belluco -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756039: [Pkg-acpi-devel] Bug#756039: acpi-support no longer has lockbtn support nor touchpad disable cap.
On 08/05/2014 12:17 PM, Michael Meskes wrote: On Fri, Jul 25, 2014 at 06:26:38PM +0200, Mattia Belluco wrote: With the lastest version I can no longer disable the integrated touch pad on a dual tracking system such as Lenovo x220 nor lock the screen with the screenlock button: apparently both scripts have been removed as obsolete but I can't see any new alternative way to achieve the same results. Upstream apparently thinks both are handled by the desktop environment now. Please tell me which scripts and events you need and I'll re-add them. Michael Please help me understand: I run testing(i386) on a laptop that doesn't have the scripts anymore and unstable(amd64) on another laptop that appears untouched by the last upgrade. What's the standard situation I should find myself in? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743569: [Pkg-bluetooth-maintainers] Bug#743569: audio.conf with pulseaudio
Hi, I'm sorry for the late reply but I was on vacation. I upgraded my debian unstable system today and everything seems to work fine with bluez5 and pulseaudio. (blueman-applet spits out an error but in the end everything works) Thanks Mattia On 07/29/2014 01:05 AM, Nobuhiro Iwamatsu wrote: Hi, I installed bluez5 into unstable. current pulseaudio needs bluez5. Could you check with bluze5? NOTE: I confirmed that pulseaudio worked with bluez5. Best regards, Nobuhiro 2014-04-04 5:10 GMT+09:00 Mattia Belluco dewa...@ninthfloor.org: Package: bluez Version: 4.101-4.1 Arch: amd64 To make thing easier to use pulseaudio with bluez there should be more comments on the config. Specifically I suggest to change: # SCO routing. Either PCM or HCI (in which case audio is routed to/from ALSA) # Defaults to HCI To something : # SCO routing. Either PCM or HCI: # PCM if you plan to use pulseaudio-bluetooth # HCI to route audio to/from ALSA # Defaults to HCI and I would had to: # If we want to disable support for specific services # Defaults to supporting all implemented services the following: # It is generally a bad idea to enable socket if you want to use the device as a sink for pulseaudio (it will pair but it will not work) It took me loads of time to figure those out. Mattia ___ Pkg-bluetooth-maintainers mailing list pkg-bluetooth-maintain...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-bluetooth-maintainers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756039: acpi-support no longer has lockbtn support nor touchpad disable cap.
Package: acpi-support Version: 0.142-2 Arch: i386 With the lastest version I can no longer disable the integrated touch pad on a dual tracking system such as Lenovo x220 nor lock the screen with the screenlock button: apparently both scripts have been removed as obsolete but I can't see any new alternative way to achieve the same results. Mattia Belluco -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754973: [Pkg-bluetooth-maintainers] Bug#754973: bluez 5.21-1 breaks blueman 1.23-git20140626133
The strange thing is that it did work on bluez5 until the last minor version update. Mattia On July 17, 2014 3:55:28 AM GMT+02:00, Nobuhiro Iwamatsu iwama...@nigauri.org wrote: reassign 754973 blueman thanks Hi, Yes, blueman does not work with bluez5. This is because of a change in the API of Bluez, blueman does not have to follow this in Debian. maintainer of blueman is working about this. I reassign this BTS to blueman. Best regards, Nobuhiro 2014-07-16 22:16 GMT+09:00 Mattia Belluco dewa...@ninthfloor.org: package: bluez version: 5.21-1 arch:amd64 As of last update I can no longer use blueman as it reports a number of errors like the following and basically it doesn't see the bt adapter. Run (/usr/lib/python2.7/dist-packages/blueman/main/PluginManager.py:202) Function on_manager_state_changed on AuthAgent Failed Traceback (most recent call last): File /usr/lib/python2.7/dist-packages/blueman/main/PluginManager.py, line 206, in Run ret = getattr(inst, function)(*args, **kwargs) File /usr/lib/python2.7/dist-packages/blueman/plugins/applet/AuthAgent.py, line 32, in on_manager_state_changed adapters = self.Applet.Manager.ListAdapters() File /usr/lib/python2.7/dist-packages/blueman/bluez/utils.py, line 28, in warp raise errors.parse_dbus_error(exception) DBusException: org.freedesktop.DBus.Error.UnknownMethod: Method ListAdapters with signature on interface org.bluez.Manager doesn't exist I downgraded bluez to jessie's version and everything started to work again. Mattia Belluco ___ Pkg-bluetooth-maintainers mailing list pkg-bluetooth-maintain...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-bluetooth-maintainers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754973: bluez 5.21-1 breaks blueman 1.23-git20140626133
package: bluez version: 5.21-1 arch:amd64 As of last update I can no longer use blueman as it reports a number of errors like the following and basically it doesn't see the bt adapter. Run (/usr/lib/python2.7/dist-packages/blueman/main/PluginManager.py:202) Function on_manager_state_changed on AuthAgent Failed Traceback (most recent call last): File /usr/lib/python2.7/dist-packages/blueman/main/PluginManager.py, line 206, in Run ret = getattr(inst, function)(*args, **kwargs) File /usr/lib/python2.7/dist-packages/blueman/plugins/applet/AuthAgent.py, line 32, in on_manager_state_changed adapters = self.Applet.Manager.ListAdapters() File /usr/lib/python2.7/dist-packages/blueman/bluez/utils.py, line 28, in warp raise errors.parse_dbus_error(exception) DBusException: org.freedesktop.DBus.Error.UnknownMethod: Method ListAdapters with signature on interface org.bluez.Manager doesn't exist I downgraded bluez to jessie's version and everything started to work again. Mattia Belluco -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725610: pulseaudio-module-bluetooth: Unable to set bluetooth headset on A2DP mode
Hi all, I feel like this bug is related to these two I reported: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743568 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743569 More specifically to make a bluetooth headset work in A2DP mode I had to change settings in audio.conf: SCORouting=PCM and keep sure Socket stay disabled. Once you've done that you would still get a Stream setup failed error unless you manually load module-bluetooth-discover with: $ pactl load-module module-bluetooth-discover If the module was not loaded you'll get a number as exit code and that being the case your next connection attempt should succeed. I hope that helps. Mattia -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743568: module-bluetooth-discover.so has to be manually loaded for bt audio
Package: pulseaudio-module-bluetooth Version: 4.0-6+b1 Arch: amd64 After much tinkering I found out one of the reasons my bluetooth audio devs (A2DP and not) were not pairing was due to the module: module-bluetooth-discover.so. I use pulseaudio per-user and my default.pa reads: ### Automatically load driver modules for Bluetooth hardware .ifexists module-bluetooth-policy.so load-module module-bluetooth-policy .endif .ifexists module-bluetooth-discover.so load-module module-bluetooth-discover .endif nonetheless the second if doesn't work but the module can be loaded manually via $ pactl load-module module-bluetooth-discover and once done that everything works (although sometimes connection between devices disappear or pulseaudio crashes). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#743569: audio.conf with pulseaudio
Package: bluez Version: 4.101-4.1 Arch: amd64 To make thing easier to use pulseaudio with bluez there should be more comments on the config. Specifically I suggest to change: # SCO routing. Either PCM or HCI (in which case audio is routed to/from ALSA) # Defaults to HCI To something : # SCO routing. Either PCM or HCI: # PCM if you plan to use pulseaudio-bluetooth # HCI to route audio to/from ALSA # Defaults to HCI and I would had to: # If we want to disable support for specific services # Defaults to supporting all implemented services the following: # It is generally a bad idea to enable socket if you want to use the device as a sink for pulseaudio (it will pair but it will not work) It took me loads of time to figure those out. Mattia -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
