[Touch-packages] [Bug 1988119] Re: systemd-udevd: Run net_setup_link on 'change' uevents to prevent DNS outages on Azure

[Matthew Ruffell]

Attached is the second patch required to fully fix this bug. It adds a
check on preinstall to see if ID_NET_DRIVER is present on the network
interface, and if it is missing, call udevadm trigger -c add on the
interface to add it.

** Patch added: "Debdiff for systemd on Bionic part two"
   
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1988119/+attachment/5613890/+files/lp1988119_bionic_part_two.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1988119

Title:
  systemd-udevd: Run net_setup_link on 'change' uevents to prevent DNS
  outages on Azure

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Fix Committed

Bug description:
  [Impact]

  A widespread outage was caused on Azure instances earlier today, when
  systemd 237-3ubuntu10.54 was published to the bionic-security pocket.
  Instances could no longer resolve DNS queries, breaking networking.

  For affected users, the following workarounds are available. Use whatever is 
most convenient.
  - Reboot your instances
  - or -
  - Issue "udevadm trigger -cadd -yeth0 && systemctl restart systemd-networkd" 
as root

  The trigger was found to be open-vm-tools issuing "udevadm trigger".
  Azure has a specific netplan setup that uses the `driver` match to set
  up networking. If a udevadm trigger is executed, the KV pair that
  contains this info is lost. Next time netplan is executed, the server
  loses it's DNS information.

  This is the same as bug 1902960 experienced on Focal two years ago.

  The root cause was found to be a bug in systemd, where if we receive a
  "Remove" action from a change uevent, we need to run net_setup_link(),
  we need to skip device rename and keep the old name.

  [Testcase]

  Start an instance up on Azure, any type. Simply issue udevadm trigger
  and reload systemd-networkd:

  $ ping google.com
  PING google.com (172.253.62.102) 56(84) bytes of data.
  64 bytes from bc-in-f102.1e100.net (172.253.62.102): icmp_seq=1 ttl=56 
time=1.85 ms
  $ sudo udevadm trigger && sudo systemctl restart systemd-networkd
  $ ping google.com
  ping: google.com: Temporary failure in name resolution

  To fix a broken instance, you can run:

  $ sudo udevadm trigger -cadd -yeth0 && sudo systemctl restart systemd-
  networkd

  and then install the test packages below:

  Test packages are available in the following ppa:

  https://launchpad.net/~mruffell/+archive/ubuntu/sf343528-test

  If you install them, the issue should no longer occur.

  [Where problems could occur]

  If a regression were to occur, it would affect systemd-udevd
  processing 'change' events from network devices, which could lead to
  network outages. Since this would happen when systemd-networkd is
  restarted on postinstall, a regression would cause widespread outages
  due to this SRU being targeted to the security pocket, where
  unattended-upgrades will automatically install from.

  Side effects could include incorrect udevd device properties.

  It is very important that this SRU is well tested before release.

  [Other info]

  This was fixed in Systemd 247 with the following commit:

  commit e0e789c1e97e2cdf1cafe0c6b7d7e43fa054f151
  Author: Yu Watanabe 
  Date: Mon, 14 Sep 2020 15:21:04 +0900
  Subject: udev: re-assign ID_NET_DRIVER=, ID_NET_LINK_FILE=, ID_NET_NAME= 
properties on non-'add' uevent
  Link: 
https://github.com/systemd/systemd/commit/e0e789c1e97e2cdf1cafe0c6b7d7e43fa054f151

  This was backported to Focal's systemd 245.4-4ubuntu3.4 in bug 1902960
  two years ago. Focal required a heavy backport, which was performed by
  Dan Streetman. Focals backport can be found in d/p/lp1902960-udev-re-
  assign-ID_NET_DRIVER-ID_NET_LINK_FILE-ID_NET.patch, or the below
  pastebin:

  https://paste.ubuntu.com/p/K5k7bGt3Wx/

  The changes between the Focal backport and the Bionic backport are:

  - We use udev_device_get_action() instead of device_get_action()
  - device_action_from_string() is used to get to enum DeviceAction
  - We return 0 from the "if (a == DEVICE_ACTION_MOVE) " hunk instead of "goto 
no_rename"
  - log_device_* has been changed to log_*.

  See attached debdiff for Bionic backport.

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


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

[Touch-packages] [Bug 1988796] Re: Incorrect rendering triggered by cairo CAIRO_OPERATOR_SATURATE with subpixel positioning

[Benjamin Gilbert]

This is a debdiff for the focal version of pixman, 0.38.4-0ubuntu1.
I've built and installed this and verified that the test case now
reports "OK".

** Patch added: "1-0.38.4-0ubuntu2.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/pixman/+bug/1988796/+attachment/5613889/+files/1-0.38.4-0ubuntu2.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pixman in Ubuntu.
https://bugs.launchpad.net/bugs/1988796

Title:
  Incorrect rendering triggered by cairo CAIRO_OPERATOR_SATURATE with
  subpixel positioning

Status in pixman package in Ubuntu:
  New

Bug description:
  pixman 0.38.4-0ubuntu1 in focal (and actually pixman 0.38.x generally)
  has a regression that causes incorrect rendering in some
  circumstances.  This can be triggered by the use of cairo with
  CAIRO_OPERATOR_SATURATE and subpixel positioning, and causes OpenSlide
   to produce incorrect output.

  The attached test program will print "Failed" if the bug exists, or
  "OK" if it doesn't.

  This is fixed upstream in
  https://gitlab.freedesktop.org/pixman/pixman/-/commit/8256c235, which
  is in pixman 0.40.0.

  See https://github.com/openslide/openslide/issues/278 for more
  context.

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


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

[Touch-packages] [Bug 1988796] [NEW] Incorrect rendering triggered by cairo CAIRO_OPERATOR_SATURATE with subpixel positioning

[Benjamin Gilbert]

Public bug reported:

pixman 0.38.4-0ubuntu1 in focal (and actually pixman 0.38.x generally)
has a regression that causes incorrect rendering in some circumstances.
This can be triggered by the use of cairo with CAIRO_OPERATOR_SATURATE
and subpixel positioning, and causes OpenSlide 
to produce incorrect output.

The attached test program will print "Failed" if the bug exists, or "OK"
if it doesn't.

This is fixed upstream in
https://gitlab.freedesktop.org/pixman/pixman/-/commit/8256c235, which is
in pixman 0.40.0.

See https://github.com/openslide/openslide/issues/278 for more context.

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

** Attachment added: "Test program"
   https://bugs.launchpad.net/bugs/1988796/+attachment/5613888/+files/pixman.c

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pixman in Ubuntu.
https://bugs.launchpad.net/bugs/1988796

Title:
  Incorrect rendering triggered by cairo CAIRO_OPERATOR_SATURATE with
  subpixel positioning

Status in pixman package in Ubuntu:
  New

Bug description:
  pixman 0.38.4-0ubuntu1 in focal (and actually pixman 0.38.x generally)
  has a regression that causes incorrect rendering in some
  circumstances.  This can be triggered by the use of cairo with
  CAIRO_OPERATOR_SATURATE and subpixel positioning, and causes OpenSlide
   to produce incorrect output.

  The attached test program will print "Failed" if the bug exists, or
  "OK" if it doesn't.

  This is fixed upstream in
  https://gitlab.freedesktop.org/pixman/pixman/-/commit/8256c235, which
  is in pixman 0.40.0.

  See https://github.com/openslide/openslide/issues/278 for more
  context.

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


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

[Touch-packages] [Bug 1988777] Re: libgail-3-0 dependencies cause a complete downgrade/uninstall of various packages

[Enrico Labedzki]

** Description changed:

  Hi,
  
  i have a fresh 22.04-LTS install on my new Huawei laptop, i tried and
  reviewed some mail clients and came to the conclusion to choose
  "evolution" as my new client, but my problem is i can't install
- "evolution" because some of his dependencies have too strong constrains,
+ "evolution" because some of his dependencies have to strong constrains,
  one of them is "libgail-3-0" which has "libgtk-3-0 (= 3.24.33-1ubuntu1)"
  as dependency, which causes a downgrade/uninstall of some required
  packages, look at this console output:
  
  -- %< ---
  root@ebony:~# apt-get install evolution
  Reading package lists... Done
  Building dependency tree... Done
  Reading state information... Done
  Some packages could not be installed. This may mean that you have
  requested an impossible situation or if you are using the unstable
  distribution that some required packages have not yet been created
  or been moved out of Incoming.
  The following information may help to resolve the situation:
  
  The following packages have unmet dependencies:
   libgail-3-0 : Depends: libgtk-3-0 (= 3.24.33-1ubuntu1) but 3.24.33-1ubuntu2 
is to be installed
  E: Unable to correct problems, you have held broken packages.
  
  root@ebony:~# apt-get install evolution libgtk-3-0=3.24.33-1ubuntu1
  Reading package lists... Done
  Building dependency tree... Done
  Reading state information... Done
  The following packages were automatically installed and are no longer 
required:
    apg gir1.2-accountsservice-1.0 gir1.2-adw-1 gir1.2-clutter-1.0 
gir1.2-cogl-1.0 gir1.2-coglpango-1.0 gir1.2-dbusmenu-glib-0.4 gir1.2-dee-1.0 
gir1.2-gck-1 gir1.2-gcr-3 gir1.2-gdata-0.0
    gir1.2-gdm-1.0 gir1.2-geoclue-2.0 gir1.2-gnomebluetooth-3.0 
gir1.2-graphene-1.0 gir1.2-gsound-1.0 gir1.2-gtk-4.0 gir1.2-gweather-3.0 
gir1.2-json-1.0 gir1.2-nautilus-3.0 gir1.2-nm-1.0
    gir1.2-nma-1.0 gir1.2-rsvg-2.0 gir1.2-unity-7.0 gir1.2-upowerglib-1.0 
gkbd-capplet gnome-bluetooth-3-common gnome-control-center-faces 
gnome-online-accounts gstreamer1.0-pipewire
    libcolord-gtk1 libfreerdp-server2-2 libgnome-bluetooth-3.0-13 
libgnomekbd-common libgnomekbd8 libgsound0 libgupnp-av-1.0-3 
libgupnp-dlna-2.0-4 libmediaart-2.0-0 librygel-core-2.6-2
    librygel-db-2.6-2 librygel-renderer-2.6-2 librygel-server-2.6-2 
libsoup-3.0-0 libsoup-3.0-common libtext-engine-0.1-0 libvncserver1 
libxklavier16 mobile-broadband-provider-info
    network-manager-gnome policykit-1-gnome python3-certifi python3-chardet 
python3-debconf python3-debian python3-idna python3-macaroonbakery python3-nacl 
python3-nautilus python3-protobuf
    python3-pymacaroons python3-requests python3-rfc3339 python3-tz 
python3-urllib3 rygel sshfs switcheroo-control update-notifier-common xwayland
  Use 'apt autoremove' to remove them.
  The following additional packages will be installed:
    bogofilter bogofilter-bdb bogofilter-common evolution-common 
evolution-plugin-bogofilter evolution-plugin-pstimport evolution-plugins 
libchamplain-0.12-0 libchamplain-gtk-0.12-0
    libcmark0.30.2 libevolution libgail-3-0 libgnome-autoar-gtk-0-0 libpst4 
libytnef0 notification-daemon policykit-1-gnome
  Suggested packages:
    db5.3-util doc-base evolution-ews evolution-plugins-experimental
  Recommended packages:
    libgtk-3-bin
  The following packages will be REMOVED:
    chrome-gnome-shell gdm3 gir1.2-mutter-10 gnome-control-center 
gnome-remote-desktop gnome-shell gnome-shell-extension-appindicator 
gnome-shell-extension-desktop-icons-ng
    gnome-shell-extension-gsconnect gnome-shell-extension-gsconnect-browsers 
gnome-shell-extension-manager gnome-shell-extension-ubuntu-dock libgtk-3-bin 
libmutter-10-0 ubuntu-desktop
    ubuntu-desktop-minimal ubuntu-release-upgrader-gtk ubuntu-session 
update-manager update-notifier
  The following NEW packages will be installed:
    bogofilter bogofilter-bdb bogofilter-common evolution evolution-common 
evolution-plugin-bogofilter evolution-plugin-pstimport evolution-plugins 
libchamplain-0.12-0 libchamplain-gtk-0.12-0
    libcmark0.30.2 libevolution libgail-3-0 libgnome-autoar-gtk-0-0 libpst4 
libytnef0 notification-daemon policykit-1-gnome
  The following packages will be DOWNGRADED:
    libgtk-3-0
  0 upgraded, 18 newly installed, 1 downgraded, 20 to remove and 0 not upgraded.
  Need to get 8.602 kB of archives.
  After this operation, 16,0 MB of additional disk space will be used.
  Do you want to continue? [Y/n] N
  Abort.
  
  -- %< 
  
  as you can see, this will downgrade and therefore destroy my entire
  setup.
  
  I'm not sure if i should send a email to the package maintainer directly
  or better file a bug here (i decided to try the later one).
  
  those packages are involved:
  
  -- %< 
  root@ebony:~# apt-cache policy evolution libgail-3-0 libgtk-3-0
  evolution:
    Installed: (none)
    Candidate: 3.44.0-1
    Version table:
   3.44.0-1 500
  

[Touch-packages] [Bug 1988790] Re: Pulse Audio 15.99.1 Simultaneous Output "Set as fallback" Not Working

[Ubuntu Foundations Team Bug Bot]

** Package changed: ubuntu => alsa-driver (Ubuntu)

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

Title:
  Pulse Audio 15.99.1 Simultaneous Output "Set as fallback" Not Working

Status in alsa-driver package in Ubuntu:
  New

Bug description:
  I have a new install of Ubuntu Studio 22.04 which came with Pulse
  Audio 15.99.1. Simultaneous Output "Set as fallback" will not stay.
  After selecting the button I then adjust the volume and the system
  adjusts the volume of my first sound card.

  There is a PA v16.1 out now that fixed a unstable combined-sink. Not
  sure if that will correct the fall back problem. Any guidance will be
  helpful. I do remember installing PA from scratch is a nightmare and
  wouldn't know where to start. I would consider without detailed
  instructions.

  Please keep me in the loop on this progress. Looking forward to trying
  KDE on 22.04 but I require whole house volume control.

  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: alsa-base 1.0.25+dfsg-0ubuntu7
  ProcVersionSignature: Ubuntu 5.15.0-47.53-lowlatency 5.15.46
  Uname: Linux 5.15.0-47-lowlatency x86_64
  ApportVersion: 2.20.11-0ubuntu82.1
  Architecture: amd64
  CasperMD5CheckResult: unknown
  CurrentDesktop: KDE
  Date: Mon Sep  5 22:06:21 2022
  InstallationDate: Installed on 2022-09-05 (0 days ago)
  InstallationMedia: Ubuntu-Studio 22.04.1 LTS "Jammy Jellyfish" - Release 
amd64 (20220809)
  PackageArchitecture: all
  SourcePackage: alsa-driver
  Symptom: audio
  Symptom_AlsaPlaybackTest: ALSA playback test through plughw:HDMI successful
  Symptom_Card: Baffin HDMI/DP Audio [Radeon RX 550 640SP / RX 560/560X] - HDA 
ATI HDMI
  Symptom_Jack: Digital Out, HDMI
  Symptom_PulsePlaybackTest: PulseAudio playback test successful
  Symptom_Type: No sound at all
  Title: [System Product Name, ATI R6xx HDMI, Digital Out, HDMI] No sound at all
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 12/16/2019
  dmi.bios.release: 5.13
  dmi.bios.vendor: American Megatrends Inc.
  dmi.bios.version: 7704
  dmi.board.asset.tag: Default string
  dmi.board.name: CROSSHAIR VI HERO
  dmi.board.vendor: ASUSTeK COMPUTER INC.
  dmi.board.version: Rev 1.xx
  dmi.chassis.asset.tag: Default string
  dmi.chassis.type: 3
  dmi.chassis.vendor: Default string
  dmi.chassis.version: Default string
  dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr7704:bd12/16/2019:br5.13:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnCROSSHAIRVIHERO:rvrRev1.xx:cvnDefaultstring:ct3:cvrDefaultstring:skuSKU:
  dmi.product.family: To be filled by O.E.M.
  dmi.product.name: System Product Name
  dmi.product.sku: SKU
  dmi.product.version: System Version
  dmi.sys.vendor: System manufacturer

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1988790/+subscriptions


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

[Touch-packages] [Bug 1988790] [NEW] Pulse Audio 15.99.1 Simultaneous Output "Set as fallback" Not Working

[Launchpad Bug Tracker]

You have been subscribed to a public bug:

I have a new install of Ubuntu Studio 22.04 which came with Pulse Audio
15.99.1. Simultaneous Output "Set as fallback" will not stay. After
selecting the button I then adjust the volume and the system adjusts the
volume of my first sound card.

There is a PA v16.1 out now that fixed a unstable combined-sink. Not
sure if that will correct the fall back problem. Any guidance will be
helpful. I do remember installing PA from scratch is a nightmare and
wouldn't know where to start. I would consider without detailed
instructions.

Please keep me in the loop on this progress. Looking forward to trying
KDE on 22.04 but I require whole house volume control.

ProblemType: Bug
DistroRelease: Ubuntu 22.04
Package: alsa-base 1.0.25+dfsg-0ubuntu7
ProcVersionSignature: Ubuntu 5.15.0-47.53-lowlatency 5.15.46
Uname: Linux 5.15.0-47-lowlatency x86_64
ApportVersion: 2.20.11-0ubuntu82.1
Architecture: amd64
CasperMD5CheckResult: unknown
CurrentDesktop: KDE
Date: Mon Sep  5 22:06:21 2022
InstallationDate: Installed on 2022-09-05 (0 days ago)
InstallationMedia: Ubuntu-Studio 22.04.1 LTS "Jammy Jellyfish" - Release amd64 
(20220809)
PackageArchitecture: all
SourcePackage: alsa-driver
Symptom: audio
Symptom_AlsaPlaybackTest: ALSA playback test through plughw:HDMI successful
Symptom_Card: Baffin HDMI/DP Audio [Radeon RX 550 640SP / RX 560/560X] - HDA 
ATI HDMI
Symptom_Jack: Digital Out, HDMI
Symptom_PulsePlaybackTest: PulseAudio playback test successful
Symptom_Type: No sound at all
Title: [System Product Name, ATI R6xx HDMI, Digital Out, HDMI] No sound at all
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 12/16/2019
dmi.bios.release: 5.13
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 7704
dmi.board.asset.tag: Default string
dmi.board.name: CROSSHAIR VI HERO
dmi.board.vendor: ASUSTeK COMPUTER INC.
dmi.board.version: Rev 1.xx
dmi.chassis.asset.tag: Default string
dmi.chassis.type: 3
dmi.chassis.vendor: Default string
dmi.chassis.version: Default string
dmi.modalias: 
dmi:bvnAmericanMegatrendsInc.:bvr7704:bd12/16/2019:br5.13:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnCROSSHAIRVIHERO:rvrRev1.xx:cvnDefaultstring:ct3:cvrDefaultstring:skuSKU:
dmi.product.family: To be filled by O.E.M.
dmi.product.name: System Product Name
dmi.product.sku: SKU
dmi.product.version: System Version
dmi.sys.vendor: System manufacturer

** Affects: alsa-driver (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug jammy
-- 
Pulse Audio 15.99.1 Simultaneous Output "Set as fallback" Not Working
https://bugs.launchpad.net/bugs/1988790
You received this bug notification because you are a member of Ubuntu Touch 
seeded packages, which is subscribed to alsa-driver in Ubuntu.

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

[Touch-packages] [Bug 1988752] Re: i was trying to update intel graphic driver

[Daniel van Vugt]

Please don't install xserver-xorg-video-intel because it is old and
buggy.

The latest (and only) driver is the one that ships with Ubuntu by
default.


** Package changed: xorg (Ubuntu) => ubuntu

** Changed in: ubuntu
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to xorg in Ubuntu.
https://bugs.launchpad.net/bugs/1988752

Title:
  i was trying to update intel graphic driver

Status in Ubuntu:
  Invalid

Bug description:
  i was trying to update intel graphic driver
  commmands:
   sudo apt-get install xserver-xorg-video-intel
  apport-bug xorg

  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: xorg 1:7.7+23ubuntu2
  ProcVersionSignature: Ubuntu 5.15.0-47.51-generic 5.15.46
  Uname: Linux 5.15.0-47-generic x86_64
  ApportVersion: 2.20.11-0ubuntu82.1
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CasperMD5CheckResult: pass
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Sep  5 12:16:17 2022
  DistUpgraded: Fresh install
  DistroCodename: jammy
  DistroVariant: ubuntu
  GraphicsCard:
   Intel Corporation HD Graphics 530 [8086:1912] (rev 06) (prog-if 00 [VGA 
controller])
 Subsystem: Dell HD Graphics 530 [1028:06b9]
  InstallationDate: Installed on 2022-08-22 (13 days ago)
  InstallationMedia: Ubuntu 22.04.1 LTS "Jammy Jellyfish" - Release amd64 
(20220809.1)
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 002: ID 093a:2510 Pixart Imaging, Inc. Optical Mouse
   Bus 001 Device 003: ID 1a2c:2d23 China Resource Semico Co., Ltd Keyboard
   Bus 001 Device 004: ID 0b0e:0300 GN Netcom Jabra EVOLVE 20 MS
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: Dell Inc. OptiPlex 7040
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-47-generic 
root=UUID=c029192a-4687-48cc-a124-1bb0c5ffb5c5 ro quiet splash vt.handoff=7
  RebootRequiredPkgs: Error: path contained symlinks.
  SourcePackage: xorg
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 12/08/2021
  dmi.bios.release: 1.22
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 1.22.0
  dmi.board.name: 0HD5W2
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A01
  dmi.chassis.type: 3
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr1.22.0:bd12/08/2021:br1.22:svnDellInc.:pnOptiPlex7040:pvr:rvnDellInc.:rn0HD5W2:rvrA01:cvnDellInc.:ct3:cvr:sku06B9:
  dmi.product.family: OptiPlex
  dmi.product.name: OptiPlex 7040
  dmi.product.sku: 06B9
  dmi.sys.vendor: Dell Inc.
  version.compiz: compiz N/A
  version.libdrm2: libdrm2 2.4.110-1ubuntu1
  version.libgl1-mesa-dri: libgl1-mesa-dri 22.0.5-0ubuntu0.1
  version.libgl1-mesa-glx: libgl1-mesa-glx N/A
  version.xserver-xorg-core: xserver-xorg-core 2:21.1.3-2ubuntu2.1
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-2ubuntu1
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20210115-1
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 
1:1.0.17-2build1

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


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

[Touch-packages] [Bug 1966800] Autopkgtest regression report (systemd/245.4-4ubuntu3.18)

[Ubuntu SRU Bot]

All autopkgtests for the newly accepted systemd (245.4-4ubuntu3.18) for focal 
have finished running.
The following regressions have been reported in tests triggered by the package:

linux-gke-5.15/5.15.0-1015.18~20.04.1 (arm64, amd64)
netplan.io/0.104-0ubuntu2~20.04.2 (armhf)
linux-hwe-5.15/5.15.0-48.54~20.04.1 (armhf, amd64)
gvfs/1.44.1-1ubuntu1.1 (ppc64el)
linux-oracle-5.15/5.15.0-1016.20~20.04.1 (arm64)
linux-oracle-5.13/5.13.0-1036.43~20.04.1 (arm64)
linux-hwe-5.11/5.11.0-61.61 (arm64)
systemd/245.4-4ubuntu3.18 (armhf)


Please visit the excuses page listed below and investigate the failures, 
proceeding afterwards as per the StableReleaseUpdates policy regarding 
autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/focal/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1966800

Title:
  systemd locks up due to incorrect handling of time zone changes

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Fix Committed
Status in systemd package in Fedora:
  Unknown

Bug description:
  [Impact]

  This bug can cause systemd timers to lock up systems using the
  Europe/Dublin timezone if certain OnCalendar values are used. If the
  timer is enabled at boot, this bug prevents the system from booting.
  If the timer is started later, systemd becomes unresponsive.

  [Test Plan]

  * Create a systemd service and corresponding timer scheduled for 01:00
  on Sundays:

  $ cat /etc/systemd/system/lp-1966800-reproducer.timer
   [Unit]
   Description=LP 1966800 reproducer

   [Timer]
   OnCalendar=Sun *-*-* 01:00:00
   Persistent=true

   [Install]
   WantedBy=timers.target

   $ cat /etc/systemd/system/lp-1966800-reproducer.service
   [Service]
   ExecStart=/usr/bin/echo "LP 1966800 reproducer"

   $ systemctl daemon-reload

  * Set the date to 21 March, 2021 in the Europe/Dublin timezone (need
  to disable NTP first):

   $ timedatectl set-ntp false
   $ timedatectl set-time "2021-03-21"
   $ timedatectl set-timezone Europe/Dublin

  * Try to start the timer, and observe that systemd becomes
  unresponsive. This command will time out, as will `systemctl status`
  etc.

   $ systemctl start lp-1966800-reproducer.timer

  [Where problems could occur]

  The patch makes changes in the calendar spec code, which is used by
  systemd timers to determine the next time to trigger a timer. If this
  patch breaks something, it would be related to the triggering of
  systemd timers.

  [Original Description]

  Recently on systems in Ireland, systemd became unresponsive due the
  change from GMT to Irish Standard Time. This is due to Ireland being
  unique in having their standard time during the summer, unlike most
  regions.

  Related to: https://bugzilla.redhat.com/show_bug.cgi?id=1941335
  Fixed by: 
https://github.com/systemd/systemd-stable/commit/a8b66ca9af811148b67ee952ab32748f88b8bba3

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


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

[Touch-packages] [Bug 1959475] Autopkgtest regression report (systemd/245.4-4ubuntu3.18)

[Ubuntu SRU Bot]

All autopkgtests for the newly accepted systemd (245.4-4ubuntu3.18) for focal 
have finished running.
The following regressions have been reported in tests triggered by the package:

linux-gke-5.15/5.15.0-1015.18~20.04.1 (arm64, amd64)
netplan.io/0.104-0ubuntu2~20.04.2 (armhf)
linux-hwe-5.15/5.15.0-48.54~20.04.1 (armhf, amd64)
gvfs/1.44.1-1ubuntu1.1 (ppc64el)
linux-oracle-5.15/5.15.0-1016.20~20.04.1 (arm64)
linux-oracle-5.13/5.13.0-1036.43~20.04.1 (arm64)
linux-hwe-5.11/5.11.0-61.61 (arm64)
systemd/245.4-4ubuntu3.18 (armhf)


Please visit the excuses page listed below and investigate the failures, 
proceeding afterwards as per the StableReleaseUpdates policy regarding 
autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/focal/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1959475

Title:
  "machinectl shell" connections immediately terminated

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Fix Committed

Bug description:
  [Impact]

  This bug prevents users on Impish and newer from connecting to Focal
  systemd containers using `machinectl shell`. This limits users ability
  to manage containers spawned with systemd-nspawn.

  [Test Plan]

  On a Jammy host, do the following:

  * Install systemd-container and debootstrap if necessary:

$ sudo apt install debootstrap systemd-container

  * Create a Focal filesystem for the container:

$ sudo debootstrap --arch= focal
  /var/lib/containers/lp1959475/

  * Launch the container:

$ sudo systemd-nspawn -D /var/lib/containers/lp1959475/ --machine
  test-container

  * Inside the container, set a password for root and then exit:

$ passwd # Enter password when prompted
$ exit

  * Re-launch the container with -b option:

$ sudo systemd-nspawn -D /var/lib/containers/lp1959475/ --machine
  test-container -b

  * In a separate terminal window, try to connect to the container:

$ sudo machinectl shell test-container

  * Observe the "Connection to machine test-container terminated" error
  message.

  [Where problems could occur]

  The patch expands the case where the TERM variable is inherited from
  PID 1 when building an execution environment, e.g. for a container. If
  problems were to occur, it would be related to the value of TERM in
  environments forked off of PID 1.

  [Other Info]

  This bug occurs when trying to connect to a Focal container from e.g. a Jammy 
host. For SRU verification, the container
  should be Focal, and the host should be Jammy. The -proposed package should 
be installed in the Focal container.

  [Original Description]

  The command "machinectl shell" does not work in systemd
  249.9-0ubuntu2:

  $ sudo machinectl shell ns-xxx
  Connected to machine ns-xxx. Press ^] three times within 1s to exit session.

  Connection to machine ns-xxx terminated.

  The issue seems to be described here:
  
https://forum.manjaro.org/t/the-machinectl-shell-command-stopped-working-after-systemd-upgrade-to-250-2-1/99899
  https://github.com/systemd/systemd/issues/22234

  and solved here:

  
https://github.com/systemd/systemd/commit/e8cf09b2a2ad0d48e5493050d54251d5f512d9b6

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


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

[Touch-packages] [Bug 1979951] Autopkgtest regression report (systemd/245.4-4ubuntu3.18)

[Ubuntu SRU Bot]

All autopkgtests for the newly accepted systemd (245.4-4ubuntu3.18) for focal 
have finished running.
The following regressions have been reported in tests triggered by the package:

linux-gke-5.15/5.15.0-1015.18~20.04.1 (arm64, amd64)
netplan.io/0.104-0ubuntu2~20.04.2 (armhf)
linux-hwe-5.15/5.15.0-48.54~20.04.1 (armhf, amd64)
gvfs/1.44.1-1ubuntu1.1 (ppc64el)
linux-oracle-5.15/5.15.0-1016.20~20.04.1 (arm64)
linux-oracle-5.13/5.13.0-1036.43~20.04.1 (arm64)
linux-hwe-5.11/5.11.0-61.61 (arm64)
systemd/245.4-4ubuntu3.18 (armhf)


Please visit the excuses page listed below and investigate the failures, 
proceeding afterwards as per the StableReleaseUpdates policy regarding 
autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/focal/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1979951

Title:
  127.0.0.1/::1 removed from loopback interface if you configure extra
  IPs on lo (r104 regression/behaviour change)

Status in netplan.io package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Fix Released
Status in netplan.io source package in Focal:
  New
Status in systemd source package in Focal:
  Fix Committed
Status in netplan.io source package in Jammy:
  New
Status in systemd source package in Jammy:
  Fix Committed

Bug description:
  [Impact]

  Users who wish to configure additional addresses on lo may
  inadvertently remove the 127.0.0.1/8 address from the interface. And,
  because this only happens on the second invocation of `netplan apply`,
  it can create confusing breakages for users. Although this is not a
  recommended configuration, it was previously supported and the current
  behavior is a regression.

  [Test Plan]

  * Configure additional addresses on the lo interface. I am testing in
  a LXD container, so I added the following to /etc/netplan/10-lxc.yaml
  under `ethernets:`

  lo:
addresses: ["10.10.10.17/24","10.10.10.19/24"]

  * Apply the config, and then inspect the lo interface's addresses:

   $ netplan apply
   $ ip addr show dev lo

  * Observe that the 127.0.0.1/8 address is still present. Now, run the
  same commands again:

   $ netplan apply
   $ ip addr show dev lo

  * On an affected system, observe that the 127.0.0.1/8 address is now
  gone. On a patched system, the address should still be present.

  [Where problems could occur]

  The patch removes cases where systemd-networkd will drop foreign
  addresses from a managed link. If problems were to occur, it would be
  related to the addresses configured on a managed link.

  [Original Description]

  If you configure the loopback interface using netplan without listing
  the standard loopback addresses (127.0.0.1 / ::1) that are auto-
  configured on boot then they are removed by netplan in r104+ but were
  not in r103.

  Confusingly this only happens the second time "netplan apply" is
  invoked and not the first time.

  There is some argument this is not a valid configuration, however
  - It worked on r103 and broke in the r104 SRU for 20.04 and breaks on upgrade
  - Since it only occurs on the second "netplan apply" it is likely people will 
accidentally create a configuration that on first verification works but breaks 
later
  - Adding addresses to a loopback or dummy interface is a common need
  - There is no dummy interface support in Netplan
  - Removing the loopback IP doesn't immediately cause obvious breakage in an 
SSH session but causes all sorts of hard to diagnose issues with applications

  Thus I consider this a high priority regression because of the
  multiple ways this can break a system at an unexpected/unrelated time
  to when the original change was made.

  As a workaround you can add 127.0.0.1/::1 to the file and this seems
  to generally work and product almost the same configuration with the
  exception that "brd 127.255.255.255" is added to the "ip addr" output
  compared to the auto-created configuration. All of the different
  routing tables seem otherwise the tame.

  = Test Case =
  (1) Add IP configuration for lo to /etc/netplan/lo.yaml

  lo:
    match:
  name: lo
    addresses:
    - 10.10.10.17/24
    - 10.10.10.19/24

  (2) Run "netplan apply" and observe the "ip addr show dev lo" output. 
Expected: 127.0.0.1/::1 are still there.
  (3) Run "netplan apply" a second time and observe the "ip addr show dev lo" 
output. Expected: 127.0.0.1/::1 are now removed.
  (4) Repeat the same test under netplan r103. Expected: 127.0.0.1/::1 are 
still there in both cases.

  = Observations =

  I found this change of behaviour happens only in r104. It is suspected
  but not clear that this is due to the configuraiton diffing behaviour
  introduced in r104. It's not clear to me why it doesn't happen o

[Touch-packages] [Bug 1978079] Autopkgtest regression report (systemd/245.4-4ubuntu3.18)

[Ubuntu SRU Bot]

All autopkgtests for the newly accepted systemd (245.4-4ubuntu3.18) for focal 
have finished running.
The following regressions have been reported in tests triggered by the package:

linux-gke-5.15/5.15.0-1015.18~20.04.1 (arm64, amd64)
netplan.io/0.104-0ubuntu2~20.04.2 (armhf)
linux-hwe-5.15/5.15.0-48.54~20.04.1 (armhf, amd64)
gvfs/1.44.1-1ubuntu1.1 (ppc64el)
linux-oracle-5.15/5.15.0-1016.20~20.04.1 (arm64)
linux-oracle-5.13/5.13.0-1036.43~20.04.1 (arm64)
linux-hwe-5.11/5.11.0-61.61 (arm64)
systemd/245.4-4ubuntu3.18 (armhf)


Please visit the excuses page listed below and investigate the failures, 
proceeding afterwards as per the StableReleaseUpdates policy regarding 
autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/focal/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1978079

Title:
  EFI pstore not cleared on boot

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Impish:
  Won't Fix
Status in systemd source package in Jammy:
  Fix Released
Status in systemd source package in Kinetic:
  Fix Released

Bug description:
  [Impact]

  Systemd has a systemd-pstore component that scans the pstore on boot
  and if non-empty, takes all previously created dumps, transfers them
  into its journal and removes the pstore elements. This is very
  important on UEFI systems, which only have a limited amount of space
  for variables.

  In Ubuntu, the kernel is configured with CONFIG_EFI_VARS_PSTORE=m
  which means the EFI pstore support gets loaded dynamically. In all of
  my boots, this dynamic module loading happened *after* systemd tried
  to check for pstore variables. So systemd-pstore never starts and
  never clears the UEFI variable store. I see this happening in AWS on
  Graviton instances, which eventually run out of space to store the
  dumps. On real hardware, this behavior may lead to unbootable systems.

  ```
  $ systemctl status systemd-pstore
  ○ systemd-pstore.service - Platform Persistent Storage Archival
   Loaded: loaded (/lib/systemd/system/systemd-pstore.service; enabled; 
vendor preset: enabled)
   Active: inactive (dead)
    Condition: start condition failed at Thu 2022-06-09 09:11:41 UTC; 29min ago
   └─ ConditionDirectoryNotEmpty=/sys/fs/pstore was not met
     Docs: man:systemd-pstore(8)

  Jun 09 09:11:41 ip-172-31-0-61 systemd[1]: Condition check resulted in
  Platform Persistent Storage Archival being skipped.

  $ ls -la /sys/fs/pstore
  total 0
  drwxr-x--- 2 root root0 Jun  9 09:11 .
  drwxr-xr-x 8 root root0 Jun  9 09:11 ..
  -r--r--r-- 1 root root 1803 Jun  9 09:07 dmesg-efi-165476562001001
  -r--r--r-- 1 root root 1777 Jun  9 09:07 dmesg-efi-165476562002001
  -r--r--r-- 1 root root 1773 Jun  9 09:07 dmesg-efi-165476562003001
  -r--r--r-- 1 root root 1815 Jun  9 09:07 dmesg-efi-165476562004001
  -r--r--r-- 1 root root 1826 Jun  9 09:07 dmesg-efi-165476562005001
  -r--r--r-- 1 root root 1754 Jun  9 09:07 dmesg-efi-165476562006001
  -r--r--r-- 1 root root 1821 Jun  9 09:07 dmesg-efi-165476562007001
  -r--r--r-- 1 root root 1767 Jun  9 09:07 dmesg-efi-165476562008001
  -r--r--r-- 1 root root 1729 Jun  9 09:07 dmesg-efi-165476562009001
  -r--r--r-- 1 root root 1819 Jun  9 09:07 dmesg-efi-165476562010001
  -r--r--r-- 1 root root 1767 Jun  9 09:07 dmesg-efi-165476562011001
  -r--r--r-- 1 root root 1775 Jun  9 09:07 dmesg-efi-165476562012001
  -r--r--r-- 1 root root 1802 Jun  9 09:07 dmesg-efi-165476562013001
  -r--r--r-- 1 root root 1812 Jun  9 09:07 dmesg-efi-165476562014001
  -r--r--r-- 1 root root 1764 Jun  9 09:07 dmesg-efi-165476562015001
  -r--r--r-- 1 root root 1795 Jun  9 09:11 dmesg-efi-165476589801001
  -r--r--r-- 1 root root 1785 Jun  9 09:11 dmesg-efi-165476589802001
  -r--r--r-- 1 root root 1683 Jun  9 09:11 dmesg-efi-165476589803001
  -r--r--r-- 1 root root 1785 Jun  9 09:11 dmesg-efi-165476589804001
  -r--r--r-- 1 root root 1771 Jun  9 09:11 dmesg-efi-165476589805001
  -r--r--r-- 1 root root 1797 Jun  9 09:11 dmesg-efi-165476589806001
  -r--r--r-- 1 root root 1805 Jun  9 09:11 dmesg-efi-165476589807001
  -r--r--r-- 1 root root 1781 Jun  9 09:11 dmesg-efi-165476589808001
  -r--r--r-- 1 root root 1806 Jun  9 09:11 dmesg-efi-165476589809001
  -r--r--r-- 1 root root 1821 Jun  9 09:11 dmesg-efi-165476589810001
  -r--r--r-- 1 root root 1763 Jun  9 09:11 dmesg-efi-165476589811001
  -r--r--r-- 1 root root 1783 Jun  9 09:11 dmesg-efi-165476589812001
  -r--r--r-- 1 root root 1788 Jun  9 09:11 dmesg-efi-165476589813001
  -r--r--r-- 1 root root 1788 Jun  9 09:11 dmesg-efi-165476589814001
  -r--r--r-- 1 root root 1786 Jun  9 09:11 dmesg-efi-165476589815001
  ```

  This problem aff

[Touch-packages] [Bug 1982462] Autopkgtest regression report (systemd/245.4-4ubuntu3.18)

[Ubuntu SRU Bot]

All autopkgtests for the newly accepted systemd (245.4-4ubuntu3.18) for focal 
have finished running.
The following regressions have been reported in tests triggered by the package:

linux-gke-5.15/5.15.0-1015.18~20.04.1 (arm64, amd64)
netplan.io/0.104-0ubuntu2~20.04.2 (armhf)
linux-hwe-5.15/5.15.0-48.54~20.04.1 (armhf, amd64)
gvfs/1.44.1-1ubuntu1.1 (ppc64el)
linux-oracle-5.15/5.15.0-1016.20~20.04.1 (arm64)
linux-oracle-5.13/5.13.0-1036.43~20.04.1 (arm64)
linux-hwe-5.11/5.11.0-61.61 (arm64)
systemd/245.4-4ubuntu3.18 (armhf)


Please visit the excuses page listed below and investigate the failures, 
proceeding afterwards as per the StableReleaseUpdates policy regarding 
autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/focal/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1982462

Title:
  Some modprobe loading services requested by the pstore service fail

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Jammy:
  Fix Committed
Status in systemd source package in Kinetic:
  Fix Released

Bug description:
  [Impact]

  It has been detected that some modprobe services fail on UC22 after
  the jammy upgrade  249.11-0ubuntu3.4:

  $ systemctl --system --no-ask-password --no-pager list-units --state=failed
  Failed units:
UNIT LOAD   ACTIVE SUBDESCRIPTION
  ● modprobe@chromeos_pstore.service loaded failed failed Load Kernel Module 
chromeos_pstore
  ● modprobe@efi_pstore.service  loaded failed failed Load Kernel Module 
efi_pstore
  ● modprobe@mtdpstore.service   loaded failed failed Load Kernel Module 
mtdpstore
  ● modprobe@pstore_blk.service  loaded failed failed Load Kernel Module 
pstore_blk
  ● modprobe@pstore_zone.service loaded failed failed Load Kernel Module 
pstore_zone
  ● modprobe@ramoops.service loaded failed failed Load Kernel Module 
ramoops

  This happens because of some changes to systemd-pstore.service that
  now has:

  After=modprobe@efi_pstore.service modprobe@mtdpstore.service 
modprobe@chromeos_pstore.service modprobe@ramoops.service 
modprobe@pstore_zone.service modprobe@pstore_blk.service
  Wants=modprobe@efi_pstore.service modprobe@mtdpstore.service 
modprobe@chromeos_pstore.service modprobe@ramoops.service 
modprobe@pstore_zone.service modprobe@pstore_blk.service

  This causes too many tries of the modprobe services, that fail in the
  end with

  Jul 20 09:02:39 ubuntu systemd[1]: modprobe@chromeos_pstore.service:
  Start request repeated too quickly.

  Although we have seen this only on UC22, it potentially can affect
  classic systems as well, as systemd-pstore.service is re-tried there a
  few times too. See https://github.com/snapcore/core-base/issues/72 for
  more details.

  A fix for this is available upstream:
  
https://github.com/systemd/systemd/commit/9625350e5381a68c1179ae4581e7586c206663e1

  [Test Plan]

  Start the device and check that there is no modprobe-pstore related
  failed service. This is racy, so a few tries will be needed to make
  sure things are fine.

  [Where problems could occur]

  The modprobe services are usually dependencies from other services, so
  it should be fine if the retry behavior is controlled by those other
  services. Risk should be small. If something goes wrong we might see a
  lot of restarts for these services.

  [Other Info]

  Testing should happen on UC22 too.

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


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

[Touch-packages] [Bug 1940996] Re: test failure - test-regex

[Bug Watch Updater]

** Bug watch added: Debian Bug tracker #884075
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884075

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to grep in Ubuntu.
https://bugs.launchpad.net/bugs/1940996

Title:
  test failure - test-regex

Status in grep:
  In Progress
Status in grep package in Ubuntu:
  New

Bug description:
  'test-regex' fails when building grep against glibc 2.34.
  Per commentary from grep upstream at 
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=50069, 
  the test failure can be attributed to skew between the glibc built-in regex 
and the one that is found in the grep source code.

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


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

[Touch-packages] [Bug 1940996]

[Vincent-srcware]

(In reply to cvs-com...@gcc.gnu.org from comment #13)
> The master branch has been updated by Paul Eggert :
> 
> https://sourceware.org/git/gitweb.cgi?p=glibc.git;
> h=0b5ca7c3e551e5502f3be3b06453324fe8604e82
> 
> commit 0b5ca7c3e551e5502f3be3b06453324fe8604e82
> Author: Paul Eggert 
> Date:   Tue Sep 21 07:47:45 2021 -0700
[...]
> * Fix glibc bug 11053.

What is the status of this bug? The comment says that it is fixed, and I could 
check on an Ubuntu 22.04.1 LTS machine with libc6 2.35-0ubuntu3.1 that regbug.c 
and rebug2.c no longer fail, but the result is still incorrect with the grep 
example from Debian bug 884075:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884075

vinc17@gcc92:~$ echo 111 | grep -E '^(11+)\1+$|^1?$' ; echo $?
111
0

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to grep in Ubuntu.
https://bugs.launchpad.net/bugs/1940996

Title:
  test failure - test-regex

Status in grep:
  In Progress
Status in grep package in Ubuntu:
  New

Bug description:
  'test-regex' fails when building grep against glibc 2.34.
  Per commentary from grep upstream at 
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=50069, 
  the test failure can be attributed to skew between the glibc built-in regex 
and the one that is found in the grep source code.

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


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

[Touch-packages] [Bug 1988772] Re: kinetic livefs builds are failing on dns errors

[Launchpad Bug Tracker]

Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: systemd (Ubuntu)
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1988772

Title:
  kinetic livefs builds are failing on dns errors

Status in live-build package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  the livefs kinetic builds are still failing, every job failed for a
  week

  https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/kinetic/ubuntu

  >'Temporary failure resolving 'ftpmaster.internal'

  Colin poked at it and wrote

  > livecd-rootfs initially sets up a correct /etc/resolv.conf inside its build 
chroot; but then
  > systemd-resolved.postinst moves that aside in favour of a symlink to 
/run/systemd/resolve/stub-
  > resolv.conf, but systemd-resolved itself isn't running because 
livecd-rootfs builds in a chroot, 
  > not a container

  he also suggested that it could be perhaps handled from live-build
  scripts/build/lb_chroot_resolv

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/live-build/+bug/1988772/+subscriptions


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

[Touch-packages] [Bug 1988777] Re: libgail-3-0 dependencies cause a complete downgrade/uninstall of various packages

[Enrico Labedzki]

** Description changed:

  Hi,
  
- i have a fresh 22.04-LTS install on my new Huawei laptop, i tried some
- mail clients and came to the conclusion to use "evolution".
- 
- My problem is but i can't install "evolution" some of his dependencies
- has to strong constrains,  one of them is "libgail-3-0" which has a
- "libgtk-3-0 (= 3.24.33-1ubuntu1)" as a dependency, which causes a
- downgrade/uninstall of some required packages, look at this console
- output:
+ i have a fresh 22.04-LTS install on my new Huawei laptop, i tried and
+ reviewed some mail clients and came to the conclusion to choose
+ "evolution" as my new client, but my problem is i can't install
+ "evolution" because some of his dependencies have too strong constrains,
+ one of them is "libgail-3-0" which has "libgtk-3-0 (= 3.24.33-1ubuntu1)"
+ as dependency, which causes a downgrade/uninstall of some required
+ packages, look at this console output:
  
  -- %< ---
  root@ebony:~# apt-get install evolution
  Reading package lists... Done
  Building dependency tree... Done
  Reading state information... Done
  Some packages could not be installed. This may mean that you have
  requested an impossible situation or if you are using the unstable
  distribution that some required packages have not yet been created
  or been moved out of Incoming.
  The following information may help to resolve the situation:
  
  The following packages have unmet dependencies:
-  libgail-3-0 : Depends: libgtk-3-0 (= 3.24.33-1ubuntu1) but 3.24.33-1ubuntu2 
is to be installed
+  libgail-3-0 : Depends: libgtk-3-0 (= 3.24.33-1ubuntu1) but 3.24.33-1ubuntu2 
is to be installed
  E: Unable to correct problems, you have held broken packages.
- 
  
  root@ebony:~# apt-get install evolution libgtk-3-0=3.24.33-1ubuntu1
  Reading package lists... Done
  Building dependency tree... Done
  Reading state information... Done
  The following packages were automatically installed and are no longer 
required:
-   apg gir1.2-accountsservice-1.0 gir1.2-adw-1 gir1.2-clutter-1.0 
gir1.2-cogl-1.0 gir1.2-coglpango-1.0 gir1.2-dbusmenu-glib-0.4 gir1.2-dee-1.0 
gir1.2-gck-1 gir1.2-gcr-3 gir1.2-gdata-0.0
-   gir1.2-gdm-1.0 gir1.2-geoclue-2.0 gir1.2-gnomebluetooth-3.0 
gir1.2-graphene-1.0 gir1.2-gsound-1.0 gir1.2-gtk-4.0 gir1.2-gweather-3.0 
gir1.2-json-1.0 gir1.2-nautilus-3.0 gir1.2-nm-1.0
-   gir1.2-nma-1.0 gir1.2-rsvg-2.0 gir1.2-unity-7.0 gir1.2-upowerglib-1.0 
gkbd-capplet gnome-bluetooth-3-common gnome-control-center-faces 
gnome-online-accounts gstreamer1.0-pipewire
-   libcolord-gtk1 libfreerdp-server2-2 libgnome-bluetooth-3.0-13 
libgnomekbd-common libgnomekbd8 libgsound0 libgupnp-av-1.0-3 
libgupnp-dlna-2.0-4 libmediaart-2.0-0 librygel-core-2.6-2
-   librygel-db-2.6-2 librygel-renderer-2.6-2 librygel-server-2.6-2 
libsoup-3.0-0 libsoup-3.0-common libtext-engine-0.1-0 libvncserver1 
libxklavier16 mobile-broadband-provider-info
-   network-manager-gnome policykit-1-gnome python3-certifi python3-chardet 
python3-debconf python3-debian python3-idna python3-macaroonbakery python3-nacl 
python3-nautilus python3-protobuf
-   python3-pymacaroons python3-requests python3-rfc3339 python3-tz 
python3-urllib3 rygel sshfs switcheroo-control update-notifier-common xwayland
+   apg gir1.2-accountsservice-1.0 gir1.2-adw-1 gir1.2-clutter-1.0 
gir1.2-cogl-1.0 gir1.2-coglpango-1.0 gir1.2-dbusmenu-glib-0.4 gir1.2-dee-1.0 
gir1.2-gck-1 gir1.2-gcr-3 gir1.2-gdata-0.0
+   gir1.2-gdm-1.0 gir1.2-geoclue-2.0 gir1.2-gnomebluetooth-3.0 
gir1.2-graphene-1.0 gir1.2-gsound-1.0 gir1.2-gtk-4.0 gir1.2-gweather-3.0 
gir1.2-json-1.0 gir1.2-nautilus-3.0 gir1.2-nm-1.0
+   gir1.2-nma-1.0 gir1.2-rsvg-2.0 gir1.2-unity-7.0 gir1.2-upowerglib-1.0 
gkbd-capplet gnome-bluetooth-3-common gnome-control-center-faces 
gnome-online-accounts gstreamer1.0-pipewire
+   libcolord-gtk1 libfreerdp-server2-2 libgnome-bluetooth-3.0-13 
libgnomekbd-common libgnomekbd8 libgsound0 libgupnp-av-1.0-3 
libgupnp-dlna-2.0-4 libmediaart-2.0-0 librygel-core-2.6-2
+   librygel-db-2.6-2 librygel-renderer-2.6-2 librygel-server-2.6-2 
libsoup-3.0-0 libsoup-3.0-common libtext-engine-0.1-0 libvncserver1 
libxklavier16 mobile-broadband-provider-info
+   network-manager-gnome policykit-1-gnome python3-certifi python3-chardet 
python3-debconf python3-debian python3-idna python3-macaroonbakery python3-nacl 
python3-nautilus python3-protobuf
+   python3-pymacaroons python3-requests python3-rfc3339 python3-tz 
python3-urllib3 rygel sshfs switcheroo-control update-notifier-common xwayland
  Use 'apt autoremove' to remove them.
  The following additional packages will be installed:
-   bogofilter bogofilter-bdb bogofilter-common evolution-common 
evolution-plugin-bogofilter evolution-plugin-pstimport evolution-plugins 
libchamplain-0.12-0 libchamplain-gtk-0.12-0
-   libcmark0.30.2 libevolution libgail-3-0 libgnome-autoar-gtk-0-0 libpst4 
libytnef0 notification-daemon policykit-1-gnome
+   bogofilter bogofilter-bdb bogofilter-common evolution-common

[Touch-packages] [Bug 1979951] Autopkgtest regression report (systemd/249.11-0ubuntu3.5)

[Ubuntu SRU Bot]

All autopkgtests for the newly accepted systemd (249.11-0ubuntu3.5) for jammy 
have finished running.
The following regressions have been reported in tests triggered by the package:

gvfs/1.48.2-0ubuntu1 (ppc64el)
systemd/249.11-0ubuntu3.5 (ppc64el)
udisks2/2.9.4-1ubuntu2 (arm64)


Please visit the excuses page listed below and investigate the failures, 
proceeding afterwards as per the StableReleaseUpdates policy regarding 
autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/jammy/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1979951

Title:
  127.0.0.1/::1 removed from loopback interface if you configure extra
  IPs on lo (r104 regression/behaviour change)

Status in netplan.io package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Fix Released
Status in netplan.io source package in Focal:
  New
Status in systemd source package in Focal:
  Fix Committed
Status in netplan.io source package in Jammy:
  New
Status in systemd source package in Jammy:
  Fix Committed

Bug description:
  [Impact]

  Users who wish to configure additional addresses on lo may
  inadvertently remove the 127.0.0.1/8 address from the interface. And,
  because this only happens on the second invocation of `netplan apply`,
  it can create confusing breakages for users. Although this is not a
  recommended configuration, it was previously supported and the current
  behavior is a regression.

  [Test Plan]

  * Configure additional addresses on the lo interface. I am testing in
  a LXD container, so I added the following to /etc/netplan/10-lxc.yaml
  under `ethernets:`

  lo:
addresses: ["10.10.10.17/24","10.10.10.19/24"]

  * Apply the config, and then inspect the lo interface's addresses:

   $ netplan apply
   $ ip addr show dev lo

  * Observe that the 127.0.0.1/8 address is still present. Now, run the
  same commands again:

   $ netplan apply
   $ ip addr show dev lo

  * On an affected system, observe that the 127.0.0.1/8 address is now
  gone. On a patched system, the address should still be present.

  [Where problems could occur]

  The patch removes cases where systemd-networkd will drop foreign
  addresses from a managed link. If problems were to occur, it would be
  related to the addresses configured on a managed link.

  [Original Description]

  If you configure the loopback interface using netplan without listing
  the standard loopback addresses (127.0.0.1 / ::1) that are auto-
  configured on boot then they are removed by netplan in r104+ but were
  not in r103.

  Confusingly this only happens the second time "netplan apply" is
  invoked and not the first time.

  There is some argument this is not a valid configuration, however
  - It worked on r103 and broke in the r104 SRU for 20.04 and breaks on upgrade
  - Since it only occurs on the second "netplan apply" it is likely people will 
accidentally create a configuration that on first verification works but breaks 
later
  - Adding addresses to a loopback or dummy interface is a common need
  - There is no dummy interface support in Netplan
  - Removing the loopback IP doesn't immediately cause obvious breakage in an 
SSH session but causes all sorts of hard to diagnose issues with applications

  Thus I consider this a high priority regression because of the
  multiple ways this can break a system at an unexpected/unrelated time
  to when the original change was made.

  As a workaround you can add 127.0.0.1/::1 to the file and this seems
  to generally work and product almost the same configuration with the
  exception that "brd 127.255.255.255" is added to the "ip addr" output
  compared to the auto-created configuration. All of the different
  routing tables seem otherwise the tame.

  = Test Case =
  (1) Add IP configuration for lo to /etc/netplan/lo.yaml

  lo:
    match:
  name: lo
    addresses:
    - 10.10.10.17/24
    - 10.10.10.19/24

  (2) Run "netplan apply" and observe the "ip addr show dev lo" output. 
Expected: 127.0.0.1/::1 are still there.
  (3) Run "netplan apply" a second time and observe the "ip addr show dev lo" 
output. Expected: 127.0.0.1/::1 are now removed.
  (4) Repeat the same test under netplan r103. Expected: 127.0.0.1/::1 are 
still there in both cases.

  = Observations =

  I found this change of behaviour happens only in r104. It is suspected
  but not clear that this is due to the configuraiton diffing behaviour
  introduced in r104. It's not clear to me why it doesn't happen on the
  first "netplan apply".

  I also found a recent upstream systemd commit to prevent networkd removing 
127.0.0.1/::1 which solves this issue on r104 as well. It's possible this is a 
better fix to backport to solve this:
  
https://github.com

[Touch-packages] [Bug 1979952] Autopkgtest regression report (systemd/249.11-0ubuntu3.5)

[Ubuntu SRU Bot]

All autopkgtests for the newly accepted systemd (249.11-0ubuntu3.5) for jammy 
have finished running.
The following regressions have been reported in tests triggered by the package:

gvfs/1.48.2-0ubuntu1 (ppc64el)
systemd/249.11-0ubuntu3.5 (ppc64el)
udisks2/2.9.4-1ubuntu2 (arm64)


Please visit the excuses page listed below and investigate the failures, 
proceeding afterwards as per the StableReleaseUpdates policy regarding 
autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/jammy/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1979952

Title:
  Bind mount to NFS mount fails on Ubuntu 22.04

Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Jammy:
  Fix Committed
Status in systemd source package in Kinetic:
  Fix Released

Bug description:
  [Impact]
  Some NFS setups that have worked on previous versions of Ubuntu are now 
broken. Specifically, when creating a bind mount, systemd will fail if the 
directory already exists on NFS.

  [Test Plan]
  This test plan requires an NFS server to be in place. The exact setup is not 
important, but for the purposes of this test plan we will assume the server 
exports /data, which contains a directory called home.

  * Make sure nfs-common is installed:

   $ apt install nfs-common -y

  * Check the NFS server exports using showmount:

   $ showmount -e $NFS_SERVER_IP
   Export list for $NFS_SERVER_IP:
   /data *

  * Add the appropriate entries to /etc/fstab. In this example, we will
  make /home2 a bind mount to /data/home:

   # /etc/fstab
   $NFS_SERVER_IP:/data /data nfs defaults,nfsvers=3 0 0
   /data/home /home2 none bind,_netdev,x-systemd.requires-mounts-for=/data 0 0

  * Check systemctl status home2.mount. On an affected system, we should
  see a permission denied error:

   $ systemctl status home2.mount
   x home2.mount - /home2
Loaded: loaded (/etc/fstab; generated)
Active: failed (Result: resources)
 Where: /home2
  What: /data/home
  Docs: man:fstab(5)
man:systemd-fstab-generator(8)

   systemd[1]: home2.mount: Failed to make bind mount source '/data/home': 
Permission denied
   systemd[1]: home2.mount: Failed to run 'mount' task: Permission denied
   systemd[1]: home2.mount: Failed with result 'resources'.
   systemd[1]: Failed to mount /home2.

  * On a patched system, we expect /home2 to be mounted successfully.

  [Where problems could occur]
  The patch makes it so that systemd will not fail bind mounts immediately if 
creating the directory fails. Thus, any regressions would be seen during bind 
mounts with systemd. N.B. that this patch restores previous behavior in systemd.

  [Original Description]
  I have the following setup:
  - /data is an NFS mount.
  - /home is a bind mount to /data/home.

  Configured in /etc/fstab with these lines:

  $FILE_SERVER:/data /data nfs defaults 0 0
  /data/home /home none bind,_netdev,x-systemd.requires-mounts-for=/data 0 0

  This has worked with the same configuration for me on at least Ubuntu 18.04 
and Ubuntu 20.04, but on Ubuntu 22.04 the mount of /home fails when attempted 
by systemd.
  So not only is /home not mounted after boot, but also when I run "sudo 
systemctl start home.mount", it fails.

  The journal entries are this:

  sudo[1316]:  wendler : TTY=pts/0 ; PWD=/home/wendler ; USER=root ; 
COMMAND=/usr/bin/systemctl start home.mount
  sudo[1316]: pam_unix(sudo:session): session opened for user root(uid=0) by 
wendler(uid=1000)
  systemd[1]: home.mount: Directory /home to mount over is not empty, mounting 
anyway.
  systemd[1]: home.mount: Failed to make bind mount source '/data/home': 
Permission denied
  systemd[1]: home.mount: Failed to run 'mount' task: Permission denied
  systemd[1]: home.mount: Failed with result 'resources'.
  systemd[1]: Failed to mount /home.

  However, when I run "sudo mount /home" it works.

  Now the weird thing is that after I have mounted /home manually once
  and unmounted it again, then "sudo systemctl start home.mount"
  suddenly also works! But of course only until the next reboot.

  And even if I just do "ls /data" once (either as root or as my user),
  it also makes "sudo systemctl start home.mount" start working!

  To be fully clear:

  - Booting the system (/home fails to mount)
  - sudo systemctl start home.mount  # fails
  - sudo ls /data  # shows correct output
  - sudo systemctl start home.mount  # works!

  Additional information:

  The NFS export for /data has root_squash set and if I remove this
  option, the bind mount of /home works as it should. However, both
  /data and /data/home have mode rwxr-xr-x, so root is able to enter and
  read these di

[Touch-packages] [Bug 1975667] Autopkgtest regression report (systemd/249.11-0ubuntu3.5)

[Ubuntu SRU Bot]

All autopkgtests for the newly accepted systemd (249.11-0ubuntu3.5) for jammy 
have finished running.
The following regressions have been reported in tests triggered by the package:

gvfs/1.48.2-0ubuntu1 (ppc64el)
systemd/249.11-0ubuntu3.5 (ppc64el)
udisks2/2.9.4-1ubuntu2 (arm64)


Please visit the excuses page listed below and investigate the failures, 
proceeding afterwards as per the StableReleaseUpdates policy regarding 
autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/jammy/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1975667

Title:
  systemd-resolved does not reset DNS server and search domain list
  properly after VPN disconnect

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Jammy:
  Fix Committed

Bug description:
  [Impact]

  Networking components such as VPNs that rely on systemd-resolved's API
  to configure search domains may inadvertently leave the network
  configuration in a bad state. This is a result of a broken systemd-
  resolved API.

  [Test Plan]
  * On a jammy host, configure a couple search domains with resolvectl:

  $ resolvectl domain  search1.internal search2.internal
  $ resolvectl domain 

  * In any case, both domains should be displayed. Then, attempt to
  clear the configured domains:

  $ resolvectl domain  ""
  $ resolvectl domain 

  * On a patched system, the two domains should no longer be displayed.
  On an un-patched system, one of the domains will still be configured.

  [Where problems could occur]
  This patch touches the logic that configures search domains in 
systemd-resolved. If the patch caused regressions, it would be related to the 
set of configured search domains.

  [Original Description]

  Hi,
  in Ubuntu 21.10 I am facing a problem with DNS server list and search domain 
list is not properly reset back to the previous values after a VPN is 
disconnected. I reproduced this in Ubuntu 21.10 instance which was upgraded 
from the older version of Ubuntu as well as in Live USB Ubuntu 21.10 so it is 
not an "upgrade issue".

  I use this resolv.conf symlink:
  /etc/resolv.conf -> ../run/systemd/resolve/resolv.conf

  Actual behavior:
  VPN connect will add VPN's DNS servers and search domains into 
/etc/resolv.conf. When VPN is disconnected there are some of the VPN's DNS 
server and search domain entries left there, so it is not reset back properly.

  Desired behavior:
  VPN connect will add VPN's DNS servers and search domains into 
/etc/resolv.conf. When VPN is disconnected DNS servers and search domain list 
is restored to exactly the same state as was prior to the VPN connection.

  Steps for reproducing:
  1. Before VPN is connected this is the DNS server and search domain list in 
/etc/resolv.conf:

  nameserver 192.168.122.1
  search .

  2. Once the VPN is connected, we see there were VPN's DNS server and
  serach domain list entries added:

  nameserver 2xx.xx.xx.x0
  nameserver 2xx.xx.xx.x1
  nameserver 192.168.122.1
  search domain1.local domain2.internal domain3.internal

  3. After VPN disconnection, we see the DNS server and search domain
  list in /etc/resolv.conf is not restored to the state at point (1.)
  and some entries from VPN is being kept there:

  nameserver 2xx.xx.xx.x1
  nameserver 192.168.122.1
  search domain2.internal domain3.internal

  ProblemType: Bug
  DistroRelease: Ubuntu 21.10
  Package: systemd 248.3-1ubuntu8
  ProcVersionSignature: Ubuntu 5.13.0-19.19-generic 5.13.14
  Uname: Linux 5.13.0-19-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.11-0ubuntu70
  Architecture: amd64
  CasperMD5CheckResult: pass
  CasperVersion: 1.465
  CurrentDesktop: ubuntu:GNOME
  Date: Wed May 25 06:06:05 2022
  LiveMediaBuild: Ubuntu 21.10 "Impish Indri" - Release amd64 (20211012)
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd QEMU USB Tablet
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  Lsusb-t:
   /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/15p, 5000M
   /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/15p, 480M
   |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 
480M
  MachineType: QEMU Standard PC (Q35 + ICH9, 2009)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/casper/vmlinuz 
file=/cdrom/preseed/username.seed maybe-ubiquity quiet splash ---
  SourcePackage: systemd
  SystemdDelta:
   [EXTENDED]   /usr/lib/systemd/system/rc-local.service → 
/usr/lib/systemd/system/rc-local.service.d/debian.conf

[Touch-packages] [Bug 1897932] Autopkgtest regression report (systemd/249.11-0ubuntu3.5)

[Ubuntu SRU Bot]

All autopkgtests for the newly accepted systemd (249.11-0ubuntu3.5) for jammy 
have finished running.
The following regressions have been reported in tests triggered by the package:

gvfs/1.48.2-0ubuntu1 (ppc64el)
systemd/249.11-0ubuntu3.5 (ppc64el)
udisks2/2.9.4-1ubuntu2 (arm64)


Please visit the excuses page listed below and investigate the failures, 
proceeding afterwards as per the StableReleaseUpdates policy regarding 
autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/jammy/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1897932

Title:
  systemd-repart not packaged

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Jammy:
  Fix Committed
Status in systemd package in Debian:
  Fix Released

Bug description:
  [Impact]

  systemd-repart is not (as of 246.6-1ubuntu1) packaged in the
  Ubuntu/Debian packages of systemd - probably because it has an extra
  dependency?

  The bug reporter would like to use it in their new raspberry pi images
  where they don't have cloud-init installed. The reporter is already
  using systemd-growfs, but they are missing the nice partition resizing
  part (so are using cloud-initramfs-growroot).

  Furthermore, in the mkosi image builder
  (https://github.com/systemd/mkosi), the systemd/mkosi developers would
  like to start using systemd-repart for partitioning. Unfortunately,
  they're currently blocked on this because 22.04 doesn't ship systemd-
  repart. The upstream CI uses Github Actions which runs on Ubuntu Jammy
  and will do so until the next Ubuntu LTS is released. If we have to
  wait for the next LTS to be released, we'll have to wait for a
  considerable amount of time before we're able to start using systemd-
  repart.

  Being able to use systemd-repart will allow the systemd/mkosi developers to 
take advantage of its improved interface compared to sfdisk,
  as well as its builtin protections against race conditions surrounding the 
use of loop devices. The systemd/mkosi developers expect to
  be able to get rid of some nasty loop device failure in mkosi by using 
systemd-repart.

  [Test Plan]
  This is a missing extra executable. Once enabled it has self-tests in the 
build-time unit tests, and also a regression test in the autopkgtest 'upstream' 
suite.

  * Attach (local) build-log showing the systemd-repart self-tests passing, as 
found in build-deb/meson-logs/testlog.txt
  * Attach autopkgtest logs showing the regression tests passing (especially 
TEST-58-REPART from "upstream-2" testsuite)
  * Test upgrade-path Jammy->Kinetic to make sure systemd-repart is properly 
replaced by Kinetic's "systemd" binary package

  [Where problems could occur]
  Shipping systemd-repart will come with no additional risk. While there is a 
systemd-repart.service that runs on boot, it's configured to not do anything if 
no config files are shipped with the system or provided by the user. As such, 
the service, if enabled, will effectively be a noop. Aside from the service, 
there's the CLI tool systemd-repart and the accompanying man pages that will be 
shipped as part of the systemd package.

  Given that there's no risk involved with enabling systemd-repart, and
  given the useful features it provides, the systemd/mkosi developers
  would like to request that systemd-repart be enabled in Ubuntu and
  backported to Jammy so that they can start adopting it in mkosi.

  Runtime behavior of existing components is not affected by the build
  config change.

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


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

[Touch-packages] [Bug 1982462] Autopkgtest regression report (systemd/249.11-0ubuntu3.5)

[Ubuntu SRU Bot]

All autopkgtests for the newly accepted systemd (249.11-0ubuntu3.5) for jammy 
have finished running.
The following regressions have been reported in tests triggered by the package:

gvfs/1.48.2-0ubuntu1 (ppc64el)
systemd/249.11-0ubuntu3.5 (ppc64el)
udisks2/2.9.4-1ubuntu2 (arm64)


Please visit the excuses page listed below and investigate the failures, 
proceeding afterwards as per the StableReleaseUpdates policy regarding 
autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/jammy/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1982462

Title:
  Some modprobe loading services requested by the pstore service fail

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Jammy:
  Fix Committed
Status in systemd source package in Kinetic:
  Fix Released

Bug description:
  [Impact]

  It has been detected that some modprobe services fail on UC22 after
  the jammy upgrade  249.11-0ubuntu3.4:

  $ systemctl --system --no-ask-password --no-pager list-units --state=failed
  Failed units:
UNIT LOAD   ACTIVE SUBDESCRIPTION
  ● modprobe@chromeos_pstore.service loaded failed failed Load Kernel Module 
chromeos_pstore
  ● modprobe@efi_pstore.service  loaded failed failed Load Kernel Module 
efi_pstore
  ● modprobe@mtdpstore.service   loaded failed failed Load Kernel Module 
mtdpstore
  ● modprobe@pstore_blk.service  loaded failed failed Load Kernel Module 
pstore_blk
  ● modprobe@pstore_zone.service loaded failed failed Load Kernel Module 
pstore_zone
  ● modprobe@ramoops.service loaded failed failed Load Kernel Module 
ramoops

  This happens because of some changes to systemd-pstore.service that
  now has:

  After=modprobe@efi_pstore.service modprobe@mtdpstore.service 
modprobe@chromeos_pstore.service modprobe@ramoops.service 
modprobe@pstore_zone.service modprobe@pstore_blk.service
  Wants=modprobe@efi_pstore.service modprobe@mtdpstore.service 
modprobe@chromeos_pstore.service modprobe@ramoops.service 
modprobe@pstore_zone.service modprobe@pstore_blk.service

  This causes too many tries of the modprobe services, that fail in the
  end with

  Jul 20 09:02:39 ubuntu systemd[1]: modprobe@chromeos_pstore.service:
  Start request repeated too quickly.

  Although we have seen this only on UC22, it potentially can affect
  classic systems as well, as systemd-pstore.service is re-tried there a
  few times too. See https://github.com/snapcore/core-base/issues/72 for
  more details.

  A fix for this is available upstream:
  
https://github.com/systemd/systemd/commit/9625350e5381a68c1179ae4581e7586c206663e1

  [Test Plan]

  Start the device and check that there is no modprobe-pstore related
  failed service. This is racy, so a few tries will be needed to make
  sure things are fine.

  [Where problems could occur]

  The modprobe services are usually dependencies from other services, so
  it should be fine if the retry behavior is controlled by those other
  services. Risk should be small. If something goes wrong we might see a
  lot of restarts for these services.

  [Other Info]

  Testing should happen on UC22 too.

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


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

[Touch-packages] [Bug 1981622] Autopkgtest regression report (systemd/249.11-0ubuntu3.5)

[Ubuntu SRU Bot]

All autopkgtests for the newly accepted systemd (249.11-0ubuntu3.5) for jammy 
have finished running.
The following regressions have been reported in tests triggered by the package:

gvfs/1.48.2-0ubuntu1 (ppc64el)
systemd/249.11-0ubuntu3.5 (ppc64el)
udisks2/2.9.4-1ubuntu2 (arm64)


Please visit the excuses page listed below and investigate the failures, 
proceeding afterwards as per the StableReleaseUpdates policy regarding 
autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/jammy/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1981622

Title:
  mtd device must be supplied (device name is empty)

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Triaged
Status in systemd source package in Jammy:
  Fix Committed

Bug description:
  [WORKAROUND]

  This will NOT fix a system that is not booting, because the "mtd
  device must be supplied (device name is empty)" message is not the
  cause of failed boots. This work around is only for those who are
  annoyed by the error message, but are otherwise not experiencing any
  issues.

  If you are not able to boot your system, but you see this error
  message, please open a separate bug with your journalctl and dmesg
  logs.

  # cp /{lib,etc}/systemd/system/systemd-pstore.service
  # sed -i 's/modprobe@mtdpstore.service //' 
/etc/systemd/system/systemd-pstore.service
  # systemctl daemon-reload

  [Impact]

  Due to mtdpstore not being properly configured as a pstore backend,
  when systemd-pstore.service tries to load the module, users get the
  following error in dmesg:

  [   18.453473] systemd[1]: Starting Load Kernel Module mtdpstore...
  [   18.462685] mtd device must be supplied (device name is empty)

  This is a distracting error for users trying to diagnose other system
  issues, especially if their system does not boot after a kernel crash
  and this is the only message displayed on the console.

  [Test Plan]

  * Force a kernel crash to populate /sys/fs/pstore, thus causing
  systemd-pstore.service to start on the subsequent boot:

  # echo 1 > /proc/sys/kernel/sysrq
  # echo 1 > /proc/sys/kernel/panic
  # echo c > /proc/sysrq-trigger

  * When the system reboots, observe the error in dmesg:

  # dmesg | grep mtd

  [Where problems could occur]

  If a system was relying on this pstore backend, and mtdpstore is built
  as a module, it is possible for systemd-pstore.service to trigger
  before mtdpstore is loaded, causing systemd-pstore to not copy the
  contents of /sys/fs/pstore. Note however that before the patched
  introduced as a result of bug 1978079, systemd-pstore.service would
  not attempt to load *any* kernel modules.

  [Original Description]

  After updating my 22.04 system (possibly caused by Systemd update).
  And now booting, dmesg has two errors:

  'mtd device must be supplied (device name is empty)'.

  See line 8 and 134 in the included logfile.

  The system are booting as it should though, and the system are working
  like it should no errors at all.

  Is this maybe caused by 'efi-pstore-not-cleared-on-boot.patch' in
  systemd?

  I have an EFI mounted at boot but it isn't used because I have
  installed my system in legacy BIOS mode.

  Is this maybe the culprit?

  I could ignore the message but it isn't nice though.

  Regards

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


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

[Touch-packages] [Bug 1981042] Autopkgtest regression report (systemd/249.11-0ubuntu3.5)

[Ubuntu SRU Bot]

All autopkgtests for the newly accepted systemd (249.11-0ubuntu3.5) for jammy 
have finished running.
The following regressions have been reported in tests triggered by the package:

gvfs/1.48.2-0ubuntu1 (ppc64el)
systemd/249.11-0ubuntu3.5 (ppc64el)
udisks2/2.9.4-1ubuntu2 (arm64)


Please visit the excuses page listed below and investigate the failures, 
proceeding afterwards as per the StableReleaseUpdates policy regarding 
autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/jammy/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1981042

Title:
  /etc/localtime symlink not correctly handled when using /etc/writable

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Jammy:
  Fix Committed
Status in systemd source package in Kinetic:
  Fix Released

Bug description:
  [Impact]
  When using /etc/writable (e.g. Ubuntu Core) /etc/localtime is a symlink to 
/etc/writable/localtime (which in itself if a symlink). Systemd doesn't handle 
this correctly when doing firstboot or using inotify to watch for changes to 
localtime.

  [Test Plan]
  This is somewhat hard to test, the following situations need to be reproduced:
  - On firstboot the timezone link will not be read correctly, it will with 
this change.
  - Starting a timer unit and then changing timezone will cause it not to occur 
at the correct time.

  [Where problems could occur]
  This could potentially break other users of localtime, however the change is 
similar to existing changes which have been in Ubuntu's version of systemd for 
some time. The change detects the /etc/writable case and if not should have the 
same existing behaviour.

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


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

[Touch-packages] [Bug 1988078] Autopkgtest regression report (systemd/249.11-0ubuntu3.5)

[Ubuntu SRU Bot]

All autopkgtests for the newly accepted systemd (249.11-0ubuntu3.5) for jammy 
have finished running.
The following regressions have been reported in tests triggered by the package:

gvfs/1.48.2-0ubuntu1 (ppc64el)
systemd/249.11-0ubuntu3.5 (ppc64el)
udisks2/2.9.4-1ubuntu2 (arm64)


Please visit the excuses page listed below and investigate the failures, 
proceeding afterwards as per the StableReleaseUpdates policy regarding 
autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/jammy/update_excuses.html#systemd

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1988078

Title:
  Please backport systemd-hwdb patches to support src:systemd-hwe tests

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Jammy:
  Fix Committed

Bug description:
  [Impact]

  We plan to SRU src:systemd-hwe to Jammy[1] to provide an easier way to
  SRU HWE hwdb rules to Ubuntu. The src:systemd-hwe package contains a
  test script[2] to ensure that no redundant hwdb rules are added to the
  package, i.e. rules that are already present in src:systemd. This test
  requires patches to implement --root flag support for the `systemd-
  hwdb query` command[3]. These patches are already present in kinetic.

  Without these patches in Jammy, src:systemd-hwe would have to disable
  these tests, which are important to maintaining HWE hwdb rules in
  Ubuntu.

  [1] https://bugs.launchpad.net/ubuntu/+source/systemd-hwe/+bug/1983996
  [2] 
https://git.launchpad.net/~canonical-foundations/+git/systemd-hwe/tree/tests/hwdb-redundancy?h=main
  [3] https://github.com/systemd/systemd/pull/23518

  [Test plan]

  * Create a new directory for testing hwdb rule queries:

  $ mkdir -p fakeroot/etc/udev/hdwb.d

  * Add a new .hwdb file to override an existing rule. For example, I
  chose to override the last entry from
  /lib/udev/hdwb.d/60-keyboard.hwdb:

  $ tail -2 /lib/udev/hwdb.d/60-keyboard.hwdb > 
fakeroot/etc/udev/hwdb.d/60-keyboard.hwdb
  $ sed -i 's/chromebook/reserved/g' fakeroot/etc/udev/hwdb.d/60-keyboard.hwdb 
  $ cat fakeroot/etc/udev/hwdb.d/60-keyboard.hwdb 
  evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer*:pnPeppy:*
   XKB_FIXED_MODEL=reserved

  * Create the hwdb.bin within fakeroot:

  $ systemd-hwdb update --root fakeroot
  $ ls fakeroot/etc/udev/hwdb.bin 
  fakeroot/etc/udev/hwdb.bin

  * Finally, attempt to query this new hwdb.bin using systemd-hwdb
  query. On an unpatched system, we will see results from the system's
  hwdb.bin:

  $ systemd-hwdb query --root fakeroot 
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer*:pnPeppy:* | grep XKB_FIXED_MODEL
  XKB_FIXED_MODEL=chromebook

  ...and on a patched system we should see the overridden rule:

  $ systemd-hwdb query --root fakeroot 
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer*:pnPeppy:* | grep XKB_FIXED_MODEL
  XKB_FIXED_MODEL=reserved 

  [Where problems could occur]
  The patches add support for the --root flag when calling systemd-hwdb query, 
thus changing the behavior of this command (previously, query would always load 
the system's hwdb.bin). It is unlikely that existing scripts try to use the 
--root flag with `systemd-hwdb query`, but if they did, this is where we would 
see problems.

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


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

[Touch-packages] [Bug 1988772] Re: kinetic livefs builds are failing on dns errors

[Steve Langasek]

If the systemd-resolved postinst doesn't work correctly in a chroot, I
think the problem needs to be fixed there, not worked around in the live
build system

** Also affects: systemd (Ubuntu)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1988772

Title:
  kinetic livefs builds are failing on dns errors

Status in live-build package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  New

Bug description:
  the livefs kinetic builds are still failing, every job failed for a
  week

  https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/kinetic/ubuntu

  >'Temporary failure resolving 'ftpmaster.internal'

  Colin poked at it and wrote

  > livecd-rootfs initially sets up a correct /etc/resolv.conf inside its build 
chroot; but then
  > systemd-resolved.postinst moves that aside in favour of a symlink to 
/run/systemd/resolve/stub-
  > resolv.conf, but systemd-resolved itself isn't running because 
livecd-rootfs builds in a chroot, 
  > not a container

  he also suggested that it could be perhaps handled from live-build
  scripts/build/lb_chroot_resolv

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/live-build/+bug/1988772/+subscriptions


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

[Touch-packages] [Bug 1986984] Re: [FFe] tzdata 2022c update

[Tomas Gonzalez]

Hi. I have Ubuntu 16 Xenial servers. Is there any way I can update tzdata? 
Up till now, I've noticed that my version is from Jan 2021 after running apt 
update and install tzdata, so I figure Xenial won't update further than that.
Can this be fixed in some way?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to tzdata in Ubuntu.
https://bugs.launchpad.net/bugs/1986984

Title:
  [FFe] tzdata 2022c update

Status in tzdata package in Ubuntu:
  Fix Released
Status in tzdata source package in Xenial:
  Confirmed
Status in tzdata source package in Bionic:
  Fix Released
Status in tzdata source package in Focal:
  Fix Released
Status in tzdata source package in Jammy:
  Fix Released
Status in tzdata source package in Kinetic:
  Fix Released

Bug description:
  New timezone data, with the following timezones impacted:
  - Chile will spring forward on 2022-09-11, not 2022-09-04 (America/Santiago)
  - Iran no longer observes DST (Asia/Tehran)

  Verification is done with 'zdump'. The first timezone that gets
  changed in the updated package is dumped with 'zdump -v
  $region/$timezone_that_changed' (this needs to be greped for in
  /usr/share/zoneinfo/). [For example: 'zdump -v Asia/Gaza'.] This is
  compared to the same output after the updated package got installed.
  If those are different the verification is considered done.

  [Test Case for all releases]
  1) zdump -v America/Santiago | grep 'Sep.*2022'
-> should indicate Sep 11, not Sep 4
  2) zdump -v Asia/Tehran | tail
-> last dates should be in 2022, not in 2499

  [Test Case for releases >= 20.04 LTS]

  For releases with ICU timezone data verification is done using the following 
with dates before and after the change:
  1) sudo apt-get install python3-icu
  2) Run the following python script:

  from datetime import datetime
  from icu import ICUtzinfo, TimeZone
  tz = ICUtzinfo(TimeZone.createTimeZone("America/Santiago"))
  always_before = datetime(2022, 9, 1)
  now_before = datetime(2022, 9, 8)
  always_after = datetime(2022, 9, 12)
  assert(tz.utcoffset(always_before) == tz.utcoffset(now_before))
  assert(tz.utcoffset(now_before) != tz.utcoffset(always_after))

  The assertions would crash on 2022a.

  [Test Case for releases <= 20.04 LTS]

  Additionally, an upstream update of tzdata removed the 'old' SystemV 
timezones, so we should ensure that they are kept in Ubuntu 20.04 LTS and 
earlier releases. Subsequently, these should be checked for using the following:
  diff <(zdump -v America/Phoenix | cut -d' ' -f2-) <(zdump -v SystemV/MST7 | 
cut -d' ' -f2-)

  Nothing should be returned by the above command.

  [Original report]
  tzdata 2022b and 2022c were just released that includes some timezone changes 
for Chile. According to the tzdata lib listed for Ubuntu 20.04, the latest 
package is 2022a. Any idea when 2022b or 2022c will be available? Chile made a 
change to the start of their daylight savings and pushed it from Sept 4th to 
the 11th, so we really need our servers updated before the 4th.

  Thanks

  Jason

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


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

[Touch-packages] [Bug 1982462] Re: Some modprobe loading services requested by the pstore service fail

[Alfonso Sanchez-Beato]

I have tested core20 built using the proposed pocket and I can confirm
that the issue does not appear (no failed services on start up).

I have also tested the focal deb on classic and the modprobe services do
not fail either:

root@focal:~# apt policy systemd
systemd:
  Installed: 245.4-4ubuntu3.18
  Candidate: 245.4-4ubuntu3.18
  Version table:
 *** 245.4-4ubuntu3.18 500
500 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 Packages
100 /var/lib/dpkg/status
 245.4-4ubuntu3.17 500
500 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages
 245.4-4ubuntu3.15 500
500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages
 245.4-4ubuntu3 500
500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages


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

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1982462

Title:
  Some modprobe loading services requested by the pstore service fail

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Jammy:
  Fix Committed
Status in systemd source package in Kinetic:
  Fix Released

Bug description:
  [Impact]

  It has been detected that some modprobe services fail on UC22 after
  the jammy upgrade  249.11-0ubuntu3.4:

  $ systemctl --system --no-ask-password --no-pager list-units --state=failed
  Failed units:
UNIT LOAD   ACTIVE SUBDESCRIPTION
  ● modprobe@chromeos_pstore.service loaded failed failed Load Kernel Module 
chromeos_pstore
  ● modprobe@efi_pstore.service  loaded failed failed Load Kernel Module 
efi_pstore
  ● modprobe@mtdpstore.service   loaded failed failed Load Kernel Module 
mtdpstore
  ● modprobe@pstore_blk.service  loaded failed failed Load Kernel Module 
pstore_blk
  ● modprobe@pstore_zone.service loaded failed failed Load Kernel Module 
pstore_zone
  ● modprobe@ramoops.service loaded failed failed Load Kernel Module 
ramoops

  This happens because of some changes to systemd-pstore.service that
  now has:

  After=modprobe@efi_pstore.service modprobe@mtdpstore.service 
modprobe@chromeos_pstore.service modprobe@ramoops.service 
modprobe@pstore_zone.service modprobe@pstore_blk.service
  Wants=modprobe@efi_pstore.service modprobe@mtdpstore.service 
modprobe@chromeos_pstore.service modprobe@ramoops.service 
modprobe@pstore_zone.service modprobe@pstore_blk.service

  This causes too many tries of the modprobe services, that fail in the
  end with

  Jul 20 09:02:39 ubuntu systemd[1]: modprobe@chromeos_pstore.service:
  Start request repeated too quickly.

  Although we have seen this only on UC22, it potentially can affect
  classic systems as well, as systemd-pstore.service is re-tried there a
  few times too. See https://github.com/snapcore/core-base/issues/72 for
  more details.

  A fix for this is available upstream:
  
https://github.com/systemd/systemd/commit/9625350e5381a68c1179ae4581e7586c206663e1

  [Test Plan]

  Start the device and check that there is no modprobe-pstore related
  failed service. This is racy, so a few tries will be needed to make
  sure things are fine.

  [Where problems could occur]

  The modprobe services are usually dependencies from other services, so
  it should be fine if the retry behavior is controlled by those other
  services. Risk should be small. If something goes wrong we might see a
  lot of restarts for these services.

  [Other Info]

  Testing should happen on UC22 too.

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


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

[Touch-packages] [Bug 1988777] [NEW] libgail-3-0 dependencies cause a complete downgrade/uninstall of various packages

[Enrico Labedzki]

Public bug reported:

Hi,

i have a fresh 22.04-LTS install on my new Huawei laptop, i tried some
mail clients and came to the conclusion to use "evolution".

My problem is but i can't install "evolution" some of his dependencies
has to strong constrains,  one of them is "libgail-3-0" which has a
"libgtk-3-0 (= 3.24.33-1ubuntu1)" as a dependency, which causes a
downgrade/uninstall of some required packages, look at this console
output:

-- %< ---
root@ebony:~# apt-get install evolution
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libgail-3-0 : Depends: libgtk-3-0 (= 3.24.33-1ubuntu1) but 3.24.33-1ubuntu2 is 
to be installed
E: Unable to correct problems, you have held broken packages.


root@ebony:~# apt-get install evolution libgtk-3-0=3.24.33-1ubuntu1
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
  apg gir1.2-accountsservice-1.0 gir1.2-adw-1 gir1.2-clutter-1.0 
gir1.2-cogl-1.0 gir1.2-coglpango-1.0 gir1.2-dbusmenu-glib-0.4 gir1.2-dee-1.0 
gir1.2-gck-1 gir1.2-gcr-3 gir1.2-gdata-0.0
  gir1.2-gdm-1.0 gir1.2-geoclue-2.0 gir1.2-gnomebluetooth-3.0 
gir1.2-graphene-1.0 gir1.2-gsound-1.0 gir1.2-gtk-4.0 gir1.2-gweather-3.0 
gir1.2-json-1.0 gir1.2-nautilus-3.0 gir1.2-nm-1.0
  gir1.2-nma-1.0 gir1.2-rsvg-2.0 gir1.2-unity-7.0 gir1.2-upowerglib-1.0 
gkbd-capplet gnome-bluetooth-3-common gnome-control-center-faces 
gnome-online-accounts gstreamer1.0-pipewire
  libcolord-gtk1 libfreerdp-server2-2 libgnome-bluetooth-3.0-13 
libgnomekbd-common libgnomekbd8 libgsound0 libgupnp-av-1.0-3 
libgupnp-dlna-2.0-4 libmediaart-2.0-0 librygel-core-2.6-2
  librygel-db-2.6-2 librygel-renderer-2.6-2 librygel-server-2.6-2 libsoup-3.0-0 
libsoup-3.0-common libtext-engine-0.1-0 libvncserver1 libxklavier16 
mobile-broadband-provider-info
  network-manager-gnome policykit-1-gnome python3-certifi python3-chardet 
python3-debconf python3-debian python3-idna python3-macaroonbakery python3-nacl 
python3-nautilus python3-protobuf
  python3-pymacaroons python3-requests python3-rfc3339 python3-tz 
python3-urllib3 rygel sshfs switcheroo-control update-notifier-common xwayland
Use 'apt autoremove' to remove them.
The following additional packages will be installed:
  bogofilter bogofilter-bdb bogofilter-common evolution-common 
evolution-plugin-bogofilter evolution-plugin-pstimport evolution-plugins 
libchamplain-0.12-0 libchamplain-gtk-0.12-0
  libcmark0.30.2 libevolution libgail-3-0 libgnome-autoar-gtk-0-0 libpst4 
libytnef0 notification-daemon policykit-1-gnome
Suggested packages:
  db5.3-util doc-base evolution-ews evolution-plugins-experimental
Recommended packages:
  libgtk-3-bin
The following packages will be REMOVED:
  chrome-gnome-shell gdm3 gir1.2-mutter-10 gnome-control-center 
gnome-remote-desktop gnome-shell gnome-shell-extension-appindicator 
gnome-shell-extension-desktop-icons-ng
  gnome-shell-extension-gsconnect gnome-shell-extension-gsconnect-browsers 
gnome-shell-extension-manager gnome-shell-extension-ubuntu-dock libgtk-3-bin 
libmutter-10-0 ubuntu-desktop
  ubuntu-desktop-minimal ubuntu-release-upgrader-gtk ubuntu-session 
update-manager update-notifier
The following NEW packages will be installed:
  bogofilter bogofilter-bdb bogofilter-common evolution evolution-common 
evolution-plugin-bogofilter evolution-plugin-pstimport evolution-plugins 
libchamplain-0.12-0 libchamplain-gtk-0.12-0
  libcmark0.30.2 libevolution libgail-3-0 libgnome-autoar-gtk-0-0 libpst4 
libytnef0 notification-daemon policykit-1-gnome
The following packages will be DOWNGRADED:
  libgtk-3-0
0 upgraded, 18 newly installed, 1 downgraded, 20 to remove and 0 not upgraded.
Need to get 8.602 kB of archives.
After this operation, 16,0 MB of additional disk space will be used.
Do you want to continue? [Y/n] N
Abort.

-- %< 

as u can see, this will downgrade and therefore destroy my entire setup.

i'm not sure if i should send a email to the package maintainer or file
a bug here (i decided to try the later one).

here some of system/setup infos:

-- %< 
root@ebony:~# inxi -b
System:
  Host: ebony Kernel: 5.15.0-47-generic x86_64 bits: 64 Desktop: GNOME 42.4
Distro: Ubuntu 22.04.1 LTS (Jammy Jellyfish)
Machine:
  Type: Laptop System: HUAWEI product: KLVL-WXX9 v: M1010
serial: YAVBB21831800177
  Mobo: HUAWEI model: KLVL-WXX9-PCB-B1 v: M1010 serial: BBGZ64218T000634
UEFI: HUAWEI v: 2.03 date: 08/09/2021
Battery:
  ID-1: BAT0 charge: 55.3 Wh (99.5%) condition: 55.6/54.9 Wh (101

[Touch-packages] [Bug 1982462] Re: Some modprobe loading services requested by the pstore service fail

[Alfonso Sanchez-Beato]

I have tested core22 built using the proposed pocket and I can confirm
that the issue is gone (no failed services on start up anymore).

I have also tested the jammy deb on classic and the modprobe services do
not fail either:

root@jammy:~# apt policy systemd
systemd:
  Installed: 249.11-0ubuntu3.5
  Candidate: 249.11-0ubuntu3.5
  Version table:
 *** 249.11-0ubuntu3.5 500
500 http://archive.ubuntu.com/ubuntu jammy-proposed/main amd64 Packages
100 /var/lib/dpkg/status
 249.11-0ubuntu3.4 500
500 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages
 249.11-0ubuntu3 500
500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages


** Tags removed: verification-needed-focal verification-needed-jammy
** Tags added: verification-done-jammy

** Tags added: verification-needed-focal

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1982462

Title:
  Some modprobe loading services requested by the pstore service fail

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Jammy:
  Fix Committed
Status in systemd source package in Kinetic:
  Fix Released

Bug description:
  [Impact]

  It has been detected that some modprobe services fail on UC22 after
  the jammy upgrade  249.11-0ubuntu3.4:

  $ systemctl --system --no-ask-password --no-pager list-units --state=failed
  Failed units:
UNIT LOAD   ACTIVE SUBDESCRIPTION
  ● modprobe@chromeos_pstore.service loaded failed failed Load Kernel Module 
chromeos_pstore
  ● modprobe@efi_pstore.service  loaded failed failed Load Kernel Module 
efi_pstore
  ● modprobe@mtdpstore.service   loaded failed failed Load Kernel Module 
mtdpstore
  ● modprobe@pstore_blk.service  loaded failed failed Load Kernel Module 
pstore_blk
  ● modprobe@pstore_zone.service loaded failed failed Load Kernel Module 
pstore_zone
  ● modprobe@ramoops.service loaded failed failed Load Kernel Module 
ramoops

  This happens because of some changes to systemd-pstore.service that
  now has:

  After=modprobe@efi_pstore.service modprobe@mtdpstore.service 
modprobe@chromeos_pstore.service modprobe@ramoops.service 
modprobe@pstore_zone.service modprobe@pstore_blk.service
  Wants=modprobe@efi_pstore.service modprobe@mtdpstore.service 
modprobe@chromeos_pstore.service modprobe@ramoops.service 
modprobe@pstore_zone.service modprobe@pstore_blk.service

  This causes too many tries of the modprobe services, that fail in the
  end with

  Jul 20 09:02:39 ubuntu systemd[1]: modprobe@chromeos_pstore.service:
  Start request repeated too quickly.

  Although we have seen this only on UC22, it potentially can affect
  classic systems as well, as systemd-pstore.service is re-tried there a
  few times too. See https://github.com/snapcore/core-base/issues/72 for
  more details.

  A fix for this is available upstream:
  
https://github.com/systemd/systemd/commit/9625350e5381a68c1179ae4581e7586c206663e1

  [Test Plan]

  Start the device and check that there is no modprobe-pstore related
  failed service. This is racy, so a few tries will be needed to make
  sure things are fine.

  [Where problems could occur]

  The modprobe services are usually dependencies from other services, so
  it should be fine if the retry behavior is controlled by those other
  services. Risk should be small. If something goes wrong we might see a
  lot of restarts for these services.

  [Other Info]

  Testing should happen on UC22 too.

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


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

[Touch-packages] [Bug 1961427] Re: zlib: compressBound() returns an incorrect result on z15

[Frank Heimes]

Thx Iliya! (updating tag accordingly)

** Tags removed: verification-needed verification-needed-focal 
verification-needed-jammy
** Tags added: verification-done verification-done-focal verification-done-jammy

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/1961427

Title:
  zlib: compressBound() returns an incorrect result on z15

Status in Ubuntu on IBM z Systems:
  In Progress
Status in bedtools package in Ubuntu:
  Fix Released
Status in htslib package in Ubuntu:
  Invalid
Status in zlib package in Ubuntu:
  Fix Released
Status in bedtools source package in Focal:
  Invalid
Status in htslib source package in Focal:
  Fix Committed
Status in zlib source package in Focal:
  Fix Committed
Status in bedtools source package in Impish:
  Won't Fix
Status in htslib source package in Impish:
  Won't Fix
Status in zlib source package in Impish:
  Won't Fix
Status in bedtools source package in Jammy:
  Fix Committed
Status in htslib source package in Jammy:
  Invalid
Status in zlib source package in Jammy:
  Fix Committed

Bug description:
  SRU Justification:
  ==

  [Impact]

  * zlib: compressBound() returns an incorrect result on IBM z15
  hardware.

  * Passing the result of compressBound() to compress() results
    in an error code.

  * This is because compressBound() is not adjusted for DFLTCC.

  [Fix]

  * Adjust compressBound() for DFLTCC like it's already done
    for deflateBound().

  * Since zlib project does not accept patches at the moment,
    the fix has been integrated into the DFLTCC pull request:
    https://github.com/madler/zlib/pull/410
    The commitid is b25781e735363e04f6c56e21431c47e4afc50b17.

  * The fix extracted out of the above is:
    
https://launchpadlibrarian.net/589857296/debdiff_zlib_1.2.11.dfsg-2ubuntu7_to_zlib_1.2.11.dfsg-2ubuntu8_jammy.diff

  * On top of this actual zlib fix, there is another patch needed:
   'Remove compressBound assertions. (PR #1258)' for htslib.

  * But there is a standalone 'htslib' package version, as well as a
htslib version included in (some) 'bedtools' packages.
Both need to be patched (see '[Other]' for more details).

  [Test Plan]

  * An IBM z15 system (LPAR, z/VM guest or KVM virtual machine)
    with Ubuntu Server 21.10 (or 22.04).

  * A test can be done  based on the following C test program:
    #include 
    #include 
    #include 
    int main() {
    Bytef in_buf[128], out_buf[1024];
    for (size_t i = 0; i < sizeof(in_buf); i++)
    in_buf[i] = rand();
    uLongf dest_len = compressBound(sizeof(in_buf));
    assert(dest_len <= sizeof(out_buf));
    int ret = compress(out_buf, &dest_len,
   in_buf, sizeof(in_buf));
    assert(ret == Z_OK);
    }

  * The test needs to be done by IBM, due to the requirements
    for the special z15 hardware.

  * A successful test was just completed, based on the version in jammy-
  proposed, which is at the same code level that the impish version this
  SRU is targeted for.

  [Where problems could occur]

  * If the adjustment of compressBound() for DFLTCC is done
    erroneously the issue can still be present or in worst case
    even affect Z systems other than z15 only.

  * The compression can become errorneous with the new changes,
    e.g. in compressBound.

  * Mistakes in dfltcc_free_window OF and especially DEFLATE_BOUND_COMPLEN,
    (incl. the bit definitions), may cause various and unforseen defects.

  * Any build time issues that might have been introduced by this patch
    can be identified by a test build; this was done and is available here:
    https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427

  [Other Info]

  * Ubuntu jammy, impish and focal are affected by the zlib issue.

  * The 'htslib' version '1.13+ds' (as it is part of I, J and K),
already includes the patch,
hence only htslib '1.10.2' in focal needs to be patched.

  * The bedtools version '2.30.0+dfsg' (as it is part of I, J and K),
requires the patch,
but version '2.27.1+dfsg' bedtools in focal does not incl. an
embedded htslib, hence does not need to be (actually can't be)
patched.

  * Patched version of the affected htslib and bedtools packages
are build and also available at this PPA:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427  

  __

  Description:   zlib: compressBound() returns an incorrect result on z15
  Symptom:   Passing the result of compressBound() to compress()
     results in an error code.
  Problem:   compressBound() is not adjusted for DFLTCC.
  Solution:  Adjust compressBound() for DFLTCC like it's already done
     for deflateBound(). Since zlib project does not accept
     patches at the moment, the fix has been integrated into
   

[Touch-packages] [Bug 1961427] Comment bridged from LTC Bugzilla

[bugproxy]

--- Comment From i...@de.ibm.com 2022-09-05 11:31 EDT---
zlib1g-dev s390x 1:1.2.11.dfsg-2ubuntu9.1 and zlib1g s390x 
1:1.2.11.dfsg-2ubuntu9.1 pass all of my tests.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/1961427

Title:
  zlib: compressBound() returns an incorrect result on z15

Status in Ubuntu on IBM z Systems:
  In Progress
Status in bedtools package in Ubuntu:
  Fix Released
Status in htslib package in Ubuntu:
  Invalid
Status in zlib package in Ubuntu:
  Fix Released
Status in bedtools source package in Focal:
  Invalid
Status in htslib source package in Focal:
  Fix Committed
Status in zlib source package in Focal:
  Fix Committed
Status in bedtools source package in Impish:
  Won't Fix
Status in htslib source package in Impish:
  Won't Fix
Status in zlib source package in Impish:
  Won't Fix
Status in bedtools source package in Jammy:
  Fix Committed
Status in htslib source package in Jammy:
  Invalid
Status in zlib source package in Jammy:
  Fix Committed

Bug description:
  SRU Justification:
  ==

  [Impact]

  * zlib: compressBound() returns an incorrect result on IBM z15
  hardware.

  * Passing the result of compressBound() to compress() results
    in an error code.

  * This is because compressBound() is not adjusted for DFLTCC.

  [Fix]

  * Adjust compressBound() for DFLTCC like it's already done
    for deflateBound().

  * Since zlib project does not accept patches at the moment,
    the fix has been integrated into the DFLTCC pull request:
    https://github.com/madler/zlib/pull/410
    The commitid is b25781e735363e04f6c56e21431c47e4afc50b17.

  * The fix extracted out of the above is:
    
https://launchpadlibrarian.net/589857296/debdiff_zlib_1.2.11.dfsg-2ubuntu7_to_zlib_1.2.11.dfsg-2ubuntu8_jammy.diff

  * On top of this actual zlib fix, there is another patch needed:
   'Remove compressBound assertions. (PR #1258)' for htslib.

  * But there is a standalone 'htslib' package version, as well as a
htslib version included in (some) 'bedtools' packages.
Both need to be patched (see '[Other]' for more details).

  [Test Plan]

  * An IBM z15 system (LPAR, z/VM guest or KVM virtual machine)
    with Ubuntu Server 21.10 (or 22.04).

  * A test can be done  based on the following C test program:
    #include 
    #include 
    #include 
    int main() {
    Bytef in_buf[128], out_buf[1024];
    for (size_t i = 0; i < sizeof(in_buf); i++)
    in_buf[i] = rand();
    uLongf dest_len = compressBound(sizeof(in_buf));
    assert(dest_len <= sizeof(out_buf));
    int ret = compress(out_buf, &dest_len,
   in_buf, sizeof(in_buf));
    assert(ret == Z_OK);
    }

  * The test needs to be done by IBM, due to the requirements
    for the special z15 hardware.

  * A successful test was just completed, based on the version in jammy-
  proposed, which is at the same code level that the impish version this
  SRU is targeted for.

  [Where problems could occur]

  * If the adjustment of compressBound() for DFLTCC is done
    erroneously the issue can still be present or in worst case
    even affect Z systems other than z15 only.

  * The compression can become errorneous with the new changes,
    e.g. in compressBound.

  * Mistakes in dfltcc_free_window OF and especially DEFLATE_BOUND_COMPLEN,
    (incl. the bit definitions), may cause various and unforseen defects.

  * Any build time issues that might have been introduced by this patch
    can be identified by a test build; this was done and is available here:
    https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427

  [Other Info]

  * Ubuntu jammy, impish and focal are affected by the zlib issue.

  * The 'htslib' version '1.13+ds' (as it is part of I, J and K),
already includes the patch,
hence only htslib '1.10.2' in focal needs to be patched.

  * The bedtools version '2.30.0+dfsg' (as it is part of I, J and K),
requires the patch,
but version '2.27.1+dfsg' bedtools in focal does not incl. an
embedded htslib, hence does not need to be (actually can't be)
patched.

  * Patched version of the affected htslib and bedtools packages
are build and also available at this PPA:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427  

  __

  Description:   zlib: compressBound() returns an incorrect result on z15
  Symptom:   Passing the result of compressBound() to compress()
     results in an error code.
  Problem:   compressBound() is not adjusted for DFLTCC.
  Solution:  Adjust compressBound() for DFLTCC like it's already done
     for deflateBound(). Since zlib project does not accept
     patches at the moment, the fix has been integrated into
     the DFLTCC pull request:
   

[Touch-packages] [Bug 1988774] [NEW] timeout hangs when combined with sudo and watch

[Mikko Rantalainen]

Public bug reported:

Command 
$ timeout 15s watch -d date --iso=ns
works as expected and shows clock going forward for 15 seconds and then stops.

However, command
$ sudo timeout 15s watch -d date --iso=ns
hangs forever.

I'm not sure if this is a bug in sudo, timeout or watch but I'm
reporting this as timeout issue because I haven't experienced similar
problem unless I use timeout.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: coreutils 8.28-1ubuntu1
ProcVersionSignature: Ubuntu 5.4.0-124.140~18.04.1-lowlatency 5.4.195
Uname: Linux 5.4.0-124-lowlatency x86_64
ApportVersion: 2.20.9-0ubuntu7.28
Architecture: amd64
CurrentDesktop: MATE
Date: Mon Sep  5 18:41:42 2022
EcryptfsInUse: Yes
InstallationDate: Installed on 2019-01-05 (1338 days ago)
InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180725)
SourcePackage: coreutils
UpgradeStatus: No upgrade log present (probably fresh install)

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


** Tags: amd64 apport-bug bionic

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to coreutils in Ubuntu.
https://bugs.launchpad.net/bugs/1988774

Title:
  timeout hangs when combined with sudo and watch

Status in coreutils package in Ubuntu:
  New

Bug description:
  Command 
  $ timeout 15s watch -d date --iso=ns
  works as expected and shows clock going forward for 15 seconds and then stops.

  However, command
  $ sudo timeout 15s watch -d date --iso=ns
  hangs forever.

  I'm not sure if this is a bug in sudo, timeout or watch but I'm
  reporting this as timeout issue because I haven't experienced similar
  problem unless I use timeout.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: coreutils 8.28-1ubuntu1
  ProcVersionSignature: Ubuntu 5.4.0-124.140~18.04.1-lowlatency 5.4.195
  Uname: Linux 5.4.0-124-lowlatency x86_64
  ApportVersion: 2.20.9-0ubuntu7.28
  Architecture: amd64
  CurrentDesktop: MATE
  Date: Mon Sep  5 18:41:42 2022
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2019-01-05 (1338 days ago)
  InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  SourcePackage: coreutils
  UpgradeStatus: No upgrade log present (probably fresh install)

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


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

[Touch-packages] [Bug 1979952] Re: Bind mount to NFS mount fails on Ubuntu 22.04

[Philipp Wendler]

Thanks! Version 249.11-0ubuntu3.5 of systemd fixes this issue for me: I
rebooted the machine and the bind mount to the NFS mount was correctly
mounted automatically. Previously this had always failed.

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

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1979952

Title:
  Bind mount to NFS mount fails on Ubuntu 22.04

Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Jammy:
  Fix Committed
Status in systemd source package in Kinetic:
  Fix Released

Bug description:
  [Impact]
  Some NFS setups that have worked on previous versions of Ubuntu are now 
broken. Specifically, when creating a bind mount, systemd will fail if the 
directory already exists on NFS.

  [Test Plan]
  This test plan requires an NFS server to be in place. The exact setup is not 
important, but for the purposes of this test plan we will assume the server 
exports /data, which contains a directory called home.

  * Make sure nfs-common is installed:

   $ apt install nfs-common -y

  * Check the NFS server exports using showmount:

   $ showmount -e $NFS_SERVER_IP
   Export list for $NFS_SERVER_IP:
   /data *

  * Add the appropriate entries to /etc/fstab. In this example, we will
  make /home2 a bind mount to /data/home:

   # /etc/fstab
   $NFS_SERVER_IP:/data /data nfs defaults,nfsvers=3 0 0
   /data/home /home2 none bind,_netdev,x-systemd.requires-mounts-for=/data 0 0

  * Check systemctl status home2.mount. On an affected system, we should
  see a permission denied error:

   $ systemctl status home2.mount
   x home2.mount - /home2
Loaded: loaded (/etc/fstab; generated)
Active: failed (Result: resources)
 Where: /home2
  What: /data/home
  Docs: man:fstab(5)
man:systemd-fstab-generator(8)

   systemd[1]: home2.mount: Failed to make bind mount source '/data/home': 
Permission denied
   systemd[1]: home2.mount: Failed to run 'mount' task: Permission denied
   systemd[1]: home2.mount: Failed with result 'resources'.
   systemd[1]: Failed to mount /home2.

  * On a patched system, we expect /home2 to be mounted successfully.

  [Where problems could occur]
  The patch makes it so that systemd will not fail bind mounts immediately if 
creating the directory fails. Thus, any regressions would be seen during bind 
mounts with systemd. N.B. that this patch restores previous behavior in systemd.

  [Original Description]
  I have the following setup:
  - /data is an NFS mount.
  - /home is a bind mount to /data/home.

  Configured in /etc/fstab with these lines:

  $FILE_SERVER:/data /data nfs defaults 0 0
  /data/home /home none bind,_netdev,x-systemd.requires-mounts-for=/data 0 0

  This has worked with the same configuration for me on at least Ubuntu 18.04 
and Ubuntu 20.04, but on Ubuntu 22.04 the mount of /home fails when attempted 
by systemd.
  So not only is /home not mounted after boot, but also when I run "sudo 
systemctl start home.mount", it fails.

  The journal entries are this:

  sudo[1316]:  wendler : TTY=pts/0 ; PWD=/home/wendler ; USER=root ; 
COMMAND=/usr/bin/systemctl start home.mount
  sudo[1316]: pam_unix(sudo:session): session opened for user root(uid=0) by 
wendler(uid=1000)
  systemd[1]: home.mount: Directory /home to mount over is not empty, mounting 
anyway.
  systemd[1]: home.mount: Failed to make bind mount source '/data/home': 
Permission denied
  systemd[1]: home.mount: Failed to run 'mount' task: Permission denied
  systemd[1]: home.mount: Failed with result 'resources'.
  systemd[1]: Failed to mount /home.

  However, when I run "sudo mount /home" it works.

  Now the weird thing is that after I have mounted /home manually once
  and unmounted it again, then "sudo systemctl start home.mount"
  suddenly also works! But of course only until the next reboot.

  And even if I just do "ls /data" once (either as root or as my user),
  it also makes "sudo systemctl start home.mount" start working!

  To be fully clear:

  - Booting the system (/home fails to mount)
  - sudo systemctl start home.mount  # fails
  - sudo ls /data  # shows correct output
  - sudo systemctl start home.mount  # works!

  Additional information:

  The NFS export for /data has root_squash set and if I remove this
  option, the bind mount of /home works as it should. However, both
  /data and /data/home have mode rwxr-xr-x, so root is able to enter and
  read these directories even despite root_squash.

  It is not a network or mount-order problem. Not only is the bind mount
  to /home correctly attempted after /data is mounted during boot,
  remember that the bind mount also fails when I try it with "sudo
  systemctl start home.mount" minutes afterwards.

  Versions (system is a recent installation with all updates appl

[Touch-packages] [Bug 1976119] Re: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-*

[Sebastien Bacher]

*** This bug is a duplicate of bug 1978838 ***
https://bugs.launchpad.net/bugs/1978838

** This bug has been marked a duplicate of bug 1978838
   Couldn't connect to accessibility bus

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to at-spi2-core in Ubuntu.
https://bugs.launchpad.net/bugs/1976119

Title:
  Couldn't connect to accessibility bus: Failed to connect to socket
  /tmp/dbus-*

Status in at-spi2-core package in Ubuntu:
  New

Bug description:
  Every time 'evince' runs it prints this on the terminal:

  dbind-WARNING **: ... Couldn't connect to accessibility bus: Failed to
  connect to socket /run/user//at-spi/bus_0: Permission denied

  AFAICT this is the same as a very-old bug 1193236, but that bug was
  closed with a comment "If you are affected, open your own bug"
  (https://bugs.launchpad.net/ubuntu/+source/at-
  spi2-core/+bug/1193236/comments/20).  So I am.

  Xubuntu (xfce) 22.04

  evince version 42.0

  at-spi2-core Ubuntu package version 2.44.0-3

  STEPS TO REPRODUCE:

  1. In a terminal, run /usr/bin/evince

  RESULTS:

  Error glop appears on terminal

  EXPECTED RESULTS:

  Silence unless there is a real error the user can respond to.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/at-spi2-core/+bug/1976119/+subscriptions


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

[Touch-packages] [Bug 1988770] [NEW] the atk tests are hanging in autopkgtest

[Sebastien Bacher]

Public bug reported:

The atk tests are timeout and failing autopkgtest

https://gitlab.gnome.org/GNOME/at-spi2-core/-/issues/89

** Affects: at-spi2-core (Ubuntu)
 Importance: High
 Status: Confirmed


** Tags: update-excuse

** Changed in: at-spi2-core (Ubuntu)
   Importance: Undecided => High

** Changed in: at-spi2-core (Ubuntu)
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to at-spi2-core in Ubuntu.
https://bugs.launchpad.net/bugs/1988770

Title:
  the atk tests are hanging in autopkgtest

Status in at-spi2-core package in Ubuntu:
  Confirmed

Bug description:
  The atk tests are timeout and failing autopkgtest

  https://gitlab.gnome.org/GNOME/at-spi2-core/-/issues/89

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/at-spi2-core/+bug/1988770/+subscriptions


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

[Touch-packages] [Bug 1844775] Re: HDR support for Ubuntu

[Timo Aaltonen]

** Description changed:

  This is a tracker bug for getting HDR support integrated in Ubuntu.
  
- Kernel
- i915:
- - 5.3 (Ice Lake)
- - plus at least https://patchwork.freedesktop.org/series/65656/
- - gen4+ needs https://patchwork.freedesktop.org/series/63373/
- - so anything beyond initial Ice Lake support will not be in 5.4
- 
- Mesa
- - needs current git master plus
- https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1942
+ wayland-protocols:
+ https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14
  
  Mutter:
- https://gitlab.gnome.org/GNOME/mutter/merge_requests/804
+ https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2356
  
- Weston:
- 
https://gitlab.freedesktop.org/ajax/weston/commit/591c95ddeb67324778cbbb5d0102bdd1a1721d99
+ ( Weston: https://gitlab.freedesktop.org/wayland/weston/-/issues/467 )

** Changed in: wayland-protocols (Ubuntu)
   Status: New => Triaged

** Description changed:

  This is a tracker bug for getting HDR support integrated in Ubuntu.
  
  wayland-protocols:
  https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14
  
  Mutter:
  https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2356
  
- ( Weston: https://gitlab.freedesktop.org/wayland/weston/-/issues/467 )
+ Weston:
+ https://gitlab.freedesktop.org/wayland/weston/-/issues/467

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libva in Ubuntu.
https://bugs.launchpad.net/bugs/1844775

Title:
  HDR support for Ubuntu

Status in ffmpeg package in Ubuntu:
  Fix Released
Status in intel-media-driver package in Ubuntu:
  Fix Released
Status in libva package in Ubuntu:
  Fix Released
Status in mesa package in Ubuntu:
  Fix Released
Status in mutter package in Ubuntu:
  Triaged
Status in wayland-protocols package in Ubuntu:
  Triaged
Status in weston package in Ubuntu:
  Confirmed

Bug description:
  This is a tracker bug for getting HDR support integrated in Ubuntu.

  wayland-protocols:
  https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14

  Mutter:
  https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2356

  Weston:
  https://gitlab.freedesktop.org/wayland/weston/-/issues/467

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


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

[Touch-packages] [Bug 1844775] Re: HDR support for Ubuntu

[Timo Aaltonen]

** Also affects: wayland-protocols (Ubuntu)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libva in Ubuntu.
https://bugs.launchpad.net/bugs/1844775

Title:
  HDR support for Ubuntu

Status in ffmpeg package in Ubuntu:
  Fix Released
Status in intel-media-driver package in Ubuntu:
  Fix Released
Status in libva package in Ubuntu:
  Fix Released
Status in mesa package in Ubuntu:
  Fix Released
Status in mutter package in Ubuntu:
  Triaged
Status in wayland-protocols package in Ubuntu:
  Triaged
Status in weston package in Ubuntu:
  Confirmed

Bug description:
  This is a tracker bug for getting HDR support integrated in Ubuntu.

  wayland-protocols:
  https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14

  Mutter:
  https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2356

  Weston:
  https://gitlab.freedesktop.org/wayland/weston/-/issues/467

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


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

[Touch-packages] [Bug 1988230] Re: glib 2.73 breaks modemmanager

[Sebastien Bacher]

reopening for the block tag to be working

** Changed in: glib2.0 (Ubuntu)
   Status: Invalid => Triaged

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to glib2.0 in Ubuntu.
https://bugs.launchpad.net/bugs/1988230

Title:
  glib 2.73 breaks modemmanager

Status in GLib:
  Fix Released
Status in glib2.0 package in Ubuntu:
  Triaged
Status in modemmanager package in Ubuntu:
  Fix Released
Status in glib2.0 package in Debian:
  Confirmed

Bug description:
  I'm filing this bug in case we want to fix it before letting glib 2.73
  in to kinetic.

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


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

[Touch-packages] [Bug 1966849] Re: gzip exec format error under WSL1

[Dimitri John Ledkov]

** Description changed:

+ [Impact]
+ 
+  * Optimization features included in jammy cause atypical alignment of
+ LOAD ELF sections. This in turn causes failure to execute binaries on
+ WSL1. Upstream have since integrated the optimization features included
+ in jammy, but also reverted alignment to a previously used one. This
+ also results in working binary under WSL1.
+ 
+  * Cherry-pick upstream applied revert to alignment to resolve running
+ gzip under WSL1.
+ 
+ [Test Plan]
+ 
+  * Use powershell to set default WSL version to 1
+ 
+  * Deploy WSL1, unpack and use updated gzip package
+ 
+  * gzip --version should execute correctly under WSL 1
+ 
+ [Where problems could occur]
+ 
+  * I cannot tell why performance improvement patches introduced
+ alignment change, and if revert of the alignment change affects the
+ performance. Note that this change aligns the codebase closer to what
+ kinetic & upstream now are.
+ 
+ [Other Info]
+  
+  * This bug fix is upstream commit 
https://git.savannah.gnu.org/cgit/gzip.git/commit/gzip.c?id=23a870d14a49803c6d2579071886c1acf497c9d1
+ 
+ ---
+ 
  gzip version 1.10-4ubuntu3 fails to run under WSL1 on Windows
  19044.1620, making WSL pretty much unusable.
  
  bash: /usr/bin/gzip: cannot execute binary file: Exec format error
  
  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: gzip 1.10-4ubuntu3
  ProcVersionSignature: Microsoft 4.4.0-19041.1237-Microsoft 4.4.35
  Uname: Linux 4.4.0-19041-Microsoft x86_64
  ApportVersion: 2.20.11-0ubuntu79
  Architecture: amd64
  CasperMD5CheckResult: unknown
  Date: Tue Mar 29 06:40:33 2022
  ProcEnviron:
-  TERM=xterm-256color
-  PATH=(custom, no user)
-  LANG=pl_PL.UTF-8
-  SHELL=/usr/bin/fish
+  TERM=xterm-256color
+  PATH=(custom, no user)
+  LANG=pl_PL.UTF-8
+  SHELL=/usr/bin/fish
  SourcePackage: gzip
  UpgradeStatus: No upgrade log present (probably fresh install)

** Also affects: gzip (Ubuntu Jammy)
   Importance: Undecided
   Status: New

** Also affects: gzip (Ubuntu Kinetic)
   Importance: Undecided
   Status: Confirmed

** Changed in: gzip (Ubuntu Jammy)
   Status: New => In Progress

** Changed in: gzip (Ubuntu Kinetic)
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gzip in Ubuntu.
https://bugs.launchpad.net/bugs/1966849

Title:
  gzip exec format error under WSL1

Status in gzip:
  New
Status in gzip package in Ubuntu:
  Fix Released
Status in gzip source package in Jammy:
  In Progress
Status in gzip source package in Kinetic:
  Fix Released

Bug description:
  [Impact]

   * Optimization features included in jammy cause atypical alignment of
  LOAD ELF sections. This in turn causes failure to execute binaries on
  WSL1. Upstream have since integrated the optimization features
  included in jammy, but also reverted alignment to a previously used
  one. This also results in working binary under WSL1.

   * Cherry-pick upstream applied revert to alignment to resolve running
  gzip under WSL1.

  [Test Plan]

   * Use powershell to set default WSL version to 1

   * Deploy WSL1, unpack and use updated gzip package

   * gzip --version should execute correctly under WSL 1

  [Where problems could occur]

   * I cannot tell why performance improvement patches introduced
  alignment change, and if revert of the alignment change affects the
  performance. Note that this change aligns the codebase closer to what
  kinetic & upstream now are.

  [Other Info]
   
   * This bug fix is upstream commit 
https://git.savannah.gnu.org/cgit/gzip.git/commit/gzip.c?id=23a870d14a49803c6d2579071886c1acf497c9d1

  ---

  gzip version 1.10-4ubuntu3 fails to run under WSL1 on Windows
  19044.1620, making WSL pretty much unusable.

  bash: /usr/bin/gzip: cannot execute binary file: Exec format error

  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: gzip 1.10-4ubuntu3
  ProcVersionSignature: Microsoft 4.4.0-19041.1237-Microsoft 4.4.35
  Uname: Linux 4.4.0-19041-Microsoft x86_64
  ApportVersion: 2.20.11-0ubuntu79
  Architecture: amd64
  CasperMD5CheckResult: unknown
  Date: Tue Mar 29 06:40:33 2022
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=pl_PL.UTF-8
   SHELL=/usr/bin/fish
  SourcePackage: gzip
  UpgradeStatus: No upgrade log present (probably fresh install)

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


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

[Touch-packages] [Bug 1979639] Re: Apps expecting an OpenSSL 1.1 -formatted openssl.cnf fail

[Robie Basak]

That's a good question. I think it's up to Simon and the Foundations
team what they want to do there. There is far less of a risk to users
either way in Kinetic, because it hasn't been released yet. So I have no
preference for Kinetic, though it does make sense to revert to me.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1979639

Title:
  Apps expecting an OpenSSL 1.1 -formatted openssl.cnf fail

Status in nodejs package in Ubuntu:
  Confirmed
Status in openssl package in Ubuntu:
  Fix Released
Status in nodejs source package in Jammy:
  Confirmed
Status in openssl source package in Jammy:
  Won't Fix
Status in nodejs source package in Kinetic:
  Confirmed
Status in openssl source package in Kinetic:
  Fix Released

Bug description:
  [Impact]
  While the default configuration works fine for every package that uses the 
system libssl3, libssl1.1.1 (which implicitly loads the configuration on 
OPENSSL_crypto_init()) fails to parse it.

  Our nodejs package vendors openssl 1.1.1, which means it will trigger this 
bug. In addition, upstream NodeJS explicitly points their statically-linked 
OpenSSL to this file as well, and ships 1.1.1 in their current LTS (branch 
16.x).
  Finally, we can also expect breakage for third-party packages that still 
depends on libssl1.1.

  If the provider section isn't present in the configuration, libssl3
  will load the default provider, which means that commenting out the
  section won't impact the behavior of standard libssl3 users.

  [Test Plan]

  On a system with a pristine openssl configuration:

  $ sudo apt install nodejs
  $ nodejs -  const { privateKey, publicKey } = crypto.generateKeyPairSync('rsa', { 
modulusLength: 2048 });
  …
  > var sign = crypto.createSign('RSA-SHA256')
  …
  > sign.update(Buffer.from("hello"))
  …
  > sign.sign(privateKey.export({type: 'pkcs1', format: 'pem'}))
  Uncaught:
  Error: error:25066067:DSO support routines:dlfcn_load:could not load the 
shared library
  at Sign.sign (node:internal/crypto/sig:131:29) {
    opensslErrorStack: [
  'error:0E076071:configuration file routines:module_run:unknown module 
name',
  'error:0E07506E:configuration file routines:module_load_dso:error loading 
dso',
  'error:25070067:DSO support routines:DSO_load:could not load the shared 
library'
    ],
    library: 'DSO support routines',
    function: 'dlfcn_load',
    reason: 'could not load the shared library',
    code: 'ERR_OSSL_DSO_COULD_NOT_LOAD_THE_SHARED_LIBRARY'
  }

  Removing the relevant provider section lines (the Debian patch doesn't
  apply cleanly, hence the use of sed) fixes it:

  ~ $ sed -i '/_sect\b/s/^/# /' /etc/ssl/openssl.cnf
  ~ $ node
  Welcome to Node.js v16.15.0.
  Type ".help" for more information.
  > const { privateKey, publicKey } = crypto.generateKeyPairSync('rsa', { 
modulusLength: 2048 });
  …
  > var sign = crypto.createSign('RSA-SHA256')
  …
  > sign.update(Buffer.from("hello"))
  …
  > sign.sign(privateKey.export({type: 'pkcs1', format: 'pem'}))
  

  I realize there is no libssl1.1 on jammy, but a statically linked
  OpenSSL is not uncommon (Node.js being a very prominent example).

  Would it be possible to get this Debian sid change ported to jammy?

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


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

[Touch-packages] [Bug 1979639] Re: Apps expecting an OpenSSL 1.1 -formatted openssl.cnf fail

[David Zuelke]

Does this mean the fix will remain in Kinetic, though?

Should it not be reverted there, then?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssl in Ubuntu.
https://bugs.launchpad.net/bugs/1979639

Title:
  Apps expecting an OpenSSL 1.1 -formatted openssl.cnf fail

Status in nodejs package in Ubuntu:
  Confirmed
Status in openssl package in Ubuntu:
  Fix Released
Status in nodejs source package in Jammy:
  Confirmed
Status in openssl source package in Jammy:
  Won't Fix
Status in nodejs source package in Kinetic:
  Confirmed
Status in openssl source package in Kinetic:
  Fix Released

Bug description:
  [Impact]
  While the default configuration works fine for every package that uses the 
system libssl3, libssl1.1.1 (which implicitly loads the configuration on 
OPENSSL_crypto_init()) fails to parse it.

  Our nodejs package vendors openssl 1.1.1, which means it will trigger this 
bug. In addition, upstream NodeJS explicitly points their statically-linked 
OpenSSL to this file as well, and ships 1.1.1 in their current LTS (branch 
16.x).
  Finally, we can also expect breakage for third-party packages that still 
depends on libssl1.1.

  If the provider section isn't present in the configuration, libssl3
  will load the default provider, which means that commenting out the
  section won't impact the behavior of standard libssl3 users.

  [Test Plan]

  On a system with a pristine openssl configuration:

  $ sudo apt install nodejs
  $ nodejs -  const { privateKey, publicKey } = crypto.generateKeyPairSync('rsa', { 
modulusLength: 2048 });
  …
  > var sign = crypto.createSign('RSA-SHA256')
  …
  > sign.update(Buffer.from("hello"))
  …
  > sign.sign(privateKey.export({type: 'pkcs1', format: 'pem'}))
  Uncaught:
  Error: error:25066067:DSO support routines:dlfcn_load:could not load the 
shared library
  at Sign.sign (node:internal/crypto/sig:131:29) {
    opensslErrorStack: [
  'error:0E076071:configuration file routines:module_run:unknown module 
name',
  'error:0E07506E:configuration file routines:module_load_dso:error loading 
dso',
  'error:25070067:DSO support routines:DSO_load:could not load the shared 
library'
    ],
    library: 'DSO support routines',
    function: 'dlfcn_load',
    reason: 'could not load the shared library',
    code: 'ERR_OSSL_DSO_COULD_NOT_LOAD_THE_SHARED_LIBRARY'
  }

  Removing the relevant provider section lines (the Debian patch doesn't
  apply cleanly, hence the use of sed) fixes it:

  ~ $ sed -i '/_sect\b/s/^/# /' /etc/ssl/openssl.cnf
  ~ $ node
  Welcome to Node.js v16.15.0.
  Type ".help" for more information.
  > const { privateKey, publicKey } = crypto.generateKeyPairSync('rsa', { 
modulusLength: 2048 });
  …
  > var sign = crypto.createSign('RSA-SHA256')
  …
  > sign.update(Buffer.from("hello"))
  …
  > sign.sign(privateKey.export({type: 'pkcs1', format: 'pem'}))
  

  I realize there is no libssl1.1 on jammy, but a statically linked
  OpenSSL is not uncommon (Node.js being a very prominent example).

  Would it be possible to get this Debian sid change ported to jammy?

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


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

[Touch-packages] [Bug 1966800] Re: systemd locks up due to incorrect handling of time zone changes

[Łukasz Zemczak]

Hello Matt, or anyone else affected,

Accepted systemd into focal-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/systemd/245.4-4ubuntu3.18 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
focal to verification-done-focal. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-focal. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: systemd (Ubuntu Focal)
   Status: New => Fix Committed

** Tags added: verification-needed verification-needed-focal

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1966800

Title:
  systemd locks up due to incorrect handling of time zone changes

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Fix Committed
Status in systemd package in Fedora:
  Unknown

Bug description:
  [Impact]

  This bug can cause systemd timers to lock up systems using the
  Europe/Dublin timezone if certain OnCalendar values are used. If the
  timer is enabled at boot, this bug prevents the system from booting.
  If the timer is started later, systemd becomes unresponsive.

  [Test Plan]

  * Create a systemd service and corresponding timer scheduled for 01:00
  on Sundays:

  $ cat /etc/systemd/system/lp-1966800-reproducer.timer
   [Unit]
   Description=LP 1966800 reproducer

   [Timer]
   OnCalendar=Sun *-*-* 01:00:00
   Persistent=true

   [Install]
   WantedBy=timers.target

   $ cat /etc/systemd/system/lp-1966800-reproducer.service
   [Service]
   ExecStart=/usr/bin/echo "LP 1966800 reproducer"

   $ systemctl daemon-reload

  * Set the date to 21 March, 2021 in the Europe/Dublin timezone (need
  to disable NTP first):

   $ timedatectl set-ntp false
   $ timedatectl set-time "2021-03-21"
   $ timedatectl set-timezone Europe/Dublin

  * Try to start the timer, and observe that systemd becomes
  unresponsive. This command will time out, as will `systemctl status`
  etc.

   $ systemctl start lp-1966800-reproducer.timer

  [Where problems could occur]

  The patch makes changes in the calendar spec code, which is used by
  systemd timers to determine the next time to trigger a timer. If this
  patch breaks something, it would be related to the triggering of
  systemd timers.

  [Original Description]

  Recently on systems in Ireland, systemd became unresponsive due the
  change from GMT to Irish Standard Time. This is due to Ireland being
  unique in having their standard time during the summer, unlike most
  regions.

  Related to: https://bugzilla.redhat.com/show_bug.cgi?id=1941335
  Fixed by: 
https://github.com/systemd/systemd-stable/commit/a8b66ca9af811148b67ee952ab32748f88b8bba3

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


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

[Touch-packages] [Bug 1978079] Re: EFI pstore not cleared on boot

[Łukasz Zemczak]

Hello Alexander, or anyone else affected,

Accepted systemd into focal-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/systemd/245.4-4ubuntu3.18 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
focal to verification-done-focal. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-focal. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: systemd (Ubuntu Focal)
   Status: In Progress => Fix Committed

** Tags added: verification-needed-focal

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1978079

Title:
  EFI pstore not cleared on boot

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Impish:
  Won't Fix
Status in systemd source package in Jammy:
  Fix Released
Status in systemd source package in Kinetic:
  Fix Released

Bug description:
  [Impact]

  Systemd has a systemd-pstore component that scans the pstore on boot
  and if non-empty, takes all previously created dumps, transfers them
  into its journal and removes the pstore elements. This is very
  important on UEFI systems, which only have a limited amount of space
  for variables.

  In Ubuntu, the kernel is configured with CONFIG_EFI_VARS_PSTORE=m
  which means the EFI pstore support gets loaded dynamically. In all of
  my boots, this dynamic module loading happened *after* systemd tried
  to check for pstore variables. So systemd-pstore never starts and
  never clears the UEFI variable store. I see this happening in AWS on
  Graviton instances, which eventually run out of space to store the
  dumps. On real hardware, this behavior may lead to unbootable systems.

  ```
  $ systemctl status systemd-pstore
  ○ systemd-pstore.service - Platform Persistent Storage Archival
   Loaded: loaded (/lib/systemd/system/systemd-pstore.service; enabled; 
vendor preset: enabled)
   Active: inactive (dead)
    Condition: start condition failed at Thu 2022-06-09 09:11:41 UTC; 29min ago
   └─ ConditionDirectoryNotEmpty=/sys/fs/pstore was not met
     Docs: man:systemd-pstore(8)

  Jun 09 09:11:41 ip-172-31-0-61 systemd[1]: Condition check resulted in
  Platform Persistent Storage Archival being skipped.

  $ ls -la /sys/fs/pstore
  total 0
  drwxr-x--- 2 root root0 Jun  9 09:11 .
  drwxr-xr-x 8 root root0 Jun  9 09:11 ..
  -r--r--r-- 1 root root 1803 Jun  9 09:07 dmesg-efi-165476562001001
  -r--r--r-- 1 root root 1777 Jun  9 09:07 dmesg-efi-165476562002001
  -r--r--r-- 1 root root 1773 Jun  9 09:07 dmesg-efi-165476562003001
  -r--r--r-- 1 root root 1815 Jun  9 09:07 dmesg-efi-165476562004001
  -r--r--r-- 1 root root 1826 Jun  9 09:07 dmesg-efi-165476562005001
  -r--r--r-- 1 root root 1754 Jun  9 09:07 dmesg-efi-165476562006001
  -r--r--r-- 1 root root 1821 Jun  9 09:07 dmesg-efi-165476562007001
  -r--r--r-- 1 root root 1767 Jun  9 09:07 dmesg-efi-165476562008001
  -r--r--r-- 1 root root 1729 Jun  9 09:07 dmesg-efi-165476562009001
  -r--r--r-- 1 root root 1819 Jun  9 09:07 dmesg-efi-165476562010001
  -r--r--r-- 1 root root 1767 Jun  9 09:07 dmesg-efi-165476562011001
  -r--r--r-- 1 root root 1775 Jun  9 09:07 dmesg-efi-165476562012001
  -r--r--r-- 1 root root 1802 Jun  9 09:07 dmesg-efi-165476562013001
  -r--r--r-- 1 root root 1812 Jun  9 09:07 dmesg-efi-165476562014001
  -r--r--r-- 1 root root 1764 Jun  9 09:07 dmesg-efi-165476562015001
  -r--r--r-- 1 root root 1795 Jun  9 09:11 dmesg-efi-165476589801001
  -r--r--r-- 1 root root 1785 Jun  9 09:11 dmesg-efi-165476589802001
  -r--r--r-- 1 root root 1683 Jun  9 09:11 dmesg-efi-165476589803001
  -r--r--r-- 1 root root 1785 Jun  9 09:11 dmesg-efi-165476589804001
  -r--r--r-- 1 root root 1771 Jun  9 09:11 dmesg-efi-165476589805001
  -r--r--r-- 1 root root 1797 Jun  9 09:11 dmesg-efi-165476589806001
  -r--r--r-- 1 root root 1805 Jun  9 09:11 dmesg-efi-165476589807001
  -r--r--r-- 1 root root 1781 Jun  9 09:11 dmesg-efi-165476589808001
  -r--r--r-- 

[Touch-packages] [Bug 1959475] Re: "machinectl shell" connections immediately terminated

[Łukasz Zemczak]

Hello renbag, or anyone else affected,

Accepted systemd into focal-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/systemd/245.4-4ubuntu3.18 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
focal to verification-done-focal. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-focal. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: systemd (Ubuntu Focal)
   Status: In Progress => Fix Committed

** Tags added: verification-needed verification-needed-focal

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1959475

Title:
  "machinectl shell" connections immediately terminated

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Fix Committed

Bug description:
  [Impact]

  This bug prevents users on Impish and newer from connecting to Focal
  systemd containers using `machinectl shell`. This limits users ability
  to manage containers spawned with systemd-nspawn.

  [Test Plan]

  On a Jammy host, do the following:

  * Install systemd-container and debootstrap if necessary:

$ sudo apt install debootstrap systemd-container

  * Create a Focal filesystem for the container:

$ sudo debootstrap --arch= focal
  /var/lib/containers/lp1959475/

  * Launch the container:

$ sudo systemd-nspawn -D /var/lib/containers/lp1959475/ --machine
  test-container

  * Inside the container, set a password for root and then exit:

$ passwd # Enter password when prompted
$ exit

  * Re-launch the container with -b option:

$ sudo systemd-nspawn -D /var/lib/containers/lp1959475/ --machine
  test-container -b

  * In a separate terminal window, try to connect to the container:

$ sudo machinectl shell test-container

  * Observe the "Connection to machine test-container terminated" error
  message.

  [Where problems could occur]

  The patch expands the case where the TERM variable is inherited from
  PID 1 when building an execution environment, e.g. for a container. If
  problems were to occur, it would be related to the value of TERM in
  environments forked off of PID 1.

  [Other Info]

  This bug occurs when trying to connect to a Focal container from e.g. a Jammy 
host. For SRU verification, the container
  should be Focal, and the host should be Jammy. The -proposed package should 
be installed in the Focal container.

  [Original Description]

  The command "machinectl shell" does not work in systemd
  249.9-0ubuntu2:

  $ sudo machinectl shell ns-xxx
  Connected to machine ns-xxx. Press ^] three times within 1s to exit session.

  Connection to machine ns-xxx terminated.

  The issue seems to be described here:
  
https://forum.manjaro.org/t/the-machinectl-shell-command-stopped-working-after-systemd-upgrade-to-250-2-1/99899
  https://github.com/systemd/systemd/issues/22234

  and solved here:

  
https://github.com/systemd/systemd/commit/e8cf09b2a2ad0d48e5493050d54251d5f512d9b6

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


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

[Touch-packages] [Bug 1979951] Re: 127.0.0.1/::1 removed from loopback interface if you configure extra IPs on lo (r104 regression/behaviour change)

[Łukasz Zemczak]

Hello Trent, or anyone else affected,

Accepted systemd into focal-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/systemd/245.4-4ubuntu3.18 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
focal to verification-done-focal. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-focal. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: systemd (Ubuntu Focal)
   Status: New => Fix Committed

** Tags added: verification-needed-focal

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1979951

Title:
  127.0.0.1/::1 removed from loopback interface if you configure extra
  IPs on lo (r104 regression/behaviour change)

Status in netplan.io package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Fix Released
Status in netplan.io source package in Focal:
  New
Status in systemd source package in Focal:
  Fix Committed
Status in netplan.io source package in Jammy:
  New
Status in systemd source package in Jammy:
  Fix Committed

Bug description:
  [Impact]

  Users who wish to configure additional addresses on lo may
  inadvertently remove the 127.0.0.1/8 address from the interface. And,
  because this only happens on the second invocation of `netplan apply`,
  it can create confusing breakages for users. Although this is not a
  recommended configuration, it was previously supported and the current
  behavior is a regression.

  [Test Plan]

  * Configure additional addresses on the lo interface. I am testing in
  a LXD container, so I added the following to /etc/netplan/10-lxc.yaml
  under `ethernets:`

  lo:
addresses: ["10.10.10.17/24","10.10.10.19/24"]

  * Apply the config, and then inspect the lo interface's addresses:

   $ netplan apply
   $ ip addr show dev lo

  * Observe that the 127.0.0.1/8 address is still present. Now, run the
  same commands again:

   $ netplan apply
   $ ip addr show dev lo

  * On an affected system, observe that the 127.0.0.1/8 address is now
  gone. On a patched system, the address should still be present.

  [Where problems could occur]

  The patch removes cases where systemd-networkd will drop foreign
  addresses from a managed link. If problems were to occur, it would be
  related to the addresses configured on a managed link.

  [Original Description]

  If you configure the loopback interface using netplan without listing
  the standard loopback addresses (127.0.0.1 / ::1) that are auto-
  configured on boot then they are removed by netplan in r104+ but were
  not in r103.

  Confusingly this only happens the second time "netplan apply" is
  invoked and not the first time.

  There is some argument this is not a valid configuration, however
  - It worked on r103 and broke in the r104 SRU for 20.04 and breaks on upgrade
  - Since it only occurs on the second "netplan apply" it is likely people will 
accidentally create a configuration that on first verification works but breaks 
later
  - Adding addresses to a loopback or dummy interface is a common need
  - There is no dummy interface support in Netplan
  - Removing the loopback IP doesn't immediately cause obvious breakage in an 
SSH session but causes all sorts of hard to diagnose issues with applications

  Thus I consider this a high priority regression because of the
  multiple ways this can break a system at an unexpected/unrelated time
  to when the original change was made.

  As a workaround you can add 127.0.0.1/::1 to the file and this seems
  to generally work and product almost the same configuration with the
  exception that "brd 127.255.255.255" is added to the "ip addr" output
  compared to the auto-created configuration. All of the different
  routing tables seem otherwise the tame.

  = Test Case =
  (1) Add IP configuration for lo to /etc/netplan/lo.yaml

  lo:
    match:
  name: lo
    addresses:
    - 10.10.10.17/24
    - 10.10.10.19/24

  (2) Run "netplan apply" and observe the "ip addr show dev lo" output. 
Expected: 127.0.0.1/:

[Touch-packages] [Bug 1982462] Re: Some modprobe loading services requested by the pstore service fail

[Łukasz Zemczak]

Hello Alfonso, or anyone else affected,

Accepted systemd into focal-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/systemd/245.4-4ubuntu3.18 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
focal to verification-done-focal. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-focal. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: systemd (Ubuntu Focal)
   Status: Confirmed => Fix Committed

** Tags added: verification-needed-focal

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1982462

Title:
  Some modprobe loading services requested by the pstore service fail

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Fix Committed
Status in systemd source package in Jammy:
  Fix Committed
Status in systemd source package in Kinetic:
  Fix Released

Bug description:
  [Impact]

  It has been detected that some modprobe services fail on UC22 after
  the jammy upgrade  249.11-0ubuntu3.4:

  $ systemctl --system --no-ask-password --no-pager list-units --state=failed
  Failed units:
UNIT LOAD   ACTIVE SUBDESCRIPTION
  ● modprobe@chromeos_pstore.service loaded failed failed Load Kernel Module 
chromeos_pstore
  ● modprobe@efi_pstore.service  loaded failed failed Load Kernel Module 
efi_pstore
  ● modprobe@mtdpstore.service   loaded failed failed Load Kernel Module 
mtdpstore
  ● modprobe@pstore_blk.service  loaded failed failed Load Kernel Module 
pstore_blk
  ● modprobe@pstore_zone.service loaded failed failed Load Kernel Module 
pstore_zone
  ● modprobe@ramoops.service loaded failed failed Load Kernel Module 
ramoops

  This happens because of some changes to systemd-pstore.service that
  now has:

  After=modprobe@efi_pstore.service modprobe@mtdpstore.service 
modprobe@chromeos_pstore.service modprobe@ramoops.service 
modprobe@pstore_zone.service modprobe@pstore_blk.service
  Wants=modprobe@efi_pstore.service modprobe@mtdpstore.service 
modprobe@chromeos_pstore.service modprobe@ramoops.service 
modprobe@pstore_zone.service modprobe@pstore_blk.service

  This causes too many tries of the modprobe services, that fail in the
  end with

  Jul 20 09:02:39 ubuntu systemd[1]: modprobe@chromeos_pstore.service:
  Start request repeated too quickly.

  Although we have seen this only on UC22, it potentially can affect
  classic systems as well, as systemd-pstore.service is re-tried there a
  few times too. See https://github.com/snapcore/core-base/issues/72 for
  more details.

  A fix for this is available upstream:
  
https://github.com/systemd/systemd/commit/9625350e5381a68c1179ae4581e7586c206663e1

  [Test Plan]

  Start the device and check that there is no modprobe-pstore related
  failed service. This is racy, so a few tries will be needed to make
  sure things are fine.

  [Where problems could occur]

  The modprobe services are usually dependencies from other services, so
  it should be fine if the retry behavior is controlled by those other
  services. Risk should be small. If something goes wrong we might see a
  lot of restarts for these services.

  [Other Info]

  Testing should happen on UC22 too.

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


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

[Touch-packages] [Bug 1988730] Re: package libsasl2-modules provides only unsafe SASL bind mechanims

[Ubuntu Foundations Team Bug Bot]

The attachment "Fix SCRAM support for SASL authentication" seems to be a
patch.  If it isn't, please remove the "patch" flag from the attachment,
remove the "patch" tag, and if you are a member of the ~ubuntu-
reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by
~brian-murray, for any issues please contact him.]

** Tags added: patch

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to cyrus-sasl2 in Ubuntu.
https://bugs.launchpad.net/bugs/1988730

Title:
  package libsasl2-modules provides only unsafe SASL bind mechanims

Status in cyrus-sasl2 package in Ubuntu:
  New

Bug description:
  Current Cyrus libsasl2 packaging (Ubuntu Jammy) distributes SASL bind 
mechanims into different packages. Plained and shared secret mechanisms are 
provided by package libsasl2-modules:
  /usr/lib/x86_64-linux-gnu/sasl2/libanonymous.so
  /usr/lib/x86_64-linux-gnu/sasl2/libanonymous.so.2
  /usr/lib/x86_64-linux-gnu/sasl2/libanonymous.so.2.0.25
  /usr/lib/x86_64-linux-gnu/sasl2/libcrammd5.so
  /usr/lib/x86_64-linux-gnu/sasl2/libcrammd5.so.2
  /usr/lib/x86_64-linux-gnu/sasl2/libcrammd5.so.2.0.25
  /usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so
  /usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so.2
  /usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so.2.0.25
  /usr/lib/x86_64-linux-gnu/sasl2/liblogin.so
  /usr/lib/x86_64-linux-gnu/sasl2/liblogin.so.2
  /usr/lib/x86_64-linux-gnu/sasl2/liblogin.so.2.0.25
  /usr/lib/x86_64-linux-gnu/sasl2/libntlm.so
  /usr/lib/x86_64-linux-gnu/sasl2/libntlm.so.2
  /usr/lib/x86_64-linux-gnu/sasl2/libntlm.so.2.0.25
  /usr/lib/x86_64-linux-gnu/sasl2/libplain.so
  /usr/lib/x86_64-linux-gnu/sasl2/libplain.so.2
  /usr/lib/x86_64-linux-gnu/sasl2/libplain.so.2.0.25

  The "safest" mechanism in this list is DIGEST-MD5, which is marked as
  obsolete by IANA and regarded as unsafe by IETF. Current safest
  standard mechanisms are SCRAM based (RFC7677).

  All SCRAM family SASL mechanisms of Cyrus SASL are provided by Ubuntu package 
libsasl2-modules-gssapi-mit:
  /usr/lib/x86_64-linux-gnu/sasl2/libscram.so
  /usr/lib/x86_64-linux-gnu/sasl2/libscram.so.2
  /usr/lib/x86_64-linux-gnu/sasl2/libscram.so.2.0.25

  But the focus of this package is GSSAPI and GS2 SASL mechanism, which
  have nothing to do with SCRAM. In addition, this package conflicts
  with package libsasl2-modules-gssapi-heimdal. System administrators
  have to choose one package for support of GSSAPI or GSS-SPEGNO. If
  they prefer Heimdal there is no safe SASL shared secret mechanism
  available anymore on the server/workstation.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cyrus-sasl2/+bug/1988730/+subscriptions


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

[Touch-packages] [Bug 1988563] Re: package libudev-dev dependency conflict

[Justas]

Hi, sharing my workaround for this issue using docker image.

FROM ubuntu:18.04
ADD 
http://archive.ubuntu.com/ubuntu/pool/main/s/systemd/libudev1_237-3ubuntu10_amd64.deb
 libudev1_237-3ubuntu10_amd64.deb
RUN dpkg -i libudev1_237-3ubuntu10_amd64.deb
ADD 
http://archive.ubuntu.com/ubuntu/pool/main/s/systemd/libudev-dev_237-3ubuntu10_amd64.deb
 libudev-dev_237-3ubuntu10_amd64.deb
RUN dpkg -i libudev-dev_237-3ubuntu10_amd64.deb
RUN apt-get update && apt-get install -y libudev-dev

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1988563

Title:
  package libudev-dev dependency conflict

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  I am not sure if this is the right place to file this, but we are
  getting the following error when installing libudev-dev on bionic

  Installing libudev-dev fails for bionic with the following error:

  ```
  Some packages could not be installed. This may mean that you have
  requested an impossible situation or if you are using the unstable
  distribution that some required packages have not yet been created
  or been moved out of Incoming.
  The following information may help to resolve the situation:

  The following packages have unmet dependencies:
   libudev-dev : Depends: libudev1 (= 237-3ubuntu10.53) but 237-3ubuntu10.54 is 
to be installed
  E: Unable to correct problems, you have held broken packages.
  ```

  Steps to reproduce:

  ```
  docker run -it --rm ubuntu:bionic
  apt update
  apt install libudev-dev
  ```

  Complete log:
  ```
  ~$ docker run -it --rm ubuntu:bionic
  Unable to find image 'ubuntu:bionic' locally
  bionic: Pulling from library/ubuntu
  dad0f37c70a6: Pull complete 
  Digest: 
sha256:3aa2ccb021969aadb28381fee1b247422e845b176e241cd1540c4b6831e000bb
  Status: Downloaded newer image for ubuntu:bionic
  root@391196612b51:/# apt update
  Get:1 http://security.ubuntu.com/ubuntu bionic-security InRelease [88.7 kB]
  Get:2 http://archive.ubuntu.com/ubuntu bionic InRelease [242 kB]  
 
  Get:3 http://security.ubuntu.com/ubuntu bionic-security/restricted amd64 
Packages [1114 kB]
  Get:4 http://security.ubuntu.com/ubuntu bionic-security/multiverse amd64 
Packages [22.8 kB]
  Get:5 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages 
[2953 kB]
  Get:6 http://security.ubuntu.com/ubuntu bionic-security/universe amd64 
Packages [1540 kB]
  Get:7 http://archive.ubuntu.com/ubuntu bionic-updates InRelease [88.7 kB] 
 
  Get:8 http://archive.ubuntu.com/ubuntu bionic-backports InRelease [74.6 kB]
  Get:9 http://archive.ubuntu.com/ubuntu bionic/multiverse amd64 Packages [186 
kB]
  Get:10 http://archive.ubuntu.com/ubuntu bionic/restricted amd64 Packages 
[13.5 kB]
  Get:11 http://archive.ubuntu.com/ubuntu bionic/universe amd64 Packages [11.3 
MB]
  Get:12 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages [1344 kB]
  Get:13 http://archive.ubuntu.com/ubuntu bionic-updates/multiverse amd64 
Packages [29.9 kB]
  Get:14 http://archive.ubuntu.com/ubuntu bionic-updates/restricted amd64 
Packages [1162 kB]
  Get:15 http://archive.ubuntu.com/ubuntu bionic-updates/universe amd64 
Packages [2318 kB]
  Get:16 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages 
[3390 kB]
  Get:17 http://archive.ubuntu.com/ubuntu bionic-backports/universe amd64 
Packages [12.9 kB]
  Get:18 http://archive.ubuntu.com/ubuntu bionic-backports/main amd64 Packages 
[12.2 kB]
  Fetched 25.9 MB in 2s (10.4 MB/s) 
  Reading package lists... Done
  Building dependency tree   
  Reading state information... Done
  All packages are up to date.
  root@391196612b51:/# apt install libudev-dev
  Reading package lists... Done
  Building dependency tree   
  Reading state information... Done
  Some packages could not be installed. This may mean that you have
  requested an impossible situation or if you are using the unstable
  distribution that some required packages have not yet been created
  or been moved out of Incoming.
  The following information may help to resolve the situation:

  The following packages have unmet dependencies:
   libudev-dev : Depends: libudev1 (= 237-3ubuntu10.53) but 237-3ubuntu10.54 is 
to be installed
  E: Unable to correct problems, you have held broken packages.
  ```

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


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

[Touch-packages] [Bug 1988752] [NEW] i was trying to update intel graphic driver

[adam moufid]

Public bug reported:

i was trying to update intel graphic driver
commmands:
 sudo apt-get install xserver-xorg-video-intel
apport-bug xorg

ProblemType: Bug
DistroRelease: Ubuntu 22.04
Package: xorg 1:7.7+23ubuntu2
ProcVersionSignature: Ubuntu 5.15.0-47.51-generic 5.15.46
Uname: Linux 5.15.0-47-generic x86_64
ApportVersion: 2.20.11-0ubuntu82.1
Architecture: amd64
BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
CasperMD5CheckResult: pass
CompositorRunning: None
CurrentDesktop: ubuntu:GNOME
Date: Mon Sep  5 12:16:17 2022
DistUpgraded: Fresh install
DistroCodename: jammy
DistroVariant: ubuntu
GraphicsCard:
 Intel Corporation HD Graphics 530 [8086:1912] (rev 06) (prog-if 00 [VGA 
controller])
   Subsystem: Dell HD Graphics 530 [1028:06b9]
InstallationDate: Installed on 2022-08-22 (13 days ago)
InstallationMedia: Ubuntu 22.04.1 LTS "Jammy Jellyfish" - Release amd64 
(20220809.1)
Lsusb:
 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
 Bus 001 Device 002: ID 093a:2510 Pixart Imaging, Inc. Optical Mouse
 Bus 001 Device 003: ID 1a2c:2d23 China Resource Semico Co., Ltd Keyboard
 Bus 001 Device 004: ID 0b0e:0300 GN Netcom Jabra EVOLVE 20 MS
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: Dell Inc. OptiPlex 7040
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-47-generic 
root=UUID=c029192a-4687-48cc-a124-1bb0c5ffb5c5 ro quiet splash vt.handoff=7
RebootRequiredPkgs: Error: path contained symlinks.
SourcePackage: xorg
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 12/08/2021
dmi.bios.release: 1.22
dmi.bios.vendor: Dell Inc.
dmi.bios.version: 1.22.0
dmi.board.name: 0HD5W2
dmi.board.vendor: Dell Inc.
dmi.board.version: A01
dmi.chassis.type: 3
dmi.chassis.vendor: Dell Inc.
dmi.modalias: 
dmi:bvnDellInc.:bvr1.22.0:bd12/08/2021:br1.22:svnDellInc.:pnOptiPlex7040:pvr:rvnDellInc.:rn0HD5W2:rvrA01:cvnDellInc.:ct3:cvr:sku06B9:
dmi.product.family: OptiPlex
dmi.product.name: OptiPlex 7040
dmi.product.sku: 06B9
dmi.sys.vendor: Dell Inc.
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.110-1ubuntu1
version.libgl1-mesa-dri: libgl1-mesa-dri 22.0.5-0ubuntu0.1
version.libgl1-mesa-glx: libgl1-mesa-glx N/A
version.xserver-xorg-core: xserver-xorg-core 2:21.1.3-2ubuntu2.1
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-2ubuntu1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20210115-1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.17-2build1

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


** Tags: amd64 apport-bug jammy ubuntu wayland-session

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to xorg in Ubuntu.
https://bugs.launchpad.net/bugs/1988752

Title:
  i was trying to update intel graphic driver

Status in xorg package in Ubuntu:
  New

Bug description:
  i was trying to update intel graphic driver
  commmands:
   sudo apt-get install xserver-xorg-video-intel
  apport-bug xorg

  ProblemType: Bug
  DistroRelease: Ubuntu 22.04
  Package: xorg 1:7.7+23ubuntu2
  ProcVersionSignature: Ubuntu 5.15.0-47.51-generic 5.15.46
  Uname: Linux 5.15.0-47-generic x86_64
  ApportVersion: 2.20.11-0ubuntu82.1
  Architecture: amd64
  BootLog: Error: [Errno 13] Permission denied: '/var/log/boot.log'
  CasperMD5CheckResult: pass
  CompositorRunning: None
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Sep  5 12:16:17 2022
  DistUpgraded: Fresh install
  DistroCodename: jammy
  DistroVariant: ubuntu
  GraphicsCard:
   Intel Corporation HD Graphics 530 [8086:1912] (rev 06) (prog-if 00 [VGA 
controller])
 Subsystem: Dell HD Graphics 530 [1028:06b9]
  InstallationDate: Installed on 2022-08-22 (13 days ago)
  InstallationMedia: Ubuntu 22.04.1 LTS "Jammy Jellyfish" - Release amd64 
(20220809.1)
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 002: ID 093a:2510 Pixart Imaging, Inc. Optical Mouse
   Bus 001 Device 003: ID 1a2c:2d23 China Resource Semico Co., Ltd Keyboard
   Bus 001 Device 004: ID 0b0e:0300 GN Netcom Jabra EVOLVE 20 MS
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: Dell Inc. OptiPlex 7040
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-47-generic 
root=UUID=c029192a-4687-48cc-a124-1bb0c5ffb5c5 ro quiet splash vt.handoff=7
  RebootRequiredPkgs: Error: path contained symlinks.
  SourcePackage: xorg
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 12/08/2021
  dmi.bios.release: 1.22
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 1.22.0
  dmi.board.name: 0HD5W2
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A01
  dmi.chassis.type: 3
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr1.22.0:bd12/08/2021:br1.22:svnDellInc.:pnOptiPlex7040:pvr:rvnDellInc.:rn0HD5W2:rvrA01:cvnDellInc.:ct3:cvr:sku06B

[Touch-packages] [Bug 1908167] Re: [SRU] pulseaudio: the headset-mic or heapdhone-mic could not be selected automatically if there is no internal mic

[Timo Aaltonen]

** Changed in: hwe-next
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pulseaudio in Ubuntu.
https://bugs.launchpad.net/bugs/1908167

Title:
  [SRU] pulseaudio: the headset-mic or heapdhone-mic could not be
  selected automatically if there is no internal mic

Status in HWE Next:
  Fix Released
Status in OEM Priority Project:
  Fix Released
Status in pulseaudio package in Ubuntu:
  Fix Released
Status in pulseaudio source package in Focal:
  Fix Released
Status in pulseaudio source package in Groovy:
  Fix Released
Status in pulseaudio source package in Hirsute:
  Fix Released

Bug description:
  [Impact]
  On the Dell AIO machines, there is no internal mic, after plugging a
  headset, users expect the headset-mic or headphone-mic could be selected
  automatically. But with the current rule, the headset-mic/headphone-mic will 
not be selected automatically and even users manually select them, they will 
not show up in the gnome sound setting, and users could not record sound by 
headset-mic/headphone-mic.

  [Fix]
  backport a patch from pulseaudio mergerequest, the patch is going to be
  merged to pulseaudio 14.1. This patch could be backported to hirsute without 
any change, but need to be changed if backport it to groovy and focal.

  [Test]
  With the old pulseaudio (prior to 1:13.99.1-1ubuntu3.10), plugging in a 
headset to the problematic Dell AIO machine will not automatically select 
headset-mic/headphone-mic, and they also do not show up in Gnome sound 
settings, leading to failure to record any sound.

  With the new proposed package, on those Dell AIO, plug a headset, open
  the gnome sound setting, the headset-mic is selected automatically,
  use the headset-mic to record the sound, the sound could be recorded
  and the sound quality is good.

  [Where problems could occur]
  This patch could change the policy of audio device switching, it will not
  affect all audio devices, but only the devices which has AVAIL_UNKNOWN 
available status, that means it has possibility to introduce the regression on 
headphone-mic ,headset-mic, internal mic and internal speaker's switching since 
they all has AVAIL_UNKNOWN status. For example, after unpluging the headset, 
the input device will not switch to internal mic automatically or after unplug 
the headphone, the output device will not switch to internal speaker 
automatically. But this possibility is very low, we have tested the patch on 
many Dell and Lenovo machines, all worked well.

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


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

[Touch-packages] [Bug 1855893] Re: Properly let PCM leave suspended state when hardware doesn't support PCM resume

[Timo Aaltonen]

** Changed in: hwe-next
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pulseaudio in Ubuntu.
https://bugs.launchpad.net/bugs/1855893

Title:
  Properly let PCM leave suspended state when hardware doesn't support
  PCM resume

Status in HWE Next:
  Fix Released
Status in pulseaudio package in Ubuntu:
  Fix Released
Status in pulseaudio source package in Bionic:
  Won't Fix

Bug description:
  [Impact]
  Headset Mic plugged into Dell WD19TB dock stops working after suspend/resume.

  [Fix]
  According to alia-lib's document, to make PCM properly leave suspended state, 
we only use snd_pcm_resume() if hardware support PCM resume.
  For hardware that doesn't support PCM resume, like snd-usb-audio on WD19TB 
dock, we should use snd_pcm_prepare(), snd_pcm_drop() or snd_pcm_drain() to 
make device leave suspended state. This patch defaults to use snd_pcm_drop() to 
achieve the goal.

  [Test]
  1. See if microphone on snd-usb-audio works in gnome-control-center/cheese.
  2. Suspend/resume.
  3. See if microphone still works in those apps.
  I can the issue is fixed after each suspend/resume cycle.

  [Regression Potential]
  Low. This fix makes PCM suspend/resume more reliable. No functional change 
intended. I also don't find any regression during some smoke test.

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


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

[Touch-packages] [Bug 1786574] Re: remove i2c-i801 from blacklist

[Timo Aaltonen]

** Changed in: hwe-next
   Status: In Progress => Fix Released

** Changed in: oem-priority
   Status: In Progress => Fix Released

** Changed in: kmod (Ubuntu Cosmic)
   Status: In Progress => Won't Fix

** Changed in: kmod (Ubuntu Xenial)
   Status: In Progress => Won't Fix

** Changed in: kmod (Ubuntu Bionic)
   Status: In Progress => Won't Fix

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to kmod in Ubuntu.
https://bugs.launchpad.net/bugs/1786574

Title:
  remove i2c-i801 from blacklist

Status in HWE Next:
  Fix Released
Status in OEM Priority Project:
  Fix Released
Status in kmod package in Ubuntu:
  Fix Released
Status in kmod source package in Xenial:
  Won't Fix
Status in kmod source package in Bionic:
  Won't Fix
Status in kmod source package in Cosmic:
  Won't Fix

Bug description:
  SRU justification
  

  [Impact]
  Many modern notebooks need i2c-i801 kernel module to function, but it is 
blacklisted by /etc/modprobe/blacklist.conf, which gives a very poor user 
experience.

  [Test case]
  1. Install Ubuntu
  2. Check touchpad works or not
  3. Install the fixed kmod package
  4. Confirm touchpad works

  [Regression Potential]
  i2c-i801 was blacklisted due to bug 16602. The user complains an HP Compaq 
nc6000 notebook cannot suspend without blacklisting i2c-i801. While this is a 
way to workaround the suspend issue, the proper fix should be in linux kernel. 
Since nc6000 was a machine sold in 2004, it is too difficult to find someone to 
verify if it will regress due to this SRU. The rationale to blacklist it is: 
https://bugs.launchpad.net/ubuntu/+source/hotplug/+bug/16602/comments/5, 
however it is no longer valid nowadays on modern computers.

  Besides, there look like to be a quirk in linux kernel that fixes it:
  https://github.com/torvalds/linux/blame/master/drivers/pci/quirks.c#L1434

  [Other Info]
  rationale of i2c_i801 driver blacklist: 
https://answers.launchpad.net/ubuntu/+source/kmod/+question/269329

  
---
  Original bug report:

  We have a Lenovo Thinkpad machine that requires i2c-i801 kernel module
  to work, but it is listed in /etc/modprobe/blacklist.conf in Ubuntu.
  To use the touchpad, users have to remove the i2c-i801 line manually.

  i2c-i801 in blacklist.conf is a very old workaround to fix HP compaq nc6000
  (Bug #16602), this module should be removed from blacklist.

  There is also another bug (Bug #1475945) that needs this module for
  Acer trackpad to work.

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


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

[Touch-packages] [Bug 1899745] Re: [SRU] alsa-utils: let alsactl support _boot section defined in ucm

[Timo Aaltonen]

** Changed in: hwe-next
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to alsa-utils in Ubuntu.
https://bugs.launchpad.net/bugs/1899745

Title:
  [SRU] alsa-utils: let alsactl support _boot section defined in ucm

Status in HWE Next:
  Fix Released
Status in alsa-utils package in Ubuntu:
  Fix Released
Status in alsa-utils source package in Focal:
  Fix Released

Bug description:
  This patchset was backported from mainline alsa-utils 1.2.3, and
  groovy already integrated alsa-utils 1.2.3, there is no need to SRU
  this patchset to groovy, so only for focal.

  [Impact]
  We enabled 2 Dell soundwire audio machines, these machines depend on
  ucm to make the audio work, and in the ucm, the _boot section defined
  some amixers values for the 1st booting, these amixer values should
  be set to audio driver at the 1st booting, otherwise the whole audio
  doesn't work.

  [Fix]
  Backport some patches from mainline v1.2.3, these patches make the
  alsactl support _boot section in the ucm, then the systemd will call
  alsactl init after booting, the alsactl init will setting all amixers
  defined in the _boot section of ucm.

  [Test Case]
  On the Dell soundwire audio machines, After booting up, run 'amixer
  contents | less' to check all amixer values defined in the _boot
  section of ucm, all values read from driver are same as the ones in
  the ucm, test speaker/microphone/headset, all work well.

  [Regression Risk]
  This could introduce failure on runing 'alsactl init' for some machines,
  then the amixers will not be initialized correctly, users will experience
  all audio can't work like speaker doesn't output sound or microphone can't
  record sound. But this regression possibility is very low, since We have
  tested it both on soundwire machines and non-soundwire machines, all worked 
well.

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


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

[Touch-packages] [Bug 1899857] Re: [SRU] alsa-lib: support the enum value settings both in "" and in ''

[Timo Aaltonen]

** Changed in: hwe-next
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to alsa-lib in Ubuntu.
https://bugs.launchpad.net/bugs/1899857

Title:
  [SRU] alsa-lib: support the enum value settings both in "" and in ''

Status in HWE Next:
  Fix Released
Status in alsa-lib package in Ubuntu:
  Fix Released
Status in alsa-lib source package in Focal:
  Fix Released
Status in alsa-lib source package in Groovy:
  Fix Released

Bug description:
  [Impact]
  Recently the ucm added some amixer settings, like this one:
  cset "name='rt711 ADC 23 Mux' 'MIC2'"
  This setting is needed for Dell soundwire audio machines, and only
  this setting is set correctly, the headset-mic could work. And we
  already backported this ucm to focal. But the alsa-lib ctl parse
  doesn't support the enum value in the '' yet, so this amixer setting
  can't be set correctly under current focal and groovy, we need to
  backport a patch from alsa-lib master branch.

  [Fix]
  Backport a patch from upstream, this patch is not in the groovy
  yet (not in the alsa-lib v1.2.3.2), so both groovy and focal need this
  patch.

  [Test Case]
  On the Dell soundwire audio machine, run alsactl init, then check if
  the amixer "rt711 ADC 23 Mux" is set to "MIC2" or not, if it is set
  correctly, it means the alsalib enum ctl parse support both "" and ''
  now.

  
  [Regression Risk]
  This could introduce failure on setting enum amixer settings, users
  will experience the failure of audio device like the speaker can't output
  sound, the mic can't record sound. But this possibility is very low since
  we have tested this SRU on many LENOVO and Dell machines (with and without
  soundwire audio), all worked as fine as before.

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


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

[Touch-packages] [Bug 1902464] Re: The rear panel of Lenovo P620 doesn't support more than one audio device at the same time

[Timo Aaltonen]

** Changed in: hwe-next
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pulseaudio in Ubuntu.
https://bugs.launchpad.net/bugs/1902464

Title:
  The rear panel of Lenovo P620 doesn't support more than one audio
  device at the same time

Status in HWE Next:
  Fix Released
Status in OEM Priority Project:
  Fix Released
Status in alsa-ucm-conf package in Ubuntu:
  Fix Released
Status in pulseaudio package in Ubuntu:
  Fix Released
Status in alsa-ucm-conf source package in Focal:
  Fix Released
Status in pulseaudio source package in Focal:
  Fix Released

Bug description:
  == SRU Justification ==
  [Impact]
  On P620, only single port can work on rear panel. For example, when the 
Line-Out is plugged, the Mic won't work anymore.

  [Fix]
  Use upstream version of UCM to handle port priority correctly, instead of 
separate ports into different profiles.

  [Test]
  Once the UCM is in place, all three ports of rear panel work correctly.

  [Where problems could occur]
  UCM is not a static thing - it's actually interpreted differently at higher 
level. So any change in userspace daemons other than PulseAudio may not like 
the change and can interpret the UCM in another way.

  == Original Bug Report ==
  After backporting following patches from PA and alsa-ucm-conf and then it 
works.

  https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/290
  https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/354
  https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/355

  https://github.com/alsa-project/alsa-ucm-conf/tree/master/ucm2/USB-
  Audio [landed by aa74f4c12eefcc98582572d2fc48982cf7478b51]

  Here is the test PPA:
  https://launchpad.net/~os369510/+archive/ubuntu/oem-package-test

  Since the upstream not yet accepted those patches, the regression
  potential may quite high.

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


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

[Touch-packages] [Bug 1890448] Re: hwdb: Add EliteBook to use micmute hotkey

[Timo Aaltonen]

** Changed in: hwe-next
   Status: New => Incomplete

** Changed in: hwe-next
   Status: Incomplete => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1890448

Title:
  hwdb: Add EliteBook to use micmute hotkey

Status in HWE Next:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Fix Released
Status in systemd source package in Focal:
  Fix Released

Bug description:
  [Impact]
  Micmute hotkey on many HP EliteBooks don't work.

  [Fix]
  Commit b6eb208b29ae ("hwdb: Add EliteBook to use micmute hotkey"), to map AT 
keyboard's scancode to micmute hotkey.

  [Test]
  With the one-liner fix, micmute hotkey works on all the EliteBooks I tested.

  [Regression Potential]
  The hwdb originally only matches a few EliteBook, and fix changes that to 
match all EliteBook models. So if there's an EliteBook that uses the scancode 
for other purpose, there will be a regression.
  However, the risk is rather slim because HP is confident that all EliteBooks 
use the same scancode for mic mute hotkey.

  [scope]

  this is needed for f and earlier.

  this is fixed upstream by commit b6eb208b29ae which is included
  starting in v246, so g and later are already fixed.

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


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

[Touch-packages] [Bug 1882042] Re: [SRU] Linux, Ubuntu, 18.4, CI, OLP15, PRTS, Audio/video is out of sync/lag when enter Suspend during playback

[Timo Aaltonen]

** Changed in: hwe-next
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pulseaudio in Ubuntu.
https://bugs.launchpad.net/bugs/1882042

Title:
  [SRU] Linux,Ubuntu,18.4,CI,OLP15,PRTS, Audio/video is out of sync/lag
  when enter Suspend during playback

Status in HWE Next:
  Fix Released
Status in pulseaudio package in Ubuntu:
  Fix Released
Status in pulseaudio source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  Users reported the audio and video is out of sync when entering suspend 
during playback on bionic.

  [Fix]
  The mainline pulseaudio already has the fix for this issue, and the fix is 
already in the eoan, focal and groovy, but it is not in the bionic.

  [Test Case]
  open a online video on the firefox, while it is playing, suspend the system, 
wait for 30 seconds, resume the system, the audio and video is still on the 
sync.

  [Potential Regression Risk]
  Low, these 2 patches are already in the mainline pulseaudio, and already in 
the eoan, focal and groovy.

  Most of the change is in the suspend/unsuspend on alsa sink/source, the 
potential regression risk is the playback/recording stops working after
  machine suspend and resume or playback/recording has an obvious discontinuity 
before suspend and after resume. I have done the test on a Lenovo and a Dell 
machine, the playback/recording worked well after resuming.

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


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

[Touch-packages] [Bug 1883670] Re: Disable IEC958 on HP Thunderbolt Dock

[Timo Aaltonen]

** Changed in: hwe-next
   Status: New => Incomplete

** Changed in: hwe-next
   Status: Incomplete => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to alsa-lib in Ubuntu.
https://bugs.launchpad.net/bugs/1883670

Title:
  Disable IEC958 on HP Thunderbolt Dock

Status in HWE Next:
  Fix Released
Status in OEM Priority Project:
  Fix Released
Status in alsa-lib package in Ubuntu:
  Fix Released
Status in alsa-lib source package in Focal:
  Fix Released
Status in alsa-lib source package in Groovy:
  Fix Released

Bug description:
  [Impact]
  On HP Thunderbolt Dock, unusable SPDIF can be selected as output from 
PulseAudio.

  [Fix]
  Disable IEC958 (SPDIF) through ALSA UCM.

  [Test]
  With the UCM applied, `pactl` and audio panel in gnome-control-center no 
longer have SPDIF option.

  [Regression Potential]
  Low. This fix limits to the HP Thunderbolt Dock, other devices are unaffected.

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


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

[Touch-packages] [Bug 1887610] Re: [SRU]There is no available audio entry in sound settings after execute suspend in 'Performance mode'

[Timo Aaltonen]

** Changed in: hwe-next
   Status: New => Fix Released

** Changed in: pulseaudio (Ubuntu Bionic)
   Status: In Progress => Won't Fix

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pulseaudio in Ubuntu.
https://bugs.launchpad.net/bugs/1887610

Title:
  [SRU]There is no available audio entry in sound settings after execute
  suspend in 'Performance mode'

Status in HWE Next:
  Fix Released
Status in OEM Priority Project:
  Fix Released
Status in pulseaudio package in Ubuntu:
  Fix Released
Status in pulseaudio source package in Bionic:
  Won't Fix
Status in pulseaudio source package in Eoan:
  Won't Fix
Status in pulseaudio source package in Focal:
  Fix Released
Status in pulseaudio source package in Groovy:
  Fix Released

Bug description:
  [Impact]
  On some I+N machines (inlcuding lenovo and dell machines), after
  setting the graphic mode to perofermance mode, and open the gnome
  sound seting, run suspend/resume test, the audio devices will
  disappear from UI, instead a dummy audio shows on the UI, and from
  then on, the audio can't work anymore.

  [Fix]
  The root cause is after resuming, the pulseaudio try to recover the
  PCM device, but at that moment, the devices nodes at /dev/snd/ are
  not accessible yet sometimes, it will make snd_pcm_open fail and
  the pulseaudio will calll unload_module to unload alsa audio card.
  I cherrpicked a fix from upstream, the fix adds retry and pa_msleep(),
  this will retry the snd_pcm_open() a couple of times if it fails.

  [Test Case]
  Install the pulseaudio wit this fix, set the graphic mode to
  performance mode, open the sound setting, then run suspend/resume 90
  times, after test check the audio devices on the UI, the speaker,
  digital mic are still on the UI, and they could work well.

  [Regression Risk]
  Low, this SRU just add retry and pa_msleep(), if the snd_pcm_open()
  doesn't fail, this patch will not introduce any change, if snd_pcm_open()
  fails, it just retry a couple of times, so it will not introduce the
  regression in theory.

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


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

[Touch-packages] [Bug 1988230] Re: glib 2.73 breaks modemmanager

[Sebastien Bacher]

The new glib issues were fixed in git, new snapshot upload and built

https://launchpad.net/ubuntu/+source/modemmanager/1.19~git20220905-0ubuntu1

** Changed in: glib2.0 (Ubuntu)
   Status: Triaged => Invalid

** Changed in: modemmanager (Ubuntu)
   Importance: Undecided => High

** Changed in: modemmanager (Ubuntu)
   Status: Triaged => In Progress

** Changed in: modemmanager (Ubuntu)
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to glib2.0 in Ubuntu.
https://bugs.launchpad.net/bugs/1988230

Title:
  glib 2.73 breaks modemmanager

Status in GLib:
  Fix Released
Status in glib2.0 package in Ubuntu:
  Invalid
Status in modemmanager package in Ubuntu:
  Fix Released
Status in glib2.0 package in Debian:
  Confirmed

Bug description:
  I'm filing this bug in case we want to fix it before letting glib 2.73
  in to kinetic.

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


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

[Touch-packages] [Bug 1988629] Re: apt install libudev-dev fails on bionic (dependency conflict)

[Launchpad Bug Tracker]

Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: systemd (Ubuntu)
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1988629

Title:
  apt install libudev-dev fails on bionic (dependency conflict)

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  The following fails, this was broken within the last few days:

  docker run -it --rm ubuntu:bionic
  apt update
  apt install libudev-dev

  
  Output:
  ```
  ~$ docker run -it --rm ubuntu:bionic
  Unable to find image 'ubuntu:bionic' locally
  bionic: Pulling from library/ubuntu
  dad0f37c70a6: Pull complete
  Digest: 
sha256:3aa2ccb021969aadb28381fee1b247422e845b176e241cd1540c4b6831e000bb
  Status: Downloaded newer image for ubuntu:bionic
  root@391196612b51:/# apt update
  Get:1 http://security.ubuntu.com/ubuntu bionic-security InRelease [88.7 kB]
  Get:2 http://archive.ubuntu.com/ubuntu bionic InRelease [242 kB]
  Get:3 http://security.ubuntu.com/ubuntu bionic-security/restricted amd64 
Packages [1114 kB]
  Get:4 http://security.ubuntu.com/ubuntu bionic-security/multiverse amd64 
Packages [22.8 kB]
  Get:5 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages 
[2953 kB]
  Get:6 http://security.ubuntu.com/ubuntu bionic-security/universe amd64 
Packages [1540 kB]
  Get:7 http://archive.ubuntu.com/ubuntu bionic-updates InRelease [88.7 kB]
  Get:8 http://archive.ubuntu.com/ubuntu bionic-backports InRelease [74.6 kB]
  Get:9 http://archive.ubuntu.com/ubuntu bionic/multiverse amd64 Packages [186 
kB]
  Get:10 http://archive.ubuntu.com/ubuntu bionic/restricted amd64 Packages 
[13.5 kB]
  Get:11 http://archive.ubuntu.com/ubuntu bionic/universe amd64 Packages [11.3 
MB]
  Get:12 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages [1344 kB]
  Get:13 http://archive.ubuntu.com/ubuntu bionic-updates/multiverse amd64 
Packages [29.9 kB]
  Get:14 http://archive.ubuntu.com/ubuntu bionic-updates/restricted amd64 
Packages [1162 kB]
  Get:15 http://archive.ubuntu.com/ubuntu bionic-updates/universe amd64 
Packages [2318 kB]
  Get:16 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages 
[3390 kB]
  Get:17 http://archive.ubuntu.com/ubuntu bionic-backports/universe amd64 
Packages [12.9 kB]
  Get:18 http://archive.ubuntu.com/ubuntu bionic-backports/main amd64 Packages 
[12.2 kB]
  Fetched 25.9 MB in 2s (10.4 MB/s)
  Reading package lists... Done
  Building dependency tree
  Reading state information... Done
  All packages are up to date.
  root@391196612b51:/# apt install libudev-dev
  Reading package lists... Done
  Building dependency tree
  Reading state information... Done
  Some packages could not be installed. This may mean that you have
  requested an impossible situation or if you are using the unstable
  distribution that some required packages have not yet been created
  or been moved out of Incoming.
  The following information may help to resolve the situation:

  The following packages have unmet dependencies:
   libudev-dev : Depends: libudev1 (= 237-3ubuntu10.53) but 237-3ubuntu10.54 is 
to be installed
  E: Unable to correct problems, you have held broken packages.
  ```

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


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

[Touch-packages] [Bug 1988730] Re: package libsasl2-modules provides only unsafe SASL bind mechanims

[rdratlos]

Attached patch adds SCRAM family mechanisms to the SASL shared secret mechanims 
package. It has been tested on an LDAP client in three configurations:
- libsasl2-modules-gssapi-* not installed
- libsasl2-modules-gssapi-mit installed
- libsasl2-modules-gssapi-heimdal installed

For the latter two configurations also GSSAPI SASL authentication has
been tested.


** Patch added: "Fix SCRAM support for SASL authentication"
   
https://bugs.launchpad.net/ubuntu/+source/cyrus-sasl2/+bug/1988730/+attachment/5613734/+files/fix-sasl-scram-support.patch

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to cyrus-sasl2 in Ubuntu.
https://bugs.launchpad.net/bugs/1988730

Title:
  package libsasl2-modules provides only unsafe SASL bind mechanims

Status in cyrus-sasl2 package in Ubuntu:
  New

Bug description:
  Current Cyrus libsasl2 packaging (Ubuntu Jammy) distributes SASL bind 
mechanims into different packages. Plained and shared secret mechanisms are 
provided by package libsasl2-modules:
  /usr/lib/x86_64-linux-gnu/sasl2/libanonymous.so
  /usr/lib/x86_64-linux-gnu/sasl2/libanonymous.so.2
  /usr/lib/x86_64-linux-gnu/sasl2/libanonymous.so.2.0.25
  /usr/lib/x86_64-linux-gnu/sasl2/libcrammd5.so
  /usr/lib/x86_64-linux-gnu/sasl2/libcrammd5.so.2
  /usr/lib/x86_64-linux-gnu/sasl2/libcrammd5.so.2.0.25
  /usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so
  /usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so.2
  /usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so.2.0.25
  /usr/lib/x86_64-linux-gnu/sasl2/liblogin.so
  /usr/lib/x86_64-linux-gnu/sasl2/liblogin.so.2
  /usr/lib/x86_64-linux-gnu/sasl2/liblogin.so.2.0.25
  /usr/lib/x86_64-linux-gnu/sasl2/libntlm.so
  /usr/lib/x86_64-linux-gnu/sasl2/libntlm.so.2
  /usr/lib/x86_64-linux-gnu/sasl2/libntlm.so.2.0.25
  /usr/lib/x86_64-linux-gnu/sasl2/libplain.so
  /usr/lib/x86_64-linux-gnu/sasl2/libplain.so.2
  /usr/lib/x86_64-linux-gnu/sasl2/libplain.so.2.0.25

  The "safest" mechanism in this list is DIGEST-MD5, which is marked as
  obsolete by IANA and regarded as unsafe by IETF. Current safest
  standard mechanisms are SCRAM based (RFC7677).

  All SCRAM family SASL mechanisms of Cyrus SASL are provided by Ubuntu package 
libsasl2-modules-gssapi-mit:
  /usr/lib/x86_64-linux-gnu/sasl2/libscram.so
  /usr/lib/x86_64-linux-gnu/sasl2/libscram.so.2
  /usr/lib/x86_64-linux-gnu/sasl2/libscram.so.2.0.25

  But the focus of this package is GSSAPI and GS2 SASL mechanism, which
  have nothing to do with SCRAM. In addition, this package conflicts
  with package libsasl2-modules-gssapi-heimdal. System administrators
  have to choose one package for support of GSSAPI or GSS-SPEGNO. If
  they prefer Heimdal there is no safe SASL shared secret mechanism
  available anymore on the server/workstation.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cyrus-sasl2/+bug/1988730/+subscriptions


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

[Touch-packages] [Bug 1988563] Re: package libudev-dev dependency conflict

[fleetwood]

Is there a workaround for this? We're struggling to run builds and would
love to know if there's something we can do to avoid this

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1988563

Title:
  package libudev-dev dependency conflict

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  I am not sure if this is the right place to file this, but we are
  getting the following error when installing libudev-dev on bionic

  Installing libudev-dev fails for bionic with the following error:

  ```
  Some packages could not be installed. This may mean that you have
  requested an impossible situation or if you are using the unstable
  distribution that some required packages have not yet been created
  or been moved out of Incoming.
  The following information may help to resolve the situation:

  The following packages have unmet dependencies:
   libudev-dev : Depends: libudev1 (= 237-3ubuntu10.53) but 237-3ubuntu10.54 is 
to be installed
  E: Unable to correct problems, you have held broken packages.
  ```

  Steps to reproduce:

  ```
  docker run -it --rm ubuntu:bionic
  apt update
  apt install libudev-dev
  ```

  Complete log:
  ```
  ~$ docker run -it --rm ubuntu:bionic
  Unable to find image 'ubuntu:bionic' locally
  bionic: Pulling from library/ubuntu
  dad0f37c70a6: Pull complete 
  Digest: 
sha256:3aa2ccb021969aadb28381fee1b247422e845b176e241cd1540c4b6831e000bb
  Status: Downloaded newer image for ubuntu:bionic
  root@391196612b51:/# apt update
  Get:1 http://security.ubuntu.com/ubuntu bionic-security InRelease [88.7 kB]
  Get:2 http://archive.ubuntu.com/ubuntu bionic InRelease [242 kB]  
 
  Get:3 http://security.ubuntu.com/ubuntu bionic-security/restricted amd64 
Packages [1114 kB]
  Get:4 http://security.ubuntu.com/ubuntu bionic-security/multiverse amd64 
Packages [22.8 kB]
  Get:5 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages 
[2953 kB]
  Get:6 http://security.ubuntu.com/ubuntu bionic-security/universe amd64 
Packages [1540 kB]
  Get:7 http://archive.ubuntu.com/ubuntu bionic-updates InRelease [88.7 kB] 
 
  Get:8 http://archive.ubuntu.com/ubuntu bionic-backports InRelease [74.6 kB]
  Get:9 http://archive.ubuntu.com/ubuntu bionic/multiverse amd64 Packages [186 
kB]
  Get:10 http://archive.ubuntu.com/ubuntu bionic/restricted amd64 Packages 
[13.5 kB]
  Get:11 http://archive.ubuntu.com/ubuntu bionic/universe amd64 Packages [11.3 
MB]
  Get:12 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages [1344 kB]
  Get:13 http://archive.ubuntu.com/ubuntu bionic-updates/multiverse amd64 
Packages [29.9 kB]
  Get:14 http://archive.ubuntu.com/ubuntu bionic-updates/restricted amd64 
Packages [1162 kB]
  Get:15 http://archive.ubuntu.com/ubuntu bionic-updates/universe amd64 
Packages [2318 kB]
  Get:16 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages 
[3390 kB]
  Get:17 http://archive.ubuntu.com/ubuntu bionic-backports/universe amd64 
Packages [12.9 kB]
  Get:18 http://archive.ubuntu.com/ubuntu bionic-backports/main amd64 Packages 
[12.2 kB]
  Fetched 25.9 MB in 2s (10.4 MB/s) 
  Reading package lists... Done
  Building dependency tree   
  Reading state information... Done
  All packages are up to date.
  root@391196612b51:/# apt install libudev-dev
  Reading package lists... Done
  Building dependency tree   
  Reading state information... Done
  Some packages could not be installed. This may mean that you have
  requested an impossible situation or if you are using the unstable
  distribution that some required packages have not yet been created
  or been moved out of Incoming.
  The following information may help to resolve the situation:

  The following packages have unmet dependencies:
   libudev-dev : Depends: libudev1 (= 237-3ubuntu10.53) but 237-3ubuntu10.54 is 
to be installed
  E: Unable to correct problems, you have held broken packages.
  ```

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


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

[Touch-packages] [Bug 1988730] [NEW] package libsasl2-modules provides only unsafe SASL bind mechanims

[rdratlos]

Public bug reported:

Current Cyrus libsasl2 packaging (Ubuntu Jammy) distributes SASL bind mechanims 
into different packages. Plained and shared secret mechanisms are provided by 
package libsasl2-modules:
/usr/lib/x86_64-linux-gnu/sasl2/libanonymous.so
/usr/lib/x86_64-linux-gnu/sasl2/libanonymous.so.2
/usr/lib/x86_64-linux-gnu/sasl2/libanonymous.so.2.0.25
/usr/lib/x86_64-linux-gnu/sasl2/libcrammd5.so
/usr/lib/x86_64-linux-gnu/sasl2/libcrammd5.so.2
/usr/lib/x86_64-linux-gnu/sasl2/libcrammd5.so.2.0.25
/usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so
/usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so.2
/usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so.2.0.25
/usr/lib/x86_64-linux-gnu/sasl2/liblogin.so
/usr/lib/x86_64-linux-gnu/sasl2/liblogin.so.2
/usr/lib/x86_64-linux-gnu/sasl2/liblogin.so.2.0.25
/usr/lib/x86_64-linux-gnu/sasl2/libntlm.so
/usr/lib/x86_64-linux-gnu/sasl2/libntlm.so.2
/usr/lib/x86_64-linux-gnu/sasl2/libntlm.so.2.0.25
/usr/lib/x86_64-linux-gnu/sasl2/libplain.so
/usr/lib/x86_64-linux-gnu/sasl2/libplain.so.2
/usr/lib/x86_64-linux-gnu/sasl2/libplain.so.2.0.25

The "safest" mechanism in this list is DIGEST-MD5, which is marked as
obsolete by IANA and regarded as unsafe by IETF. Current safest standard
mechanisms are SCRAM based (RFC7677).

All SCRAM family SASL mechanisms of Cyrus SASL are provided by Ubuntu package 
libsasl2-modules-gssapi-mit:
/usr/lib/x86_64-linux-gnu/sasl2/libscram.so
/usr/lib/x86_64-linux-gnu/sasl2/libscram.so.2
/usr/lib/x86_64-linux-gnu/sasl2/libscram.so.2.0.25

But the focus of this package is GSSAPI and GS2 SASL mechanism, which
have nothing to do with SCRAM. In addition, this package conflicts with
package libsasl2-modules-gssapi-heimdal. System administrators have to
choose one package for support of GSSAPI or GSS-SPEGNO. If they prefer
Heimdal there is no safe SASL shared secret mechanism available anymore
on the server/workstation.

** Affects: cyrus-sasl2 (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to cyrus-sasl2 in Ubuntu.
https://bugs.launchpad.net/bugs/1988730

Title:
  package libsasl2-modules provides only unsafe SASL bind mechanims

Status in cyrus-sasl2 package in Ubuntu:
  New

Bug description:
  Current Cyrus libsasl2 packaging (Ubuntu Jammy) distributes SASL bind 
mechanims into different packages. Plained and shared secret mechanisms are 
provided by package libsasl2-modules:
  /usr/lib/x86_64-linux-gnu/sasl2/libanonymous.so
  /usr/lib/x86_64-linux-gnu/sasl2/libanonymous.so.2
  /usr/lib/x86_64-linux-gnu/sasl2/libanonymous.so.2.0.25
  /usr/lib/x86_64-linux-gnu/sasl2/libcrammd5.so
  /usr/lib/x86_64-linux-gnu/sasl2/libcrammd5.so.2
  /usr/lib/x86_64-linux-gnu/sasl2/libcrammd5.so.2.0.25
  /usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so
  /usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so.2
  /usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so.2.0.25
  /usr/lib/x86_64-linux-gnu/sasl2/liblogin.so
  /usr/lib/x86_64-linux-gnu/sasl2/liblogin.so.2
  /usr/lib/x86_64-linux-gnu/sasl2/liblogin.so.2.0.25
  /usr/lib/x86_64-linux-gnu/sasl2/libntlm.so
  /usr/lib/x86_64-linux-gnu/sasl2/libntlm.so.2
  /usr/lib/x86_64-linux-gnu/sasl2/libntlm.so.2.0.25
  /usr/lib/x86_64-linux-gnu/sasl2/libplain.so
  /usr/lib/x86_64-linux-gnu/sasl2/libplain.so.2
  /usr/lib/x86_64-linux-gnu/sasl2/libplain.so.2.0.25

  The "safest" mechanism in this list is DIGEST-MD5, which is marked as
  obsolete by IANA and regarded as unsafe by IETF. Current safest
  standard mechanisms are SCRAM based (RFC7677).

  All SCRAM family SASL mechanisms of Cyrus SASL are provided by Ubuntu package 
libsasl2-modules-gssapi-mit:
  /usr/lib/x86_64-linux-gnu/sasl2/libscram.so
  /usr/lib/x86_64-linux-gnu/sasl2/libscram.so.2
  /usr/lib/x86_64-linux-gnu/sasl2/libscram.so.2.0.25

  But the focus of this package is GSSAPI and GS2 SASL mechanism, which
  have nothing to do with SCRAM. In addition, this package conflicts
  with package libsasl2-modules-gssapi-heimdal. System administrators
  have to choose one package for support of GSSAPI or GSS-SPEGNO. If
  they prefer Heimdal there is no safe SASL shared secret mechanism
  available anymore on the server/workstation.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cyrus-sasl2/+bug/1988730/+subscriptions


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

[Touch-packages] [Bug 1897932] Re: systemd-repart not packaged

[Łukasz Zemczak]

Hello Iain, or anyone else affected,

Accepted systemd into jammy-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/systemd/249.11-0ubuntu3.5 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
jammy to verification-done-jammy. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-jammy. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: systemd (Ubuntu Jammy)
   Status: Confirmed => Fix Committed

** Tags added: verification-needed verification-needed-jammy

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1897932

Title:
  systemd-repart not packaged

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Jammy:
  Fix Committed
Status in systemd package in Debian:
  Fix Released

Bug description:
  [Impact]

  systemd-repart is not (as of 246.6-1ubuntu1) packaged in the
  Ubuntu/Debian packages of systemd - probably because it has an extra
  dependency?

  The bug reporter would like to use it in their new raspberry pi images
  where they don't have cloud-init installed. The reporter is already
  using systemd-growfs, but they are missing the nice partition resizing
  part (so are using cloud-initramfs-growroot).

  Furthermore, in the mkosi image builder
  (https://github.com/systemd/mkosi), the systemd/mkosi developers would
  like to start using systemd-repart for partitioning. Unfortunately,
  they're currently blocked on this because 22.04 doesn't ship systemd-
  repart. The upstream CI uses Github Actions which runs on Ubuntu Jammy
  and will do so until the next Ubuntu LTS is released. If we have to
  wait for the next LTS to be released, we'll have to wait for a
  considerable amount of time before we're able to start using systemd-
  repart.

  Being able to use systemd-repart will allow the systemd/mkosi developers to 
take advantage of its improved interface compared to sfdisk,
  as well as its builtin protections against race conditions surrounding the 
use of loop devices. The systemd/mkosi developers expect to
  be able to get rid of some nasty loop device failure in mkosi by using 
systemd-repart.

  [Test Plan]
  This is a missing extra executable. Once enabled it has self-tests in the 
build-time unit tests, and also a regression test in the autopkgtest 'upstream' 
suite.

  * Attach (local) build-log showing the systemd-repart self-tests passing, as 
found in build-deb/meson-logs/testlog.txt
  * Attach autopkgtest logs showing the regression tests passing (especially 
TEST-58-REPART from "upstream-2" testsuite)
  * Test upgrade-path Jammy->Kinetic to make sure systemd-repart is properly 
replaced by Kinetic's "systemd" binary package

  [Where problems could occur]
  Shipping systemd-repart will come with no additional risk. While there is a 
systemd-repart.service that runs on boot, it's configured to not do anything if 
no config files are shipped with the system or provided by the user. As such, 
the service, if enabled, will effectively be a noop. Aside from the service, 
there's the CLI tool systemd-repart and the accompanying man pages that will be 
shipped as part of the systemd package.

  Given that there's no risk involved with enabling systemd-repart, and
  given the useful features it provides, the systemd/mkosi developers
  would like to request that systemd-repart be enabled in Ubuntu and
  backported to Jammy so that they can start adopting it in mkosi.

  Runtime behavior of existing components is not affected by the build
  config change.

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


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

[Touch-packages] [Bug 1979951] Re: 127.0.0.1/::1 removed from loopback interface if you configure extra IPs on lo (r104 regression/behaviour change)

[Łukasz Zemczak]

Hello Trent, or anyone else affected,

Accepted systemd into jammy-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/systemd/249.11-0ubuntu3.5 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
jammy to verification-done-jammy. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-jammy. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: systemd (Ubuntu Jammy)
   Status: New => Fix Committed

** Tags added: verification-needed verification-needed-jammy

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1979951

Title:
  127.0.0.1/::1 removed from loopback interface if you configure extra
  IPs on lo (r104 regression/behaviour change)

Status in netplan.io package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Fix Released
Status in netplan.io source package in Focal:
  New
Status in systemd source package in Focal:
  New
Status in netplan.io source package in Jammy:
  New
Status in systemd source package in Jammy:
  Fix Committed

Bug description:
  [Impact]

  Users who wish to configure additional addresses on lo may
  inadvertently remove the 127.0.0.1/8 address from the interface. And,
  because this only happens on the second invocation of `netplan apply`,
  it can create confusing breakages for users. Although this is not a
  recommended configuration, it was previously supported and the current
  behavior is a regression.

  [Test Plan]

  * Configure additional addresses on the lo interface. I am testing in
  a LXD container, so I added the following to /etc/netplan/10-lxc.yaml
  under `ethernets:`

  lo:
addresses: ["10.10.10.17/24","10.10.10.19/24"]

  * Apply the config, and then inspect the lo interface's addresses:

   $ netplan apply
   $ ip addr show dev lo

  * Observe that the 127.0.0.1/8 address is still present. Now, run the
  same commands again:

   $ netplan apply
   $ ip addr show dev lo

  * On an affected system, observe that the 127.0.0.1/8 address is now
  gone. On a patched system, the address should still be present.

  [Where problems could occur]

  The patch removes cases where systemd-networkd will drop foreign
  addresses from a managed link. If problems were to occur, it would be
  related to the addresses configured on a managed link.

  [Original Description]

  If you configure the loopback interface using netplan without listing
  the standard loopback addresses (127.0.0.1 / ::1) that are auto-
  configured on boot then they are removed by netplan in r104+ but were
  not in r103.

  Confusingly this only happens the second time "netplan apply" is
  invoked and not the first time.

  There is some argument this is not a valid configuration, however
  - It worked on r103 and broke in the r104 SRU for 20.04 and breaks on upgrade
  - Since it only occurs on the second "netplan apply" it is likely people will 
accidentally create a configuration that on first verification works but breaks 
later
  - Adding addresses to a loopback or dummy interface is a common need
  - There is no dummy interface support in Netplan
  - Removing the loopback IP doesn't immediately cause obvious breakage in an 
SSH session but causes all sorts of hard to diagnose issues with applications

  Thus I consider this a high priority regression because of the
  multiple ways this can break a system at an unexpected/unrelated time
  to when the original change was made.

  As a workaround you can add 127.0.0.1/::1 to the file and this seems
  to generally work and product almost the same configuration with the
  exception that "brd 127.255.255.255" is added to the "ip addr" output
  compared to the auto-created configuration. All of the different
  routing tables seem otherwise the tame.

  = Test Case =
  (1) Add IP configuration for lo to /etc/netplan/lo.yaml

  lo:
    match:
  name: lo
    addresses:
    - 10.10.10.17/24
    - 10.10.10.19/24

  (2) Run "netplan apply" and observe the "ip addr show dev lo" output. 
Expected: 1

[Touch-packages] [Bug 1975667] Re: systemd-resolved does not reset DNS server and search domain list properly after VPN disconnect

[Łukasz Zemczak]

Hello stan383, or anyone else affected,

Accepted systemd into jammy-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/systemd/249.11-0ubuntu3.5 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
jammy to verification-done-jammy. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-jammy. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: systemd (Ubuntu Jammy)
   Status: Confirmed => Fix Committed

** Tags added: verification-needed verification-needed-jammy

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1975667

Title:
  systemd-resolved does not reset DNS server and search domain list
  properly after VPN disconnect

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Jammy:
  Fix Committed

Bug description:
  [Impact]

  Networking components such as VPNs that rely on systemd-resolved's API
  to configure search domains may inadvertently leave the network
  configuration in a bad state. This is a result of a broken systemd-
  resolved API.

  [Test Plan]
  * On a jammy host, configure a couple search domains with resolvectl:

  $ resolvectl domain  search1.internal search2.internal
  $ resolvectl domain 

  * In any case, both domains should be displayed. Then, attempt to
  clear the configured domains:

  $ resolvectl domain  ""
  $ resolvectl domain 

  * On a patched system, the two domains should no longer be displayed.
  On an un-patched system, one of the domains will still be configured.

  [Where problems could occur]
  This patch touches the logic that configures search domains in 
systemd-resolved. If the patch caused regressions, it would be related to the 
set of configured search domains.

  [Original Description]

  Hi,
  in Ubuntu 21.10 I am facing a problem with DNS server list and search domain 
list is not properly reset back to the previous values after a VPN is 
disconnected. I reproduced this in Ubuntu 21.10 instance which was upgraded 
from the older version of Ubuntu as well as in Live USB Ubuntu 21.10 so it is 
not an "upgrade issue".

  I use this resolv.conf symlink:
  /etc/resolv.conf -> ../run/systemd/resolve/resolv.conf

  Actual behavior:
  VPN connect will add VPN's DNS servers and search domains into 
/etc/resolv.conf. When VPN is disconnected there are some of the VPN's DNS 
server and search domain entries left there, so it is not reset back properly.

  Desired behavior:
  VPN connect will add VPN's DNS servers and search domains into 
/etc/resolv.conf. When VPN is disconnected DNS servers and search domain list 
is restored to exactly the same state as was prior to the VPN connection.

  Steps for reproducing:
  1. Before VPN is connected this is the DNS server and search domain list in 
/etc/resolv.conf:

  nameserver 192.168.122.1
  search .

  2. Once the VPN is connected, we see there were VPN's DNS server and
  serach domain list entries added:

  nameserver 2xx.xx.xx.x0
  nameserver 2xx.xx.xx.x1
  nameserver 192.168.122.1
  search domain1.local domain2.internal domain3.internal

  3. After VPN disconnection, we see the DNS server and search domain
  list in /etc/resolv.conf is not restored to the state at point (1.)
  and some entries from VPN is being kept there:

  nameserver 2xx.xx.xx.x1
  nameserver 192.168.122.1
  search domain2.internal domain3.internal

  ProblemType: Bug
  DistroRelease: Ubuntu 21.10
  Package: systemd 248.3-1ubuntu8
  ProcVersionSignature: Ubuntu 5.13.0-19.19-generic 5.13.14
  Uname: Linux 5.13.0-19-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.11-0ubuntu70
  Architecture: amd64
  CasperMD5CheckResult: pass
  CasperVersion: 1.465
  CurrentDesktop: ubuntu:GNOME
  Date: Wed May 25 06:06:05 2022
  LiveMediaBuild: Ubuntu 21.10 "Impish Indri" - Release amd64 (20211012)
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd QEMU

[Touch-packages] [Bug 1981042] Re: /etc/localtime symlink not correctly handled when using /etc/writable

[Łukasz Zemczak]

Hello Robert, or anyone else affected,

Accepted systemd into jammy-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/systemd/249.11-0ubuntu3.5 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
jammy to verification-done-jammy. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-jammy. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: systemd (Ubuntu Jammy)
   Status: New => Fix Committed

** Tags added: verification-needed verification-needed-jammy

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1981042

Title:
  /etc/localtime symlink not correctly handled when using /etc/writable

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Jammy:
  Fix Committed
Status in systemd source package in Kinetic:
  Fix Released

Bug description:
  [Impact]
  When using /etc/writable (e.g. Ubuntu Core) /etc/localtime is a symlink to 
/etc/writable/localtime (which in itself if a symlink). Systemd doesn't handle 
this correctly when doing firstboot or using inotify to watch for changes to 
localtime.

  [Test Plan]
  This is somewhat hard to test, the following situations need to be reproduced:
  - On firstboot the timezone link will not be read correctly, it will with 
this change.
  - Starting a timer unit and then changing timezone will cause it not to occur 
at the correct time.

  [Where problems could occur]
  This could potentially break other users of localtime, however the change is 
similar to existing changes which have been in Ubuntu's version of systemd for 
some time. The change detects the /etc/writable case and if not should have the 
same existing behaviour.

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


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

[Touch-packages] [Bug 1979952] Re: Bind mount to NFS mount fails on Ubuntu 22.04

[Łukasz Zemczak]

Hello Philipp, or anyone else affected,

Accepted systemd into jammy-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/systemd/249.11-0ubuntu3.5 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
jammy to verification-done-jammy. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-jammy. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Tags added: verification-needed verification-needed-jammy

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1979952

Title:
  Bind mount to NFS mount fails on Ubuntu 22.04

Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Jammy:
  Fix Committed
Status in systemd source package in Kinetic:
  Fix Released

Bug description:
  [Impact]
  Some NFS setups that have worked on previous versions of Ubuntu are now 
broken. Specifically, when creating a bind mount, systemd will fail if the 
directory already exists on NFS.

  [Test Plan]
  This test plan requires an NFS server to be in place. The exact setup is not 
important, but for the purposes of this test plan we will assume the server 
exports /data, which contains a directory called home.

  * Make sure nfs-common is installed:

   $ apt install nfs-common -y

  * Check the NFS server exports using showmount:

   $ showmount -e $NFS_SERVER_IP
   Export list for $NFS_SERVER_IP:
   /data *

  * Add the appropriate entries to /etc/fstab. In this example, we will
  make /home2 a bind mount to /data/home:

   # /etc/fstab
   $NFS_SERVER_IP:/data /data nfs defaults,nfsvers=3 0 0
   /data/home /home2 none bind,_netdev,x-systemd.requires-mounts-for=/data 0 0

  * Check systemctl status home2.mount. On an affected system, we should
  see a permission denied error:

   $ systemctl status home2.mount
   x home2.mount - /home2
Loaded: loaded (/etc/fstab; generated)
Active: failed (Result: resources)
 Where: /home2
  What: /data/home
  Docs: man:fstab(5)
man:systemd-fstab-generator(8)

   systemd[1]: home2.mount: Failed to make bind mount source '/data/home': 
Permission denied
   systemd[1]: home2.mount: Failed to run 'mount' task: Permission denied
   systemd[1]: home2.mount: Failed with result 'resources'.
   systemd[1]: Failed to mount /home2.

  * On a patched system, we expect /home2 to be mounted successfully.

  [Where problems could occur]
  The patch makes it so that systemd will not fail bind mounts immediately if 
creating the directory fails. Thus, any regressions would be seen during bind 
mounts with systemd. N.B. that this patch restores previous behavior in systemd.

  [Original Description]
  I have the following setup:
  - /data is an NFS mount.
  - /home is a bind mount to /data/home.

  Configured in /etc/fstab with these lines:

  $FILE_SERVER:/data /data nfs defaults 0 0
  /data/home /home none bind,_netdev,x-systemd.requires-mounts-for=/data 0 0

  This has worked with the same configuration for me on at least Ubuntu 18.04 
and Ubuntu 20.04, but on Ubuntu 22.04 the mount of /home fails when attempted 
by systemd.
  So not only is /home not mounted after boot, but also when I run "sudo 
systemctl start home.mount", it fails.

  The journal entries are this:

  sudo[1316]:  wendler : TTY=pts/0 ; PWD=/home/wendler ; USER=root ; 
COMMAND=/usr/bin/systemctl start home.mount
  sudo[1316]: pam_unix(sudo:session): session opened for user root(uid=0) by 
wendler(uid=1000)
  systemd[1]: home.mount: Directory /home to mount over is not empty, mounting 
anyway.
  systemd[1]: home.mount: Failed to make bind mount source '/data/home': 
Permission denied
  systemd[1]: home.mount: Failed to run 'mount' task: Permission denied
  systemd[1]: home.mount: Failed with result 'resources'.
  systemd[1]: Failed to mount /home.

  However, when I run "sudo mount /home" it works.

  Now the weird thing is that after I have mounted /home manually once
  and unmounted it again, then "sudo system

[Touch-packages] [Bug 1981042] Re: /etc/localtime symlink not correctly handled when using /etc/writable

[Łukasz Zemczak]

This does introduce some code duplication, but I guess that's fine.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1981042

Title:
  /etc/localtime symlink not correctly handled when using /etc/writable

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Jammy:
  Fix Committed
Status in systemd source package in Kinetic:
  Fix Released

Bug description:
  [Impact]
  When using /etc/writable (e.g. Ubuntu Core) /etc/localtime is a symlink to 
/etc/writable/localtime (which in itself if a symlink). Systemd doesn't handle 
this correctly when doing firstboot or using inotify to watch for changes to 
localtime.

  [Test Plan]
  This is somewhat hard to test, the following situations need to be reproduced:
  - On firstboot the timezone link will not be read correctly, it will with 
this change.
  - Starting a timer unit and then changing timezone will cause it not to occur 
at the correct time.

  [Where problems could occur]
  This could potentially break other users of localtime, however the change is 
similar to existing changes which have been in Ubuntu's version of systemd for 
some time. The change detects the /etc/writable case and if not should have the 
same existing behaviour.

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


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

[Touch-packages] [Bug 1981622] Re: mtd device must be supplied (device name is empty)

[Łukasz Zemczak]

Hello pelm, or anyone else affected,

Accepted systemd into jammy-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/systemd/249.11-0ubuntu3.5 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
jammy to verification-done-jammy. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-jammy. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: systemd (Ubuntu Jammy)
   Status: Triaged => Fix Committed

** Tags added: verification-needed verification-needed-jammy

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1981622

Title:
  mtd device must be supplied (device name is empty)

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Triaged
Status in systemd source package in Jammy:
  Fix Committed

Bug description:
  [WORKAROUND]

  This will NOT fix a system that is not booting, because the "mtd
  device must be supplied (device name is empty)" message is not the
  cause of failed boots. This work around is only for those who are
  annoyed by the error message, but are otherwise not experiencing any
  issues.

  If you are not able to boot your system, but you see this error
  message, please open a separate bug with your journalctl and dmesg
  logs.

  # cp /{lib,etc}/systemd/system/systemd-pstore.service
  # sed -i 's/modprobe@mtdpstore.service //' 
/etc/systemd/system/systemd-pstore.service
  # systemctl daemon-reload

  [Impact]

  Due to mtdpstore not being properly configured as a pstore backend,
  when systemd-pstore.service tries to load the module, users get the
  following error in dmesg:

  [   18.453473] systemd[1]: Starting Load Kernel Module mtdpstore...
  [   18.462685] mtd device must be supplied (device name is empty)

  This is a distracting error for users trying to diagnose other system
  issues, especially if their system does not boot after a kernel crash
  and this is the only message displayed on the console.

  [Test Plan]

  * Force a kernel crash to populate /sys/fs/pstore, thus causing
  systemd-pstore.service to start on the subsequent boot:

  # echo 1 > /proc/sys/kernel/sysrq
  # echo 1 > /proc/sys/kernel/panic
  # echo c > /proc/sysrq-trigger

  * When the system reboots, observe the error in dmesg:

  # dmesg | grep mtd

  [Where problems could occur]

  If a system was relying on this pstore backend, and mtdpstore is built
  as a module, it is possible for systemd-pstore.service to trigger
  before mtdpstore is loaded, causing systemd-pstore to not copy the
  contents of /sys/fs/pstore. Note however that before the patched
  introduced as a result of bug 1978079, systemd-pstore.service would
  not attempt to load *any* kernel modules.

  [Original Description]

  After updating my 22.04 system (possibly caused by Systemd update).
  And now booting, dmesg has two errors:

  'mtd device must be supplied (device name is empty)'.

  See line 8 and 134 in the included logfile.

  The system are booting as it should though, and the system are working
  like it should no errors at all.

  Is this maybe caused by 'efi-pstore-not-cleared-on-boot.patch' in
  systemd?

  I have an EFI mounted at boot but it isn't used because I have
  installed my system in legacy BIOS mode.

  Is this maybe the culprit?

  I could ignore the message but it isn't nice though.

  Regards

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


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

[Touch-packages] [Bug 1982462] Re: Some modprobe loading services requested by the pstore service fail

[Łukasz Zemczak]

Hello Alfonso, or anyone else affected,

Accepted systemd into jammy-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/systemd/249.11-0ubuntu3.5 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
jammy to verification-done-jammy. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-jammy. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: systemd (Ubuntu Jammy)
   Status: Triaged => Fix Committed

** Tags added: verification-needed verification-needed-jammy

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1982462

Title:
  Some modprobe loading services requested by the pstore service fail

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Focal:
  Confirmed
Status in systemd source package in Jammy:
  Fix Committed
Status in systemd source package in Kinetic:
  Fix Released

Bug description:
  [Impact]

  It has been detected that some modprobe services fail on UC22 after
  the jammy upgrade  249.11-0ubuntu3.4:

  $ systemctl --system --no-ask-password --no-pager list-units --state=failed
  Failed units:
UNIT LOAD   ACTIVE SUBDESCRIPTION
  ● modprobe@chromeos_pstore.service loaded failed failed Load Kernel Module 
chromeos_pstore
  ● modprobe@efi_pstore.service  loaded failed failed Load Kernel Module 
efi_pstore
  ● modprobe@mtdpstore.service   loaded failed failed Load Kernel Module 
mtdpstore
  ● modprobe@pstore_blk.service  loaded failed failed Load Kernel Module 
pstore_blk
  ● modprobe@pstore_zone.service loaded failed failed Load Kernel Module 
pstore_zone
  ● modprobe@ramoops.service loaded failed failed Load Kernel Module 
ramoops

  This happens because of some changes to systemd-pstore.service that
  now has:

  After=modprobe@efi_pstore.service modprobe@mtdpstore.service 
modprobe@chromeos_pstore.service modprobe@ramoops.service 
modprobe@pstore_zone.service modprobe@pstore_blk.service
  Wants=modprobe@efi_pstore.service modprobe@mtdpstore.service 
modprobe@chromeos_pstore.service modprobe@ramoops.service 
modprobe@pstore_zone.service modprobe@pstore_blk.service

  This causes too many tries of the modprobe services, that fail in the
  end with

  Jul 20 09:02:39 ubuntu systemd[1]: modprobe@chromeos_pstore.service:
  Start request repeated too quickly.

  Although we have seen this only on UC22, it potentially can affect
  classic systems as well, as systemd-pstore.service is re-tried there a
  few times too. See https://github.com/snapcore/core-base/issues/72 for
  more details.

  A fix for this is available upstream:
  
https://github.com/systemd/systemd/commit/9625350e5381a68c1179ae4581e7586c206663e1

  [Test Plan]

  Start the device and check that there is no modprobe-pstore related
  failed service. This is racy, so a few tries will be needed to make
  sure things are fine.

  [Where problems could occur]

  The modprobe services are usually dependencies from other services, so
  it should be fine if the retry behavior is controlled by those other
  services. Risk should be small. If something goes wrong we might see a
  lot of restarts for these services.

  [Other Info]

  Testing should happen on UC22 too.

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


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

[Touch-packages] [Bug 1988078] Re: Please backport systemd-hwdb patches to support src:systemd-hwe tests

[Łukasz Zemczak]

This would need systemd-hwe to be promoted to main in jammy as well. Let
me actually do that now.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1988078

Title:
  Please backport systemd-hwdb patches to support src:systemd-hwe tests

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Jammy:
  Fix Committed

Bug description:
  [Impact]

  We plan to SRU src:systemd-hwe to Jammy[1] to provide an easier way to
  SRU HWE hwdb rules to Ubuntu. The src:systemd-hwe package contains a
  test script[2] to ensure that no redundant hwdb rules are added to the
  package, i.e. rules that are already present in src:systemd. This test
  requires patches to implement --root flag support for the `systemd-
  hwdb query` command[3]. These patches are already present in kinetic.

  Without these patches in Jammy, src:systemd-hwe would have to disable
  these tests, which are important to maintaining HWE hwdb rules in
  Ubuntu.

  [1] https://bugs.launchpad.net/ubuntu/+source/systemd-hwe/+bug/1983996
  [2] 
https://git.launchpad.net/~canonical-foundations/+git/systemd-hwe/tree/tests/hwdb-redundancy?h=main
  [3] https://github.com/systemd/systemd/pull/23518

  [Test plan]

  * Create a new directory for testing hwdb rule queries:

  $ mkdir -p fakeroot/etc/udev/hdwb.d

  * Add a new .hwdb file to override an existing rule. For example, I
  chose to override the last entry from
  /lib/udev/hdwb.d/60-keyboard.hwdb:

  $ tail -2 /lib/udev/hwdb.d/60-keyboard.hwdb > 
fakeroot/etc/udev/hwdb.d/60-keyboard.hwdb
  $ sed -i 's/chromebook/reserved/g' fakeroot/etc/udev/hwdb.d/60-keyboard.hwdb 
  $ cat fakeroot/etc/udev/hwdb.d/60-keyboard.hwdb 
  evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer*:pnPeppy:*
   XKB_FIXED_MODEL=reserved

  * Create the hwdb.bin within fakeroot:

  $ systemd-hwdb update --root fakeroot
  $ ls fakeroot/etc/udev/hwdb.bin 
  fakeroot/etc/udev/hwdb.bin

  * Finally, attempt to query this new hwdb.bin using systemd-hwdb
  query. On an unpatched system, we will see results from the system's
  hwdb.bin:

  $ systemd-hwdb query --root fakeroot 
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer*:pnPeppy:* | grep XKB_FIXED_MODEL
  XKB_FIXED_MODEL=chromebook

  ...and on a patched system we should see the overridden rule:

  $ systemd-hwdb query --root fakeroot 
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer*:pnPeppy:* | grep XKB_FIXED_MODEL
  XKB_FIXED_MODEL=reserved 

  [Where problems could occur]
  The patches add support for the --root flag when calling systemd-hwdb query, 
thus changing the behavior of this command (previously, query would always load 
the system's hwdb.bin). It is unlikely that existing scripts try to use the 
--root flag with `systemd-hwdb query`, but if they did, this is where we would 
see problems.

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


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

[Touch-packages] [Bug 1988078] Re: Please backport systemd-hwdb patches to support src:systemd-hwe tests

[Łukasz Zemczak]

Hello Nick, or anyone else affected,

Accepted systemd into jammy-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/systemd/249.11-0ubuntu3.5 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
jammy to verification-done-jammy. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-jammy. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: systemd (Ubuntu Jammy)
   Status: New => Fix Committed

** Tags added: verification-needed verification-needed-jammy

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1988078

Title:
  Please backport systemd-hwdb patches to support src:systemd-hwe tests

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Jammy:
  Fix Committed

Bug description:
  [Impact]

  We plan to SRU src:systemd-hwe to Jammy[1] to provide an easier way to
  SRU HWE hwdb rules to Ubuntu. The src:systemd-hwe package contains a
  test script[2] to ensure that no redundant hwdb rules are added to the
  package, i.e. rules that are already present in src:systemd. This test
  requires patches to implement --root flag support for the `systemd-
  hwdb query` command[3]. These patches are already present in kinetic.

  Without these patches in Jammy, src:systemd-hwe would have to disable
  these tests, which are important to maintaining HWE hwdb rules in
  Ubuntu.

  [1] https://bugs.launchpad.net/ubuntu/+source/systemd-hwe/+bug/1983996
  [2] 
https://git.launchpad.net/~canonical-foundations/+git/systemd-hwe/tree/tests/hwdb-redundancy?h=main
  [3] https://github.com/systemd/systemd/pull/23518

  [Test plan]

  * Create a new directory for testing hwdb rule queries:

  $ mkdir -p fakeroot/etc/udev/hdwb.d

  * Add a new .hwdb file to override an existing rule. For example, I
  chose to override the last entry from
  /lib/udev/hdwb.d/60-keyboard.hwdb:

  $ tail -2 /lib/udev/hwdb.d/60-keyboard.hwdb > 
fakeroot/etc/udev/hwdb.d/60-keyboard.hwdb
  $ sed -i 's/chromebook/reserved/g' fakeroot/etc/udev/hwdb.d/60-keyboard.hwdb 
  $ cat fakeroot/etc/udev/hwdb.d/60-keyboard.hwdb 
  evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer*:pnPeppy:*
   XKB_FIXED_MODEL=reserved

  * Create the hwdb.bin within fakeroot:

  $ systemd-hwdb update --root fakeroot
  $ ls fakeroot/etc/udev/hwdb.bin 
  fakeroot/etc/udev/hwdb.bin

  * Finally, attempt to query this new hwdb.bin using systemd-hwdb
  query. On an unpatched system, we will see results from the system's
  hwdb.bin:

  $ systemd-hwdb query --root fakeroot 
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer*:pnPeppy:* | grep XKB_FIXED_MODEL
  XKB_FIXED_MODEL=chromebook

  ...and on a patched system we should see the overridden rule:

  $ systemd-hwdb query --root fakeroot 
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnAcer*:pnPeppy:* | grep XKB_FIXED_MODEL
  XKB_FIXED_MODEL=reserved 

  [Where problems could occur]
  The patches add support for the --root flag when calling systemd-hwdb query, 
thus changing the behavior of this command (previously, query would always load 
the system's hwdb.bin). It is unlikely that existing scripts try to use the 
--root flag with `systemd-hwdb query`, but if they did, this is where we would 
see problems.

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


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

[Touch-packages] [Bug 1802483] Re: Notifications emitted by a snap with local files or desktop files use wrong namespace

[Launchpad Bug Tracker]

This bug was fixed in the package libnotify - 0.7.7-3ubuntu0.18.04.1

---
libnotify (0.7.7-3ubuntu0.18.04.1) bionic; urgency=medium

  * debian: Update references as per ubuntu/bionic branching
  * debian/patches: Handle file paths, uris and desktop-ID's in Snapped apps
(LP: #1802483)

 -- Marco Trevisan (Treviño)   Wed, 27 Apr 2022
23:38:42 +0200

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libnotify in Ubuntu.
https://bugs.launchpad.net/bugs/1802483

Title:
  Notifications emitted by a snap with local files or desktop files use
  wrong namespace

Status in libnotify package in Ubuntu:
  Fix Released
Status in libnotify source package in Bionic:
  Fix Released
Status in libnotify source package in Focal:
  Fix Released
Status in libnotify source package in Jammy:
  Fix Released

Bug description:
  As can be tested using this example snap:
   - https://github.com/3v1n0/notify-send-test-snap

  Basically the icons are referenced using absolute paths in snap
  environment, while they should be readapted so that they depend on
  $SNAP location.

  As we do with appindicators and libunity emblems.

  

  [ Impact ]

  Icons sonuds and desktop files referenced by a snapped app using
  notifications aren't exposed to the desktop in absolute paths

  [ Test case ]

  Build the test snap (or install it from the attached files to this bug):
    git clone https://github.com/3v1n0/notify-send-test-snap
    snapcraft prime
    snap try prime

  To use the pre-built snap 
(https://bugs.launchpad.net/ubuntu/+source/libnotify/+bug/1802483/comments/7)
    snap install --dangerous notify-send-test-snap_*.snap

  Check that icons are shown when launching:
    notify-send-test-snap
    notify-send-test-snap.image-path
notify-send-test-snap.image-uri

  Ensure that desktop entry is correctly sent, monitoring the dbus
  session:

   In a terminal:
     dbus-monitor --session --monitor 
"interface='org.freedesktop.Notifications'"

   In the other:
     notify-send-test-snap.desktop-entry
     notify-send-test-snap.desktop-entry-explicit-id
     notify-send-test-snap.desktop-entry-explicit-file-name
     notify-send-test-snap.desktop-entry-explicit-path
     notify-send-test-snap.desktop-entry-explicit-uri
     notify-send-test-snap.desktop-entry-explicit-snapped-uri

  The
   `desktop-entry` value sent to dbus should be either:
     - A `notify-send-test-snap_`-prefixed desktop ID
     - A .desktop file path (readable from both inside and outside the snap)
     - A .desktop file uri (readable from both inside and outside the snap)

  [ Regression potential ]

  Normal applications that are run with a SNAP environment variable set,
  might use wrong paths for files or desktop file

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


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

[Touch-packages] [Bug 1802483] Re: Notifications emitted by a snap with local files or desktop files use wrong namespace

[Launchpad Bug Tracker]

This bug was fixed in the package libnotify - 0.7.9-1ubuntu3.20.04.2

---
libnotify (0.7.9-1ubuntu3.20.04.2) focal; urgency=medium

  * debian: Update references as per ubuntu/focal branching
  * debian/patches: Exit with an error if showing notification fails
(LP: #1970647)
  * debian/patches: Handle file paths, uris and desktop-ID's in Snapped apps
(LP: #1802483)

 -- Marco Trevisan (Treviño)   Wed, 27 Apr 2022
23:42:13 +0200

** Changed in: libnotify (Ubuntu Focal)
   Status: Fix Committed => Fix Released

** Changed in: libnotify (Ubuntu Bionic)
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libnotify in Ubuntu.
https://bugs.launchpad.net/bugs/1802483

Title:
  Notifications emitted by a snap with local files or desktop files use
  wrong namespace

Status in libnotify package in Ubuntu:
  Fix Released
Status in libnotify source package in Bionic:
  Fix Released
Status in libnotify source package in Focal:
  Fix Released
Status in libnotify source package in Jammy:
  Fix Released

Bug description:
  As can be tested using this example snap:
   - https://github.com/3v1n0/notify-send-test-snap

  Basically the icons are referenced using absolute paths in snap
  environment, while they should be readapted so that they depend on
  $SNAP location.

  As we do with appindicators and libunity emblems.

  

  [ Impact ]

  Icons sonuds and desktop files referenced by a snapped app using
  notifications aren't exposed to the desktop in absolute paths

  [ Test case ]

  Build the test snap (or install it from the attached files to this bug):
    git clone https://github.com/3v1n0/notify-send-test-snap
    snapcraft prime
    snap try prime

  To use the pre-built snap 
(https://bugs.launchpad.net/ubuntu/+source/libnotify/+bug/1802483/comments/7)
    snap install --dangerous notify-send-test-snap_*.snap

  Check that icons are shown when launching:
    notify-send-test-snap
    notify-send-test-snap.image-path
notify-send-test-snap.image-uri

  Ensure that desktop entry is correctly sent, monitoring the dbus
  session:

   In a terminal:
     dbus-monitor --session --monitor 
"interface='org.freedesktop.Notifications'"

   In the other:
     notify-send-test-snap.desktop-entry
     notify-send-test-snap.desktop-entry-explicit-id
     notify-send-test-snap.desktop-entry-explicit-file-name
     notify-send-test-snap.desktop-entry-explicit-path
     notify-send-test-snap.desktop-entry-explicit-uri
     notify-send-test-snap.desktop-entry-explicit-snapped-uri

  The
   `desktop-entry` value sent to dbus should be either:
     - A `notify-send-test-snap_`-prefixed desktop ID
     - A .desktop file path (readable from both inside and outside the snap)
     - A .desktop file uri (readable from both inside and outside the snap)

  [ Regression potential ]

  Normal applications that are run with a SNAP environment variable set,
  might use wrong paths for files or desktop file

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


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

[Touch-packages] [Bug 1970647] Re: notify-send exit code doesn't match result

[Launchpad Bug Tracker]

This bug was fixed in the package libnotify - 0.7.9-1ubuntu3.20.04.2

---
libnotify (0.7.9-1ubuntu3.20.04.2) focal; urgency=medium

  * debian: Update references as per ubuntu/focal branching
  * debian/patches: Exit with an error if showing notification fails
(LP: #1970647)
  * debian/patches: Handle file paths, uris and desktop-ID's in Snapped apps
(LP: #1802483)

 -- Marco Trevisan (Treviño)   Wed, 27 Apr 2022
23:42:13 +0200

** Changed in: libnotify (Ubuntu Focal)
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libnotify in Ubuntu.
https://bugs.launchpad.net/bugs/1970647

Title:
  notify-send exit code doesn't match result

Status in libnotify package in Ubuntu:
  Fix Released
Status in libnotify source package in Focal:
  Fix Released
Status in libnotify source package in Jammy:
  Fix Released

Bug description:
  No error exit code is returned by notify-send on failure

  [ Test case ]

  1. Run:
     env DBUS_SESSION_BUS_ADDRESS= notify-send foo bar || echo error
  2. In a terminal "error" should be printed

  [ Regression potential ]

  Programs relying on notify-send may have errors when they did not.

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


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

[Touch-packages] [Bug 1969976] Re: DynamicUser=1 doesn't get along with services that need dbus-daemon

[Chris Halse Rogers]

Hello Mario, or anyone else affected,

Accepted fwupd into jammy-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/fwupd/1.8.3-1~22.04.1
in a few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
jammy to verification-done-jammy. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-jammy. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: fwupd (Ubuntu Jammy)
   Status: Confirmed => Fix Committed

** Tags added: verification-needed verification-needed-jammy

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1969976

Title:
  DynamicUser=1 doesn't get along with services that need dbus-daemon

Status in Fwupd:
  Fix Released
Status in systemd:
  New
Status in fwupd package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Won't Fix
Status in fwupd source package in Focal:
  Confirmed
Status in systemd source package in Focal:
  Won't Fix
Status in fwupd source package in Impish:
  Won't Fix
Status in systemd source package in Impish:
  Won't Fix
Status in fwupd source package in Jammy:
  Fix Committed
Status in systemd source package in Jammy:
  Won't Fix

Bug description:
  Updating to systemd 245.4-4ubuntu3.16 has caused a regression in
  Ubuntu 20.04, that fwupd-refresh.service always fails to run.

  This has been root caused down to the changes in
  https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1871538

  Unfortunately this is an upstream issue introduced by stable systemd.
  https://github.com/systemd/systemd/issues/22737

  The problem also occurs in Ubuntu 22.04 with a newer systemd release.
  As discussed in 
https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1871538/comments/61
 it's a tradeoff of issues.  So within Ubuntu something probably needs to be 
done about fwupd-refresh.service.

  One proposal is to remove DynamicUser=yes from the systemd unit, but
  this will mean fwupdgmr refresh runs as root.  It's relatively
  sandboxed by other security mechanisms, but still not ideal.  Could we
  repurpose any other service account?  Or alternatively we can make a
  new fwupd service account that this systemd unit uses.

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


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

[Touch-packages] [Bug 1988563] Re: package libudev-dev dependency conflict

[Julian Andres Klode]

Reverting the systemd SRU broke existing images.

** Package changed: apt (Ubuntu) => systemd (Ubuntu)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1988563

Title:
  package libudev-dev dependency conflict

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  I am not sure if this is the right place to file this, but we are
  getting the following error when installing libudev-dev on bionic

  Installing libudev-dev fails for bionic with the following error:

  ```
  Some packages could not be installed. This may mean that you have
  requested an impossible situation or if you are using the unstable
  distribution that some required packages have not yet been created
  or been moved out of Incoming.
  The following information may help to resolve the situation:

  The following packages have unmet dependencies:
   libudev-dev : Depends: libudev1 (= 237-3ubuntu10.53) but 237-3ubuntu10.54 is 
to be installed
  E: Unable to correct problems, you have held broken packages.
  ```

  Steps to reproduce:

  ```
  docker run -it --rm ubuntu:bionic
  apt update
  apt install libudev-dev
  ```

  Complete log:
  ```
  ~$ docker run -it --rm ubuntu:bionic
  Unable to find image 'ubuntu:bionic' locally
  bionic: Pulling from library/ubuntu
  dad0f37c70a6: Pull complete 
  Digest: 
sha256:3aa2ccb021969aadb28381fee1b247422e845b176e241cd1540c4b6831e000bb
  Status: Downloaded newer image for ubuntu:bionic
  root@391196612b51:/# apt update
  Get:1 http://security.ubuntu.com/ubuntu bionic-security InRelease [88.7 kB]
  Get:2 http://archive.ubuntu.com/ubuntu bionic InRelease [242 kB]  
 
  Get:3 http://security.ubuntu.com/ubuntu bionic-security/restricted amd64 
Packages [1114 kB]
  Get:4 http://security.ubuntu.com/ubuntu bionic-security/multiverse amd64 
Packages [22.8 kB]
  Get:5 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages 
[2953 kB]
  Get:6 http://security.ubuntu.com/ubuntu bionic-security/universe amd64 
Packages [1540 kB]
  Get:7 http://archive.ubuntu.com/ubuntu bionic-updates InRelease [88.7 kB] 
 
  Get:8 http://archive.ubuntu.com/ubuntu bionic-backports InRelease [74.6 kB]
  Get:9 http://archive.ubuntu.com/ubuntu bionic/multiverse amd64 Packages [186 
kB]
  Get:10 http://archive.ubuntu.com/ubuntu bionic/restricted amd64 Packages 
[13.5 kB]
  Get:11 http://archive.ubuntu.com/ubuntu bionic/universe amd64 Packages [11.3 
MB]
  Get:12 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages [1344 kB]
  Get:13 http://archive.ubuntu.com/ubuntu bionic-updates/multiverse amd64 
Packages [29.9 kB]
  Get:14 http://archive.ubuntu.com/ubuntu bionic-updates/restricted amd64 
Packages [1162 kB]
  Get:15 http://archive.ubuntu.com/ubuntu bionic-updates/universe amd64 
Packages [2318 kB]
  Get:16 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages 
[3390 kB]
  Get:17 http://archive.ubuntu.com/ubuntu bionic-backports/universe amd64 
Packages [12.9 kB]
  Get:18 http://archive.ubuntu.com/ubuntu bionic-backports/main amd64 Packages 
[12.2 kB]
  Fetched 25.9 MB in 2s (10.4 MB/s) 
  Reading package lists... Done
  Building dependency tree   
  Reading state information... Done
  All packages are up to date.
  root@391196612b51:/# apt install libudev-dev
  Reading package lists... Done
  Building dependency tree   
  Reading state information... Done
  Some packages could not be installed. This may mean that you have
  requested an impossible situation or if you are using the unstable
  distribution that some required packages have not yet been created
  or been moved out of Incoming.
  The following information may help to resolve the situation:

  The following packages have unmet dependencies:
   libudev-dev : Depends: libudev1 (= 237-3ubuntu10.53) but 237-3ubuntu10.54 is 
to be installed
  E: Unable to correct problems, you have held broken packages.
  ```

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


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

[Touch-packages] [Bug 1988300] Re: systemd-resolved is not installable in Docker images

[Cristovao Cordeiro]

I can no longer reproduce the issue after the systemd fix (both on Jammy
and Kinetic).

** Changed in: ubuntu-docker-images
 Assignee: (unassigned) => Cristovao Cordeiro (cjdc)

** Changed in: ubuntu-docker-images
   Status: Invalid => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1988300

Title:
  systemd-resolved is not installable in Docker images

Status in Ubuntu Docker Images:
  Fix Released
Status in dpkg package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Fix Released

Bug description:
  Since 30 August (going by my daily CI builds, I do see the changelog
  entry for resolved is a few days older), I get this:

  Selecting previously unselected package systemd-resolved.
  Preparing to unpack .../321-systemd-resolved_251.4-1ubuntu1_amd64.deb ...
  Unpacking systemd-resolved (251.4-1ubuntu1) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-NS2Yvi/321-systemd-resolved_251.4-1ubuntu1_amd64.deb 
(--unpack):
   unable to make backup link of './etc/resolv.conf' before installing new 
version: Invalid cross-device link

  The reason this fails is that Docker mounts resolv.conf, readonly,
  from the host system, so dpkg is not allowed to move/replace it.

  (To be clear, I do not need systemd-resolved in my container. "apt
  install devscripts" pulled it in, and debtree does not tell me why.
  "apt install --no-install-recommends devscripts" does not pull it in,
  and I'll likely adjust my builds [for PowerDNS] to do that because
  it's a good idea anyway).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-docker-images/+bug/1988300/+subscriptions


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