from:"lukas"

Actually, this seems to be an issue of the source package not being
pulled from -proposed, as I can install the binaries just fine in a LXD
container:

root@nn:~# dpkg --add-architecture i386
root@nn:~# apt update
[...]
root@nn:~# apt install libvpx9:i386
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
  libnsl-dev libtirpc-dev
Use 'apt autoremove' to remove them.
The following additional packages will be installed:
  gcc-14-base:i386 libc-bin libc-dev-bin libc-devtools libc6 libc6:i386 
libc6-dev libgcc-s1:i386 libidn2-0:i386
  libunistring5:i386 locales
Suggested packages:
  glibc-doc glibc-doc:i386 locales:i386 libnss-nis:i386 libnss-nisplus:i386
The following NEW packages will be installed:
  gcc-14-base:i386 libc6:i386 libgcc-s1:i386 libidn2-0:i386 libunistring5:i386 
libvpx9:i386
The following packages will be upgraded:
  libc-bin libc-dev-bin libc-devtools libc6 libc6-dev locales
6 upgraded, 6 newly installed, 0 to remove and 7 not upgraded.
Need to get 15.3 MB of archives.
After this operation, 18.6 MB of additional disk space will be used.
Do you want to continue? [Y/n] 
[...]
Get:12 http://archive.ubuntu.com/ubuntu noble-proposed/main i386 libvpx9 i386 
1.14.0-1ubuntu1 [1129 kB]


0


root@nn:~# apt-get source libvpx
Reading package lists... Done
NOTICE: 'libvpx' packaging is maintained in the 'Git' version control system at:
https://salsa.debian.org/multimedia-team/libvpx.git
Please use:
git clone https://salsa.debian.org/multimedia-team/libvpx.git
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 4332 kB of source archives.
Get:1 http://archive.ubuntu.com/ubuntu noble/main libvpx 1.13.1-2ubuntu1 (dsc) 
[2366 B]
Get:2 http://archive.ubuntu.com/ubuntu noble/main libvpx 1.13.1-2ubuntu1 (tar) 
[4316 kB]
Get:3 http://archive.ubuntu.com/ubuntu noble/main libvpx 1.13.1-2ubuntu1 (diff) 
[13.6 kB]
Fetched 4332 kB in 1s (8427 kB/s)
dpkg-source: info: extracting libvpx in libvpx-1.13.1
dpkg-source: info: unpacking libvpx_1.13.1.orig.tar.xz
dpkg-source: info: unpacking libvpx_1.13.1-2ubuntu1.debian.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying 0001-Relax-ABI-check.patch
dpkg-source: info: applying 0002-Do-not-undefine-_FORTIFY_SOURCE.patch

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

Title:
  Missing in i386 Packages index

Status in libvpx package in Ubuntu:
  New

Bug description:
  The new version of libvpx 1.14 seems not to be published to
  http://ftpmaster.internal on i386 only.

  This leads to the autopkgtest trigger "libvpx/1.14.0-1ubuntu1", not having 
any effect on i386:
  https://autopkgtest.ubuntu.com/packages/libvpx/noble/i386

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvpx/+bug/2058930/+subscriptions


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

[Desktop-packages] [Bug 2058930] Re: Missing in i386 Packages index

** Description changed:

- The new version of libvpx 1.14 seems to be missing in
- http://archive.ubuntu.com/ubuntu/dists/noble-
- proposed/main/binary-i386/Packages.xz, while it's still available in
- http://archive.ubuntu.com/ubuntu/dists/noble-
- proposed/main/binary-i386/Packages.gz.
- 
- Grep for "Source: libvpx".
+ The new version of libvpx 1.14 seems not to be published to
+ http://ftpmaster.internal on i386 only.
  
  This leads to the autopkgtest trigger "libvpx/1.14.0-1ubuntu1", not having 
any effect on i386:
  https://autopkgtest.ubuntu.com/packages/libvpx/noble/i386

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

Title:
  Missing in i386 Packages index

Status in libvpx package in Ubuntu:
  New

Bug description:
  The new version of libvpx 1.14 seems not to be published to
  http://ftpmaster.internal on i386 only.

  This leads to the autopkgtest trigger "libvpx/1.14.0-1ubuntu1", not having 
any effect on i386:
  https://autopkgtest.ubuntu.com/packages/libvpx/noble/i386

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvpx/+bug/2058930/+subscriptions


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

[Desktop-packages] [Bug 2058930] [NEW] Missing in i386 Packages index

Public bug reported:

The new version of libvpx 1.14 seems not to be published to
http://ftpmaster.internal on i386 only.

This leads to the autopkgtest trigger "libvpx/1.14.0-1ubuntu1", not having any 
effect on i386:
https://autopkgtest.ubuntu.com/packages/libvpx/noble/i386

** Affects: libvpx (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: rls-nn-incoming update-excuse

** Tags added: rls-nn-incoming

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

Title:
  Missing in i386 Packages index

Status in libvpx package in Ubuntu:
  New

Bug description:
  The new version of libvpx 1.14 seems not to be published to
  http://ftpmaster.internal on i386 only.

  This leads to the autopkgtest trigger "libvpx/1.14.0-1ubuntu1", not having 
any effect on i386:
  https://autopkgtest.ubuntu.com/packages/libvpx/noble/i386

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libvpx/+bug/2058930/+subscriptions


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

[Desktop-packages] [Bug 2055148] Re: NetworkManager connections with an explicit DoT (DNS over TLS) are not supported with Netplan

** Tags added: fr-7190

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2055148

Title:
  NetworkManager connections with an explicit DoT (DNS over TLS) are not
  supported with Netplan

Status in Netplan:
  Triaged
Status in netplan.io package in Ubuntu:
  Confirmed
Status in network-manager package in Ubuntu:
  Confirmed

Bug description:
  From: https://discourse.ubuntu.com/t/blog-netplan-developer-
  diaries/35932/11

  Hi all,

  NetworkManager connections with an explicit DoT (DNS over TLS)
  configuration are not supported with Netplan, but NetworkManager does
  feed back the DoT DNS info with server address and Server Name
  Indication (SNI) in the form server_address#SNI, e.g.
  1.2.3.4#dns.myhome.com as nameserver addresses to Netplan. As a
  result, subsequent Netplan config applications fail because DNS
  servers don’t have the expected dotted decimal (IPv4) or colon’ed hex
  (IPv6) form.

  ```
  nmcli> describe ipv4.dns

  === [dns] ===
  [NM property description]
  Array of IP addresses of DNS servers. For DoT (DNS over TLS), the SNI server 
name can be specified by appending "#example.com" to the IP address of the DNS 
server. This currently only has effect when using systemd-resolved.
  ```

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


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

[Desktop-packages] [Bug 2055148] Re: NetworkManager connections with an explicit DoT (DNS over TLS) are not supported with Netplan

2024-03-18 Thread Lukas Märdian

We should land a fix keeping the full string in
networkmanager.passthrough and additionaly work on a proper upstream
solution, as suggested by Danilo in comment #4, introducing new settings
as a longer term solution.

** Changed in: netplan
   Status: New => Triaged

** Changed in: netplan
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2055148

Title:
  NetworkManager connections with an explicit DoT (DNS over TLS) are not
  supported with Netplan

Status in netplan:
  Triaged
Status in netplan.io package in Ubuntu:
  Confirmed
Status in network-manager package in Ubuntu:
  Confirmed

Bug description:
  From: https://discourse.ubuntu.com/t/blog-netplan-developer-
  diaries/35932/11

  Hi all,

  NetworkManager connections with an explicit DoT (DNS over TLS)
  configuration are not supported with Netplan, but NetworkManager does
  feed back the DoT DNS info with server address and Server Name
  Indication (SNI) in the form server_address#SNI, e.g.
  1.2.3.4#dns.myhome.com as nameserver addresses to Netplan. As a
  result, subsequent Netplan config applications fail because DNS
  servers don’t have the expected dotted decimal (IPv4) or colon’ed hex
  (IPv6) form.

  ```
  nmcli> describe ipv4.dns

  === [dns] ===
  [NM property description]
  Array of IP addresses of DNS servers. For DoT (DNS over TLS), the SNI server 
name can be specified by appending "#example.com" to the IP address of the DNS 
server. This currently only has effect when using systemd-resolved.
  ```

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


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

[Desktop-packages] [Bug 2045096] Re: Error in network definition: Invalid MAC address 'random'

2024-03-18 Thread Lukas Märdian

This will be part of 1.0-1

** Changed in: netplan.io (Ubuntu)
   Status: New => Fix Committed

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2045096

Title:
  Error in network definition: Invalid MAC address 'random'

Status in netplan:
  Fix Committed
Status in netplan.io package in Ubuntu:
  Fix Committed
Status in network-manager package in Ubuntu:
  New

Bug description:
  netplan dose not understand the 'random' key word in 'Cloned MAC address' set 
by networkmanager.
  ```
  /etc/netplan/90-NM-X.yaml:9:19: Error in network definition: Invalid MAC 
address 'random', must be XX:XX:XX:XX:XX:XX or 
XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
macaddress: "random"
^
  ```

  netplan Version 0.107-5ubuntu2
  network-manager Version 1.44.2-1ubuntu2

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


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

[Desktop-packages] [Bug 2058231] [NEW] Fallback to IPv4-LL when DHCP is failing

2024-03-18 Thread Lukas Märdian

Public bug reported:

The intention of the previous avahi-autoipd integration was that on a
connection that does have dhcp configured, it will fall back to IPV4LL
if dhcp is unavailable.

This integration was recently dropped (and I think it never worked as intended 
in the first place):
https://code.launchpad.net/~vorlon/ubuntu-seeds/+git/ubuntu/+merge/460785

We want to implement this functionality in Ubuntu/NetworkManager and there's 
some upstream work tracking this too:
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/966

See FR-4142

** Affects: network-manager (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2058231

Title:
  Fallback to IPv4-LL when DHCP is failing

Status in network-manager package in Ubuntu:
  New

Bug description:
  The intention of the previous avahi-autoipd integration was that on a
  connection that does have dhcp configured, it will fall back to IPV4LL
  if dhcp is unavailable.

  This integration was recently dropped (and I think it never worked as 
intended in the first place):
  https://code.launchpad.net/~vorlon/ubuntu-seeds/+git/ubuntu/+merge/460785

  We want to implement this functionality in Ubuntu/NetworkManager and there's 
some upstream work tracking this too:
  https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/966

  See FR-4142

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/2058231/+subscriptions


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

[Desktop-packages] [Bug 2051895] Re: Lenovo XT99 BT headset can't work in HFP profile

2024-03-12 Thread Lukas Märdian

I confirmed the patch matches the upstream changes and builds find. I
see the bug description ([Test] section) was updated to mention pairing
of 7 audio and 2 non-audio devices. That pairing test needs to be re-run
with the final binaries, once they are build in the archive, as per the
usual SRU process.

Sponsoring for Mantic & Jammy, unsubscribing sponsors. The status is
already set to "In Progress".

https://launchpad.net/ubuntu/mantic/+queue?queue_state=1_text=pulseaudio
https://launchpad.net/ubuntu/jammy/+queue?queue_state=1_text=pulseaudio

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

Title:
  Lenovo XT99 BT headset can't work in HFP profile

Status in HWE Next:
  New
Status in pulseaudio package in Ubuntu:
  Fix Committed
Status in pulseaudio source package in Jammy:
  In Progress
Status in pulseaudio source package in Mantic:
  In Progress
Status in pulseaudio source package in Noble:
  Fix Committed

Bug description:
  [Summary]
  When use the ThinkPluse xt99 bluetooth head set to run the test 
com.canonical.certification::bluetooth/audio_record_playback, it cannot record 
the sound and playback.
  It seems this device cannot switch to Hand free mode in this platform.

  [Steps to reproduce]
  Connect the ThinkPluse xt99, use the Handfree mode, then try to record some 
voice.

  [Expected result]
  The bluetooth headset ThinkPluse xt99 can use as a MIC to input sound.

  [Actual result]
  The bluetooth headset xt99 cannot work in the Handfree mode.

  [Failure rate]
  100%

  [Impact]
  With the current Ubuntu 22.04 oem image, we try to connect the LENOVO
  XT99 bt headset and let it work in HFP mode, we select HFP profile
  from gnome sound-setting, but the microphone will not auto change to
  bt microphone and the bt output could not work too. So this BT headset
  could only work in A2DP mode with the current 22.04 OEM image.

  And we tried ubuntu 22.04 generic image, mantic image and noble image,
  none of them could make the headset work in HFP mode.

  [Fix]
  Cherry-pick a pulseaudio commit from upstream.

  [Test]
  I installed ubuntu 22.04 and 23.10 on 2 different Thinkpad laptops, then 
upgraded the pulseaudio from my ppa (ppa:hui.wang/pa-testing), in theory my 
change only affects bluetooth audio devices, it will not bring any impact to 
non-audio bluetooth devices, here I did the test with 7 bluetooth audio devices 
and 2 non-audio devices:

  BT audio devices (pairing, connection, re-connection, playback and capture 
all worked well):
  PLT_BBTGO2 (headset)
  Xiaomi Air3 SE (headset)
  Crusher Wireless (headset)
  SOAIY S18 (sound box)
  HK Soho Wireless (headset)
  Thinkplus XT99 (headset)
  Wl-1000X (headset)

  BT non-audio devices (pairing, connection, re-connection, key input all 
worked well):
  BT3.0 Keyboard
  The Pinao 2 keyboard

  
  [Where problems could occur]
  This change will impact bt headset negotiation process in the pulseaudio,
  so the possiblity of regression is limited to bt headset, it could make
  the bt headset fail to connect, but this possibility is very low, we tested
  the patch with different bt headset and bt speaker, all worked well.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/2051895/+subscriptions


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

[Desktop-packages] [Bug 2048388] Re: Test suite often fails with "systemd units changed without reload" on s390x

2024-02-28 Thread Lukas Märdian

This patch seems to resolve the situation locally.

For now I'll only go with the changes to tests/integration/base.py,
though. As that should be enough to avoid test failures, while the
service units shouldn't change (besides being re-generated 1:1).

I want to better understand what's going on exactly and why the units
are re-generated multiple times, before applying changes to
netplan_cli/cli/commands/apply.py

** Patch added: 
"0001-tests-integration-Be-less-strict-about-systemctl-dae.patch"
   
https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/2048388/+attachment/5750250/+files/0001-tests-integration-Be-less-strict-about-systemctl-dae.patch

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

Title:
  Test suite often fails with "systemd units changed without reload" on
  s390x

Status in netplan:
  Invalid
Status in netplan.io package in Ubuntu:
  Triaged
Status in wpa package in Ubuntu:
  New

Bug description:
  The "ethernets" autopkgtest for netplan.io 0.107-5ubuntu2 on s390x
  often fails with

  AssertionError: systemd units changed without reload

  Looking at the history of autopkgtest runs, it looks like that the
  error does not always occur during execution of a specific test. I've
  seen occurrences of this error during the following test-cases:

  test_dhcp6 (__main__.TestNetworkd.test_dhcp6) ... FAIL
  test_link_local_ipv4 (__main__.TestNetworkd.test_link_local_ipv4) ... FAIL
  test_eth_mtu (__main__.TestNetworkd.test_eth_mtu) ... FAIL

  Example [1]:

  781s FAIL: test_dhcp6 (__main__.TestNetworkd.test_dhcp6)
  781s --
  781s Traceback (most recent call last):
  781s   File 
"/tmp/autopkgtest.G0qQU0/build.Snp/src/tests/integration/ethernets.py", line 
189, in test_dhcp6
  781s self.generate_and_settle([self.state_dhcp6(self.dev_e_client)])
  781s   File 
"/tmp/autopkgtest.G0qQU0/build.Snp/src/tests/integration/base.py", line 342, in 
generate_and_settle
  781s self.fail('systemd units changed without reload')
  781s AssertionError: systemd units changed without reload

  [1] https://autopkgtest.ubuntu.com/results/autopkgtest-
  noble/noble/s390x/n/netplan.io/20240105_144627_cb35e@/log.gz

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


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

[Desktop-packages] [Bug 2048388] Re: Test suite often fails with "systemd units changed without reload" on s390x

2024-02-28 Thread Lukas Märdian

This is related:
https://github.com/canonical/netplan/commit/da6f776dd7e33050124fe2990b715db92c1ddee3

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

Title:
  Test suite often fails with "systemd units changed without reload" on
  s390x

Status in netplan:
  Invalid
Status in netplan.io package in Ubuntu:
  Triaged
Status in wpa package in Ubuntu:
  New

Bug description:
  The "ethernets" autopkgtest for netplan.io 0.107-5ubuntu2 on s390x
  often fails with

  AssertionError: systemd units changed without reload

  Looking at the history of autopkgtest runs, it looks like that the
  error does not always occur during execution of a specific test. I've
  seen occurrences of this error during the following test-cases:

  test_dhcp6 (__main__.TestNetworkd.test_dhcp6) ... FAIL
  test_link_local_ipv4 (__main__.TestNetworkd.test_link_local_ipv4) ... FAIL
  test_eth_mtu (__main__.TestNetworkd.test_eth_mtu) ... FAIL

  Example [1]:

  781s FAIL: test_dhcp6 (__main__.TestNetworkd.test_dhcp6)
  781s --
  781s Traceback (most recent call last):
  781s   File 
"/tmp/autopkgtest.G0qQU0/build.Snp/src/tests/integration/ethernets.py", line 
189, in test_dhcp6
  781s self.generate_and_settle([self.state_dhcp6(self.dev_e_client)])
  781s   File 
"/tmp/autopkgtest.G0qQU0/build.Snp/src/tests/integration/base.py", line 342, in 
generate_and_settle
  781s self.fail('systemd units changed without reload')
  781s AssertionError: systemd units changed without reload

  [1] https://autopkgtest.ubuntu.com/results/autopkgtest-
  noble/noble/s390x/n/netplan.io/20240105_144627_cb35e@/log.gz

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


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

[Desktop-packages] [Bug 2055148] [NEW] NetworkManager connections with an explicit DoT (DNS over TLS) are not supported with Netplan

2024-02-27 Thread Lukas Märdian

Public bug reported:

From: https://discourse.ubuntu.com/t/blog-netplan-developer-
diaries/35932/11

Hi all,

NetworkManager connections with an explicit DoT (DNS over TLS)
configuration are not supported with Netplan, but NetworkManager does
feed back the DoT DNS info with server address and Server Name
Indication (SNI) in the form server_address#SNI, e.g.
1.2.3.4#dns.myhome.com as nameserver addresses to Netplan. As a result,
subsequent Netplan config applications fail because DNS servers don’t
have the expected dotted decimal (IPv4) or colon’ed hex (IPv6) form.

```
nmcli> describe ipv4.dns

=== [dns] ===
[NM property description]
Array of IP addresses of DNS servers. For DoT (DNS over TLS), the SNI server 
name can be specified by appending "#example.com" to the IP address of the DNS 
server. This currently only has effect when using systemd-resolved.
```

** Affects: netplan
 Importance: Undecided
 Status: New

** Affects: netplan.io (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: network-manager (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: netplan-everywhere

** Also affects: netplan
   Importance: Undecided
   Status: New

** Also affects: network-manager (Ubuntu)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2055148

Title:
  NetworkManager connections with an explicit DoT (DNS over TLS) are not
  supported with Netplan

Status in netplan:
  New
Status in netplan.io package in Ubuntu:
  New
Status in network-manager package in Ubuntu:
  New

Bug description:
  From: https://discourse.ubuntu.com/t/blog-netplan-developer-
  diaries/35932/11

  Hi all,

  NetworkManager connections with an explicit DoT (DNS over TLS)
  configuration are not supported with Netplan, but NetworkManager does
  feed back the DoT DNS info with server address and Server Name
  Indication (SNI) in the form server_address#SNI, e.g.
  1.2.3.4#dns.myhome.com as nameserver addresses to Netplan. As a
  result, subsequent Netplan config applications fail because DNS
  servers don’t have the expected dotted decimal (IPv4) or colon’ed hex
  (IPv6) form.

  ```
  nmcli> describe ipv4.dns

  === [dns] ===
  [NM property description]
  Array of IP addresses of DNS servers. For DoT (DNS over TLS), the SNI server 
name can be specified by appending "#example.com" to the IP address of the DNS 
server. This currently only has effect when using systemd-resolved.
  ```

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


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

[Desktop-packages] [Bug 2045096] Re: Error in network definition: Invalid MAC address 'random'

2024-02-26 Thread Lukas Märdian

** Changed in: netplan
   Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2045096

Title:
  Error in network definition: Invalid MAC address 'random'

Status in netplan:
  Fix Committed
Status in netplan.io package in Ubuntu:
  New
Status in network-manager package in Ubuntu:
  New

Bug description:
  netplan dose not understand the 'random' key word in 'Cloned MAC address' set 
by networkmanager.
  ```
  /etc/netplan/90-NM-X.yaml:9:19: Error in network definition: Invalid MAC 
address 'random', must be XX:XX:XX:XX:XX:XX or 
XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
macaddress: "random"
^
  ```

  netplan Version 0.107-5ubuntu2
  network-manager Version 1.44.2-1ubuntu2

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


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

[Desktop-packages] [Bug 2045096] Re: Error in network definition: Invalid MAC address 'random'

2024-02-19 Thread Lukas Märdian

** Changed in: netplan
   Status: Triaged => In Progress

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2045096

Title:
  Error in network definition: Invalid MAC address 'random'

Status in netplan:
  In Progress
Status in netplan.io package in Ubuntu:
  New
Status in network-manager package in Ubuntu:
  New

Bug description:
  netplan dose not understand the 'random' key word in 'Cloned MAC address' set 
by networkmanager.
  ```
  /etc/netplan/90-NM-X.yaml:9:19: Error in network definition: Invalid MAC 
address 'random', must be XX:XX:XX:XX:XX:XX or 
XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
macaddress: "random"
^
  ```

  netplan Version 0.107-5ubuntu2
  network-manager Version 1.44.2-1ubuntu2

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


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

[Desktop-packages] [Bug 2052495] Re: [MIR] wsl-pro-service

** Also affects: wsl-pro-service (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** Also affects: wsl-pro-service (Ubuntu Noble)
   Importance: Undecided
 Assignee: Lukas Märdian (slyon)
   Status: New

** Also affects: wsl-pro-service (Ubuntu Focal)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to wsl-pro-service in Ubuntu.
https://bugs.launchpad.net/bugs/2052495

Title:
  [MIR] wsl-pro-service

Status in wsl-pro-service package in Ubuntu:
  New
Status in wsl-pro-service source package in Focal:
  New
Status in wsl-pro-service source package in Jammy:
  New
Status in wsl-pro-service source package in Noble:
  New

Bug description:
  [Availability]
  The package wsl-pro-service is already available in Ubuntu universe.
  The package wsl-pro-service build for the architectures it is designed to 
work on.
  It currently builds and works for architectures: amd64, arm64, armhf, 
ppc64el, riscv64, s390x

  Link to package https://launchpad.net/ubuntu/+source/wsl-pro-service

  [Rationale]
  Ubuntu Pro for WSL is a set of applications to manage Ubuntu WSL instances, 
grant them Pro status, orchestrate instances from Landscape and manage their 
lifecycle. Wsl-pro-service serves as a bridge between the agent running on 
Windows and Ubuntu instances. It controls the Pro and Landscape status.
  The package wsl-pro-service is required to be in main to seed it by default 
on WSL images.
  The package wsl-pro-service will generally be useful for corporate users.  
  No package in main or universe currently offers these capabilities.

  The target release is all the LTS releases from 20.04 onwards.

  [Security]
  This is a new software developed and maintained by Canonical. It has no 
security history.

  It is a new software and no CVEs/security issues in this software in
  the past.

  - no `suid` or `sgid` binaries
  - The package installs a systemd service called wsl-pro-service
  - It installs a service in /usr/libexec/wsl-pro-service, running as root. The 
service has some systemd confinement.
  - Packages does not open privileged ports (ports < 1024)
  - Packages does not contain extensions to security-sensitive software
  - Communication between wsl-pro-service and the agent running on Windows is 
done over gRPC.
  - Security has been kept in mind and common isolation/risk-mitigation 
patterns are in place utilizing systemd isolation features.

  *This requires a security review.*

  [Quality assurance - function/usage]
  The package works well right after installation. 

  [Quality assurance - maintenance]
  The Ubuntu Desktop team (~desktop-packages) maintains this package. It 
doesn’t have any long-term and critical, open bugs: 
  - https://github.com/canonical/ubuntu-pro-for-windows/issues 
  - https://bugs.launchpad.net/ubuntu/+source/wsl-pro-service 

  [Quality assurance - testing]
  There is a comprehensive, non-trivial, testsuite. The testsuite includes 
integration and functional tests.
  The testsuite runs at build time. The branch coverage is over 88%:
  - 
https://github.com/canonical/ubuntu-pro-for-windows/actions/workflows/qa.yaml?query=branch%3Amain
 
  - https://app.codecov.io/gh/canonical/ubuntu-pro-for-wsl 

  The same test suite runs as autopkgtest. It is passing on all supported 
architectures. Links to test logs:
  - https://autopkgtest.ubuntu.com/packages/wsl-pro-service

  Upstream CI also includes code sanity checks (golangci-lint, including
  gosec) and vulnerability scanning (govulneck).

  [Quality assurance - packaging]
  - There is no debian/watch because wsl-pro-service is a native package.
  - debian/control defines a correct Maintainer field:
  - Maintainer: Ubuntu Developers 

  This package does not yield massive lintian Warnings, Errors
  ```
 W: wsl-pro-service: no-manual-page [usr/libexec/wsl-pro-service]
  ```

  Full output from   `lintian --pedantic`:

  ```
 W: wsl-pro-service: no-manual-page [usr/libexec/wsl-pro-service]
  ```

  - Lintian overrides  are not present.
  - This package does not rely on obsolete or about to be demoted packages.
  - This package has no python2 or GTK2 dependencies
  - The package will be installed by default but does not ask debconf questions.

  Packaging and build is easy:
  - 
https://github.com/canonical/ubuntu-pro-for-windows/blob/main/wsl-pro-service/debian/rules
  

  [UI standards]
  Application is not end-user facing. However some strings are translatable and 
used for error messages via standard intltool/gettext or similar build and 
runtime internationalization system:

  The system for internationalization is in place of the project and the
  mo and po files are generated. It’s a question of taking the time to
  mark the appropriate strings for translations. It is a background
  service. Strings are used for logging and are not immediately visible
  to the user.

  [Dependencies]
  No furt

[Desktop-packages] [Bug 2052959] Re: FTBFS when rebuilding 1.44 with glib2-2.79.1

Upstream fix landed in:
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/7f2a32fa11d580ee65a0458f438018de12b6ae84

** Summary changed:

- FTBFS when rebuilding 1.44 with GCC-14
+ FTBFS when rebuilding 1.44 with glib2-2.79.1

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2052959

Title:
  FTBFS when rebuilding 1.44 with glib2-2.79.1

Status in network-manager package in Ubuntu:
  Fix Committed

Bug description:
  FTBFS due to test failure after an unrelated autopkgtest change was
  uploaded (https://launchpad.net/ubuntu/+source/network-
  manager/1.44.2-7ubuntu2).

  
  ok 7 /config/warnings
  PASS: src/core/tests/config/test-config 7 /config/warnings
  # (src/core/tests/config/test-config.c:1107) invalid value in config-data 
.intern.with-whitespace.key2 = (null) (instead of " b c\,  d  ")
  exec "./src/core/tests/config/test-config" failed with exit code 133
  ERROR: src/core/tests/config/test-config - too few tests run (expected 14, 
got 7)
  ERROR: src/core/tests/config/test-config - exited with status 5

  See upstream bug report:
  https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1465

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/2052959/+subscriptions


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

[Desktop-packages] [Bug 2052959] Re: FTBFS when rebuilding 1.44 with GCC-14

Fixed in https://launchpad.net/ubuntu/+source/network-
manager/1.45.90-1ubuntu1

** Changed in: network-manager (Ubuntu)
   Status: New => Fix Committed

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2052959

Title:
  FTBFS when rebuilding 1.44 with glib2-2.79.1

Status in network-manager package in Ubuntu:
  Fix Committed

Bug description:
  FTBFS due to test failure after an unrelated autopkgtest change was
  uploaded (https://launchpad.net/ubuntu/+source/network-
  manager/1.44.2-7ubuntu2).

  
  ok 7 /config/warnings
  PASS: src/core/tests/config/test-config 7 /config/warnings
  # (src/core/tests/config/test-config.c:1107) invalid value in config-data 
.intern.with-whitespace.key2 = (null) (instead of " b c\,  d  ")
  exec "./src/core/tests/config/test-config" failed with exit code 133
  ERROR: src/core/tests/config/test-config - too few tests run (expected 14, 
got 7)
  ERROR: src/core/tests/config/test-config - exited with status 5

  See upstream bug report:
  https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1465

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/2052959/+subscriptions


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

[Desktop-packages] [Bug 2052959] Re: FTBFS when rebuilding 1.44 with GCC-14

** Summary changed:

- FTBFS when rebuilding 1.44
+ FTBFS when rebuilding 1.44 with GCC-14

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2052959

Title:
  FTBFS when rebuilding 1.44 with GCC-14

Status in network-manager package in Ubuntu:
  New

Bug description:
  FTBFS due to test failure after an unrelated autopkgtest change was
  uploaded (https://launchpad.net/ubuntu/+source/network-
  manager/1.44.2-7ubuntu2).

  
  ok 7 /config/warnings
  PASS: src/core/tests/config/test-config 7 /config/warnings
  # (src/core/tests/config/test-config.c:1107) invalid value in config-data 
.intern.with-whitespace.key2 = (null) (instead of " b c\,  d  ")
  exec "./src/core/tests/config/test-config" failed with exit code 133
  ERROR: src/core/tests/config/test-config - too few tests run (expected 14, 
got 7)
  ERROR: src/core/tests/config/test-config - exited with status 5

  See upstream bug report:
  https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1465

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/2052959/+subscriptions


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

[Desktop-packages] [Bug 2052959] [NEW] FTBFS when rebuilding 1.44

2024-02-12 Thread Lukas Märdian

Public bug reported:

FTBFS due to test failure after an unrelated autopkgtest change was
uploaded (https://launchpad.net/ubuntu/+source/network-
manager/1.44.2-7ubuntu2).


ok 7 /config/warnings
PASS: src/core/tests/config/test-config 7 /config/warnings
# (src/core/tests/config/test-config.c:1107) invalid value in config-data 
.intern.with-whitespace.key2 = (null) (instead of " b c\,  d  ")
exec "./src/core/tests/config/test-config" failed with exit code 133
ERROR: src/core/tests/config/test-config - too few tests run (expected 14, got 
7)
ERROR: src/core/tests/config/test-config - exited with status 5

See upstream bug report:
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1465

** Affects: network-manager (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: update-excuse

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2052959

Title:
  FTBFS when rebuilding 1.44

Status in network-manager package in Ubuntu:
  New

Bug description:
  FTBFS due to test failure after an unrelated autopkgtest change was
  uploaded (https://launchpad.net/ubuntu/+source/network-
  manager/1.44.2-7ubuntu2).

  
  ok 7 /config/warnings
  PASS: src/core/tests/config/test-config 7 /config/warnings
  # (src/core/tests/config/test-config.c:1107) invalid value in config-data 
.intern.with-whitespace.key2 = (null) (instead of " b c\,  d  ")
  exec "./src/core/tests/config/test-config" failed with exit code 133
  ERROR: src/core/tests/config/test-config - too few tests run (expected 14, 
got 7)
  ERROR: src/core/tests/config/test-config - exited with status 5

  See upstream bug report:
  https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1465

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/2052959/+subscriptions


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

[Desktop-packages] [Bug 1958019]

2024-02-05 Thread lukas

(In reply to Jacob Garby from comment #816)
> (In reply to Lukas from comment #814)
> > (In reply to Jacob Garby from comment #813)
> > > I have a "Lenovo Legion Slim 7i 16", and several days ago, out of
> nowhere,
> > > the speaker started working. I have no idea how -- I did not change
> > anything
> > > manually. I suspect it's a new kernel version that did it.
> > > 
> > > I'm on Arch Linux, and I can't remember which kernel version I have
> > > installed (but I can update when I get home later today).
> > > 
> > > Anyway, good news!
> > 
> > Amazing
> > 
> > I would like to reproduce this. You can find out your current kernel
> version
> > with the command "uname -r". The installed sound packages/libs would also
> be
> > interesting. What I know of would be to look at the alsa version. 
> > Someone else surely has more information on what to specificly look for and
> > how.
> 
> Okay, so my kernel version is 6.7.2-arch1-1
> 
> These are some (maybe all) of the audio related packages I have installed:
> kpipewire 5.27.10-1
> libpipewire 1:1.0.1-2
> pipewire 1:1.0.1-2
> pipewire-alsa 1:1.0.1-2
> pipewire-audio 1:1.0.1-2
> pipewire-jack 1:1.0.1-2
> pipewire-pulse 1:1.0.1-2
> libpulse 17.0-3
> pipewire-pulse 1:1.0.1-2
> projectm-pulseaudio 3.1.12-4
> 
> But I can verify that my speaker did also work _before_ I switched from
> Pulseaudio to Pipewire, seems both should work.
> 
> The result of running alsa-info is here:
> http://alsa-project.org/db/?f=07a1fdaf34a424adc27dbb6be3f417995df6994f
> 
> Good luck!

atm i did not get it to work. i habe all the same packages or newer
installed. hoping newer verions did not brick it again this means it
would have to be the kernel. fedora 39 stabe only gets access to 6.6.13.
tests for 6.7 are beeing done.

i even tired to switch to pulse and back. no changes.

will provide mor info when new kernel is here. maybe someone can provide
info on weather fedora and arch kernel are vastly different as yours
specificly says arch in the version. mine does not

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to alsa-driver in Ubuntu.
https://bugs.launchpad.net/bugs/1958019

Title:
  [Lenovo Legion7 16ACHg6 82N6, Realtek ALC287, Speaker, Internal] No
  sound at all

Status in sound-2.6 (alsa-kernel):
  Confirmed
Status in alsa-driver package in Ubuntu:
  Confirmed

Bug description:
  On my Lenovo Legion-7-16ACHg6 laptop I can't hear any sound by
  internal speakers, but it work by headphones connected to standard
  jack aux.

  uname -r
  5.11.0-44-generic

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: alsa-base 1.0.25+dfsg-0ubuntu5
  ProcVersionSignature: Ubuntu 5.11.0-44.48~20.04.2-generic 5.11.22
  Uname: Linux 5.11.0-44-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.11-0ubuntu27.21
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC2:  i3draven   1266 F pulseaudio
   /dev/snd/controlC0:  i3draven   1266 F pulseaudio
   /dev/snd/controlC1:  i3draven   1266 F pulseaudio
   /dev/snd/pcmC1D0p:   i3draven   1266 F...m pulseaudio
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Sat Jan 15 15:10:53 2022
  InstallationDate: Installed on 2021-10-11 (96 days ago)
  InstallationMedia: Ubuntu 20.04.3 LTS "Focal Fossa" - Release amd64 (20210819)
  PackageArchitecture: all
  SourcePackage: alsa-driver
  Symptom: audio
  Symptom_AlsaPlaybackTest: ALSA playback test through plughw:Generic failed
  Symptom_Card: Family 17h (Models 10h-1fh) HD Audio Controller - HD-Audio 
Generic
  Symptom_DevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC2:  i3draven   1266 F pulseaudio
   /dev/snd/controlC0:  i3draven   1266 F pulseaudio
   /dev/snd/controlC1:  i3draven   1266 F pulseaudio
   /dev/snd/pcmC1D0p:   i3draven   1266 F...m pulseaudio
  Symptom_Jack: Speaker, Internal
  Symptom_Type: No sound at all
  Title: [82N6, Realtek ALC287, Speaker, Internal] No sound at all
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 11/08/2021
  dmi.bios.release: 1.49
  dmi.bios.vendor: LENOVO
  dmi.bios.version: GKCN49WW
  dmi.board.asset.tag: NO Asset Tag
  dmi.board.name: LNVNB161216
  dmi.board.vendor: LENOVO
  dmi.board.version: SDK0R32862 WIN
  dmi.chassis.asset.tag: NO Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Legion 7 16ACHg6
  dmi.ec.firmware.release: 1.49
  dmi.modalias: 
dmi:bvnLENOVO:bvrGKCN49WW:bd11/08/2021:br1.49:efr1.49:svnLENOVO:pn82N6:pvrLegion716ACHg6:skuLENOVO_MT_82N6_BU_idea_FM_Legion716ACHg6:rvnLENOVO:rnLNVNB161216:rvrSDK0R32862WIN:cvnLENOVO:ct10:cvrLegion716ACHg6:
  d

[Desktop-packages] [Bug 1958019]

2024-01-31 Thread lukas

(In reply to Jacob Garby from comment #813)
> I have a "Lenovo Legion Slim 7i 16", and several days ago, out of nowhere,
> the speaker started working. I have no idea how -- I did not change anything
> manually. I suspect it's a new kernel version that did it.
> 
> I'm on Arch Linux, and I can't remember which kernel version I have
> installed (but I can update when I get home later today).
> 
> Anyway, good news!

Amazing

I would like to reproduce this. You can find out your current kernel version 
with the command "uname -r". The installed sound packages/libs would also be 
interesting. What I know of would be to look at the alsa version. 
Someone else surely has more information on what to specificly look for and how.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to alsa-driver in Ubuntu.
https://bugs.launchpad.net/bugs/1958019

Title:
  [Lenovo Legion7 16ACHg6 82N6, Realtek ALC287, Speaker, Internal] No
  sound at all

Status in sound-2.6 (alsa-kernel):
  Confirmed
Status in alsa-driver package in Ubuntu:
  Confirmed

Bug description:
  On my Lenovo Legion-7-16ACHg6 laptop I can't hear any sound by
  internal speakers, but it work by headphones connected to standard
  jack aux.

  uname -r
  5.11.0-44-generic

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: alsa-base 1.0.25+dfsg-0ubuntu5
  ProcVersionSignature: Ubuntu 5.11.0-44.48~20.04.2-generic 5.11.22
  Uname: Linux 5.11.0-44-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.11-0ubuntu27.21
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC2:  i3draven   1266 F pulseaudio
   /dev/snd/controlC0:  i3draven   1266 F pulseaudio
   /dev/snd/controlC1:  i3draven   1266 F pulseaudio
   /dev/snd/pcmC1D0p:   i3draven   1266 F...m pulseaudio
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Sat Jan 15 15:10:53 2022
  InstallationDate: Installed on 2021-10-11 (96 days ago)
  InstallationMedia: Ubuntu 20.04.3 LTS "Focal Fossa" - Release amd64 (20210819)
  PackageArchitecture: all
  SourcePackage: alsa-driver
  Symptom: audio
  Symptom_AlsaPlaybackTest: ALSA playback test through plughw:Generic failed
  Symptom_Card: Family 17h (Models 10h-1fh) HD Audio Controller - HD-Audio 
Generic
  Symptom_DevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC2:  i3draven   1266 F pulseaudio
   /dev/snd/controlC0:  i3draven   1266 F pulseaudio
   /dev/snd/controlC1:  i3draven   1266 F pulseaudio
   /dev/snd/pcmC1D0p:   i3draven   1266 F...m pulseaudio
  Symptom_Jack: Speaker, Internal
  Symptom_Type: No sound at all
  Title: [82N6, Realtek ALC287, Speaker, Internal] No sound at all
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 11/08/2021
  dmi.bios.release: 1.49
  dmi.bios.vendor: LENOVO
  dmi.bios.version: GKCN49WW
  dmi.board.asset.tag: NO Asset Tag
  dmi.board.name: LNVNB161216
  dmi.board.vendor: LENOVO
  dmi.board.version: SDK0R32862 WIN
  dmi.chassis.asset.tag: NO Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Legion 7 16ACHg6
  dmi.ec.firmware.release: 1.49
  dmi.modalias: 
dmi:bvnLENOVO:bvrGKCN49WW:bd11/08/2021:br1.49:efr1.49:svnLENOVO:pn82N6:pvrLegion716ACHg6:skuLENOVO_MT_82N6_BU_idea_FM_Legion716ACHg6:rvnLENOVO:rnLNVNB161216:rvrSDK0R32862WIN:cvnLENOVO:ct10:cvrLegion716ACHg6:
  dmi.product.family: Legion 7 16ACHg6
  dmi.product.name: 82N6
  dmi.product.sku: LENOVO_MT_82N6_BU_idea_FM_Legion 7 16ACHg6
  dmi.product.version: Legion 7 16ACHg6
  dmi.sys.vendor: LENOVO

To manage notifications about this bug go to:
https://bugs.launchpad.net/sound-2.6/+bug/1958019/+subscriptions


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

[Desktop-packages] [Bug 1958019]

2024-01-23 Thread lukas

Hey, I have a Lenovo Yoga 7 16IAP7 with Fedora Workstation 39 installed.

Kernel Verion: Linux 6.6.11-200.fc39.x86_64
alsa-lib version: alsa-lib-1.2.10-3.fc39.x86_64

I installed alsa-tools and went into hdajackretask to see what is going
on. Then I noticed that my System is telling me that I have an ALC287
installed but actually it is a ALC3306. Sound is horrible and several
fixes with ALC 287 for Legion Models did nit work. In the Settings I can
see as well, that only 2 of the 4 integrated speakers are getting
noticed.

I have had this Problem for a while now.

Comment #806 said that this should have worked till 6.6 and then it
broke again. I had a fresh install of Fedora 38 back then with the
Kernel 6.4.6-200.fc38.x86_64. It did not work form me with this Kernel
either.

Are there any news or is there hope of fixes?

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to alsa-driver in Ubuntu.
https://bugs.launchpad.net/bugs/1958019

Title:
  [Lenovo Legion7 16ACHg6 82N6, Realtek ALC287, Speaker, Internal] No
  sound at all

Status in sound-2.6 (alsa-kernel):
  Confirmed
Status in alsa-driver package in Ubuntu:
  Confirmed

Bug description:
  On my Lenovo Legion-7-16ACHg6 laptop I can't hear any sound by
  internal speakers, but it work by headphones connected to standard
  jack aux.

  uname -r
  5.11.0-44-generic

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: alsa-base 1.0.25+dfsg-0ubuntu5
  ProcVersionSignature: Ubuntu 5.11.0-44.48~20.04.2-generic 5.11.22
  Uname: Linux 5.11.0-44-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.11-0ubuntu27.21
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC2:  i3draven   1266 F pulseaudio
   /dev/snd/controlC0:  i3draven   1266 F pulseaudio
   /dev/snd/controlC1:  i3draven   1266 F pulseaudio
   /dev/snd/pcmC1D0p:   i3draven   1266 F...m pulseaudio
  CasperMD5CheckResult: skip
  CurrentDesktop: ubuntu:GNOME
  Date: Sat Jan 15 15:10:53 2022
  InstallationDate: Installed on 2021-10-11 (96 days ago)
  InstallationMedia: Ubuntu 20.04.3 LTS "Focal Fossa" - Release amd64 (20210819)
  PackageArchitecture: all
  SourcePackage: alsa-driver
  Symptom: audio
  Symptom_AlsaPlaybackTest: ALSA playback test through plughw:Generic failed
  Symptom_Card: Family 17h (Models 10h-1fh) HD Audio Controller - HD-Audio 
Generic
  Symptom_DevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC2:  i3draven   1266 F pulseaudio
   /dev/snd/controlC0:  i3draven   1266 F pulseaudio
   /dev/snd/controlC1:  i3draven   1266 F pulseaudio
   /dev/snd/pcmC1D0p:   i3draven   1266 F...m pulseaudio
  Symptom_Jack: Speaker, Internal
  Symptom_Type: No sound at all
  Title: [82N6, Realtek ALC287, Speaker, Internal] No sound at all
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 11/08/2021
  dmi.bios.release: 1.49
  dmi.bios.vendor: LENOVO
  dmi.bios.version: GKCN49WW
  dmi.board.asset.tag: NO Asset Tag
  dmi.board.name: LNVNB161216
  dmi.board.vendor: LENOVO
  dmi.board.version: SDK0R32862 WIN
  dmi.chassis.asset.tag: NO Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Legion 7 16ACHg6
  dmi.ec.firmware.release: 1.49
  dmi.modalias: 
dmi:bvnLENOVO:bvrGKCN49WW:bd11/08/2021:br1.49:efr1.49:svnLENOVO:pn82N6:pvrLegion716ACHg6:skuLENOVO_MT_82N6_BU_idea_FM_Legion716ACHg6:rvnLENOVO:rnLNVNB161216:rvrSDK0R32862WIN:cvnLENOVO:ct10:cvrLegion716ACHg6:
  dmi.product.family: Legion 7 16ACHg6
  dmi.product.name: 82N6
  dmi.product.sku: LENOVO_MT_82N6_BU_idea_FM_Legion 7 16ACHg6
  dmi.product.version: Legion 7 16ACHg6
  dmi.sys.vendor: LENOVO

To manage notifications about this bug go to:
https://bugs.launchpad.net/sound-2.6/+bug/1958019/+subscriptions


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

[Desktop-packages] [Bug 2048388] Re: Test suite often fails with "systemd units changed without reload" on s390x

2024-01-18 Thread Lukas Märdian

IMO the wpasupplicant trigger is a red herring, as we see the same
failure on a trigger=system/255... test case:

https://autopkgtest.ubuntu.com/results/autopkgtest-
noble/noble/s390x/n/netplan.io/20240104_111341_511f7@/log.gz

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

Title:
  Test suite often fails with "systemd units changed without reload" on
  s390x

Status in netplan:
  Invalid
Status in netplan.io package in Ubuntu:
  Triaged
Status in wpa package in Ubuntu:
  New

Bug description:
  The "ethernets" autopkgtest for netplan.io 0.107-5ubuntu2 on s390x
  often fails with

  AssertionError: systemd units changed without reload

  Looking at the history of autopkgtest runs, it looks like that the
  error does not always occur during execution of a specific test. I've
  seen occurrences of this error during the following test-cases:

  test_dhcp6 (__main__.TestNetworkd.test_dhcp6) ... FAIL
  test_link_local_ipv4 (__main__.TestNetworkd.test_link_local_ipv4) ... FAIL
  test_eth_mtu (__main__.TestNetworkd.test_eth_mtu) ... FAIL

  Example [1]:

  781s FAIL: test_dhcp6 (__main__.TestNetworkd.test_dhcp6)
  781s --
  781s Traceback (most recent call last):
  781s   File 
"/tmp/autopkgtest.G0qQU0/build.Snp/src/tests/integration/ethernets.py", line 
189, in test_dhcp6
  781s self.generate_and_settle([self.state_dhcp6(self.dev_e_client)])
  781s   File 
"/tmp/autopkgtest.G0qQU0/build.Snp/src/tests/integration/base.py", line 342, in 
generate_and_settle
  781s self.fail('systemd units changed without reload')
  781s AssertionError: systemd units changed without reload

  [1] https://autopkgtest.ubuntu.com/results/autopkgtest-
  noble/noble/s390x/n/netplan.io/20240105_144627_cb35e@/log.gz

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


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

[Desktop-packages] [Bug 2048388] Re: Test suite often fails with "systemd units changed without reload" on s390x

2024-01-18 Thread Lukas Märdian

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

Title:
  Test suite often fails with "systemd units changed without reload" on
  s390x

Status in netplan:
  Invalid
Status in netplan.io package in Ubuntu:
  Triaged
Status in wpa package in Ubuntu:
  New

Bug description:
  The "ethernets" autopkgtest for netplan.io 0.107-5ubuntu2 on s390x
  often fails with

  AssertionError: systemd units changed without reload

  Looking at the history of autopkgtest runs, it looks like that the
  error does not always occur during execution of a specific test. I've
  seen occurrences of this error during the following test-cases:

  test_dhcp6 (__main__.TestNetworkd.test_dhcp6) ... FAIL
  test_link_local_ipv4 (__main__.TestNetworkd.test_link_local_ipv4) ... FAIL
  test_eth_mtu (__main__.TestNetworkd.test_eth_mtu) ... FAIL

  Example [1]:

  781s FAIL: test_dhcp6 (__main__.TestNetworkd.test_dhcp6)
  781s --
  781s Traceback (most recent call last):
  781s   File 
"/tmp/autopkgtest.G0qQU0/build.Snp/src/tests/integration/ethernets.py", line 
189, in test_dhcp6
  781s self.generate_and_settle([self.state_dhcp6(self.dev_e_client)])
  781s   File 
"/tmp/autopkgtest.G0qQU0/build.Snp/src/tests/integration/base.py", line 342, in 
generate_and_settle
  781s self.fail('systemd units changed without reload')
  781s AssertionError: systemd units changed without reload

  [1] https://autopkgtest.ubuntu.com/results/autopkgtest-
  noble/noble/s390x/n/netplan.io/20240105_144627_cb35e@/log.gz

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


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

[Desktop-packages] [Bug 2041491] Re: Provide an option to avoid the yaml NM backend

2024-01-15 Thread Lukas Märdian

Another option/idea I'd like to provide here is the migration script
used by NetworkManager [1], to transfer NM keyfiles from
/etc/NetworkManager/system-conncetions/ into /etc/netplan. This script
is automatically run on package upgrade of NetworkManager. I understand
this does not exactly fit the usecase described by alkisg, as you'd go
from debian-box:/etc/NetworkManager/system-connections -> ubuntu-
box:/etc/NetworkManager/system-connections -> migrate.sh -> ubuntu-
box:/run/NetworkManager/system-connections

Running "./migrate.sh configure" would transfer your copied original NM
keyfiles from a different box into Netplan and re-generate them in
/run/NetworkManager/system-connections:

```bash
# Run "Netplan Everywhere" migration after debhelper (re-)started
# NetworkManager.service for us. On every package upgrade.
DIR="/etc/NetworkManager/system-connections"
if [ "$1" = "configure" ] && [ -d "$DIR" ]; then
mkdir -p /run/netplan/nm-migrate
for CON in /etc/NetworkManager/system-connections/*; do
TYPE=$(file -bi "$CON" | cut -s -d ";" -f 1)
[ "$TYPE" = "text/plain" ] || continue # skip non-keyfiles
UUID=$(grep "^uuid=" "$CON" | cut -c 6-)
if [ -n "$UUID" ]
then
# Wait for NetworkManager startup to complete,
# so we can safely use nmcli. Wait in every interation to handle
# a crashed NetworkManager in the previous migraiton step.
if ! nm-online -qs; then
echo "SKIP: NetworkManager is not ready ..." 1>&2
continue
fi
BACKUP="/run/netplan/nm-migrate/"$(basename "$CON")
ORIG_NAME=$(nmcli --get-values connection.id con show "$UUID") || \
{ echo "SKIP: $(basename "$CON") ($UUID) unknown to 
NetworkManager." 1>&2 && \
  continue; }
cp "$CON" "$BACKUP"
echo "Migrating $ORIG_NAME ($UUID) to /etc/netplan" 1>&2
# Touch the connection's ID (con-name) to trigger its migration.
# The Netplan integration will translate the original NM keyfile 
from
# /etc/NetworkManager/system-connections/* to a YAML file located in
# /etc/netplan/90-NM-*.yaml and re-generate a corresponding keyfile 
in
# /run/NetworkManager/system-connections/netplan-NM-*.nmconnection
nmcli con mod "$UUID" con-name "$ORIG_NAME" || \
(echo "FAILED. Restoring backup ..." 1>&2 && mv "$BACKUP" 
"$CON" && \
 rm -f "/etc/netplan/90-NM-$UUID"*.yaml)
rm -f "$BACKUP" # clear backup (if it still exists)
   fi
done
rm -rf /run/netplan/nm-migrate # cleanup after ourselves
(nm-online -qs && nmcli con reload) || echo "WARNING: NetworkManager could 
not reload connections ..." 1>&2
fi
```

[1] https://git.launchpad.net/network-manager/tree/debian/network-
manager.postinst#n62

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2041491

Title:
  Provide an option to avoid the yaml NM backend

Status in netplan.io package in Ubuntu:
  Confirmed
Status in network-manager package in Ubuntu:
  Confirmed

Bug description:
  Hi, recently netplan added support for a yaml NM backend:

  https://discourse.ubuntu.com/t/call-for-testing-networkmanager-yaml-
  settings/32420

  The rationale is that "the descriptive YAML layer is especially useful
  in cloud environments":

  
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/556

  It's great that you care about that user group!
  Please also care for the rest of us that do not use cloud environments!

  For example, I routinely review, clone, backup or even directly edit
  the /etc/NetworkManager/system-connections files in my desktops and
  servers, in all distributions.

  Having an Ubuntu-specific way to do things will make things harder for
  me. I will have to learn a new Ubuntu-specific syntax, develop scripts
  and methods to convert my connections between distributions, I will
  need to discover and report bugs in the netplan <=> nm mapping etc...

  I.e. Ubuntu is great for the cloud, and it's awesome that you want to provide 
a unified yaml-based experience for cloud-init etc.
  But Ubuntu is also great outside the cloud; please allow us to continue 
having a unified experience between distributions (i.e. directly using nm or 
systemd-networkd) without enforcing an Ubuntu-specific way of doing things 
(netplan) to us.

  For Ubuntu 24.04+, please provide an option to avoid the yaml NM
  backend, thank you very much!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/2041491/+subscriptions


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

[Desktop-packages] [Bug 2045096] Re: Error in network definition: Invalid MAC address 'random'

2024-01-08 Thread Lukas Märdian

Reducing to "Medium", as I don't think we can hit this situation through
the Netplan-everywhere integration, but manual steps (wrong YAML config)
must be involved in reaching this state.

We're working on a fix here:
https://github.com/canonical/netplan/pull/427

** Changed in: netplan
   Importance: High => Medium

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2045096

Title:
  Error in network definition: Invalid MAC address 'random'

Status in netplan:
  Triaged
Status in netplan.io package in Ubuntu:
  New
Status in network-manager package in Ubuntu:
  New

Bug description:
  netplan dose not understand the 'random' key word in 'Cloned MAC address' set 
by networkmanager.
  ```
  /etc/netplan/90-NM-X.yaml:9:19: Error in network definition: Invalid MAC 
address 'random', must be XX:XX:XX:XX:XX:XX or 
XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
macaddress: "random"
^
  ```

  netplan Version 0.107-5ubuntu2
  network-manager Version 1.44.2-1ubuntu2

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


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

[Desktop-packages] [Bug 2045096] Re: Error in network definition: Invalid MAC address 'random'

2024-01-04 Thread Lukas Märdian

@vanillaoerba How did you end up in that situation? Did you modify
/etc/netplan/90-NM-X.yaml manually?

Those special values for the MAC address should have been handled by the
networkmanager.passthrough.cloned-mac-address=random setting for you..

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2045096

Title:
  Error in network definition: Invalid MAC address 'random'

Status in netplan:
  Triaged
Status in netplan.io package in Ubuntu:
  New
Status in network-manager package in Ubuntu:
  New

Bug description:
  netplan dose not understand the 'random' key word in 'Cloned MAC address' set 
by networkmanager.
  ```
  /etc/netplan/90-NM-X.yaml:9:19: Error in network definition: Invalid MAC 
address 'random', must be XX:XX:XX:XX:XX:XX or 
XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
macaddress: "random"
^
  ```

  netplan Version 0.107-5ubuntu2
  network-manager Version 1.44.2-1ubuntu2

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


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

[Desktop-packages] [Bug 2046158] Re: Updating wireguard-peer.allowed-ips gets wrong default netmask for IPv6 addresses

2024-01-04 Thread Lukas Märdian

** Changed in: netplan.io (Ubuntu)
   Status: Confirmed => Fix Committed

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2046158

Title:
  Updating wireguard-peer.allowed-ips gets wrong default netmask for
  IPv6 addresses

Status in netplan.io package in Ubuntu:
  Fix Committed
Status in network-manager package in Ubuntu:
  Invalid

Bug description:
  In https://cockpit-project.org/ we have an integration test for
  NM+wireguard integration. That test starts with an IPv4-only
  connection:

  # cat /etc/netplan/90-NM-b5edee2d-c736-4827-bae3-c95e349cb73b.yaml
  network:
    version: 2
    tunnels:
  wg0:
    renderer: NetworkManager
    addresses:
    - "10.0.0.2/24"
    mode: "wireguard"
    port: 51820
    keys:
  private: "KDI3xiJN6uthba43AMm7EBBxjPPNeamjlV3xXT5Zh0E="
    peers:
    - keys:
    public: "RsfKtJHMIAYs/i2i/TZUfRSWF1LmAEXzc3UyidXZTnI="
  allowed-ips:
  - "10.0.0.1/32"
    networkmanager:
  uuid: "b5edee2d-c736-4827-bae3-c95e349cb73b"
  name: "con-wg0"
  passthrough:
    ipv6.addr-gen-mode: "default"
    ipv6.method: "disabled"
    ipv6.ip6-privacy: "-1"
    proxy._: ""

  which gets rendered as

  # cat /run/NetworkManager/system-connections/netplan-wg0.nmconnection
  [connection]
  id=con-wg0
  type=wireguard
  uuid=b5edee2d-c736-4827-bae3-c95e349cb73b
  interface-name=wg0

  [wireguard]
  private-key=KDI3xiJN6uthba43AMm7EBBxjPPNeamjlV3xXT5Zh0E=
  listen-port=51820

  [wireguard-peer.RsfKtJHMIAYs/i2i/TZUfRSWF1LmAEXzc3UyidXZTnI=]
  allowed-ips=10.0.0.1/32;

  [ipv4]
  method=manual
  address1=10.0.0.2/24

  [ipv6]
  #Netplan: passthrough override
  method=disabled
  #Netplan: passthrough setting
  addr-gen-mode=default

  [proxy]

  Now the UI modifies the "allowed-ips" setting to ["10.0.0.1",
  "2001::1"]. Notably the addresses do *not* have a netmask, neither in
  the original config nor that update. Unfortunately that update cannot
  be done on the CLI:

  # nmcli con modify con-wg0 
"wireguard-peer.RsfKtJHMIAYs/i2i/TZUfRSWF1LmAEXzc3UyidXZTnI=.allowed-ips" 
"2001::1"
  Error: invalid or not allowed setting 'wireguard-peer': 'wireguard-peer' not 
among [connection, wireguard, match, ipv4, ipv6, hostname, link, tc, proxy].

  So it has to happen via D-Bus:

  
"/org/freedesktop/NetworkManager/Settings/5","org.freedesktop.NetworkManager.Settings.Connection","Update",[{"connection":{"id":{"v":"con-
  wg0","t":"s"},"interface-
  
name":{"v":"wg0","t":"s"},"permissions":{"t":"as","v":[]},"timestamp":{"t":"t","v":1702299778},"type":{"v":"wireguard","t":"s"},"uuid":{"v":"04237010-9663-4064-aa06-bcde279b67da","t":"s"},"autoconnect":{"v":true,"t":"b"},"autoconnect-
  slaves":{"v":-1,"t":"i"}},"wireguard":{"listen-
  port":{"v":51820,"t":"u"},"peers":{"v":[{"public-
  key":{"t":"s","v":"2CvDKtc8k94LLpabq6rZdYh1Co8fzjhoAD61ESMfjSc="},"allowed-
  ips":{"t":"as","v":["10.0.0.1/32","2001::1"]}}],"t":"aa{sv}"},"private-
  
key":{"v":"iDM1BknhsROJt8TpJnBNNHVCAqWnfqZEkL20+sVfXlA=","t":"s"}},"ipv4":{"address-
  
data":{"t":"aa{sv}","v":[{"address":{"t":"s","v":"10.0.0.2"},"prefix":{"t":"u","v":24}}]},"addresses":{"v":[[33554442,24,0]],"t":"aau"},"dns-
  search":{"v":[],"t":"as"},"method":{"v":"manual","t":"s"},"route-
  
data":{"t":"aa{sv}","v":[]},"routes":{"t":"aau","v":[]},"dns":{"v":[],"t":"au"}},"ipv6":{"address-
  data":{"t":"aa{sv}","v":[]},"addresses":{"v":[],"t":"a(ayuay)"},"dns-
  search":{"v":[],"t":"as"},"method":{"v":"disabled","t":"s"},"route-
  data":{"t":"aa{sv}","v":[]},"routes":{"v":[],"t":"a(ayuayu)"},"ignore-
  auto-dns":{"v":false,"t":"b"},"ignore-auto-
  routes":{"v":false,"t":"b"},"dns":{"v":[],"t":"aay"}},"proxy":{}}]]

  But this generates a wrong "/32" default netmask in the netplan config
  for the IPv6 address:

  allowed-ips:
  - "10.0.0.1/32"
  - "2001::1/32"

  On Fedora, with NM's default .nmconnection files, such a netmask is
  not added on this call. The netplan backend should do that (not
  second-guessing NM) or at least default to /128 for an IPv6 address.

  Doing this D-Bus call with `busctl` is a nuisance. If you need a
  reproducer at this level, I can spend an hour or so trying to stitch
  it together, but I hope your unit tests make this easier somehow.

  This was fine until 22.10, but with NM's new "netplan by default"
  backend this regressed.

  DistroRelease: Ubuntu 23.10
  Package: network-manager 1.44.2-1ubuntu1.2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/2046158/+subscriptions


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

[Desktop-packages] [Bug 2045096] Re: Error in network definition: Invalid MAC address 'random'

2023-12-04 Thread Lukas Märdian

** Also affects: netplan.io (Ubuntu)
   Importance: Undecided
   Status: New

** Tags added: fr-6121

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2045096

Title:
  Error in network definition: Invalid MAC address 'random'

Status in netplan:
  Triaged
Status in netplan.io package in Ubuntu:
  New
Status in network-manager package in Ubuntu:
  New

Bug description:
  netplan dose not understand the 'random' key word in 'Cloned MAC address' set 
by networkmanager.
  ```
  /etc/netplan/90-NM-X.yaml:9:19: Error in network definition: Invalid MAC 
address 'random', must be XX:XX:XX:XX:XX:XX or 
XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
macaddress: "random"
^
  ```

  netplan Version 0.107-5ubuntu2
  network-manager Version 1.44.2-1ubuntu2

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


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

[Desktop-packages] [Bug 2045096] Re: Error in network definition: Invalid MAC address 'random'

2023-12-04 Thread Lukas Märdian

** Tags added: netplan-everywhere

** Changed in: netplan
   Status: New => Triaged

** Changed in: netplan
   Importance: Undecided => High

** Tags added: foundations-todo

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2045096

Title:
  Error in network definition: Invalid MAC address 'random'

Status in netplan:
  Triaged
Status in network-manager package in Ubuntu:
  New

Bug description:
  netplan dose not understand the 'random' key word in 'Cloned MAC address' set 
by networkmanager.
  ```
  /etc/netplan/90-NM-X.yaml:9:19: Error in network definition: Invalid MAC 
address 'random', must be XX:XX:XX:XX:XX:XX or 
XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX
macaddress: "random"
^
  ```

  netplan Version 0.107-5ubuntu2
  network-manager Version 1.44.2-1ubuntu2

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


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

[Desktop-packages] [Bug 2026230] Re: libnetplan integration breaks "cloned-mac-address" special values

2023-11-29 Thread Lukas Märdian

Fixed in v0.107 https://github.com/canonical/netplan/releases/tag/0.107

** Changed in: netplan
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2026230

Title:
  libnetplan integration breaks "cloned-mac-address" special values

Status in netplan:
  Fix Released
Status in netplan.io package in Ubuntu:
  Fix Released
Status in network-manager package in Ubuntu:
  Invalid

Bug description:
  I received an error from apport about a programme not working. I
  collected the data to submit. Hope this helps.

  ProblemType: Crash
  DistroRelease: Ubuntu 23.10
  Package: network-manager 1.42.6-2ubuntu1
  Uname: Linux 6.2.0-24-generic x86_64
  Architecture: amd64
  Date: Wed Jul  5 23:11:14 2023
  ExecutablePath: /usr/sbin/NetworkManager
  ExecutableTimestamp: 1687429583
  ProcCmdline: /usr/sbin/NetworkManager --no-daemon
  ProcCwd: /
  ProcEnviron:
   LANG=en_US.UTF-8
   PATH=(custom, no user)
  Signal: 6
  SourcePackage: network-manager
  UserGroups: N/A

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


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

[Desktop-packages] [Bug 2024661] Re: Unable to configure Wireguard connection at NetworkManager interface

2023-11-27 Thread Lukas Märdian

This should have been fixed upstream as of
https://github.com/canonical/netplan/pull/371 and should be fixed in
Mantic.

Can you still re-produce this issue today?

** Changed in: netplan.io (Ubuntu)
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2024661

Title:
  Unable to configure Wireguard connection at NetworkManager interface

Status in netplan.io package in Ubuntu:
  Fix Released
Status in network-manager package in Ubuntu:
  Invalid

Bug description:
  Repro steps:

  1) Open NetworkManager GUI.
  2) Click "Add new Connection" and select "Wireguard" connection type.
  3) Then you have to configure new connection. Basic configuration looks like 
that:
  a) Write down connection name,
  b) Write down local private key,
  c) Create new peer and populate peer's parameters: public key of the 
peer, allowed IPs (i.e. 0.0.0.0/0), peer's IP address and port.
  4) Click "OK" and "Save".
  5) Open "Peers" again. Ensure that settings were not stored. All fields are 
empty.

  Found in Kubuntu flavor version 23.10 (development), Plasma Network Manager 
interface.
  netplan.io 0.106.1-2
  network-manager 1.42.4-1ubuntu7

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/2024661/+subscriptions


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

[Desktop-packages] [Bug 2040153] Re: Network Manager will not remove Netplan YAMLs when connections are deleted

2023-11-27 Thread Lukas Märdian

** Changed in: netplan.io (Ubuntu)
   Status: Triaged => Invalid

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2040153

Title:
  Network Manager will not remove Netplan YAMLs when connections are
  deleted

Status in netplan.io package in Ubuntu:
  Invalid
Status in network-manager package in Ubuntu:
  Fix Released
Status in netplan.io source package in Mantic:
  Invalid
Status in network-manager source package in Mantic:
  Fix Released

Bug description:
  [ Impact ]

  Desktop users, or any users with YAML files in /usr/lib/netplan, can't delete
  Network Manager connections persistently. That means that, when the 
connection is
  deliberately deleted by the user, it will re-appear when the system is 
rebooted or
  netplan apply is executed.

  This is happening because the systemd service unit is setting the property 
"ProtectSystem"
  to true. Because of that, /usr is being presented to the Network Manager 
daemon as read-only.
  When connections are deleted, libnetplan will try to open its YAML files with 
writing permissions
  and will fail for files from /usr/lib/netplan. Even if the user hasn't added 
any files there manually,
  the file /usr/lib/netplan/00-network-manager-all.yaml will be installed by 
the package ubuntu-settings.

  This issue is fixed by allow-listing /usr/lib/netplan with 
ReadWritePaths=/usr/lib/netplan in systemd
  so the Network Manager's daemon will be able to write to that directory.

  This upload also improves the autopkgtests related to Netplan. Network 
Manager will be
  started by systemd, which ensures we are testing in the same environment 
conditions
  used by a desktop installation. It also adds a few more instances of 
connections deletions so
  we can test a bit more that YAML files are being removed. It also adds all 
the dependencies
  required by the test script (which sadly was causing the nm_netplan.py tests 
to be skipped).

  [ Test Plan ]

  Launch a new Mantic VM:

  $ lxc launch ubuntu:mantic --vm

  Install network-manager and ubuntu-settings:

  # apt install network-manager ubuntu-settings

  Run Netplan

  # netplan apply

  Create a dummy connection via nmcli:

  # nmcli con add type dummy connection.interface-name dummy0

  Check a new YAML will be created in /etc/netplan

  Delete the connection with nmcli

  # nmcli con del dummy-dummy0

  Check the YAML WAS NOT removed from /etc/netplan

  You will see the error below in the NetworkManager's journal

  netplan_delete_connection: Cannot write output state: Read-only file
  system

  Add the PPA containing the fix and run the same test described above

  # add-apt-repository ppa:danilogondolfo/network-manager
  # apt update
  # apt upgrade

  Check that the YAML will be created when the connection is added and
  deleted and the connection is removed.

  [ Where problems could occur ]

  As the only change is a relaxation of the restrictions applied by systemd on 
the environment where Network Manager
  runs, we are not expecting any regression.

  As for the changes in the autopkgtest related to Netplan, they are
  passing on all architectures.

  Autopkgtests

  amd64 - 
https://autopkgtest.ubuntu.com/results/autopkgtest-mantic-danilogondolfo-network-manager/mantic/amd64/n/network-manager/20231023_175203_b2798@/log.gz
  ppc64 - 
https://autopkgtest.ubuntu.com/results/autopkgtest-mantic-danilogondolfo-network-manager/mantic/ppc64el/n/network-manager/20231023_182332_f0497@/log.gz
  s390x - 
https://autopkgtest.ubuntu.com/results/autopkgtest-mantic-danilogondolfo-network-manager/mantic/s390x/n/network-manager/20231023_190810_ced8d@/log.gz
  arm64 - 
https://autopkgtest.ubuntu.com/results/autopkgtest-mantic-danilogondolfo-network-manager/mantic/arm64/n/network-manager/20231024_084542_ac017@/log.gz
  armhf - 
https://autopkgtest.ubuntu.com/results/autopkgtest-mantic-danilogondolfo-network-manager/mantic/armhf/n/network-manager/20231024_083545_ac017@/log.gz

  [ Other Info ]

  
  --- Original description ---

  When a connection is deleted using any NM facility, libnetplan is
  failing to delete the YAML file. Because of that, the connection will
  be recreated when "netplan generate" runs again.

  This is probably being caused by a combination of two things. First,
  the NM's systemd unit has this setting "ProtectSystem=true", which
  will mount /usr as read-only for NM. Second, we migrated the default
  "00-network-manager-all.yaml" file to, /usr/lib/netplan recently [1].
  When libnetplan tries to open this file for writing, the open system
  fails with EROFS:

  ---
  22517 openat(AT_FDCWD, "/lib/netplan/00-network-manager-all.yaml", 
O_WRONLY|O_CREAT|O_TRUNC, 0600) = -1 EROFS (Read-only file system)
  22517 write(2, "netplan_delete_connection: Canno"..., 76) = 76
  ---

  [1] - https://launchpad.net/ubuntu/+source/ubuntu-settings/23.10.1

To manage notifications about

[Desktop-packages] [Bug 2041491] Re: Provide an option to avoid the yaml NM backend

2023-11-23 Thread Lukas Märdian

** Tags removed: rls-nn-incoming

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2041491

Title:
  Provide an option to avoid the yaml NM backend

Status in netplan.io package in Ubuntu:
  New
Status in network-manager package in Ubuntu:
  New

Bug description:
  Hi, recently netplan added support for a yaml NM backend:

  https://discourse.ubuntu.com/t/call-for-testing-networkmanager-yaml-
  settings/32420

  The rationale is that "the descriptive YAML layer is especially useful
  in cloud environments":

  
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/556

  It's great that you care about that user group!
  Please also care for the rest of us that do not use cloud environments!

  For example, I routinely review, clone, backup or even directly edit
  the /etc/NetworkManager/system-connections files in my desktops and
  servers, in all distributions.

  Having an Ubuntu-specific way to do things will make things harder for
  me. I will have to learn a new Ubuntu-specific syntax, develop scripts
  and methods to convert my connections between distributions, I will
  need to discover and report bugs in the netplan <=> nm mapping etc...

  I.e. Ubuntu is great for the cloud, and it's awesome that you want to provide 
a unified yaml-based experience for cloud-init etc.
  But Ubuntu is also great outside the cloud; please allow us to continue 
having a unified experience between distributions (i.e. directly using nm or 
systemd-networkd) without enforcing an Ubuntu-specific way of doing things 
(netplan) to us.

  For Ubuntu 24.04+, please provide an option to avoid the yaml NM
  backend, thank you very much!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/2041491/+subscriptions


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

[Desktop-packages] [Bug 2041491] Re: Provide an option to avoid the yaml NM backend

2023-10-30 Thread Lukas Märdian

Thank you for your thoughtful report!

This change was not just made to be useful in cloud environments, but
also is about unification of network configuration across the different
variants of Ubuntu (Desktop/Server/Core/Cloud/..), to improve the UX for
Ubuntu users. I understand this impacts the cross-distro compatibility
of our NetworkManager packaging.

If you want to manage your NM connection profiles manually, you could
place the keyfiles in /usr/lib/NetworkManager/system-connections/ and NM
will pick them up as before. But those connections would no be visible
to Netplan and any modifications through the NetworKManager tooling
(GUI, nmtui, nmcli, ...) would write the modifications to /etc/netplan/
instead of /etc/NetworkManager/system-connections/

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2041491

Title:
  Provide an option to avoid the yaml NM backend

Status in netplan.io package in Ubuntu:
  New
Status in network-manager package in Ubuntu:
  New

Bug description:
  Hi, recently netplan added support for a yaml NM backend:

  https://discourse.ubuntu.com/t/call-for-testing-networkmanager-yaml-
  settings/32420

  The rationale is that "the descriptive YAML layer is especially useful
  in cloud environments":

  
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/556

  It's great that you care about that user group!
  Please also care for the rest of us that do not use cloud environments!

  For example, I routinely review, clone, backup or even directly edit
  the /etc/NetworkManager/system-connections files in my desktops and
  servers, in all distributions.

  Having an Ubuntu-specific way to do things will make things harder for
  me. I will have to learn a new Ubuntu-specific syntax, develop scripts
  and methods to convert my connections between distributions, I will
  need to discover and report bugs in the netplan <=> nm mapping etc...

  I.e. Ubuntu is great for the cloud, and it's awesome that you want to provide 
a unified yaml-based experience for cloud-init etc.
  But Ubuntu is also great outside the cloud; please allow us to continue 
having a unified experience between distributions (i.e. directly using nm or 
systemd-networkd) without enforcing an Ubuntu-specific way of doing things 
(netplan) to us.

  For Ubuntu 24.04+, please provide an option to avoid the yaml NM
  backend, thank you very much!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/2041491/+subscriptions


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

[Desktop-packages] [Bug 2041491] Re: Provide an option to avoid the yaml NM backend

2023-10-30 Thread Lukas Märdian

** Also affects: netplan.io (Ubuntu)
   Importance: Undecided
   Status: New

** Tags added: netplan-everywhere

** Tags added: rls-nn-incoming

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2041491

Title:
  Provide an option to avoid the yaml NM backend

Status in netplan.io package in Ubuntu:
  New
Status in network-manager package in Ubuntu:
  New

Bug description:
  Hi, recently netplan added support for a yaml NM backend:

  https://discourse.ubuntu.com/t/call-for-testing-networkmanager-yaml-
  settings/32420

  The rationale is that "the descriptive YAML layer is especially useful
  in cloud environments":

  
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/556

  It's great that you care about that user group!
  Please also care for the rest of us that do not use cloud environments!

  For example, I routinely review, clone, backup or even directly edit
  the /etc/NetworkManager/system-connections files in my desktops and
  servers, in all distributions.

  Having an Ubuntu-specific way to do things will make things harder for
  me. I will have to learn a new Ubuntu-specific syntax, develop scripts
  and methods to convert my connections between distributions, I will
  need to discover and report bugs in the netplan <=> nm mapping etc...

  I.e. Ubuntu is great for the cloud, and it's awesome that you want to provide 
a unified yaml-based experience for cloud-init etc.
  But Ubuntu is also great outside the cloud; please allow us to continue 
having a unified experience between distributions (i.e. directly using nm or 
systemd-networkd) without enforcing an Ubuntu-specific way of doing things 
(netplan) to us.

  For Ubuntu 24.04+, please provide an option to avoid the yaml NM
  backend, thank you very much!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/2041491/+subscriptions


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

[Desktop-packages] [Bug 2040153] Re: Network Manager will not remove Netplan YAMLs when connections are deleted

2023-10-26 Thread Lukas Märdian

** Tags removed: foundations-todo

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2040153

Title:
  Network Manager will not remove Netplan YAMLs when connections are
  deleted

Status in netplan.io package in Ubuntu:
  Triaged
Status in network-manager package in Ubuntu:
  In Progress
Status in netplan.io source package in Mantic:
  Invalid
Status in network-manager source package in Mantic:
  Fix Released

Bug description:
  [ Impact ]

  Desktop users, or any users with YAML files in /usr/lib/netplan, can't delete
  Network Manager connections persistently. That means that, when the 
connection is
  deliberately deleted by the user, it will re-appear when the system is 
rebooted or
  netplan apply is executed.

  This is happening because the systemd service unit is setting the property 
"ProtectSystem"
  to true. Because of that, /usr is being presented to the Network Manager 
daemon as read-only.
  When connections are deleted, libnetplan will try to open its YAML files with 
writing permissions
  and will fail for files from /usr/lib/netplan. Even if the user hasn't added 
any files there manually,
  the file /usr/lib/netplan/00-network-manager-all.yaml will be installed by 
the package ubuntu-settings.

  This issue is fixed by allow-listing /usr/lib/netplan with 
ReadWritePaths=/usr/lib/netplan in systemd
  so the Network Manager's daemon will be able to write to that directory.

  This upload also improves the autopkgtests related to Netplan. Network 
Manager will be
  started by systemd, which ensures we are testing in the same environment 
conditions
  used by a desktop installation. It also adds a few more instances of 
connections deletions so
  we can test a bit more that YAML files are being removed. It also adds all 
the dependencies
  required by the test script (which sadly was causing the nm_netplan.py tests 
to be skipped).

  [ Test Plan ]

  Launch a new Mantic VM:

  $ lxc launch ubuntu:mantic --vm

  Install network-manager and ubuntu-settings:

  # apt install network-manager ubuntu-settings

  Run Netplan

  # netplan apply

  Create a dummy connection via nmcli:

  # nmcli con add type dummy connection.interface-name dummy0

  Check a new YAML will be created in /etc/netplan

  Delete the connection with nmcli

  # nmcli con del dummy-dummy0

  Check the YAML WAS NOT removed from /etc/netplan

  You will see the error below in the NetworkManager's journal

  netplan_delete_connection: Cannot write output state: Read-only file
  system

  Add the PPA containing the fix and run the same test described above

  # add-apt-repository ppa:danilogondolfo/network-manager
  # apt update
  # apt upgrade

  Check that the YAML will be created when the connection is added and
  deleted and the connection is removed.

  [ Where problems could occur ]

  As the only change is a relaxation of the restrictions applied by systemd on 
the environment where Network Manager
  runs, we are not expecting any regression.

  As for the changes in the autopkgtest related to Netplan, they are
  passing on all architectures.

  Autopkgtests

  amd64 - 
https://autopkgtest.ubuntu.com/results/autopkgtest-mantic-danilogondolfo-network-manager/mantic/amd64/n/network-manager/20231023_175203_b2798@/log.gz
  ppc64 - 
https://autopkgtest.ubuntu.com/results/autopkgtest-mantic-danilogondolfo-network-manager/mantic/ppc64el/n/network-manager/20231023_182332_f0497@/log.gz
  s390x - 
https://autopkgtest.ubuntu.com/results/autopkgtest-mantic-danilogondolfo-network-manager/mantic/s390x/n/network-manager/20231023_190810_ced8d@/log.gz
  arm64 - 
https://autopkgtest.ubuntu.com/results/autopkgtest-mantic-danilogondolfo-network-manager/mantic/arm64/n/network-manager/20231024_084542_ac017@/log.gz
  armhf - 
https://autopkgtest.ubuntu.com/results/autopkgtest-mantic-danilogondolfo-network-manager/mantic/armhf/n/network-manager/20231024_083545_ac017@/log.gz

  [ Other Info ]

  
  --- Original description ---

  When a connection is deleted using any NM facility, libnetplan is
  failing to delete the YAML file. Because of that, the connection will
  be recreated when "netplan generate" runs again.

  This is probably being caused by a combination of two things. First,
  the NM's systemd unit has this setting "ProtectSystem=true", which
  will mount /usr as read-only for NM. Second, we migrated the default
  "00-network-manager-all.yaml" file to, /usr/lib/netplan recently [1].
  When libnetplan tries to open this file for writing, the open system
  fails with EROFS:

  ---
  22517 openat(AT_FDCWD, "/lib/netplan/00-network-manager-all.yaml", 
O_WRONLY|O_CREAT|O_TRUNC, 0600) = -1 EROFS (Read-only file system)
  22517 write(2, "netplan_delete_connection: Canno"..., 76) = 76
  ---

  [1] - https://launchpad.net/ubuntu/+source/ubuntu-settings/23.10.1

To manage notifications about this bug go to:

[Desktop-packages] [Bug 2023183] Re: network-manager autokpgtest failure (nm.py)

2023-10-26 Thread Lukas Märdian

** Changed in: network-manager (Ubuntu Noble)
   Status: Confirmed => In Progress

** Changed in: network-manager (Ubuntu Noble)
 Assignee: (unassigned) => Lukas Märdian (slyon)

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2023183

Title:
  network-manager autokpgtest failure (nm.py)

Status in network-manager package in Ubuntu:
  In Progress
Status in network-manager source package in Lunar:
  Confirmed
Status in network-manager source package in Mantic:
  Confirmed
Status in network-manager source package in Noble:
  In Progress

Bug description:
  This fails only on arm64.

  https://autopkgtest.ubuntu.com/results/autopkgtest-
  lunar/lunar/arm64/n/network-manager/20230522_141200_71ac4@/log.gz

  To be determined if there is a bug in the package or linux kernel.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/2023183/+subscriptions


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

[Desktop-packages] [Bug 2023183] Re: network-manager autokpgtest failure (nm.py)

2023-10-26 Thread Lukas Märdian

Thank you for your investigation. This sounds very related to this
systemd/udev quirk:

https://github.com/canonical/netplan/commit/1413f0e7b8f4d068f817a009d998656de3224370

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2023183

Title:
  network-manager autokpgtest failure (nm.py)

Status in network-manager package in Ubuntu:
  In Progress
Status in network-manager source package in Lunar:
  Confirmed
Status in network-manager source package in Mantic:
  Confirmed
Status in network-manager source package in Noble:
  In Progress

Bug description:
  This fails only on arm64.

  https://autopkgtest.ubuntu.com/results/autopkgtest-
  lunar/lunar/arm64/n/network-manager/20230522_141200_71ac4@/log.gz

  To be determined if there is a bug in the package or linux kernel.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/2023183/+subscriptions


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

[Desktop-packages] [Bug 2040292] Re: network-manager SRU flags system for restart required but also restarted the service

** Tags removed: block-proposed-mantic

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2040292

Title:
  network-manager SRU flags system for restart required but also
  restarted the service

Status in network-manager package in Ubuntu:
  Triaged
Status in network-manager source package in Mantic:
  New

Bug description:
  [ Impact ]

   * During an upgrade (or installation) of the network-manager package, its 
debian/network-manager.postinst maintainer script restarts 
NetworkManager.service and also requests users to reboot their system.
   * It requests a reboot, by calling into 
/usr/share/update-notifier/notify-reboot-required and listing "network-manager" 
in /var/run/reboot-required.pkgs
   * Restarting the systemd service AND asking for a reboot isn't needed. Just 
the service restart is enough and we shouldn't ask for a reboot as that is bad 
UX

  [ Test Plan ]

   * Reboot your system (or clear /var/run/reboot-required.pkgs)
 echo "" | sudo tee /var/run/reboot-required.pkgs
   * Install network-manager from mantic-proposed
 apt install [--reinstall] -t mantic-proposed network-manager
   * Observe that the NetworkManager.service was restarted by this operation: 
"active (running) [...] 2 min ago"
 systemctl status Networkmanager.service
  ● NetworkManager.service - Network Manager
   Loaded: loaded (/lib/systemd/system/NetworkManager.service; enabled; 
preset: enabled)
   Active: active (running) since Wed 2023-10-25 15:21:27 CEST; 2min ago
 Docs: man:NetworkManager(8)
 Main PID: 3880250 (NetworkManager)
Tasks: 4 (limit: 28344)
   Memory: 6.1M
  CPU: 425ms
   CGroup: /system.slice/NetworkManager.service
   └─3880250 /usr/sbin/NetworkManager --no-daemon
   * Observe that network-manager was NOT written to 
/var/run/reboot-required.pkgs
 cat /var/run/reboot-required.pkgs
   * Observe that no GUI popped up asking you for a reboot because of 
NetworkManager

  [ Where problems could occur ]

   * This change is touching a maintainer script (.postinst)
   * Failures or syntax errors could leave the network-manager package 
unconfigured
   * It could break installation of the network-manager package

  [ Other Info ]
   
   * This SRU should probably just be staged, using `block-proposed-mantic` and 
bundled with the next upload.

  === original description ===

  After applying the network-manager SRU in mantic, I get a notification
  that a system restart is required to fully apply updates.

  This immediately raised a question, because I KNOW my network
  connection was restarted when the SRU was installed (I have a VPN that
  did not auto-reconnect).

  And I checked the state of the process - it was definitely restarted
  and is running from the binary currently on disk.

  The network-manager postinst has the following code:

  # request a reboot (NM tears down interfaces on restart
  # which is not the way we want to go)
  [ -x /usr/share/update-notifier/notify-reboot-required ] && \
  /usr/share/update-notifier/notify-reboot-required

  But the service restart is also happening. debian/rules currently has:

  override_dh_installsystemd:
  dh_installsystemd -pnetwork-manager --no-start 
NetworkManager-dispatcher.service NetworkManager-wait-online.service 
nm-priv-helper.service
  dh_installsystemd -pnetwork-manager --no-also NetworkManager.service

  No other systemd overrides. Nothing inhibits the restart of the
  service.

  It needs to be one or the other.  And if we're doing SRUs of network-
  manager, then this is bad UX for users applying their daily updates
  and should be fixed in SRU.

  ProblemType: Bug
  DistroRelease: Ubuntu 23.10
  Package: network-manager 1.44.2-1ubuntu1.1
  ProcVersionSignature: Ubuntu 6.5.0-9.9-generic 6.5.3
  Uname: Linux 6.5.0-9-generic x86_64
  NonfreeKernelModules: zfs
  ApportVersion: 2.27.0-0ubuntu5
  Architecture: amd64
  CasperMD5CheckResult: unknown
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Oct 24 08:19:38 2023
  InstallationDate: Installed on 2019-12-23 (1401 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
  RebootRequiredPkgs: Error: path contained symlinks.
  SourcePackage: network-manager
  UpgradeStatus: Upgraded to mantic on 2023-10-16 (8 days ago)
  nmcli-nm:
   RUNNING  VERSION  STATE  STARTUP  CONNECTIVITY  NETWORKING  WIFI-HW  
WIFI WWAN-HW  WWAN
   running  1.44.2   connected  started  full  enabled enabled  
enabled  missing  enabled

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/2040292/+subscriptions


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

[Desktop-packages] [Bug 2040292] Re: network-manager SRU flags system for restart required but also restarted the service

** Tags added: block-proposed-mantic

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2040292

Title:
  network-manager SRU flags system for restart required but also
  restarted the service

Status in network-manager package in Ubuntu:
  Triaged
Status in network-manager source package in Mantic:
  New

Bug description:
  [ Impact ]

   * During an upgrade (or installation) of the network-manager package, its 
debian/network-manager.postinst maintainer script restarts 
NetworkManager.service and also requests users to reboot their system.
   * It requests a reboot, by calling into 
/usr/share/update-notifier/notify-reboot-required and listing "network-manager" 
in /var/run/reboot-required.pkgs
   * Restarting the systemd service AND asking for a reboot isn't needed. Just 
the service restart is enough and we shouldn't ask for a reboot as that is bad 
UX

  [ Test Plan ]

   * Reboot your system (or clear /var/run/reboot-required.pkgs)
 echo "" | sudo tee /var/run/reboot-required.pkgs
   * Install network-manager from mantic-proposed
 apt install [--reinstall] -t mantic-proposed network-manager
   * Observe that the NetworkManager.service was restarted by this operation: 
"active (running) [...] 2 min ago"
 systemctl status Networkmanager.service
  ● NetworkManager.service - Network Manager
   Loaded: loaded (/lib/systemd/system/NetworkManager.service; enabled; 
preset: enabled)
   Active: active (running) since Wed 2023-10-25 15:21:27 CEST; 2min ago
 Docs: man:NetworkManager(8)
 Main PID: 3880250 (NetworkManager)
Tasks: 4 (limit: 28344)
   Memory: 6.1M
  CPU: 425ms
   CGroup: /system.slice/NetworkManager.service
   └─3880250 /usr/sbin/NetworkManager --no-daemon
   * Observe that network-manager was NOT written to 
/var/run/reboot-required.pkgs
 cat /var/run/reboot-required.pkgs
   * Observe that no GUI popped up asking you for a reboot because of 
NetworkManager

  [ Where problems could occur ]

   * This change is touching a maintainer script (.postinst)
   * Failures or syntax errors could leave the network-manager package 
unconfigured
   * It could break installation of the network-manager package

  [ Other Info ]
   
   * This SRU should probably just be staged, using `block-proposed-mantic` and 
bundled with the next upload.

  === original description ===

  After applying the network-manager SRU in mantic, I get a notification
  that a system restart is required to fully apply updates.

  This immediately raised a question, because I KNOW my network
  connection was restarted when the SRU was installed (I have a VPN that
  did not auto-reconnect).

  And I checked the state of the process - it was definitely restarted
  and is running from the binary currently on disk.

  The network-manager postinst has the following code:

  # request a reboot (NM tears down interfaces on restart
  # which is not the way we want to go)
  [ -x /usr/share/update-notifier/notify-reboot-required ] && \
  /usr/share/update-notifier/notify-reboot-required

  But the service restart is also happening. debian/rules currently has:

  override_dh_installsystemd:
  dh_installsystemd -pnetwork-manager --no-start 
NetworkManager-dispatcher.service NetworkManager-wait-online.service 
nm-priv-helper.service
  dh_installsystemd -pnetwork-manager --no-also NetworkManager.service

  No other systemd overrides. Nothing inhibits the restart of the
  service.

  It needs to be one or the other.  And if we're doing SRUs of network-
  manager, then this is bad UX for users applying their daily updates
  and should be fixed in SRU.

  ProblemType: Bug
  DistroRelease: Ubuntu 23.10
  Package: network-manager 1.44.2-1ubuntu1.1
  ProcVersionSignature: Ubuntu 6.5.0-9.9-generic 6.5.3
  Uname: Linux 6.5.0-9-generic x86_64
  NonfreeKernelModules: zfs
  ApportVersion: 2.27.0-0ubuntu5
  Architecture: amd64
  CasperMD5CheckResult: unknown
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Oct 24 08:19:38 2023
  InstallationDate: Installed on 2019-12-23 (1401 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
  RebootRequiredPkgs: Error: path contained symlinks.
  SourcePackage: network-manager
  UpgradeStatus: Upgraded to mantic on 2023-10-16 (8 days ago)
  nmcli-nm:
   RUNNING  VERSION  STATE  STARTUP  CONNECTIVITY  NETWORKING  WIFI-HW  
WIFI WWAN-HW  WWAN
   running  1.44.2   connected  started  full  enabled enabled  
enabled  missing  enabled

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/2040292/+subscriptions


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

[Desktop-packages] [Bug 2040292] Re: network-manager SRU flags system for restart required but also restarted the service

** Description changed:

+ [ Impact ]
+ 
+  * During an upgrade (or installation) of the network-manager package, its 
debian/network-manager.postinst maintainer script restarts 
NetworkManager.service and also requests users to reboot their system.
+  * It requests a reboot, by calling into 
/usr/share/update-notifier/notify-reboot-required and listing "network-manager" 
in /var/run/reboot-required.pkgs
+  * Restarting the systemd service AND asking for a reboot isn't needed. Just 
the service restart is enough and we shouldn't ask for a reboot as that is bad 
UX
+ 
+ [ Test Plan ]
+ 
+  * Reboot your system (or clear /var/run/reboot-required.pkgs)
+echo "" | sudo tee /var/run/reboot-required.pkgs
+  * Install network-manager from mantic-proposed
+apt install [--reinstall] -t mantic-proposed network-manager
+  * Observe that the NetworkManager.service was restarted by this operation: 
"active (running) [...] 2 min ago"
+systemctl status Networkmanager.service
+ ● NetworkManager.service - Network Manager
+  Loaded: loaded (/lib/systemd/system/NetworkManager.service; enabled; 
preset: enabled)
+  Active: active (running) since Wed 2023-10-25 15:21:27 CEST; 2min ago
+Docs: man:NetworkManager(8)
+Main PID: 3880250 (NetworkManager)
+   Tasks: 4 (limit: 28344)
+  Memory: 6.1M
+ CPU: 425ms
+  CGroup: /system.slice/NetworkManager.service
+  └─3880250 /usr/sbin/NetworkManager --no-daemon
+  * Observe that network-manager was NOT written to 
/var/run/reboot-required.pkgs
+cat /var/run/reboot-required.pkgs
+  * Observe that no GUI popped up asking you for a reboot because of 
NetworkManager
+ 
+ [ Where problems could occur ]
+ 
+  * This change is touching a maintainer script (.postinst)
+  * Failures or syntax errors could leave the network-manager package 
unconfigured
+  * It could break installation of the network-manager package
+ 
+ [ Other Info ]
+  
+  * This SRU should probably just be staged, using `block-proposed-mantic` and 
bundled with the next upload.
+ 
+ === original description ===
+ 
  After applying the network-manager SRU in mantic, I get a notification
  that a system restart is required to fully apply updates.
  
  This immediately raised a question, because I KNOW my network connection
  was restarted when the SRU was installed (I have a VPN that did not
  auto-reconnect).
  
  And I checked the state of the process - it was definitely restarted and
  is running from the binary currently on disk.
  
  The network-manager postinst has the following code:
  
- # request a reboot (NM tears down interfaces on restart
- # which is not the way we want to go)
- [ -x /usr/share/update-notifier/notify-reboot-required ] && \
- /usr/share/update-notifier/notify-reboot-required
+ # request a reboot (NM tears down interfaces on restart
+ # which is not the way we want to go)
+ [ -x /usr/share/update-notifier/notify-reboot-required ] && \
+ /usr/share/update-notifier/notify-reboot-required
  
  But the service restart is also happening. debian/rules currently has:
  
  override_dh_installsystemd:
- dh_installsystemd -pnetwork-manager --no-start 
NetworkManager-dispatcher.service NetworkManager-wait-online.service 
nm-priv-helper.service
- dh_installsystemd -pnetwork-manager --no-also NetworkManager.service
+ dh_installsystemd -pnetwork-manager --no-start 
NetworkManager-dispatcher.service NetworkManager-wait-online.service 
nm-priv-helper.service
+ dh_installsystemd -pnetwork-manager --no-also NetworkManager.service
  
  No other systemd overrides. Nothing inhibits the restart of the service.
  
  It needs to be one or the other.  And if we're doing SRUs of network-
  manager, then this is bad UX for users applying their daily updates and
  should be fixed in SRU.
  
  ProblemType: Bug
  DistroRelease: Ubuntu 23.10
  Package: network-manager 1.44.2-1ubuntu1.1
  ProcVersionSignature: Ubuntu 6.5.0-9.9-generic 6.5.3
  Uname: Linux 6.5.0-9-generic x86_64
  NonfreeKernelModules: zfs
  ApportVersion: 2.27.0-0ubuntu5
  Architecture: amd64
  CasperMD5CheckResult: unknown
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Oct 24 08:19:38 2023
  InstallationDate: Installed on 2019-12-23 (1401 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
  RebootRequiredPkgs: Error: path contained symlinks.
  SourcePackage: network-manager
  UpgradeStatus: Upgraded to mantic on 2023-10-16 (8 days ago)
  nmcli-nm:
-  RUNNING  VERSION  STATE  STARTUP  CONNECTIVITY  NETWORKING  WIFI-HW  
WIFI WWAN-HW  WWAN
-  running  1.44.2   connected  started  full  enabled enabled  
enabled  missing  enabled
+  RUNNING  VERSION  STATE  STARTUP  CONNECTIVITY  NETWORKING  WIFI-HW  
WIFI WWAN-HW  WWAN
+  running  1.44.2   connected  started  full  enabled enabled  
enabled  missing  enabled

-- 
You

[Desktop-packages] [Bug 2040292] Re: network-manager SRU flags system for restart required but also restarted the service

** Also affects: network-manager (Ubuntu Mantic)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2040292

Title:
  network-manager SRU flags system for restart required but also
  restarted the service

Status in network-manager package in Ubuntu:
  Triaged
Status in network-manager source package in Mantic:
  New

Bug description:
  After applying the network-manager SRU in mantic, I get a notification
  that a system restart is required to fully apply updates.

  This immediately raised a question, because I KNOW my network
  connection was restarted when the SRU was installed (I have a VPN that
  did not auto-reconnect).

  And I checked the state of the process - it was definitely restarted
  and is running from the binary currently on disk.

  The network-manager postinst has the following code:

  # request a reboot (NM tears down interfaces on restart
  # which is not the way we want to go)
  [ -x /usr/share/update-notifier/notify-reboot-required ] && \
  /usr/share/update-notifier/notify-reboot-required

  But the service restart is also happening. debian/rules currently has:

  override_dh_installsystemd:
  dh_installsystemd -pnetwork-manager --no-start 
NetworkManager-dispatcher.service NetworkManager-wait-online.service 
nm-priv-helper.service
  dh_installsystemd -pnetwork-manager --no-also NetworkManager.service

  No other systemd overrides. Nothing inhibits the restart of the
  service.

  It needs to be one or the other.  And if we're doing SRUs of network-
  manager, then this is bad UX for users applying their daily updates
  and should be fixed in SRU.

  ProblemType: Bug
  DistroRelease: Ubuntu 23.10
  Package: network-manager 1.44.2-1ubuntu1.1
  ProcVersionSignature: Ubuntu 6.5.0-9.9-generic 6.5.3
  Uname: Linux 6.5.0-9-generic x86_64
  NonfreeKernelModules: zfs
  ApportVersion: 2.27.0-0ubuntu5
  Architecture: amd64
  CasperMD5CheckResult: unknown
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Oct 24 08:19:38 2023
  InstallationDate: Installed on 2019-12-23 (1401 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
  RebootRequiredPkgs: Error: path contained symlinks.
  SourcePackage: network-manager
  UpgradeStatus: Upgraded to mantic on 2023-10-16 (8 days ago)
  nmcli-nm:
   RUNNING  VERSION  STATE  STARTUP  CONNECTIVITY  NETWORKING  WIFI-HW  
WIFI WWAN-HW  WWAN
   running  1.44.2   connected  started  full  enabled enabled  
enabled  missing  enabled

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/2040292/+subscriptions


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

[Desktop-packages] [Bug 2040153] Re: Network Manager will not remove Netplan YAMLs when connections are deleted

I can confirm this fixes the issue for me, too, using network-manager
1.44.2-1ubuntu1.2 from mantic-proposed.


$ sudo apt install -t mantic-proposed network-manager
[...]
$ LC_ALL=C apt list -i network-manager
Listing... Done
network-manager/mantic-proposed,now 1.44.2-1ubuntu1.2 amd64 [installed]


$ nmcli con add type dummy connection.interface-name dummy0
$ sudo cat /etc/netplan/90-NM-4189c63a-ecee-4a39-90f3-fffad2b96d0b.yaml 
network:
  version: 2
  dummy-devices:
NM-4189c63a-ecee-4a39-90f3-fffad2b96d0b:
  renderer: NetworkManager
  networkmanager:
uuid: "4189c63a-ecee-4a39-90f3-fffad2b96d0b"
name: "dummy-dummy0"
passthrough:
  connection.interface-name: "dummy0"
  dummy._: ""
  ipv4.method: "disabled"
  ipv6.addr-gen-mode: "default"
  ipv6.method: "disabled"
  ipv6.ip6-privacy: "-1"
  proxy._: ""
$ nmcli d show dummy0
GENERAL.DEVICE: dummy0
GENERAL.TYPE:   dummy
GENERAL.HWADDR: 32:89:DC:E0:74:2F
GENERAL.MTU:1500
GENERAL.STATE:  100 (verbunden)
GENERAL.CONNECTION: dummy-dummy0
GENERAL.CON-PATH:   
/org/freedesktop/NetworkManager/ActiveConnection/10
IP4.GATEWAY:--
IP6.GATEWAY:--

$ nmcli con del dummy-dummy0
$ LC_ALL=C nmcli d show dummy0
Error: Device 'dummy0' not found.
$ sudo LC_ALL=C cat 
/etc/netplan/90-NM-4189c63a-ecee-4a39-90f3-fffad2b96d0b.yaml 
cat: /etc/netplan/90-NM-4189c63a-ecee-4a39-90f3-fffad2b96d0b.yaml: No such file 
or directory
$ journalctl -u NetworkManager -e # I cannot spot any errors in here

** Tags removed: verification-needed-mantic
** Tags added: verification-done-mantic

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2040153

Title:
  Network Manager will not remove Netplan YAMLs when connections are
  deleted

Status in netplan.io package in Ubuntu:
  Triaged
Status in network-manager package in Ubuntu:
  In Progress
Status in netplan.io source package in Mantic:
  Invalid
Status in network-manager source package in Mantic:
  Fix Committed

Bug description:
  [ Impact ]

  Desktop users, or any users with YAML files in /usr/lib/netplan, can't delete
  Network Manager connections persistently. That means that, when the 
connection is
  deliberately deleted by the user, it will re-appear when the system is 
rebooted or
  netplan apply is executed.

  This is happening because the systemd service unit is setting the property 
"ProtectSystem"
  to true. Because of that, /usr is being presented to the Network Manager 
daemon as read-only.
  When connections are deleted, libnetplan will try to open its YAML files with 
writing permissions
  and will fail for files from /usr/lib/netplan. Even if the user hasn't added 
any files there manually,
  the file /usr/lib/netplan/00-network-manager-all.yaml will be installed by 
the package ubuntu-settings.

  This issue is fixed by allow-listing /usr/lib/netplan with 
ReadWritePaths=/usr/lib/netplan in systemd
  so the Network Manager's daemon will be able to write to that directory.

  This upload also improves the autopkgtests related to Netplan. Network 
Manager will be
  started by systemd, which ensures we are testing in the same environment 
conditions
  used by a desktop installation. It also adds a few more instances of 
connections deletions so
  we can test a bit more that YAML files are being removed. It also adds all 
the dependencies
  required by the test script (which sadly was causing the nm_netplan.py tests 
to be skipped).

  [ Test Plan ]

  Launch a new Mantic VM:

  $ lxc launch ubuntu:mantic --vm

  Install network-manager and ubuntu-settings:

  # apt install network-manager ubuntu-settings

  Run Netplan

  # netplan apply

  Create a dummy connection via nmcli:

  # nmcli con add type dummy connection.interface-name dummy0

  Check a new YAML will be created in /etc/netplan

  Delete the connection with nmcli

  # nmcli con del dummy-dummy0

  Check the YAML WAS NOT removed from /etc/netplan

  You will see the error below in the NetworkManager's journal

  netplan_delete_connection: Cannot write output state: Read-only file
  system

  Add the PPA containing the fix and run the same test described above

  # add-apt-repository ppa:danilogondolfo/network-manager
  # apt update
  # apt upgrade

  Check that the YAML will be created when the connection is added and
  deleted and the connection is removed.

  [ Where problems could occur ]

  As the only change is a relaxation of the restrictions applied by systemd on 
the environment where Network Manager
  runs, we are not expecting any regression.

  As for the changes in the autopkgtest related to Netplan, they are
  passing on all

[Desktop-packages] [Bug 2040153] Re: Network Manager will not remove Netplan YAMLs when connections are deleted

2023-10-24 Thread Lukas Märdian

I staged the changes for 'noble' in the 'ubuntu/master' branch:
https://git.launchpad.net/network-manager/log/

And uploaded the contents of the 'ubuntu-mantic' branch as an SRU:
https://git.launchpad.net/network-manager/log/?h=ubuntu-mantic
https://launchpad.net/ubuntu/mantic/+queue?queue_state=1

** Changed in: network-manager (Ubuntu Mantic)
   Status: Triaged => In Progress

** Changed in: network-manager (Ubuntu)
   Status: Triaged => In Progress

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2040153

Title:
  Network Manager will not remove Netplan YAMLs when connections are
  deleted

Status in netplan.io package in Ubuntu:
  Triaged
Status in network-manager package in Ubuntu:
  In Progress
Status in netplan.io source package in Mantic:
  Invalid
Status in network-manager source package in Mantic:
  In Progress

Bug description:
  [ Impact ]

  Desktop users, or any users with YAML files in /usr/lib/netplan, can't delete
  Network Manager connections persistently. That means that, when the 
connection is
  deliberately deleted by the user, it will re-appear when the system is 
rebooted or
  netplan apply is executed.

  This is happening because the systemd service unit is setting the property 
"ProtectSystem"
  to true. Because of that, /usr is being presented to the Network Manager 
daemon as read-only.
  When connections are deleted, libnetplan will try to open its YAML files with 
writing permissions
  and will fail for files from /usr/lib/netplan. Even if the user hasn't added 
any files there manually,
  the file /usr/lib/netplan/00-network-manager-all.yaml will be installed by 
the package ubuntu-settings.

  This issue is fixed by allow-listing /usr/lib/netplan with 
ReadWritePaths=/usr/lib/netplan in systemd
  so the Network Manager's daemon will be able to write to that directory.

  This upload also improves the autopkgtests related to Netplan. Network 
Manager will be
  started by systemd, which ensures we are testing in the same environment 
conditions
  used by a desktop installation. It also adds a few more instances of 
connections deletions so
  we can test a bit more that YAML files are being removed. It also adds all 
the dependencies
  required by the test script (which sadly was causing the nm_netplan.py tests 
to be skipped).

  [ Test Plan ]

  Launch a new Mantic VM:

  $ lxc launch ubuntu:mantic --vm

  Install network-manager and ubuntu-settings:

  # apt install network-manager ubuntu-settings

  Run Netplan

  # netplan apply

  Create a dummy connection via nmcli:

  # nmcli con add type dummy connection.interface-name dummy0

  Check a new YAML will be created in /etc/netplan

  Delete the connection with nmcli

  # nmcli con del dummy-dummy0

  Check the YAML WAS NOT removed from /etc/netplan

  You will see the error below in the NetworkManager's journal

  netplan_delete_connection: Cannot write output state: Read-only file
  system

  Add the PPA containing the fix and run the same test described above

  # add-apt-repository ppa:danilogondolfo/network-manager
  # apt update
  # apt upgrade

  Check that the YAML will be created when the connection is added and
  deleted and the connection is removed.

  [ Where problems could occur ]

  As the only change is a relaxation of the restrictions applied by systemd on 
the environment where Network Manager
  runs, we are not expecting any regression.

  As for the changes in the autopkgtest related to Netplan, they are
  passing on all architectures.

  Autopkgtests

  amd64 - 
https://autopkgtest.ubuntu.com/results/autopkgtest-mantic-danilogondolfo-network-manager/mantic/amd64/n/network-manager/20231023_175203_b2798@/log.gz
  ppc64 - 
https://autopkgtest.ubuntu.com/results/autopkgtest-mantic-danilogondolfo-network-manager/mantic/ppc64el/n/network-manager/20231023_182332_f0497@/log.gz
  s390x - 
https://autopkgtest.ubuntu.com/results/autopkgtest-mantic-danilogondolfo-network-manager/mantic/s390x/n/network-manager/20231023_190810_ced8d@/log.gz
  arm64 - 
https://autopkgtest.ubuntu.com/results/autopkgtest-mantic-danilogondolfo-network-manager/mantic/arm64/n/network-manager/20231024_084542_ac017@/log.gz
  armhf - 
https://autopkgtest.ubuntu.com/results/autopkgtest-mantic-danilogondolfo-network-manager/mantic/armhf/n/network-manager/20231024_083545_ac017@/log.gz

  [ Other Info ]

  
  --- Original description ---

  When a connection is deleted using any NM facility, libnetplan is
  failing to delete the YAML file. Because of that, the connection will
  be recreated when "netplan generate" runs again.

  This is probably being caused by a combination of two things. First,
  the NM's systemd unit has this setting "ProtectSystem=true", which
  will mount /usr as read-only for NM. Second, we migrated the default
  "00-network-manager-all.yaml" file to, /usr/lib/netplan recently [1].
  When

[Desktop-packages] [Bug 2040153] Re: Network Manager will not remove Netplan YAMLs when connections are deleted

2023-10-24 Thread Lukas Märdian

** Changed in: netplan.io (Ubuntu Mantic)
   Status: Triaged => Invalid

** Changed in: netplan.io (Ubuntu Mantic)
   Importance: Critical => Medium

** Changed in: netplan.io (Ubuntu)
   Importance: Critical => Medium

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2040153

Title:
  Network Manager will not remove Netplan YAMLs when connections are
  deleted

Status in netplan.io package in Ubuntu:
  Triaged
Status in network-manager package in Ubuntu:
  Triaged
Status in netplan.io source package in Mantic:
  Invalid
Status in network-manager source package in Mantic:
  Triaged

Bug description:
  When a connection is deleted using any NM facility, libnetplan is
  failing to delete the YAML file. Because of that, the connection will
  be recreated when "netplan generate" runs again.

  This is probably being caused by a combination of two things. First,
  the NM's systemd unit has this setting "ProtectSystem=true", which
  will mount /usr as read-only for NM. Second, we migrated the default
  "00-network-manager-all.yaml" file to, /usr/lib/netplan recently [1].
  When libnetplan tries to open this file for writing, the open system
  fails with EROFS:

  ---
  22517 openat(AT_FDCWD, "/lib/netplan/00-network-manager-all.yaml", 
O_WRONLY|O_CREAT|O_TRUNC, 0600) = -1 EROFS (Read-only file system)
  22517 write(2, "netplan_delete_connection: Canno"..., 76) = 76
  ---

  
  [1] - https://launchpad.net/ubuntu/+source/ubuntu-settings/23.10.1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/2040153/+subscriptions


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

[Desktop-packages] [Bug 2040153] Re: Network Manager will not remove Netplan YAMLs when connections are deleted

2023-10-23 Thread Lukas Märdian

** Tags added: foundations-todo

** Changed in: netplan.io (Ubuntu Mantic)
   Status: New => Triaged

** Changed in: network-manager (Ubuntu Mantic)
   Status: New => Triaged

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2040153

Title:
  Network Manager will not remove Netplan YAMLs when connections are
  deleted

Status in netplan.io package in Ubuntu:
  Triaged
Status in network-manager package in Ubuntu:
  Triaged
Status in netplan.io source package in Mantic:
  Triaged
Status in network-manager source package in Mantic:
  Triaged

Bug description:
  When a connection is deleted using any NM facility, libnetplan is
  failing to delete the YAML file. Because of that, the connection will
  be recreated when "netplan generate" runs again.

  This is probably being caused by a combination of two things. First,
  the NM's systemd unit has this setting "ProtectSystem=true", which
  will mount /usr as read-only for NM. Second, we migrated the default
  "00-network-manager-all.yaml" file to, /usr/lib/netplan recently [1].
  When libnetplan tries to open this file for writing, the open system
  fails with EROFS:

  ---
  22517 openat(AT_FDCWD, "/lib/netplan/00-network-manager-all.yaml", 
O_WRONLY|O_CREAT|O_TRUNC, 0600) = -1 EROFS (Read-only file system)
  22517 write(2, "netplan_delete_connection: Canno"..., 76) = 76
  ---

  
  [1] - https://launchpad.net/ubuntu/+source/ubuntu-settings/23.10.1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/2040153/+subscriptions


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

[Desktop-packages] [Bug 2039503] Re: package network-manager 1.44.2-1ubuntu1 failed to install/upgrade: installed network-manager package post-installation script subprocess returned error exit status

2023-10-18 Thread Lukas Märdian

I tested network-manager 1.44.2-1ubuntu1.1 inside a Mantic LXD
container. Package installation/upgrade and Netplan migration of (valid)
connection profiles worked nicely, according to the "Test Plan":


# Previous version of NM is installed
root@mm-nm-sru:~# dpkg -l network-manager
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ NameVersion Architecture Description
+++-===-===--=
ii  network-manager 1.44.2-1ubuntu1 amd64network management framework 
(daemon and userspace tools)

# Creating test files
root@mm-nm-sru:~# cat /etc/NetworkManager/system-connections/UPTOWN.guests
[connection]
id=UPTOWN.guests
uuid=491fa5c8-68ef-4140-8679-dca422f5c262
type=wifi

[wifi]
ssid=UPTOWN.guests
mode=infrastructure
mac-address=E0:9D:31:09:84:54

[ipv6]
method=auto

[ipv4]
method=auto
root@mm-nm-sru:~# cat /etc/NetworkManager/system-connections/aaaUPTOWN
[connection]
id=aaaUPTOWN
uuid=491fa5c8-68ef---dca422f5c262
type=wifi

[wifi]
ssid=aaaUPTOWN
mode=infrastructure
mac-address=E0:9D:31:09:84:54

[ipv6]
method=auto

[ipv4]
method=auto
root@mm-nm-sru:~# sudo chmod 600 /etc/NetworkManager/system-connections/*UPTOWN*

# Valid connection profiles are loaded into the old NM version as keyfiles in 
/etc/NetworkManager/
root@mm-nm-sru:~# ls -la /etc/NetworkManager/system-connections/
total 16
drwxr-xr-x 2 root root 4096 Oct 18 13:11 .
drwxr-xr-x 7 root root 4096 Oct 18 13:11 ..
-rw--- 1 root root  199 Oct 18 13:11 UPTOWN.guests
-rw--- 1 root root  191 Oct 18 13:11 aaaUPTOWN
root@mm-nm-sru:~# sudo nmcli con reload  
root@mm-nm-sru:~# nmcli c
NAME   UUID  TYPE  DEVICE 
aaaUPTOWN  491fa5c8-68ef---dca422f5c262  wifi  -- 


# Upgrade to SRU version of NetworkManager
root@mm-nm-sru:~# vim /etc/apt/sources.list # enable -proposed
root@mm-nm-sru:~# apt update && apt install -t mantic-proposed network-manager
Hit:1 http://archive.ubuntu.com/ubuntu mantic InRelease
Hit:2 http://archive.ubuntu.com/ubuntu mantic-updates InRelease
Get:3 http://archive.ubuntu.com/ubuntu mantic-proposed InRelease [256 kB]
Hit:4 http://security.ubuntu.com/ubuntu mantic-security InRelease   
 
Hit:5 http://archive.ubuntu.com/ubuntu mantic-backports InRelease
Get:6 http://archive.ubuntu.com/ubuntu mantic-proposed/main amd64 Packages 
[9428 B]
Get:7 http://archive.ubuntu.com/ubuntu mantic-proposed/main Translation-en 
[3480 B]
Get:8 http://archive.ubuntu.com/ubuntu mantic-proposed/main amd64 DEP-11 
Metadata [7604 B]
Get:9 http://archive.ubuntu.com/ubuntu mantic-proposed/main amd64 c-n-f 
Metadata [292 B]
Get:10 http://archive.ubuntu.com/ubuntu mantic-proposed/restricted amd64 c-n-f 
Metadata [116 B]
Fetched 277 kB in 1s (532 kB/s)  
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
3 packages can be upgraded. Run 'apt list --upgradable' to see them.
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  libnm0
Suggested packages:
  avahi-autoipd libteam-utils
The following packages will be upgraded:
  libnm0 network-manager
2 upgraded, 0 newly installed, 0 to remove and 5 not upgraded.
Need to get 2809 kB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] 
Get:1 http://archive.ubuntu.com/ubuntu mantic-proposed/main amd64 
network-manager amd64 1.44.2-1ubuntu1.1 [2331 kB]
Get:2 http://archive.ubuntu.com/ubuntu mantic-proposed/main amd64 libnm0 amd64 
1.44.2-1ubuntu1.1 [478 kB]
Fetched 2809 kB in 1s (2511 kB/s)
(Reading database ... 33906 files and directories currently installed.)
Preparing to unpack .../network-manager_1.44.2-1ubuntu1.1_amd64.deb ...
Unpacking network-manager (1.44.2-1ubuntu1.1) over (1.44.2-1ubuntu1) ...
Preparing to unpack .../libnm0_1.44.2-1ubuntu1.1_amd64.deb ...
Unpacking libnm0:amd64 (1.44.2-1ubuntu1.1) over (1.44.2-1ubuntu1) ...
Setting up libnm0:amd64 (1.44.2-1ubuntu1.1) ...

#
# Here is the relevant NetworkManager Netplan migration.
# The invalid UPTOWN.guests file is skipped
# The valid aaaUPTOWN profile is migrated
#
Setting up network-manager (1.44.2-1ubuntu1.1) ...
Error: 491fa5c8-68ef-4140-8679-dca422f5c262 - no such connection profile.
SKIP: UPTOWN.guests (491fa5c8-68ef-4140-8679-dca422f5c262) unknown to 
NetworkManager.
Migrating aaaUPTOWN (491fa5c8-68ef---dca422f5c262) to /etc/netplan
Processing triggers for dbus (1.14.10-1ubuntu1) ...
Processing triggers for libc-bin (2.38-1ubuntu6) ...
Processing triggers for man-db (2.11.2-3) ...
Scanning processes...

[Desktop-packages] [Bug 2039503] Re: package network-manager 1.44.2-1ubuntu1 failed to install/upgrade: installed network-manager package post-installation script subprocess returned error exit status

2023-10-18 Thread Lukas Märdian

After restoring git history for bug #2038439 I've now uploaded this SRU
into Mantic, using the `ubuntu-mantic` branch (tag:
ubuntu/1.44.2-1ubuntu1.1):

https://launchpad.net/ubuntu/mantic/+queue?queue_state=1_text=network-
manager

** Description changed:

  [ Impact ]
  
   * A failure to query nmcli will fail the network-manager.postinst
  maintainer script (using "set -e")
  
   * This will make the package installation/upgrade fail
  
   * The fix catches the error on "ORIG_NAME=$(nmcli --get-values
  connection.id con show "$UUID")" and skips the corresponding keyfile
  with a warning message
  
  [ Test Plan ]
  
  $ sudo vim /etc/NetworkManager/system-connections/UPTOWN.guests # bad file
  [connection]
  id=UPTOWN.guests
  uuid=491fa5c8-68ef-4140-8679-dca422f5c262
  type=wifi
  
  [wifi]
  ssid=UPTOWN.guests
  mode=infrastructure
  mac-address=E0:9D:31:09:84:54
  
  [ipv6]
  method=auto
  
  [ipv4]
  method=auto
  
  $ sudo vim /etc/NetworkManager/system-connections/aaaUPTOWN # good file
  [connection]
  id=aaaUPTOWN
  uuid=491fa5c8-68ef---dca422f5c262
  type=wifi
  
  [wifi]
  ssid=aaaUPTOWN
  mode=infrastructure
  mac-address=E0:9D:31:09:84:54
  
  [ipv6]
  method=auto
  
  [ipv4]
  method=auto
  
  $ sudo chmod 600 /etc/NetworkManager/system-connections/*UPTOWN*
  $ sudo nmcli con reload
  $ ls -la /etc/NetworkManager/system-connections/
  total 32
  drwxr-xr-x 2 root root 12288 Oct 17 17:51 ./
  drwxr-xr-x 7 root root 12288 Oct 17 17:46 ../
  -rw--- 1 root root   199 Oct 17 17:05 UPTOWN.guests
  -rw--- 1 root root   191 Oct 17 17:46 aaaUPTOWN
  
  # Install network-manager from proposed
- $ apt update && apt install -t mantic-proposed network-manager # version 
1.44.0-1ubuntu2.1
+ $ apt update && apt install -t mantic-proposed network-manager # version 
1.44.2-1ubuntu1.1
  
  # Verify you don't see an error like this, breaking the pkg install
  Error: 491fa5c8-68ef-4140-8679-dca422f5c262 - no such connection profile.
  dpkg: error processing package network-manager (--configure):
   installed network-manager package post-installation script subprocess 
returned error exit status 10
  
  # Verify you see a migration log like this and the package installation is 
successful:
  Error: 491fa5c8-68ef-4140-8679-dca422f5c262 - no such connection profile.
  SKIP: UPTOWN.guests (491fa5c8-68ef-4140-8679-dca422f5c262) unknown to 
NetworkManager.
  Migrating aaaUPTOWN (491fa5c8-68ef---dca422f5c262) to /etc/netplan
  $ echo $?
  0
  
  # Verify the good profile got migrated, while the bad one remains:
  $ sudo grep -RH UPTOWN /etc/netplan/
  /etc/netplan/90-NM-491fa5c8-68ef---dca422f5c262.yaml:
"aaaUPTOWN":
  /etc/netplan/90-NM-491fa5c8-68ef---dca422f5c262.yaml:
name: "aaaUPTOWN"
  /etc/netplan/90-NM-491fa5c8-68ef---dca422f5c262.yaml:name: 
"aaaUPTOWN"
  $ ls -la /etc/NetworkManager/system-connections/
  insgesamt 28
  drwxr-xr-x 2 root root 12288 Okt 17 18:03 .
  drwxr-xr-x 7 root root 12288 Okt 17 17:46 ..
  -rw--- 1 root root   199 Okt 17 17:05 UPTOWN.guests
  
  [ Where problems could occur ]
  
   * This is touching NetworkManager's maintainer script
-  * Breaking it could lead to a broken/unconfigured NetworkManager package
-  * This could render a machine's networking unusable
-  * It could break distribution upgrades on package install/configure failure
+  * Breaking it could lead to a broken/unconfigured NetworkManager package
+  * This could render a machine's networking unusable
+  * It could break distribution upgrades on package install/configure failure
  
  [ Other Info ]
  
   * Linting was used to validate the maintainer script:
-shellcheck --shell=sh debian/network-manager.postinst
+    shellcheck --shell=sh debian/network-manager.postinst
  
  === original bug description ===
  
  lunar to mantic upgrade, exciting to see output from network-manager
  postinst migrating connections to /etc/netplan one by one.  But then:
  
  Error: 491fa5c8-68ef-4140-8679-dca422f5c262 - no such connection profile.
  dpkg: error processing package network-manager (--configure):
   installed network-manager package post-installation script subprocess 
returned error exit status 10
  
  That UUID appears in a file /etc/NetworkManager/system-
  connections/UPTOWN.guests that hasn't been touched since 2015.
  
  Contents of the file were:
  
  [connection]
  id=UPTOWN.guests
  uuid=491fa5c8-68ef-4140-8679-dca422f5c262
  type=wifi
  
  [wifi]
  ssid=UPTOWN.guests
  mode=infrastructure
  mac-address=E0:9D:31:09:84:54
  
  [ipv6]
  method=auto
  
  [ipv4]
  method=auto
  
  I've removed it from disk and the migration continued to completion.
  
  Then I got another failure on:
  
  [connection]
  id=belkin.1e4.guests
  uuid=2c77e512-f3e3-4238-b401-c94559cc6db0
  type=802-11-wireless
  
  [802-11-wireless]
  ssid=belkin.1e4.guests
  mode=infrastructure
  mac-address=00:24:D7:1F:EA:20
  
  [ipv6]
  method=auto
  
  [ipv4]

[Desktop-packages] [Bug 2039503] Re: package network-manager 1.44.2-1ubuntu1 failed to install/upgrade: installed network-manager package post-installation script subprocess returned error exit status

The bugfix was staged for the "devel" series, as the archive is still
frozen: https://git.launchpad.net/network-manager/log/

I'm uploading this into Mantic: https://git.launchpad.net/network-
manager/log/?h=ubuntu/mantic

** Description changed:

+ [ Impact ]
+ 
+  * A failure to query nmcli will fail the network-manager.postinst
+ maintainer script (using "set -e")
+ 
+  * This will make the package installation/upgrade fail
+ 
+  * The fix catches the error on "ORIG_NAME=$(nmcli --get-values
+ connection.id con show "$UUID")" and skips the corresponding keyfile
+ with a warning message
+ 
+ [ Test Plan ]
+ 
+ $ sudo vim /etc/NetworkManager/system-connections/UPTOWN.guests # bad file
+ [connection]
+ id=UPTOWN.guests
+ uuid=491fa5c8-68ef-4140-8679-dca422f5c262
+ type=wifi
+ 
+ [wifi]
+ ssid=UPTOWN.guests
+ mode=infrastructure
+ mac-address=E0:9D:31:09:84:54
+ 
+ [ipv6]
+ method=auto
+ 
+ [ipv4]
+ method=auto
+ 
+ $ sudo vim /etc/NetworkManager/system-connections/aaaUPTOWN # good file
+ [connection]
+ id=aaaUPTOWN
+ uuid=491fa5c8-68ef---dca422f5c262
+ type=wifi
+ 
+ [wifi]
+ ssid=aaaUPTOWN
+ mode=infrastructure
+ mac-address=E0:9D:31:09:84:54
+ 
+ [ipv6]
+ method=auto
+ 
+ [ipv4]
+ method=auto
+ 
+ $ sudo chmod 600 /etc/NetworkManager/system-connections/*UPTOWN*
+ $ sudo nmcli con reload
+ $ ls -la /etc/NetworkManager/system-connections/
+ total 32
+ drwxr-xr-x 2 root root 12288 Oct 17 17:51 ./
+ drwxr-xr-x 7 root root 12288 Oct 17 17:46 ../
+ -rw--- 1 root root   199 Oct 17 17:05 UPTOWN.guests
+ -rw--- 1 root root   191 Oct 17 17:46 aaaUPTOWN
+ 
+ # Install network-manager from proposed
+ $ apt update && apt install -t mantic-proposed network-manager # version 
1.44.0-1ubuntu2.1
+ 
+ # Verify you don't see an error like this, breaking the pkg install
+ Error: 491fa5c8-68ef-4140-8679-dca422f5c262 - no such connection profile.
+ dpkg: error processing package network-manager (--configure):
+  installed network-manager package post-installation script subprocess 
returned error exit status 10
+ 
+ # Verify you see a migration log like this and the package installation is 
successful:
+ Error: 491fa5c8-68ef-4140-8679-dca422f5c262 - no such connection profile.
+ SKIP: UPTOWN.guests (491fa5c8-68ef-4140-8679-dca422f5c262) unknown to 
NetworkManager.
+ Migrating aaaUPTOWN (491fa5c8-68ef---dca422f5c262) to /etc/netplan
+ $ echo $?
+ 0
+ 
+ # Verify the good profile got migrated, while the bad one remains:
+ $ sudo grep -RH UPTOWN /etc/netplan/
+ /etc/netplan/90-NM-491fa5c8-68ef---dca422f5c262.yaml:
"aaaUPTOWN":
+ /etc/netplan/90-NM-491fa5c8-68ef---dca422f5c262.yaml:
name: "aaaUPTOWN"
+ /etc/netplan/90-NM-491fa5c8-68ef---dca422f5c262.yaml:name: 
"aaaUPTOWN"
+ $ ls -la /etc/NetworkManager/system-connections/
+ insgesamt 28
+ drwxr-xr-x 2 root root 12288 Okt 17 18:03 .
+ drwxr-xr-x 7 root root 12288 Okt 17 17:46 ..
+ -rw--- 1 root root   199 Okt 17 17:05 UPTOWN.guests
+ 
+ 
+ [ Where problems could occur ]
+ 
+  * Think about what the upload changes in the software. Imagine the change is
+wrong or breaks something else: how would this show up?
+ 
+  * It is assumed that any SRU candidate patch is well-tested before
+upload and has a low overall risk of regression, but it's important
+to make the effort to think about what ''could'' happen in the
+event of a regression.
+ 
+  * This must '''never''' be "None" or "Low", or entirely an argument as to why
+your upload is low risk.
+ 
+  * This both shows the SRU team that the risks have been considered,
+and provides guidance to testers in regression-testing the SRU.
+ 
+ [ Other Info ]
+  
+  * Anything else you think is useful to include
+  * Anticipate questions from users, SRU, +1 maintenance, security teams and 
the Technical Board
+  * and address these questions in advance
+ 
+ === original bug description ===
+ 
  lunar to mantic upgrade, exciting to see output from network-manager
  postinst migrating connections to /etc/netplan one by one.  But then:
  
  Error: 491fa5c8-68ef-4140-8679-dca422f5c262 - no such connection profile.
  dpkg: error processing package network-manager (--configure):
-  installed network-manager package post-installation script subprocess 
returned error exit status 10
+  installed network-manager package post-installation script subprocess 
returned error exit status 10
  
  That UUID appears in a file /etc/NetworkManager/system-
  connections/UPTOWN.guests that hasn't been touched since 2015.
  
  Contents of the file were:
  
  [connection]
  id=UPTOWN.guests
  uuid=491fa5c8-68ef-4140-8679-dca422f5c262
  type=wifi
  
  [wifi]
  ssid=UPTOWN.guests
  mode=infrastructure
  mac-address=E0:9D:31:09:84:54
  
  [ipv6]
  method=auto
  
  [ipv4]
  method=auto
- 
  
  I've removed it from disk and the migration continued to completion.
  
  Then I got another failure on:
  
  [connection]
  id=belkin.1e4.guests

[Desktop-packages] [Bug 2039503] Re: package network-manager 1.44.2-1ubuntu1 failed to install/upgrade: installed network-manager package post-installation script subprocess returned error exit status

Right. The .guests suffix seems to be a problem here. But I don't know
which suffixes are accepted/ignored now and in the future, so I'd avoid
changing file names, as that will probably get us into other issues down
the road (e.g. overwriting an already existing file of that new name).

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2039503

Title:
  package network-manager 1.44.2-1ubuntu1 failed to install/upgrade:
  installed network-manager package post-installation script subprocess
  returned error exit status 10

Status in network-manager package in Ubuntu:
  New
Status in network-manager source package in Mantic:
  New

Bug description:
  [ Impact ]

   * A failure to query nmcli will fail the network-manager.postinst
  maintainer script (using "set -e")

   * This will make the package installation/upgrade fail

   * The fix catches the error on "ORIG_NAME=$(nmcli --get-values
  connection.id con show "$UUID")" and skips the corresponding keyfile
  with a warning message

  [ Test Plan ]

  $ sudo vim /etc/NetworkManager/system-connections/UPTOWN.guests # bad file
  [connection]
  id=UPTOWN.guests
  uuid=491fa5c8-68ef-4140-8679-dca422f5c262
  type=wifi

  [wifi]
  ssid=UPTOWN.guests
  mode=infrastructure
  mac-address=E0:9D:31:09:84:54

  [ipv6]
  method=auto

  [ipv4]
  method=auto

  $ sudo vim /etc/NetworkManager/system-connections/aaaUPTOWN # good file
  [connection]
  id=aaaUPTOWN
  uuid=491fa5c8-68ef---dca422f5c262
  type=wifi

  [wifi]
  ssid=aaaUPTOWN
  mode=infrastructure
  mac-address=E0:9D:31:09:84:54

  [ipv6]
  method=auto

  [ipv4]
  method=auto

  $ sudo chmod 600 /etc/NetworkManager/system-connections/*UPTOWN*
  $ sudo nmcli con reload
  $ ls -la /etc/NetworkManager/system-connections/
  total 32
  drwxr-xr-x 2 root root 12288 Oct 17 17:51 ./
  drwxr-xr-x 7 root root 12288 Oct 17 17:46 ../
  -rw--- 1 root root   199 Oct 17 17:05 UPTOWN.guests
  -rw--- 1 root root   191 Oct 17 17:46 aaaUPTOWN

  # Install network-manager from proposed
  $ apt update && apt install -t mantic-proposed network-manager # version 
1.44.0-1ubuntu2.1

  # Verify you don't see an error like this, breaking the pkg install
  Error: 491fa5c8-68ef-4140-8679-dca422f5c262 - no such connection profile.
  dpkg: error processing package network-manager (--configure):
   installed network-manager package post-installation script subprocess 
returned error exit status 10

  # Verify you see a migration log like this and the package installation is 
successful:
  Error: 491fa5c8-68ef-4140-8679-dca422f5c262 - no such connection profile.
  SKIP: UPTOWN.guests (491fa5c8-68ef-4140-8679-dca422f5c262) unknown to 
NetworkManager.
  Migrating aaaUPTOWN (491fa5c8-68ef---dca422f5c262) to /etc/netplan
  $ echo $?
  0

  # Verify the good profile got migrated, while the bad one remains:
  $ sudo grep -RH UPTOWN /etc/netplan/
  /etc/netplan/90-NM-491fa5c8-68ef---dca422f5c262.yaml:
"aaaUPTOWN":
  /etc/netplan/90-NM-491fa5c8-68ef---dca422f5c262.yaml:
name: "aaaUPTOWN"
  /etc/netplan/90-NM-491fa5c8-68ef---dca422f5c262.yaml:name: 
"aaaUPTOWN"
  $ ls -la /etc/NetworkManager/system-connections/
  insgesamt 28
  drwxr-xr-x 2 root root 12288 Okt 17 18:03 .
  drwxr-xr-x 7 root root 12288 Okt 17 17:46 ..
  -rw--- 1 root root   199 Okt 17 17:05 UPTOWN.guests

  
  [ Where problems could occur ]

   * Think about what the upload changes in the software. Imagine the change is
 wrong or breaks something else: how would this show up?

   * It is assumed that any SRU candidate patch is well-tested before
 upload and has a low overall risk of regression, but it's important
 to make the effort to think about what ''could'' happen in the
 event of a regression.

   * This must '''never''' be "None" or "Low", or entirely an argument as to why
 your upload is low risk.

   * This both shows the SRU team that the risks have been considered,
 and provides guidance to testers in regression-testing the SRU.

  [ Other Info ]
   
   * Anything else you think is useful to include
   * Anticipate questions from users, SRU, +1 maintenance, security teams and 
the Technical Board
   * and address these questions in advance

  === original bug description ===

  lunar to mantic upgrade, exciting to see output from network-manager
  postinst migrating connections to /etc/netplan one by one.  But then:

  Error: 491fa5c8-68ef-4140-8679-dca422f5c262 - no such connection profile.
  dpkg: error processing package network-manager (--configure):
   installed network-manager package post-installation script subprocess 
returned error exit status 10

  That UUID appears in a file /etc/NetworkManager/system-
  connections/UPTOWN.guests that hasn't been touched since 2015.

  Contents of the file were:

  [connection]
  id=UPTOWN.guests

[Desktop-packages] [Bug 2007702] Re: Deb version numbering is misleading

Thank you for this suggestion.
Even though bumping the epoch is a very big hammer, it sounds very sensible to 
me.
The patch is looking mostly good, too.

But I wonder if we should rather change the version number to
"2:1snap1-0ubuntu1", in order to use a similar format as we have on
Firefox (LP: #1892724)? What do you think?

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to chromium-browser in Ubuntu.
https://bugs.launchpad.net/bugs/2007702

Title:
  Deb version numbering is misleading

Status in chromium-browser package in Ubuntu:
  Triaged

Bug description:
  For Ubuntu >= Focal the transitional debs are frozen at the version
  number 1:85...

  This might make one think[1][2] that it will install a critically
  outdated Chromium while it does not, because it installs the snap.

  [1] 
https://answers.launchpad.net/ubuntu/+source/chromium-browser/+question/702591
  [2] https://askubuntu.com/q/1420925

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/2007702/+subscriptions


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

[Desktop-packages] [Bug 2039503] Re: package network-manager 1.44.2-1ubuntu1 failed to install/upgrade: installed network-manager package post-installation script subprocess returned error exit status

NM can load keyfiles without any suffix, AFAIR. With my proposed patch
it would migrate any keyfiles that are actually loaded by NM, skipping
the other. We should not try to make it load (re-activate) old keyfiles,
which NM isn't loading anymore itself, by renaming them.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2039503

Title:
  package network-manager 1.44.2-1ubuntu1 failed to install/upgrade:
  installed network-manager package post-installation script subprocess
  returned error exit status 10

Status in network-manager package in Ubuntu:
  New
Status in network-manager source package in Mantic:
  New

Bug description:
  lunar to mantic upgrade, exciting to see output from network-manager
  postinst migrating connections to /etc/netplan one by one.  But then:

  Error: 491fa5c8-68ef-4140-8679-dca422f5c262 - no such connection profile.
  dpkg: error processing package network-manager (--configure):
   installed network-manager package post-installation script subprocess 
returned error exit status 10

  That UUID appears in a file /etc/NetworkManager/system-
  connections/UPTOWN.guests that hasn't been touched since 2015.

  Contents of the file were:

  [connection]
  id=UPTOWN.guests
  uuid=491fa5c8-68ef-4140-8679-dca422f5c262
  type=wifi

  [wifi]
  ssid=UPTOWN.guests
  mode=infrastructure
  mac-address=E0:9D:31:09:84:54

  [ipv6]
  method=auto

  [ipv4]
  method=auto

  
  I've removed it from disk and the migration continued to completion.

  Then I got another failure on:

  [connection]
  id=belkin.1e4.guests
  uuid=2c77e512-f3e3-4238-b401-c94559cc6db0
  type=802-11-wireless

  [802-11-wireless]
  ssid=belkin.1e4.guests
  mode=infrastructure
  mac-address=00:24:D7:1F:EA:20

  [ipv6]
  method=auto

  [ipv4]
  method=auto

  Is it unhappy because of the . in the names?

  ProblemType: Package
  DistroRelease: Ubuntu 23.10
  Package: network-manager 1.44.2-1ubuntu1
  ProcVersionSignature: Ubuntu 6.2.0-34.34-generic 6.2.16
  Uname: Linux 6.2.0-34-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.27.0-0ubuntu5
  Architecture: amd64
  CasperMD5CheckResult: unknown
  Date: Mon Oct 16 16:12:43 2023
  ErrorMessage: installed network-manager package post-installation script 
subprocess returned error exit status 10
  InstallationDate: Installed on 2019-12-23 (1393 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
  NetworkManager.state:
   [main]
   NetworkingEnabled=true
   WirelessEnabled=true
   WWANEnabled=true
  Python3Details: /usr/bin/python3.11, Python 3.11.6, python3-minimal, 3.11.4-5
  PythonDetails: N/A
  RebootRequiredPkgs: Error: path contained symlinks.
  RelatedPackageVersions:
   dpkg 1.22.0ubuntu1
   apt  2.7.3
  SourcePackage: network-manager
  Title: package network-manager 1.44.2-1ubuntu1 failed to install/upgrade: 
installed network-manager package post-installation script subprocess returned 
error exit status 10
  UpgradeStatus: Upgraded to mantic on 2023-10-16 (0 days ago)
  nmcli-nm:
   RUNNING  VERSION  STATE  STARTUP  CONNECTIVITY  NETWORKING  WIFI-HW  
WIFI WWAN-HW  WWAN
   running  1.44.2   connected  started  full  enabled enabled  
enabled  missing  enabled

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/2039503/+subscriptions


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

[Desktop-packages] [Bug 2039503] Re: package network-manager 1.44.2-1ubuntu1 failed to install/upgrade: installed network-manager package post-installation script subprocess returned error exit status

I created a patch which should fix the issue:
https://code.launchpad.net/~slyon/network-manager/+git/network-
manager/+merge/453731

This also needs SRU

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2039503

Title:
  package network-manager 1.44.2-1ubuntu1 failed to install/upgrade:
  installed network-manager package post-installation script subprocess
  returned error exit status 10

Status in network-manager package in Ubuntu:
  New
Status in network-manager source package in Mantic:
  New

Bug description:
  lunar to mantic upgrade, exciting to see output from network-manager
  postinst migrating connections to /etc/netplan one by one.  But then:

  Error: 491fa5c8-68ef-4140-8679-dca422f5c262 - no such connection profile.
  dpkg: error processing package network-manager (--configure):
   installed network-manager package post-installation script subprocess 
returned error exit status 10

  That UUID appears in a file /etc/NetworkManager/system-
  connections/UPTOWN.guests that hasn't been touched since 2015.

  Contents of the file were:

  [connection]
  id=UPTOWN.guests
  uuid=491fa5c8-68ef-4140-8679-dca422f5c262
  type=wifi

  [wifi]
  ssid=UPTOWN.guests
  mode=infrastructure
  mac-address=E0:9D:31:09:84:54

  [ipv6]
  method=auto

  [ipv4]
  method=auto

  
  I've removed it from disk and the migration continued to completion.

  Then I got another failure on:

  [connection]
  id=belkin.1e4.guests
  uuid=2c77e512-f3e3-4238-b401-c94559cc6db0
  type=802-11-wireless

  [802-11-wireless]
  ssid=belkin.1e4.guests
  mode=infrastructure
  mac-address=00:24:D7:1F:EA:20

  [ipv6]
  method=auto

  [ipv4]
  method=auto

  Is it unhappy because of the . in the names?

  ProblemType: Package
  DistroRelease: Ubuntu 23.10
  Package: network-manager 1.44.2-1ubuntu1
  ProcVersionSignature: Ubuntu 6.2.0-34.34-generic 6.2.16
  Uname: Linux 6.2.0-34-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.27.0-0ubuntu5
  Architecture: amd64
  CasperMD5CheckResult: unknown
  Date: Mon Oct 16 16:12:43 2023
  ErrorMessage: installed network-manager package post-installation script 
subprocess returned error exit status 10
  InstallationDate: Installed on 2019-12-23 (1393 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
  NetworkManager.state:
   [main]
   NetworkingEnabled=true
   WirelessEnabled=true
   WWANEnabled=true
  Python3Details: /usr/bin/python3.11, Python 3.11.6, python3-minimal, 3.11.4-5
  PythonDetails: N/A
  RebootRequiredPkgs: Error: path contained symlinks.
  RelatedPackageVersions:
   dpkg 1.22.0ubuntu1
   apt  2.7.3
  SourcePackage: network-manager
  Title: package network-manager 1.44.2-1ubuntu1 failed to install/upgrade: 
installed network-manager package post-installation script subprocess returned 
error exit status 10
  UpgradeStatus: Upgraded to mantic on 2023-10-16 (0 days ago)
  nmcli-nm:
   RUNNING  VERSION  STATE  STARTUP  CONNECTIVITY  NETWORKING  WIFI-HW  
WIFI WWAN-HW  WWAN
   running  1.44.2   connected  started  full  enabled enabled  
enabled  missing  enabled

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/2039503/+subscriptions


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

[Desktop-packages] [Bug 2039503] Re: package network-manager 1.44.2-1ubuntu1 failed to install/upgrade: installed network-manager package post-installation script subprocess returned error exit status

Thank you for providing the keyfiles as a reproducer!

I think this line in the migration script [1] is failing here. We need to catch 
and handle the error.
> ORIG_NAME=$(nmcli --get-values connection.id con show "$UUID")

The issue is, that this connection profile is apparently very old and
doesn't get loaded into memory by modern NetworkManager anymore,
therefor we cannot query NM about it. When trying to load it manually, I
can see the following error in the journal:


$ nmcli con load UPTOWN.guests
$ journalctl -u NetworkManager -e
NetworkManager[126986]:   [1697527301.3708] settings: load: failure to 
load "/etc/NetworkManager/system-connections/UPTOWN.guests": filename is not 
valid for a keyfile


[1] 
https://git.launchpad.net/network-manager/tree/debian/network-manager.postinst#n67

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2039503

Title:
  package network-manager 1.44.2-1ubuntu1 failed to install/upgrade:
  installed network-manager package post-installation script subprocess
  returned error exit status 10

Status in network-manager package in Ubuntu:
  New
Status in network-manager source package in Mantic:
  New

Bug description:
  lunar to mantic upgrade, exciting to see output from network-manager
  postinst migrating connections to /etc/netplan one by one.  But then:

  Error: 491fa5c8-68ef-4140-8679-dca422f5c262 - no such connection profile.
  dpkg: error processing package network-manager (--configure):
   installed network-manager package post-installation script subprocess 
returned error exit status 10

  That UUID appears in a file /etc/NetworkManager/system-
  connections/UPTOWN.guests that hasn't been touched since 2015.

  Contents of the file were:

  [connection]
  id=UPTOWN.guests
  uuid=491fa5c8-68ef-4140-8679-dca422f5c262
  type=wifi

  [wifi]
  ssid=UPTOWN.guests
  mode=infrastructure
  mac-address=E0:9D:31:09:84:54

  [ipv6]
  method=auto

  [ipv4]
  method=auto

  
  I've removed it from disk and the migration continued to completion.

  Then I got another failure on:

  [connection]
  id=belkin.1e4.guests
  uuid=2c77e512-f3e3-4238-b401-c94559cc6db0
  type=802-11-wireless

  [802-11-wireless]
  ssid=belkin.1e4.guests
  mode=infrastructure
  mac-address=00:24:D7:1F:EA:20

  [ipv6]
  method=auto

  [ipv4]
  method=auto

  Is it unhappy because of the . in the names?

  ProblemType: Package
  DistroRelease: Ubuntu 23.10
  Package: network-manager 1.44.2-1ubuntu1
  ProcVersionSignature: Ubuntu 6.2.0-34.34-generic 6.2.16
  Uname: Linux 6.2.0-34-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.27.0-0ubuntu5
  Architecture: amd64
  CasperMD5CheckResult: unknown
  Date: Mon Oct 16 16:12:43 2023
  ErrorMessage: installed network-manager package post-installation script 
subprocess returned error exit status 10
  InstallationDate: Installed on 2019-12-23 (1393 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
  NetworkManager.state:
   [main]
   NetworkingEnabled=true
   WirelessEnabled=true
   WWANEnabled=true
  Python3Details: /usr/bin/python3.11, Python 3.11.6, python3-minimal, 3.11.4-5
  PythonDetails: N/A
  RebootRequiredPkgs: Error: path contained symlinks.
  RelatedPackageVersions:
   dpkg 1.22.0ubuntu1
   apt  2.7.3
  SourcePackage: network-manager
  Title: package network-manager 1.44.2-1ubuntu1 failed to install/upgrade: 
installed network-manager package post-installation script subprocess returned 
error exit status 10
  UpgradeStatus: Upgraded to mantic on 2023-10-16 (0 days ago)
  nmcli-nm:
   RUNNING  VERSION  STATE  STARTUP  CONNECTIVITY  NETWORKING  WIFI-HW  
WIFI WWAN-HW  WWAN
   running  1.44.2   connected  started  full  enabled enabled  
enabled  missing  enabled

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/2039503/+subscriptions


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

[Desktop-packages] [Bug 2038811] Re: NetworkManager crashes when updating wpa-eap connections

2023-10-12 Thread Lukas Märdian

** Summary changed:

- 
/usr/sbin/NetworkManager:6:g_assertion_message:g_assertion_message_expr:_internal_write_connection:nms_keyfile_writer_connection:nms_keyfile_plugin_update_connection
+ NetworkManager crashes when updating wpa-eap connections

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2038811

Title:
  NetworkManager crashes when updating wpa-eap connections

Status in netplan.io package in Ubuntu:
  Triaged
Status in network-manager package in Ubuntu:
  Triaged

Bug description:
  The Ubuntu Error Tracker has been receiving reports about a problem regarding 
network-manager.  This problem was most recently seen with package version 
1.44.2-1ubuntu1, the problem page at 
https://errors.ubuntu.com/problem/0185fff02c2976262de9f862e539829420f9c737 
contains more details, including versions of packages affected, stacktrace or 
traceback, and individual crash reports.
  If you do not have access to the Ubuntu Error Tracker and are a software 
developer, you can request it at http://forms.canonical.com/reports/.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/2038811/+subscriptions


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

[Desktop-packages] [Bug 2038811] Re: /usr/sbin/NetworkManager:6:g_assertion_message:g_assertion_message_expr:_internal_write_connection:nms_keyfile_writer_connection:nms_keyfile_plugin_update_connecti

2023-10-11 Thread Lukas Märdian

Reproducer:
nmcli con add type wifi ifname wlan0 ssid asdasd wifi-sec.key-mgmt wpa-eap 
802-1x.eap leap 802-1x.identity username 802-1x.password 


The crash (SIGABRT) happens in NetworkManager's Netplan integration patch, 
because of running into a "nm_assert_not_reached()" call. This could easily be 
avoided by muting that assert and just logging the error and returning FALSE 
(as is already done below the assert):

https://git.launchpad.net/ubuntu/+source/network-
manager/tree/debian/patches/netplan/0002-netplan-make-use-of-libnetplan-
for-YAML-backend.patch#n319

This would not fix the root-cause, though, which is located in
libnetplan: When creating or updating a NetworkManager connection
profile that uses a 802.1x eap authentication method unknown to Netplan
(such as "leap" or "pwd"), the Netplan keyfile parser is getting
confused and generates a broken keyfile config for NetworkManager.

https://github.com/canonical/netplan/blob/main/src/parse-nm.c#L383

This is triggered when manually adding/modifying a corresponding NM
connection profile (through the NM GUI, nmcli, NM DBus, ...) or
automatically, when migrating a corresponding profile through
NetworkManager's "Netplan everywhere" migration as part of the .postinst
maintainer script. In the latter case the crash is handled gracefully,
NetworkManager is restarted and the broken keyfile is restored from a
backup.

https://git.launchpad.net/ubuntu/+source/network-
manager/tree/debian/network-manager.postinst#n67


This can be fixed by supporting all of NetworkManager's 802.1x eap 
authentication methods in Netplan or by making Netplan's passthrough logic 
detect such cases and handle them as a fallback.


Kudos to @danilogondolfo for the investigation and the proposed patch:
https://github.com/canonical/netplan/pull/415

** Changed in: netplan.io (Ubuntu)
   Importance: Undecided => High

** Changed in: network-manager (Ubuntu)
   Importance: High => Medium

** Changed in: network-manager (Ubuntu)
   Status: New => Triaged

** Changed in: netplan.io (Ubuntu)
   Status: New => Triaged

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2038811

Title:
  
/usr/sbin/NetworkManager:6:g_assertion_message:g_assertion_message_expr:_internal_write_connection:nms_keyfile_writer_connection:nms_keyfile_plugin_update_connection

Status in netplan.io package in Ubuntu:
  Triaged
Status in network-manager package in Ubuntu:
  Triaged

Bug description:
  The Ubuntu Error Tracker has been receiving reports about a problem regarding 
network-manager.  This problem was most recently seen with package version 
1.44.2-1ubuntu1, the problem page at 
https://errors.ubuntu.com/problem/0185fff02c2976262de9f862e539829420f9c737 
contains more details, including versions of packages affected, stacktrace or 
traceback, and individual crash reports.
  If you do not have access to the Ubuntu Error Tracker and are a software 
developer, you can request it at http://forms.canonical.com/reports/.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/2038811/+subscriptions


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

[Desktop-packages] [Bug 2038811] Re: /usr/sbin/NetworkManager:6:g_assertion_message:g_assertion_message_expr:_internal_write_connection:nms_keyfile_writer_connection:nms_keyfile_plugin_update_connecti

2023-10-09 Thread Lukas Märdian

** Tags added: foundations-todo

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2038811

Title:
  
/usr/sbin/NetworkManager:6:g_assertion_message:g_assertion_message_expr:_internal_write_connection:nms_keyfile_writer_connection:nms_keyfile_plugin_update_connection

Status in netplan.io package in Ubuntu:
  New
Status in network-manager package in Ubuntu:
  New

Bug description:
  The Ubuntu Error Tracker has been receiving reports about a problem regarding 
network-manager.  This problem was most recently seen with package version 
1.44.2-1ubuntu1, the problem page at 
https://errors.ubuntu.com/problem/0185fff02c2976262de9f862e539829420f9c737 
contains more details, including versions of packages affected, stacktrace or 
traceback, and individual crash reports.
  If you do not have access to the Ubuntu Error Tracker and are a software 
developer, you can request it at http://forms.canonical.com/reports/.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/2038811/+subscriptions


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

[Desktop-packages] [Bug 2028054] Re: [MIR] python-rlpycairo

2023-08-29 Thread Lukas Märdian

** Changed in: python-rlpycairo (Ubuntu)
   Status: New => Incomplete

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

Title:
  [MIR] python-rlpycairo

Status in hplip package in Ubuntu:
  New
Status in python-reportlab package in Ubuntu:
  Incomplete
Status in python-rlpycairo package in Ubuntu:
  Incomplete

Bug description:
  python-rlpycairo is a new dependency of python-reportlab (currently
  owned by Foundations).

  The only consumer of python-reportlab is hplip (owned by Desktop),
  apparently it needs it for scanning: https://bugs.debian.org/cgi-
  bin/bugreport.cgi?bug=651240

  $ reverse-depends src:python-reportlab -c main -r mantic
  Reverse-Depends
  ===
  * hplip (for python3-reportlab)

  Packages without architectures listed are reverse-dependencies in:
  amd64, arm64, armhf, ppc64el, s390x

  src:hplip -> src:python-reportlab -> src:python-rlpycairo ->
  src:freetype-py & src:ttf-bitstream-vera

  So from the above, it sounds like this new dependency is actually
  needed (after the reportlab package dropped its renderpm extension).
  It should be discussed between Foundations and Desktop who's owning
  those dependencies and doing the MIRs for python-rlpycairo, freetype-
  py and ttf-bitstream-vera

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/hplip/+bug/2028054/+subscriptions


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

[Desktop-packages] [Bug 2028054] Re: [MIR] python-rlpycairo

2023-08-29 Thread Lukas Märdian

Thanks Till, for the detailed analysis in comment #3!

IMO src:hplip should be adopted accordingly, to avoid those new MIR
dependencies, as they don't seem to be necessary. Especially, as we're
moving to a CUPS snap based stack eventually.

What do Desktop people think about that?

We might want to be a bit more selective in
https://git.launchpad.net/~ubuntu-core-dev/ubuntu-
seeds/+git/platform/tree/desktop-common#n69 instead of just seeding all
of hplip.

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

Title:
  [MIR] python-rlpycairo

Status in hplip package in Ubuntu:
  New
Status in python-reportlab package in Ubuntu:
  Incomplete
Status in python-rlpycairo package in Ubuntu:
  New

Bug description:
  python-rlpycairo is a new dependency of python-reportlab (currently
  owned by Foundations).

  The only consumer of python-reportlab is hplip (owned by Desktop),
  apparently it needs it for scanning: https://bugs.debian.org/cgi-
  bin/bugreport.cgi?bug=651240

  $ reverse-depends src:python-reportlab -c main -r mantic
  Reverse-Depends
  ===
  * hplip (for python3-reportlab)

  Packages without architectures listed are reverse-dependencies in:
  amd64, arm64, armhf, ppc64el, s390x

  src:hplip -> src:python-reportlab -> src:python-rlpycairo ->
  src:freetype-py & src:ttf-bitstream-vera

  So from the above, it sounds like this new dependency is actually
  needed (after the reportlab package dropped its renderpm extension).
  It should be discussed between Foundations and Desktop who's owning
  those dependencies and doing the MIRs for python-rlpycairo, freetype-
  py and ttf-bitstream-vera

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/hplip/+bug/2028054/+subscriptions


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

[Desktop-packages] [Bug 2028054] Re: [MIR] python-rlpycairo

2023-08-29 Thread Lukas Märdian

** Changed in: python-reportlab (Ubuntu)
   Status: Fix Released => Incomplete

** Changed in: python-reportlab (Ubuntu)
 Assignee: Ubuntu Foundations Bugs (foundations-bugs) => (unassigned)

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

Title:
  [MIR] python-rlpycairo

Status in hplip package in Ubuntu:
  New
Status in python-reportlab package in Ubuntu:
  Incomplete
Status in python-rlpycairo package in Ubuntu:
  New

Bug description:
  python-rlpycairo is a new dependency of python-reportlab (currently
  owned by Foundations).

  The only consumer of python-reportlab is hplip (owned by Desktop),
  apparently it needs it for scanning: https://bugs.debian.org/cgi-
  bin/bugreport.cgi?bug=651240

  $ reverse-depends src:python-reportlab -c main -r mantic
  Reverse-Depends
  ===
  * hplip (for python3-reportlab)

  Packages without architectures listed are reverse-dependencies in:
  amd64, arm64, armhf, ppc64el, s390x

  src:hplip -> src:python-reportlab -> src:python-rlpycairo ->
  src:freetype-py & src:ttf-bitstream-vera

  So from the above, it sounds like this new dependency is actually
  needed (after the reportlab package dropped its renderpm extension).
  It should be discussed between Foundations and Desktop who's owning
  those dependencies and doing the MIRs for python-rlpycairo, freetype-
  py and ttf-bitstream-vera

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/hplip/+bug/2028054/+subscriptions


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

[Desktop-packages] [Bug 2012902] Re: netplan plugin: generated NM config when using globbing will be used for only one connection

2023-08-28 Thread Lukas Märdian

** Tags added: foundations-todo

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2012902

Title:
  netplan plugin: generated NM config when using globbing will be used
  for only one connection

Status in netplan:
  Triaged
Status in network-manager package in Ubuntu:
  New

Bug description:
  There is a mismatch between what netplan expresses when using globbing
  in a netplan file and what NM understands when using a match setting.
  For instance:

  network:
  version: 2
  ethernets:
  all-en:
  match:
  name: "en*"
  dhcp4: true

  Generates a NM connection in /run/NetworkManager/system-connections:

  ...
  [match]
  interface-name=en*;
  ...

  But an NM connection can only match one interface, so if two
  interfaces like ens2 and ens3 exist, only one of them will be
  configured, even though the netplan configuration is expected to be
  applied to both.

  Solving this might involve generating one NM connection in the netplan
  plugin per detected interface.

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


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

[Desktop-packages] [Bug 2028054] Re: [MIR] python-rlpycairo

2023-07-20 Thread Lukas Märdian

Ok, we're not doing the MIR then and waiting for the desktop team to
demote the printing stack.

** Changed in: python-rlpycairo (Ubuntu)
   Status: Incomplete => Won't Fix

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

Title:
  [MIR] python-rlpycairo

Status in hplip package in Ubuntu:
  New
Status in python-reportlab package in Ubuntu:
  New
Status in python-rlpycairo package in Ubuntu:
  Won't Fix

Bug description:
  python-rlpycairo is a new dependency of python-reportlab (currently
  owned by Foundations).

  The only consumer of python-reportlab is hplip (owned by Desktop),
  apparently it needs it for scanning: https://bugs.debian.org/cgi-
  bin/bugreport.cgi?bug=651240

  $ reverse-depends src:python-reportlab -c main -r mantic
  Reverse-Depends
  ===
  * hplip (for python3-reportlab)

  Packages without architectures listed are reverse-dependencies in:
  amd64, arm64, armhf, ppc64el, s390x

  src:hplip -> src:python-reportlab -> src:python-rlpycairo ->
  src:freetype-py & src:ttf-bitstream-vera

  So from the above, it sounds like this new dependency is actually
  needed (after the reportlab package dropped its renderpm extension).
  It should be discussed between Foundations and Desktop who's owning
  those dependencies and doing the MIRs for python-rlpycairo, freetype-
  py and ttf-bitstream-vera

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/hplip/+bug/2028054/+subscriptions


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

[Desktop-packages] [Bug 2028054] [NEW] [MIR] python-rlpycairo

2023-07-18 Thread Lukas Märdian

Public bug reported:

python-rlpycairo is a new dependency of python-reportlab (currently
owned by Foundations).

The only consumer of python-reportlab is hplip (owned by Desktop),
apparently it needs it for scanning: https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=651240

$ reverse-depends src:python-reportlab -c main -r mantic
Reverse-Depends
===
* hplip (for python3-reportlab)

Packages without architectures listed are reverse-dependencies in:
amd64, arm64, armhf, ppc64el, s390x

src:hplip -> src:python-reportlab -> src:python-rlpycairo ->
src:freetype-py & src:ttf-bitstream-vera

So from the above, it sounds like this new dependency is actually needed
(after the reportlab package dropped its renderpm extension). It should
be discussed between Foundations and Desktop who's owning those
dependencies and doing the MIRs for python-rlpycairo, freetype-py and
ttf-bitstream-vera

** Affects: hplip (Ubuntu)
 Importance: Undecided
 Assignee: Ubuntu Printing Team (ubuntu-printing)
 Status: New

** Affects: python-reportlab (Ubuntu)
 Importance: Undecided
 Assignee: Ubuntu Foundations Bugs (foundations-bugs)
 Status: New

** Affects: python-rlpycairo (Ubuntu)
 Importance: Undecided
 Status: Incomplete


** Tags: mantic rls-mm-incoming update-excuse

** Also affects: python-reportlab (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: python-reportlab (Ubuntu)
 Assignee: (unassigned) => Ubuntu Foundations Bugs (foundations-bugs)

** Also affects: hplip (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: hplip (Ubuntu)
 Assignee: (unassigned) => Ubuntu Printing Team (ubuntu-printing)

** Tags added: update-excuse

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

Title:
  [MIR] python-rlpycairo

Status in hplip package in Ubuntu:
  New
Status in python-reportlab package in Ubuntu:
  New
Status in python-rlpycairo package in Ubuntu:
  Incomplete

Bug description:
  python-rlpycairo is a new dependency of python-reportlab (currently
  owned by Foundations).

  The only consumer of python-reportlab is hplip (owned by Desktop),
  apparently it needs it for scanning: https://bugs.debian.org/cgi-
  bin/bugreport.cgi?bug=651240

  $ reverse-depends src:python-reportlab -c main -r mantic
  Reverse-Depends
  ===
  * hplip (for python3-reportlab)

  Packages without architectures listed are reverse-dependencies in:
  amd64, arm64, armhf, ppc64el, s390x

  src:hplip -> src:python-reportlab -> src:python-rlpycairo ->
  src:freetype-py & src:ttf-bitstream-vera

  So from the above, it sounds like this new dependency is actually
  needed (after the reportlab package dropped its renderpm extension).
  It should be discussed between Foundations and Desktop who's owning
  those dependencies and doing the MIRs for python-rlpycairo, freetype-
  py and ttf-bitstream-vera

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/hplip/+bug/2028054/+subscriptions


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

[Desktop-packages] [Bug 2026826] Re: glib2.0 (2.77.0 ) breaks Netplan build

2023-07-13 Thread Lukas Märdian

Thank you! The Netplan build seems to be fixed now. Removing the tag.

** Tags removed: block-proposed

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to glib2.0 in Ubuntu.
https://bugs.launchpad.net/bugs/2026826

Title:
  glib2.0 (2.77.0 ) breaks Netplan build

Status in GLib:
  New
Status in glib2.0 package in Ubuntu:
  Fix Committed

Bug description:
  Netplan FTBFS as of the latest release of glib2.0 (2.77.0-0ubuntu1) in
  mantic-proposed.

  See: https://launchpad.net/ubuntu/+source/netplan.io/0.106.1-3

  When I downgrade glib in my sbuild environment, everything works as
  expected:

  $ apt install libglib2.0-0=2.76.3-1ubuntu1
  libglib2.0-bin=2.76.3-1ubuntu1 libglib2.0-dev=2.76.3-1ubuntu1
  libglib2.0-dev-bin=2.76.3-1ubuntu1 libglib2.0-data=2.76.3-1ubuntu1

  The build also works fine in Debian unstable, which is using glib2.0
  2.74.6-2.

  Netplan is using plenty of GLib's keyfile functions
  (https://docs.gtk.org/glib/struct.KeyFile.html), which seem to
  producing a different output with this newer release (some strange
  line breaks injected in the middle of a keyfile).

  
  Example keyfile from the test_wifis.test_wifi_wowlan test, that should be 
generated by Netplan and the way it fails:

  Expected output:
  ```
  [connection]
  id=netplan-wl0-homenet
  type=wifi
  interface-name=wl0

  [wifi]
  wake-on-wlan=330
  ssid=homenet
  mode=infrastructure

  [ipv4]
  method=link-local

  [ipv6]
  method=ignore
  ```

  Failure:
  ```
  E   AssertionError: '[con[88 
chars]330\n\nssid=homenet\nmode=infrastructure\n[ipv[44 chars]re\n' != '[con[88 
chars]330\nssid=homenet\nmode=infrastructure\n\n[ipv[44 chars]re\n'
  E [connection]
  E id=netplan-wl0-homenet
  E type=wifi
  E interface-name=wl0
  E 
  E [wifi]
  E wake-on-wlan=330
  E   - 
  E ssid=homenet
  E mode=infrastructure
  E   + 
  E [ipv4]
  E method=link-local
  E 
  E [ipv6]
  E method=ignore
  ```

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


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

[Desktop-packages] [Bug 2026826] Re: glib2.0 (2.77.0 ) breaks Netplan build

2023-07-13 Thread Lukas Märdian

** Bug watch added: gitlab.gnome.org/GNOME/glib/-/issues #3047
   https://gitlab.gnome.org/GNOME/glib/-/issues/3047

** Also affects: glib via
   https://gitlab.gnome.org/GNOME/glib/-/issues/3047
   Importance: Unknown
   Status: Unknown

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to glib2.0 in Ubuntu.
https://bugs.launchpad.net/bugs/2026826

Title:
  glib2.0 (2.77.0 ) breaks Netplan build

Status in GLib:
  Unknown
Status in glib2.0 package in Ubuntu:
  In Progress

Bug description:
  Netplan FTBFS as of the latest release of glib2.0 (2.77.0-0ubuntu1) in
  mantic-proposed.

  See: https://launchpad.net/ubuntu/+source/netplan.io/0.106.1-3

  When I downgrade glib in my sbuild environment, everything works as
  expected:

  $ apt install libglib2.0-0=2.76.3-1ubuntu1
  libglib2.0-bin=2.76.3-1ubuntu1 libglib2.0-dev=2.76.3-1ubuntu1
  libglib2.0-dev-bin=2.76.3-1ubuntu1 libglib2.0-data=2.76.3-1ubuntu1

  The build also works fine in Debian unstable, which is using glib2.0
  2.74.6-2.

  Netplan is using plenty of GLib's keyfile functions
  (https://docs.gtk.org/glib/struct.KeyFile.html), which seem to
  producing a different output with this newer release (some strange
  line breaks injected in the middle of a keyfile).

  
  Example keyfile from the test_wifis.test_wifi_wowlan test, that should be 
generated by Netplan and the way it fails:

  Expected output:
  ```
  [connection]
  id=netplan-wl0-homenet
  type=wifi
  interface-name=wl0

  [wifi]
  wake-on-wlan=330
  ssid=homenet
  mode=infrastructure

  [ipv4]
  method=link-local

  [ipv6]
  method=ignore
  ```

  Failure:
  ```
  E   AssertionError: '[con[88 
chars]330\n\nssid=homenet\nmode=infrastructure\n[ipv[44 chars]re\n' != '[con[88 
chars]330\nssid=homenet\nmode=infrastructure\n\n[ipv[44 chars]re\n'
  E [connection]
  E id=netplan-wl0-homenet
  E type=wifi
  E interface-name=wl0
  E 
  E [wifi]
  E wake-on-wlan=330
  E   - 
  E ssid=homenet
  E mode=infrastructure
  E   + 
  E [ipv4]
  E method=link-local
  E 
  E [ipv6]
  E method=ignore
  ```

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


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

[Desktop-packages] [Bug 2026826] Re: glib2.0 (2.77.0 ) breaks Netplan build

2023-07-11 Thread Lukas Märdian

** Description changed:

  Netplan FTBFS as of the latest release of glib2.0 (2.77.0-0ubuntu1) in
  mantic-proposed.
  
  See: https://launchpad.net/ubuntu/+source/netplan.io/0.106.1-3
  
  When I downgrade glib in my sbuild environment, everything works as
  expected:
  
  $ apt install libglib2.0-0=2.76.3-1ubuntu1
  libglib2.0-bin=2.76.3-1ubuntu1 libglib2.0-dev=2.76.3-1ubuntu1
  libglib2.0-dev-bin=2.76.3-1ubuntu1 libglib2.0-data=2.76.3-1ubuntu1
  
  The build also works fine in Debian unstable, which is using glib2.0
  2.74.6-2.
  
  Netplan is using plenty of GLib's keyfile functions
  (https://docs.gtk.org/glib/struct.KeyFile.html), which seem to producing
  a different output with this newer release (some strange line breaks
  injected in the middle of a keyfile).
+ 
+ 
+ Example keyfile from the test_wifis.test_wifi_wowlan test, that should be 
generated by Netplan and the way it fails:
+ 
+ Expected output:
+ ```
+ [connection]
+ id=netplan-wl0-homenet
+ type=wifi
+ interface-name=wl0
+ 
+ [wifi]
+ wake-on-wlan=330
+ ssid=homenet
+ mode=infrastructure
+ 
+ [ipv4]
+ method=link-local
+ 
+ [ipv6]
+ method=ignore
+ ```
+ 
+ Failure:
+ ```
+ E   AssertionError: '[con[88 
chars]330\n\nssid=homenet\nmode=infrastructure\n[ipv[44 chars]re\n' != '[con[88 
chars]330\nssid=homenet\nmode=infrastructure\n\n[ipv[44 chars]re\n'
+ E [connection]
+ E id=netplan-wl0-homenet
+ E type=wifi
+ E interface-name=wl0
+ E 
+ E [wifi]
+ E wake-on-wlan=330
+ E   - 
+ E ssid=homenet
+ E mode=infrastructure
+ E   + 
+ E [ipv4]
+ E method=link-local
+ E 
+ E [ipv6]
+ E method=ignore
+ ```

** Tags added: rls-mm-incoming

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to glib2.0 in Ubuntu.
https://bugs.launchpad.net/bugs/2026826

Title:
  glib2.0 (2.77.0 ) breaks Netplan build

Status in glib2.0 package in Ubuntu:
  New

Bug description:
  Netplan FTBFS as of the latest release of glib2.0 (2.77.0-0ubuntu1) in
  mantic-proposed.

  See: https://launchpad.net/ubuntu/+source/netplan.io/0.106.1-3

  When I downgrade glib in my sbuild environment, everything works as
  expected:

  $ apt install libglib2.0-0=2.76.3-1ubuntu1
  libglib2.0-bin=2.76.3-1ubuntu1 libglib2.0-dev=2.76.3-1ubuntu1
  libglib2.0-dev-bin=2.76.3-1ubuntu1 libglib2.0-data=2.76.3-1ubuntu1

  The build also works fine in Debian unstable, which is using glib2.0
  2.74.6-2.

  Netplan is using plenty of GLib's keyfile functions
  (https://docs.gtk.org/glib/struct.KeyFile.html), which seem to
  producing a different output with this newer release (some strange
  line breaks injected in the middle of a keyfile).

  
  Example keyfile from the test_wifis.test_wifi_wowlan test, that should be 
generated by Netplan and the way it fails:

  Expected output:
  ```
  [connection]
  id=netplan-wl0-homenet
  type=wifi
  interface-name=wl0

  [wifi]
  wake-on-wlan=330
  ssid=homenet
  mode=infrastructure

  [ipv4]
  method=link-local

  [ipv6]
  method=ignore
  ```

  Failure:
  ```
  E   AssertionError: '[con[88 
chars]330\n\nssid=homenet\nmode=infrastructure\n[ipv[44 chars]re\n' != '[con[88 
chars]330\nssid=homenet\nmode=infrastructure\n\n[ipv[44 chars]re\n'
  E [connection]
  E id=netplan-wl0-homenet
  E type=wifi
  E interface-name=wl0
  E 
  E [wifi]
  E wake-on-wlan=330
  E   - 
  E ssid=homenet
  E mode=infrastructure
  E   + 
  E [ipv4]
  E method=link-local
  E 
  E [ipv6]
  E method=ignore
  ```

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/2026826/+subscriptions


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

[Desktop-packages] [Bug 2026826] Re: glib2.0 (2.77.0 ) breaks Netplan build

2023-07-11 Thread Lukas Märdian

I'm tagging this block-proposed to avoid this broken GLib to move into
mantic-release.

** Tags added: block-proposed

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to glib2.0 in Ubuntu.
https://bugs.launchpad.net/bugs/2026826

Title:
  glib2.0 (2.77.0 ) breaks Netplan build

Status in glib2.0 package in Ubuntu:
  New

Bug description:
  Netplan FTBFS as of the latest release of glib2.0 (2.77.0-0ubuntu1) in
  mantic-proposed.

  See: https://launchpad.net/ubuntu/+source/netplan.io/0.106.1-3

  When I downgrade glib in my sbuild environment, everything works as
  expected:

  $ apt install libglib2.0-0=2.76.3-1ubuntu1
  libglib2.0-bin=2.76.3-1ubuntu1 libglib2.0-dev=2.76.3-1ubuntu1
  libglib2.0-dev-bin=2.76.3-1ubuntu1 libglib2.0-data=2.76.3-1ubuntu1

  The build also works fine in Debian unstable, which is using glib2.0
  2.74.6-2.

  Netplan is using plenty of GLib's keyfile functions
  (https://docs.gtk.org/glib/struct.KeyFile.html), which seem to
  producing a different output with this newer release (some strange
  line breaks injected in the middle of a keyfile).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/2026826/+subscriptions


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

[Desktop-packages] [Bug 2026826] [NEW] glib2.0 (2.77.0 ) breaks Netplan build

2023-07-11 Thread Lukas Märdian

Public bug reported:

Netplan FTBFS as of the latest release of glib2.0 (2.77.0-0ubuntu1) in
mantic-proposed.

See: https://launchpad.net/ubuntu/+source/netplan.io/0.106.1-3

When I downgrade glib in my sbuild environment, everything works as
expected:

$ apt install libglib2.0-0=2.76.3-1ubuntu1
libglib2.0-bin=2.76.3-1ubuntu1 libglib2.0-dev=2.76.3-1ubuntu1
libglib2.0-dev-bin=2.76.3-1ubuntu1 libglib2.0-data=2.76.3-1ubuntu1

The build also works fine in Debian unstable, which is using glib2.0
2.74.6-2.

Netplan is using plenty of GLib's keyfile functions
(https://docs.gtk.org/glib/struct.KeyFile.html), which seem to producing
a different output with this newer release (some strange line breaks
injected in the middle of a keyfile).

** Affects: glib2.0 (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: block-proposed

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to glib2.0 in Ubuntu.
https://bugs.launchpad.net/bugs/2026826

Title:
  glib2.0 (2.77.0 ) breaks Netplan build

Status in glib2.0 package in Ubuntu:
  New

Bug description:
  Netplan FTBFS as of the latest release of glib2.0 (2.77.0-0ubuntu1) in
  mantic-proposed.

  See: https://launchpad.net/ubuntu/+source/netplan.io/0.106.1-3

  When I downgrade glib in my sbuild environment, everything works as
  expected:

  $ apt install libglib2.0-0=2.76.3-1ubuntu1
  libglib2.0-bin=2.76.3-1ubuntu1 libglib2.0-dev=2.76.3-1ubuntu1
  libglib2.0-dev-bin=2.76.3-1ubuntu1 libglib2.0-data=2.76.3-1ubuntu1

  The build also works fine in Debian unstable, which is using glib2.0
  2.74.6-2.

  Netplan is using plenty of GLib's keyfile functions
  (https://docs.gtk.org/glib/struct.KeyFile.html), which seem to
  producing a different output with this newer release (some strange
  line breaks injected in the middle of a keyfile).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/2026826/+subscriptions


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

[Desktop-packages] [Bug 2026230] Re: libnetplan integration breaks "cloned-mac-address" special values

2023-07-10 Thread Lukas Märdian

Merged upstream. Will be part of the next Netplan release.

** Also affects: netplan
   Importance: Undecided
   Status: New

** Changed in: netplan
   Status: New => Fix Committed

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2026230

Title:
  libnetplan integration breaks "cloned-mac-address" special values

Status in netplan:
  Fix Committed
Status in netplan.io package in Ubuntu:
  In Progress
Status in network-manager package in Ubuntu:
  Invalid

Bug description:
  I received an error from apport about a programme not working. I
  collected the data to submit. Hope this helps.

  ProblemType: Crash
  DistroRelease: Ubuntu 23.10
  Package: network-manager 1.42.6-2ubuntu1
  Uname: Linux 6.2.0-24-generic x86_64
  Architecture: amd64
  Date: Wed Jul  5 23:11:14 2023
  ExecutablePath: /usr/sbin/NetworkManager
  ExecutableTimestamp: 1687429583
  ProcCmdline: /usr/sbin/NetworkManager --no-daemon
  ProcCwd: /
  ProcEnviron:
   LANG=en_US.UTF-8
   PATH=(custom, no user)
  Signal: 6
  SourcePackage: network-manager
  UserGroups: N/A

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


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

[Desktop-packages] [Bug 2026230] Re: libnetplan integration breaks "cloned-mac-address" special values

2023-07-10 Thread Lukas Märdian

** Summary changed:

- error when setting up after upgrading
+ libnetplan integration breaks "cloned-mac-address" special values

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2026230

Title:
  libnetplan integration breaks "cloned-mac-address" special values

Status in netplan.io package in Ubuntu:
  In Progress
Status in network-manager package in Ubuntu:
  Invalid

Bug description:
  I received an error from apport about a programme not working. I
  collected the data to submit. Hope this helps.

  ProblemType: Crash
  DistroRelease: Ubuntu 23.10
  Package: network-manager 1.42.6-2ubuntu1
  Uname: Linux 6.2.0-24-generic x86_64
  Architecture: amd64
  Date: Wed Jul  5 23:11:14 2023
  ExecutablePath: /usr/sbin/NetworkManager
  ExecutableTimestamp: 1687429583
  ProcCmdline: /usr/sbin/NetworkManager --no-daemon
  ProcCwd: /
  ProcEnviron:
   LANG=en_US.UTF-8
   PATH=(custom, no user)
  Signal: 6
  SourcePackage: network-manager
  UserGroups: N/A

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/2026230/+subscriptions


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

[Desktop-packages] [Bug 2024661] Re: Unable to configure Wireguard connection at NetworkManager interface

2023-06-26 Thread Lukas Märdian

https://github.com/canonical/netplan/pull/371

** Changed in: netplan.io (Ubuntu)
   Status: Confirmed => In Progress

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2024661

Title:
  Unable to configure Wireguard connection at NetworkManager interface

Status in netplan.io package in Ubuntu:
  In Progress
Status in network-manager package in Ubuntu:
  Invalid

Bug description:
  Repro steps:

  1) Open NetworkManager GUI.
  2) Click "Add new Connection" and select "Wireguard" connection type.
  3) Then you have to configure new connection. Basic configuration looks like 
that:
  a) Write down connection name,
  b) Write down local private key,
  c) Create new peer and populate peer's parameters: public key of the 
peer, allowed IPs (i.e. 0.0.0.0/0), peer's IP address and port.
  4) Click "OK" and "Save".
  5) Open "Peers" again. Ensure that settings were not stored. All fields are 
empty.

  Found in Kubuntu flavor version 23.10 (development), Plasma Network Manager 
interface.
  netplan.io 0.106.1-2
  network-manager 1.42.4-1ubuntu7

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/2024661/+subscriptions


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

[Desktop-packages] [Bug 2024661] Re: Unable to configure Wireguard connection at NetworkManager interface

2023-06-22 Thread Lukas Märdian

** Tags added: netplan-everywhere

** Also affects: network-manager (Ubuntu)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2024661

Title:
  Unable to configure Wireguard connection at NetworkManager interface

Status in netplan.io package in Ubuntu:
  New
Status in network-manager package in Ubuntu:
  New

Bug description:
  Repro steps:

  1) Open NetworkManager GUI.
  2) Click "Add new Connection" and select "Wireguard" connection type.
  3) Then you have to configure new connection. Basic configuration looks like 
that:
  a) Write down connection name,
  b) Write down local private key,
  c) Create new peer and populate peer's parameters: public key of the 
peer, allowed IPs (i.e. 0.0.0.0/0), peer's IP address and port.
  4) Click "OK" and "Save".
  5) Open "Peers" again. Ensure that settings were not stored. All fields are 
empty.

  Found in Kubuntu flavor version 23.10 (development), Plasma Network Manager 
interface.
  netplan.io 0.106.1-2
  network-manager 1.42.4-1ubuntu7

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/2024661/+subscriptions


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

[Desktop-packages] [Bug 2010561] Re: The Netplan Everywhere NetworkManager fails to supply Netplan with networking information until a connection is deleted and re-created

2023-06-19 Thread Lukas Märdian

Thanks Simon, those are two good catches!

The "file" package/command is seeded in the Ubuntu desktop flavours:
$ seeded-in-ubuntu file
file (from file) is seeded in:
edubuntu: daily-live
kubuntu: daily-live
lubuntu: daily-live
ubuntu-budgie: daily-legacy, daily-live
ubuntu-mate: daily-live
ubuntu-server: daily-live, daily-preinstalled
ubuntu-unity: daily-live
ubuntu: daily-canary, daily-legacy, daily-live, daily-preinstalled
ubuntucinnamon: daily-live
ubuntukylin: daily-live
ubuntustudio: dvd
xubuntu: daily-live, daily-minimal

The subshell issue should be fixed with this commit:
https://git.launchpad.net/network-manager/commit/?id=781778e6b7dd6677ef308ad0a3f8f5dfed1e1c63

--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2010561

Title:
The Netplan Everywhere NetworkManager fails to supply Netplan with
networking information until a connection is deleted and re-created

Status in netplan:
Invalid
Status in network-manager package in Ubuntu:
Fix Released

Bug description:
Steps to reproduce:

1. Install Ubuntu Lunar or a flavor thereof onto physical hardware with a
WiFi adapter. (I used Lubuntu Lunar.)
2. Connect to WiFi and install all updates.
3. Enable the Netplan Everywhere PPA and install the updated NetworkManager
from it (further details at
https://discourse.ubuntu.com/t/call-for-testing-networkmanager-yaml-settings/32420?u=arraybolt3)
4. When the installation finishes, run "sudo netplan get".

Expected result: Networking information related to the WiFi connection
should appear in the "sudo netplan get" output.

Actual result: "sudo netplan get" returns the following:

** (process:4088): WARNING **: 12:41:41.394; Permissions for
/etc/netplan/01-network-manager-all.yaml are too open. Netplan configuration
should NOT be accessible by others.
network:
version: 2
renderer: NetworkManager

End of output. Additionally, the /etc/netplan folder does not contain
files that I would expect to be there that would contain the
networking info.

Additional information:

If I disconnect from WiFi, then delete my WiFi connection entirely in
nmtui, and *then* reconnect to the same WiFi network, "sudo netplan
get" returns the expected networking information. /etc/netplan is also
properly populated after doing this.

This bug seems like it will probably cause unintended behavior after
an upgrade from 23.04 (which uses normal NetworkManager) to 23.10
(which is supposed to be using the Netplan Everywhere NetworkManager).
People probably won't know to entirely delete the WiFi and other
connections and then reconnect them in order for the netplan output to
be usable.

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

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

[Desktop-packages] [Bug 2019940] Re: Directly manipulating NetworkManager keyfiles

Thank you @seth-arnold! I've updated the affected packages of this bug
and (bug #2019939) accordingly.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2019940

Title:
  Directly manipulating NetworkManager keyfiles

Status in augeas package in Ubuntu:
  New
Status in calamares package in Ubuntu:
  New
Status in cloud-init package in Ubuntu:
  Invalid
Status in cruft package in Ubuntu:
  Won't Fix
Status in cruft-ng package in Ubuntu:
  New
Status in dracut package in Ubuntu:
  New
Status in forensic-artifacts package in Ubuntu:
  New
Status in guestfs-tools package in Ubuntu:
  New
Status in guix package in Ubuntu:
  New
Status in ltsp package in Ubuntu:
  Invalid
Status in netcfg package in Ubuntu:
  Won't Fix
Status in netplan.io package in Ubuntu:
  Invalid
Status in network-manager package in Ubuntu:
  New
Status in refpolicy package in Ubuntu:
  New
Status in sosreport package in Ubuntu:
  New
Status in ubiquity package in Ubuntu:
  New
Status in uhd package in Ubuntu:
  New
Status in vagrant package in Ubuntu:
  New

Bug description:
  The affected packages can manipulate NetworkManager keyfiles directly
  on disk, which might not be appropriate anymore on Ubuntu, since the
  Netplan integration was enabled in NetworkManager (starting with
  Mantic), migrating any keyfile configuration from
  /etc/NetworkManager/system-connections/*[.nmconnection] to
  /etc/netplan/90-NM-*.yaml

  See Netplan's documentation for how connections are handled:
  https://netplan.readthedocs.io/en/latest/netplan-everywhere/

  PS: Packages were queried using:
  
https://codesearch.debian.net/search?q=%2Fsystem-connections=1=1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/augeas/+bug/2019940/+subscriptions


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

[Desktop-packages] [Bug 2019939] Re: Outdated documentation about NetworkManager keyfiles

** Also affects: scap-security-guide (Ubuntu)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-user-docs in Ubuntu.
https://bugs.launchpad.net/bugs/2019939

Title:
  Outdated documentation about NetworkManager keyfiles

Status in debian-handbook package in Ubuntu:
  New
Status in dhcpcanon package in Ubuntu:
  New
Status in fai package in Ubuntu:
  New
Status in gnome-user-docs package in Ubuntu:
  New
Status in network-manager package in Ubuntu:
  New
Status in network-manager-l2tp package in Ubuntu:
  New
Status in scap-security-guide package in Ubuntu:
  New
Status in wifi-qr package in Ubuntu:
  New

Bug description:
  The affected packages contain documentation or examples about
  NetworkManager keyfiles, which might not be appropriate anymore on
  Ubuntu, since the Netplan integration was enabled in NetworkManager
  (starting with Mantic), migrating any keyfile configuration from
  /etc/NetworkManager/system-connections/*[.nmconnection] to
  /etc/netplan/90-NM-*.yaml

  See Netplan's documentation for how connections are handled:
  https://netplan.readthedocs.io/en/latest/netplan-everywhere/

  PS: Packages were queried using:
  
https://codesearch.debian.net/search?q=%2Fsystem-connections=1=1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debian-handbook/+bug/2019939/+subscriptions


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

[Desktop-packages] [Bug 2019940] Re: Directly manipulating NetworkManager keyfiles

cruft is not part of Ubuntu anymore (got dropped post Kinetic)

** Also affects: ubiquity (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: cruft (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: cruft (Ubuntu)
   Status: New => Won't Fix

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2019940

Title:
  Directly manipulating NetworkManager keyfiles

Status in augeas package in Ubuntu:
  New
Status in calamares package in Ubuntu:
  New
Status in cloud-init package in Ubuntu:
  Invalid
Status in cruft package in Ubuntu:
  Won't Fix
Status in cruft-ng package in Ubuntu:
  New
Status in dracut package in Ubuntu:
  New
Status in forensic-artifacts package in Ubuntu:
  New
Status in guestfs-tools package in Ubuntu:
  New
Status in guix package in Ubuntu:
  New
Status in ltsp package in Ubuntu:
  Invalid
Status in netcfg package in Ubuntu:
  Won't Fix
Status in netplan.io package in Ubuntu:
  Invalid
Status in network-manager package in Ubuntu:
  New
Status in refpolicy package in Ubuntu:
  New
Status in sosreport package in Ubuntu:
  New
Status in ubiquity package in Ubuntu:
  New
Status in uhd package in Ubuntu:
  New
Status in vagrant package in Ubuntu:
  New

Bug description:
  The affected packages can manipulate NetworkManager keyfiles directly
  on disk, which might not be appropriate anymore on Ubuntu, since the
  Netplan integration was enabled in NetworkManager (starting with
  Mantic), migrating any keyfile configuration from
  /etc/NetworkManager/system-connections/*[.nmconnection] to
  /etc/netplan/90-NM-*.yaml

  See Netplan's documentation for how connections are handled:
  https://netplan.readthedocs.io/en/latest/netplan-everywhere/

  PS: Packages were queried using:
  
https://codesearch.debian.net/search?q=%2Fsystem-connections=1=1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/augeas/+bug/2019940/+subscriptions


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

[Desktop-packages] [Bug 2019940] Re: Directly manipulating NetworkManager keyfiles

** Changed in: netplan.io (Ubuntu)
   Status: Won't Fix => Invalid

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2019940

Title:
  Directly manipulating NetworkManager keyfiles

Status in augeas package in Ubuntu:
  New
Status in calamares package in Ubuntu:
  New
Status in cloud-init package in Ubuntu:
  Invalid
Status in cruft-ng package in Ubuntu:
  New
Status in dracut package in Ubuntu:
  New
Status in forensic-artifacts package in Ubuntu:
  New
Status in guestfs-tools package in Ubuntu:
  New
Status in guix package in Ubuntu:
  New
Status in ltsp package in Ubuntu:
  Invalid
Status in netcfg package in Ubuntu:
  Won't Fix
Status in netplan.io package in Ubuntu:
  Invalid
Status in network-manager package in Ubuntu:
  New
Status in refpolicy package in Ubuntu:
  New
Status in sosreport package in Ubuntu:
  New
Status in uhd package in Ubuntu:
  New
Status in vagrant package in Ubuntu:
  New

Bug description:
  The affected packages can manipulate NetworkManager keyfiles directly
  on disk, which might not be appropriate anymore on Ubuntu, since the
  Netplan integration was enabled in NetworkManager (starting with
  Mantic), migrating any keyfile configuration from
  /etc/NetworkManager/system-connections/*[.nmconnection] to
  /etc/netplan/90-NM-*.yaml

  See Netplan's documentation for how connections are handled:
  https://netplan.readthedocs.io/en/latest/netplan-everywhere/

  PS: Packages were queried using:
  
https://codesearch.debian.net/search?q=%2Fsystem-connections=1=1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/augeas/+bug/2019940/+subscriptions


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

[Desktop-packages] [Bug 2010561] Re: The Netplan Everywhere NetworkManager fails to supply Netplan with networking information until a connection is deleted and re-created

** Changed in: network-manager (Ubuntu)
Status: Fix Committed => Fix Released

--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2010561

Title:
The Netplan Everywhere NetworkManager fails to supply Netplan with
networking information until a connection is deleted and re-created

Status in netplan:
Invalid
Status in network-manager package in Ubuntu:
Fix Released

Bug description:
Steps to reproduce:

Expected result: Networking information related to the WiFi connection
should appear in the "sudo netplan get" output.

Actual result: "sudo netplan get" returns the following:

End of output. Additionally, the /etc/netplan folder does not contain
files that I would expect to be there that would contain the
networking info.

Additional information:

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

[Desktop-packages] [Bug 2019940] Re: Directly manipulating NetworkManager keyfiles

We should run the same query on the Ubuntu archive, too. The security
team (sespiros / sarnold) might be able to help with this in the future.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2019940

Title:
  Directly manipulating NetworkManager keyfiles

Status in augeas package in Ubuntu:
  New
Status in calamares package in Ubuntu:
  New
Status in cloud-init package in Ubuntu:
  New
Status in cruft-ng package in Ubuntu:
  New
Status in dracut package in Ubuntu:
  New
Status in forensic-artifacts package in Ubuntu:
  New
Status in guestfs-tools package in Ubuntu:
  New
Status in guix package in Ubuntu:
  New
Status in ltsp package in Ubuntu:
  Invalid
Status in netcfg package in Ubuntu:
  Won't Fix
Status in netplan.io package in Ubuntu:
  Won't Fix
Status in network-manager package in Ubuntu:
  New
Status in refpolicy package in Ubuntu:
  New
Status in sosreport package in Ubuntu:
  New
Status in uhd package in Ubuntu:
  New
Status in vagrant package in Ubuntu:
  New

Bug description:
  The affected packages can manipulate NetworkManager keyfiles directly
  on disk, which might not be appropriate anymore on Ubuntu, since the
  Netplan integration was enabled in NetworkManager (starting with
  Mantic), migrating any keyfile configuration from
  /etc/NetworkManager/system-connections/*[.nmconnection] to
  /etc/netplan/90-NM-*.yaml

  See Netplan's documentation for how connections are handled:
  https://netplan.readthedocs.io/en/latest/netplan-everywhere/

  PS: Packages were queried using:
  
https://codesearch.debian.net/search?q=%2Fsystem-connections=1=1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/augeas/+bug/2019940/+subscriptions


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

[Desktop-packages] [Bug 2019939] Re: Outdated documentation about NetworkManager keyfiles

** Tags added: rls-mm-incoming

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-user-docs in Ubuntu.
https://bugs.launchpad.net/bugs/2019939

Title:
  Outdated documentation about NetworkManager keyfiles

Status in debian-handbook package in Ubuntu:
  New
Status in dhcpcanon package in Ubuntu:
  New
Status in fai package in Ubuntu:
  New
Status in gnome-user-docs package in Ubuntu:
  New
Status in network-manager package in Ubuntu:
  New
Status in network-manager-l2tp package in Ubuntu:
  New
Status in wifi-qr package in Ubuntu:
  New

Bug description:
  The affected packages contain documentation or examples about
  NetworkManager keyfiles, which might not be appropriate anymore on
  Ubuntu, since the Netplan integration was enabled in NetworkManager
  (starting with Mantic), migrating any keyfile configuration from
  /etc/NetworkManager/system-connections/*[.nmconnection] to
  /etc/netplan/90-NM-*.yaml

  See Netplan's documentation for how connections are handled:
  https://netplan.readthedocs.io/en/latest/netplan-everywhere/

  PS: Packages were queried using:
  
https://codesearch.debian.net/search?q=%2Fsystem-connections=1=1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debian-handbook/+bug/2019939/+subscriptions


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

[Desktop-packages] [Bug 2019940] Re: Directly manipulating NetworkManager keyfiles

netcfg is not part of Ubuntu anymore (got dropped post Focal)

** Changed in: netcfg (Ubuntu)
   Status: New => Won't Fix

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2019940

Title:
  Directly manipulating NetworkManager keyfiles

Status in augeas package in Ubuntu:
  New
Status in calamares package in Ubuntu:
  New
Status in cloud-init package in Ubuntu:
  New
Status in cruft-ng package in Ubuntu:
  New
Status in dracut package in Ubuntu:
  New
Status in forensic-artifacts package in Ubuntu:
  New
Status in guestfs-tools package in Ubuntu:
  New
Status in guix package in Ubuntu:
  New
Status in ltsp package in Ubuntu:
  New
Status in netcfg package in Ubuntu:
  Won't Fix
Status in netplan.io package in Ubuntu:
  Won't Fix
Status in network-manager package in Ubuntu:
  New
Status in refpolicy package in Ubuntu:
  New
Status in sosreport package in Ubuntu:
  New
Status in uhd package in Ubuntu:
  New
Status in vagrant package in Ubuntu:
  New

Bug description:
  The affected packages can manipulate NetworkManager keyfiles directly
  on disk, which might not be appropriate anymore on Ubuntu, since the
  Netplan integration was enabled in NetworkManager (starting with
  Mantic), migrating any keyfile configuration from
  /etc/NetworkManager/system-connections/*[.nmconnection] to
  /etc/netplan/90-NM-*.yaml

  See Netplan's documentation for how connections are handled:
  https://netplan.readthedocs.io/en/latest/netplan-everywhere/

  PS: Packages were queried using:
  
https://codesearch.debian.net/search?q=%2Fsystem-connections=1=1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/augeas/+bug/2019940/+subscriptions


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

[Desktop-packages] [Bug 2019940] Re: Directly manipulating NetworkManager keyfiles

Netplan deals with keyfiles in /run/NetworkManager/system-connections
not /etc/...

** Changed in: netplan.io (Ubuntu)
   Status: New => Won't Fix

** Tags added: rls-mm-incoming

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2019940

Title:
  Directly manipulating NetworkManager keyfiles

Status in augeas package in Ubuntu:
  New
Status in calamares package in Ubuntu:
  New
Status in cloud-init package in Ubuntu:
  New
Status in cruft-ng package in Ubuntu:
  New
Status in dracut package in Ubuntu:
  New
Status in forensic-artifacts package in Ubuntu:
  New
Status in guestfs-tools package in Ubuntu:
  New
Status in guix package in Ubuntu:
  New
Status in ltsp package in Ubuntu:
  New
Status in netcfg package in Ubuntu:
  Won't Fix
Status in netplan.io package in Ubuntu:
  Won't Fix
Status in network-manager package in Ubuntu:
  New
Status in refpolicy package in Ubuntu:
  New
Status in sosreport package in Ubuntu:
  New
Status in uhd package in Ubuntu:
  New
Status in vagrant package in Ubuntu:
  New

Bug description:
  The affected packages can manipulate NetworkManager keyfiles directly
  on disk, which might not be appropriate anymore on Ubuntu, since the
  Netplan integration was enabled in NetworkManager (starting with
  Mantic), migrating any keyfile configuration from
  /etc/NetworkManager/system-connections/*[.nmconnection] to
  /etc/netplan/90-NM-*.yaml

  See Netplan's documentation for how connections are handled:
  https://netplan.readthedocs.io/en/latest/netplan-everywhere/

  PS: Packages were queried using:
  
https://codesearch.debian.net/search?q=%2Fsystem-connections=1=1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/augeas/+bug/2019940/+subscriptions


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

[Desktop-packages] [Bug 2019940] [NEW] Directly manipulating NetworkManager keyfiles

Public bug reported:

The affected packages can manipulate NetworkManager keyfiles directly on
disk, which might not be appropriate anymore on Ubuntu, since the
Netplan integration was enabled in NetworkManager (starting with
Mantic), migrating any keyfile configuration from
/etc/NetworkManager/system-connections/*[.nmconnection] to
/etc/netplan/90-NM-*.yaml

See Netplan's documentation for how connections are handled:
https://netplan.readthedocs.io/en/latest/netplan-everywhere/

PS: Packages were queried using:
https://codesearch.debian.net/search?q=%2Fsystem-connections=1=1

** Affects: augeas (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: calamares (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: cloud-init (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: cruft-ng (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: dracut (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: forensic-artifacts (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: guestfs-tools (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: guix (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: ltsp (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: netcfg (Ubuntu)
 Importance: Undecided
 Status: Won't Fix

** Affects: netplan.io (Ubuntu)
 Importance: Undecided
 Status: Won't Fix

** Affects: network-manager (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: refpolicy (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: sosreport (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: uhd (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: vagrant (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: netplan-everywhere rls-mm-incoming

** Also affects: netplan.io (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: cloud-init (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: netcfg (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: sosreport (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: calamares (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: guestfs-tools (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: cruft-ng (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: guix (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: refpolicy (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: augeas (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: ltsp (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: forensic-artifacts (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: dracut (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: uhd (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: vagrant (Ubuntu)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/2019940

Title:
  Directly manipulating NetworkManager keyfiles

Status in augeas package in Ubuntu:
  New
Status in calamares package in Ubuntu:
  New
Status in cloud-init package in Ubuntu:
  New
Status in cruft-ng package in Ubuntu:
  New
Status in dracut package in Ubuntu:
  New
Status in forensic-artifacts package in Ubuntu:
  New
Status in guestfs-tools package in Ubuntu:
  New
Status in guix package in Ubuntu:
  New
Status in ltsp package in Ubuntu:
  New
Status in netcfg package in Ubuntu:
  Won't Fix
Status in netplan.io package in Ubuntu:
  Won't Fix
Status in network-manager package in Ubuntu:
  New
Status in refpolicy package in Ubuntu:
  New
Status in sosreport package in Ubuntu:
  New
Status in uhd package in Ubuntu:
  New
Status in vagrant package in Ubuntu:
  New

Bug description:
  The affected packages can manipulate NetworkManager keyfiles directly
  on disk, which might not be appropriate anymore on Ubuntu, since the
  Netplan integration was enabled in NetworkManager (starting with
  Mantic), migrating any keyfile configuration from
  /etc/NetworkManager/system-connections/*[.nmconnection] to
  /etc/netplan/90-NM-*.yaml

  See Netplan's documentation for how connections are handled:
  https://netplan.readthedocs.io/en/latest/netplan-everywhere/

  PS: Packages were queried using:
  
https://codesearch.debian.net/search?q=%2Fsystem-connections=1=1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/augeas/+bug/2019940/+subscriptions


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

[Desktop-packages] [Bug 2019939] [NEW] Outdated documentation about NetworkManager keyfiles