[Dx-packages] [Bug 1787867] Re: Ubuntu 18.04 LTS bluetooth left discoverable

2020-05-20 Thread Rael Gugelmin Cunha 
Just checked in 20.04, with a connected Bluetooth device, and my system
is no more automatically discoverable. It's discoverable only when the
Bluetooth Settings panel is opened.

-- 
You received this bug notification because you are a member of DX
Packages, which is subscribed to indicator-bluetooth in Ubuntu.
https://bugs.launchpad.net/bugs/1787867

Title:
  Ubuntu 18.04 LTS bluetooth left discoverable

Status in indicator-bluetooth package in Ubuntu:
  Confirmed

Bug description:
  Ubuntu 18.04 LTS, when Bluetooth is on, the computer stays
  discoverable which opens up unnecessary vulnerability surface. There
  should be a separate UI switch for discoverability with auto timeout.
  Leaving bluetooth on (using a Bluetooth mouse) should not leave the
  computer always discoverable.

  Current behavior does not match documentation
  https://help.ubuntu.com/stable/ubuntu-help/bluetooth-
  visibility.html.en, even without Bluetooth panel open, the computer is
  still discoverable.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/indicator-bluetooth/+bug/1787867/+subscriptions

-- 
Mailing list: https://launchpad.net/~dx-packages
Post to : dx-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dx-packages
More help   : https://help.launchpad.net/ListHelp

[Dx-packages] [Bug 1787867] Re: Ubuntu 18.04 LTS bluetooth left discoverable

2020-05-20 Thread Kevin Senecal 
sudo hciconfig hci0 noscan will turn discovery off but leave bluetooth
on.  I added the line to the /etc/rc.local file so that it will start at
every reboot without the sudo.  So the line will read hciconfig hci0
noscan.  This is a temporary workaround until this is fixed.  This bug
persists in 20.04.

-- 
You received this bug notification because you are a member of DX
Packages, which is subscribed to indicator-bluetooth in Ubuntu.
https://bugs.launchpad.net/bugs/1787867

Title:
  Ubuntu 18.04 LTS bluetooth left discoverable

Status in indicator-bluetooth package in Ubuntu:
  Confirmed

Bug description:
  Ubuntu 18.04 LTS, when Bluetooth is on, the computer stays
  discoverable which opens up unnecessary vulnerability surface. There
  should be a separate UI switch for discoverability with auto timeout.
  Leaving bluetooth on (using a Bluetooth mouse) should not leave the
  computer always discoverable.

  Current behavior does not match documentation
  https://help.ubuntu.com/stable/ubuntu-help/bluetooth-
  visibility.html.en, even without Bluetooth panel open, the computer is
  still discoverable.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/indicator-bluetooth/+bug/1787867/+subscriptions

-- 
Mailing list: https://launchpad.net/~dx-packages
Post to : dx-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dx-packages
More help   : https://help.launchpad.net/ListHelp

[Dx-packages] [Bug 1871538] Re: dbus timeout-ed during an upgrade, taking services down including gdm

2020-05-20 Thread Christian Ehrhardt  
I hit that again today on an upgrade.
Network manager didn't come up again.

Mai 20 11:04:46 Keschdeichel systemd[1]: NetworkManager.service: Unexpected 
error response from GetNameOwner(): Connection terminated
Mai 20 11:04:46 Keschdeichel NetworkManager[1330]:   [1589965486.9491] 
caught SIGTERM, shutting down normally.
Mai 20 11:04:46 Keschdeichel NetworkManager[1330]:   [1589965486.9504] 
dhcp4 (enp0s31f6): canceled DHCP transaction
Mai 20 11:04:46 Keschdeichel NetworkManager[1330]:   [1589965486.9504] 
dhcp4 (enp0s31f6): state changed extended -> done
Mai 20 11:04:46 Keschdeichel NetworkManager[1330]:   [1589965486.9504] 
device (enp0s31f6): DHCPv4: trying to acquire a new lease within 90 seconds
Mai 20 11:04:46 Keschdeichel NetworkManager[1330]:   [1589965486.9733] 
dhcp4 (wlp4s0): canceled DHCP transaction
Mai 20 11:04:46 Keschdeichel NetworkManager[1330]:   [1589965486.9812] 
dhcp4 (wlp4s0): state changed bound -> done
Mai 20 11:04:46 Keschdeichel NetworkManager[1330]:   [1589965486.9813] 
device (wlp4s0): DHCPv4: trying to acquire a new lease within 90 seconds
Mai 20 11:04:46 Keschdeichel NetworkManager[1330]:   [1589965486.9817] 
device (p2p-dev-wlp4s0): state change: disconnected -> unmanaged (reason 
'unmanaged', sys-iface-state: 'managed')
Mai 20 11:04:46 Keschdeichel NetworkManager[1330]:   [1589965486.9825] 
device (strswanbr2-nic): released from master device strswanbr2
Mai 20 11:04:46 Keschdeichel NetworkManager[1330]:   [1589965486.9829] 
device (strswanbr1-nic): released from master device strswanbr1
Mai 20 11:04:46 Keschdeichel NetworkManager[1330]:   [1589965486.9831] 
device (veth47e5): released from master device lxdbr0
Mai 20 11:04:47 Keschdeichel NetworkManager[1330]:   [1589965487.0047] 
device (virbr0-nic): released from master device virbr0
Mai 20 11:04:47 Keschdeichel NetworkManager[1330]:   [1589965487.0050] 
device (vethcc7405c8): released from master device lxdbr0
Mai 20 11:04:47 Keschdeichel NetworkManager[1330]:   [1589965487.0069] 
device (vetha09a9db4): released from master device lxdbr0
Mai 20 11:04:47 Keschdeichel NetworkManager[1330]:   [1589965487.0077] 
device (veth754add92): released from master device lxdbr0
Mai 20 11:04:47 Keschdeichel NetworkManager[1330]:   [1589965487.0094] 
device (vethc060f004): released from master device virbr0
Mai 20 11:04:47 Keschdeichel NetworkManager[1330]:   [1589965487.0101] 
device (veth3152ecc9): released from master device lxdbr0
Mai 20 11:04:47 Keschdeichel NetworkManager[1330]:   [1589965487.0109] 
device (vethb6dd0569): released from master device lxdbr0
Mai 20 11:04:47 Keschdeichel NetworkManager[1330]:   [1589965487.1008] 
device (virbr0): bridge port vnet1 was detached
Mai 20 11:04:47 Keschdeichel NetworkManager[1330]:   [1589965487.1025] 
manager: NetworkManager state is now CONNECTED_SITE
Mai 20 11:04:47 Keschdeichel NetworkManager[1330]:   [1589965487.1030] 
device (virbr0): bridge port vnet0 was detached
Mai 20 11:04:47 Keschdeichel NetworkManager[1330]:   [1589965487.1629] 
exiting (success)
Mai 20 11:04:47 Keschdeichel systemd[1]: NetworkManager.service: Succeeded.
Mai 20 11:04:48 Keschdeichel nm-openvpn[847263]: SIGTERM[hard,] received, 
process exiting

$ systemctl status NetworkManager
● NetworkManager.service - Network Manager
 Loaded: loaded (/lib/systemd/system/NetworkManager.service; enabled; 
vendor preset: enabled)
 Active: inactive (dead) since Wed 2020-05-20 11:04:47 CEST; 15min ago
   Docs: man:NetworkManager(8)
   Main PID: 1330 (code=exited, status=0/SUCCESS)
  Tasks: 0 (limit: 38269)
 Memory: 12.2M
 CGroup: /system.slice/NetworkManager.service

But that still isn't the root cause.


And before this plenty of things failed on GetNameOwner() in that sense
it is similar to the former occurance.


Mai 20 11:03:56 Keschdeichel systemd[1]: Reloading.
Mai 20 11:03:56 Keschdeichel systemd[1]: /lib/systemd/system/dbus.socket:5: 
ListenStream= references a path below legacy directory /var/run/, updating 
/var/run/dbus/system_bus_socket → /run>
Mai 20 11:04:11 Keschdeichel tracker-store[976018]: OK
Mai 20 11:04:11 Keschdeichel systemd[18845]: tracker-store.service: Succeeded.
Mai 20 11:04:21 Keschdeichel systemd[1]: We couldn't coldplug 
machine-qemu\x2d13\x2dfocal.scope, proceeding anyway: Connection timed out
Mai 20 11:04:46 Keschdeichel systemd[1]: We couldn't coldplug 
machine-qemu\x2d11\x2dbionic.scope, proceeding anyway: Connection timed out
Mai 20 11:04:46 Keschdeichel systemd[1]: NetworkManager.service: Unexpected 
error response from GetNameOwner(): Connection terminated
Mai 20 11:04:46 Keschdeichel systemd[1]: wpa_supplicant.service: Unexpected 
error response from GetNameOwner(): Connection terminated
Mai 20 11:04:46 Keschdeichel systemd[1]: thermald.service: Unexpected error 
response from GetNameOwner(): Connection terminated
Mai 20 11:04:46 Keschdeichel systemd[1]: udisks2.service: Unexpected error 
response from GetNameOwner(): Connection terminated
Mai 20 11:04:46

[Dx-packages] [Bug 784055] Re: CPU usage increases dramatically (and visible stuttering) when running indicator-multiload

2020-05-20 Thread Daniel van Vugt 
** Summary changed:

- CPU usage increases dramatically when running indicator-multiload
+ CPU usage increases dramatically (and visible stuttering) when running 
indicator-multiload

** Tags added: focal

-- 
You received this bug notification because you are a member of DX
Packages, which is subscribed to libindicator in Ubuntu.
https://bugs.launchpad.net/bugs/784055

Title:
  CPU usage increases dramatically (and visible stuttering) when running
  indicator-multiload

Status in libindicator:
  Fix Committed
Status in The Ubuntu Power Consumption Project:
  Triaged
Status in gnome-shell package in Ubuntu:
  Confirmed
Status in gnome-shell-extension-appindicator package in Ubuntu:
  Confirmed
Status in indicator-multiload package in Ubuntu:
  Confirmed
Status in libindicator package in Ubuntu:
  Fix Released

Bug description:
  using 0.1-0~5~natty1 on mostly up to date natty system, when running
  the indicator-multiload with with just cpu monitor and the default
  update interval of 500 milliseconds, I see (via top) that compiz usage
  when generally idle goes from either 0 or 1% of CPU to 3 or 4% of CPU.
  Reducing the update interval does seem to have an affect.

  I realize that 
  a.) top is not scientific
  b.) there could be something I'm missing here
  c.) saying "300%" (in the subject) is not scientific

To manage notifications about this bug go to:
https://bugs.launchpad.net/libindicator/+bug/784055/+subscriptions

-- 
Mailing list: https://launchpad.net/~dx-packages
Post to : dx-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dx-packages
More help   : https://help.launchpad.net/ListHelp