[Touch-packages] [Bug 1989309] [NEW] [FFe] apparmor 3.1.1 upstream release
Public bug reported: Placeholder for preparation of AppArmor 3.1.1 for kinetic. ** Affects: apparmor (Ubuntu) Importance: Undecided Status: New ** Summary changed: - [FFe] apparmor 3.1.0 upstream release + [FFe] apparmor 3.1.1 upstream release -- 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/1989309 Title: [FFe] apparmor 3.1.1 upstream release Status in apparmor package in Ubuntu: New Bug description: Placeholder for preparation of AppArmor 3.1.1 for kinetic. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1989309/+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 1970402] Re: Initrd out of memory error after upgrade to 22.04
*** This bug is a duplicate of bug 1842320 *** https://bugs.launchpad.net/bugs/1842320 I have the similar issue on LG Gram 16 inch 11 Generation ram 16GB 512SSD -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1970402 Title: Initrd out of memory error after upgrade to 22.04 Status in initramfs-tools package in Ubuntu: Confirmed Status in initramfs-tools source package in Jammy: Confirmed Bug description: After upgrading to 22.04 system is unbootable because of "out of memory" error when loading initial ramdisk. I was able to fix it by editing cat /etc/initramfs-tools/initramfs.conf and changing configuration to: MODULES=dep COMPRESS=xz RUNSIZE=15% Not sure which one helped, but I can test it if needed. System information: Description:Ubuntu 22.04 LTS Release:22.04 initramfs-tools: Installed: 0.140ubuntu13 Candidate: 0.140ubuntu13 Version table: *** 0.140ubuntu13 500 500 http://pl.archive.ubuntu.com/ubuntu jammy/main amd64 Packages 500 http://pl.archive.ubuntu.com/ubuntu jammy/main i386 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1970402/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1961427] Re: zlib: compressBound() returns an incorrect result on z15
** Tags added: foundations-todo
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to zlib in Ubuntu.
https://bugs.launchpad.net/bugs/1961427
Title:
zlib: compressBound() returns an incorrect result on z15
Status in Ubuntu on IBM z Systems:
In Progress
Status in bedtools package in Ubuntu:
Fix Released
Status in htslib package in Ubuntu:
Invalid
Status in zlib package in Ubuntu:
Fix Released
Status in bedtools source package in Focal:
Invalid
Status in htslib source package in Focal:
Fix Committed
Status in zlib source package in Focal:
Fix Committed
Status in bedtools source package in Impish:
Won't Fix
Status in htslib source package in Impish:
Won't Fix
Status in zlib source package in Impish:
Won't Fix
Status in bedtools source package in Jammy:
Fix Committed
Status in htslib source package in Jammy:
Invalid
Status in zlib source package in Jammy:
Fix Committed
Bug description:
SRU Justification:
==
[Impact]
* zlib: compressBound() returns an incorrect result on IBM z15
hardware.
* Passing the result of compressBound() to compress() results
in an error code.
* This is because compressBound() is not adjusted for DFLTCC.
[Fix]
* Adjust compressBound() for DFLTCC like it's already done
for deflateBound().
* Since zlib project does not accept patches at the moment,
the fix has been integrated into the DFLTCC pull request:
https://github.com/madler/zlib/pull/410
The commitid is b25781e735363e04f6c56e21431c47e4afc50b17.
* The fix extracted out of the above is:
https://launchpadlibrarian.net/589857296/debdiff_zlib_1.2.11.dfsg-2ubuntu7_to_zlib_1.2.11.dfsg-2ubuntu8_jammy.diff
* On top of this actual zlib fix, there is another patch needed:
'Remove compressBound assertions. (PR #1258)' for htslib.
* But there is a standalone 'htslib' package version, as well as a
htslib version included in (some) 'bedtools' packages.
Both need to be patched (see '[Other]' for more details).
[Test Plan]
* An IBM z15 system (LPAR, z/VM guest or KVM virtual machine)
with Ubuntu Server 21.10 (or 22.04).
* A test can be done based on the following C test program:
#include
#include
#include
int main() {
Bytef in_buf[128], out_buf[1024];
for (size_t i = 0; i < sizeof(in_buf); i++)
in_buf[i] = rand();
uLongf dest_len = compressBound(sizeof(in_buf));
assert(dest_len <= sizeof(out_buf));
int ret = compress(out_buf, _len,
in_buf, sizeof(in_buf));
assert(ret == Z_OK);
}
* The test needs to be done by IBM, due to the requirements
for the special z15 hardware.
* A successful test was just completed, based on the version in jammy-
proposed, which is at the same code level that the impish version this
SRU is targeted for.
[Where problems could occur]
* If the adjustment of compressBound() for DFLTCC is done
erroneously the issue can still be present or in worst case
even affect Z systems other than z15 only.
* The compression can become errorneous with the new changes,
e.g. in compressBound.
* Mistakes in dfltcc_free_window OF and especially DEFLATE_BOUND_COMPLEN,
(incl. the bit definitions), may cause various and unforseen defects.
* Any build time issues that might have been introduced by this patch
can be identified by a test build; this was done and is available here:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427
[Other Info]
* Ubuntu jammy, impish and focal are affected by the zlib issue.
* The 'htslib' version '1.13+ds' (as it is part of I, J and K),
already includes the patch,
hence only htslib '1.10.2' in focal needs to be patched.
* The bedtools version '2.30.0+dfsg' (as it is part of I, J and K),
requires the patch,
but version '2.27.1+dfsg' bedtools in focal does not incl. an
embedded htslib, hence does not need to be (actually can't be)
patched.
* Patched version of the affected htslib and bedtools packages
are build and also available at this PPA:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1961427
__
Description: zlib: compressBound() returns an incorrect result on z15
Symptom: Passing the result of compressBound() to compress()
results in an error code.
Problem: compressBound() is not adjusted for DFLTCC.
Solution: Adjust compressBound() for DFLTCC like it's already done
for deflateBound(). Since zlib project does not accept
patches at the moment, the fix has been integrated into
the DFLTCC pull request:
https://github.com/madler/zlib/pull/410
The commitid is b25781e735363e04f6c56e21431c47e4afc50b17.
[Touch-packages] [Bug 1975667] Re: systemd-resolved does not reset DNS server and search domain list properly after VPN disconnect
** Tags added: foundations-todo -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1975667 Title: systemd-resolved does not reset DNS server and search domain list properly after VPN disconnect Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Jammy: Fix Committed Bug description: [Impact] Networking components such as VPNs that rely on systemd-resolved's API to configure search domains may inadvertently leave the network configuration in a bad state. This is a result of a broken systemd- resolved API. [Test Plan] * On a jammy host, configure a couple search domains with resolvectl: $ resolvectl domain search1.internal search2.internal $ resolvectl domain * In any case, both domains should be displayed. Then, attempt to clear the configured domains: $ resolvectl domain "" $ resolvectl domain * On a patched system, the two domains should no longer be displayed. On an un-patched system, one of the domains will still be configured. [Where problems could occur] This patch touches the logic that configures search domains in systemd-resolved. If the patch caused regressions, it would be related to the set of configured search domains. [Original Description] Hi, in Ubuntu 21.10 I am facing a problem with DNS server list and search domain list is not properly reset back to the previous values after a VPN is disconnected. I reproduced this in Ubuntu 21.10 instance which was upgraded from the older version of Ubuntu as well as in Live USB Ubuntu 21.10 so it is not an "upgrade issue". I use this resolv.conf symlink: /etc/resolv.conf -> ../run/systemd/resolve/resolv.conf Actual behavior: VPN connect will add VPN's DNS servers and search domains into /etc/resolv.conf. When VPN is disconnected there are some of the VPN's DNS server and search domain entries left there, so it is not reset back properly. Desired behavior: VPN connect will add VPN's DNS servers and search domains into /etc/resolv.conf. When VPN is disconnected DNS servers and search domain list is restored to exactly the same state as was prior to the VPN connection. Steps for reproducing: 1. Before VPN is connected this is the DNS server and search domain list in /etc/resolv.conf: nameserver 192.168.122.1 search . 2. Once the VPN is connected, we see there were VPN's DNS server and serach domain list entries added: nameserver 2xx.xx.xx.x0 nameserver 2xx.xx.xx.x1 nameserver 192.168.122.1 search domain1.local domain2.internal domain3.internal 3. After VPN disconnection, we see the DNS server and search domain list in /etc/resolv.conf is not restored to the state at point (1.) and some entries from VPN is being kept there: nameserver 2xx.xx.xx.x1 nameserver 192.168.122.1 search domain2.internal domain3.internal ProblemType: Bug DistroRelease: Ubuntu 21.10 Package: systemd 248.3-1ubuntu8 ProcVersionSignature: Ubuntu 5.13.0-19.19-generic 5.13.14 Uname: Linux 5.13.0-19-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair ApportVersion: 2.20.11-0ubuntu70 Architecture: amd64 CasperMD5CheckResult: pass CasperVersion: 1.465 CurrentDesktop: ubuntu:GNOME Date: Wed May 25 06:06:05 2022 LiveMediaBuild: Ubuntu 21.10 "Impish Indri" - Release amd64 (20211012) Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd QEMU USB Tablet Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Lsusb-t: /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/15p, 5000M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/15p, 480M |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 480M MachineType: QEMU Standard PC (Q35 + ICH9, 2009) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/casper/vmlinuz file=/cdrom/preseed/username.seed maybe-ubiquity quiet splash --- SourcePackage: systemd SystemdDelta: [EXTENDED] /usr/lib/systemd/system/rc-local.service → /usr/lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /usr/lib/systemd/system/systemd-localed.service → /usr/lib/systemd/system/systemd-localed.service.d/locale-gen.conf [EXTENDED] /usr/lib/systemd/system/user@.service → /usr/lib/systemd/system/user@.service.d/timeout.conf 3 overridden configuration files found. UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/01/2014 dmi.bios.release: 0.0 dmi.bios.vendor: SeaBIOS dmi.bios.version: 1.14.0-2 dmi.chassis.type: 1 dmi.chassis.vendor: QEMU dmi.chassis.version: pc-q35-6.0 dmi.modalias:
[Touch-packages] [Bug 1937110] Re: dhcp option 121 & 249
** Tags added: foundations-todo -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu. https://bugs.launchpad.net/bugs/1937110 Title: dhcp option 121 & 249 Status in subiquity: New Status in isc-dhcp package in Ubuntu: Fix Released Status in isc-dhcp source package in Jammy: Incomplete Bug description: Hello, I'm running into issues with subiquity on a cloud provider. The cloud provider is using an on-link L3 gateway. His DHCP response looks like this: OPTION: 53 ( 1) DHCP message type 5 (DHCPACK) OPTION: 54 ( 4) Server identifier 172.31.1.1 OPTION: 51 ( 4) IP address leasetime 86400 (24h) OPTION: 1 ( 4) Subnet mask 255.255.255.255 OPTION: 3 ( 4) Routers 172.31.1.1 OPTION: 6 ( 12) DNS server OPTION: 121 ( 14) Classless Static Route20ac1f010100 ... ac1f0101 .. OPTION: 249 ( 14) MSFT - Classless route20ac1f010100 ... ac1f0101 .. Im booting the subiquity process with an patched ipxe (https://github.com/ipxe/ipxe/pull/104) like this: #!ipxe kernel .../vmlinuz initrd=initrd root=/dev/ram0 ramdisk_size=150 ip=dhcp url=https://cdimage.ubuntu.com/ubuntu-server/focal/daily-live/current/focal-live-server-amd64.iso autoinstall ds=nocloud-net;s=.../...-ad-78/ cloud-config-url=/dev/null initrd .../initrd boot initrd/vmlinuz is extracted right out of focal-live-server-amd64.iso Sadly subiquity is stuck with a broken network (because of missing dhcp option 121/249 support). It happens when its running the /init from the kernel right after kernel is booted, i guess even before the subiquity is started(?). After further debugging, it looks like the provided kernel 5.4.80 #90 Ubuntu, is using busybox 1.30.1-4ubuntu~6.3 which includes isc- dhclient-4.4.1 which is lacking the given options. Would be awesome if this could be fixed.. maybe just a simple busybox compile option? To manage notifications about this bug go to: https://bugs.launchpad.net/subiquity/+bug/1937110/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1979951] Re: 127.0.0.1/::1 removed from loopback interface if you configure extra IPs on lo (r104 regression/behaviour change)
** Tags added: foundations-todo -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1979951 Title: 127.0.0.1/::1 removed from loopback interface if you configure extra IPs on lo (r104 regression/behaviour change) Status in netplan.io package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Fix Released Status in netplan.io source package in Focal: New Status in systemd source package in Focal: Fix Committed Status in netplan.io source package in Jammy: New Status in systemd source package in Jammy: Fix Committed Bug description: [Impact] Users who wish to configure additional addresses on lo may inadvertently remove the 127.0.0.1/8 address from the interface. And, because this only happens on the second invocation of `netplan apply`, it can create confusing breakages for users. Although this is not a recommended configuration, it was previously supported and the current behavior is a regression. [Test Plan] * Configure additional addresses on the lo interface. I am testing in a LXD container, so I added the following to /etc/netplan/10-lxc.yaml under `ethernets:` lo: addresses: ["10.10.10.17/24","10.10.10.19/24"] * Apply the config, and then inspect the lo interface's addresses: $ netplan apply $ ip addr show dev lo * Observe that the 127.0.0.1/8 address is still present. Now, run the same commands again: $ netplan apply $ ip addr show dev lo * On an affected system, observe that the 127.0.0.1/8 address is now gone. On a patched system, the address should still be present. [Where problems could occur] The patch removes cases where systemd-networkd will drop foreign addresses from a managed link. If problems were to occur, it would be related to the addresses configured on a managed link. [Original Description] If you configure the loopback interface using netplan without listing the standard loopback addresses (127.0.0.1 / ::1) that are auto- configured on boot then they are removed by netplan in r104+ but were not in r103. Confusingly this only happens the second time "netplan apply" is invoked and not the first time. There is some argument this is not a valid configuration, however - It worked on r103 and broke in the r104 SRU for 20.04 and breaks on upgrade - Since it only occurs on the second "netplan apply" it is likely people will accidentally create a configuration that on first verification works but breaks later - Adding addresses to a loopback or dummy interface is a common need - There is no dummy interface support in Netplan - Removing the loopback IP doesn't immediately cause obvious breakage in an SSH session but causes all sorts of hard to diagnose issues with applications Thus I consider this a high priority regression because of the multiple ways this can break a system at an unexpected/unrelated time to when the original change was made. As a workaround you can add 127.0.0.1/::1 to the file and this seems to generally work and product almost the same configuration with the exception that "brd 127.255.255.255" is added to the "ip addr" output compared to the auto-created configuration. All of the different routing tables seem otherwise the tame. = Test Case = (1) Add IP configuration for lo to /etc/netplan/lo.yaml lo: match: name: lo addresses: - 10.10.10.17/24 - 10.10.10.19/24 (2) Run "netplan apply" and observe the "ip addr show dev lo" output. Expected: 127.0.0.1/::1 are still there. (3) Run "netplan apply" a second time and observe the "ip addr show dev lo" output. Expected: 127.0.0.1/::1 are now removed. (4) Repeat the same test under netplan r103. Expected: 127.0.0.1/::1 are still there in both cases. = Observations = I found this change of behaviour happens only in r104. It is suspected but not clear that this is due to the configuraiton diffing behaviour introduced in r104. It's not clear to me why it doesn't happen on the first "netplan apply". I also found a recent upstream systemd commit to prevent networkd removing 127.0.0.1/::1 which solves this issue on r104 as well. It's possible this is a better fix to backport to solve this: https://github.com/systemd/systemd/commit/b69bfa43052586cd6894c32d7d3d447195539ec5 Reverting to r103 *or* running a newer systemd with that patch resolves the issue on 20.04 and 22.04 in my testing. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/1979951/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1981042] Re: /etc/localtime symlink not correctly handled when using /etc/writable
** Tags added: foundations-todo -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1981042 Title: /etc/localtime symlink not correctly handled when using /etc/writable Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Jammy: Fix Committed Status in systemd source package in Kinetic: Fix Released Bug description: [Impact] When using /etc/writable (e.g. Ubuntu Core) /etc/localtime is a symlink to /etc/writable/localtime (which in itself if a symlink). Systemd doesn't handle this correctly when doing firstboot or using inotify to watch for changes to localtime. [Test Plan] This is somewhat hard to test, the following situations need to be reproduced: - On firstboot the timezone link will not be read correctly, it will with this change. - Starting a timer unit and then changing timezone will cause it not to occur at the correct time. [Where problems could occur] This could potentially break other users of localtime, however the change is similar to existing changes which have been in Ubuntu's version of systemd for some time. The change detects the /etc/writable case and if not should have the same existing behaviour. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1981042/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1982462] Re: Some modprobe loading services requested by the pstore service fail
** Tags added: foundations-todo -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1982462 Title: Some modprobe loading services requested by the pstore service fail Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: Fix Committed Status in systemd source package in Jammy: Fix Committed Status in systemd source package in Kinetic: Fix Released Bug description: [Impact] It has been detected that some modprobe services fail on UC22 after the jammy upgrade 249.11-0ubuntu3.4: $ systemctl --system --no-ask-password --no-pager list-units --state=failed Failed units: UNIT LOAD ACTIVE SUBDESCRIPTION ● modprobe@chromeos_pstore.service loaded failed failed Load Kernel Module chromeos_pstore ● modprobe@efi_pstore.service loaded failed failed Load Kernel Module efi_pstore ● modprobe@mtdpstore.service loaded failed failed Load Kernel Module mtdpstore ● modprobe@pstore_blk.service loaded failed failed Load Kernel Module pstore_blk ● modprobe@pstore_zone.service loaded failed failed Load Kernel Module pstore_zone ● modprobe@ramoops.service loaded failed failed Load Kernel Module ramoops This happens because of some changes to systemd-pstore.service that now has: After=modprobe@efi_pstore.service modprobe@mtdpstore.service modprobe@chromeos_pstore.service modprobe@ramoops.service modprobe@pstore_zone.service modprobe@pstore_blk.service Wants=modprobe@efi_pstore.service modprobe@mtdpstore.service modprobe@chromeos_pstore.service modprobe@ramoops.service modprobe@pstore_zone.service modprobe@pstore_blk.service This causes too many tries of the modprobe services, that fail in the end with Jul 20 09:02:39 ubuntu systemd[1]: modprobe@chromeos_pstore.service: Start request repeated too quickly. Although we have seen this only on UC22, it potentially can affect classic systems as well, as systemd-pstore.service is re-tried there a few times too. See https://github.com/snapcore/core-base/issues/72 for more details. A fix for this is available upstream: https://github.com/systemd/systemd/commit/9625350e5381a68c1179ae4581e7586c206663e1 [Test Plan] Start the device and check that there is no modprobe-pstore related failed service. This is racy, so a few tries will be needed to make sure things are fine. [Where problems could occur] The modprobe services are usually dependencies from other services, so it should be fine if the retry behavior is controlled by those other services. Risk should be small. If something goes wrong we might see a lot of restarts for these services. [Other Info] Testing should happen on UC22 too. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1982462/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1981109] Re: server image pulls in ModemManager via fwupd, consumes 25MiB RAM in every container
** Tags added: foundations-todo -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/1981109 Title: server image pulls in ModemManager via fwupd, consumes 25MiB RAM in every container Status in fwupd package in Ubuntu: Invalid Status in livecd-rootfs package in Ubuntu: Fix Released Status in modemmanager package in Ubuntu: Triaged Status in ubuntu-meta package in Ubuntu: New Status in fwupd source package in Jammy: Invalid Status in livecd-rootfs source package in Jammy: Triaged Status in modemmanager source package in Jammy: New Status in ubuntu-meta source package in Jammy: New Bug description: Looking at memory utilization in a pristine Ubuntu lxd container (top -o RES), I see that ModemManager is running, which I was surprised to see is present at all in the stock image. Tracking this I find that fwupd depends on libmm-glib0, which in turn Recommends: modemmanager. Libraries in general should not recommend daemons, so it's possible this should be fixed by libmm-glib0 dropping this Recommends. It certainly doesn't seem to be a deliberate decision by the Server Team to have modemmanager installed and running by default on all systems. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/fwupd/+bug/1981109/+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 1867204] Re: /usr/share/apport/whoopsie-upload-all:FileNotFoundError:/usr/share/apport/whoopsie-upload-all@170:collect_info:process_report
** Tags added: foundations-todo -- 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/1867204 Title: /usr/share/apport/whoopsie-upload- all:FileNotFoundError:/usr/share/apport/whoopsie-upload- all@170:collect_info:process_report Status in Apport: Fix Released Status in apport package in Ubuntu: Fix Released Status in apport source package in Focal: Fix Committed Bug description: The Ubuntu Error Tracker has been receiving reports about a problem regarding apport. This problem was most recently seen with package version 2.20.11-0ubuntu19, the problem page at https://errors.ubuntu.com/problem/7a3912ff155870bdb23500abfa48a21a6cb07171 contains more details, including versions of packages affected, stacktrace or traceback, and individual crash reports. If you do not have access to the Ubuntu Error Tracker and are a software developer, you can request it at http://forms.canonical.com/reports/. To manage notifications about this bug go to: https://bugs.launchpad.net/apport/+bug/1867204/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1979952] Re: Bind mount to NFS mount fails on Ubuntu 22.04
** Tags added: foundations-todo -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1979952 Title: Bind mount to NFS mount fails on Ubuntu 22.04 Status in systemd: Unknown Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Jammy: Fix Committed Status in systemd source package in Kinetic: Fix Released Bug description: [Impact] Some NFS setups that have worked on previous versions of Ubuntu are now broken. Specifically, when creating a bind mount, systemd will fail if the directory already exists on NFS. [Test Plan] This test plan requires an NFS server to be in place. The exact setup is not important, but for the purposes of this test plan we will assume the server exports /data, which contains a directory called home. * Make sure nfs-common is installed: $ apt install nfs-common -y * Check the NFS server exports using showmount: $ showmount -e $NFS_SERVER_IP Export list for $NFS_SERVER_IP: /data * * Add the appropriate entries to /etc/fstab. In this example, we will make /home2 a bind mount to /data/home: # /etc/fstab $NFS_SERVER_IP:/data /data nfs defaults,nfsvers=3 0 0 /data/home /home2 none bind,_netdev,x-systemd.requires-mounts-for=/data 0 0 * Check systemctl status home2.mount. On an affected system, we should see a permission denied error: $ systemctl status home2.mount x home2.mount - /home2 Loaded: loaded (/etc/fstab; generated) Active: failed (Result: resources) Where: /home2 What: /data/home Docs: man:fstab(5) man:systemd-fstab-generator(8) systemd[1]: home2.mount: Failed to make bind mount source '/data/home': Permission denied systemd[1]: home2.mount: Failed to run 'mount' task: Permission denied systemd[1]: home2.mount: Failed with result 'resources'. systemd[1]: Failed to mount /home2. * On a patched system, we expect /home2 to be mounted successfully. [Where problems could occur] The patch makes it so that systemd will not fail bind mounts immediately if creating the directory fails. Thus, any regressions would be seen during bind mounts with systemd. N.B. that this patch restores previous behavior in systemd. [Original Description] I have the following setup: - /data is an NFS mount. - /home is a bind mount to /data/home. Configured in /etc/fstab with these lines: $FILE_SERVER:/data /data nfs defaults 0 0 /data/home /home none bind,_netdev,x-systemd.requires-mounts-for=/data 0 0 This has worked with the same configuration for me on at least Ubuntu 18.04 and Ubuntu 20.04, but on Ubuntu 22.04 the mount of /home fails when attempted by systemd. So not only is /home not mounted after boot, but also when I run "sudo systemctl start home.mount", it fails. The journal entries are this: sudo[1316]: wendler : TTY=pts/0 ; PWD=/home/wendler ; USER=root ; COMMAND=/usr/bin/systemctl start home.mount sudo[1316]: pam_unix(sudo:session): session opened for user root(uid=0) by wendler(uid=1000) systemd[1]: home.mount: Directory /home to mount over is not empty, mounting anyway. systemd[1]: home.mount: Failed to make bind mount source '/data/home': Permission denied systemd[1]: home.mount: Failed to run 'mount' task: Permission denied systemd[1]: home.mount: Failed with result 'resources'. systemd[1]: Failed to mount /home. However, when I run "sudo mount /home" it works. Now the weird thing is that after I have mounted /home manually once and unmounted it again, then "sudo systemctl start home.mount" suddenly also works! But of course only until the next reboot. And even if I just do "ls /data" once (either as root or as my user), it also makes "sudo systemctl start home.mount" start working! To be fully clear: - Booting the system (/home fails to mount) - sudo systemctl start home.mount # fails - sudo ls /data # shows correct output - sudo systemctl start home.mount # works! Additional information: The NFS export for /data has root_squash set and if I remove this option, the bind mount of /home works as it should. However, both /data and /data/home have mode rwxr-xr-x, so root is able to enter and read these directories even despite root_squash. It is not a network or mount-order problem. Not only is the bind mount to /home correctly attempted after /data is mounted during boot, remember that the bind mount also fails when I try it with "sudo systemctl start home.mount" minutes afterwards. Versions (system is a recent installation with all updates applied): - Ubuntu 22.04 - Linux 5.15.0-40-generic - systemd 249.11-0ubuntu3.3 - util-linux 2.37.2-4ubuntu3 This appears on both Ubuntu 22.04 machines that I have (a hardware machine and a VM). To manage notifications about this bug go to:
[Touch-packages] [Bug 1981622] Re: mtd device must be supplied (device name is empty)
** Tags added: foundations-todo
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1981622
Title:
mtd device must be supplied (device name is empty)
Status in systemd package in Ubuntu:
Fix Released
Status in systemd source package in Focal:
Triaged
Status in systemd source package in Jammy:
Fix Committed
Bug description:
[WORKAROUND]
This will NOT fix a system that is not booting, because the "mtd
device must be supplied (device name is empty)" message is not the
cause of failed boots. This work around is only for those who are
annoyed by the error message, but are otherwise not experiencing any
issues.
If you are not able to boot your system, but you see this error
message, please open a separate bug with your journalctl and dmesg
logs.
# cp /{lib,etc}/systemd/system/systemd-pstore.service
# sed -i 's/modprobe@mtdpstore.service //'
/etc/systemd/system/systemd-pstore.service
# systemctl daemon-reload
[Impact]
Due to mtdpstore not being properly configured as a pstore backend,
when systemd-pstore.service tries to load the module, users get the
following error in dmesg:
[ 18.453473] systemd[1]: Starting Load Kernel Module mtdpstore...
[ 18.462685] mtd device must be supplied (device name is empty)
This is a distracting error for users trying to diagnose other system
issues, especially if their system does not boot after a kernel crash
and this is the only message displayed on the console.
[Test Plan]
* Force a kernel crash to populate /sys/fs/pstore, thus causing
systemd-pstore.service to start on the subsequent boot:
# echo 1 > /proc/sys/kernel/sysrq
# echo 1 > /proc/sys/kernel/panic
# echo c > /proc/sysrq-trigger
* When the system reboots, observe the error in dmesg:
# dmesg | grep mtd
[Where problems could occur]
If a system was relying on this pstore backend, and mtdpstore is built
as a module, it is possible for systemd-pstore.service to trigger
before mtdpstore is loaded, causing systemd-pstore to not copy the
contents of /sys/fs/pstore. Note however that before the patched
introduced as a result of bug 1978079, systemd-pstore.service would
not attempt to load *any* kernel modules.
[Original Description]
After updating my 22.04 system (possibly caused by Systemd update).
And now booting, dmesg has two errors:
'mtd device must be supplied (device name is empty)'.
See line 8 and 134 in the included logfile.
The system are booting as it should though, and the system are working
like it should no errors at all.
Is this maybe caused by 'efi-pstore-not-cleared-on-boot.patch' in
systemd?
I have an EFI mounted at boot but it isn't used because I have
installed my system in legacy BIOS mode.
Is this maybe the culprit?
I could ignore the message but it isn't nice though.
Regards
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1981622/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1962454] Re: Oops pages show wrong time window in JournalErrors
** Tags added: foundations-todo -- 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/1962454 Title: Oops pages show wrong time window in JournalErrors Status in Apport: Fix Released Status in apport package in Ubuntu: Fix Released Status in apport source package in Jammy: Incomplete Bug description: [Impact] Oops pages show wrong time window in JournalErrors. For example, I just experienced a crash at: Feb 28 17:31:12 And the JournalErrors entries are: Feb 28 17:31:30 - Feb 28 17:31:41 So don't relate to the crash. [Test Plan] 1. Find a recent crash report from a relevant Ubuntu release on https://errors.ubuntu.com/ If you're looking at https://errors.ubuntu.com/problem/SOMETHING then scroll down and pick a relevant instance from the Occurrences list. 2. Now you're on a page starting with https://errors.ubuntu.com/oops/ look at ApportVersion and verify that apport is a recent enough version to contain the proposed fix. If not then go to step 1. 3. Verify the Date field falls within the time range of the JournalErrors entries. Step 3 might fail in the case of there being no system log entries from around the time of the crash. That does not necessarily mean the test plan has failed. Go to step 1 and pick a different crash. Prior to the fix you would almost never find oops pages that would pass the test. After the fix you should find many/most oops pages do pass the test. [Where problems could occur] Worst case - in any part of the bug reporting/collection procedure, since that is what's changing. [Other Info] To manage notifications about this bug go to: https://bugs.launchpad.net/apport/+bug/1962454/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1959475] Re: "machinectl shell" connections immediately terminated
** Tags added: foundations-todo -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1959475 Title: "machinectl shell" connections immediately terminated Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: Fix Committed Bug description: [Impact] This bug prevents users on Impish and newer from connecting to Focal systemd containers using `machinectl shell`. This limits users ability to manage containers spawned with systemd-nspawn. [Test Plan] On a Jammy host, do the following: * Install systemd-container and debootstrap if necessary: $ sudo apt install debootstrap systemd-container * Create a Focal filesystem for the container: $ sudo debootstrap --arch= focal /var/lib/containers/lp1959475/ * Launch the container: $ sudo systemd-nspawn -D /var/lib/containers/lp1959475/ --machine test-container * Inside the container, set a password for root and then exit: $ passwd # Enter password when prompted $ exit * Re-launch the container with -b option: $ sudo systemd-nspawn -D /var/lib/containers/lp1959475/ --machine test-container -b * In a separate terminal window, try to connect to the container: $ sudo machinectl shell test-container * Observe the "Connection to machine test-container terminated" error message. [Where problems could occur] The patch expands the case where the TERM variable is inherited from PID 1 when building an execution environment, e.g. for a container. If problems were to occur, it would be related to the value of TERM in environments forked off of PID 1. [Other Info] This bug occurs when trying to connect to a Focal container from e.g. a Jammy host. For SRU verification, the container should be Focal, and the host should be Jammy. The -proposed package should be installed in the Focal container. [Original Description] The command "machinectl shell" does not work in systemd 249.9-0ubuntu2: $ sudo machinectl shell ns-xxx Connected to machine ns-xxx. Press ^] three times within 1s to exit session. Connection to machine ns-xxx terminated. The issue seems to be described here: https://forum.manjaro.org/t/the-machinectl-shell-command-stopped-working-after-systemd-upgrade-to-250-2-1/99899 https://github.com/systemd/systemd/issues/22234 and solved here: https://github.com/systemd/systemd/commit/e8cf09b2a2ad0d48e5493050d54251d5f512d9b6 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1959475/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1970402] Re: Initrd out of memory error after upgrade to 22.04
*** This bug is a duplicate of bug 1842320 *** https://bugs.launchpad.net/bugs/1842320 ** Tags added: foundations-todo -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1970402 Title: Initrd out of memory error after upgrade to 22.04 Status in initramfs-tools package in Ubuntu: Confirmed Status in initramfs-tools source package in Jammy: Confirmed Bug description: After upgrading to 22.04 system is unbootable because of "out of memory" error when loading initial ramdisk. I was able to fix it by editing cat /etc/initramfs-tools/initramfs.conf and changing configuration to: MODULES=dep COMPRESS=xz RUNSIZE=15% Not sure which one helped, but I can test it if needed. System information: Description:Ubuntu 22.04 LTS Release:22.04 initramfs-tools: Installed: 0.140ubuntu13 Candidate: 0.140ubuntu13 Version table: *** 0.140ubuntu13 500 500 http://pl.archive.ubuntu.com/ubuntu jammy/main amd64 Packages 500 http://pl.archive.ubuntu.com/ubuntu jammy/main i386 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1970402/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1988667] Re: Quito isn't displayed as choice for time zone
Thank you for following this up and your reply. I will report it and see if it is updated upstream. Thank you again! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to tzdata in Ubuntu. https://bugs.launchpad.net/bugs/1988667 Title: Quito isn't displayed as choice for time zone Status in tzdata package in Ubuntu: Opinion Bug description: On Ubuntu 22.04.1 (and 20.04.x) there is no option available for Quito. On GNOME Settings > Date & Time > (A map is displayed) Type Quito on the search field. There are no matches. On KDE == System Settings > Regional Settings > Date & Time > Time Zone When searching for the time zone I enter: Quito There are no matches. The entries for Ecuador are Galapagos Islands and Guayaquil. Quito is the capital city of Ecuador, whereas Guayaquil is the second biggest. It makes no sense for the capital not to be displayed in the city list, but to have the second. It is akin to have Marseille as the main choice for France instead of Paris. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/1988667/+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 1980937] Re: [HP EliteBook 840 G8 Notebook PC, Realtek ALC245, Speaker, Internal] No sound except loud crackling (popping) noise
I forgot to check for the internal speaker. The bug is only partially fixed by the recent updates. The internal speaker still does not work, but the 3.5mm jack works perfectly now. -- 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/1980937 Title: [HP EliteBook 840 G8 Notebook PC, Realtek ALC245, Speaker, Internal] No sound except loud crackling (popping) noise Status in alsa-driver package in Ubuntu: Confirmed Bug description: New laptop with fresh installation of Xubuntu 22.04. Intel Tiger Lake- LP audio controller. When playing any audio, the internal speaker plays no sound except periodic loud crackling noise. The 3.5mm jack does not work either, producing the same craclking noise alongside some eletrical noise. HDMI audio skimmishly tested, but also gave no sound. Curiously, USB headphone (along with microphone) works perfectly, also the internal microphone. As attempts to fix the problem, I have tried the following separately, with no avail: - Installing some Ubuntu OEM version of the 5.17 kernel - Updating to the v2.2 firmware from Sound Open Firmware Project (thesofproject on github), reverted afterwards I found exactly the same problem reported in the Fedora community: https://forums.fedoraforum.org/showthread.php?328627-HP-Elitebook-840-G8-Tiger-Lake-audio-only-produces-popping-sound=1860086 As the pre-installed Windows has been destroyed, no further test on Windows has been done. Since USB headphone and internal microphone work, I think that there is no problem on the Intel Tiger Lake-LP controller and its driver. The bug probably lies elsewhere, like in the handling of ALC245 on this new laptop model. Thank you very much for your time and effort in advance. ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: alsa-base 1.0.25+dfsg-0ubuntu7 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 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: fwjmath2810 F pulseaudio fwjmath 72467 F alsamixer CasperMD5CheckResult: pass CurrentDesktop: XFCE Date: Thu Jul 7 10:59:22 2022 InstallationDate: Installed on 2022-06-29 (7 days ago) InstallationMedia: Xubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419) PackageArchitecture: all SourcePackage: alsa-driver Symptom: audio Symptom_AlsaPlaybackTest: ALSA playback test through plughw:sofhdadsp failed Symptom_Card: Tiger Lake-LP Smart Sound Technology Audio Controller - sof-hda-dsp Symptom_DevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: fwjmath2810 F pulseaudio fwjmath 72467 F alsamixer Symptom_Jack: Speaker, Internal Symptom_Type: No sound at all Title: [HP EliteBook 840 G8 Notebook PC, Realtek ALC245, Speaker, Internal] No sound at all UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 05/05/2022 dmi.bios.release: 9.1 dmi.bios.vendor: HP dmi.bios.version: T37 Ver. 01.09.01 dmi.board.name: 8AB8 dmi.board.vendor: HP dmi.board.version: KBC Version 58.03.00 dmi.chassis.type: 10 dmi.chassis.vendor: HP dmi.ec.firmware.release: 88.3 dmi.modalias: dmi:bvnHP:bvrT37Ver.01.09.01:bd05/05/2022:br9.1:efr88.3:svnHP:pnHPEliteBook840G8NotebookPC:pvr:rvnHP:rn8AB8:rvrKBCVersion58.03.00:cvnHP:ct10:cvr:sku6A3P3AV: dmi.product.family: 103C_5336AN HP EliteBook dmi.product.name: HP EliteBook 840 G8 Notebook PC dmi.product.sku: 6A3P3AV dmi.sys.vendor: HP mtime.conffile..etc.modprobe.d.alsa-base.conf: 2022-07-02T17:07:35.783239 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1980937/+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 1970402] Re: Initrd out of memory error after upgrade to 22.04
*** This bug is a duplicate of bug 1842320 *** https://bugs.launchpad.net/bugs/1842320 Bug present on laptop model HP Pavilion Laptop 15-cs3xxx -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1970402 Title: Initrd out of memory error after upgrade to 22.04 Status in initramfs-tools package in Ubuntu: Confirmed Status in initramfs-tools source package in Jammy: Confirmed Bug description: After upgrading to 22.04 system is unbootable because of "out of memory" error when loading initial ramdisk. I was able to fix it by editing cat /etc/initramfs-tools/initramfs.conf and changing configuration to: MODULES=dep COMPRESS=xz RUNSIZE=15% Not sure which one helped, but I can test it if needed. System information: Description:Ubuntu 22.04 LTS Release:22.04 initramfs-tools: Installed: 0.140ubuntu13 Candidate: 0.140ubuntu13 Version table: *** 0.140ubuntu13 500 500 http://pl.archive.ubuntu.com/ubuntu jammy/main amd64 Packages 500 http://pl.archive.ubuntu.com/ubuntu jammy/main i386 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1970402/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1935758] Re: changing volume kills USB audio output
still happens under 5.15.0-47-generic #51-Ubuntu SMP -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1935758 Title: changing volume kills USB audio output Status in pulseaudio package in Ubuntu: New Bug description: problem happens whether changing volume using Pulseaudio, or using alsamixer from cli. Background: USB audio device EVGA NU audio installed and working at boot Action: change volume level (using pulseaudio or alsamixer) Expected: volume level change, sound keeps playing Actual result: audio output stops. More info: reloading alsa does not fix problem. reloading pulseaudio does not fix problem Following lines found in syslog: Jul 10 13:39:10 TorreyPine pulseaudio[1515]: ALSA woke us up to write new data to the device, but there was actually nothing to write. Jul 10 13:39:10 TorreyPine pulseaudio[1515]: Most likely this is a bug in the ALSA driver 'snd_usb_audio'. Please report this issue to the ALSA developers. Jul 10 13:39:10 TorreyPine pulseaudio[1515]: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail. Release info: Linux TorreyPine 5.11.0-22-generic #23-Ubuntu SMP Thu Jun 17 00:34:23 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux Pulseaudio package info: Linux TorreyPine 5.11.0-22-generic #23-Ubuntu SMP Thu Jun 17 00:34:23 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux ProblemType: Bug DistroRelease: Ubuntu 21.04 Package: pulseaudio 1:14.2-1ubuntu1.1 ProcVersionSignature: Ubuntu 5.11.0-22.23-generic 5.11.21 Uname: Linux 5.11.0-22-generic x86_64 ApportVersion: 2.20.11-0ubuntu65.1 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC1: doug 1515 F pulseaudio /dev/snd/controlC0: doug 1515 F pulseaudio CasperMD5CheckResult: unknown CurrentDesktop: XFCE Date: Sat Jul 10 13:48:52 2021 InstallationDate: Installed on 2020-04-26 (440 days ago) InstallationMedia: Xubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) ProcEnviron: LANGUAGE=en_US PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: pulseaudio UpgradeStatus: Upgraded to hirsute on 2021-05-08 (63 days ago) dmi.bios.date: 03/11/2021 dmi.bios.release: 5.17 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 3002 dmi.board.asset.tag: Default string dmi.board.name: PRIME B450-PLUS dmi.board.vendor: ASUSTeK COMPUTER INC. dmi.board.version: Rev X.0x dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr3002:bd03/11/2021:br5.17:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnPRIMEB450-PLUS:rvrRevX.0x:cvnDefaultstring:ct3:cvrDefaultstring: dmi.product.family: To be filled by O.E.M. dmi.product.name: System Product Name dmi.product.sku: SKU dmi.product.version: System Version dmi.sys.vendor: System manufacturer modified.conffile..etc.pulse.daemon.conf: [modified] mtime.conffile..etc.pulse.daemon.conf: 2020-05-15T17:21:42.290977 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1935758/+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 1983794] Re: Evolution not deleting autosave files
Lindsay, this bug isn't fixed. The upstream bug was closed. Gitlab uses
closed for both fixed and wont-fix bug statuses so Launchpad reports it
as "Fix Released" which is correct some of the time.
The bug is still open for Ubuntu's libcanberra package.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libcanberra in Ubuntu.
https://bugs.launchpad.net/bugs/1983794
Title:
Evolution not deleting autosave files
Status in Evolution:
Fix Released
Status in evolution package in Ubuntu:
Invalid
Status in libcanberra package in Ubuntu:
Triaged
Bug description:
Running Ubuntu MATE, Ubuntu 22.04.1 LTS. Evolution v3.44.1-0ubuntu1
was installed with the distribution on a new system and received
settings imported from an earlier version on another computer.
When composing an email, if the process takes long enough an autosave
file is created as ~/.local/share/evolution/.evolution-
composer.autosave-xx ("xx" is a random 6 character string).
When the email is successfully sent, the autosave file SHOULD be
deleted. It's not. When evolution is shut down and restarted I'm asked
if I want to recover an unfinished email. Answering No to this will
delete the autosave file, but otherwise it persists and the recovery
query recurs the next time I open evolution.
Other people are having the same issue, see
https://gitlab.gnome.org/GNOME/evolution/-/issues/1972. The Gnome
people aren't dealing with it, perhaps considering it a distro-
specific bug.
On a system used by many people this is a potential security issue.
To manage notifications about this bug go to:
https://bugs.launchpad.net/evolution/+bug/1983794/+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
