Bug#990501: connman: Connman disrupted network during upgrade on system where it does not manage network

2021-09-25 Thread Amy Kos
Hi,

in case you have plasma-nm installed, cmst (connman) shouldn't have been 
installed at all.

Lxqt metapackage recommends cmst (connman) or nm-tray (network-manager) or 
network-manager-gnome (network-manager) or plasma-nm (network-manager) or wicd 
(wicd-daemon).

In case you have network-manager without plasma-nm installed, avoid the lxqt 
metapackage, or add network-manager to its recommends.

Cheers,
Amy



Bug#990501: connman: Connman disrupted network during upgrade on system where it does not manage network

2021-06-30 Thread Jesse Rhodes
Package: connman
Version: 1.36-2.2
Severity: normal
X-Debbugs-Cc: je...@sney.ca

Dear Maintainer, 

This system has two desktop environments installed: KDE Plasma, which is used 
primarily; and LXQT, for backup. Network connections are managed by 
NetworkManager whenever I am using Plasma, which I was when I discovered this 
bug.

On upgrade to 1.36-2.2, connman triggered something to restart the network, the 
wifi connection dropped, and apt appeared to hang at: 

> Setting up connman (1.36-2.2) ...

I noticed after a few minutes, used my acpi hotkey to re-enable wifi, and the 
upgrade proceeded, with: 

> Job for connman-wait-online.service failed because the control process exited 
> with error code.
> See "systemctl status connman-wait-online.service" and "journalctl -xe" for 
> details.

The associated systemctl status output was: 

> Jun 30 14:34:25 debaser systemd[1]: Starting Wait for network to be 
> configured by ConnMan...
> Jun 30 14:36:26 debaser systemd[1]: connman-wait-online.service: Main process 
> exited, code=exited, status=110/n/a
> Jun 30 14:36:26 debaser systemd[1]: connman-wait-online.service: Failed with 
> result 'exit-code'.
> Jun 30 14:36:26 debaser systemd[1]: Failed to start Wait for network to be 
> configured by ConnMan.
 
It appears that connman was waiting for some kind of network-up condition, 
which would never arrive because connman was not managing the network. It 
should be able to detect a system where something else (n-m, ifupdown, etc) is 
being used, and proceed with the upgrade without trying to mess with it. 

Please let me know if you need any more information. 

Jesse (sney) 

-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-security')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages connman depends on:
ii  dbus  1.12.20-2
ii  iptables  1.8.7-1
ii  libc6 2.31-12
ii  libdbus-1-3   1.12.20-2
ii  libglib2.0-0  2.66.8-1
ii  libgnutls30   3.7.1-5
ii  libreadline8  8.1-1
ii  libxtables12  1.8.7-1
ii  lsb-base  11.1.0

Versions of packages connman recommends:
ii  bluez  5.55-3.1
ii  ofono  1.31-3
ii  wpasupplicant  2:2.9.0-21

Versions of packages connman suggests:
pn  connman-vpn  

-- no debconf information