date:20231002

Dropped severity because this bug is proving elusive. Most of us are
never seeing it, even when we try with similar hardware.

** Changed in: mesa (Ubuntu)
   Importance: Critical => High

** Changed in: mutter (Ubuntu)
   Importance: Critical => High

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

Title:
  gnome-shell crashed with SIGSEGV at NULL from end_query() from
  cogl_gl_create_timestamp_query() from
  cogl_onscreen_egl_swap_buffers_with_damage()

Status in Mesa:
  New
Status in Mutter:
  Fix Released
Status in mesa package in Ubuntu:
  Confirmed
Status in mutter package in Ubuntu:
  Confirmed
Status in mesa package in Fedora:
  Confirmed

Bug description:
  crash after update
  wayland session is not accessible anymore

  ProblemType: Crash
  DistroRelease: Ubuntu 23.10
  Package: gnome-shell 45.0-1ubuntu1
  ProcVersionSignature: Ubuntu 6.5.0-5.5-generic 6.5.0
  Uname: Linux 6.5.0-5-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.27.0-0ubuntu2
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Sep 27 05:52:26 2023
  DisplayManager: gdm3
  ExecutablePath: /usr/bin/gnome-shell
  InstallationDate: Installed on 2023-09-26 (0 days ago)
  InstallationMedia: Ubuntu 23.10 "Mantic Minotaur" - Beta amd64 (20230924)
  ProcCmdline: /usr/bin/gnome-shell
  ProcEnviron:
   LANG=fr_FR.UTF-8
   PATH=(custom, no user)
   SHELL=/bin/bash
   XDG_RUNTIME_DIR=
  RelatedPackageVersions: mutter-common 45.0-2ubuntu1
  Signal: 11
  SourcePackage: gnome-shell
  StacktraceTop:
   ?? ()
   ?? () from /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
   ?? () from /usr/lib/x86_64-linux-gnu/mutter-13/libmutter-cogl-13.so.0
   ?? () from /usr/lib/x86_64-linux-gnu/mutter-13/libmutter-cogl-13.so.0
   ?? () from /lib/x86_64-linux-gnu/libmutter-13.so.0
  Title: gnome-shell crashed with SIGSEGV
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip libvirt lpadmin plugdev sudo users
  separator:

To manage notifications about this bug go to:
https://bugs.launchpad.net/mesa/+bug/2037497/+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 2037569] Re: udev issues with mantic beta

This bug was fixed in the package udisks2 - 2.10.1-1ubuntu1

---
udisks2 (2.10.1-1ubuntu1) mantic; urgency=medium

  * Fix an event loop that can occur when ID_PART_TABLE_TYPE is not set for a
device and that device has partitions.  (LP: #2037569)

 -- Dan Bungert   Mon, 02 Oct 2023
11:26:55 -0600

** Changed in: udisks2 (Ubuntu)
   Status: Fix Committed => 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/2037569

Title:
  udev issues with mantic beta

Status in Ubuntu on IBM z Systems:
  Confirmed
Status in libblockdev package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Invalid
Status in udisks2 package in Ubuntu:
  Fix Released

Bug description:
  While installing mantic beta (on s390x, LPAR and z/VM - but this might not be 
architecture specific) I faced issues with udev.
  In my installation I've updated the installer to "edge/lp-2009141" (subiquity 
 22.02.2+git1762.1b1ee6f4  5164).

  During my installations I first noticed bad response times in case of
  dealing with devices (like enabling new devices with chzdev). chzdev
  is used during the installation, hence the installation procedure is
  also affected by this. (I mainly notice this issue in case of DASD
  ECKD disk enablements.)

  But even after after a successful (but due to this issue less snappier) 
installation, means after the post-install reboot, in the installed system I 
can find several udev related processes, like:
69448 root  20   0   31280  11944   2560 S  39.2   0.0   2:51.67 
(udev-worker)
  509 root  20   0   31276  13812   4600 S  20.6   0.0   2:07.76 
systemd-udevd
  893 root  20   0  469016  13544  10496 R  17.3   0.0   1:43.53 
udisksd  
1 root  20   0  168664  12748   8396 S  16.3   0.0   1:40.47 
systemd  
  which is not only unusual, but (as one can see) they consume quite some 
resources.
  Even the remote ssh into that system is impacted by this high load.

  So far I only see this in mantic.
  I tried 20.04.3 as well as lunar, but both do not seem to be affected by this 
udev problem.
  I neither face the bad response on device enablement, nor can see any udev 
related processes still running after post-install-reboot in the installed 
system.

  (Sometimes I could also see a growing log file 'syslog').

  I cannot say yet what is causing this, but since I see 'systemd-udevd'
  as prominent process in top, I'll first of all mark this as affecting
  systemd-udevd (or systemd).

  I've attached the outcome of some more investigations I did ...

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2037569/+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 1957024] Re: pam-mkhomedir does not honor private home directories

2023-10-02 Thread Ubuntu Foundations Team Bug Bot

The attachment "private_homedir.patch" 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 pam in Ubuntu.
https://bugs.launchpad.net/bugs/1957024

Title:
  pam-mkhomedir does not honor private home directories

Status in pam package in Ubuntu:
  New

Bug description:
  As reported in https://discourse.ubuntu.com/t/private-home-
  directories-for-ubuntu-21-04-onwards/19533/13:

  A common situation is to have a central set of users (e.g. in LDAP)
  and use pam_mkhomedir.so to create the home directory when the user
  first logs in.

  These changes do not cover this situation. The default configuration
  of pam_mkhomedir.so will result in a home directory created with 0755
  permissions.

  To make pam_mkhomedir.so create a home directory by default with
  permissions consistent with the other tools then a umask argument can
  be added to the pam_mkhomedir.so module in the file /usr/share/pam-
  configs/mkhomedir. I believe this would have to be done before
  enabling the module. The file is part of the libpam-modules package.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pam/+bug/1957024/+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 1957024] Re: pam-mkhomedir does not honor private home directories

2023-10-02 Thread Andrew Lowther

I created a patch that changes the behavior of the default mkhomedir
configuration to follow the "private home directories" proposal.  The
permissions on home directories created by pam_mkhomedir.so will be
consistent with the permissions on home directories created by `adduser`
and `useradd`.

** Patch added: "private_homedir.patch"
   
https://bugs.launchpad.net/ubuntu/+source/pam/+bug/1957024/+attachment/5705955/+files/private_homedir.patch

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

Title:
  pam-mkhomedir does not honor private home directories

Status in pam package in Ubuntu:
  New

Bug description:
  As reported in https://discourse.ubuntu.com/t/private-home-
  directories-for-ubuntu-21-04-onwards/19533/13:

  A common situation is to have a central set of users (e.g. in LDAP)
  and use pam_mkhomedir.so to create the home directory when the user
  first logs in.

  These changes do not cover this situation. The default configuration
  of pam_mkhomedir.so will result in a home directory created with 0755
  permissions.

  To make pam_mkhomedir.so create a home directory by default with
  permissions consistent with the other tools then a umask argument can
  be added to the pam_mkhomedir.so module in the file /usr/share/pam-
  configs/mkhomedir. I believe this would have to be done before
  enabling the module. The file is part of the libpam-modules package.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pam/+bug/1957024/+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 2038095] Re: gnome save dialog -> no reaction to thumb buttons of mouse

2023-10-02 Thread Paul White

** Package changed: ubuntu => gtk+3.0 (Ubuntu)

** Tags added: jammy

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

Title:
  gnome save dialog -> no reaction to thumb buttons of mouse

Status in gtk+3.0 package in Ubuntu:
  New

Bug description:
  Bug related to: #1891739

  While "saving" documents in programs like LO, firefox, gedit,
  filezilla, ... the thumb mouse-buttons don't react to browse in the
  menu structure as usual e.g. in a filebrowser like nautilus or in
  using firefox going back from the current page.

  I'd expect to go back and forth in the "file-browser of the saving-
  dialog" with the thumb buttons (4. and 5. button) of my mouse:

  cherry DW5100

  
  ~$ inxi -Fxxxz
  System:
Kernel: 6.2.0-33-generic x86_64 bits: 64 compiler: N/A Desktop: GNOME 42.9
  tk: GTK 3.24.33 wm: gnome-shell dm: GDM3 42.0
  Distro: Ubuntu 22.04.3 LTS (Jammy Jellyfish)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/2038095/+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 2038095] [NEW] gnome save dialog -> no reaction to thumb buttons of mouse

You have been subscribed to a public bug:

Bug related to: #1891739

While "saving" documents in programs like LO, firefox, gedit, filezilla,
... the thumb mouse-buttons don't react to browse in the menu structure
as usual e.g. in a filebrowser like nautilus or in using firefox going
back from the current page.

I'd expect to go back and forth in the "file-browser of the saving-
dialog" with the thumb buttons (4. and 5. button) of my mouse:

cherry DW5100


~$ inxi -Fxxxz
System:
  Kernel: 6.2.0-33-generic x86_64 bits: 64 compiler: N/A Desktop: GNOME 42.9
tk: GTK 3.24.33 wm: gnome-shell dm: GDM3 42.0
Distro: Ubuntu 22.04.3 LTS (Jammy Jellyfish)

** Affects: gtk+3.0 (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: bot-comment
-- 
gnome save dialog -> no reaction to thumb buttons of mouse
https://bugs.launchpad.net/bugs/2038095
You received this bug notification because you are a member of Ubuntu Touch 
seeded packages, which is subscribed to gtk+3.0 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 2037202] Re: Mantic/23.10: PXE boot tries to initialize DHCP before network link is up

2023-10-02 Thread Michael Hudson-Doyle

https://code.launchpad.net/~mwhudson/ubuntu/+source/initramfs-
tools/+git/initramfs-tools/+merge/452586 might be a fix? Not tested at
all.

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

Title:
  Mantic/23.10: PXE boot tries to initialize DHCP before network link is
  up

Status in initramfs-tools package in Ubuntu:
  New

Bug description:
  I'm not sure whether this is the correct package for this bug, please
  reassign if not.

  I'm booting the Ubuntu Mantic/23.10 desktop beta image via PXE in
  order to perform an unattended installation. The kernel command line
  looks like that:

  iso/casper/vmlinuz --- ip=dhcp netboot=nfs
  nfsroot=192.168.1.1:/export/ubuntu autoinstall ds=nocloud\;s=

  This has worked perfectly before. However, in 23.10, the kernel tries
  to intialize DHCP before a network link is up.

  I can see a few instances of messages like the following:
  dhcpcd-10.0.2 starting
  dev: loaded udev
  no interfaces have a carrier
  exiting due to oneshot
  dhcpcd exited

  Then, the kernel tries to mount NFS, even though neither an IP address nor 
even a link is available:
  connect: Network is unreachable
  NFS over TCP not available from 192.168.1.1

  This is repeated for a while. In between, a message tells that now the link 
is up:
  [10.0002805] e1000e :00:19.0 enp0s25: NIC Link is Up 1000 Mbps Full 
Duplex, Flow Control: Rx/Tx

  The NFS messages repeat for a while, until the system gives up and I'm
  dropped into a busybox prompt.

  Executing dhcpcd now correctly gets IP addresses, but I don't know how
  to continue the boot from there.

  The problem occurs on most physical machines that I tried, but not in
  VMs.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2037202/+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 2037569] Re: udev issues with mantic beta

2023-10-02 Thread Ubuntu Foundations Team Bug Bot

** Tags added: patch

-- 
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/2037569

Title:
  udev issues with mantic beta

Status in Ubuntu on IBM z Systems:
  Confirmed
Status in libblockdev package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Invalid
Status in udisks2 package in Ubuntu:
  Fix Committed

Bug description:
  While installing mantic beta (on s390x, LPAR and z/VM - but this might not be 
architecture specific) I faced issues with udev.
  In my installation I've updated the installer to "edge/lp-2009141" (subiquity 
 22.02.2+git1762.1b1ee6f4  5164).

  During my installations I first noticed bad response times in case of
  dealing with devices (like enabling new devices with chzdev). chzdev
  is used during the installation, hence the installation procedure is
  also affected by this. (I mainly notice this issue in case of DASD
  ECKD disk enablements.)

  But even after after a successful (but due to this issue less snappier) 
installation, means after the post-install reboot, in the installed system I 
can find several udev related processes, like:
69448 root  20   0   31280  11944   2560 S  39.2   0.0   2:51.67 
(udev-worker)
  509 root  20   0   31276  13812   4600 S  20.6   0.0   2:07.76 
systemd-udevd
  893 root  20   0  469016  13544  10496 R  17.3   0.0   1:43.53 
udisksd  
1 root  20   0  168664  12748   8396 S  16.3   0.0   1:40.47 
systemd  
  which is not only unusual, but (as one can see) they consume quite some 
resources.
  Even the remote ssh into that system is impacted by this high load.

  So far I only see this in mantic.
  I tried 20.04.3 as well as lunar, but both do not seem to be affected by this 
udev problem.
  I neither face the bad response on device enablement, nor can see any udev 
related processes still running after post-install-reboot in the installed 
system.

  (Sometimes I could also see a growing log file 'syslog').

  I cannot say yet what is causing this, but since I see 'systemd-udevd'
  as prominent process in top, I'll first of all mark this as affecting
  systemd-udevd (or systemd).

  I've attached the outcome of some more investigations I did ...

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2037569/+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 2037202] Re: Mantic/23.10: PXE boot tries to initialize DHCP before network link is up

2023-10-02 Thread Michael Hudson-Doyle

Is the point here that dhcpcd -1 exits immediately if it finds no
devices, even if it has a -t argument?

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

Title:
  Mantic/23.10: PXE boot tries to initialize DHCP before network link is
  up

Status in initramfs-tools package in Ubuntu:
  New

Bug description:
  I'm not sure whether this is the correct package for this bug, please
  reassign if not.

  I'm booting the Ubuntu Mantic/23.10 desktop beta image via PXE in
  order to perform an unattended installation. The kernel command line
  looks like that:

  iso/casper/vmlinuz --- ip=dhcp netboot=nfs
  nfsroot=192.168.1.1:/export/ubuntu autoinstall ds=nocloud\;s=

  This has worked perfectly before. However, in 23.10, the kernel tries
  to intialize DHCP before a network link is up.

  I can see a few instances of messages like the following:
  dhcpcd-10.0.2 starting
  dev: loaded udev
  no interfaces have a carrier
  exiting due to oneshot
  dhcpcd exited

  Then, the kernel tries to mount NFS, even though neither an IP address nor 
even a link is available:
  connect: Network is unreachable
  NFS over TCP not available from 192.168.1.1

  This is repeated for a while. In between, a message tells that now the link 
is up:
  [10.0002805] e1000e :00:19.0 enp0s25: NIC Link is Up 1000 Mbps Full 
Duplex, Flow Control: Rx/Tx

  The NFS messages repeat for a while, until the system gives up and I'm
  dropped into a busybox prompt.

  Executing dhcpcd now correctly gets IP addresses, but I don't know how
  to continue the boot from there.

  The problem occurs on most physical machines that I tried, but not in
  VMs.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2037202/+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 2037569] Re: udev issues with mantic beta

2023-10-02 Thread Dan Bungert

Seb reviewed and +1ed on IRC.  Uploaded.

** Changed in: udisks2 (Ubuntu)
 Assignee: (unassigned) => Dan Bungert (dbungert)

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

-- 
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/2037569

Title:
  udev issues with mantic beta

Status in Ubuntu on IBM z Systems:
  Confirmed
Status in libblockdev package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Invalid
Status in udisks2 package in Ubuntu:
  Fix Committed

Bug description:
  While installing mantic beta (on s390x, LPAR and z/VM - but this might not be 
architecture specific) I faced issues with udev.
  In my installation I've updated the installer to "edge/lp-2009141" (subiquity 
 22.02.2+git1762.1b1ee6f4  5164).

  During my installations I first noticed bad response times in case of
  dealing with devices (like enabling new devices with chzdev). chzdev
  is used during the installation, hence the installation procedure is
  also affected by this. (I mainly notice this issue in case of DASD
  ECKD disk enablements.)

  But even after after a successful (but due to this issue less snappier) 
installation, means after the post-install reboot, in the installed system I 
can find several udev related processes, like:
69448 root  20   0   31280  11944   2560 S  39.2   0.0   2:51.67 
(udev-worker)
  509 root  20   0   31276  13812   4600 S  20.6   0.0   2:07.76 
systemd-udevd
  893 root  20   0  469016  13544  10496 R  17.3   0.0   1:43.53 
udisksd  
1 root  20   0  168664  12748   8396 S  16.3   0.0   1:40.47 
systemd  
  which is not only unusual, but (as one can see) they consume quite some 
resources.
  Even the remote ssh into that system is impacted by this high load.

  So far I only see this in mantic.
  I tried 20.04.3 as well as lunar, but both do not seem to be affected by this 
udev problem.
  I neither face the bad response on device enablement, nor can see any udev 
related processes still running after post-install-reboot in the installed 
system.

  (Sometimes I could also see a growing log file 'syslog').

  I cannot say yet what is causing this, but since I see 'systemd-udevd'
  as prominent process in top, I'll first of all mark this as affecting
  systemd-udevd (or systemd).

  I've attached the outcome of some more investigations I did ...

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2037569/+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 2032386] Re: Aug 21 17:08:54 jak-t14-g3 kernel: amdgpu 0000:04:00.0: amdgpu: [gfxhub] page fault (src_id:0 ring:40 vmid:1 pasid:32782, for process firefox pid 1163281 thread fire

2023-10-02 Thread Bug Watch Updater

** Changed in: mesa
   Status: New => Fix Released

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

Title:
  Aug 21 17:08:54 jak-t14-g3 kernel: amdgpu :04:00.0: amdgpu:
  [gfxhub] page fault (src_id:0 ring:40 vmid:1 pasid:32782, for process
  firefox pid 1163281 thread firefox:cs0 pid 1163466) Aug 21 17:08:54
  jak-t14-g3 kernel: amdgpu :04:00.0: amdgpu:   in page starting at
  address 0x800111ec from client 0x1b (UTCL2) Aug 21 17:08:54
  jak-t14-g3 kernel: amdgpu :04:00.0: amdgpu:
  GCVM_L2_PROTECTION_FAULT_STATUS:0x Aug 21 17:08:54 jak-t14-g3
  kernel: amdgpu :04:00.0: amdgpu:  Faulty UTCL2 client ID:
  CB/DB (0x0) Aug 21 17:08:54 jak-t14-g3 kernel: amdgpu :04:00.0:
  amdgpu:  MORE_FAULTS: 0x0 Aug 21 17:08:54 jak-t14-g3 kernel:
  amdgpu :04:00.0: amdgpu:  WALKER_ERROR: 0x0 Aug 21
  17:08:54 jak-t14-g3 kernel: amdgpu :04:00.0: amdgpu:
  PERMISSION_FAULTS: 0x0 Aug 21 17:08:54 jak-t14-g3 kernel: amdgpu
  :04:00.0: amdgpu:  MAPPING_ERROR: 0x0 Aug 21 17:08:54
  jak-t14-g3 kernel: amdgpu :04:00.0: amdgpu:  RW: 0x0 Aug
  21 17:09:04 jak-t14-g3 kernel: [drm:amdgpu_job_timedout [amdgpu]]
  *ERROR* ring gfx_0.0.0 timeout, but soft recovered

Status in Mesa:
  Fix Released
Status in linux package in Ubuntu:
  Confirmed
Status in mesa package in Ubuntu:
  New

Bug description:
  I'm sorry I don't have more information than the dmesg output but
  firefox (snap) just hang; bug could be either mesa or kernel (I mean
  generally I'd say that if userspace can DoS the GPU that's also a
  kernel bug regardless but YMMV)

  ProblemType: Bug
  DistroRelease: Ubuntu 23.10
  Package: linux-image-6.3.0-7-generic 6.3.0-7.7+1
  ProcVersionSignature: Ubuntu 6.3.0-7.7-generic 6.3.5
  Uname: Linux 6.3.0-7-generic x86_64
  ApportVersion: 2.27.0-0ubuntu2
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: GNOME
  Date: Mon Aug 21 17:09:36 2023
  InstallationDate: Installed on 2022-11-26 (268 days ago)
  InstallationMedia: Ubuntu 23.04 "Lunar Lobster" - Alpha amd64 (20221126)
  MachineType: {report['dmi.sys.vendor']} {report['dmi.product.name']}
  ProcFB: 0 amdgpudrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-6.3.0-7-generic 
root=/dev/mapper/ubuntu-root ro rootflags=subvol=@ quiet splash vt.handoff=7
  PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No 
PulseAudio daemon running, or not running as session daemon.
  RelatedPackageVersions:
   linux-restricted-modules-6.3.0-7-generic N/A
   linux-backports-modules-6.3.0-7-generic  N/A
   linux-firmware   20230815.git0e048b06-0ubuntu1
  SourcePackage: linux
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 03/21/2023
  dmi.bios.release: 1.35
  dmi.bios.vendor: LENOVO
  dmi.bios.version: R23ET65W (1.35 )
  dmi.board.asset.tag: Not Available
  dmi.board.name: 21CF004PGE
  dmi.board.vendor: LENOVO
  dmi.board.version: SDK0T76538 WIN
  dmi.chassis.asset.tag: No Asset Information
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: None
  dmi.ec.firmware.release: 1.28
  dmi.modalias: 
dmi:bvnLENOVO:bvrR23ET65W(1.35):bd03/21/2023:br1.35:efr1.28:svnLENOVO:pn21CF004PGE:pvrThinkPadT14Gen3:rvnLENOVO:rn21CF004PGE:rvrSDK0T76538WIN:cvnLENOVO:ct10:cvrNone:skuLENOVO_MT_21CF_BU_Think_FM_ThinkPadT14Gen3:
  dmi.product.family: ThinkPad T14 Gen 3
  dmi.product.name: 21CF004PGE
  dmi.product.sku: LENOVO_MT_21CF_BU_Think_FM_ThinkPad T14 Gen 3
  dmi.product.version: ThinkPad T14 Gen 3
  dmi.sys.vendor: LENOVO

To manage notifications about this bug go to:
https://bugs.launchpad.net/mesa/+bug/2032386/+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 2036128] Re: [FFe] enable unprivileged user namespace restrictions by default for mantic

2023-10-02 Thread Steve Langasek

I am very concerned about landing such a change a week before release
because of the risk of regression and the short runway to identify those
regressions and deal with them before release.

From the discourse post:

> To identify applications within the Ubuntu archive that require
> the use of unprivileged user namespaces, a combination of static
> analysis and dynamic testing should be used.

Where has this been done, where can we see the list / count of programs
that had to have apparmor profiles added in order to account for this?

The spec acknowledged that static analysis was insufficient to identify
all the packages in Ubuntu that would regress if this feature landed
without corresponding apparmor profile updates.  So, what dynamic
testing has been done, and why is the Security Team confident that this
covers us for 23.10?

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

Title:
  [FFe] enable unprivileged user namespace restrictions by default for
  mantic

Status in apparmor package in Ubuntu:
  New

Bug description:
  As per https://discourse.ubuntu.com/t/spec-unprivileged-user-
  namespace-restrictions-via-apparmor-in-ubuntu-23-10/37626,
  unprivileged user namespace restrictions for Ubuntu 23.10 are to be
  enabled by default via a sysctl.d conf file in apparmor.

  In https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2035315 new
  apparmor profiles were added to the apparmor package for various
  applications which require unprivileged user namespaces, using a new
  unconfined profile mode. To support this an additional change was
  added to the mantic kernel in https://git.launchpad.net/~ubuntu-
  kernel/ubuntu/+source/linux/+git/mantic/commit?h=master-
  next=7327726a2dbf571e05f7c095916dcce0347790b4 which is still
  currently unreleased.

  Without this kernel change, if userns restrictions are enabled the
  existing policies added above will not actually work to allow them to
  be used by the various applications. As such we need to ensure that
  userns restrictions are not enabled via sysctl when this feature is
  not present / enabled.

  Whilst it may be possible to capture the dependency logic via
  `Breaks:` or similar, this would not help in the case that a user
  booted into an older kernel with the new apparmor userspace package.

  As such, as well as enabling the sysctl via the sysctl.d conf file, it
  is proposed to add logic into the apparmor.service systemd unit to
  check that the kernel supports the aforementioned unconfined profile
  mode and that it is enabled - and if not then to force disable the
  userns restrictions sysctl via the following logic:

  userns_restricted=$(sysctl -n kernel.apparmor_restrict_unprivileged_userns)
  unconfined_userns=$([ -f 
/sys/kernel/security/apparmor/features/policy/unconfined_restrictions/userns ] 
&& cat 
/sys/kernel/security/apparmor/features/policy/unconfined_restrictions/userns || 
echo 0)
  if [ -n "$userns_restricted" ] && [ "$userns_restricted" -eq 1 ]; then
    if [ "$unconfined_userns" -eq 0 ]; then
  # userns restrictions rely on unconfined userns to be supported
  echo "disabling unprivileged userns restrictions since unconfined userns 
is not supported / enabled"
  sysctl -w kernel.apparmor_restrict_unprivileged_userns=0
    fi
  fi

  this allows a local admin to disable the sysctl via the regular
  sysctl.d conf approach, but to also make sure we don't inadvertently
  enable it when it is not supported by the kernel.

  This proposed change has been tested via the QA Regression Testing
  project, in particular with the specific test added in
  https://git.launchpad.net/qa-regression-
  testing/commit/?id=6f2c5ab7c8659174adac772ce0e894328bb5045d

  This produces the following output, confirming the fallback works as
  expected on the current mantic kernel (which does not fully support
  the userns restrictions):

  
---

  Running test: './test-apparmor.py' distro: 'Ubuntu 23.10' kernel: '6.5.0-5.5 
(Ubuntu 6.5.0-5.5-generic 6.5.0)' arch: 'amd64' init: 'systemd' uid: 0/0 
SUDO_USER: 'ubuntu')
  test_unconfined_userns (__main__.ApparmorTest.test_unconfined_userns)
  Test that unconfined userns restrictions are applied ... Skipping private 
tests

  WARN: kernel rate limiting in effect
  Disabling ratelimiting until the next reboot. To renable, run:
  # sysctl -w kernel.printk_ratelimit=5

  (enabling userns restrictions) (restarting apparmor) (checking userns
  restrictions got disabled) ok

  --
  Ran 1 test in 0.232s

  OK

  
---

  
  Also we can see on a fresh-boot with this new version installed that 
apparmor.service shows it has disabled the sysctl

[Touch-packages] [Bug 2037569] Re: udev issues with mantic beta

2023-10-02 Thread Dan Bungert

Proposed changes to avoid the event storm

** Patch added: "udisks2-1_2.10.1-1_2.10.1-1ubuntu1.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/udisks2/+bug/2037569/+attachment/5705929/+files/udisks2-1_2.10.1-1_2.10.1-1ubuntu1.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/2037569

Title:
  udev issues with mantic beta

Status in Ubuntu on IBM z Systems:
  Confirmed
Status in libblockdev package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Invalid
Status in udisks2 package in Ubuntu:
  Confirmed

Bug description:
  While installing mantic beta (on s390x, LPAR and z/VM - but this might not be 
architecture specific) I faced issues with udev.
  In my installation I've updated the installer to "edge/lp-2009141" (subiquity 
 22.02.2+git1762.1b1ee6f4  5164).

  During my installations I first noticed bad response times in case of
  dealing with devices (like enabling new devices with chzdev). chzdev
  is used during the installation, hence the installation procedure is
  also affected by this. (I mainly notice this issue in case of DASD
  ECKD disk enablements.)

  But even after after a successful (but due to this issue less snappier) 
installation, means after the post-install reboot, in the installed system I 
can find several udev related processes, like:
69448 root  20   0   31280  11944   2560 S  39.2   0.0   2:51.67 
(udev-worker)
  509 root  20   0   31276  13812   4600 S  20.6   0.0   2:07.76 
systemd-udevd
  893 root  20   0  469016  13544  10496 R  17.3   0.0   1:43.53 
udisksd  
1 root  20   0  168664  12748   8396 S  16.3   0.0   1:40.47 
systemd  
  which is not only unusual, but (as one can see) they consume quite some 
resources.
  Even the remote ssh into that system is impacted by this high load.

  So far I only see this in mantic.
  I tried 20.04.3 as well as lunar, but both do not seem to be affected by this 
udev problem.
  I neither face the bad response on device enablement, nor can see any udev 
related processes still running after post-install-reboot in the installed 
system.

  (Sometimes I could also see a growing log file 'syslog').

  I cannot say yet what is causing this, but since I see 'systemd-udevd'
  as prominent process in top, I'll first of all mark this as affecting
  systemd-udevd (or systemd).

  I've attached the outcome of some more investigations I did ...

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2037569/+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 2037672] Re: amdgpu: [gfxhub] page fault when switching a video to or from fullscreen

2023-10-02 Thread Johon Doee

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

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

Title:
  amdgpu: [gfxhub] page fault when switching a video to or from
  fullscreen

Status in linux package in Ubuntu:
  Confirmed
Status in mesa package in Ubuntu:
  Confirmed

Bug description:
  Hi,

  Switching a video to or from fullscreen freezes the screen for around
  10 seconds. This happens with Totem as well as VLC so its not related
  to a specific app.

  Additional observations:

  - The issue seems to be connected to the video's bitrate. With low
  bitrate videos I cannot trigger the freeze. However, videos with high
  bandwidth trigger the freeze reliably.

  Specs:
  Ubuntu 23.10 up to date as of 28.09.2023
  AMD Ryzen 7 PRO 6850U
  Kernel 6.5.0-5-generic
  Grub configured with: amdgpu.vm_update_mode=3

  Syslog shows:

  2023-09-28T20:02:29.803955+02:00 kernel: [27003.800898] amdgpu
  :04:00.0: amdgpu: [gfxhub] page fault (src_id:0 ring:24 vmid:2
  pasid:32771, for process Xwayland pid 2113 thread Xwayland:cs0 pid
  2311)

  2023-09-28T20:02:39.975854+02:00 kernel: [27013.972772]
  [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx_0.0.0 timeout, but
  soft recovered

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2037672/+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 2037569] Re: udev issues with mantic beta

2023-10-02 Thread Dan Bungert

proposal 4. set ID_PART_TABLE_TYPE in the appropriate spot

-- 
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/2037569

Title:
  udev issues with mantic beta

Status in Ubuntu on IBM z Systems:
  Confirmed
Status in libblockdev package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Invalid
Status in udisks2 package in Ubuntu:
  Confirmed

Bug description:
  While installing mantic beta (on s390x, LPAR and z/VM - but this might not be 
architecture specific) I faced issues with udev.
  In my installation I've updated the installer to "edge/lp-2009141" (subiquity 
 22.02.2+git1762.1b1ee6f4  5164).

  During my installations I first noticed bad response times in case of
  dealing with devices (like enabling new devices with chzdev). chzdev
  is used during the installation, hence the installation procedure is
  also affected by this. (I mainly notice this issue in case of DASD
  ECKD disk enablements.)

  But even after after a successful (but due to this issue less snappier) 
installation, means after the post-install reboot, in the installed system I 
can find several udev related processes, like:
69448 root  20   0   31280  11944   2560 S  39.2   0.0   2:51.67 
(udev-worker)
  509 root  20   0   31276  13812   4600 S  20.6   0.0   2:07.76 
systemd-udevd
  893 root  20   0  469016  13544  10496 R  17.3   0.0   1:43.53 
udisksd  
1 root  20   0  168664  12748   8396 S  16.3   0.0   1:40.47 
systemd  
  which is not only unusual, but (as one can see) they consume quite some 
resources.
  Even the remote ssh into that system is impacted by this high load.

  So far I only see this in mantic.
  I tried 20.04.3 as well as lunar, but both do not seem to be affected by this 
udev problem.
  I neither face the bad response on device enablement, nor can see any udev 
related processes still running after post-install-reboot in the installed 
system.

  (Sometimes I could also see a growing log file 'syslog').

  I cannot say yet what is causing this, but since I see 'systemd-udevd'
  as prominent process in top, I'll first of all mark this as affecting
  systemd-udevd (or systemd).

  I've attached the outcome of some more investigations I did ...

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2037569/+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 2037202] Re: Mantic/23.10: PXE boot tries to initialize DHCP before network link is up

Thanks for the precision Marian.

Dimitri, do you know if the "sleep 1" works in practice?

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

Title:
  Mantic/23.10: PXE boot tries to initialize DHCP before network link is
  up

Status in initramfs-tools package in Ubuntu:
  New

Bug description:
  I'm not sure whether this is the correct package for this bug, please
  reassign if not.

  I'm booting the Ubuntu Mantic/23.10 desktop beta image via PXE in
  order to perform an unattended installation. The kernel command line
  looks like that:

  iso/casper/vmlinuz --- ip=dhcp netboot=nfs
  nfsroot=192.168.1.1:/export/ubuntu autoinstall ds=nocloud\;s=

  This has worked perfectly before. However, in 23.10, the kernel tries
  to intialize DHCP before a network link is up.

  I can see a few instances of messages like the following:
  dhcpcd-10.0.2 starting
  dev: loaded udev
  no interfaces have a carrier
  exiting due to oneshot
  dhcpcd exited

  Then, the kernel tries to mount NFS, even though neither an IP address nor 
even a link is available:
  connect: Network is unreachable
  NFS over TCP not available from 192.168.1.1

  This is repeated for a while. In between, a message tells that now the link 
is up:
  [10.0002805] e1000e :00:19.0 enp0s25: NIC Link is Up 1000 Mbps Full 
Duplex, Flow Control: Rx/Tx

  The NFS messages repeat for a while, until the system gives up and I'm
  dropped into a busybox prompt.

  Executing dhcpcd now correctly gets IP addresses, but I don't know how
  to continue the boot from there.

  The problem occurs on most physical machines that I tried, but not in
  VMs.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2037202/+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 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"

** Description changed:

=== SRU information ===
[Meta]
This bug is part of a series of four bugs for a single SRU.
This ( #2033422 ) is the "central" bug with the global information and
debdiff.

This SRU addresses four issues with Jammy's openssl version:
- http://pad.lv/1990216: Blowfish OFB/CFB decryption
- http://pad.lv/1994165: ignored SMIME signature errors
- http://pad.lv/2023545: imbca engine dumps core
- http://pad.lv/2033422: very high CPU usage for concurrent TLS connections

The SRU information has been added to the four bug reports and I am
attaching the debdiff here only for all four.

All the patches have been included in subsequent openssl 3.0.x releases
which in turn have been included in subsequent Ubuntu releases. There
has been no report of issues when updating to these Ubuntu releases.

I have rebuilt the openssl versions and used abi-compliance-checker to
compare the ABIs of the libraries in jammy and the one for the SRU. Both
matched completely (FYI, mantic's matched completely too).

The patch related to blowfish presents an annoying situation: jammy's openssl
creates incompatible files and cannot read other files but fixing it will lead
to files created on jammy so far to become unreadable. Fortunately, blowfish is
long-deprecated and applications can be improved to handle this situation if
the need arises in practice.
This is stated in the SRU information in the bug and in d/changelog.
The current situation in Jammy could be a security issue but due to the
aforementioned deprecation, the low usage of blowfish and the fact that
upstream didn't consider this worthy of a security notice, we (this includes
the security team) chose not to pursue that path either.

I have also pushed the code to git (without any attempt to make it git-
ubuntu friendly).

https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy-
sru
+
+ I asked Brian Murray about phasing speed and he concurs a slow roll-out is
probably better for openssl. There is a small uncertainty because a security
update could come before the phasing is over, effectively fast-forwarding the
SRU. Still, unless there is already a current pre-advisory, this is probably
better than a 10% phasing which is over after only a couple days anyway.
+ NB: at the moment openssl doesn't phase slowly so this needs to be
implemented.

[Impact]
Severely degraded performance for concurrent operations compared to openssl
1.1. The performance is so degraded that some workloads fail due to timeouts or
insufficient resources (noone magically has 5 times more machines). As a
consequence, a number of people use openssl 1.1 instead and do not get security
updates.

[Test plan]
Rafael Lopez has shared a simple benchmarks in http://pad.lv/2009544 with
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py
.
Using this, I get the following numbers on my laptop:

3.0.2:
real 2m5.567s
user 4m3.948s
sys 2m0.233s

this SRU:
real 0m23.966s
user 2m35.687s
sys 0m1.920s

As can be easily seen, the speed-up is massive: system time is divided
by 60 and overall wall clock time is roughly five times lower.

In http://pad.lv/2009544 , Rafael also shared his performance numbers
and they are relatable to these. He used slightly different versions
(upstreams rather than patched with cherry-picks) but at least one of
the version used does not include other performance change. He also used
different hardware and this performance issue seems to depend on the
number of CPUs available but also obtained a performance several times
better. Results on a given machine vary also very little across runs
(less than 2% variation on runs of size 10). They are also very similar
on a Raspberry Pi 4 (8GB).

The benchmark uses https://www.google.com/humans.txt which takes around
130ms to download on my machine but I modified the script to download
something only 20ms away. Results are so close to the ones using
humans.txt that they are within the error margin. This is consistent
with the high-concurrency in the benchmark which both saturates CPU, and
"hides" latencies that are relatively low.

Finally, there are positive reports on github. Unfortunately they are
not always completely targeted at these patches only and therefore I
will not link directly to them but they have also been encouraging.

[Where problems could occur]
The change is spread over several patches which touch the internals of
openssl. As such, the engine and provider functionality could be broken by
these changes. Fortunately, in addition to upstream's code review, these
patches are included in openssl 3.0.4 (iirc) and therefore in kinetic. No issue
related to these changes was reported on launchpad or upstream.

However, it is possible that

[Touch-packages] [Bug 2036968] Re: Mantic minimized/minimal cloud images do not receive IP address during provisioning; systemd regression with wait-online

2023-10-02 Thread Nick Rosbrook

** Tags removed: rls-mm-incoming
** Tags added: foundations-todo

** Tags added: rls-mm-incoming

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

** Changed in: systemd (Ubuntu)
   Importance: Undecided => High

** Changed in: systemd (Ubuntu)
 Assignee: (unassigned) => Nick Rosbrook (enr0n)

-- 
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/2036968

Title:
  Mantic minimized/minimal cloud images do not receive IP address during
  provisioning; systemd regression with wait-online

Status in cloud-images:
  New
Status in linux package in Ubuntu:
  Fix Committed
Status in systemd package in Ubuntu:
  Triaged

Bug description:
  Following a recent change from linux-kvm kernel to linux-generic
  kernel in the mantic minimized images, there is a reproducable bug
  where a guest VM does not have an IP address assigned as part of
  cloud-init provisioning.

  This is easiest to reproduce when emulating arm64 on amd64 host. The
  bug is a race condition, so there could exist fast enough
  virtualisation on fast enough hardware where this bug is not present
  but in all my testing I have been able to reproduce.

  The latest mantic minimized images from http://cloud-
  images.ubuntu.com/minimal/daily/mantic/ have force initrdless boot and
  no initrd to fallback to.

  This but is not present in the non minimized/base images @
  http://cloud-images.ubuntu.com/mantic/ as these boot with initrd with
  the required drivers present for virtio-net.

  Reproducer

  ```
  wget -O "launch-qcow2-image-qemu-arm64.sh" 
https://people.canonical.com/~philroche/20230921-cloud-images-mantic-fail-to-provision/launch-qcow2-image-qemu-arm64.sh

  chmod +x ./launch-qcow2-image-qemu-arm64.sh
  wget 
https://people.canonical.com/~philroche/20230921-cloud-images-mantic-fail-to-provision/livecd.ubuntu-cpc.img
  ./launch-qcow2-image-qemu-arm64.sh --password passw0rd --image 
./livecd.ubuntu-cpc.img
  ```

  You will then be able to log in with user `ubuntu` and password
  `passw0rd`.

  You can run `ip a` and see that there is a network interface present
  (separate to `lo`) but no IP address has been assigned.

  ```
  ubuntu@cloudimg:~$ ip a
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
     valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
     valid_lft forever preferred_lft forever
  2: enp0s1:  mtu 1500 qdisc noop state DOWN group default 
qlen 1000
  link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff

  ```

  This is because when cloud-init is trying to configure network
  interfaces it doesn't find any so it doesn't configure any. But by the
  time boot is complete the network interface is present but cloud-init
  provisioning has already completed.

  You can verify this by running `sudo cloud-init clean && sudo cloud-
  init init`

  You can then see a successfully configured network interface

  ```
  ubuntu@cloudimg:~$ ip a
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
     valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
     valid_lft forever preferred_lft forever
  2: enp0s1:  mtu 1500 qdisc pfifo_fast state 
UP group default qlen 1000
  link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
  inet 10.0.2.15/24 metric 100 brd 10.0.2.255 scope global dynamic enp0s1
     valid_lft 86391sec preferred_lft 86391sec
  inet6 fec0::5054:ff:fe12:3456/64 scope site dynamic mngtmpaddr 
noprefixroute
     valid_lft 86393sec preferred_lft 14393sec
  inet6 fe80::5054:ff:fe12:3456/64 scope link
     valid_lft forever preferred_lft forever

  ```

  The bug is also reproducible with amd64 guest on adm64 host on
  older/slower hardware.

  The suggested fixes while debugging this issue are:

  * to include `virtio-net` as a built-in in the mantic generic kernel
  * understand what needs to change in cloud-init so that it can react to late 
additions of network interfaces

  I will file a separate bug against cloud-init to address the race
  condition on emulated guest/older hardware.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/2036968/+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 2034986] Re: some text became unreadable during a distribution upgrade

This bug was fixed in the package ubuntu-release-upgrader - 1:23.10.7

---
ubuntu-release-upgrader (1:23.10.7) mantic; urgency=medium

  * DistUpgradeQuirks: Use generic font temporarily at upgrade
(LP: #2034986)
  * DistUpgradeQuirks: Switch snap channels instead of refresh
(LP: #2036765)
  * DistUpgradeController: Ensure security archive is used for security pocket
(LP: #2036679)
  * Run pre-build.sh: updating mirrors and demotions.

 -- Nick Rosbrook   Fri, 29 Sep 2023 14:44:34 -0400

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

Title:
  some text became unreadable during a distribution upgrade

Status in ubuntu-meta package in Ubuntu:
  Fix Released
Status in ubuntu-release-upgrader package in Ubuntu:
  Fix Released
Status in ubuntu-meta source package in Mantic:
  Fix Released
Status in ubuntu-release-upgrader source package in Mantic:
  Fix Released

Bug description:
  I was upgrading from Lunar to Mantic the other day and left a couple
  of applications open during the upgrade process. During the upgrade
  the text in audacious became unreadable (I'll attach a screenshot) and
  I seem to recall the title bar of Firefox being unreadable but the
  contents of web pages still being readable.

  ProblemType: Bug
  DistroRelease: Ubuntu 23.10
  Package: ubuntu-release-upgrader-core 1:23.10.5
  ProcVersionSignature: Ubuntu 6.5.0-4.4-generic 6.5.0
  Uname: Linux 6.5.0-4-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia zfs
  ApportVersion: 2.27.0-0ubuntu2
  Architecture: amd64
  CasperMD5CheckResult: unknown
  CrashDB: ubuntu
  CurrentDesktop: ubuntu:GNOME
  Date: Fri Sep  8 15:39:27 2023
  InstallationDate: Installed on 2018-08-10 (1855 days ago)
  InstallationMedia: Ubuntu-Server 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  PackageArchitecture: all
  SourcePackage: ubuntu-release-upgrader
  Symptom: ubuntu-release-upgrader
  UpgradeStatus: Upgraded to mantic on 2023-09-06 (2 days ago)
  VarLogDistupgradeAptclonesystemstate.tar.gz: Error: command ['pkexec', 'cat', 
'/var/log/dist-upgrade/apt-clone_system_state.tar.gz'] failed with exit code 
126: Error executing command as another user: Request dismissed
  VarLogDistupgradeTermlog:
   
  mtime.conffile..etc.update-manager.meta-release: 2021-05-27T16:30:16.970490

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/2034986/+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 2034986] Re: some text became unreadable during a distribution upgrade

This bug was fixed in the package ubuntu-meta - 1.523

---
ubuntu-meta (1.523) mantic; urgency=medium

  * Refreshed dependencies
  * Added fonts-dejavu-core to desktop, desktop-minimal, desktop-raspi
(LP: #2034986)
  * Removed fonts-dejavu-mono from desktop-minimal-recommends,
desktop-raspi-recommends, desktop-recommends

 -- Gunnar Hjalmarsson   Fri, 29 Sep 2023 12:53:17
+0200

** Changed in: ubuntu-meta (Ubuntu Mantic)
   Status: In Progress => Fix Released

** Changed in: ubuntu-release-upgrader (Ubuntu Mantic)
   Status: Fix Committed => Fix Released

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

Title:
  some text became unreadable during a distribution upgrade

Status in ubuntu-meta package in Ubuntu:
  Fix Released
Status in ubuntu-release-upgrader package in Ubuntu:
  Fix Released
Status in ubuntu-meta source package in Mantic:
  Fix Released
Status in ubuntu-release-upgrader source package in Mantic:
  Fix Released

Bug description:
  I was upgrading from Lunar to Mantic the other day and left a couple
  of applications open during the upgrade process. During the upgrade
  the text in audacious became unreadable (I'll attach a screenshot) and
  I seem to recall the title bar of Firefox being unreadable but the
  contents of web pages still being readable.

  ProblemType: Bug
  DistroRelease: Ubuntu 23.10
  Package: ubuntu-release-upgrader-core 1:23.10.5
  ProcVersionSignature: Ubuntu 6.5.0-4.4-generic 6.5.0
  Uname: Linux 6.5.0-4-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia zfs
  ApportVersion: 2.27.0-0ubuntu2
  Architecture: amd64
  CasperMD5CheckResult: unknown
  CrashDB: ubuntu
  CurrentDesktop: ubuntu:GNOME
  Date: Fri Sep  8 15:39:27 2023
  InstallationDate: Installed on 2018-08-10 (1855 days ago)
  InstallationMedia: Ubuntu-Server 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  PackageArchitecture: all
  SourcePackage: ubuntu-release-upgrader
  Symptom: ubuntu-release-upgrader
  UpgradeStatus: Upgraded to mantic on 2023-09-06 (2 days ago)
  VarLogDistupgradeAptclonesystemstate.tar.gz: Error: command ['pkexec', 'cat', 
'/var/log/dist-upgrade/apt-clone_system_state.tar.gz'] failed with exit code 
126: Error executing command as another user: Request dismissed
  VarLogDistupgradeTermlog:
   
  mtime.conffile..etc.update-manager.meta-release: 2021-05-27T16:30:16.970490

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/2034986/+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 2036968] Re: Mantic minimized/minimal cloud images do not receive IP address during provisioning

2023-10-02 Thread Dimitri John Ledkov

analysis at https://github.com/canonical/cloud-init/issues/4451
identified systemd regression that is affecting mantic
the kernel workaround is here for virtio-net, but not for all other NIC types, 
i.e. e1000
and will likely affect other users too, not just cloud-init use case.

Request to consider fixing https://github.com/canonical/cloud-
init/issues/4451#issuecomment-1733881643 in systemd in Mantic for GA, or
0-day sru.

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

** Tags added: rls-mm-incoming

** Summary changed:

- Mantic minimized/minimal cloud images do not receive IP address during 
provisioning
+ Mantic minimized/minimal cloud images do not receive IP address during 
provisioning; systemd regression with wait-online

-- 
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/2036968

Title:
  Mantic minimized/minimal cloud images do not receive IP address during
  provisioning; systemd regression with wait-online

Status in cloud-images:
  New
Status in linux package in Ubuntu:
  Fix Committed
Status in systemd package in Ubuntu:
  New

Bug description:
  Following a recent change from linux-kvm kernel to linux-generic
  kernel in the mantic minimized images, there is a reproducable bug
  where a guest VM does not have an IP address assigned as part of
  cloud-init provisioning.

  This is easiest to reproduce when emulating arm64 on amd64 host. The
  bug is a race condition, so there could exist fast enough
  virtualisation on fast enough hardware where this bug is not present
  but in all my testing I have been able to reproduce.

  The latest mantic minimized images from http://cloud-
  images.ubuntu.com/minimal/daily/mantic/ have force initrdless boot and
  no initrd to fallback to.

  This but is not present in the non minimized/base images @
  http://cloud-images.ubuntu.com/mantic/ as these boot with initrd with
  the required drivers present for virtio-net.

  Reproducer

  ```
  wget -O "launch-qcow2-image-qemu-arm64.sh" 
https://people.canonical.com/~philroche/20230921-cloud-images-mantic-fail-to-provision/launch-qcow2-image-qemu-arm64.sh

  chmod +x ./launch-qcow2-image-qemu-arm64.sh
  wget 
https://people.canonical.com/~philroche/20230921-cloud-images-mantic-fail-to-provision/livecd.ubuntu-cpc.img
  ./launch-qcow2-image-qemu-arm64.sh --password passw0rd --image 
./livecd.ubuntu-cpc.img
  ```

  You will then be able to log in with user `ubuntu` and password
  `passw0rd`.

  You can run `ip a` and see that there is a network interface present
  (separate to `lo`) but no IP address has been assigned.

  ```
  ubuntu@cloudimg:~$ ip a
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
     valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
     valid_lft forever preferred_lft forever
  2: enp0s1:  mtu 1500 qdisc noop state DOWN group default 
qlen 1000
  link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff

  ```

  This is because when cloud-init is trying to configure network
  interfaces it doesn't find any so it doesn't configure any. But by the
  time boot is complete the network interface is present but cloud-init
  provisioning has already completed.

  You can verify this by running `sudo cloud-init clean && sudo cloud-
  init init`

  You can then see a successfully configured network interface

  ```
  ubuntu@cloudimg:~$ ip a
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
     valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
     valid_lft forever preferred_lft forever
  2: enp0s1:  mtu 1500 qdisc pfifo_fast state 
UP group default qlen 1000
  link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
  inet 10.0.2.15/24 metric 100 brd 10.0.2.255 scope global dynamic enp0s1
     valid_lft 86391sec preferred_lft 86391sec
  inet6 fec0::5054:ff:fe12:3456/64 scope site dynamic mngtmpaddr 
noprefixroute
     valid_lft 86393sec preferred_lft 14393sec
  inet6 fe80::5054:ff:fe12:3456/64 scope link
     valid_lft forever preferred_lft forever

  ```

  The bug is also reproducible with amd64 guest on adm64 host on
  older/slower hardware.

  The suggested fixes while debugging this issue are:

  * to include `virtio-net` as a built-in in the mantic generic kernel
  * understand what needs to change in cloud-init so that it can react to late 
additions of network interfaces

  I will file a separate bug against cloud-init to address the race
  condition on emulated guest/older hardware.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/2036968/+subscriptions


-- 
Mailing list:

[Touch-packages] [Bug 2036440] Re: Choosing "Try Ubuntu" on daily-legacy image produced a crash

Bug confirmed but it does unfortunately result in bug 2015857, and no
assertion mentioned in the system log.

I think the circumstances are consistent with bug 2036889 though
(asserting on X11 session shutdown), so we should focus on fixing that
first.

** No longer affects: ubiquity (Ubuntu)

** Changed in: gnome-shell (Ubuntu)
   Status: Incomplete => Confirmed

** No longer affects: apport (Ubuntu)

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

Title:
  Choosing "Try Ubuntu" on daily-legacy image produced a crash

Status in gnome-shell package in Ubuntu:
  Confirmed

Bug description:
  I was booting up a daily-legacy image from 20230918 and received a
  crash report after choosing "Try Ubuntu".

  ProblemType: Crash
  DistroRelease: Ubuntu 23.10
  Package: gnome-shell 45~rc-0ubuntu3
  Uname: Linux 6.5.0-5-generic x86_64
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Mon Sep 18 15:20:58 2023
  ExecutablePath: /usr/bin/gnome-shell
  ExecutableTimestamp: 1694375959
  ProcCmdline: gnome-shell --sm-disable --mode=ubiquity
  ProcCwd: /home/ubuntu
  ProcEnviron:
   LANG=C.UTF-8
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
  Signal: 6
  SourcePackage: gnome-shell
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo users

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/2036440/+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 2037202] Re: Mantic/23.10: PXE boot tries to initialize DHCP before network link is up

2023-10-02 Thread Dimitri John Ledkov

I request this to be considered release critical, as this prevents all
kernel team & certification team deployments of mantic systems,
inhibiting our ability to test SRUs on all architectures.

** Tags added: rls-mm-incoming

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

Title:
  Mantic/23.10: PXE boot tries to initialize DHCP before network link is
  up

Status in initramfs-tools package in Ubuntu:
  New

Bug description:
  I'm not sure whether this is the correct package for this bug, please
  reassign if not.

  I'm booting the Ubuntu Mantic/23.10 desktop beta image via PXE in
  order to perform an unattended installation. The kernel command line
  looks like that:

  iso/casper/vmlinuz --- ip=dhcp netboot=nfs
  nfsroot=192.168.1.1:/export/ubuntu autoinstall ds=nocloud\;s=

  This has worked perfectly before. However, in 23.10, the kernel tries
  to intialize DHCP before a network link is up.

  I can see a few instances of messages like the following:
  dhcpcd-10.0.2 starting
  dev: loaded udev
  no interfaces have a carrier
  exiting due to oneshot
  dhcpcd exited

  Then, the kernel tries to mount NFS, even though neither an IP address nor 
even a link is available:
  connect: Network is unreachable
  NFS over TCP not available from 192.168.1.1

  This is repeated for a while. In between, a message tells that now the link 
is up:
  [10.0002805] e1000e :00:19.0 enp0s25: NIC Link is Up 1000 Mbps Full 
Duplex, Flow Control: Rx/Tx

  The NFS messages repeat for a while, until the system gives up and I'm
  dropped into a busybox prompt.

  Executing dhcpcd now correctly gets IP addresses, but I don't know how
  to continue the boot from there.

  The problem occurs on most physical machines that I tried, but not in
  VMs.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/2037202/+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 2034986] Re: some text became unreadable during a distribution upgrade

2023-10-02 Thread Nick Rosbrook

** Tags removed: block-proposed

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

Title:
  some text became unreadable during a distribution upgrade

Status in ubuntu-meta package in Ubuntu:
  In Progress
Status in ubuntu-release-upgrader package in Ubuntu:
  Fix Committed
Status in ubuntu-meta source package in Mantic:
  In Progress
Status in ubuntu-release-upgrader source package in Mantic:
  Fix Committed

Bug description:
  I was upgrading from Lunar to Mantic the other day and left a couple
  of applications open during the upgrade process. During the upgrade
  the text in audacious became unreadable (I'll attach a screenshot) and
  I seem to recall the title bar of Firefox being unreadable but the
  contents of web pages still being readable.

  ProblemType: Bug
  DistroRelease: Ubuntu 23.10
  Package: ubuntu-release-upgrader-core 1:23.10.5
  ProcVersionSignature: Ubuntu 6.5.0-4.4-generic 6.5.0
  Uname: Linux 6.5.0-4-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia zfs
  ApportVersion: 2.27.0-0ubuntu2
  Architecture: amd64
  CasperMD5CheckResult: unknown
  CrashDB: ubuntu
  CurrentDesktop: ubuntu:GNOME
  Date: Fri Sep  8 15:39:27 2023
  InstallationDate: Installed on 2018-08-10 (1855 days ago)
  InstallationMedia: Ubuntu-Server 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  PackageArchitecture: all
  SourcePackage: ubuntu-release-upgrader
  Symptom: ubuntu-release-upgrader
  UpgradeStatus: Upgraded to mantic on 2023-09-06 (2 days ago)
  VarLogDistupgradeAptclonesystemstate.tar.gz: Error: command ['pkexec', 'cat', 
'/var/log/dist-upgrade/apt-clone_system_state.tar.gz'] failed with exit code 
126: Error executing command as another user: Request dismissed
  VarLogDistupgradeTermlog:
   
  mtime.conffile..etc.update-manager.meta-release: 2021-05-27T16:30:16.970490

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/2034986/+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 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"

** Description changed:

=== SRU information ===
[Meta]
This bug is part of a series of four bugs for a single SRU.
This ( #2033422 ) is the "central" bug with the global information and
debdiff.

The SRU information has been added to the four bug reports and I am
attaching the debdiff here only for all four.

I have also pushed the code to git (without any attempt to make it git-
ubuntu friendly).

https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy-
sru

3.0.2:
real 2m5.567s
user 4m3.948s
sys 2m0.233s

this SRU:
real 0m23.966s
user 2m35.687s
sys 0m1.920s

As can be easily seen, the speed-up is massive: system time is divided
by 60 and overall wall clock time is roughly five times lower.

+ In http://pad.lv/2009544 , Rafael also shared his performance numbers
+ and they are relatable to these. He used slightly different versions
+ (upstreams rather than patched with cherry-picks) but at least one of
+ the version used does not include other performance change. He also used
+ different hardware and this performance issue seems to depend on the
+ number of CPUs available but also obtained a performance several times
+ better. Results on a given machine vary also very little across runs
+ (less than 2% variation on runs of size 10). They are also very similar
+ on a Raspberry Pi 4 (8GB).
+
+ The benchmark uses https://www.google.com/humans.txt which takes around
+ 130ms to download on my machine but I modified the script to download
+ something only 20ms away. Results are so close to the ones using
+ humans.txt that they are within the error margin. This is consistent
+ with the high-concurrency in the benchmark which both saturates CPU, and
+ "hides" latencies that are relatively low.
+
+ Finally, there are positive reports on github. Unfortunately they are
+ not always completely targeted at these patches only and therefore I
+ will not link directly to them but they have also been encouraging.
+
[Where problems could occur]
The change is spread over several patches which touch the internals of
openssl. As such, the engine and provider functionality could be broken by
these changes. Fortunately, in addition to upstream's code review, these
patches are included in openssl 3.0.4 (iirc) and therefore in kinetic. No issue
related to these changes was reported on launchpad or upstream.

However, it is possible that there were more patch dependencies than
these in either 3.0.3 or 3.0.4. In that case there could be problems.

[Patches]
The patches come directly from upstream and apply cleanly.

https://github.com/openssl/openssl/pull/18151#issuecomment-1118535602

[Touch-packages] [Bug 2033597] Re: System theme messed up for no apparent reason

2023-10-02 Thread Bug Watch Updater

** Changed in: yaru
   Status: Unknown => New

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

Title:
  System theme messed up for no apparent reason

Status in Yaru Theme:
  New
Status in gtk+3.0 package in Ubuntu:
  New
Status in gtk4 package in Ubuntu:
  New
Status in yaru-theme package in Ubuntu:
  New

Bug description:
  Was browsing the web when all of a sudden all icons changed and system
  theme now looks like a blast from the past.

  Specifically:
  - "Home" icon on the desktop
  - Trash, disk icons on the app drawer
  - Icons and buttons on the "Restart required" msgbox, and its topbar icon 
(next to wifi)
  - Folder icons in Files (nautilus) window

  ProblemType: Bug
  DistroRelease: Ubuntu 23.10
  Package: nautilus 1:45~beta2-1ubuntu1
  ProcVersionSignature: Ubuntu 6.3.0-7.7-generic 6.3.5
  Uname: Linux 6.3.0-7-generic x86_64
  ApportVersion: 2.27.0-0ubuntu2
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Aug 31 02:32:02 2023
  GsettingsChanges: b'org.gnome.nautilus.preferences' b'migrated-gtk-settings' 
b'true'
  InstallationDate: Installed on 2023-08-26 (5 days ago)
  InstallationMedia: Ubuntu 23.10 "Mantic Minotaur" - Daily amd64 (20230825)
  ProcEnviron:
   LANG=en_US.UTF-8
   PATH=(custom, no user)
   SHELL=/bin/bash
   XDG_RUNTIME_DIR=
  RebootRequiredPkgs: Error: path contained symlinks.
  SourcePackage: nautilus
  UpgradeStatus: No upgrade log present (probably fresh install)
  usr_lib_nautilus: nautilus-extension-gnome-terminal 3.49.92-2ubuntu1

To manage notifications about this bug go to:
https://bugs.launchpad.net/yaru/+bug/2033597/+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 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"

** Description changed:

=== SRU information ===
[Meta]
This bug is part of a series of four bugs for a single SRU.
This ( #2033422 ) is the "central" bug with the global information and
debdiff.

The SRU information has been added to the four bug reports and I am
attaching the debdiff here only for all four.

I have also pushed the code to git (without any attempt to make it git-
ubuntu friendly).

https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy-
sru

3.0.2:
real 2m5.567s
user 4m3.948s
sys 2m0.233s

this SRU:
real 0m23.966s
user 2m35.687s
sys 0m1.920s

As can be easily seen, the speed-up is massive: system time is divided
by 60 and overall wall clock time is roughly five times lower.

+ However, it is possible that there were more patch dependencies than
+ these in either 3.0.3 or 3.0.4. In that case there could be problems.
+
[Patches]
The patches come directly from upstream and apply cleanly.

https://github.com/openssl/openssl/pull/18151#issuecomment-1118535602

*
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-Drop-ossl_provider_clear_all_operation_bits-and-all-.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0
*
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0002-Refactor-method-construction-pre-and-post-condition.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0
*
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0003-Don-t-empty-the-method-store-when-flushing-the-query.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0
*
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0004-Make-it-possible-to-remove-methods-by-the-provider-t.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0
*
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0005-Complete-the-cleanup-of-an-algorithm-in-OSSL_METHOD_.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0
*
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0006-For-child-libctx-provider-don-t-count-self-reference.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0
*

[Touch-packages] [Bug 2023545] Re: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate

** Description changed:

  === SRU information ===
  [Meta]
  This bug is part of a series of four bugs for a single SRU.
- The "central" bug with the global information and debdiff is #2033422
+ The "central" bug with the global information and debdiff is 
http://pad.lv/2033422
  
  [Impact]
  Openssl using an engine dumps core upon certificate creation; other 
operations are probably affected too. Overall, engines are likely mostly 
unusable.
  
  [Test plan]
  An engine is needed to test the fix and I don't think we have many in the 
archive. This complicates reproducing the issue. I have been relying on user 
reports which have been very detailled and helpful.
  The issue has also been reported independently and with another engine 
(devcrypto).
  The issue is fixed in openssl 3.0.8 which landed in lunar.
  
  [Where problems could occur]
  I don't pretend to understand the lifecycle of providers in openssl3 but the 
patch is simple and has been widely tested by now, including on ubuntu. Thus, I 
see little chance an unexpected problem would occur with it.
  
  [Patches]
  The patches come directly from upstream and apply cleanly.
  
  https://github.com/openssl/openssl/issues/18578
  
  *
  
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-
  sru-0001-Release-the-drbg-in-the-global-default-context-
  befor.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0
  
  === Original description ===
  
  openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem
  -keyout __key.pem --subj '/CN=US'
  
  ---Problem Description---
  OpenSSL with ibmca engine configured dumps core when creating a new 
certificate.
  
  # openssl engine
  (dynamic) Dynamic engine loading support
  (ibmca) Ibmca hardware engine support
  # openssl req  -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem 
-keyout __key.pem --subj '/CN=US'
  Segmentation fault (core dumped)
  
  # journalctl
  Jun 07 13:06:08 SYSTEM kernel: User process fault: interruption code 003b 
ilc:2 in libc.so.6[3ffae08+1ca000]
  Jun 07 13:06:08 SYSTEM kernel: Failing address:  TEID: 
0800
  Jun 07 13:06:08 SYSTEM kernel: Fault in primary space mode while using user 
ASCE.
  Jun 07 13:06:08 SYSTEM kernel: AS:9c2941c7 R3:0024
  Jun 07 13:06:08 SYSTEM kernel: CPU: 2 PID: 2344 Comm: openssl Kdump: loaded 
Not tainted 5.15.0-73-generic #80-Ubuntu
  Jun 07 13:06:08 SYSTEM kernel: Hardware name: IBM 3931 A01 703 (z/VM 7.3.0)
  Jun 07 13:06:08 SYSTEM kernel: User PSW : 070500018000 03ffae11c708
  Jun 07 13:06:08 SYSTEM kernel:R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:1 
AS:0 CC:0 PM:0 RI:0 EA:3
  Jun 07 13:06:08 SYSTEM kernel: User GPRS: 0007 03ffae11c6f0 
 02aa3289f9d0
  Jun 07 13:06:08 SYSTEM kernel:02aa1825980f 02aa3289f9d0 
 02aa328a4300
  Jun 07 13:06:08 SYSTEM kernel:03ffae870720 03ffae657128 
02aa03ff 
  Jun 07 13:06:08 SYSTEM kernel:03ffae24dd10 03ffae657120 
03ffae437c22 03ffec2fe000
  Jun 07 13:06:08 SYSTEM kernel: User Code: 03ffae11c6fc: b90400b2  
  lgr%r11,%r2
    03ffae11c700: 
4700bc0,0
   #03ffae11c704: 
b24f00a0ear%r10,%a0
   >03ffae11c708: 
58102018l%r1,24(%r2)
    03ffae11c70c: 
ebaa002dsllg%r10,%r10,32
    03ffae11c712: 
b24f00a1ear%r10,%a1
    03ffae11c716: 
5910a0d0c%r1,208(%r10)
    03ffae11c71a: 
a7840033brc8,03ffae11c780
  Jun 07 13:06:08 SYSTEM kernel: Last Breaking-Event-Address:
  Jun 07 13:06:08 SYSTEM kernel:  [<03ffae33242c>] 0x3ffae33242c
  Jun 07 13:06:08 SYSTEM systemd[1]: Started Process Core Dump (PID 2345/UID 0).
  Jun 07 13:06:08 SYSTEM systemd-coredump[2350]: Process 2344 (openssl) of user 
0 dumped core.
  
     Found module 
linux-vdso64.so.1 with build-id: bcfab8ac8dbd44c758c3c5494e2952db16905d2e
     Found module 
libica.so.4 with build-id: 0cc5ace50644dfba6d0ecf4f783477cd04a55731
     Found module 
ibmca.so with build-id: 27daaf0ed1857fdad3761c2b3db21020999eee08
     Found module 
ld64.so.1 with build-id: 31d4856f0ba9ea058c91a34f4d684ae0fe01964c

[Touch-packages] [Bug 1990216] Re: backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or CFB modes" to Jammy

** Description changed:

  === SRU information ===
  [Meta]
  This bug is part of a series of four bugs for a single SRU.
- The "central" bug with the global information and debdiff is #2033422
+ The "central" bug with the global information and debdiff is 
http://pad.lv/2033422
  
  [Impact]
  Decryption for Blowfish with OFB and CFB modes fails due to using a key 
shorter than expected by default.
  Encryption will also use a key shorter than expected.
  Exchange of encrypted data from/to Jammy using BF OFB/CFB will therefore lead 
to decryption issues.
  
  [Test plan]
  On Focal, run the following and copy the output to your clipboard
  
  for cipher in bf-cbc bf-cfb bf-ecb bf-ofb; do  echo "Test with ${cipher}" 
| openssl enc -${cipher} -k test -pbkdf2 -out "pouet.${cipher}"; done
  tar c pouet.bf-* | xz | base64 -w 60
  
  You can also run this on Lunar or Mantic if you add "-provider legacy
  -provider default" to the "openssl enc" invocation.
  
  On Jammy, run the following and paste your clipboard
  
  base64 -d | xz -d | tar x
  for cipher in bf-cbc bf-cfb bf-ecb bf-ofb; do openssl enc -d -provider 
legacy -provider default -${cipher} -k test -pbkdf2 -d -in "pouet.${cipher}"; 
done
  
  Only "Test with bf-cbc" and "Test with bf-ecb" will be properly
  decrypted: the other two will result in garbage on screen.
  
  Here is the result of the enc + tar + xz + base64 on Focal (works with
  Lunar/Mantic too but you need to added ):
  
  /Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4Cf/ARBdADgbyxDlZ/1Xd7bAmZw7
  8pbqQTu5j8StVybo1p1B2ydBc5VcodF6fu0hEp801tvirgSFNMSAHk5HMN/w
  hCgU1BIr/nK51g3A3Lkdv7QNbaUw2ux1AmO/MpCLKLffCB9ElFZH4tuOS5AR
  m9CJMzi6LQOw9wytGKm2IK3Ph7WpU6JQ/3HJilffQwHbFLnukiWGpLNO5v0O
  D/4AJikrU9iemfChT0jXDbIRZ8a8VpVhJqu0u6eYOheVTqmSRiHHpIC/p1VA
  ecFb0mACF/TQhjxcMUWGSGO/mtof+VaLiyg0KB87GKlChfwXTEvgbNuP9hmu
  GL64VhX568Oy9EakSxlcXiIRk14kJKv0MdHQqY1R22wAACzqSr/nzpwqAAGs
  AoBQAACjzq5WscRn+wIABFla
  
  Here is the same but from Jammy if you want to test encryption on Jammy
  and decryption on Lunar/Mantic:
  
  /Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4Cf/ARFdADgbyxDlZ/1Xd7bAmZw7
  8pbqQTu5j8StVybo1p1B2ydBc1zK4HR2g3CiLJet+R++nZy/gph6RscQ6hI3
  HySjdDOFRfjIVttiNK3DvRsZb37r8SXkj/JCYWicZGjWPZxVE3OAZhEed5qe
  jrFv871QAbm4jVGD4oIc4cOb5V/xDN7KWgwEzpWQy6+tcfPm3KLPQvULx56N
  2qQf60hP//p5EXS3RpCitUsrGUoYzTynjOUIRy2yCmgZDh62RmchUshyWePa
  k0nEYlDbl5/dSHXbWEWESqW+QDj136MZRwQRY+QC4MvLXg2Bo8H+Dl/xvNDF
  /5J4layZdFlh76lWOtFRVoIbX6JtpAP34g4zx1422GSNAABRzyqPdCqX
  1AABrQKAUAAABh3ynbHEZ/sCAARZWg==
  
  The contents are expected to be different due to the use of randomness.
  Don't try to compare the base64 outputs: I'm only using them to ease
  testing across containers.
  
  [Where problems could occur]
  This patch makes openssl match the documented default (see "man openssl-enc" 
and search for "Blowfish" for instance) and fixes decryption from an up-to-date 
Jammy to pretty much everything else, but it also create an issue for data 
encrypted on Jammy without this patch and Jammy with this patch.
  
  There are two possible cases: encrypted data being streamed across this
  boundary or data at rest being transferred or read later.
  
  Streaming is probably not an issue in practice because it's rather the
  current situation that has been an issue and it's easy to remedy by
  updating everything (which is relatively few machines since that's only
  Jammy and not any other OS or distribution).
  
  Data at rest is more annoying since updating Jammy will make it
  impossible to read the data again without updates to other pieces of
  software. That sounds like a really bad thing and it kind of is but at
  the same, the benefits are much larger than the issues. Indeed, there is
  already an incompatibility at the moment between Jammy and everything
  else and the more time passes by, the more such problematic files can be
  created. Luckily very few people are using blowfish nowadays and it's
  not even enabled by default anymore in openssl. Moreover the software
  update to work around the issue should be a single API call which is
  documented in the upstream bug report (
  https://github.com/openssl/openssl/issues/18359 ). Finally, I have
  warned the two projects that I am aware are impacted; this is made
  easier by the fact that they encountered the initial incompatibility.
  
  [Patches]
  The patches come directly from upstream and apply cleanly.
  
  https://github.com/openssl/openssl/issues/18359
  
  * 
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-Fix-regression-in-default-key-length-for-Blowfish-CF.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0
  * 
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0002-Test-the-default-key-length-of-the-Blowfish-ciphers.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0
  
  ===

[Touch-packages] [Bug 1994165] Re: CMS_final: do not ignore CMS_dataFinal result

** Description changed:

  === SRU information ===
  [Meta]
  This bug is part of a series of four bugs for a single SRU.
- The "central" bug with the global information and debdiff is #2033422
+ The "central" bug with the global information and debdiff is 
http://pad.lv/2033422
  
  [Impact]
  S/MIME signature can fail silently
  The commit by upstream propagates the return code of some functions rather 
than ignore it.
  
  [Test plan]
  This issue is not very simple to reproduce because "openssl cms" cannot be 
used to do so. This has to be done with the openssl API instead.
  At least the bug reportere here and the one on openssl's bug tracker have 
confirmed the patch solves the issue. Additionally, the bug reporter here has 
tested the PPA that contains the patche and validated it. Finally, I read 
through the patch attentively.
  
  [Where problems could occur]
  At this point it is unlikely an error would appear. The openssl bug tracker 
mentions nothing related to this patch which landed more than a year ago. The 
patch is simple and doesn't change the code logic.
  
  [Patches]
  The patches come directly from upstream and apply cleanly.
  
  https://github.com/openssl/openssl/pull/18876
  
  * 
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-REGRESSION-CMS_final-do-not-ignore-CMS_dataFinal-res.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0
  * 
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0002-Handle-SMIME_crlf_copy-return-code.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0
  
  === Original description ===
  
  https://github.com/openssl/openssl/pull/18876
  
  The CMS_dataFinal result is important as signature may fail, however, it
  is ignored while returning success from CMS_final.
  
  Please add this fix to The openssl 3.0.2 "Jammy Jellyfish (supported)"
  
  Thanks
  
  Upstream commit:
  
  ```
  commit 67c0460b89cc1b0644a1a59af78284dfd8d720af
  Author: Alon Bar-Lev 
  Date:   Tue Jul 26 15:17:06 2022 +0300
  
  Handle SMIME_crlf_copy return code
  
  Currently the SMIME_crlf_copy result is ignored in all usages. It does
  return failure when memory allocation fails.
  
  This patch handles the SMIME_crlf_copy return code in all
  occurrences.
  
  Signed-off-by: Alon Bar-Lev 
  
  Reviewed-by: Tomas Mraz 
  Reviewed-by: Paul Dale 
  Reviewed-by: Hugo Landau 
  (Merged from https://github.com/openssl/openssl/pull/18876)
  ```

-- 
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/1994165

Title:
  CMS_final: do not ignore CMS_dataFinal result

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Jammy:
  In Progress
Status in openssl source package in Kinetic:
  Won't Fix
Status in openssl source package in Lunar:
  Fix Released

Bug description:
  === SRU information ===
  [Meta]
  This bug is part of a series of four bugs for a single SRU.
  The "central" bug with the global information and debdiff is 
http://pad.lv/2033422

  [Impact]
  S/MIME signature can fail silently
  The commit by upstream propagates the return code of some functions rather 
than ignore it.

  [Test plan]
  This issue is not very simple to reproduce because "openssl cms" cannot be 
used to do so. This has to be done with the openssl API instead.
  At least the bug reportere here and the one on openssl's bug tracker have 
confirmed the patch solves the issue. Additionally, the bug reporter here has 
tested the PPA that contains the patche and validated it. Finally, I read 
through the patch attentively.

  [Where problems could occur]
  At this point it is unlikely an error would appear. The openssl bug tracker 
mentions nothing related to this patch which landed more than a year ago. The 
patch is simple and doesn't change the code logic.

  [Patches]
  The patches come directly from upstream and apply cleanly.

  https://github.com/openssl/openssl/pull/18876

  * 
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-REGRESSION-CMS_final-do-not-ignore-CMS_dataFinal-res.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0
  * 
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0002-Handle-SMIME_crlf_copy-return-code.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0

  === Original description ===

  https://github.com/openssl/openssl/pull/18876

  The CMS_dataFinal result is important as signature may fail, however, it
  is ignored while returning success from CMS_final.

  Please add this fix to The openssl 3.0.2 "Jammy Jellyfish (supported)"

  Thanks

  Upstream commit:

  ```
  commit 67c0460b89cc1b0644a1a59af78284dfd8d720af
  Author: Alon Bar-Lev 
  Date:   Tue Jul 26 15:17:06 2022 +0300

  Handle SMIME_crlf_copy

[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"

** Description changed:

  === SRU information ===
  [Meta]
  This bug is part of a series of four bugs for a single SRU.
  This ( #2033422 ) is the "central" bug with the global information and 
debdiff.
  
  This SRU addresses four issues with Jammy's openssl version:
- - #1990216: Blowfish OFB/CFB decryption
- - #1994165: ignored SMIME signature errors
- - #2023545: imbca engine dumps core
- - #2033422: very high CPU usage for concurrent TLS connections
+ - http://pad.lv/1990216: Blowfish OFB/CFB decryption
+ - http://pad.lv/1994165: ignored SMIME signature errors
+ - http://pad.lv/2023545: imbca engine dumps core
+ - http://pad.lv/2033422: very high CPU usage for concurrent TLS connections
  
  The SRU information has been added to the four bug reports and I am
  attaching the debdiff here only for all four.
  
  All the patches have been included in subsequent openssl 3.0.x releases
  which in turn have been included in subsequent Ubuntu releases. There
  has been no report of issues when updating to these Ubuntu releases.
  
  I have rebuilt the openssl versions and used abi-compliance-checker to
  compare the ABIs of the libraries in jammy and the one for the SRU. Both
  matched completely (FYI, mantic's matched completely too).
  
  The patch related to blowfish presents an annoying situation: jammy's openssl 
creates incompatible files and cannot read other files but fixing it will lead 
to files created on jammy so far to become unreadable. Fortunately, blowfish is 
long-deprecated and applications can be improved to handle this situation if 
the need arises in practice.
  This is stated in the SRU information in the bug and in d/changelog.
  The current situation in Jammy could be a security issue but due to the 
aforementioned deprecation, the low usage of blowfish and the fact that 
upstream didn't consider this worthy of a security notice, we (this includes 
the security team) chose not to pursue that path either.
  
  I have also pushed the code to git (without any attempt to make it git-
  ubuntu friendly).
  
  
https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy-
  sru
  
  [Impact]
  Severely degraded performance for concurrent operations compared to openssl 
1.1. The performance is so degraded that some workloads fail due to timeouts or 
insufficient resources (noone magically has 5 times more machines). As a 
consequence, a number of people use openssl 1.1 instead and do not get security 
updates.
  
  [Test plan]
  Rafael Lopez has shared a simple benchmarks in #2009544 with 
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py
 .
  Using this, I get the following numbers on my laptop:
  
  3.0.2:
- real  2m5.567s
- user  4m3.948s
- sys   2m0.233s
+ real  2m5.567s
+ user  4m3.948s
+ sys   2m0.233s
  
  this SRU:
- real  0m23.966s
- user  2m35.687s
- sys   0m1.920s
+ real  0m23.966s
+ user  2m35.687s
+ sys   0m1.920s
  
  As can be easily seen, the speed-up is massive: system time is divided
  by 60 and overall wall clock time is roughly five times lower.
  
  [Where problems could occur]
  The change is spread over several patches which touch the internals of 
openssl. As such, the engine and provider functionality could be broken by 
these changes. Fortunately, in addition to upstream's code review, these 
patches are included in openssl 3.0.4 (iirc) and therefore in kinetic. No issue 
related to these changes was reported on launchpad or upstream.
  
  [Patches]
  The patches come directly from upstream and apply cleanly.
  
  https://github.com/openssl/openssl/pull/18151#issuecomment-1118535602
  
  * 
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-Drop-ossl_provider_clear_all_operation_bits-and-all-.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0
  * 
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0002-Refactor-method-construction-pre-and-post-condition.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0
  * 
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0003-Don-t-empty-the-method-store-when-flushing-the-query.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0
  * 
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0004-Make-it-possible-to-remove-methods-by-the-provider-t.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0
  * 
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0005-Complete-the-cleanup-of-an-algorithm-in-OSSL_METHOD_.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0
  * 
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0006-For-child-libctx-provider-don-t-count-self-reference.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0
  *

[Touch-packages] [Bug 2037417] Re: mantic images after 20230917 are failing to deploy with failure to mount root and kernel filesystems

2023-10-02 Thread Francis Ginther

My experiments with the workaround mentioned in
https://bugs.launchpad.net/ubuntu/+source/initramfs-
tools/+bug/2037202/comments/1 did not help.

-- 
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/2037417

Title:
  mantic images after 20230917 are failing to deploy with failure to
  mount root and kernel filesystems

Status in maas-images:
  New
Status in The Ubuntu-power-systems project:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  Mantic arm64 deploys started failing on Sept 18th with:

  [   41.913552] systemd[1]: Starting systemd-remount-fs.service - Remount Root 
and Kernel File Systems...
   Starting [0;1;39msystemd-remount-f鈥t Root and Kernel File 
Systems...
  [   41.940748] systemd[1]: Starting systemd-udev-trigger.service - Coldplug 
All udev Devices...
   Starting [0;1;39msystemd-udev-trig鈥0m - Coldplug All udev 
Devices...
  [   41.964758] systemd[1]: Started systemd-journald.service - Journal Service.
  [[0;32m  OK  [0m] Started [0;1;39msystemd-journald.service[0m - Journal 
Service.
  [[0;32m  OK  [0m] Mounted [0;1;39mdev-hugepages.mount[0m - Huge Pages 
File System.
  [[0;32m  OK  [0m] Mounted [0;1;39mdev-mqueue.mount[鈥�- POSIX Message 
Queue File System.
  [[0;32m  OK  [0m] Mounted [0;1;39msys-kernel-debug.m鈥t[0m - Kernel Debug 
File System.
  [[0;32m  OK  [0m] Mounted [0;1;39msys-kernel-tracing鈥t[0m - Kernel Trace 
File System.
  [[0;32m  OK  [0m] Finished [0;1;39mkeyboard-setup.se鈥�- Set the console 
keyboard layout.
  [[0;32m  OK  [0m] Finished [0;1;39mkmod-static-nodes鈥eate List of Static 
Device Nodes.
  [[0;32m  OK  [0m] Finished [0;1;39mlvm2-monitor.serv鈥ing dmeventd or 
progress polling.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@configfs鈥0m - Load Kernel 
Module configfs.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@dm_mod.s鈥[0m - Load Kernel 
Module dm_mod.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@drm.service[0m - Load Kernel 
Module drm.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@efi_psto鈥 - Load Kernel 
Module efi_pstore.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@fuse.service[0m - Load Kernel 
Module fuse.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@loop.service[0m - Load Kernel 
Module loop.
  [[0;32m  OK  [0m] Finished [0;1;39msystemd-modules-l鈥ervice[0m - Load 
Kernel Modules.
  [[0;1;31mFAILED[0m] Failed to start [0;1;39msystemd-re鈥unt Root and 
Kernel File Systems.
  See 'systemctl status systemd-remount-fs.service' for details.

  After this many other services and cloud-init fails. See the full
  kopter-0918.log. For comparison, a log from the prior day's test is
  also attached.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas-images/+bug/2037417/+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 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"

** Description changed:

=== SRU information ===
[Meta]
This bug is part of a series of four bugs for a single SRU.
This ( #2033422 ) is the "central" bug with the global information and
debdiff.

This SRU addresses four issues with Jammy's openssl version:
- #1990216: Blowfish OFB/CFB decryption
- #1994165: ignored SMIME signature errors
- #2023545: imbca engine dumps core
- #2033422: very high CPU usage for concurrent TLS connections

The SRU information has been added to the four bug reports and I am
attaching the debdiff here only for all four.

I have also pushed the code to git (without any attempt to make it git-
ubuntu friendly).

https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy-
sru

[Test plan]
- Rafael Lopez has shared a simple benchmarks and results in #2009544 . I have
tested this on a raspberry pi 4 with 8GB of memory and obtained speedups at
least as high.
+ Rafael Lopez has shared a simple benchmarks in #2009544 with
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/2009544/+attachment/5690224/+files/main.py
.
+ Using this, I get the following numbers on my laptop:
+
+ 3.0.2:
+ real 2m5.567s
+ user 4m3.948s
+ sys 2m0.233s
+
+ this SRU:
+ real 0m23.966s
+ user 2m35.687s
+ sys 0m1.920s
+
+ As can be easily seen, the speed-up is massive: system time is divided
+ by 60 and overall wall clock time is roughly five times lower.

[Where problems could occur]
- The change is spread over several patches which touch the internals of
openssl. Upstream has code review in place and the patches have first appeared
in openssl 3.0.4 iirc and therefore in kinetic which was released a year ago
and we have not seen issues crop up.
+ The change is spread over several patches which touch the internals of
openssl. As such, the engine and provider functionality could be broken by
these changes. Fortunately, in addition to upstream's code review, these
patches are included in openssl 3.0.4 (iirc) and therefore in kinetic. No issue
related to these changes was reported on launchpad or upstream.

[Patches]
The patches come directly from upstream and apply cleanly.

https://github.com/openssl/openssl/pull/18151#issuecomment-1118535602

[Touch-packages] [Bug 1970402] Re: Initrd out of memory error after upgrade to 22.04

2023-10-02 Thread Jan Ehlert

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

** Also affects: initramfs-tools
   Importance: Undecided
   Status: New

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

Title:
  Initrd out of memory error after upgrade to 22.04

Status in initramfs-tools:
  New
Status in initramfs-tools package in Ubuntu:
  Confirmed
Status in initramfs-tools source package in Jammy:
  Confirmed

Bug description:
  After upgrading to 22.04 system is unbootable because of "out of memory" 
error when loading initial ramdisk. I was able to fix it by editing cat 
/etc/initramfs-tools/initramfs.conf
  and changing configuration to:
  MODULES=dep
  COMPRESS=xz
  RUNSIZE=15%

  Not sure which one helped, but I can test it if needed.

  System information:
  Description:Ubuntu 22.04 LTS
  Release:22.04

  initramfs-tools:
Installed: 0.140ubuntu13
Candidate: 0.140ubuntu13
Version table:
   *** 0.140ubuntu13 500
  500 http://pl.archive.ubuntu.com/ubuntu jammy/main amd64 Packages
  500 http://pl.archive.ubuntu.com/ubuntu jammy/main i386 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/initramfs-tools/+bug/1970402/+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 2029930] Re: wget crash when printing download rate

2023-10-02 Thread halfgaar

I'm still getting a bunch of wget crashes from cron jobs I have. Is
there any progress on this?

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

Title:
  wget crash when printing download rate

Status in wget package in Ubuntu:
  Confirmed
Status in wget package in Debian:
  Confirmed

Bug description:
  
  All supported versions of Ubuntu suffer from crashes in wget in printing of 
the download speed. I've been getting this on various servers. It's been fixed 
upstream and should probably be included in 'updates' of all supported Ubuntu 
versions.

  https://git.savannah.gnu.org/git/wget.git
  Commit 04ab35666997fbb3cd5d72497415fb3dfd62dcc5

  https://lists.gnu.org/archive/html/bug-wget/2023-08/msg1.html

  Patch attached.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/wget/+bug/2029930/+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 1994165] Re: CMS_final: do not ignore CMS_dataFinal result

** Description changed:

  === SRU information ===
+ [Meta]
+ This bug is part of a series of four bugs for a single SRU.
+ The "central" bug with the global information and debdiff is #2033422
  
  [Impact]
  S/MIME signature can fail silently
  The commit by upstream propagates the return code of some functions rather 
than ignore it.
  
  [Test plan]
  This issue is not very simple to reproduce because "openssl cms" cannot be 
used to do so. This has to be done with the openssl API instead.
  At least the bug reportere here and the one on openssl's bug tracker have 
confirmed the patch solves the issue. Additionally, the bug reporter here has 
tested the PPA that contains the patche and validated it. Finally, I read 
through the patch attentively.
  
  [Where problems could occur]
  At this point it is unlikely an error would appear. The openssl bug tracker 
mentions nothing related to this patch which landed more than a year ago. The 
patch is simple and doesn't change the code logic.
  
  [Patches]
  The patches come directly from upstream and apply cleanly.
  
  https://github.com/openssl/openssl/pull/18876
  
  * 
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-REGRESSION-CMS_final-do-not-ignore-CMS_dataFinal-res.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0
  * 
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0002-Handle-SMIME_crlf_copy-return-code.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0
  
  === Original description ===
  
  https://github.com/openssl/openssl/pull/18876
  
  The CMS_dataFinal result is important as signature may fail, however, it
  is ignored while returning success from CMS_final.
  
  Please add this fix to The openssl 3.0.2 "Jammy Jellyfish (supported)"
  
  Thanks
  
  Upstream commit:
  
  ```
  commit 67c0460b89cc1b0644a1a59af78284dfd8d720af
  Author: Alon Bar-Lev 
  Date:   Tue Jul 26 15:17:06 2022 +0300
  
  Handle SMIME_crlf_copy return code
  
  Currently the SMIME_crlf_copy result is ignored in all usages. It does
  return failure when memory allocation fails.
  
  This patch handles the SMIME_crlf_copy return code in all
  occurrences.
  
  Signed-off-by: Alon Bar-Lev 
  
  Reviewed-by: Tomas Mraz 
  Reviewed-by: Paul Dale 
  Reviewed-by: Hugo Landau 
  (Merged from https://github.com/openssl/openssl/pull/18876)
  ```

-- 
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/1994165

Title:
  CMS_final: do not ignore CMS_dataFinal result

Status in openssl package in Ubuntu:
  Fix Released
Status in openssl source package in Jammy:
  In Progress
Status in openssl source package in Kinetic:
  Won't Fix
Status in openssl source package in Lunar:
  Fix Released

Bug description:
  === SRU information ===
  [Meta]
  This bug is part of a series of four bugs for a single SRU.
  The "central" bug with the global information and debdiff is #2033422

  [Impact]
  S/MIME signature can fail silently
  The commit by upstream propagates the return code of some functions rather 
than ignore it.

  [Test plan]
  This issue is not very simple to reproduce because "openssl cms" cannot be 
used to do so. This has to be done with the openssl API instead.
  At least the bug reportere here and the one on openssl's bug tracker have 
confirmed the patch solves the issue. Additionally, the bug reporter here has 
tested the PPA that contains the patche and validated it. Finally, I read 
through the patch attentively.

  [Where problems could occur]
  At this point it is unlikely an error would appear. The openssl bug tracker 
mentions nothing related to this patch which landed more than a year ago. The 
patch is simple and doesn't change the code logic.

  [Patches]
  The patches come directly from upstream and apply cleanly.

  https://github.com/openssl/openssl/pull/18876

  * 
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-REGRESSION-CMS_final-do-not-ignore-CMS_dataFinal-res.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0
  * 
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0002-Handle-SMIME_crlf_copy-return-code.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0

  === Original description ===

  https://github.com/openssl/openssl/pull/18876

  The CMS_dataFinal result is important as signature may fail, however, it
  is ignored while returning success from CMS_final.

  Please add this fix to The openssl 3.0.2 "Jammy Jellyfish (supported)"

  Thanks

  Upstream commit:

  ```
  commit 67c0460b89cc1b0644a1a59af78284dfd8d720af
  Author: Alon Bar-Lev 
  Date:   Tue Jul 26 15:17:06 2022 +0300

  Handle SMIME_crlf_copy return code

  Currently the SMIME_crlf_copy result is ignored in all usages. It does

[Touch-packages] [Bug 2023545] Re: [UBUNTU 22.04] openssl with ibmca engine configured dumps core when creating a new certificate

** Description changed:

  === SRU information ===
+ [Meta]
+ This bug is part of a series of four bugs for a single SRU.
+ The "central" bug with the global information and debdiff is #2033422
  
  [Impact]
  Openssl using an engine dumps core upon certificate creation; other 
operations are probably affected too. Overall, engines are likely mostly 
unusable.
  
  [Test plan]
  An engine is needed to test the fix and I don't think we have many in the 
archive. This complicates reproducing the issue. I have been relying on user 
reports which have been very detailled and helpful.
  The issue has also been reported independently and with another engine 
(devcrypto).
  The issue is fixed in openssl 3.0.8 which landed in lunar.
  
  [Where problems could occur]
  I don't pretend to understand the lifecycle of providers in openssl3 but the 
patch is simple and has been widely tested by now, including on ubuntu. Thus, I 
see little chance an unexpected problem would occur with it.
  
  [Patches]
  The patches come directly from upstream and apply cleanly.
  
  https://github.com/openssl/openssl/issues/18578
  
  *
  
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-
  sru-0001-Release-the-drbg-in-the-global-default-context-
  befor.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0
  
  === Original description ===
  
  openssl req -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem
  -keyout __key.pem --subj '/CN=US'
  
  ---Problem Description---
  OpenSSL with ibmca engine configured dumps core when creating a new 
certificate.
  
  # openssl engine
  (dynamic) Dynamic engine loading support
  (ibmca) Ibmca hardware engine support
  # openssl req  -new -newkey rsa:2048 -x509 -sha256 -nodes -out __cert.pem 
-keyout __key.pem --subj '/CN=US'
  Segmentation fault (core dumped)
  
  # journalctl
  Jun 07 13:06:08 SYSTEM kernel: User process fault: interruption code 003b 
ilc:2 in libc.so.6[3ffae08+1ca000]
  Jun 07 13:06:08 SYSTEM kernel: Failing address:  TEID: 
0800
  Jun 07 13:06:08 SYSTEM kernel: Fault in primary space mode while using user 
ASCE.
  Jun 07 13:06:08 SYSTEM kernel: AS:9c2941c7 R3:0024
  Jun 07 13:06:08 SYSTEM kernel: CPU: 2 PID: 2344 Comm: openssl Kdump: loaded 
Not tainted 5.15.0-73-generic #80-Ubuntu
  Jun 07 13:06:08 SYSTEM kernel: Hardware name: IBM 3931 A01 703 (z/VM 7.3.0)
  Jun 07 13:06:08 SYSTEM kernel: User PSW : 070500018000 03ffae11c708
  Jun 07 13:06:08 SYSTEM kernel:R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:1 
AS:0 CC:0 PM:0 RI:0 EA:3
  Jun 07 13:06:08 SYSTEM kernel: User GPRS: 0007 03ffae11c6f0 
 02aa3289f9d0
  Jun 07 13:06:08 SYSTEM kernel:02aa1825980f 02aa3289f9d0 
 02aa328a4300
  Jun 07 13:06:08 SYSTEM kernel:03ffae870720 03ffae657128 
02aa03ff 
  Jun 07 13:06:08 SYSTEM kernel:03ffae24dd10 03ffae657120 
03ffae437c22 03ffec2fe000
  Jun 07 13:06:08 SYSTEM kernel: User Code: 03ffae11c6fc: b90400b2  
  lgr%r11,%r2
    03ffae11c700: 
4700bc0,0
   #03ffae11c704: 
b24f00a0ear%r10,%a0
   >03ffae11c708: 
58102018l%r1,24(%r2)
    03ffae11c70c: 
ebaa002dsllg%r10,%r10,32
    03ffae11c712: 
b24f00a1ear%r10,%a1
    03ffae11c716: 
5910a0d0c%r1,208(%r10)
    03ffae11c71a: 
a7840033brc8,03ffae11c780
  Jun 07 13:06:08 SYSTEM kernel: Last Breaking-Event-Address:
  Jun 07 13:06:08 SYSTEM kernel:  [<03ffae33242c>] 0x3ffae33242c
  Jun 07 13:06:08 SYSTEM systemd[1]: Started Process Core Dump (PID 2345/UID 0).
  Jun 07 13:06:08 SYSTEM systemd-coredump[2350]: Process 2344 (openssl) of user 
0 dumped core.
  
     Found module 
linux-vdso64.so.1 with build-id: bcfab8ac8dbd44c758c3c5494e2952db16905d2e
     Found module 
libica.so.4 with build-id: 0cc5ace50644dfba6d0ecf4f783477cd04a55731
     Found module 
ibmca.so with build-id: 27daaf0ed1857fdad3761c2b3db21020999eee08
     Found module 
ld64.so.1 with build-id: 31d4856f0ba9ea058c91a34f4d684ae0fe01964c
     Found module 
libc.so.6 with

[Touch-packages] [Bug 1990216] Re: backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or CFB modes" to Jammy

** Description changed:

  === SRU information ===
+ [Meta]
+ This bug is part of a series of four bugs for a single SRU.
+ The "central" bug with the global information and debdiff is #2033422
  
  [Impact]
  Decryption for Blowfish with OFB and CFB modes fails due to using a key 
shorter than expected by default.
  Encryption will also use a key shorter than expected.
  Exchange of encrypted data from/to Jammy using BF OFB/CFB will therefore lead 
to decryption issues.
  
  [Test plan]
  On Focal, run the following and copy the output to your clipboard
  
  for cipher in bf-cbc bf-cfb bf-ecb bf-ofb; do  echo "Test with ${cipher}" 
| openssl enc -${cipher} -k test -pbkdf2 -out "pouet.${cipher}"; done
  tar c pouet.bf-* | xz | base64 -w 60
  
  You can also run this on Lunar or Mantic if you add "-provider legacy
  -provider default" to the "openssl enc" invocation.
  
  On Jammy, run the following and paste your clipboard
  
  base64 -d | xz -d | tar x
  for cipher in bf-cbc bf-cfb bf-ecb bf-ofb; do openssl enc -d -provider 
legacy -provider default -${cipher} -k test -pbkdf2 -d -in "pouet.${cipher}"; 
done
  
  Only "Test with bf-cbc" and "Test with bf-ecb" will be properly
  decrypted: the other two will result in garbage on screen.
  
  Here is the result of the enc + tar + xz + base64 on Focal (works with
  Lunar/Mantic too but you need to added ):
  
  /Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4Cf/ARBdADgbyxDlZ/1Xd7bAmZw7
  8pbqQTu5j8StVybo1p1B2ydBc5VcodF6fu0hEp801tvirgSFNMSAHk5HMN/w
  hCgU1BIr/nK51g3A3Lkdv7QNbaUw2ux1AmO/MpCLKLffCB9ElFZH4tuOS5AR
  m9CJMzi6LQOw9wytGKm2IK3Ph7WpU6JQ/3HJilffQwHbFLnukiWGpLNO5v0O
  D/4AJikrU9iemfChT0jXDbIRZ8a8VpVhJqu0u6eYOheVTqmSRiHHpIC/p1VA
  ecFb0mACF/TQhjxcMUWGSGO/mtof+VaLiyg0KB87GKlChfwXTEvgbNuP9hmu
  GL64VhX568Oy9EakSxlcXiIRk14kJKv0MdHQqY1R22wAACzqSr/nzpwqAAGs
  AoBQAACjzq5WscRn+wIABFla
  
  Here is the same but from Jammy if you want to test encryption on Jammy
  and decryption on Lunar/Mantic:
  
  /Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4Cf/ARFdADgbyxDlZ/1Xd7bAmZw7
  8pbqQTu5j8StVybo1p1B2ydBc1zK4HR2g3CiLJet+R++nZy/gph6RscQ6hI3
  HySjdDOFRfjIVttiNK3DvRsZb37r8SXkj/JCYWicZGjWPZxVE3OAZhEed5qe
  jrFv871QAbm4jVGD4oIc4cOb5V/xDN7KWgwEzpWQy6+tcfPm3KLPQvULx56N
  2qQf60hP//p5EXS3RpCitUsrGUoYzTynjOUIRy2yCmgZDh62RmchUshyWePa
  k0nEYlDbl5/dSHXbWEWESqW+QDj136MZRwQRY+QC4MvLXg2Bo8H+Dl/xvNDF
  /5J4layZdFlh76lWOtFRVoIbX6JtpAP34g4zx1422GSNAABRzyqPdCqX
  1AABrQKAUAAABh3ynbHEZ/sCAARZWg==
  
  The contents are expected to be different due to the use of randomness.
  Don't try to compare the base64 outputs: I'm only using them to ease
  testing across containers.
  
  [Where problems could occur]
  This patch makes openssl match the documented default (see "man openssl-enc" 
and search for "Blowfish" for instance) and fixes decryption from an up-to-date 
Jammy to pretty much everything else, but it also create an issue for data 
encrypted on Jammy without this patch and Jammy with this patch.
  
  There are two possible cases: encrypted data being streamed across this
  boundary or data at rest being transferred or read later.
  
  Streaming is probably not an issue in practice because it's rather the
  current situation that has been an issue and it's easy to remedy by
  updating everything (which is relatively few machines since that's only
  Jammy and not any other OS or distribution).
  
  Data at rest is more annoying since updating Jammy will make it
  impossible to read the data again without updates to other pieces of
  software. That sounds like a really bad thing and it kind of is but at
  the same, the benefits are much larger than the issues. Indeed, there is
  already an incompatibility at the moment between Jammy and everything
  else and the more time passes by, the more such problematic files can be
  created. Luckily very few people are using blowfish nowadays and it's
  not even enabled by default anymore in openssl. Moreover the software
  update to work around the issue should be a single API call which is
  documented in the upstream bug report (
  https://github.com/openssl/openssl/issues/18359 ). Finally, I have
  warned the two projects that I am aware are impacted; this is made
  easier by the fact that they encountered the initial incompatibility.
  
  [Patches]
  The patches come directly from upstream and apply cleanly.
  
  https://github.com/openssl/openssl/issues/18359
  
  * 
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-Fix-regression-in-default-key-length-for-Blowfish-CF.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0
  * 
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0002-Test-the-default-key-length-of-the-Blowfish-ciphers.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0
  
  === Original description ===
  
  OpenSSL upstream implemented a fix for their issue #18359

[Touch-packages] [Bug 2033422] Re: openssl: backport to jammy "clear method store / query cache confusion"

Attaching debdiff for openssl from 3.0.2-0ubuntu1.10 to
3.0.2-0ubuntu1.11

** Description changed:

  === SRU information ===
+ [Meta]
+ This bug is part of a series of four bugs for a single SRU.
+ The "central" bug with the global information and debdiff is #2033422
+ 
+ This SRU addresses four issues with Jammy's openssl version:
+ - #1990216: Blowfish OFB/CFB decryption
+ - #1994165: ignored SMIME signature errors
+ - #2023545: imbca engine dumps core
+ - #2033422: very high CPU usage for concurrent TLS connections
+ 
+ The SRU information has been added to the four bug reports and I am
+ attaching the debdiff here only for all four.
+ 
+ All the patches have been included in subsequent openssl 3.0.x releases
+ which in turn have been included in subsequent Ubuntu releases. There
+ has been no report of issues when updating to these Ubuntu releases.
+ 
+ I have rebuilt the openssl versions and used abi-compliance-checker to
+ compare the ABIs of the libraries in jammy and the one for the SRU. Both 
matched completely (FYI, mantic's matched completely too).
+ 
+ The patch related to blowfish presents an annoying situation: jammy's
+ openssl creates incompatible files and cannot read other files but
+ fixing it will lead to files created on jammy so far to become unreadable. 
Fortunately, blowfish is long-deprecated and applications
+ can be improved to handle this situation if the need arises in practice.
+ This is stated in the SRU information in the bug and in d/changelog.
+ The current situation in Jammy could be a security issue but due to the 
aforementioned deprecation, the low usage of blowfish and the fact that 
upstream didn't consider this worthy of a security notice, we (this includes 
the security team) chose not to pursue that path either.
+ 
+ I have also pushed the code to git (without any attempt to make it git-
+ ubuntu friendly).
+ 
+ 
https://code.launchpad.net/~adrien-n/ubuntu/+source/openssl/+git/openssl/+ref/jammy-
+ sru
  
  [Impact]
  Severely degraded performance for concurrent operations compared to openssl 
1.1. The performance is so degraded that some workloads fail due to timeouts or 
insufficient resources (noone magically has 5 times more machines). As a 
consequence, a number of people use openssl 1.1 instead and do not get security 
updates.
  
  [Test plan]
  Rafael Lopez has shared a simple benchmarks and results in #2009544 . I have 
tested this on a raspberry pi 4 with 8GB of memory and obtained speedups at 
least as high.
  
  [Where problems could occur]
  The change is spread over several patches which touch the internals of 
openssl. Upstream has code review in place and the patches have first appeared 
in openssl 3.0.4 iirc and therefore in kinetic which was released a year ago 
and we have not seen issues crop up.
  
  [Patches]
  The patches come directly from upstream and apply cleanly.
  
  https://github.com/openssl/openssl/pull/18151#issuecomment-1118535602
  
  * 
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-Drop-ossl_provider_clear_all_operation_bits-and-all-.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0
  * 
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0002-Refactor-method-construction-pre-and-post-condition.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0
  * 
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0003-Don-t-empty-the-method-store-when-flushing-the-query.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0
  * 
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0004-Make-it-possible-to-remove-methods-by-the-provider-t.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0
  * 
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0005-Complete-the-cleanup-of-an-algorithm-in-OSSL_METHOD_.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0
  * 
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0006-For-child-libctx-provider-don-t-count-self-reference.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0
  * 
https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0007-Add-method-store-cache-flush-and-method-removal-to-n.patch?h=jammy-sru=04ef023920ab08fba214817523fba897527dfff0
  
  === Original description ===
  
  This is about SRU'ing to Jammy the patches at
  https://github.com/openssl/openssl/pull/18151#issuecomment-1118535602 .
  They're purely performance but their impact is large. They have been
  released as part of openssl 3.0.4 (they're among the first after 3.0.3)
  which has been included in Kinetic.

** Description changed:

** Description changed:

  === SRU information ===
  [Meta]
  This bug is part of a series of four bugs for a single SRU.
  The "central" bug with the global information and debdiff is

[Touch-packages] [Bug 2037907] Re: No package 'nss' found

2023-10-02 Thread Clark

https://www.debian.org/Bugs/ is just for debian

I need help to install poppler on debian which I don't think I can get
help there

As said. I managed to install poppler on Debian with initial syntax.. I
just need to know how to install the dependencies

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

Title:
  No package 'nss' found

Status in poppler package in Ubuntu:
  Invalid

Bug description:
  Have installed poppler on several systems, but experience issues in
  some cases.

  All the dependencies should be installed!

  Distro: Debian Bullseye 11

  
  # apt-get install libopenjp2-7-dev libfreetype6-dev libfontconfig1-dev 
libjpeg-dev libtiff5-dev
  # cd /var/bin && wget https://poppler.freedesktop.org/poppler-23.09.0.tar.xz 
&& tar -xvf poppler-23.09.0.tar.xz
  # cd poppler-23.09.0 && mkdir build && cd build
  # cmake ..

  
  CMake Warning at CMakeLists.txt:95 (message):

  
 No test data found in $testdatadir.
 You will not be able to run 'make test' successfully.


 The test data is not included in the source packages
 and is also not part of the main git repository. Instead,
 you can checkout the test data from its own git
 repository with:


   git clone git://git.freedesktop.org/git/poppler/test


 You should checkout the test data as a sibling of your
 poppler source folder or specify the location of your
 checkout with -DTESTDATADIR=/path/to/checkoutdir/test.


  -- Checking for module 'nss>=3.49'
  --   No package 'nss' found
  -- Could NOT find NSS3 (missing: NSS3_LIBRARIES NSS3_CFLAGS)
  CMake Warning at cmake/modules/MacroOptionalFindPackage.cmake:32 
(find_package):
By not providing "FindGpgmepp.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "Gpgmepp", but
CMake did not find one.

Could not find a package configuration file provided by "Gpgmepp"
(requested version 1.19) with any of the following names:

  GpgmeppConfig.cmake
  gpgmepp-config.cmake

Add the installation prefix of "Gpgmepp" to CMAKE_PREFIX_PATH or set
"Gpgmepp_DIR" to a directory containing one of the above files.  If
"Gpgmepp" provides a separate development package or SDK, be sure it has
been installed.
  Call Stack (most recent call first):
CMakeLists.txt:158 (macro_optional_find_package)

  
  CMake Warning at CMakeLists.txt:198 (find_package):
By not providing "FindQt5Core.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "Qt5Core", but
CMake did not find one.

Could not find a package configuration file provided by "Qt5Core"
(requested version 5.12) with any of the following names:

  Qt5CoreConfig.cmake
  qt5core-config.cmake

Add the installation prefix of "Qt5Core" to CMAKE_PREFIX_PATH or set
"Qt5Core_DIR" to a directory containing one of the above files.  If
"Qt5Core" provides a separate development package or SDK, be sure it has
been installed.

  
  CMake Warning at CMakeLists.txt:199 (find_package):
By not providing "FindQt5Gui.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "Qt5Gui", but
CMake did not find one.

Could not find a package configuration file provided by "Qt5Gui" with any
of the following names:

  Qt5GuiConfig.cmake
  qt5gui-config.cmake

Add the installation prefix of "Qt5Gui" to CMAKE_PREFIX_PATH or set
"Qt5Gui_DIR" to a directory containing one of the above files.  If "Qt5Gui"
provides a separate development package or SDK, be sure it has been
installed.

  
  CMake Warning at CMakeLists.txt:200 (find_package):
By not providing "FindQt5Xml.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "Qt5Xml", but
CMake did not find one.

Could not find a package configuration file provided by "Qt5Xml" with any
of the following names:

  Qt5XmlConfig.cmake
  qt5xml-config.cmake

Add the installation prefix of "Qt5Xml" to CMAKE_PREFIX_PATH or set
"Qt5Xml_DIR" to a directory containing one of the above files.  If "Qt5Xml"
provides a separate development package or SDK, be sure it has been
installed.

  
  CMake Warning at CMakeLists.txt:201 (find_package):
By not providing "FindQt5Widgets.cmake" in CMAKE_MODULE_PATH this project
has asked CMake to find a package configuration file provided by
"Qt5Widgets", but CMake did not find one.

Could not find a package configuration file provided by "Qt5Widgets" with
any of the following names:

  Qt5WidgetsConfig.cmake
  qt5widgets-config.cmake

Add the installation prefix of "Qt5Widgets" to CMAKE_PREFIX_PATH or set
"Qt5Widgets_DIR" to a directory

[Touch-packages] [Bug 2037907] Re: No package 'nss' found

2023-10-02 Thread Clark

Where can I find help?

The old bug report is no longer maintained
https://bugs.freedesktop.org/buglist.cgi?product=poppler

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

Title:
  No package 'nss' found

Status in poppler package in Ubuntu:
  Invalid

Bug description:
  Have installed poppler on several systems, but experience issues in
  some cases.

  All the dependencies should be installed!

  Distro: Debian Bullseye 11

  
  # apt-get install libopenjp2-7-dev libfreetype6-dev libfontconfig1-dev 
libjpeg-dev libtiff5-dev
  # cd /var/bin && wget https://poppler.freedesktop.org/poppler-23.09.0.tar.xz 
&& tar -xvf poppler-23.09.0.tar.xz
  # cd poppler-23.09.0 && mkdir build && cd build
  # cmake ..

  
  CMake Warning at CMakeLists.txt:95 (message):

  
 No test data found in $testdatadir.
 You will not be able to run 'make test' successfully.


 The test data is not included in the source packages
 and is also not part of the main git repository. Instead,
 you can checkout the test data from its own git
 repository with:


   git clone git://git.freedesktop.org/git/poppler/test


 You should checkout the test data as a sibling of your
 poppler source folder or specify the location of your
 checkout with -DTESTDATADIR=/path/to/checkoutdir/test.


  -- Checking for module 'nss>=3.49'
  --   No package 'nss' found
  -- Could NOT find NSS3 (missing: NSS3_LIBRARIES NSS3_CFLAGS)
  CMake Warning at cmake/modules/MacroOptionalFindPackage.cmake:32 
(find_package):
By not providing "FindGpgmepp.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "Gpgmepp", but
CMake did not find one.

Could not find a package configuration file provided by "Gpgmepp"
(requested version 1.19) with any of the following names:

  GpgmeppConfig.cmake
  gpgmepp-config.cmake

Add the installation prefix of "Gpgmepp" to CMAKE_PREFIX_PATH or set
"Gpgmepp_DIR" to a directory containing one of the above files.  If
"Gpgmepp" provides a separate development package or SDK, be sure it has
been installed.
  Call Stack (most recent call first):
CMakeLists.txt:158 (macro_optional_find_package)

  
  CMake Warning at CMakeLists.txt:198 (find_package):
By not providing "FindQt5Core.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "Qt5Core", but
CMake did not find one.

Could not find a package configuration file provided by "Qt5Core"
(requested version 5.12) with any of the following names:

  Qt5CoreConfig.cmake
  qt5core-config.cmake

Add the installation prefix of "Qt5Core" to CMAKE_PREFIX_PATH or set
"Qt5Core_DIR" to a directory containing one of the above files.  If
"Qt5Core" provides a separate development package or SDK, be sure it has
been installed.

  
  CMake Warning at CMakeLists.txt:199 (find_package):
By not providing "FindQt5Gui.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "Qt5Gui", but
CMake did not find one.

Could not find a package configuration file provided by "Qt5Gui" with any
of the following names:

  Qt5GuiConfig.cmake
  qt5gui-config.cmake

Add the installation prefix of "Qt5Gui" to CMAKE_PREFIX_PATH or set
"Qt5Gui_DIR" to a directory containing one of the above files.  If "Qt5Gui"
provides a separate development package or SDK, be sure it has been
installed.

  
  CMake Warning at CMakeLists.txt:200 (find_package):
By not providing "FindQt5Xml.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "Qt5Xml", but
CMake did not find one.

Could not find a package configuration file provided by "Qt5Xml" with any
of the following names:

  Qt5XmlConfig.cmake
  qt5xml-config.cmake

Add the installation prefix of "Qt5Xml" to CMAKE_PREFIX_PATH or set
"Qt5Xml_DIR" to a directory containing one of the above files.  If "Qt5Xml"
provides a separate development package or SDK, be sure it has been
installed.

  
  CMake Warning at CMakeLists.txt:201 (find_package):
By not providing "FindQt5Widgets.cmake" in CMAKE_MODULE_PATH this project
has asked CMake to find a package configuration file provided by
"Qt5Widgets", but CMake did not find one.

Could not find a package configuration file provided by "Qt5Widgets" with
any of the following names:

  Qt5WidgetsConfig.cmake
  qt5widgets-config.cmake

Add the installation prefix of "Qt5Widgets" to CMAKE_PREFIX_PATH or set
"Qt5Widgets_DIR" to a directory containing one of the above files.  If
"Qt5Widgets" provides a separate development package or SDK, be sure it has
been installed.

[Touch-packages] [Bug 2037703] Re: dpkg-reconfigure openssh-server doesn't ask questions again

2023-10-02 Thread Thomas Bechtold

Ok. Thanks for clarification. With that I think we can continue to get
https://code.launchpad.net/~toabctl/livecd-rootfs/+git/livecd-
rootfs-1/+merge/452352 merged.

But I still find this behavior confusing/buggy. I can still use
"debconf-show openssh-server" and see the password-authentication entry.
And that entry is out-of-sync with the real configuration. That's a bug
imo given that the behavior is not documented in README.Debian.gz .

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

Title:
  dpkg-reconfigure openssh-server doesn't ask questions again

Status in openssh package in Ubuntu:
  New

Bug description:
  openssh-server does provide a couple of configuration options:

  [~]$ sudo debconf-get-selections |grep openssh-server
  openssh-serveropenssh-server/listenstream-may-failerror   
  openssh-serveropenssh-server/password-authentication  boolean true
  openssh-serveropenssh-server/permit-root-loginboolean true

  
  I want to change those options now interactively but nothing I tried worked 
and showed a dialog:

  [~]$ sudo dpkg-reconfigure -p low openssh-server  
  Warning: Stopping ssh.service, but it can still be activated by:
ssh.socket
  rescue-ssh.target is a disabled or a static unit not running, not starting it.

  [~]$ sudo dpkg-reconfigure -p low --force --frontend dialog openssh-server
  Warning: Stopping ssh.service, but it can still be activated by:
ssh.socket
  rescue-ssh.target is a disabled or a static unit not running, not starting it.


  But the documentation (https://manpages.debian.org/testing/debconf-
  doc/debconf.7.en.html#Reconfiguring_packages) does state that those
  commands should ask those questions again.

  
  p.s. also tried with a lxc debian-sid container and had the same problem 
there.

  ProblemType: Bug
  DistroRelease: Ubuntu 23.10
  Package: openssh-server 1:9.3p1-1ubuntu3
  ProcVersionSignature: Ubuntu 6.5.0-5.5-generic 6.5.0
  Uname: Linux 6.5.0-5-generic x86_64
  NonfreeKernelModules: zfs
  ApportVersion: 2.27.0-0ubuntu2
  Architecture: amd64
  CasperMD5CheckResult: unknown
  CurrentDesktop: ubuntu:GNOME
  Date: Fri Sep 29 10:35:33 2023
  InstallationDate: Installed on 2023-05-10 (142 days ago)
  InstallationMedia: Ubuntu 23.04 "Lunar Lobster" - Release amd64 (20230418)
  ProcEnviron:
   LANG=en_US.UTF-8
   PATH=(custom, no user)
   SHELL=/usr/bin/zsh
   TERM=xterm-256color
   XDG_RUNTIME_DIR=
  SourcePackage: openssh
  UpgradeStatus: Upgraded to mantic on 2023-07-19 (71 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/2037703/+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 2037965] Re: [Demo][Experimental] My brightness hotkey doesn't work on some PC

2023-10-02 Thread Shih-Yuan Lee

** Patch added: "systemd_249.11-0ubuntu3.12.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2037965/+attachment/5705848/+files/systemd_249.11-0ubuntu3.12.debdiff

** Package changed: systemd (Ubuntu) => null-and-void

** Summary changed:

- [Demo][Experimental] My brightness hotkey doesn't work on some PC
+ null

** Description changed:

- hwdb lacks of the map for my brightness hotkey.
+ null

-- 
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/2037965

Title:
  null

Status in NULL Project:
  New

Bug description:
  null

To manage notifications about this bug go to:
https://bugs.launchpad.net/null-and-void/+bug/2037965/+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 2037965] [NEW] null

2023-10-02 Thread Shih-Yuan Lee

Public bug reported:

null

** Affects: null-and-void
 Importance: Undecided
 Status: New

** Summary changed:

- My brightness hotkey doesn't work on some PC
+ [Demo][Experimental] My brightness hotkey doesn't work on some PC

-- 
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/2037965

Title:
  null

Status in NULL Project:
  New

Bug description:
  null

To manage notifications about this bug go to:
https://bugs.launchpad.net/null-and-void/+bug/2037965/+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 2033597] Re: System theme messed up for no apparent reason

** Bug watch added: github.com/ubuntu/yaru/issues #3977
   https://github.com/ubuntu/yaru/issues/3977

** Also affects: yaru via
   https://github.com/ubuntu/yaru/issues/3977
   Importance: Unknown
   Status: Unknown

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

Title:
  System theme messed up for no apparent reason

Status in Yaru Theme:
  Unknown
Status in gtk+3.0 package in Ubuntu:
  New
Status in gtk4 package in Ubuntu:
  New
Status in yaru-theme package in Ubuntu:
  New

Bug description:
  Was browsing the web when all of a sudden all icons changed and system
  theme now looks like a blast from the past.

  Specifically:
  - "Home" icon on the desktop
  - Trash, disk icons on the app drawer
  - Icons and buttons on the "Restart required" msgbox, and its topbar icon 
(next to wifi)
  - Folder icons in Files (nautilus) window

  ProblemType: Bug
  DistroRelease: Ubuntu 23.10
  Package: nautilus 1:45~beta2-1ubuntu1
  ProcVersionSignature: Ubuntu 6.3.0-7.7-generic 6.3.5
  Uname: Linux 6.3.0-7-generic x86_64
  ApportVersion: 2.27.0-0ubuntu2
  Architecture: amd64
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Aug 31 02:32:02 2023
  GsettingsChanges: b'org.gnome.nautilus.preferences' b'migrated-gtk-settings' 
b'true'
  InstallationDate: Installed on 2023-08-26 (5 days ago)
  InstallationMedia: Ubuntu 23.10 "Mantic Minotaur" - Daily amd64 (20230825)
  ProcEnviron:
   LANG=en_US.UTF-8
   PATH=(custom, no user)
   SHELL=/bin/bash
   XDG_RUNTIME_DIR=
  RebootRequiredPkgs: Error: path contained symlinks.
  SourcePackage: nautilus
  UpgradeStatus: No upgrade log present (probably fresh install)
  usr_lib_nautilus: nautilus-extension-gnome-terminal 3.49.92-2ubuntu1

To manage notifications about this bug go to:
https://bugs.launchpad.net/yaru/+bug/2033597/+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 2036149] Re: BlueZ release 5.70