[Touch-packages] [Bug 1978988] Re: [USB-Audio - USB Audio, recording] Recording problem
I found a issue for ALC4080 audio chip: - https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/1337 - https://github.com/alsa-project/alsa-ucm-conf/pull/143 But, Ubuntu 22.04 use alsaucm and pipewire by default?, remember in this version use Wayland & pipewire enabled by default. I try apply manualy the changes but does not work: $ git clone https://github.com/alsa-project/alsa-ucm-conf; $ rsync -tvrz --delete --links alsa-ucm-conf/ucm/ /usr/share/alsa/ucm/; $ rsync -tvrz --delete --links alsa-ucm-conf/ucm2/ /usr/share/alsa/ucm2/; $ reboot The hardware id is in usb settings but does not work, i have spent many days researching in many forums and reading many alsa and pulse manuals without any apparent solution and I don't know what exactly the problem could be: https://www.linuxquestions.org/questions/showthread.php?p=6361785 ** Bug watch added: gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues #1337 https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/1337 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to alsa-driver in Ubuntu. https://bugs.launchpad.net/bugs/1978988 Title: [USB-Audio - USB Audio, recording] Recording problem Status in alsa-driver package in Ubuntu: New Bug description: My Motherboard is MSI X570S and output audio works fine but: - Motherboard microphone plug is not work. - Frontal microphone plug is not work. - When change output from gnome settings to hdmi audio does not work, the audio continues to play in the plug and not in the monitor. - When I change the input or output from digital to analog or sinput it does not change at all. - The strangest thing is that the microphone input captures the audio that is heard in the system as if it were the output, audacious records the audio from the desktop when it tries to monitor the microphone. - When plugging or unplugging the microphone, the system detects this change and tries to change the audio input automatically, but it does not capture the microphone and the desktop continues to be heard. My alsa data: http://alsa- project.org/db/?f=df4d1f6c126260eabc5f159e64cff37efa064a38 MSI have not audio drivers for linux. I can't stream with this motherboard because the microphone doesn't work. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: alsa-base 1.0.25+dfsg-0ubuntu7 ProcVersionSignature: Ubuntu 5.15.0-39.42-generic 5.15.35 Uname: Linux 5.15.0-39-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC1: whk1940 F pulseaudio /dev/snd/pcmC1D0c: whk1940 F...m pulseaudio /dev/snd/pcmC1D0p: whk1940 F...m pulseaudio /dev/snd/controlC0: whk1940 F pulseaudio CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Thu Jun 16 13:13:20 2022 InstallationDate: Installed on 2022-06-13 (2 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) PackageArchitecture: all SourcePackage: alsa-driver Symptom: audio Symptom_AlsaRecordingTest: ALSA recording test through plughw:Audio failed Symptom_Card: HDA-Intel - HD-Audio Generic Symptom_Type: Only some of inputs are working Title: [USB-Audio - USB Audio, recording] Recording problem UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 05/19/2022 dmi.bios.release: 5.17 dmi.bios.vendor: American Megatrends International, LLC. dmi.bios.version: 1.31 dmi.board.asset.tag: To be filled by O.E.M. dmi.board.name: MPG X570S EDGE MAX WIFI (MS-7D53) dmi.board.vendor: Micro-Star International Co., Ltd. dmi.board.version: 1.0 dmi.chassis.asset.tag: To be filled by O.E.M. dmi.chassis.type: 3 dmi.chassis.vendor: Micro-Star International Co., Ltd. dmi.chassis.version: 1.0 dmi.modalias: dmi:bvnAmericanMegatrendsInternational,LLC.:bvr1.31:bd05/19/2022:br5.17:svnMicro-StarInternationalCo.,Ltd.:pnMS-7D53:pvr1.0:rvnMicro-StarInternationalCo.,Ltd.:rnMPGX570SEDGEMAXWIFI(MS-7D53):rvr1.0:cvnMicro-StarInternationalCo.,Ltd.:ct3:cvr1.0:skuTobefilledbyO.E.M.: dmi.product.family: To be filled by O.E.M. dmi.product.name: MS-7D53 dmi.product.sku: To be filled by O.E.M. dmi.product.version: 1.0 dmi.sys.vendor: Micro-Star International Co., Ltd. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1978988/+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 1977645] Re: python3-gpg 1.16.0-unknown version is incomparable, dependencies always fail
** Summary changed: - python3-gpg "1.16.0-unknown" version is incomparable -> dependencies always fail + python3-gpg 1.16.0-unknown version is incomparable, dependencies always fail ** Bug watch added: Debian Bug tracker #1004742 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004742 ** Also affects: gpgme1.0 (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004742 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gpgme1.0 in Ubuntu. https://bugs.launchpad.net/bugs/1977645 Title: python3-gpg 1.16.0-unknown version is incomparable, dependencies always fail Status in gpgme1.0 package in Ubuntu: Confirmed Status in gpgme1.0 package in Debian: Unknown Bug description: The python version of the gpgme version contains "unknown" and is therefore not PEP440 order compatible. See this example: # pip3 freeze | grep gpg gpg===1.16.0-unknown # pip3 install pstore ... Successfully installed gpg-1.10.0 Successfully installed pstore-2.0.0 # pip3 freeze | grep gpg gpg==1.10.0 Key takeways from that example: - pstore depends on gpg>=1.10 - 1.16 SHOULD be higher than 1.10 - pip installs 1.10 even though 1.16 exists - the triple-= (gpg===1.16.0-unknown) means that the version exists, but cannot be version compared: https://peps.python.org/pep-0440/#arbitrary-equality Suggested fix: - replace the '-' from `gpgme-config --version` "1.16.0-unknown" with a '+'; that will compare as expected; - fix so "-unknown" isn't appended. Apparently, this is caused by insufficient fixes in 0001-avoid-identifying-as-beta.patch I've attached a FIXED version, which should fix things. Before: $ autoreconf -ivf $ grep Generated.*gpgme configure # Generated by GNU Autoconf 2.71 for gpgme 1.16.0-unknown. After: $ quilt push Applying patch 0001-avoid-identifying-as-beta-FIXED.patch $ autoreconf -ivf $ grep Generated.*gpgme configure # Generated by GNU Autoconf 2.71 for gpgme 1.16.0. Versions: $ lsb_release -a 2>/dev/null| grep Codename Codename: jammy $ apt-cache policy python3-gpg | grep Installed Installed: 1.16.0-1.2ubuntu4 Cheers, Walter Doekes OSSO B.V. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gpgme1.0/+bug/1977645/+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 1979096] Re: X.org or Gnome-shell
** Package changed: ubuntu => xorg (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1979096 Title: X.org or Gnome-shell Status in xorg package in Ubuntu: New Bug description: The problem happens, when I enable the dock to hide automatically. With this enabled, it is not possible to run the programs through the search. But when disabled, it is possible to search and run the programs. Here's the video of the problem. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: xorg 1:7.7+23ubuntu2 ProcVersionSignature: Ubuntu 5.15.0-39.42-generic 5.15.35 Uname: Linux 5.15.0-39-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 BootLog: Error: [Errno 13] Permissão negada: '/var/log/boot.log' CasperMD5CheckResult: unknown CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Fri Jun 17 18:21:45 2022 DistUpgraded: 2022-04-21 13:52:59,951 DEBUG Running PostInstallScript: '/usr/lib/ubuntu-advantage/upgrade_lts_contract.py' DistroCodename: jammy DistroVariant: ubuntu DkmsStatus: v4l2loopback/0.12.5, 5.15.0-37-generic, x86_64: installed v4l2loopback/0.12.5, 5.15.0-39-generic, x86_64: installed ExtraDebuggingInterest: I just need to know a workaround GraphicsCard: Advanced Micro Devices, Inc. [AMD/ATI] RS780L [Radeon 3000] [1002:9616] (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. RS780L [Radeon 3000] [1043:8388] InstallationDate: Installed on 2021-04-15 (428 days ago) InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 (20210209.1) MachineType: System manufacturer System Product Name ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-39-generic root=UUID=7e3c483e-6d02-4fc2-be0e-48207eb147eb ro quiet splash vt.handoff=7 SourcePackage: xorg Symptom: display UpgradeStatus: Upgraded to jammy on 2022-04-21 (57 days ago) dmi.bios.date: 03/04/2017 dmi.bios.release: 8.15 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 1201 dmi.board.asset.tag: To Be Filled By O.E.M. dmi.board.name: M5A78L-M LX/BR dmi.board.vendor: ASUSTeK Computer INC. dmi.board.version: Rev X.0x dmi.chassis.asset.tag: Asset-1234567890 dmi.chassis.type: 3 dmi.chassis.vendor: Chassis Manufacture dmi.chassis.version: Chassis Version dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr1201:bd03/04/2017:br8.15:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKComputerINC.:rnM5A78L-MLX/BR:rvrRevX.0x:cvnChassisManufacture:ct3:cvrChassisVersion:skuToBeFilledByO.E.M.: dmi.product.family: To Be Filled By O.E.M. dmi.product.name: System Product Name dmi.product.sku: To Be Filled By O.E.M. dmi.product.version: System Version dmi.sys.vendor: System manufacturer version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.110-1ubuntu1 version.libgl1-mesa-dri: libgl1-mesa-dri 22.0.1-1ubuntu2.1 version.libgl1-mesa-glx: libgl1-mesa-glx 22.0.1-1ubuntu2.1 version.xserver-xorg-core: xserver-xorg-core 2:21.1.3-2ubuntu2 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-2build3 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20210115-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.17-2build1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1979096/+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 1979096] [NEW] X.org or Gnome-shell
You have been subscribed to a public bug: The problem happens, when I enable the dock to hide automatically. With this enabled, it is not possible to run the programs through the search. But when disabled, it is possible to search and run the programs. Here's the video of the problem. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: xorg 1:7.7+23ubuntu2 ProcVersionSignature: Ubuntu 5.15.0-39.42-generic 5.15.35 Uname: Linux 5.15.0-39-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 BootLog: Error: [Errno 13] Permissão negada: '/var/log/boot.log' CasperMD5CheckResult: unknown CompositorRunning: None CurrentDesktop: ubuntu:GNOME Date: Fri Jun 17 18:21:45 2022 DistUpgraded: 2022-04-21 13:52:59,951 DEBUG Running PostInstallScript: '/usr/lib/ubuntu-advantage/upgrade_lts_contract.py' DistroCodename: jammy DistroVariant: ubuntu DkmsStatus: v4l2loopback/0.12.5, 5.15.0-37-generic, x86_64: installed v4l2loopback/0.12.5, 5.15.0-39-generic, x86_64: installed ExtraDebuggingInterest: I just need to know a workaround GraphicsCard: Advanced Micro Devices, Inc. [AMD/ATI] RS780L [Radeon 3000] [1002:9616] (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. RS780L [Radeon 3000] [1043:8388] InstallationDate: Installed on 2021-04-15 (428 days ago) InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 (20210209.1) MachineType: System manufacturer System Product Name ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-39-generic root=UUID=7e3c483e-6d02-4fc2-be0e-48207eb147eb ro quiet splash vt.handoff=7 SourcePackage: xorg Symptom: display UpgradeStatus: Upgraded to jammy on 2022-04-21 (57 days ago) dmi.bios.date: 03/04/2017 dmi.bios.release: 8.15 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 1201 dmi.board.asset.tag: To Be Filled By O.E.M. dmi.board.name: M5A78L-M LX/BR dmi.board.vendor: ASUSTeK Computer INC. dmi.board.version: Rev X.0x dmi.chassis.asset.tag: Asset-1234567890 dmi.chassis.type: 3 dmi.chassis.vendor: Chassis Manufacture dmi.chassis.version: Chassis Version dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr1201:bd03/04/2017:br8.15:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKComputerINC.:rnM5A78L-MLX/BR:rvrRevX.0x:cvnChassisManufacture:ct3:cvrChassisVersion:skuToBeFilledByO.E.M.: dmi.product.family: To Be Filled By O.E.M. dmi.product.name: System Product Name dmi.product.sku: To Be Filled By O.E.M. dmi.product.version: System Version dmi.sys.vendor: System manufacturer version.compiz: compiz N/A version.libdrm2: libdrm2 2.4.110-1ubuntu1 version.libgl1-mesa-dri: libgl1-mesa-dri 22.0.1-1ubuntu2.1 version.libgl1-mesa-glx: libgl1-mesa-glx 22.0.1-1ubuntu2.1 version.xserver-xorg-core: xserver-xorg-core 2:21.1.3-2ubuntu2 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-2build3 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20210115-1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.17-2build1 ** Affects: xorg (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug jammy ubuntu -- X.org or Gnome-shell https://bugs.launchpad.net/bugs/1979096 You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xorg 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 1979098] [NEW] detached ua key and and attached back, now on extensive security maintenance until 31/12/9999
Public bug reported: I have detached Ubuntu Advantage key and attached again, to make livepatch work. When I realized the updates tab changed to Extensive Security Maintenance until 31/12/ (essentially until Y10K) I tried re-opening the app, didn't work. Restarted the PC, didn't work. A partial upgrade, didn't work. I have a screenshot, it has been attached. Ubuntu Release: 22.04 Version of software-properties-gtk: 0.99.22.2 What I expected to happen: Livepatch working again, on the free subscription of LTS until 2027. What happened instead: Somehow got support until 31/12/ (again, Y10K.) ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: software-properties-gtk 0.99.22.2 ProcVersionSignature: Ubuntu 5.15.0-40.43-generic 5.15.35 Uname: Linux 5.15.0-40-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Fri Jun 17 19:03:59 2022 InstallationDate: Installed on 2022-06-14 (2 days ago) InstallationMedia: Ubuntu 20.04.4 LTS "Focal Fossa" - Release amd64 (20220223) PackageArchitecture: all ProcEnviron: LANGUAGE=pt_BR:pt:en PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=pt_BR.UTF-8 SHELL=/bin/bash SourcePackage: software-properties UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: software-properties (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug jammy wayland-session ** Attachment added: "screenshot of 31/12/" https://bugs.launchpad.net/bugs/1979098/+attachment/5598072/+files/Captura%20de%20tela%20de%202022-06-17%2019-12-37.png -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to software-properties in Ubuntu. https://bugs.launchpad.net/bugs/1979098 Title: detached ua key and and attached back, now on extensive security maintenance until 31/12/ Status in software-properties package in Ubuntu: New Bug description: I have detached Ubuntu Advantage key and attached again, to make livepatch work. When I realized the updates tab changed to Extensive Security Maintenance until 31/12/ (essentially until Y10K) I tried re-opening the app, didn't work. Restarted the PC, didn't work. A partial upgrade, didn't work. I have a screenshot, it has been attached. Ubuntu Release: 22.04 Version of software-properties-gtk: 0.99.22.2 What I expected to happen: Livepatch working again, on the free subscription of LTS until 2027. What happened instead: Somehow got support until 31/12/ (again, Y10K.) ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: software-properties-gtk 0.99.22.2 ProcVersionSignature: Ubuntu 5.15.0-40.43-generic 5.15.35 Uname: Linux 5.15.0-40-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Fri Jun 17 19:03:59 2022 InstallationDate: Installed on 2022-06-14 (2 days ago) InstallationMedia: Ubuntu 20.04.4 LTS "Focal Fossa" - Release amd64 (20220223) PackageArchitecture: all ProcEnviron: LANGUAGE=pt_BR:pt:en PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=pt_BR.UTF-8 SHELL=/bin/bash SourcePackage: software-properties UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1979098/+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 1970634] Re: FTBFS: mariadb fails to start due to low MEMLOCK limit
** Changed in: systemd (Ubuntu Jammy) Status: In Progress => New ** Changed in: systemd (Ubuntu Jammy) Assignee: Andreas Hasenack (ahasenack) => (unassigned) ** Changed in: mariadb-10.6 (Ubuntu Jammy) Status: Triaged => In Progress ** Description changed: [Impact] Jammy's MariaDB will fail to build, and also fail to start, if the underlying kernel is 5.4.x (focal's) and if it's running in an unprivileged container (lxd, docker). It will also fail to build in launchpad builders. Common scenarios where this combination exists is a focal host, running an unprivileged jammy container (lxd or docker), or even a chroot (the launchpad builders). Jammy's MariaDB was built with io_uring support, and it tries to enable it at runtime if it deems it's running on a supported kernel. There is a range of kernel versions it checks, but of interest for this SRU, the Focal (5.4.x) kernel is inside this range and io_uring will be enabled. The jammy kernel (5.15) is not, so io_uring will not be enabled there, and thus the bug is not manifested in that case. If io_uring is enabled, a higher MEMLOCK limit is required than what is set by default in focal or jammy (64Mb is what we get, 256Mb or more is required). The systemd unit file for mariadb tries to raise this limit, but in an unprivileged container this won't work. MariaDB has checks in place to catch when MEMLOCK is too low, in which case it will not use io_uring, but these checks are failing because of the LTO build flags that were used in the jammy build of mariadb. It's unclear if it's a bug in gcc or something else. There is more information in comment #1, comment #5 and later. The suggested fix here is to disable LTO for the jammy build. This has been done for kinetic already, and is also applied to the debian packaging (inside a distro-specific conditional). [Test Plan] The test plan is to launch mariadb in a jammy lxd container running on a focal host. lxc launch ubuntu:focal f --vm lxc shell lxd init # just hit enter for all questions lxc launch ubuntu:jammy j lxc shell j ulimit -l # confirm it's less than 256 apt update && apt install mariadb-server -y After the installation, mariadb will not be running, and this can be checked with: - systemctl status mariadb-server + systemctl status mariadb.service or journalctl -u mariadb.server You will see something like this: Jun 17 18:32:01 jammy-mariadb systemd[1]: Starting MariaDB 10.6.7 database server... Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] /usr/sbin/mariadbd (server 10.6.7-MariaDB-2ubuntu1) starting as process 1864 ... Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] InnoDB: The first data file './ibdata1' did not exist. A new tablespace will be created! Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] InnoDB: Compressed tables use zlib 1.2.11 Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] InnoDB: Using transactional memory Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] InnoDB: Number of pools: 1 Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Warning] mariadbd: io_uring_queue_init() failed with ENOMEM: try larger memory locked limit, ulimit -l, or https://mariadb.com/kb/en/systemd/#configuring-limitmemlock under systemd (262144 bytes required) Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 220617 18:32:01 [ERROR] mysqld got signal 6 ; And a crash dump. With the fixed version, the service will be running normally after installation. [Where problems could occur] The proposed fix is not a surgical strike. It's unfortunate that we didn't get to the bottom of why LTO is causing this behavior. Reverting it is still the quickest and less risky change at the moment, though. This gets us on par with upstream binary builds, and debian builds, and these also have wide test coverage and ample user base. The other regression possibility is that this is a rebuild of mariadb in the current jammy environment, and the package that is currently in jammy was built on March 10th, 2022. Most likely the reverse dependencies were updated in jammy since then. It's unclear how 10.6.7-2ubuntu1 migrated in jammy. I checked build logs and dep8 logs, and can't tell why the tests passed. At least the build log in jammy shows the host kernel was 5.4.x, so it should have been affected. My only explanation is that at that time, the MEMLOCK limit was higher in that environment for some reason, and didn't trigger this bug. Then at some point later, launchpad builders changed, and MEMLOCK was reduced to 64Mb.
[Touch-packages] [Bug 1117222] Re: autopkgtest test cases for libestr
This bug was fixed in the package libestr - 0.1.11-1 --- libestr (0.1.11-1) unstable; urgency=medium * New maintainer (Closes: #1010434) - redo packaging from scratch, following current best practices - reintroduce autopkgtest from #700293 which was silently dropped in 0.1.10-1, but adjust it for cross-compilation (LP: #1117222) * New upstream release (Closes: #912419) -- Florian Ernst Sun, 05 Jun 2022 08:15:55 +0200 ** Changed in: libestr (Ubuntu) Status: Triaged => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libestr in Ubuntu. https://bugs.launchpad.net/bugs/1117222 Title: autopkgtest test cases for libestr Status in libestr package in Ubuntu: Fix Released Status in libestr package in Debian: Fix Released Bug description: The DEP 8 specification defines how automatic testing can very easily be integrated into packages. I have created test cases for libestr and attached them as a debdiff. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libestr/+bug/1117222/+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 1977627] Re: New upstream microrelease 2.5.12
** Changed in: openldap (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1977627 Title: New upstream microrelease 2.5.12 Status in openldap package in Ubuntu: Invalid Status in openldap source package in Jammy: Fix Committed Bug description: [ Impact ] * MRE for the latest stable OpenLDAP 2.5.x release, 2.5.12. This update includes bugfixes only following the SRU policy exception defined at https://wiki.ubuntu.com/OpenLDAPUpdates. [ Major Changes ] * See the list of bugs fixed in this release here: https://lists.openldap.org/hyperkitty/list/openldap- annou...@openldap.org/thread/LSEQKADYZFFMZJGPEVBRR3OVOY4IOGRA/ * In particular, this release includes the fix for CVE-2022-29155, but since the CVE has already been addressed by the currently OpenLDAP version in Jammy (2.5.11+dfsg-1~exp1ubuntu3.1), this does not classify as a security upload. [ Test Plan ] * Upstream gitlab pipeline results: https://git.openldap.org/openldap/openldap/-/pipelines/4298 * Upstream "call for testing": https://lists.openldap.org/hyperkitty/list/openldap- techni...@openldap.org/thread/5ZJEOQSVFQBG5TRLAAF6S5M3VRJH5IAV/ * As described in the MRE wiki page for OpenLDAP, the test plan is to build the package in bileto and make sure that (1) all build-time tests pass and (2) all autopkgtest runs (from reverse dependencies) also pass. * Build log (amd64) confirming that the build-time testsuite has been performed and completed successfully: https://launchpadlibrarian.net/606922528/buildlog_ubuntu-jammy- amd64.openldap_2.5.12+dfsg-0ubuntu0.22.04.1_BUILDING.txt.gz * Bileto ticket: https://bileto.ubuntu.com/#/ticket/4868 [ Where problems could occur ] * Upstream tests are always executed during build-time. There are many reverse dependencies whose dep8 tests depend on OpenLDAP so the coverage is good. Nevertheless, there is always a risk for something to break since we are dealing with a microrelease upgrade. Whenever a test failure is detected, we will be on top of it and make sure it doesn't affect existing users. [ Other Info ] * This is a reoccurring MRE. See below for links to previous OpenLDAP MREs. * CVEs fixed by this release: - CVE-2022-29155, which has already been addressed in Jammy. Current versions in supported releases that got updates: openldap | 2.5.11+dfsg-1~exp1ubuntu3.1 | jammy-updates | source Special cases: - None. Previous MREs for OpenLDAP: - None so far. As usual we test and prep from the PPA and then push through SRU/Security as applicable. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1977627/+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 1854237] Re: autopkgtests fail after security fixes
** Changed in: apport Status: New => Fix Released -- 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/1854237 Title: autopkgtests fail after security fixes Status in Apport: Fix Released Status in apport package in Ubuntu: Fix Released Status in apport source package in Xenial: Fix Released Status in apport source package in Bionic: Fix Released Status in apport source package in Disco: Won't Fix Status in apport source package in Eoan: Fix Released Bug description: The following autopkgtests fail after the recent security fixes: log:FAIL: test_get_logind_session (__main__.T) log:FAIL: test_core_dump_packaged (__main__.T) log:FAIL: test_core_dump_unpackaged (__main__.T) log:FAIL: test_crash_setuid_drop (__main__.T) log:FAIL: test_crash_setuid_keep (__main__.T) log:FAIL: test_crash_setuid_nonwritable_cwd (__main__.T) log:FAIL: test_lock_symlink (__main__.T) test_get_logind_session is a test failing to keep up with an API change. test_core_dump_* is failures to remove partly written core files. Both of these are easy fixes, I'll have a MP for them soon. test_crash_setuid_* are caused by the dropping of privileges when accessing the crashing process's /proc. They seem to be testing behaviour now explicitly forbidden by the fix to be honest! test_lock_symlink fails because the lock file is now always in /var/lock/apport/ and not in $APPORT_REPORT_DIR. I guess we could update the test, but is it really worth it after the fix? To manage notifications about this bug go to: https://bugs.launchpad.net/apport/+bug/1854237/+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 1970634] Re: FTBFS: mariadb fails to start due to low MEMLOCK limit
** Merge proposal linked: https://code.launchpad.net/~ahasenack/ubuntu/+source/mariadb-10.6/+git/mariadb-10.6/+merge/424986 -- 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/1970634 Title: FTBFS: mariadb fails to start due to low MEMLOCK limit Status in mariadb-10.6 package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Confirmed Status in mariadb-10.6 source package in Jammy: Triaged Status in systemd source package in Jammy: In Progress Bug description: [Impact] Jammy's MariaDB will fail to build, and also fail to start, if the underlying kernel is 5.4.x (focal's) and if it's running in an unprivileged container (lxd, docker). It will also fail to build in launchpad builders. Common scenarios where this combination exists is a focal host, running an unprivileged jammy container (lxd or docker), or even a chroot (the launchpad builders). Jammy's MariaDB was built with io_uring support, and it tries to enable it at runtime if it deems it's running on a supported kernel. There is a range of kernel versions it checks, but of interest for this SRU, the Focal (5.4.x) kernel is inside this range and io_uring will be enabled. The jammy kernel (5.15) is not, so io_uring will not be enabled there, and thus the bug is not manifested in that case. If io_uring is enabled, a higher MEMLOCK limit is required than what is set by default in focal or jammy (64Mb is what we get, 256Mb or more is required). The systemd unit file for mariadb tries to raise this limit, but in an unprivileged container this won't work. MariaDB has checks in place to catch when MEMLOCK is too low, in which case it will not use io_uring, but these checks are failing because of the LTO build flags that were used in the jammy build of mariadb. It's unclear if it's a bug in gcc or something else. There is more information in comment #1, comment #5 and later. The suggested fix here is to disable LTO for the jammy build. This has been done for kinetic already, and is also applied to the debian packaging (inside a distro-specific conditional). [Test Plan] The test plan is to launch mariadb in a jammy lxd container running on a focal host. lxc launch ubuntu:focal f --vm lxc shell lxd init # just hit enter for all questions lxc launch ubuntu:jammy j lxc shell j ulimit -l # confirm it's less than 256 apt update && apt install mariadb-server -y After the installation, mariadb will not be running, and this can be checked with: systemctl status mariadb-server or journalctl -u mariadb.server You will see something like this: Jun 17 18:32:01 jammy-mariadb systemd[1]: Starting MariaDB 10.6.7 database server... Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] /usr/sbin/mariadbd (server 10.6.7-MariaDB-2ubuntu1) starting as process 1864 ... Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] InnoDB: The first data file './ibdata1' did not exist. A new tablespace will be created! Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] InnoDB: Compressed tables use zlib 1.2.11 Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] InnoDB: Using transactional memory Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] InnoDB: Number of pools: 1 Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Warning] mariadbd: io_uring_queue_init() failed with ENOMEM: try larger memory locked limit, ulimit -l, or https://mariadb.com/kb/en/systemd/#configuring-limitmemlock under systemd (262144 bytes required) Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 220617 18:32:01 [ERROR] mysqld got signal 6 ; And a crash dump. With the fixed version, the service will be running normally after installation. [Where problems could occur] The proposed fix is not a surgical strike. It's unfortunate that we didn't get to the bottom of why LTO is causing this behavior. Reverting it is still the quickest and less risky change at the moment, though. This gets us on par with upstream binary builds, and debian builds, and these also have wide test coverage and ample user base. The other regression possibility is that this is a rebuild of mariadb in the current jammy environment, and the package that is currently in jammy was built on March 10th, 2022. Most likely the reverse dependencies were updated in jammy since then. It's unclear how 10.6.7-2ubuntu1 migrated in jammy. I checked build logs and dep8 logs, and can't tell why the tests passed. At least the build log in jammy shows the host kernel was 5.4.x, so it should have been affected. My
[Touch-packages] [Bug 1970634] Re: FTBFS: mariadb fails to start due to low MEMLOCK limit
** Description changed: [Impact] Jammy's MariaDB will fail to build, and also fail to start, if the underlying kernel is 5.4.x (focal's) and if it's running in an unprivileged container (lxd, docker). It will also fail to build in launchpad builders. Common scenarios where this combination exists is a focal host, running an unprivileged jammy container (lxd or docker), or even a chroot (the launchpad builders). Jammy's MariaDB was built with io_uring support, and it tries to enable it at runtime if it deems it's running on a supported kernel. There is a range of kernel versions it checks, but of interest for this SRU, the Focal (5.4.x) kernel is inside this range and io_uring will be enabled. The jammy kernel (5.15) is not, so io_uring will not be enabled there, and thus the bug is not manifested in that case. If io_uring is enabled, a higher MEMLOCK limit is required than what is set by default in focal or jammy (64Mb is what we get, 256Mb or more is required). The systemd unit file for mariadb tries to raise this limit, but in an unprivileged container this won't work. MariaDB has checks in place to catch when MEMLOCK is too low, in which case it will not use io_uring, but these checks are failing because of the LTO build flags that were used in the jammy build of mariadb. It's unclear if it's a bug in gcc or something else. There is more information in comment #1, comment #5 and later. The suggested fix here is to disable LTO for the jammy build. This has been done for kinetic already, and is also applied to the debian packaging (inside a distro-specific conditional). [Test Plan] The test plan is to launch mariadb in a jammy lxd container running on a focal host. lxc launch ubuntu:focal f --vm lxc shell lxd init # just hit enter for all questions lxc launch ubuntu:jammy j lxc shell j ulimit -l # confirm it's less than 256 apt update && apt install mariadb-server -y After the installation, mariadb will not be running, and this can be checked with: systemctl status mariadb-server or journalctl -u mariadb.server You will see something like this: Jun 17 18:32:01 jammy-mariadb systemd[1]: Starting MariaDB 10.6.7 database server... Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] /usr/sbin/mariadbd (server 10.6.7-MariaDB-2ubuntu1) starting as process 1864 ... Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] InnoDB: The first data file './ibdata1' did not exist. A new tablespace will be created! Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] InnoDB: Compressed tables use zlib 1.2.11 Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] InnoDB: Using transactional memory Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] InnoDB: Number of pools: 1 Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 2022-06-17 18:32:01 0 [Warning] mariadbd: io_uring_queue_init() failed with ENOMEM: try larger memory locked limit, ulimit -l, or https://mariadb.com/kb/en/systemd/#configuring-limitmemlock under systemd (262144 bytes required) Jun 17 18:32:01 jammy-mariadb mariadbd[1864]: 220617 18:32:01 [ERROR] mysqld got signal 6 ; And a crash dump. With the fixed version, the service will be running normally after installation. [Where problems could occur] + The proposed fix is not a surgical strike. It's unfortunate that we didn't get to the bottom of why LTO is causing this behavior. Reverting it is still the quickest and less risky change at the moment, though. This gets us on par with upstream binary builds, and debian builds, and these also have wide test coverage and ample user base. - * Think about what the upload changes in the software. Imagine the change is - wrong or breaks something else: how would this show up? + The other regression possibility is that this is a rebuild of mariadb in + the current jammy environment, and the package that is currently in + jammy was built on March 10th, 2022. Most likely the reverse + dependencies were updated in jammy since then. - * It is assumed that any SRU candidate patch is well-tested before - upload and has a low overall risk of regression, but it's important - to make the effort to think about what ''could'' happen in the - event of a regression. + It's unclear how 10.6.7-2ubuntu1 migrated in jammy. I checked build logs + and dep8 logs, and can't tell why the tests passed. At least the build + log in jammy shows the host kernel was 5.4.x, so it should have been + affected. My only explanation is that at that time, the MEMLOCK limit + was higher in that environment for some reason, and didn't trigger this + bug. Then at some point later,
[Touch-packages] [Bug 1972159] Re: systemd-oomd frequently kills firefox and visual studio code
> This is also occuring on Ubuntu Server on VPS. Did you install/enable systemd-oomd manually? AFAIK, systemd-oomd is not enabled by default on server. Or is something else killing your programs? > swap file is far from full. If it is systemd-oomd, do you have logs from this (journalctl -u systemd-oomd)? -- 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/1972159 Title: systemd-oomd frequently kills firefox and visual studio code Status in systemd package in Ubuntu: Confirmed Status in systemd source package in Kinetic: Confirmed Status in systemd package in Fedora: Unknown Bug description: Since I installed Ubuntu 22.04, firefox and visual studio code are frequently killed by systemd-oomd (every 2hours). I have 8 GB memory and never experienced this before the upgrade to Ubuntu 22.04. I thus assume that the claim that there is not enough memory is abusive. Did 64GB of memory become the minimum requirement to run Ubuntu ? The second problem is that it gives a very bad user experience which is critical for new Ubuntu users. There should be a warning prior killing apps to give the opportunity to save the app data. There should at least be an apologize and an explanation after killing the app. The current behavior gives the impression that Ubuntu 22.04 is unreliable and unsafe to use which is a problem for an LTS release that many people might want to use for critical production context. There might be a configuration problem with systemd-oomd or simply a bogus behavior. I would recommend to disable it or remove it completely until this problem is resolved. This is what I will do for myself because I have work to do. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1972159/+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 1970634] Re: FTBFS: mariadb fails to start due to low MEMLOCK limit
** Description changed: [Impact] - * An explanation of the effects of the bug on users and + Jammy's MariaDB was built with io_uring support, and it tries to enable + it at runtime if it deems it's running on a supported kernel. There is a + range of kernel versions it checks, but of interest for this SRU, the + Focal (5.4.x) kernel is inside this range and io_uring will be enabled. + The jammy kernel (5.15) is not, so io_uring will not be enabled there. - * justification for backporting the fix to the stable release. + Common scenarios where this combination exists is a focal host, running + a jammy container (lxd or docker), or even a chroot (the launchpad + builders). - * In addition, it is helpful, but not required, to include an -explanation of how the upload fixes this bug. + If io_uring is enabled, a higher MEMLOCK limit is required than what is + set by default in focal or jammy (64Mb is what we get, 256Mb or more is + required). + + The systemd unit file for mariadb tries to raise this limit, but in an + unprivileged container, or a root-less chroot, this won't work. + + MariaDB has checks in place to catch when MEMLOCK is too low, in which + case it will not use io_uring, but these checks are failing because of + the LTO build flags that were used in the jammy build of mariadb. It's + unclear if it's a bug in gcc. There is more information in comment #1, + comment #5 and later. + + The suggested fix here is to disable LTO for the jammy build. This has + been done for kinetic already, and is also applied to the debian + packaging (inside a distro-specific conditional). + [Test Plan] - * detailed instructions how to reproduce the bug + * detailed instructions how to reproduce the bug - * these should allow someone who is not familiar with the affected -package to reproduce the bug and verify that the updated package fixes -the problem. + * these should allow someone who is not familiar with the affected + package to reproduce the bug and verify that the updated package fixes + the problem. - * if other testing is appropriate to perform before landing this update, -this should also be described here. + * if other testing is appropriate to perform before landing this update, + this should also be described here. [Where problems could occur] - * Think about what the upload changes in the software. Imagine the change is -wrong or breaks something else: how would this show up? + * Think about what the upload changes in the software. Imagine the change is + wrong or breaks something else: how would this show up? - * It is assumed that any SRU candidate patch is well-tested before -upload and has a low overall risk of regression, but it's important -to make the effort to think about what ''could'' happen in the -event of a regression. + * It is assumed that any SRU candidate patch is well-tested before + upload and has a low overall risk of regression, but it's important + to make the effort to think about what ''could'' happen in the + event of a regression. - * This must '''never''' be "None" or "Low", or entirely an argument as to why -your upload is low risk. + * This must '''never''' be "None" or "Low", or entirely an argument as to why + your upload is low risk. - * This both shows the SRU team that the risks have been considered, -and provides guidance to testers in regression-testing the SRU. + * This both shows the SRU team that the risks have been considered, + and provides guidance to testers in regression-testing the SRU. [Other Info] - - * Anything else you think is useful to include - * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board - * and address these questions in advance + * Anything else you think is useful to include + * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board + * and address these questions in advance [Original Description] ahasenack: IIRC, originally Launchpad was FTBFSing on mariadb that included io_uring support because upstream were doing a build time test for io_uring (and I think still are), which is wrong because it should be done at runtime since the lack of io_uring availablity at build time doesn't tell us about its availablity at runtime. But then the Launchpad builders got updated to a newer release and therefore a newer kernel that supported it. AIUI, that's how we ended up with a successful build in the Jammy release pocket (of 10.6). I think the lp builders are using the focal hwe kernel 5.4.0-something let me check that build log But then something changed that caused this current FTBFS, and I haven't tracked down what that is. hm, both are 10.6.7 release and proposed What puzzles me is that if the root cause is a memlock rlimit issue then why did it work before? So since
[Touch-packages] [Bug 1970634] Re: FTBFS: mariadb fails to start due to low MEMLOCK limit
** Description changed: + [Impact] + + * An explanation of the effects of the bug on users and + + * justification for backporting the fix to the stable release. + + * In addition, it is helpful, but not required, to include an +explanation of how the upload fixes this bug. + + [Test Plan] + + * detailed instructions how to reproduce the bug + + * these should allow someone who is not familiar with the affected +package to reproduce the bug and verify that the updated package fixes +the problem. + + * if other testing is appropriate to perform before landing this update, +this should also be described here. + + [Where problems could occur] + + * Think about what the upload changes in the software. Imagine the change is +wrong or breaks something else: how would this show up? + + * It is assumed that any SRU candidate patch is well-tested before +upload and has a low overall risk of regression, but it's important +to make the effort to think about what ''could'' happen in the +event of a regression. + + * This must '''never''' be "None" or "Low", or entirely an argument as to why +your upload is low risk. + + * This both shows the SRU team that the risks have been considered, +and provides guidance to testers in regression-testing the SRU. + + [Other Info] + + * Anything else you think is useful to include + * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board + * and address these questions in advance + + + [Original Description] + ahasenack: IIRC, originally Launchpad was FTBFSing on mariadb that included io_uring support because upstream were doing a build time test for io_uring (and I think still are), which is wrong because it should be done at runtime since the lack of io_uring availablity at build time doesn't tell us about its availablity at runtime. But then the Launchpad builders got updated to a newer release and therefore a newer kernel that supported it. AIUI, that's how we ended up with a successful build in the Jammy release pocket (of 10.6). I think the lp builders are using the focal hwe kernel 5.4.0-something let me check that build log But then something changed that caused this current FTBFS, and I haven't tracked down what that is. hm, both are 10.6.7 release and proposed What puzzles me is that if the root cause is a memlock rlimit issue then why did it work before? So since there's a contradiction somewhere, maybe one or more of my "facts" above is wrong. this is the current failure 2022-04-14 8:11:49 0 [Warning] mariadbd: io_uring_queue_init() failed with ENOMEM: try larger memory locked limit, ulimit -l, or https://mariadb.com/kb/en/systemd/#configuring-limitmemlock under systemd (262144 bytes required) and ulimit -l confirms that the limit is lower - Max locked memory 6553665536 bytes + Max locked memory 6553665536 bytes just 64kbytes Yeah but then how did the release pocket build work? either the limit was different back then or ... stuff -- 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/1970634 Title: FTBFS: mariadb fails to start due to low MEMLOCK limit Status in mariadb-10.6 package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Confirmed Status in mariadb-10.6 source package in Jammy: Triaged Status in systemd source package in Jammy: In Progress Bug description: [Impact] * An explanation of the effects of the bug on users and * justification for backporting the fix to the stable release. * In addition, it is helpful, but not required, to include an explanation of how the upload fixes this bug. [Test Plan] * detailed instructions how to reproduce the bug * these should allow someone who is not familiar with the affected package to reproduce the bug and verify that the updated package fixes the problem. * if other testing is appropriate to perform before landing this update, this should also be described here. [Where problems could occur] * Think about what the upload changes in the software. Imagine the change is wrong or breaks something else: how would this show up? * It is assumed that any SRU candidate patch is well-tested before upload and has a low overall risk of regression, but it's important to make the effort to think about what ''could'' happen in the event of a regression. * This must '''never''' be "None" or "Low", or entirely an argument as to why your upload is low risk. * This both shows the SRU team that the risks have been considered, and provides guidance to testers in regression-testing the SRU. [Other Info] * Anything else you think is
[Touch-packages] [Bug 1970634] Re: FTBFS: mariadb fails to start due to low MEMLOCK limit
Ok, phew, my test was incorrect, the bug is present in jammy. That makes this SRU simpler. I'll proceed with it, without a block-proposed tag. -- 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/1970634 Title: FTBFS: mariadb fails to start due to low MEMLOCK limit Status in mariadb-10.6 package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Confirmed Status in mariadb-10.6 source package in Jammy: Triaged Status in systemd source package in Jammy: In Progress Bug description: [Impact] * An explanation of the effects of the bug on users and * justification for backporting the fix to the stable release. * In addition, it is helpful, but not required, to include an explanation of how the upload fixes this bug. [Test Plan] * detailed instructions how to reproduce the bug * these should allow someone who is not familiar with the affected package to reproduce the bug and verify that the updated package fixes the problem. * if other testing is appropriate to perform before landing this update, this should also be described here. [Where problems could occur] * Think about what the upload changes in the software. Imagine the change is wrong or breaks something else: how would this show up? * It is assumed that any SRU candidate patch is well-tested before upload and has a low overall risk of regression, but it's important to make the effort to think about what ''could'' happen in the event of a regression. * This must '''never''' be "None" or "Low", or entirely an argument as to why your upload is low risk. * This both shows the SRU team that the risks have been considered, and provides guidance to testers in regression-testing the SRU. [Other Info] * Anything else you think is useful to include * Anticipate questions from users, SRU, +1 maintenance, security teams and the Technical Board * and address these questions in advance [Original Description] ahasenack: IIRC, originally Launchpad was FTBFSing on mariadb that included io_uring support because upstream were doing a build time test for io_uring (and I think still are), which is wrong because it should be done at runtime since the lack of io_uring availablity at build time doesn't tell us about its availablity at runtime. But then the Launchpad builders got updated to a newer release and therefore a newer kernel that supported it. AIUI, that's how we ended up with a successful build in the Jammy release pocket (of 10.6). I think the lp builders are using the focal hwe kernel 5.4.0-something let me check that build log But then something changed that caused this current FTBFS, and I haven't tracked down what that is. hm, both are 10.6.7 release and proposed What puzzles me is that if the root cause is a memlock rlimit issue then why did it work before? So since there's a contradiction somewhere, maybe one or more of my "facts" above is wrong. this is the current failure 2022-04-14 8:11:49 0 [Warning] mariadbd: io_uring_queue_init() failed with ENOMEM: try larger memory locked limit, ulimit -l, or https://mariadb.com/kb/en/systemd/#configuring-limitmemlock under systemd (262144 bytes required) and ulimit -l confirms that the limit is lower Max locked memory 6553665536 bytes just 64kbytes Yeah but then how did the release pocket build work? either the limit was different back then or ... stuff To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mariadb-10.6/+bug/1970634/+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 1972159] Re: systemd-oomd frequently kills firefox and visual studio code
This is also occuring on Ubuntu Server on VPS. I have 7x Ubuntu 22.04 VPSses with 1 GB physical RAM and a 3GB swap file. The programs I'm running get killed which stops production even though the swap file is far from full. -- 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/1972159 Title: systemd-oomd frequently kills firefox and visual studio code Status in systemd package in Ubuntu: Confirmed Status in systemd source package in Kinetic: Confirmed Status in systemd package in Fedora: Unknown Bug description: Since I installed Ubuntu 22.04, firefox and visual studio code are frequently killed by systemd-oomd (every 2hours). I have 8 GB memory and never experienced this before the upgrade to Ubuntu 22.04. I thus assume that the claim that there is not enough memory is abusive. Did 64GB of memory become the minimum requirement to run Ubuntu ? The second problem is that it gives a very bad user experience which is critical for new Ubuntu users. There should be a warning prior killing apps to give the opportunity to save the app data. There should at least be an apologize and an explanation after killing the app. The current behavior gives the impression that Ubuntu 22.04 is unreliable and unsafe to use which is a problem for an LTS release that many people might want to use for critical production context. There might be a configuration problem with systemd-oomd or simply a bogus behavior. I would recommend to disable it or remove it completely until this problem is resolved. This is what I will do for myself because I have work to do. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1972159/+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 1970634] Re: FTBFS: mariadb fails to start due to low MEMLOCK limit
I got a report on IRC that the existing jammy package of mariadb does exhibit this problem: (link will expire soon) https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_bd5/839585/23/check/kolla-ansible-ubuntu-source/bd5a051/primary/logs/kolla/mariadb/mariadb.txt: """ 2022-06-15 12:38:03 0 [Warning] mariadbd: io_uring_queue_init() failed with ENOMEM: try larger memory locked limit, ulimit -l, or https://mariadb.com/kb/en/systemd/#configuring-limitmemlock under systemd (262144 bytes required) 220615 12:38:03 [ERROR] mysqld got signal 6 ; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. To report this bug, see https://mariadb.com/kb/en/reporting-bugs We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. Server version: 10.6.7-MariaDB-2ubuntu1-log key_buffer_size=67108864 read_buffer_size=131072 max_used_connections=0 max_threads=10002 thread_count=0 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 22090304 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. (...) """ The scenario is very similar to the lxd testing I've been using to confirm the bug. Above it's a docker container running mariadb from jammy, on a focal host. The docker image was built with just pulling in mariadb from jammy, without rebuilding it, so it's the same binary as published. I probably made a mistake in my testing with the jammy package just now. I'll repeat it and inspect it more carefully. -- 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/1970634 Title: FTBFS: mariadb fails to start due to low MEMLOCK limit Status in mariadb-10.6 package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Confirmed Status in mariadb-10.6 source package in Jammy: Triaged Status in systemd source package in Jammy: In Progress Bug description: ahasenack: IIRC, originally Launchpad was FTBFSing on mariadb that included io_uring support because upstream were doing a build time test for io_uring (and I think still are), which is wrong because it should be done at runtime since the lack of io_uring availablity at build time doesn't tell us about its availablity at runtime. But then the Launchpad builders got updated to a newer release and therefore a newer kernel that supported it. AIUI, that's how we ended up with a successful build in the Jammy release pocket (of 10.6). I think the lp builders are using the focal hwe kernel 5.4.0-something let me check that build log But then something changed that caused this current FTBFS, and I haven't tracked down what that is. hm, both are 10.6.7 release and proposed What puzzles me is that if the root cause is a memlock rlimit issue then why did it work before? So since there's a contradiction somewhere, maybe one or more of my "facts" above is wrong. this is the current failure 2022-04-14 8:11:49 0 [Warning] mariadbd: io_uring_queue_init() failed with ENOMEM: try larger memory locked limit, ulimit -l, or https://mariadb.com/kb/en/systemd/#configuring-limitmemlock under systemd (262144 bytes required) and ulimit -l confirms that the limit is lower Max locked memory 6553665536 bytes just 64kbytes Yeah but then how did the release pocket build work? either the limit was different back then or ... stuff To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mariadb-10.6/+bug/1970634/+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 1864215] Re: Please add webp loader to gdk-pixbuf
webp-pixbuf-loader was just packaged for Ubuntu 22.10 (which will be released in October). If you install that package, you can open webp files in eog, etc. ** Package changed: gdk-pixbuf (Ubuntu) => webp-pixbuf-loader (Ubuntu) ** Changed in: webp-pixbuf-loader (Ubuntu) Status: Confirmed => Fix Released ** Package changed: debian => webp-pixbuf-loader (Debian) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gdk-pixbuf in Ubuntu. https://bugs.launchpad.net/bugs/1864215 Title: Please add webp loader to gdk-pixbuf Status in gdk-pixbuf: Fix Released Status in webp-pixbuf-loader package in Ubuntu: Fix Released Status in gdk-pixbuf package in Baltix: Triaged Status in webp-pixbuf-loader package in Debian: New Bug description: Attempting to load a webp image -- for instance, https://images.theweek.com/sites/default/files/styles/tw_image_9_4/public/FKK78W.jpg.webp or https://cdn.vox-cdn.com/thumbor/2YtWB5zH7sPycyc0FYv3JSB6SFw=/60x0:1140x720/920x613/filters:focal(60x0:1140x720):format(webp)/cdn.vox-cdn.com/uploads/chorus_image/image/49663815/timburton.0.0.jpg -- in a gdk-pixbuf app results in a "Couldn’t recognize the image file format" error. Bug 1318327 covers this issue in eye of gnome, and bug 1407644 in libwebp, but isn't this really a gdk-pixbuf issue? If it really does belong to libwebp, my apologies, please dup this bug to 1407644 (I'm confident it doesn't belong to eog since I don't use that program; I have other programs that use libgdk-pixbuf). You can probably use eog to test this, or run /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders | grep -i webp (I assume the loader would mention webp if there was a loader for it). I have these packages installed in addition to libgdk-pixbuf2.0-0: libwebp-dev libwebp6 libwebpdemux2 libwebpmux3 webp. file recognizes the format: $ file /tmp/FKK78W.jpg.webp /tmp/FKK78W.jpg.webp: RIFF (little-endian) data, Web/P image, VP8 encoding, 1200x533, Scaling: [none]x[none], YUV color, decoders should clamp ProblemType: Bug DistroRelease: Ubuntu 19.10 Package: libgdk-pixbuf2.0-0 2.40.0+dfsg-1build1 ProcVersionSignature: Ubuntu 5.3.0-40.32-generic 5.3.18 Uname: Linux 5.3.0-40-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu8.4 Architecture: amd64 Date: Fri Feb 21 08:48:36 2020 InstallationDate: Installed on 2019-10-10 (133 days ago) InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Beta amd64 (20190926.1) SourcePackage: gdk-pixbuf UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/gdk-pixbuf/+bug/1864215/+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 1979079] Re: Can print to (brother) driverless printer only using aa-complain cupsd
Please could you post the lines containing "audit", "DENIED", and "cupsd" or "cups-browsed" which are in your /var/log/syslog and/or your journal here? Try to find especially the messages which appear when you print a job until you get the error message "No suitable Destination Host found by cups-browsed". Can you print in AppArmor's complain mode? Switch to complain mode with sudo aa-complain cupsd sudo aa-complain cups-browsed and back to the default enforce mode sudo aa-enforce cupsd sudo aa-enforce cups-browsed Please try at first to only put cupsd into complain mode, after that only cups-browsed, and after that both. With which of these settings are you able to print and with which not? ** Changed in: cups (Ubuntu) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1979079 Title: Can print to (brother) driverless printer only using aa-complain cupsd Status in cups package in Ubuntu: Incomplete Bug description: The apparmor configuration for cupsd is incorrect and makes it impossible to print to driverless printers (at least to the brother printer I am trying). Cups cannot obtain the IP address of the printer. You get "No suitable Destination Host found by cups-browsed" There are multiple reports of this issue on the network, also wrt debian. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: cups-daemon 2.4.1op1-1ubuntu4.1 ProcVersionSignature: Ubuntu 5.15.0-39.42-generic 5.15.35 Uname: Linux 5.15.0-39-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: KDE Date: Fri Jun 17 18:19:32 2022 EcryptfsInUse: Yes InstallationDate: Installed on 2020-02-16 (852 days ago) InstallationMedia: Kubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017) MachineType: SCHENKER SCHENKER_SLIM14_SSL14L19 Papersize: a4 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-39-generic root=/dev/mapper/VG_NVMe-root ro quiet splash vt.handoff=7 SourcePackage: cups UpgradeStatus: Upgraded to jammy on 2022-06-03 (14 days ago) dmi.bios.date: 10/02/2019 dmi.bios.release: 7.4 dmi.bios.vendor: INSYDE Corp. dmi.bios.version: 1.07.04RTR1 dmi.board.asset.tag: Tag 12345 dmi.board.name: N141CU dmi.board.vendor: SCHENKER dmi.board.version: Not Applicable dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: Notebook dmi.chassis.version: N/A dmi.ec.firmware.release: 7.2 dmi.modalias: dmi:bvnINSYDECorp.:bvr1.07.04RTR1:bd10/02/2019:br7.4:efr7.2:svnSCHENKER:pnSCHENKER_SLIM14_SSL14L19:pvrNotApplicable:rvnSCHENKER:rnN141CU:rvrNotApplicable:cvnNotebook:ct10:cvrN/A:skuNotApplicable: dmi.product.family: Not Applicable dmi.product.name: SCHENKER_SLIM14_SSL14L19 dmi.product.sku: Not Applicable dmi.product.version: Not Applicable dmi.sys.vendor: SCHENKER To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1979079/+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 1969896] Re: Evince Document Viewer(42.0) does not remember last page in 22.04 and opens in a tiny window when launched
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: evince (Ubuntu Jammy) Status: New => Confirmed -- 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/1969896 Title: Evince Document Viewer(42.0) does not remember last page in 22.04 and opens in a tiny window when launched Status in apparmor package in Ubuntu: In Progress Status in evince package in Ubuntu: In Progress Status in apparmor source package in Jammy: In Progress Status in evince source package in Jammy: Confirmed Status in apparmor source package in Kinetic: In Progress Status in evince source package in Kinetic: In Progress Bug description: Just switched from Ubuntu 20.04 to 22.04 and realized that Document Viewer no longer open on the last viewed page and doesn't remember the side pane preference even after using the "Save Current Settings as Default" option. Kindly advise ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: evince 42.1-3 ProcVersionSignature: Ubuntu 5.15.0-25.25-generic 5.15.30 Uname: Linux 5.15.0-25-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu82 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Fri Apr 22 15:58:50 2022 InstallationDate: Installed on 2022-03-19 (34 days ago) InstallationMedia: Ubuntu 20.04.4 LTS "Focal Fossa" - Release amd64 (20220223) ProcEnviron: PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: evince UpgradeStatus: Upgraded to jammy on 2022-04-21 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1969896/+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 1979079] [NEW] Can print to (brother) driverless printer only using aa-complain cupsd
Public bug reported: The apparmor configuration for cupsd is incorrect and makes it impossible to print to driverless printers (at least to the brother printer I am trying). Cups cannot obtain the IP address of the printer. You get "No suitable Destination Host found by cups-browsed" There are multiple reports of this issue on the network, also wrt debian. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: cups-daemon 2.4.1op1-1ubuntu4.1 ProcVersionSignature: Ubuntu 5.15.0-39.42-generic 5.15.35 Uname: Linux 5.15.0-39-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: KDE Date: Fri Jun 17 18:19:32 2022 EcryptfsInUse: Yes InstallationDate: Installed on 2020-02-16 (852 days ago) InstallationMedia: Kubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017) MachineType: SCHENKER SCHENKER_SLIM14_SSL14L19 Papersize: a4 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-39-generic root=/dev/mapper/VG_NVMe-root ro quiet splash vt.handoff=7 SourcePackage: cups UpgradeStatus: Upgraded to jammy on 2022-06-03 (14 days ago) dmi.bios.date: 10/02/2019 dmi.bios.release: 7.4 dmi.bios.vendor: INSYDE Corp. dmi.bios.version: 1.07.04RTR1 dmi.board.asset.tag: Tag 12345 dmi.board.name: N141CU dmi.board.vendor: SCHENKER dmi.board.version: Not Applicable dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: Notebook dmi.chassis.version: N/A dmi.ec.firmware.release: 7.2 dmi.modalias: dmi:bvnINSYDECorp.:bvr1.07.04RTR1:bd10/02/2019:br7.4:efr7.2:svnSCHENKER:pnSCHENKER_SLIM14_SSL14L19:pvrNotApplicable:rvnSCHENKER:rnN141CU:rvrNotApplicable:cvnNotebook:ct10:cvrN/A:skuNotApplicable: dmi.product.family: Not Applicable dmi.product.name: SCHENKER_SLIM14_SSL14L19 dmi.product.sku: Not Applicable dmi.product.version: Not Applicable dmi.sys.vendor: SCHENKER ** Affects: cups (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug jammy -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1979079 Title: Can print to (brother) driverless printer only using aa-complain cupsd Status in cups package in Ubuntu: New Bug description: The apparmor configuration for cupsd is incorrect and makes it impossible to print to driverless printers (at least to the brother printer I am trying). Cups cannot obtain the IP address of the printer. You get "No suitable Destination Host found by cups-browsed" There are multiple reports of this issue on the network, also wrt debian. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: cups-daemon 2.4.1op1-1ubuntu4.1 ProcVersionSignature: Ubuntu 5.15.0-39.42-generic 5.15.35 Uname: Linux 5.15.0-39-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: KDE Date: Fri Jun 17 18:19:32 2022 EcryptfsInUse: Yes InstallationDate: Installed on 2020-02-16 (852 days ago) InstallationMedia: Kubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017) MachineType: SCHENKER SCHENKER_SLIM14_SSL14L19 Papersize: a4 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.15.0-39-generic root=/dev/mapper/VG_NVMe-root ro quiet splash vt.handoff=7 SourcePackage: cups UpgradeStatus: Upgraded to jammy on 2022-06-03 (14 days ago) dmi.bios.date: 10/02/2019 dmi.bios.release: 7.4 dmi.bios.vendor: INSYDE Corp. dmi.bios.version: 1.07.04RTR1 dmi.board.asset.tag: Tag 12345 dmi.board.name: N141CU dmi.board.vendor: SCHENKER dmi.board.version: Not Applicable dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: Notebook dmi.chassis.version: N/A dmi.ec.firmware.release: 7.2 dmi.modalias: dmi:bvnINSYDECorp.:bvr1.07.04RTR1:bd10/02/2019:br7.4:efr7.2:svnSCHENKER:pnSCHENKER_SLIM14_SSL14L19:pvrNotApplicable:rvnSCHENKER:rnN141CU:rvrNotApplicable:cvnNotebook:ct10:cvrN/A:skuNotApplicable: dmi.product.family: Not Applicable dmi.product.name: SCHENKER_SLIM14_SSL14L19 dmi.product.sku: Not Applicable dmi.product.version: Not Applicable dmi.sys.vendor: SCHENKER To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1979079/+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 1979066] Re: BUG: kernel NULL pointer dereference, address: 0000000000000300
** Package changed: ubuntu => xorg (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1979066 Title: BUG: kernel NULL pointer dereference, address: 0300 Status in xorg package in Ubuntu: New Bug description: Recently I experienced the issue that after dis- and reconnecting my monitor (Philips 346B1C) with USB-Hub, my laptop (Lenovo E480) did not accept any inputs (mouse or keyboard, neither), while the display looked OK. I was able to access the laptop using SSH and found following backtrace in dmesg: [18890.250253] pcieport :00:1d.2: AER: Corrected error received: :00:1d.2 [18890.250286] pcieport :00:1d.2: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID) [18890.250293] pcieport :00:1d.2: device [8086:9d1a] error status/mask=0001/2000 [18890.250300] pcieport :00:1d.2:[ 0] RxErr [18923.193928] pcieport :00:1d.2: AER: Corrected error received: :00:1d.2 [18923.193941] pcieport :00:1d.2: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID) [18923.193944] pcieport :00:1d.2: device [8086:9d1a] error status/mask=0001/2000 [18923.193948] pcieport :00:1d.2:[ 0] RxErr [18929.192524] pcieport :00:1d.2: AER: Corrected error received: :00:1d.2 [18929.192547] pcieport :00:1d.2: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID) [18929.192554] pcieport :00:1d.2: device [8086:9d1a] error status/mask=0001/2000 [18929.192561] pcieport :00:1d.2:[ 0] RxErr [18941.195429] pcieport :00:1d.2: AER: Corrected error received: :00:1d.2 [18941.195440] pcieport :00:1d.2: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID) [18941.195446] pcieport :00:1d.2: device [8086:9d1a] error status/mask=0001/2000 [18941.195450] pcieport :00:1d.2:[ 0] RxErr [18965.194123] pcieport :00:1d.2: AER: Corrected error received: :00:1d.2 [18965.194132] pcieport :00:1d.2: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID) [18965.194134] pcieport :00:1d.2: device [8086:9d1a] error status/mask=0001/2000 [18965.194136] pcieport :00:1d.2:[ 0] RxErr [18983.192431] pcieport :00:1d.2: AER: Multiple Corrected error received: :00:1d.2 [18983.192471] pcieport :00:1d.2: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Transmitter ID) [18983.192478] pcieport :00:1d.2: device [8086:9d1a] error status/mask=1001/2000 [18983.192487] pcieport :00:1d.2:[ 0] RxErr [18983.192494] pcieport :00:1d.2:[12] Timeout [18989.194543] pcieport :00:1d.2: AER: Corrected error received: :00:1d.2 [18989.194574] pcieport :00:1d.2: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID) [18989.194581] pcieport :00:1d.2: device [8086:9d1a] error status/mask=0001/2000 [18989.194588] pcieport :00:1d.2:[ 0] RxErr [19001.195887] pcieport :00:1d.2: AER: Corrected error received: :00:1d.2 [19001.195914] pcieport :00:1d.2: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID) [19001.195919] pcieport :00:1d.2: device [8086:9d1a] error status/mask=0001/2000 [19001.195926] pcieport :00:1d.2:[ 0] RxErr [19005.947848] pcieport :00:1d.2: AER: Corrected error received: :00:1d.2 [19005.947872] pcieport :00:1d.2: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID) [19005.947878] pcieport :00:1d.2: device [8086:9d1a] error status/mask=0001/2000 [19005.947886] pcieport :00:1d.2:[ 0] RxErr [19007.194477] pcieport :00:1d.2: AER: Corrected error received: :00:1d.2 [19007.194505] pcieport :00:1d.2: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID) [19007.194509] pcieport :00:1d.2: device [8086:9d1a] error status/mask=0001/2000 [19007.194514] pcieport :00:1d.2:[ 0] RxErr [19024.985336] usb 1-2: USB disconnect, device number 38 [19024.985359] usb 1-2.1: USB disconnect, device number 39 [19024.985370] usb 1-2.1.1: USB disconnect, device number 40 [19025.030357] r8152 2-2.2:1.0 enx186571e521da: Stop submitting intr, status -71 [19025.049481] usb 1-2.1.2: USB disconnect, device number 41 [19025.151593] usb 1-2.1.4: USB disconnect, device number 42 [19025.276446] usb 2-2.1: Port disable: can't disable remote wake [19025.555856] r8152 2-2.2:1.0 enx186571e521da: Tx status -71 [19025.735918] usb 1-2: new high-speed USB device number 43 using xhci_hcd [19025.770499] usb 2-2: USB disconnect, device number 5 [19025.770513] usb 2-2.1: USB disconnect, device number 6 [19025.771766] usb 2-2.2: USB disconnect, device
[Touch-packages] [Bug 1979066] [NEW] BUG: kernel NULL pointer dereference, address: 0000000000000300
You have been subscribed to a public bug: Recently I experienced the issue that after dis- and reconnecting my monitor (Philips 346B1C) with USB-Hub, my laptop (Lenovo E480) did not accept any inputs (mouse or keyboard, neither), while the display looked OK. I was able to access the laptop using SSH and found following backtrace in dmesg: [18890.250253] pcieport :00:1d.2: AER: Corrected error received: :00:1d.2 [18890.250286] pcieport :00:1d.2: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID) [18890.250293] pcieport :00:1d.2: device [8086:9d1a] error status/mask=0001/2000 [18890.250300] pcieport :00:1d.2:[ 0] RxErr [18923.193928] pcieport :00:1d.2: AER: Corrected error received: :00:1d.2 [18923.193941] pcieport :00:1d.2: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID) [18923.193944] pcieport :00:1d.2: device [8086:9d1a] error status/mask=0001/2000 [18923.193948] pcieport :00:1d.2:[ 0] RxErr [18929.192524] pcieport :00:1d.2: AER: Corrected error received: :00:1d.2 [18929.192547] pcieport :00:1d.2: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID) [18929.192554] pcieport :00:1d.2: device [8086:9d1a] error status/mask=0001/2000 [18929.192561] pcieport :00:1d.2:[ 0] RxErr [18941.195429] pcieport :00:1d.2: AER: Corrected error received: :00:1d.2 [18941.195440] pcieport :00:1d.2: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID) [18941.195446] pcieport :00:1d.2: device [8086:9d1a] error status/mask=0001/2000 [18941.195450] pcieport :00:1d.2:[ 0] RxErr [18965.194123] pcieport :00:1d.2: AER: Corrected error received: :00:1d.2 [18965.194132] pcieport :00:1d.2: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID) [18965.194134] pcieport :00:1d.2: device [8086:9d1a] error status/mask=0001/2000 [18965.194136] pcieport :00:1d.2:[ 0] RxErr [18983.192431] pcieport :00:1d.2: AER: Multiple Corrected error received: :00:1d.2 [18983.192471] pcieport :00:1d.2: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Transmitter ID) [18983.192478] pcieport :00:1d.2: device [8086:9d1a] error status/mask=1001/2000 [18983.192487] pcieport :00:1d.2:[ 0] RxErr [18983.192494] pcieport :00:1d.2:[12] Timeout [18989.194543] pcieport :00:1d.2: AER: Corrected error received: :00:1d.2 [18989.194574] pcieport :00:1d.2: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID) [18989.194581] pcieport :00:1d.2: device [8086:9d1a] error status/mask=0001/2000 [18989.194588] pcieport :00:1d.2:[ 0] RxErr [19001.195887] pcieport :00:1d.2: AER: Corrected error received: :00:1d.2 [19001.195914] pcieport :00:1d.2: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID) [19001.195919] pcieport :00:1d.2: device [8086:9d1a] error status/mask=0001/2000 [19001.195926] pcieport :00:1d.2:[ 0] RxErr [19005.947848] pcieport :00:1d.2: AER: Corrected error received: :00:1d.2 [19005.947872] pcieport :00:1d.2: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID) [19005.947878] pcieport :00:1d.2: device [8086:9d1a] error status/mask=0001/2000 [19005.947886] pcieport :00:1d.2:[ 0] RxErr [19007.194477] pcieport :00:1d.2: AER: Corrected error received: :00:1d.2 [19007.194505] pcieport :00:1d.2: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID) [19007.194509] pcieport :00:1d.2: device [8086:9d1a] error status/mask=0001/2000 [19007.194514] pcieport :00:1d.2:[ 0] RxErr [19024.985336] usb 1-2: USB disconnect, device number 38 [19024.985359] usb 1-2.1: USB disconnect, device number 39 [19024.985370] usb 1-2.1.1: USB disconnect, device number 40 [19025.030357] r8152 2-2.2:1.0 enx186571e521da: Stop submitting intr, status -71 [19025.049481] usb 1-2.1.2: USB disconnect, device number 41 [19025.151593] usb 1-2.1.4: USB disconnect, device number 42 [19025.276446] usb 2-2.1: Port disable: can't disable remote wake [19025.555856] r8152 2-2.2:1.0 enx186571e521da: Tx status -71 [19025.735918] usb 1-2: new high-speed USB device number 43 using xhci_hcd [19025.770499] usb 2-2: USB disconnect, device number 5 [19025.770513] usb 2-2.1: USB disconnect, device number 6 [19025.771766] usb 2-2.2: USB disconnect, device number 7 [19025.778710] pcieport :00:1d.2: AER: Corrected error received: :00:1d.2 [19025.778739] pcieport :00:1d.2: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID) [19025.778748] pcieport :00:1d.2: device [8086:9d1a] error status/mask=0001/2000 [19025.778760] pcieport :00:1d.2:[ 0] RxErr [19025.884801] usb 1-2: New USB device found, idVendor=05e3, idProduct=0610,
[Touch-packages] [Bug 1971538] Re: My machine as Wi-Fi Hotspot broken after upgrade to 22.04
As a workaround, open the installed app "Advanced Network Configuration" Select Hotspot Click the Gear button Try changing Wi-Fi Security settings to something that works for you. I was unable to duplicate your bug with 2 clients, an Android phone and an Ubuntu 22.04 LTS install. Both were able to connect to the hotspot without a problem. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1971538 Title: My machine as Wi-Fi Hotspot broken after upgrade to 22.04 Status in network-manager package in Ubuntu: Confirmed Bug description: * Impact The hotspot feature fails to forward the data to the clients * Test case - log into an Ubuntu or GNOME session - connect the machine to an eth cable for internet - go to gnome-control-center -> wifi - enable the hotspot from the menu in the headerbar - connect another device to the wifi created -> the client should connect and access to internet work correctly Upon updating to 22.04, none of my machines can use the connection. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1971538/+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 1970634] Re: FTBFS: mariadb fails to start due to low MEMLOCK limit
Ok, a plain jammy rebuild in a launchpad ppa failed: 2022-06-17 14:18:27 0 [Warning] mariadbd: io_uring_queue_init() failed with ENOMEM: try larger memory locked limit, ulimit -l, or https://mariadb.com/kb/en/systemd/#configuring-limitmemlock under systemd (262144 bytes required) The binary package that is currently in jammy was probably rebuilt before the lto changes I'm guessing, because it's not affected by this. So I wonder how current jammy users could be affected by this (besides the rebuild). Let's see if Michal has something to say about my comment #15. -- 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/1970634 Title: FTBFS: mariadb fails to start due to low MEMLOCK limit Status in mariadb-10.6 package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Confirmed Status in mariadb-10.6 source package in Jammy: Triaged Status in systemd source package in Jammy: In Progress Bug description: ahasenack: IIRC, originally Launchpad was FTBFSing on mariadb that included io_uring support because upstream were doing a build time test for io_uring (and I think still are), which is wrong because it should be done at runtime since the lack of io_uring availablity at build time doesn't tell us about its availablity at runtime. But then the Launchpad builders got updated to a newer release and therefore a newer kernel that supported it. AIUI, that's how we ended up with a successful build in the Jammy release pocket (of 10.6). I think the lp builders are using the focal hwe kernel 5.4.0-something let me check that build log But then something changed that caused this current FTBFS, and I haven't tracked down what that is. hm, both are 10.6.7 release and proposed What puzzles me is that if the root cause is a memlock rlimit issue then why did it work before? So since there's a contradiction somewhere, maybe one or more of my "facts" above is wrong. this is the current failure 2022-04-14 8:11:49 0 [Warning] mariadbd: io_uring_queue_init() failed with ENOMEM: try larger memory locked limit, ulimit -l, or https://mariadb.com/kb/en/systemd/#configuring-limitmemlock under systemd (262144 bytes required) and ulimit -l confirms that the limit is lower Max locked memory 6553665536 bytes just 64kbytes Yeah but then how did the release pocket build work? either the limit was different back then or ... stuff To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mariadb-10.6/+bug/1970634/+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 1970634] Re: FTBFS: mariadb fails to start due to low MEMLOCK limit
I can't reproduce this bug anymore with the package currently in jammy (1:10.6.7-2ubuntu1): lxc launch ubuntu:focal f --vm lxc shell f lxd init # just hit enter for all questions lxc launch ubuntu:jammy j lxc shell j ulimit -l # confirm it's less than 256 apt update && apt install mariadb-server -y I wonder if it was just an interim issue in jammy's 1:10.6.7-3 package. I'm doing a test rebuild of 1:10.6.7-2ubuntu1 in jammy. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1970634 Title: FTBFS: mariadb fails to start due to low MEMLOCK limit Status in mariadb-10.6 package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Confirmed Status in mariadb-10.6 source package in Jammy: Triaged Status in systemd source package in Jammy: In Progress Bug description: ahasenack: IIRC, originally Launchpad was FTBFSing on mariadb that included io_uring support because upstream were doing a build time test for io_uring (and I think still are), which is wrong because it should be done at runtime since the lack of io_uring availablity at build time doesn't tell us about its availablity at runtime. But then the Launchpad builders got updated to a newer release and therefore a newer kernel that supported it. AIUI, that's how we ended up with a successful build in the Jammy release pocket (of 10.6). I think the lp builders are using the focal hwe kernel 5.4.0-something let me check that build log But then something changed that caused this current FTBFS, and I haven't tracked down what that is. hm, both are 10.6.7 release and proposed What puzzles me is that if the root cause is a memlock rlimit issue then why did it work before? So since there's a contradiction somewhere, maybe one or more of my "facts" above is wrong. this is the current failure 2022-04-14 8:11:49 0 [Warning] mariadbd: io_uring_queue_init() failed with ENOMEM: try larger memory locked limit, ulimit -l, or https://mariadb.com/kb/en/systemd/#configuring-limitmemlock under systemd (262144 bytes required) and ulimit -l confirms that the limit is lower Max locked memory 6553665536 bytes just 64kbytes Yeah but then how did the release pocket build work? either the limit was different back then or ... stuff To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mariadb-10.6/+bug/1970634/+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 1970634] Re: FTBFS: mariadb fails to start due to low MEMLOCK limit
Hi Michal, I'm going over the test procedure for this bug and turns out the scenario where we encountered it is a bit convoluted, specially for users: you need to be running a 5.4 kernel on a jammy userspace (jammy itself has 5.15 kernel). Could you please elaborate on how this bug affects you? Are you included in the above scenario, or is it something else? -- 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/1970634 Title: FTBFS: mariadb fails to start due to low MEMLOCK limit Status in mariadb-10.6 package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Confirmed Status in mariadb-10.6 source package in Jammy: Triaged Status in systemd source package in Jammy: In Progress Bug description: ahasenack: IIRC, originally Launchpad was FTBFSing on mariadb that included io_uring support because upstream were doing a build time test for io_uring (and I think still are), which is wrong because it should be done at runtime since the lack of io_uring availablity at build time doesn't tell us about its availablity at runtime. But then the Launchpad builders got updated to a newer release and therefore a newer kernel that supported it. AIUI, that's how we ended up with a successful build in the Jammy release pocket (of 10.6). I think the lp builders are using the focal hwe kernel 5.4.0-something let me check that build log But then something changed that caused this current FTBFS, and I haven't tracked down what that is. hm, both are 10.6.7 release and proposed What puzzles me is that if the root cause is a memlock rlimit issue then why did it work before? So since there's a contradiction somewhere, maybe one or more of my "facts" above is wrong. this is the current failure 2022-04-14 8:11:49 0 [Warning] mariadbd: io_uring_queue_init() failed with ENOMEM: try larger memory locked limit, ulimit -l, or https://mariadb.com/kb/en/systemd/#configuring-limitmemlock under systemd (262144 bytes required) and ulimit -l confirms that the limit is lower Max locked memory 6553665536 bytes just 64kbytes Yeah but then how did the release pocket build work? either the limit was different back then or ... stuff To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mariadb-10.6/+bug/1970634/+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 1970634] Re: FTBFS: mariadb fails to start due to low MEMLOCK limit
** Changed in: systemd (Ubuntu Jammy) Assignee: (unassigned) => Andreas Hasenack (ahasenack) ** Changed in: systemd (Ubuntu Jammy) Status: New => In Progress ** Changed in: systemd (Ubuntu Jammy) Importance: Undecided => High -- 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/1970634 Title: FTBFS: mariadb fails to start due to low MEMLOCK limit Status in mariadb-10.6 package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Confirmed Status in mariadb-10.6 source package in Jammy: Triaged Status in systemd source package in Jammy: In Progress Bug description: ahasenack: IIRC, originally Launchpad was FTBFSing on mariadb that included io_uring support because upstream were doing a build time test for io_uring (and I think still are), which is wrong because it should be done at runtime since the lack of io_uring availablity at build time doesn't tell us about its availablity at runtime. But then the Launchpad builders got updated to a newer release and therefore a newer kernel that supported it. AIUI, that's how we ended up with a successful build in the Jammy release pocket (of 10.6). I think the lp builders are using the focal hwe kernel 5.4.0-something let me check that build log But then something changed that caused this current FTBFS, and I haven't tracked down what that is. hm, both are 10.6.7 release and proposed What puzzles me is that if the root cause is a memlock rlimit issue then why did it work before? So since there's a contradiction somewhere, maybe one or more of my "facts" above is wrong. this is the current failure 2022-04-14 8:11:49 0 [Warning] mariadbd: io_uring_queue_init() failed with ENOMEM: try larger memory locked limit, ulimit -l, or https://mariadb.com/kb/en/systemd/#configuring-limitmemlock under systemd (262144 bytes required) and ulimit -l confirms that the limit is lower Max locked memory 6553665536 bytes just 64kbytes Yeah but then how did the release pocket build work? either the limit was different back then or ... stuff To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mariadb-10.6/+bug/1970634/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1978079] Re: EFI pstore not cleared on boot
** Merge proposal linked: https://code.launchpad.net/~mustafakemalgilor/ubuntu/+source/systemd/+git/systemd/+merge/424958 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1978079 Title: EFI pstore not cleared on boot Status in systemd package in Ubuntu: In Progress Bug description: Systemd has a systemd-pstore component that scans the pstore on boot and if non-empty, takes all previously created dumps, transfers them into its journal and removes the pstore elements. This is very important on UEFI systems, which only have a limited amount of space for variables. In Ubuntu, the kernel is configured with CONFIG_EFI_VARS_PSTORE=m which means the EFI pstore support gets loaded dynamically. In all of my boots, this dynamic module loading happened *after* systemd tried to check for pstore variables. So systemd-pstore never starts and never clears the UEFI variable store. I see this happening in AWS on Graviton instances, which eventually run out of space to store the dumps. On real hardware, this behavior may lead to unbootable systems. ``` $ systemctl status systemd-pstore ○ systemd-pstore.service - Platform Persistent Storage Archival Loaded: loaded (/lib/systemd/system/systemd-pstore.service; enabled; vendor preset: enabled) Active: inactive (dead) Condition: start condition failed at Thu 2022-06-09 09:11:41 UTC; 29min ago └─ ConditionDirectoryNotEmpty=/sys/fs/pstore was not met Docs: man:systemd-pstore(8) Jun 09 09:11:41 ip-172-31-0-61 systemd[1]: Condition check resulted in Platform Persistent Storage Archival being skipped. $ ls -la /sys/fs/pstore total 0 drwxr-x--- 2 root root0 Jun 9 09:11 . drwxr-xr-x 8 root root0 Jun 9 09:11 .. -r--r--r-- 1 root root 1803 Jun 9 09:07 dmesg-efi-165476562001001 -r--r--r-- 1 root root 1777 Jun 9 09:07 dmesg-efi-165476562002001 -r--r--r-- 1 root root 1773 Jun 9 09:07 dmesg-efi-165476562003001 -r--r--r-- 1 root root 1815 Jun 9 09:07 dmesg-efi-165476562004001 -r--r--r-- 1 root root 1826 Jun 9 09:07 dmesg-efi-165476562005001 -r--r--r-- 1 root root 1754 Jun 9 09:07 dmesg-efi-165476562006001 -r--r--r-- 1 root root 1821 Jun 9 09:07 dmesg-efi-165476562007001 -r--r--r-- 1 root root 1767 Jun 9 09:07 dmesg-efi-165476562008001 -r--r--r-- 1 root root 1729 Jun 9 09:07 dmesg-efi-165476562009001 -r--r--r-- 1 root root 1819 Jun 9 09:07 dmesg-efi-165476562010001 -r--r--r-- 1 root root 1767 Jun 9 09:07 dmesg-efi-165476562011001 -r--r--r-- 1 root root 1775 Jun 9 09:07 dmesg-efi-165476562012001 -r--r--r-- 1 root root 1802 Jun 9 09:07 dmesg-efi-165476562013001 -r--r--r-- 1 root root 1812 Jun 9 09:07 dmesg-efi-165476562014001 -r--r--r-- 1 root root 1764 Jun 9 09:07 dmesg-efi-165476562015001 -r--r--r-- 1 root root 1795 Jun 9 09:11 dmesg-efi-165476589801001 -r--r--r-- 1 root root 1785 Jun 9 09:11 dmesg-efi-165476589802001 -r--r--r-- 1 root root 1683 Jun 9 09:11 dmesg-efi-165476589803001 -r--r--r-- 1 root root 1785 Jun 9 09:11 dmesg-efi-165476589804001 -r--r--r-- 1 root root 1771 Jun 9 09:11 dmesg-efi-165476589805001 -r--r--r-- 1 root root 1797 Jun 9 09:11 dmesg-efi-165476589806001 -r--r--r-- 1 root root 1805 Jun 9 09:11 dmesg-efi-165476589807001 -r--r--r-- 1 root root 1781 Jun 9 09:11 dmesg-efi-165476589808001 -r--r--r-- 1 root root 1806 Jun 9 09:11 dmesg-efi-165476589809001 -r--r--r-- 1 root root 1821 Jun 9 09:11 dmesg-efi-165476589810001 -r--r--r-- 1 root root 1763 Jun 9 09:11 dmesg-efi-165476589811001 -r--r--r-- 1 root root 1783 Jun 9 09:11 dmesg-efi-165476589812001 -r--r--r-- 1 root root 1788 Jun 9 09:11 dmesg-efi-165476589813001 -r--r--r-- 1 root root 1788 Jun 9 09:11 dmesg-efi-165476589814001 -r--r--r-- 1 root root 1786 Jun 9 09:11 dmesg-efi-165476589815001 ``` This problem affects (at least) Ubuntu 20.04 and 22.04. A quick fix would be to configure CONFIG_EFI_VARS_PSTORE=y so that it's always available. A long term fix would make systemd rescan the directory after all module probing settled. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1978079/+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 1979053] Re: UI glitches in GTK application with AMDGPU
** Description changed: After updating to (K)ubuntu 22.04, I see user interface glitches in GTK application. Most obviously affected is Gimp, but Evolution and Eclipse IDE are affected, too. The glitches don't appear on a notebook with Intel graphics, so maybe the problem is caused by a weird interaction between the AMDGPU X.Org driver (I use a Radeon RX5600XT) and GTK. But as the KDE desktop itself isn't affected and only GTK application show these glitches, I think it's not a general problem with AMDGPU. I also booted both Kubunutu and Ubuntu live images and installed Gimp: - The effect show up there, too. So it's than a problem of my actual + The effect shows up there, too. So it's not a problem of my specific installation. I will upload some Gimp screenshots, so you can see what I mean... ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: libcairo2 1.16.0-5ubuntu2 ProcVersionSignature: Ubuntu 5.15.0-39.42-generic 5.15.35 Uname: Linux 5.15.0-39-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: KDE Date: Fri Jun 17 12:36:26 2022 InstallationDate: Installed on 2022-04-27 (50 days ago) InstallationMedia: Kubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) SourcePackage: cairo UpgradeStatus: No upgrade log present (probably fresh install) ** Description changed: After updating to (K)ubuntu 22.04, I see user interface glitches in GTK application. Most obviously affected is Gimp, but Evolution and Eclipse IDE are affected, too. The glitches don't appear on a notebook with Intel graphics, so maybe the problem is caused by a weird interaction between the AMDGPU X.Org driver (I use a Radeon RX5600XT) and GTK. But as the KDE desktop itself isn't affected and only GTK application show these glitches, I think it's not a general problem with AMDGPU. I also booted both Kubunutu and Ubuntu live images and installed Gimp: - The effect shows up there, too. So it's not a problem of my specific + The effect show up there, too. So it's than a problem of my actual installation. I will upload some Gimp screenshots, so you can see what I mean... + + I'm not sure, but I tried to find the library used by all affected + application: Maybe it's libcairo2, maybe not... ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: libcairo2 1.16.0-5ubuntu2 ProcVersionSignature: Ubuntu 5.15.0-39.42-generic 5.15.35 Uname: Linux 5.15.0-39-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: KDE Date: Fri Jun 17 12:36:26 2022 InstallationDate: Installed on 2022-04-27 (50 days ago) InstallationMedia: Kubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) SourcePackage: cairo UpgradeStatus: No upgrade log present (probably fresh install) ** Description changed: After updating to (K)ubuntu 22.04, I see user interface glitches in GTK application. Most obviously affected is Gimp, but Evolution and Eclipse IDE are affected, too. The glitches don't appear on a notebook with Intel graphics, so maybe the problem is caused by a weird interaction between the AMDGPU X.Org driver (I use a Radeon RX5600XT) and GTK. But as the KDE desktop itself isn't affected and only GTK application show these glitches, I think it's not a general problem with AMDGPU. I also booted both Kubunutu and Ubuntu live images and installed Gimp: - The effect show up there, too. So it's than a problem of my actual + The effect shows up there, too. So it's not only a problem of my current installation. I will upload some Gimp screenshots, so you can see what I mean... I'm not sure, but I tried to find the library used by all affected application: Maybe it's libcairo2, maybe not... ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: libcairo2 1.16.0-5ubuntu2 ProcVersionSignature: Ubuntu 5.15.0-39.42-generic 5.15.35 Uname: Linux 5.15.0-39-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: KDE Date: Fri Jun 17 12:36:26 2022 InstallationDate: Installed on 2022-04-27 (50 days ago) InstallationMedia: Kubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) SourcePackage: cairo UpgradeStatus: No upgrade log present (probably fresh install) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cairo in Ubuntu. https://bugs.launchpad.net/bugs/1979053 Title: UI glitches in GTK application with AMDGPU Status in cairo package in Ubuntu: New Bug description: After updating to (K)ubuntu 22.04, I see user interface glitches in GTK application. Most obviously affected is Gimp, but Evolution and Eclipse IDE are affected, too. The glitches don't appear on a notebook with Intel
[Touch-packages] [Bug 1979053] Re: UI glitches in GTK application with AMDGPU
** Package changed: ubuntu => cairo (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cairo in Ubuntu. https://bugs.launchpad.net/bugs/1979053 Title: UI glitches in GTK application with AMDGPU Status in cairo package in Ubuntu: New Bug description: After updating to (K)ubuntu 22.04, I see user interface glitches in GTK application. Most obviously affected is Gimp, but Evolution and Eclipse IDE are affected, too. The glitches don't appear on a notebook with Intel graphics, so maybe the problem is caused by a weird interaction between the AMDGPU X.Org driver (I use a Radeon RX5600XT) and GTK. But as the KDE desktop itself isn't affected and only GTK application show these glitches, I think it's not a general problem with AMDGPU. I also booted both Kubunutu and Ubuntu live images and installed Gimp: The effect show up there, too. So it's than a problem of my actual installation. I will upload some Gimp screenshots, so you can see what I mean... ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: libcairo2 1.16.0-5ubuntu2 ProcVersionSignature: Ubuntu 5.15.0-39.42-generic 5.15.35 Uname: Linux 5.15.0-39-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: KDE Date: Fri Jun 17 12:36:26 2022 InstallationDate: Installed on 2022-04-27 (50 days ago) InstallationMedia: Kubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) SourcePackage: cairo UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cairo/+bug/1979053/+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 1979053] [NEW] UI glitches in GTK application with AMDGPU
You have been subscribed to a public bug: After updating to (K)ubuntu 22.04, I see user interface glitches in GTK application. Most obviously affected is Gimp, but Evolution and Eclipse IDE are affected, too. The glitches don't appear on a notebook with Intel graphics, so maybe the problem is caused by a weird interaction between the AMDGPU X.Org driver (I use a Radeon RX5600XT) and GTK. But as the KDE desktop itself isn't affected and only GTK application show these glitches, I think it's not a general problem with AMDGPU. I also booted both Kubunutu and Ubuntu live images and installed Gimp: The effect show up there, too. So it's than a problem of my actual installation. I will upload some Gimp screenshots, so you can see what I mean... ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: libcairo2 1.16.0-5ubuntu2 ProcVersionSignature: Ubuntu 5.15.0-39.42-generic 5.15.35 Uname: Linux 5.15.0-39-generic x86_64 ApportVersion: 2.20.11-0ubuntu82.1 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: KDE Date: Fri Jun 17 12:36:26 2022 InstallationDate: Installed on 2022-04-27 (50 days ago) InstallationMedia: Kubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) SourcePackage: cairo UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: cairo (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug jammy -- UI glitches in GTK application with AMDGPU https://bugs.launchpad.net/bugs/1979053 You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cairo 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 1969896] Re: Evince Document Viewer(42.0) does not remember last page in 22.04 and opens in a tiny window when launched
** Also affects: evince (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: apparmor (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: evince (Ubuntu Kinetic) Importance: High Status: In Progress ** Also affects: apparmor (Ubuntu Kinetic) Importance: High Status: Confirmed ** Changed in: apparmor (Ubuntu Kinetic) Status: Confirmed => In Progress ** Changed in: apparmor (Ubuntu Jammy) Status: New => In Progress ** Changed in: apparmor (Ubuntu Kinetic) Assignee: (unassigned) => Alex Murray (alexmurray) ** Changed in: apparmor (Ubuntu Jammy) Assignee: (unassigned) => Alex Murray (alexmurray) ** Changed in: apparmor (Ubuntu Jammy) Importance: Undecided => High -- 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/1969896 Title: Evince Document Viewer(42.0) does not remember last page in 22.04 and opens in a tiny window when launched Status in apparmor package in Ubuntu: In Progress Status in evince package in Ubuntu: In Progress Status in apparmor source package in Jammy: In Progress Status in evince source package in Jammy: New Status in apparmor source package in Kinetic: In Progress Status in evince source package in Kinetic: In Progress Bug description: Just switched from Ubuntu 20.04 to 22.04 and realized that Document Viewer no longer open on the last viewed page and doesn't remember the side pane preference even after using the "Save Current Settings as Default" option. Kindly advise ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: evince 42.1-3 ProcVersionSignature: Ubuntu 5.15.0-25.25-generic 5.15.30 Uname: Linux 5.15.0-25-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu82 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Fri Apr 22 15:58:50 2022 InstallationDate: Installed on 2022-03-19 (34 days ago) InstallationMedia: Ubuntu 20.04.4 LTS "Focal Fossa" - Release amd64 (20220223) ProcEnviron: PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: evince UpgradeStatus: Upgraded to jammy on 2022-04-21 (0 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1969896/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1978079] Re: EFI pstore not cleared on boot
** Merge proposal linked: https://code.launchpad.net/~mustafakemalgilor/ubuntu/+source/systemd/+git/systemd/+merge/424938 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1978079 Title: EFI pstore not cleared on boot Status in systemd package in Ubuntu: In Progress Bug description: Systemd has a systemd-pstore component that scans the pstore on boot and if non-empty, takes all previously created dumps, transfers them into its journal and removes the pstore elements. This is very important on UEFI systems, which only have a limited amount of space for variables. In Ubuntu, the kernel is configured with CONFIG_EFI_VARS_PSTORE=m which means the EFI pstore support gets loaded dynamically. In all of my boots, this dynamic module loading happened *after* systemd tried to check for pstore variables. So systemd-pstore never starts and never clears the UEFI variable store. I see this happening in AWS on Graviton instances, which eventually run out of space to store the dumps. On real hardware, this behavior may lead to unbootable systems. ``` $ systemctl status systemd-pstore ○ systemd-pstore.service - Platform Persistent Storage Archival Loaded: loaded (/lib/systemd/system/systemd-pstore.service; enabled; vendor preset: enabled) Active: inactive (dead) Condition: start condition failed at Thu 2022-06-09 09:11:41 UTC; 29min ago └─ ConditionDirectoryNotEmpty=/sys/fs/pstore was not met Docs: man:systemd-pstore(8) Jun 09 09:11:41 ip-172-31-0-61 systemd[1]: Condition check resulted in Platform Persistent Storage Archival being skipped. $ ls -la /sys/fs/pstore total 0 drwxr-x--- 2 root root0 Jun 9 09:11 . drwxr-xr-x 8 root root0 Jun 9 09:11 .. -r--r--r-- 1 root root 1803 Jun 9 09:07 dmesg-efi-165476562001001 -r--r--r-- 1 root root 1777 Jun 9 09:07 dmesg-efi-165476562002001 -r--r--r-- 1 root root 1773 Jun 9 09:07 dmesg-efi-165476562003001 -r--r--r-- 1 root root 1815 Jun 9 09:07 dmesg-efi-165476562004001 -r--r--r-- 1 root root 1826 Jun 9 09:07 dmesg-efi-165476562005001 -r--r--r-- 1 root root 1754 Jun 9 09:07 dmesg-efi-165476562006001 -r--r--r-- 1 root root 1821 Jun 9 09:07 dmesg-efi-165476562007001 -r--r--r-- 1 root root 1767 Jun 9 09:07 dmesg-efi-165476562008001 -r--r--r-- 1 root root 1729 Jun 9 09:07 dmesg-efi-165476562009001 -r--r--r-- 1 root root 1819 Jun 9 09:07 dmesg-efi-165476562010001 -r--r--r-- 1 root root 1767 Jun 9 09:07 dmesg-efi-165476562011001 -r--r--r-- 1 root root 1775 Jun 9 09:07 dmesg-efi-165476562012001 -r--r--r-- 1 root root 1802 Jun 9 09:07 dmesg-efi-165476562013001 -r--r--r-- 1 root root 1812 Jun 9 09:07 dmesg-efi-165476562014001 -r--r--r-- 1 root root 1764 Jun 9 09:07 dmesg-efi-165476562015001 -r--r--r-- 1 root root 1795 Jun 9 09:11 dmesg-efi-165476589801001 -r--r--r-- 1 root root 1785 Jun 9 09:11 dmesg-efi-165476589802001 -r--r--r-- 1 root root 1683 Jun 9 09:11 dmesg-efi-165476589803001 -r--r--r-- 1 root root 1785 Jun 9 09:11 dmesg-efi-165476589804001 -r--r--r-- 1 root root 1771 Jun 9 09:11 dmesg-efi-165476589805001 -r--r--r-- 1 root root 1797 Jun 9 09:11 dmesg-efi-165476589806001 -r--r--r-- 1 root root 1805 Jun 9 09:11 dmesg-efi-165476589807001 -r--r--r-- 1 root root 1781 Jun 9 09:11 dmesg-efi-165476589808001 -r--r--r-- 1 root root 1806 Jun 9 09:11 dmesg-efi-165476589809001 -r--r--r-- 1 root root 1821 Jun 9 09:11 dmesg-efi-165476589810001 -r--r--r-- 1 root root 1763 Jun 9 09:11 dmesg-efi-165476589811001 -r--r--r-- 1 root root 1783 Jun 9 09:11 dmesg-efi-165476589812001 -r--r--r-- 1 root root 1788 Jun 9 09:11 dmesg-efi-165476589813001 -r--r--r-- 1 root root 1788 Jun 9 09:11 dmesg-efi-165476589814001 -r--r--r-- 1 root root 1786 Jun 9 09:11 dmesg-efi-165476589815001 ``` This problem affects (at least) Ubuntu 20.04 and 22.04. A quick fix would be to configure CONFIG_EFI_VARS_PSTORE=y so that it's always available. A long term fix would make systemd rescan the directory after all module probing settled. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1978079/+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 1973441] Re: Printing does not work on Ubuntu 22.04 - cups-pki-invalid
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: cups (Ubuntu) Status: New => Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1973441 Title: Printing does not work on Ubuntu 22.04 - cups-pki-invalid Status in cups package in Ubuntu: Confirmed Bug description: After upgrading to 22.04 printing did not work. There is cups-pki- invalid error and printer goes to paused state. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: cups 2.4.1op1-1ubuntu4 Uname: Linux 5.17.7-051707-generic x86_64 ApportVersion: 2.20.11-0ubuntu82 Architecture: amd64 CasperMD5CheckResult: pass CupsErrorLog: Error: [Errno 13] Permission denied: '/var/log/cups/error_log' CurrentDesktop: ubuntu:GNOME Date: Sun May 15 15:34:47 2022 EcryptfsInUse: Yes InstallationDate: Installed on 2021-10-12 (214 days ago) InstallationMedia: Ubuntu 21.10 "Impish Indri" - Daily amd64 (20211010) Lpstat: device for HP_Color_LaserJet_M552_5F80BF: implicitclass://HP_Color_LaserJet_M552_5F80BF/ MachineType: ASUSTeK COMPUTER INC. ROG Strix G513QY_G513QY Papersize: a4 PpdFiles: Error: command ['fgrep', '-H', '*NickName', '/etc/cups/ppd/HP_Color_LaserJet_M552_5F80BF.ppd'] failed with exit code 2: grep: /etc/cups/ppd/HP_Color_LaserJet_M552_5F80BF.ppd: Permission denied ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.17.7-051707-generic root=UUID=ff964c9b-ce92-4334-8759-9d785a262c60 ro rootflags=subvol=@ quiet splash vt.handoff=7 SourcePackage: cups UpgradeStatus: Upgraded to jammy on 2022-04-24 (21 days ago) dmi.bios.date: 03/29/2022 dmi.bios.release: 5.19 dmi.bios.vendor: American Megatrends International, LLC. dmi.bios.version: G513QY.318 dmi.board.asset.tag: ATN12345678901234567 dmi.board.name: G513QY dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: 1.0 dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: ASUSTeK COMPUTER INC. dmi.chassis.version: 1.0 dmi.ec.firmware.release: 0.81 dmi.modalias: dmi:bvnAmericanMegatrendsInternational,LLC.:bvrG513QY.318:bd03/29/2022:br5.19:efr0.81:svnASUSTeKCOMPUTERINC.:pnROGStrixG513QY_G513QY:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnG513QY:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0:sku: dmi.product.family: ROG Strix dmi.product.name: ROG Strix G513QY_G513QY dmi.product.version: 1.0 dmi.sys.vendor: ASUSTeK COMPUTER INC. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1973441/+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 1979032] [NEW] cpu_freq returns current value in GHz but min/max (fixed in 5.9.1)
Public bug reported: Can python-psutil be updated to 5.9.1? It fixes incorrect cpu_freq which affects s-tui. https://github.com/giampaolo/psutil/issues/2049 https://github.com/amanusk/s-tui/issues/186#issuecomment-1100639705 Thanks ** Affects: python-psutil (Ubuntu) Importance: Undecided Status: New ** Description changed: - Can python-psutil be updated to 5.9.1? It fixes incorrect cpu_freq which - affects s-tui. + Can python-psutil be updated to 5.9.1? It fixes incorrect cpu_freq which affects s-tui. + https://github.com/giampaolo/psutil/issues/2049 https://github.com/amanusk/s-tui/issues/186#issuecomment-1100639705 Thanks -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python-psutil in Ubuntu. https://bugs.launchpad.net/bugs/1979032 Title: cpu_freq returns current value in GHz but min/max (fixed in 5.9.1) Status in python-psutil package in Ubuntu: New Bug description: Can python-psutil be updated to 5.9.1? It fixes incorrect cpu_freq which affects s-tui. https://github.com/giampaolo/psutil/issues/2049 https://github.com/amanusk/s-tui/issues/186#issuecomment-1100639705 Thanks To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-psutil/+bug/1979032/+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
