[Desktop-packages] [Bug 2025447] Re: Incorrect Downloads directory for LDAP user in snapped firefox & chromium
** Also affects: snapcraft Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox in Ubuntu. https://bugs.launchpad.net/bugs/2025447 Title: Incorrect Downloads directory for LDAP user in snapped firefox & chromium Status in Snapcraft: New Status in snapd: New Status in chromium package in Ubuntu: New Status in firefox package in Ubuntu: New Status in snapd package in Ubuntu: New Bug description: Test procedure: 1. Log in to Gnome as a Active Directory user. 2. Launch browser (firefox or chrome) - make sure there's no existing config (we are interested in the default Downloads location). 3. Download a file via the browser. 4. Check where it was downloaded. Expected result: The files are downloaded to ~/Downloads (or a translated equivalent). Actual result: The files are downloaded to: ~/snap/firefox/common/Downloads ~/snap/chromium/current/Downloads For local users the behavior is as expected (all files are downloaded to ~/Downloads). This is very inconvenient for enterprise environments where manual setting modification is needed on every host. This has been tested on 22.04 with the following versions: - firefox (116.0.3 Mozilla Firefox Snap for Ubuntu canonical-002 - 1.0) - chromium (Version 116.0.5845.110 (Official Build) snap (64-bit)) - snapd 2.58+22.04.1 [1] https://ubuntu.com/server/docs/service-sssd-ad To manage notifications about this bug go to: https://bugs.launchpad.net/snapcraft/+bug/2025447/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2025447] Re: Incorrect Downloads directory for LDAP user in snapped firefox & chromium
Simply replacing the line above with:
REALHOME=${SNAP_REAL_HOME}
makes the issue go away.
I'm not sure what was the purpose of the getent call, but clearly it has
problems with accessing the passwd database inside the snap sandbox.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/2025447
Title:
Incorrect Downloads directory for LDAP user in snapped firefox &
chromium
Status in snapd:
New
Status in chromium package in Ubuntu:
New
Status in firefox package in Ubuntu:
New
Status in snapd package in Ubuntu:
New
Bug description:
Test procedure:
1. Log in to Gnome as a Active Directory user.
2. Launch browser (firefox or chrome) - make sure there's no existing config
(we are interested in the default Downloads location).
3. Download a file via the browser.
4. Check where it was downloaded.
Expected result:
The files are downloaded to ~/Downloads (or a translated equivalent).
Actual result:
The files are downloaded to:
~/snap/firefox/common/Downloads
~/snap/chromium/current/Downloads
For local users the behavior is as expected (all files are downloaded
to ~/Downloads).
This is very inconvenient for enterprise environments where manual
setting modification is needed on every host.
This has been tested on 22.04 with the following versions:
- firefox (116.0.3 Mozilla Firefox Snap for Ubuntu canonical-002 - 1.0)
- chromium (Version 116.0.5845.110 (Official Build) snap (64-bit))
- snapd 2.58+22.04.1
[1] https://ubuntu.com/server/docs/service-sssd-ad
To manage notifications about this bug go to:
https://bugs.launchpad.net/snapd/+bug/2025447/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2025447] Re: Incorrect Downloads directory for LDAP user in snapped firefox & chromium
I have been looking into this issue and I've noticed that in snap/command-chain/desktop-launch line 39 cases the issue: REALHOME=$(getent passwd $UID | cut -d ':' -f 6) Inside the snap getent passwd $UID returns an empty string for the AD/LDAP user. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox in Ubuntu. https://bugs.launchpad.net/bugs/2025447 Title: Incorrect Downloads directory for LDAP user in snapped firefox & chromium Status in snapd: New Status in chromium package in Ubuntu: New Status in firefox package in Ubuntu: New Status in snapd package in Ubuntu: New Bug description: Test procedure: 1. Log in to Gnome as a Active Directory user. 2. Launch browser (firefox or chrome) - make sure there's no existing config (we are interested in the default Downloads location). 3. Download a file via the browser. 4. Check where it was downloaded. Expected result: The files are downloaded to ~/Downloads (or a translated equivalent). Actual result: The files are downloaded to: ~/snap/firefox/common/Downloads ~/snap/chromium/current/Downloads For local users the behavior is as expected (all files are downloaded to ~/Downloads). This is very inconvenient for enterprise environments where manual setting modification is needed on every host. This has been tested on 22.04 with the following versions: - firefox (116.0.3 Mozilla Firefox Snap for Ubuntu canonical-002 - 1.0) - chromium (Version 116.0.5845.110 (Official Build) snap (64-bit)) - snapd 2.58+22.04.1 [1] https://ubuntu.com/server/docs/service-sssd-ad To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/2025447/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2025447] Re: Incorrect Downloads directory for LDAP user in snapped firefox & chromium
** Description changed: - It was brought to my attention that when signed in as an LDAP- - authenticated user the default Downloads directory for snapped Firefox - and Chromium browser is not /home/user/Downloads but e.g. - /home/user/snap/firefox/common/Downloads. + Test procedure: + 1. Log in to Gnome as a Active Directory user. + 2. Launch browser (firefox or chrome) - make sure there's no existing config (we are interested in the default Downloads location). + 3. Download a file via the browser. + 4. Check where it was downloaded. - When user is set to a local one (outside of LDAP/AD) the default - Download path is /home/user/Downloads. + Expected result: + The files are downloaded to ~/Downloads (or a translated equivalent). - The issue is observed on 22.04 at least with snapd 2.58+22.04.1. I'll - post an update after checking on other releases. + Actual result: + The files are downloaded to: + ~/snap/firefox/common/Downloads + ~/snap/chromium/current/Downloads + + For local users the behavior is as expected (all files are downloaded to + ~/Downloads). + + This is very inconvenient for enterprise environments where manual + setting modification is needed on every host. + + This has been tested on 22.04 with the following versions: + - firefox (116.0.3 Mozilla Firefox Snap for Ubuntu canonical-002 - 1.0) + - chromium (Version 116.0.5845.110 (Official Build) snap (64-bit)) + - snapd 2.58+22.04.1 + + [1] https://ubuntu.com/server/docs/service-sssd-ad ** Also affects: firefox (Ubuntu) Importance: Undecided Status: New ** Also affects: snapd (Ubuntu) Importance: Undecided Status: New ** Also affects: chromium (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox in Ubuntu. https://bugs.launchpad.net/bugs/2025447 Title: Incorrect Downloads directory for LDAP user in snapped firefox & chromium Status in snapd: New Status in chromium package in Ubuntu: New Status in firefox package in Ubuntu: New Status in snapd package in Ubuntu: New Bug description: Test procedure: 1. Log in to Gnome as a Active Directory user. 2. Launch browser (firefox or chrome) - make sure there's no existing config (we are interested in the default Downloads location). 3. Download a file via the browser. 4. Check where it was downloaded. Expected result: The files are downloaded to ~/Downloads (or a translated equivalent). Actual result: The files are downloaded to: ~/snap/firefox/common/Downloads ~/snap/chromium/current/Downloads For local users the behavior is as expected (all files are downloaded to ~/Downloads). This is very inconvenient for enterprise environments where manual setting modification is needed on every host. This has been tested on 22.04 with the following versions: - firefox (116.0.3 Mozilla Firefox Snap for Ubuntu canonical-002 - 1.0) - chromium (Version 116.0.5845.110 (Official Build) snap (64-bit)) - snapd 2.58+22.04.1 [1] https://ubuntu.com/server/docs/service-sssd-ad To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/2025447/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2033381] [NEW] For AD users snapped browsers save downloads to dir under ~/snap instead of ~/Downloads by default
*** This bug is a duplicate of bug 2025447 *** https://bugs.launchpad.net/bugs/2025447 Public bug reported: Test procedure: 1. Log in to Gnome as a Active Directory user. 2. Launch browser (firefox or chrome) - make sure there's no existing config (we are interested in the default Downloads location). 3. Download a file via the browser. 4. Check where it was downloaded. Expected result: The files are downloaded to ~/Downloads (or a translated equivalent). Actual result: The files are downloaded to: ~/snap/firefox/common/Downloads ~/snap/chromium/current/Downloads For local users the behavior is as expected (all files are downloaded to ~/Downloads). This is very inconvenient for enterprise environments where manual setting modification is needed on every host. This has been tested on 22.04 with the following versions: - firefox (116.0.3 Mozilla Firefox Snap for Ubuntu canonical-002 - 1.0) - chromium (Version 116.0.5845.110 (Official Build) snap (64-bit)) - snapd 2.58+22.04.1 [1] https://ubuntu.com/server/docs/service-sssd-ad ** Affects: chromium (Ubuntu) Importance: Undecided Status: New ** Affects: firefox (Ubuntu) Importance: Undecided Status: New ** Summary changed: - For AD users snapped browser save downloads to dir under ~/snap instead of ~/Downloads by default + For AD users snapped browsers save downloads to dir under ~/snap instead of ~/Downloads by default ** Also affects: chromium (Ubuntu) Importance: Undecided Status: New ** Description changed: Test procedure: 1. Log in to Gnome as a Active Directory user. 2. Launch browser (firefox or chrome) - make sure there's no existing config (we are interested in the default Downloads location). 3. Download a file via the browser. 4. Check where it was downloaded. Expected result: The files are downloaded to ~/Downloads (or a translated equivalent). Actual result: The files are downloaded to: ~/snap/firefox/common/Downloads ~/snap/chromium/current/Downloads For local users the behavior is as expected (all files are downloaded to ~/Downloads). + This is very inconvenient for enterprise environments where manual + setting modification is needed on every host. + This has been tested on 22.04 with the following versions: - firefox (116.0.3 Mozilla Firefox Snap for Ubuntu canonical-002 - 1.0) - chromium (Version 116.0.5845.110 (Official Build) snap (64-bit)) - snapd 2.58+22.04.1 [1] https://ubuntu.com/server/docs/service-sssd-ad ** This bug has been marked a duplicate of bug 2025447 Incorrect Downloads directory for LDAP user in snapped firefox & chromium -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox in Ubuntu. https://bugs.launchpad.net/bugs/2033381 Title: For AD users snapped browsers save downloads to dir under ~/snap instead of ~/Downloads by default Status in chromium package in Ubuntu: New Status in firefox package in Ubuntu: New Bug description: Test procedure: 1. Log in to Gnome as a Active Directory user. 2. Launch browser (firefox or chrome) - make sure there's no existing config (we are interested in the default Downloads location). 3. Download a file via the browser. 4. Check where it was downloaded. Expected result: The files are downloaded to ~/Downloads (or a translated equivalent). Actual result: The files are downloaded to: ~/snap/firefox/common/Downloads ~/snap/chromium/current/Downloads For local users the behavior is as expected (all files are downloaded to ~/Downloads). This is very inconvenient for enterprise environments where manual setting modification is needed on every host. This has been tested on 22.04 with the following versions: - firefox (116.0.3 Mozilla Firefox Snap for Ubuntu canonical-002 - 1.0) - chromium (Version 116.0.5845.110 (Official Build) snap (64-bit)) - snapd 2.58+22.04.1 [1] https://ubuntu.com/server/docs/service-sssd-ad To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium/+bug/2033381/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2026120] [NEW] xf86CloseConsole: KDSETMODE failed: Input/output error
Public bug reported: On every reboot the following messages are shown in the journal: /usr/libexec/gdm-x-session[14875]: (II) NVIDIA(GPU-0): Deleting GPU-0 /usr/libexec/gdm-x-session[14875]: (WW) xf86CloseConsole: KDSETMODE failed: Input/output error /usr/libexec/gdm-x-session[14875]: (WW) xf86CloseConsole: VT_GETMODE failed: Input/output error This is consistent on every reboot on several machines (including a cloud VM and metal). I was able to observe it on mantic and on jammy. Is this a result of the GPU being deleted prematurely? ** Affects: xorg-server (Ubuntu) Importance: Low Status: New ** Changed in: xorg-server (Ubuntu) Importance: Undecided => Low -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xorg-server in Ubuntu. https://bugs.launchpad.net/bugs/2026120 Title: xf86CloseConsole: KDSETMODE failed: Input/output error Status in xorg-server package in Ubuntu: New Bug description: On every reboot the following messages are shown in the journal: /usr/libexec/gdm-x-session[14875]: (II) NVIDIA(GPU-0): Deleting GPU-0 /usr/libexec/gdm-x-session[14875]: (WW) xf86CloseConsole: KDSETMODE failed: Input/output error /usr/libexec/gdm-x-session[14875]: (WW) xf86CloseConsole: VT_GETMODE failed: Input/output error This is consistent on every reboot on several machines (including a cloud VM and metal). I was able to observe it on mantic and on jammy. Is this a result of the GPU being deleted prematurely? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/2026120/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 2007746] Re: [SRU] xserver crashes when hyperv_drm kernel module is loaded on azure NV series instances w/ nvidia grid driver
** Tags added: se sts -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xorg-server in Ubuntu. https://bugs.launchpad.net/bugs/2007746 Title: [SRU] xserver crashes when hyperv_drm kernel module is loaded on azure NV series instances w/ nvidia grid driver Status in xorg-server package in Ubuntu: Fix Released Status in xorg-server source package in Focal: In Progress Bug description: [ Impact ] * Microsoft Azure NV-series instances with NVidia GRID drivers started to experience xserver crashes while following Microsoft's official guide to installing Nvidia drivers [1]. * Root cause analysis showed that it was due to having a device with BusID "PCI:0@:0:0", where domain id is >= 32767 while the hyperv_drm kernel module is loaded. * Removing either the BusID specification or unloading the hyperv_drm kernel module seems to fix the crash. * The crash is happening while X.server is trying to enumerate PCI devices. X.server dereferences a NULL pointer while trying to access to the PCI device info. * The reason why it only happens while the hyperv_drm kernel module is loaded is that the hyperv_drm module does not expose PCI hardware information since it's a virtual device. * The upstream patch [2] addresses the issue and it's confirmed that the xserver with the patch does not experience the crash. * Ubuntu Focal `xorg-server` package does not include the patch [2] at the moment (xserver-xorg-core=2:1.20.13-1ubuntu1~20.04.6). [1]: https://learn.microsoft.com/en-us/azure/virtual-machines/linux/n-series-driver-setup#install-grid-drivers-on-nv-or-nvv3-series-vms [2]: https://github.com/freedesktop/xorg-xserver/commit/0d93bbfa2cfacbb73741f8bed0e32fa1a656b928 [ Test Plan ] Part (a) is quoted from Microsoft's official guide [1]. Part (a): * Spawn a Microsoft Azure NV-series instance with an NVidia GRID-supported GPU - e.g. `NV36adms A10` * Install updates, required tooling, and the desktop environment: - sudo apt-get update - sudo apt-get upgrade -y - sudo apt-get dist-upgrade -y - sudo apt-get install build-essential ubuntu-desktop -y - sudo apt-get install linux-azure -y * Disable nouveau kernel driver: # Create a blacklist file /etc/modprobe.d/nouveau.conf with following contents: blacklist nouveau blacklist lbm-nouveau * Reboot the VM, re-connect, and then stop X server: - sudo reboot # wait for the reboot, reconnect, and continue: - sudo systemctl stop lightdm.service * Download and install the NVidia GRID driver: - wget -O NVIDIA-Linux-x86_64-grid.run https://go.microsoft.com/fwlink/?linkid=874272 - chmod +x NVIDIA-Linux-x86_64-grid.run - sudo ./NVIDIA-Linux-x86_64-grid.run - # When the setup asks whether you want to run the nvidia-xconfig utility to update your X configuration file, select Yes. * Copy /etc/nvidia/gridd.conf.template to /etc/nvidia/gridd.conf - sudo cp /etc/nvidia/gridd.conf.template /etc/nvidia/gridd.conf * Edit /etc/nvidia/grid.conf - sudo nano /etc/nvidia/grid.conf # Append the following lines: IgnoreSP=FALSE EnableUI=FALSE # Remove this line if present: FeatureType=0 # And save. * Reboot the VM Part (b): * Ensure that the hyperv_drm kernel module is loaded: - sudo modprobe hyperv_drm * Use the attached xorg.conf file to override /etc/X11/xorg.conf file * try to start the `xserver`: - sudo startx * `xserver` should crash with a similar output to the following: X.Org X Server 1.20.13 X Protocol Version 11, Revision 0 Build Operating System: linux Ubuntu Current Operating System: Linux a10test 5.15.0-1031-azure #38~20.04.1-Ubuntu SMP Mon Jan 9 18:23:48 UTC 2023 x86_64 Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.15.0-1031-azure root=PARTUUID=4cac852b-afba-447b-b3e7-c002155c1305 ro console=tty1 console=ttyS0 earlyprintk=ttyS0 panic=-1 Build Date: 07 February 2023 12:48:13PM xorg-server 2:1.20.13-1ubuntu1~20.04.6 (For technical support please see http://www.ubuntu.com/support) Current version of pixman: 0.38.4 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.1.log", Time: Sat Feb 18 10:54:26 2023 (==) Using config file: "/etc/X11/xorg.conf" (==) Using system config directory "/usr/share/X11/xorg.conf.d" (EE) (EE) Backtrace: (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x13c) [0x55e7787c5ecc] (EE) 1: /lib/x86_64-linux-gnu/libpthread.so.0 (funlockfile+0x60) [0x7f9576cac420] (EE) 2: /usr/lib/xorg/Xorg
[Desktop-packages] [Bug 2007746] Re: [SRU] xserver crashes when hyperv_drm kernel module is loaded on azure NV series instances w/ nvidia grid driver
** Tags added: se-sponsor-dgadomski -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xorg-server in Ubuntu. https://bugs.launchpad.net/bugs/2007746 Title: [SRU] xserver crashes when hyperv_drm kernel module is loaded on azure NV series instances w/ nvidia grid driver Status in xorg-server package in Ubuntu: Fix Released Status in xorg-server source package in Focal: In Progress Bug description: [ Impact ] * Microsoft Azure NV-series instances with NVidia GRID drivers started to experience xserver crashes while following Microsoft's official guide to installing Nvidia drivers [1]. * Root cause analysis showed that it was due to having a device with BusID "PCI:0@:0:0", where domain id is >= 32767 while the hyperv_drm kernel module is loaded. * Removing either the BusID specification or unloading the hyperv_drm kernel module seems to fix the crash. * The crash is happening while X.server is trying to enumerate PCI devices. X.server dereferences a NULL pointer while trying to access to the PCI device info. * The reason why it only happens while the hyperv_drm kernel module is loaded is that the hyperv_drm module does not expose PCI hardware information since it's a virtual device. * The upstream patch [2] addresses the issue and it's confirmed that the xserver with the patch does not experience the crash. * Ubuntu Focal `xorg-server` package does not include the patch [2] at the moment (xserver-xorg-core=2:1.20.13-1ubuntu1~20.04.6). [1]: https://learn.microsoft.com/en-us/azure/virtual-machines/linux/n-series-driver-setup#install-grid-drivers-on-nv-or-nvv3-series-vms [2]: https://github.com/freedesktop/xorg-xserver/commit/0d93bbfa2cfacbb73741f8bed0e32fa1a656b928 [ Test Plan ] Part (a) is quoted from Microsoft's official guide [1]. Part (a): * Spawn a Microsoft Azure NV-series instance with an NVidia GRID-supported GPU - e.g. `NV36adms A10` * Install updates, required tooling, and the desktop environment: - sudo apt-get update - sudo apt-get upgrade -y - sudo apt-get dist-upgrade -y - sudo apt-get install build-essential ubuntu-desktop -y - sudo apt-get install linux-azure -y * Disable nouveau kernel driver: # Create a blacklist file /etc/modprobe.d/nouveau.conf with following contents: blacklist nouveau blacklist lbm-nouveau * Reboot the VM, re-connect, and then stop X server: - sudo reboot # wait for the reboot, reconnect, and continue: - sudo systemctl stop lightdm.service * Download and install the NVidia GRID driver: - wget -O NVIDIA-Linux-x86_64-grid.run https://go.microsoft.com/fwlink/?linkid=874272 - chmod +x NVIDIA-Linux-x86_64-grid.run - sudo ./NVIDIA-Linux-x86_64-grid.run - # When the setup asks whether you want to run the nvidia-xconfig utility to update your X configuration file, select Yes. * Copy /etc/nvidia/gridd.conf.template to /etc/nvidia/gridd.conf - sudo cp /etc/nvidia/gridd.conf.template /etc/nvidia/gridd.conf * Edit /etc/nvidia/grid.conf - sudo nano /etc/nvidia/grid.conf # Append the following lines: IgnoreSP=FALSE EnableUI=FALSE # Remove this line if present: FeatureType=0 # And save. * Reboot the VM Part (b): * Ensure that the hyperv_drm kernel module is loaded: - sudo modprobe hyperv_drm * Use the attached xorg.conf file to override /etc/X11/xorg.conf file * try to start the `xserver`: - sudo startx * `xserver` should crash with a similar output to the following: X.Org X Server 1.20.13 X Protocol Version 11, Revision 0 Build Operating System: linux Ubuntu Current Operating System: Linux a10test 5.15.0-1031-azure #38~20.04.1-Ubuntu SMP Mon Jan 9 18:23:48 UTC 2023 x86_64 Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.15.0-1031-azure root=PARTUUID=4cac852b-afba-447b-b3e7-c002155c1305 ro console=tty1 console=ttyS0 earlyprintk=ttyS0 panic=-1 Build Date: 07 February 2023 12:48:13PM xorg-server 2:1.20.13-1ubuntu1~20.04.6 (For technical support please see http://www.ubuntu.com/support) Current version of pixman: 0.38.4 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.1.log", Time: Sat Feb 18 10:54:26 2023 (==) Using config file: "/etc/X11/xorg.conf" (==) Using system config directory "/usr/share/X11/xorg.conf.d" (EE) (EE) Backtrace: (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x13c) [0x55e7787c5ecc] (EE) 1: /lib/x86_64-linux-gnu/libpthread.so.0 (funlockfile+0x60) [0x7f9576cac420] (EE) 2: /usr/lib/xorg/Xorg
[Desktop-packages] [Bug 1931603] Re: [apparmor] Unable to show Downloads with apparmor enabled
** Description changed: [Impact] * After a finished download (or opening the downloads list) it is impossible to "Open Containing Folder" for a downloaded file - pressing the button does nothing visible. [Test Plan] * sudo aa-enforce /etc/apparmor.d/usr.bin.firefox * launch Firefox * Download a file. * Go to downloads list. * Press the "Open Containing Folder" button next to the downloaded file on the list. [Where problems could occur] + Unlocking the possibility of launching file browser from Firefox, that + was not working before may result in windows popping up where they have + not earlier (e.g. from the Downloads window, downloads list). + [Other Info] -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox in Ubuntu. https://bugs.launchpad.net/bugs/1931603 Title: [apparmor] Unable to show Downloads with apparmor enabled Status in firefox package in Ubuntu: Invalid Status in firefox source package in Focal: Confirmed Status in firefox source package in Hirsute: Won't Fix Status in firefox source package in Impish: Confirmed Bug description: [Impact] * After a finished download (or opening the downloads list) it is impossible to "Open Containing Folder" for a downloaded file - pressing the button does nothing visible. [Test Plan] * sudo aa-enforce /etc/apparmor.d/usr.bin.firefox * launch Firefox * Download a file. * Go to downloads list. * Press the "Open Containing Folder" button next to the downloaded file on the list. [Where problems could occur] Unlocking the possibility of launching file browser from Firefox, that was not working before may result in windows popping up where they have not earlier (e.g. from the Downloads window, downloads list). [Other Info] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1931603/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1931603] Re: [apparmor] Unable to show Downloads with apparmor enabled
** Changed in: firefox (Ubuntu) Status: Invalid => In Progress -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox in Ubuntu. https://bugs.launchpad.net/bugs/1931603 Title: [apparmor] Unable to show Downloads with apparmor enabled Status in firefox package in Ubuntu: In Progress Status in firefox source package in Focal: Confirmed Status in firefox source package in Hirsute: Won't Fix Status in firefox source package in Impish: Confirmed Bug description: [Impact] * After a finished download (or opening the downloads list) it is impossible to "Open Containing Folder" for a downloaded file - pressing the button does nothing visible. [Test Plan] * sudo aa-enforce /etc/apparmor.d/usr.bin.firefox * launch Firefox * Download a file. * Go to downloads list. * Press the "Open Containing Folder" button next to the downloaded file on the list. [Where problems could occur] [Other Info] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1931603/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1938355] Re: When enabled, Firefox AppArmor profile blocks 'Open Containing Folder' function for downloads
*** This bug is a duplicate of bug 1931603 ***
https://bugs.launchpad.net/bugs/1931603
** This bug has been marked a duplicate of bug 1931603
[apparmor] Unable to show Downloads with apparmor enabled
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1938355
Title:
When enabled, Firefox AppArmor profile blocks 'Open Containing Folder'
function for downloads
Status in firefox package in Ubuntu:
New
Bug description:
When a firefox user has downloaded a file, the download dropdown
includes an 'Open Containing Folder' option which does what the name
implies.
When AppArmor is enabled, this button stops working. Instead, the
following denials are logged:-
dbus-daemon[6348]: apparmor="DENIED" operation="dbus_method_call"
bus="session" path="/org/freedesktop/FileManager1"
interface="org.freedesktop.FileManager1" member="ShowItems"
mask="send" name="org.freedesktop.FileManager1" pid=6874
label="firefox" peer_pid=8779 peer_label="unconfined"
dbus-daemon[6348]: apparmor="DENIED" operation="dbus_method_call"
bus="session" path="/org/gnome/Nautilus"
interface="org.freedesktop.Application" member="Open" mask="send"
name="org.gnome.Nautilus" pid=6874 label="firefox" peer_pid=8779
peer_label="unconfined"
Adding the following permissions to /etc/apparmor.d/usr.bin.firefox
fixes the issue:-
# 'Open Containing Folder' function for downloads
dbus (send)
bus=session
path=/org/freedesktop/FileManager1
interface=org.freedesktop.FileManager1
member="ShowItems"
peer=(label=unconfined),
dbus (send)
bus=session
path=/org/gnome/Nautilus
interface=org.freedesktop.Application
member="Open"
peer=(label=unconfined),
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: firefox 90.0+build1-0ubuntu0.20.04.1
ProcVersionSignature: Ubuntu 5.8.0-63.71~20.04.1-generic 5.8.18
Uname: Linux 5.8.0-63-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
AddonCompatCheckDisabled: False
ApportVersion: 2.20.11-0ubuntu27.18
Architecture: amd64
AudioDevicesInUse:
USERPID ACCESS COMMAND
/dev/snd/controlC0: mtandy 6342 F pulseaudio
/dev/snd/pcmC0D0p: mtandy 6342 F...m pulseaudio
/dev/snd/controlC1: mtandy 6342 F pulseaudio
BuildID: 20210705185941
CasperMD5CheckResult: skip
Channel: Unavailable
CurrentDesktop: ubuntu:GNOME
Date: Thu Jul 29 00:04:41 2021
ForcedLayersAccel: False
IncompatibleExtensions: Default - {972ce4c6-7e08-4474-a285-3208198ce6fd}
InstallationDate: Installed on 2021-05-31 (58 days ago)
InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64
(20210209.1)
IpRoute:
default via 192.168.0.1 dev enp3s0 proto dhcp metric 100
169.254.0.0/16 dev enp3s0 scope link metric 1000
192.168.0.0/24 dev enp3s0 proto kernel scope link src 192.168.0.2 metric 100
MostRecentCrashID: bp-4122b123-9c74-4baf-b817-c8a771171216
PrefErrors: Unexpected character ',' before close parenthesis @
/usr/lib/firefox/omni.ja:greprefs.js:352
PrefSources: prefs.js
Profiles: Profile0 (Default) - LastVersion=90.0/20210705185941 (In use)
RunningIncompatibleAddons: True
SourcePackage: firefox
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 07/11/2014
dmi.bios.release: 4.6
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 2202
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: Z97-K
dmi.board.vendor: ASUSTeK COMPUTER INC.
dmi.board.version: Rev X.0x
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: To Be Filled By O.E.M.
dmi.chassis.version: To Be Filled By O.E.M.
dmi.modalias:
dmi:bvnAmericanMegatrendsInc.:bvr2202:bd07/11/2014:br4.6:svnASUS:pnAllSeries:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnZ97-K:rvrRevX.0x:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
dmi.product.family: ASUS MB
dmi.product.name: All Series
dmi.product.sku: All
dmi.product.version: System Version
dmi.sys.vendor: ASUS
mtime.conffile..etc.apparmor.d.usr.bin.firefox: 2021-07-28T23:39:29.648857
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1938355/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1931603] Re: [apparmor] Unable to show Downloads with apparmor enabled
Fix proposal for focal. ** Patch added: "focal.debdiff" https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1931603/+attachment/5586948/+files/focal.debdiff -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox in Ubuntu. https://bugs.launchpad.net/bugs/1931603 Title: [apparmor] Unable to show Downloads with apparmor enabled Status in firefox package in Ubuntu: Invalid Status in firefox source package in Focal: New Status in firefox source package in Hirsute: Won't Fix Status in firefox source package in Impish: New Bug description: [Impact] * After a finished download (or opening the downloads list) it is impossible to "Open Containing Folder" for a downloaded file - pressing the button does nothing visible. [Test Plan] * sudo aa-enforce /etc/apparmor.d/usr.bin.firefox * launch Firefox * Download a file. * Go to downloads list. * Press the "Open Containing Folder" button next to the downloaded file on the list. [Where problems could occur] [Other Info] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1931603/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1931603] Re: [apparmor] Unable to show Downloads with apparmor enabled
Marking as "invalid" for the development release due to transition to snaps. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox in Ubuntu. https://bugs.launchpad.net/bugs/1931603 Title: [apparmor] Unable to show Downloads with apparmor enabled Status in firefox package in Ubuntu: Invalid Status in firefox source package in Focal: New Status in firefox source package in Hirsute: Won't Fix Status in firefox source package in Impish: New Bug description: [Impact] * After a finished download (or opening the downloads list) it is impossible to "Open Containing Folder" for a downloaded file - pressing the button does nothing visible. [Test Plan] * sudo aa-enforce /etc/apparmor.d/usr.bin.firefox * launch Firefox * Download a file. * Go to downloads list. * Press the "Open Containing Folder" button next to the downloaded file on the list. [Where problems could occur] [Other Info] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1931603/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1931603] Re: [apparmor] Unable to show Downloads with apparmor enabled
Attaching impish fix proposal. ** Patch added: "impish.debdiff" https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1931603/+attachment/5586947/+files/impish.debdiff ** Changed in: firefox (Ubuntu Focal) Importance: Undecided => Medium ** Changed in: firefox (Ubuntu Impish) Importance: Undecided => Medium ** Changed in: firefox (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox in Ubuntu. https://bugs.launchpad.net/bugs/1931603 Title: [apparmor] Unable to show Downloads with apparmor enabled Status in firefox package in Ubuntu: Invalid Status in firefox source package in Focal: New Status in firefox source package in Hirsute: Won't Fix Status in firefox source package in Impish: New Bug description: [Impact] * After a finished download (or opening the downloads list) it is impossible to "Open Containing Folder" for a downloaded file - pressing the button does nothing visible. [Test Plan] * sudo aa-enforce /etc/apparmor.d/usr.bin.firefox * launch Firefox * Download a file. * Go to downloads list. * Press the "Open Containing Folder" button next to the downloaded file on the list. [Where problems could occur] [Other Info] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1931603/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1931603] Re: [apparmor] Unable to show Downloads with apparmor enabled
** Description changed: - Impact] + [Impact] - * After a finished download (or opening the downloads list) it is + * After a finished download (or opening the downloads list) it is impossible to "Open Containing Folder" for a downloaded file - pressing the button does nothing visible. [Test Plan] - * sudo aa-enforce /etc/apparmor.d/usr.bin.firefox + * sudo aa-enforce /etc/apparmor.d/usr.bin.firefox - * launch Firefox + * launch Firefox - * Download a file. + * Download a file. - * Go to downloads list. + * Go to downloads list. - * Press the "Open Containing Folder" button next to the downloaded file + * Press the "Open Containing Folder" button next to the downloaded file on the list. [Where problems could occur] [Other Info] -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox in Ubuntu. https://bugs.launchpad.net/bugs/1931603 Title: [apparmor] Unable to show Downloads with apparmor enabled Status in firefox package in Ubuntu: New Status in firefox source package in Focal: New Status in firefox source package in Hirsute: Won't Fix Status in firefox source package in Impish: New Bug description: [Impact] * After a finished download (or opening the downloads list) it is impossible to "Open Containing Folder" for a downloaded file - pressing the button does nothing visible. [Test Plan] * sudo aa-enforce /etc/apparmor.d/usr.bin.firefox * launch Firefox * Download a file. * Go to downloads list. * Press the "Open Containing Folder" button next to the downloaded file on the list. [Where problems could occur] [Other Info] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1931603/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1948008] Re: Copying and pasting files between desktop and Nautilus does not work
Hey Dan. I've been trying to backport it to 21.10 (available in ppa:dgadomski/lp1948008-desktop-icons) but it seems to work only one-way for now. I am looking into this. 20.04 on the other hand seems even more complicated, I will look into it right after I get 21.10 working, but can't provide any estimates at this point. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell-extension-desktop-icons in Ubuntu. https://bugs.launchpad.net/bugs/1948008 Title: Copying and pasting files between desktop and Nautilus does not work Status in Gnome Shell Extension Desktop Icons Ng: Unknown Status in gnome-shell package in Ubuntu: Confirmed Status in gnome-shell-extension-desktop-icons package in Ubuntu: Confirmed Status in gnome-shell-extension-desktop-icons-ng package in Ubuntu: Fix Released Status in gnome-shell source package in Focal: Confirmed Status in gnome-shell-extension-desktop-icons source package in Focal: Confirmed Status in gnome-shell-extension-desktop-icons-ng source package in Focal: Invalid Status in gnome-shell source package in Hirsute: Fix Released Status in gnome-shell-extension-desktop-icons source package in Hirsute: Invalid Status in gnome-shell-extension-desktop-icons-ng source package in Hirsute: Won't Fix Status in gnome-shell source package in Impish: Fix Released Status in gnome-shell-extension-desktop-icons source package in Impish: Invalid Status in gnome-shell-extension-desktop-icons-ng source package in Impish: Confirmed Bug description: [Impact] * After upstream Nautilus has reverted the following commit [1] related to upstream bug [2] the desktop icons extension lost it's ability to copy to/from nautilus. * This is related to the fact that before there was some metadata passed along in the clipboard along with text data. This was causing issues with compatibility with some applications that were not expecting any metadata (MIME type in this case) was glued to the text clipboard contents. Hence, it was reverted upstream [3]. * Fixing the root cause of this issue required changes to Nautilus [3], gnome-shell [4] and desktop-icons [5] [6]. Nautilus and gnome- shell parts are already implemented and present in Hirsute and Impish. [Test Plan] 1) Make sure desktop-icons extension is enabled. 2) Open nautilus window and copy any file from there by right-clicking and selecting "Copy" from the popup menu. 3) Right-click on desktop and select "Paste" from the context menu. Expected result: selected file is copied to the desktop. Actual result: "Paste" item is disabled in the menu. [Where problems could occur] * Mixing a version of nautilus without commit [3] and fixed version of desktop-icons may still lead to a scenario when copying will not work. * Any extension/application copying to desktop using the smuggled-in- text clipboard behavior should be expected to stop working. [Other Info] [1] https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/289 [2] https://gitlab.gnome.org/GNOME/nautilus/-/issues/634 [3] https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/573 [4] https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1321 [5] https://gitlab.gnome.org/World/ShellExtensions/desktop-icons/-/merge_requests/186 [6] https://gitlab.gnome.org/World/ShellExtensions/desktop-icons/-/merge_requests/195 To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-shell-extension-desktop-icons-ng/+bug/1948008/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1948008] Re: Copying and pasting files between desktop and Nautilus does not work
It seems this has been fixed with https://gitlab.com/rastersoft/desktop- icons-ng/-/commit/4c6de6a39f3e0d7ccff4399cb06f4bcd6485c047 I'll look into a way of backporting it into impish. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell-extension-desktop-icons in Ubuntu. https://bugs.launchpad.net/bugs/1948008 Title: Copying and pasting files between desktop and Nautilus does not work Status in gnome-shell package in Ubuntu: Confirmed Status in gnome-shell-extension-desktop-icons package in Ubuntu: Confirmed Status in gnome-shell-extension-desktop-icons-ng package in Ubuntu: Fix Released Status in gnome-shell source package in Focal: Confirmed Status in gnome-shell-extension-desktop-icons source package in Focal: Confirmed Status in gnome-shell-extension-desktop-icons-ng source package in Focal: Invalid Status in gnome-shell source package in Hirsute: Fix Released Status in gnome-shell-extension-desktop-icons source package in Hirsute: Invalid Status in gnome-shell-extension-desktop-icons-ng source package in Hirsute: Won't Fix Status in gnome-shell source package in Impish: Fix Released Status in gnome-shell-extension-desktop-icons source package in Impish: Invalid Status in gnome-shell-extension-desktop-icons-ng source package in Impish: Confirmed Bug description: [Impact] * After upstream Nautilus has reverted the following commit [1] related to upstream bug [2] the desktop icons extension lost it's ability to copy to/from nautilus. * This is related to the fact that before there was some metadata passed along in the clipboard along with text data. This was causing issues with compatibility with some applications that were not expecting any metadata (MIME type in this case) was glued to the text clipboard contents. Hence, it was reverted upstream [3]. * Fixing the root cause of this issue required changes to Nautilus [3], gnome-shell [4] and desktop-icons [5] [6]. Nautilus and gnome- shell parts are already implemented and present in Hirsute and Impish. [Test Plan] 1) Make sure desktop-icons extension is enabled. 2) Open nautilus window and copy any file from there by right-clicking and selecting "Copy" from the popup menu. 3) Right-click on desktop and select "Paste" from the context menu. Expected result: selected file is copied to the desktop. Actual result: "Paste" item is disabled in the menu. [Where problems could occur] * Mixing a version of nautilus without commit [3] and fixed version of desktop-icons may still lead to a scenario when copying will not work. * Any extension/application copying to desktop using the smuggled-in- text clipboard behavior should be expected to stop working. [Other Info] [1] https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/289 [2] https://gitlab.gnome.org/GNOME/nautilus/-/issues/634 [3] https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/573 [4] https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1321 [5] https://gitlab.gnome.org/World/ShellExtensions/desktop-icons/-/merge_requests/186 [6] https://gitlab.gnome.org/World/ShellExtensions/desktop-icons/-/merge_requests/195 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1948008/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1948008] Re: Copying and pasting files between desktop and Nautilus does not work
Thank you for this observation Gunnar. Indeed, looks like its fixed for jammy. I'll try to figure out the right commit and backport it. ** Changed in: gnome-shell-extension-desktop-icons-ng (Ubuntu) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell-extension-desktop-icons in Ubuntu. https://bugs.launchpad.net/bugs/1948008 Title: Copying and pasting files between desktop and Nautilus does not work Status in gnome-shell package in Ubuntu: Confirmed Status in gnome-shell-extension-desktop-icons package in Ubuntu: Confirmed Status in gnome-shell-extension-desktop-icons-ng package in Ubuntu: Fix Released Status in gnome-shell source package in Focal: Confirmed Status in gnome-shell-extension-desktop-icons source package in Focal: Confirmed Status in gnome-shell-extension-desktop-icons-ng source package in Focal: Invalid Status in gnome-shell source package in Hirsute: Fix Released Status in gnome-shell-extension-desktop-icons source package in Hirsute: Invalid Status in gnome-shell-extension-desktop-icons-ng source package in Hirsute: Won't Fix Status in gnome-shell source package in Impish: Fix Released Status in gnome-shell-extension-desktop-icons source package in Impish: Invalid Status in gnome-shell-extension-desktop-icons-ng source package in Impish: Confirmed Bug description: [Impact] * After upstream Nautilus has reverted the following commit [1] related to upstream bug [2] the desktop icons extension lost it's ability to copy to/from nautilus. * This is related to the fact that before there was some metadata passed along in the clipboard along with text data. This was causing issues with compatibility with some applications that were not expecting any metadata (MIME type in this case) was glued to the text clipboard contents. Hence, it was reverted upstream [3]. * Fixing the root cause of this issue required changes to Nautilus [3], gnome-shell [4] and desktop-icons [5] [6]. Nautilus and gnome- shell parts are already implemented and present in Hirsute and Impish. [Test Plan] 1) Make sure desktop-icons extension is enabled. 2) Open nautilus window and copy any file from there by right-clicking and selecting "Copy" from the popup menu. 3) Right-click on desktop and select "Paste" from the context menu. Expected result: selected file is copied to the desktop. Actual result: "Paste" item is disabled in the menu. [Where problems could occur] * Mixing a version of nautilus without commit [3] and fixed version of desktop-icons may still lead to a scenario when copying will not work. * Any extension/application copying to desktop using the smuggled-in- text clipboard behavior should be expected to stop working. [Other Info] [1] https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/289 [2] https://gitlab.gnome.org/GNOME/nautilus/-/issues/634 [3] https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/573 [4] https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1321 [5] https://gitlab.gnome.org/World/ShellExtensions/desktop-icons/-/merge_requests/186 [6] https://gitlab.gnome.org/World/ShellExtensions/desktop-icons/-/merge_requests/195 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1948008/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1931602] Re: [apparmor] Segfault in logs with apparmor enabled
Attaching a fix proposal for jammy. ** Patch added: "jammy.debdiff" https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1931602/+attachment/5539262/+files/jammy.debdiff ** Changed in: firefox (Ubuntu Focal) Importance: Undecided => Medium ** Changed in: firefox (Ubuntu Hirsute) Importance: Undecided => Medium ** Changed in: firefox (Ubuntu Impish) Importance: Undecided => Medium ** Changed in: firefox (Ubuntu Impish) Importance: Medium => Low ** Changed in: firefox (Ubuntu Hirsute) Importance: Medium => Low ** Changed in: firefox (Ubuntu Focal) Importance: Medium => Low ** Changed in: firefox (Ubuntu) Importance: Medium => Low ** Tags added: sts-sponsor-dgadomski -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox in Ubuntu. https://bugs.launchpad.net/bugs/1931602 Title: [apparmor] Segfault in logs with apparmor enabled Status in firefox package in Ubuntu: Confirmed Status in firefox source package in Focal: Confirmed Status in firefox source package in Hirsute: New Status in firefox source package in Impish: New Bug description: [Impact] * With apparmor enabled (and usr.bin.firefox in enforce mode) there is a crash happening every time right after launching Firefox. [Test Plan] * sudo aa-enforce /etc/apparmor.d/usr.bin.firefox * launch Firefox * See a similar segfault reported in the syslog: Jun 10 17:25:40 ubuntu kernel: [ 86.775837] firefox[1765]: segfault at 0 ip 7f724dd06384 sp 7fffa7aec450 error 6 in libxul.so[7f724a483000+53b2000] Jun 10 17:25:40 ubuntu kernel: [ 86.775843] Code: 00 0f 1f 44 00 00 50 80 3d f8 56 4c 04 00 74 02 58 c3 c6 05 ed 56 4c 04 01 48 8d 05 24 2c fa 02 48 8b 0d 77 f0 3a 04 48 89 01 04 25 00 00 00 00 8d 01 00 00 e8 74 63 78 fc 66 2e 0f 1f 84 00 [Where problems could occur] The fix adds additional paths to firefox apparmor profile (e.g. affecting /sys/devices/pci* and RealtimeKit1). When using deb version of firefox the browser may chose a different code path to execute than before, so it may affect hw acceleration (the sysfs paths were used by libxul) and audio. Maybe rendering artifacts and audio sync issues in videos. [Other Info] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1931602/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1931602] Re: [apparmor] Segfault in logs with apparmor enabled
** Changed in: firefox (Ubuntu Hirsute) Assignee: (unassigned) => Dariusz Gadomski (dgadomski) ** Changed in: firefox (Ubuntu Impish) Assignee: (unassigned) => Dariusz Gadomski (dgadomski) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox in Ubuntu. https://bugs.launchpad.net/bugs/1931602 Title: [apparmor] Segfault in logs with apparmor enabled Status in firefox package in Ubuntu: Confirmed Status in firefox source package in Focal: Confirmed Status in firefox source package in Hirsute: New Status in firefox source package in Impish: New Bug description: [Impact] * With apparmor enabled (and usr.bin.firefox in enforce mode) there is a crash happening every time right after launching Firefox. [Test Plan] * sudo aa-enforce /etc/apparmor.d/usr.bin.firefox * launch Firefox * See a similar segfault reported in the syslog: Jun 10 17:25:40 ubuntu kernel: [ 86.775837] firefox[1765]: segfault at 0 ip 7f724dd06384 sp 7fffa7aec450 error 6 in libxul.so[7f724a483000+53b2000] Jun 10 17:25:40 ubuntu kernel: [ 86.775843] Code: 00 0f 1f 44 00 00 50 80 3d f8 56 4c 04 00 74 02 58 c3 c6 05 ed 56 4c 04 01 48 8d 05 24 2c fa 02 48 8b 0d 77 f0 3a 04 48 89 01 04 25 00 00 00 00 8d 01 00 00 e8 74 63 78 fc 66 2e 0f 1f 84 00 [Where problems could occur] The fix adds additional paths to firefox apparmor profile (e.g. affecting /sys/devices/pci* and RealtimeKit1). When using deb version of firefox the browser may chose a different code path to execute than before, so it may affect hw acceleration (the sysfs paths were used by libxul) and audio. Maybe rendering artifacts and audio sync issues in videos. [Other Info] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1931602/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1931602] Re: [apparmor] Segfault in logs with apparmor enabled
** Description changed: [Impact] - * With apparmor enabled (and usr.bin.firefox in enforce mode) there is + * With apparmor enabled (and usr.bin.firefox in enforce mode) there is a crash happening every time right after launching Firefox. [Test Plan] - * sudo aa-enforce /etc/apparmor.d/usr.bin.firefox + * sudo aa-enforce /etc/apparmor.d/usr.bin.firefox - * launch Firefox + * launch Firefox - * See a similar segfault reported in the syslog: + * See a similar segfault reported in the syslog: Jun 10 17:25:40 ubuntu kernel: [ 86.775837] firefox[1765]: segfault at 0 ip 7f724dd06384 sp 7fffa7aec450 error 6 in libxul.so[7f724a483000+53b2000] Jun 10 17:25:40 ubuntu kernel: [ 86.775843] Code: 00 0f 1f 44 00 00 50 80 3d f8 56 4c 04 00 74 02 58 c3 c6 05 ed 56 4c 04 01 48 8d 05 24 2c fa 02 48 8b 0d 77 f0 3a 04 48 89 01 04 25 00 00 00 00 8d 01 00 00 e8 74 63 78 fc 66 2e 0f 1f 84 00 [Where problems could occur] + The fix adds additional paths to firefox apparmor profile (e.g. affecting /sys/devices/pci* and RealtimeKit1). When using deb version of firefox the browser may chose a different code path to execute than before, so it may affect hw acceleration (the sysfs paths were used by libxul) and audio. + Maybe rendering artifacts and audio sync issues in videos. + [Other Info] -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox in Ubuntu. https://bugs.launchpad.net/bugs/1931602 Title: [apparmor] Segfault in logs with apparmor enabled Status in firefox package in Ubuntu: Confirmed Status in firefox source package in Focal: Confirmed Status in firefox source package in Hirsute: New Status in firefox source package in Impish: New Bug description: [Impact] * With apparmor enabled (and usr.bin.firefox in enforce mode) there is a crash happening every time right after launching Firefox. [Test Plan] * sudo aa-enforce /etc/apparmor.d/usr.bin.firefox * launch Firefox * See a similar segfault reported in the syslog: Jun 10 17:25:40 ubuntu kernel: [ 86.775837] firefox[1765]: segfault at 0 ip 7f724dd06384 sp 7fffa7aec450 error 6 in libxul.so[7f724a483000+53b2000] Jun 10 17:25:40 ubuntu kernel: [ 86.775843] Code: 00 0f 1f 44 00 00 50 80 3d f8 56 4c 04 00 74 02 58 c3 c6 05 ed 56 4c 04 01 48 8d 05 24 2c fa 02 48 8b 0d 77 f0 3a 04 48 89 01 04 25 00 00 00 00 8d 01 00 00 e8 74 63 78 fc 66 2e 0f 1f 84 00 [Where problems could occur] The fix adds additional paths to firefox apparmor profile (e.g. affecting /sys/devices/pci* and RealtimeKit1). When using deb version of firefox the browser may chose a different code path to execute than before, so it may affect hw acceleration (the sysfs paths were used by libxul) and audio. Maybe rendering artifacts and audio sync issues in videos. [Other Info] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1931602/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1931603] Re: [apparmor] Unable to show Downloads with apparmor enabled
** Also affects: firefox (Ubuntu Hirsute) Importance: Undecided Status: New ** Also affects: firefox (Ubuntu Impish) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox in Ubuntu. https://bugs.launchpad.net/bugs/1931603 Title: [apparmor] Unable to show Downloads with apparmor enabled Status in firefox package in Ubuntu: New Status in firefox source package in Focal: New Status in firefox source package in Hirsute: New Status in firefox source package in Impish: New Bug description: Impact] * After a finished download (or opening the downloads list) it is impossible to "Open Containing Folder" for a downloaded file - pressing the button does nothing visible. [Test Plan] * sudo aa-enforce /etc/apparmor.d/usr.bin.firefox * launch Firefox * Download a file. * Go to downloads list. * Press the "Open Containing Folder" button next to the downloaded file on the list. [Where problems could occur] [Other Info] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1931603/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1931602] Re: [apparmor] Segfault in logs with apparmor enabled
** Also affects: firefox (Ubuntu Hirsute) Importance: Undecided Status: New ** Also affects: firefox (Ubuntu Impish) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox in Ubuntu. https://bugs.launchpad.net/bugs/1931602 Title: [apparmor] Segfault in logs with apparmor enabled Status in firefox package in Ubuntu: Confirmed Status in firefox source package in Focal: Confirmed Status in firefox source package in Hirsute: New Status in firefox source package in Impish: New Bug description: [Impact] * With apparmor enabled (and usr.bin.firefox in enforce mode) there is a crash happening every time right after launching Firefox. [Test Plan] * sudo aa-enforce /etc/apparmor.d/usr.bin.firefox * launch Firefox * See a similar segfault reported in the syslog: Jun 10 17:25:40 ubuntu kernel: [ 86.775837] firefox[1765]: segfault at 0 ip 7f724dd06384 sp 7fffa7aec450 error 6 in libxul.so[7f724a483000+53b2000] Jun 10 17:25:40 ubuntu kernel: [ 86.775843] Code: 00 0f 1f 44 00 00 50 80 3d f8 56 4c 04 00 74 02 58 c3 c6 05 ed 56 4c 04 01 48 8d 05 24 2c fa 02 48 8b 0d 77 f0 3a 04 48 89 01 04 25 00 00 00 00 8d 01 00 00 e8 74 63 78 fc 66 2e 0f 1f 84 00 [Where problems could occur] [Other Info] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1931602/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1948008] Re: Copying and pasting to/from Nautilus does not work
I have backported the gnome-shell fix for focal, however I'll wait with uploading until desktop-icons extension is fixed to push them together. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell in Ubuntu. https://bugs.launchpad.net/bugs/1948008 Title: Copying and pasting to/from Nautilus does not work Status in gnome-shell package in Ubuntu: New Status in gnome-shell-extension-desktop-icons package in Ubuntu: Invalid Status in gnome-shell-extension-desktop-icons-ng package in Ubuntu: New Status in gnome-shell source package in Focal: New Status in gnome-shell-extension-desktop-icons source package in Focal: New Status in gnome-shell-extension-desktop-icons-ng source package in Focal: Invalid Status in gnome-shell source package in Hirsute: Fix Released Status in gnome-shell-extension-desktop-icons source package in Hirsute: Invalid Status in gnome-shell-extension-desktop-icons-ng source package in Hirsute: New Status in gnome-shell source package in Impish: Fix Released Status in gnome-shell-extension-desktop-icons source package in Impish: Invalid Status in gnome-shell-extension-desktop-icons-ng source package in Impish: New Bug description: [Impact] * After upstream Nautilus has reverted the following commit [1] related to upstream bug [2] the desktop icons extension lost it's ability to copy to/from nautilus. * This is related to the fact that before there was some metadata passed along in the clipboard along with text data. This was causing issues with compatibility with some applications that were not expecting any metadata (MIME type in this case) was glued to the text clipboard contents. Hence, it was reverted upstream [3]. * Fixing the root cause of this issue required changes to Nautilus [3], gnome-shell [4] and desktop-icons [5] [6]. Nautilus and gnome- shell parts are already implemented and present in Hirsute and Impish. [Test Plan] 1) Make sure desktop-icons extension is enabled. 2) Open nautilus window and copy any file from there by right-clicking and selecting "Copy" from the popup menu. 3) Right-click on desktop and select "Paste" from the context menu. Expected result: selected file is copied to the desktop. Actual result: "Paste" item is disabled in the menu. [Where problems could occur] * Mixing a version of nautilus without commit [3] and fixed version of desktop-icons may still lead to a scenario when copying will not work. * Any extension/application copying to desktop using the smuggled-in- text clipboard behavior should be expected to stop working. [Other Info] [1] https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/289 [2] https://gitlab.gnome.org/GNOME/nautilus/-/issues/634 [3] https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/573 [4] https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1321 [5] https://gitlab.gnome.org/World/ShellExtensions/desktop-icons/-/merge_requests/186 [6] https://gitlab.gnome.org/World/ShellExtensions/desktop-icons/-/merge_requests/195 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1948008/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1948008] Re: Copying and pasting to/from Nautilus does not work
** This bug is no longer a duplicate of bug 1843588 Nautilus doesn't copy filenames for paste to other programs anymore ** No longer affects: gnome-shell-extension-desktop-icons (Ubuntu Hirsute) ** Also affects: gnome-shell-extension-desktop-icons (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: gnome-shell-extension-desktop-icons-ng (Ubuntu) Importance: Undecided Status: New ** Also affects: gnome-shell-extension-desktop-icons (Ubuntu Impish) Importance: Undecided Status: New ** Also affects: gnome-shell-extension-desktop-icons-ng (Ubuntu Impish) Importance: Undecided Status: New ** Also affects: gnome-shell-extension-desktop-icons (Ubuntu Hirsute) Importance: Undecided Status: New ** Also affects: gnome-shell-extension-desktop-icons-ng (Ubuntu Hirsute) Importance: Undecided Status: New ** Changed in: gnome-shell-extension-desktop-icons (Ubuntu Impish) Status: New => Won't Fix ** Changed in: gnome-shell-extension-desktop-icons (Ubuntu Hirsute) Status: New => Won't Fix ** Changed in: gnome-shell-extension-desktop-icons-ng (Ubuntu Focal) Status: New => Won't Fix ** Also affects: gnome-shell (Ubuntu) Importance: Undecided Status: New ** Changed in: gnome-shell (Ubuntu Hirsute) Status: New => Won't Fix ** Changed in: gnome-shell (Ubuntu Hirsute) Status: Won't Fix => Fix Released ** Changed in: gnome-shell (Ubuntu Impish) Status: New => Fix Released ** Changed in: gnome-shell (Ubuntu) Importance: Undecided => Low ** Changed in: gnome-shell-extension-desktop-icons (Ubuntu) Importance: Medium => Low ** Changed in: gnome-shell (Ubuntu Focal) Importance: Undecided => Low ** Changed in: gnome-shell-extension-desktop-icons (Ubuntu Focal) Importance: Undecided => Low ** Changed in: gnome-shell-extension-desktop-icons-ng (Ubuntu Hirsute) Importance: Undecided => Low ** Changed in: gnome-shell-extension-desktop-icons-ng (Ubuntu Impish) Importance: Undecided => Low ** Changed in: gnome-shell-extension-desktop-icons-ng (Ubuntu) Importance: Undecided => Low ** Changed in: gnome-shell-extension-desktop-icons (Ubuntu Hirsute) Status: Won't Fix => Invalid ** Changed in: gnome-shell-extension-desktop-icons (Ubuntu Impish) Status: Won't Fix => Invalid ** Changed in: gnome-shell-extension-desktop-icons-ng (Ubuntu Focal) Status: Won't Fix => Invalid -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell-extension-desktop-icons in Ubuntu. https://bugs.launchpad.net/bugs/1948008 Title: Copying and pasting to/from Nautilus does not work Status in gnome-shell package in Ubuntu: New Status in gnome-shell-extension-desktop-icons package in Ubuntu: Incomplete Status in gnome-shell-extension-desktop-icons-ng package in Ubuntu: New Status in gnome-shell source package in Focal: New Status in gnome-shell-extension-desktop-icons source package in Focal: New Status in gnome-shell-extension-desktop-icons-ng source package in Focal: Invalid Status in gnome-shell source package in Hirsute: Fix Released Status in gnome-shell-extension-desktop-icons source package in Hirsute: Invalid Status in gnome-shell-extension-desktop-icons-ng source package in Hirsute: New Status in gnome-shell source package in Impish: Fix Released Status in gnome-shell-extension-desktop-icons source package in Impish: Invalid Status in gnome-shell-extension-desktop-icons-ng source package in Impish: New Bug description: [Impact] * After upstream Nautilus has reverted the following commit [1] related to upstream bug [2] the desktop icons extension lost it's ability to copy to/from nautilus. * This is related to the fact that before there was some metadata passed along in the clipboard along with text data. This was causing issues with compatibility with some applications that were not expecting any metadata (MIME type in this case) was glued to the text clipboard contents. Hence, it was reverted upstream [3]. * Fixing the root cause of this issue required changes to Nautilus [3], gnome-shell [4] and desktop-icons [5] [6]. Nautilus and gnome- shell parts are already implemented and present in Hirsute and Impish. [Test Plan] 1) Make sure desktop-icons extension is enabled. 2) Open nautilus window and copy any file from there by right-clicking and selecting "Copy" from the popup menu. 3) Right-click on desktop and select "Paste" from the context menu. Expected result: selected file is copied to the desktop. Actual result: "Paste" item is disabled in the menu. [Where problems could occur] * Mixing a version of nautilus without commit [3] and fixed version of desktop-icons may still lead to a scenario when copying will not work. * Any extension/application copying to desktop using the smuggled-in- text clipboard behavior
[Desktop-packages] [Bug 1843588] Re: Nautilus doesn't copy filenames for paste to other programs anymore
Marking as verified as per Michael's comment #12. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/1843588 Title: Nautilus doesn't copy filenames for paste to other programs anymore Status in Nautilus: New Status in nautilus package in Ubuntu: Fix Released Status in nautilus source package in Focal: Fix Committed Bug description: [Impact] * One of the upstream changes changed behavior of clipboard copying files/directories from nautilus to applications accepting text only (e.g. gnome-terminal). In such case the pasted input is prefixed with: x-special/nautilus-clipboard copy file:// This was not the case in earlier releases and this change has been reverted in later upstream releases. Reverting the problematic commit will fix the usecase reported in this bug (and all applications where copying from Nautilus and pasting the data into a text-based input makes sense), but will break copying to/from Desktop Icons extension. I recommend reporting the Desktop Icons extension issue (present already in every later Ubuntu release) in a separate bug and track the fix there. [Test Plan] 1. Open nautilus. 2. Right-click on any file or directory and select 'Copy' from the context menu. 3. Open gnome-terminal and right-click paste the contents of the clipboard. Expected result: path of the file/directory is pasted in the terminal. Actual result: pasted input is prefixed with "x-special/nautilus-clipboard copy file://" [Where problems could occur] * There are some workarounds listed in the upstream bug so fixing the root cause may break environments with those workarounds in place. * Reverting this change also limits functionality of the desktop icons extension shipped with Ubuntu. Namely: before the new clipboard API is used in desktop-icons (merge requests [1] and [2]) copying and pasting to/from the desktop extension to a nautilus will not be possible via keyboard shortcuts or context menu (dragging and dropping will remain to work). [1] https://gitlab.gnome.org/World/ShellExtensions/desktop-icons/-/merge_requests/186 [2] https://gitlab.gnome.org/World/ShellExtensions/desktop-icons/-/merge_requests/195 [Other Info] Original bug description: Until Ubuntu 18.10 Nautilus does copy all selected filenames in simple Text format and this way you cold paste the selected files as a list to other programs: for example into the texteditor gedit. This was a very useful function if you have, for example, to upload a file to webmail or other web-service. You cold copy the file within nautilus and paste it directliy to the selection dialog or webfield to upload the file. Or if you wanted a simple List of all your files in a folder you where able to select all files with nautilus, copy and paste into gedit. This is not possible anymore. The output of natilus looks now like this: x-special/nautilus-clipboard copy file:///home//Schreibtisch/new%20document.txt Until Ubuntu 18.10 this looks like this: /home//Schreibtisch/new document.txt Steps to reproduce: 1. Select files with nautilus 2. Press Ctrl+C 3. open gedit 4. press Ctrl+V ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: nautilus 1:3.32.1-0ubuntu0.19.04.0 ProcVersionSignature: Ubuntu 5.0.0-27.28-generic 5.0.21 Uname: Linux 5.0.0-27-generic x86_64 ApportVersion: 2.20.10-0ubuntu27.1 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Wed Sep 11 15:06:14 2019 ExecutablePath: /usr/bin/nautilus SourcePackage: nautilus UpgradeStatus: No upgrade log present (probably fresh install) usr_lib_nautilus: To manage notifications about this bug go to: https://bugs.launchpad.net/nautilus/+bug/1843588/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1843588] Re: Nautilus doesn't copy filenames for paste to other programs anymore
thanks for testing it Michael. Regarding desktop-icons: afaik there's still no fix for it. ** No longer affects: gnome-shell (Ubuntu) ** No longer affects: gnome-shell-extension-desktop-icons (Ubuntu) ** No longer affects: gnome-shell (Ubuntu Focal) ** No longer affects: gnome-shell-extension-desktop-icons (Ubuntu Focal) ** Tags removed: verification-needed verification-needed-focal ** Tags added: verification-done verification-done-focal -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/1843588 Title: Nautilus doesn't copy filenames for paste to other programs anymore Status in Nautilus: New Status in nautilus package in Ubuntu: Fix Released Status in nautilus source package in Focal: Fix Committed Bug description: [Impact] * One of the upstream changes changed behavior of clipboard copying files/directories from nautilus to applications accepting text only (e.g. gnome-terminal). In such case the pasted input is prefixed with: x-special/nautilus-clipboard copy file:// This was not the case in earlier releases and this change has been reverted in later upstream releases. Reverting the problematic commit will fix the usecase reported in this bug (and all applications where copying from Nautilus and pasting the data into a text-based input makes sense), but will break copying to/from Desktop Icons extension. I recommend reporting the Desktop Icons extension issue (present already in every later Ubuntu release) in a separate bug and track the fix there. [Test Plan] 1. Open nautilus. 2. Right-click on any file or directory and select 'Copy' from the context menu. 3. Open gnome-terminal and right-click paste the contents of the clipboard. Expected result: path of the file/directory is pasted in the terminal. Actual result: pasted input is prefixed with "x-special/nautilus-clipboard copy file://" [Where problems could occur] * There are some workarounds listed in the upstream bug so fixing the root cause may break environments with those workarounds in place. * Reverting this change also limits functionality of the desktop icons extension shipped with Ubuntu. Namely: before the new clipboard API is used in desktop-icons (merge requests [1] and [2]) copying and pasting to/from the desktop extension to a nautilus will not be possible via keyboard shortcuts or context menu (dragging and dropping will remain to work). [1] https://gitlab.gnome.org/World/ShellExtensions/desktop-icons/-/merge_requests/186 [2] https://gitlab.gnome.org/World/ShellExtensions/desktop-icons/-/merge_requests/195 [Other Info] Original bug description: Until Ubuntu 18.10 Nautilus does copy all selected filenames in simple Text format and this way you cold paste the selected files as a list to other programs: for example into the texteditor gedit. This was a very useful function if you have, for example, to upload a file to webmail or other web-service. You cold copy the file within nautilus and paste it directliy to the selection dialog or webfield to upload the file. Or if you wanted a simple List of all your files in a folder you where able to select all files with nautilus, copy and paste into gedit. This is not possible anymore. The output of natilus looks now like this: x-special/nautilus-clipboard copy file:///home//Schreibtisch/new%20document.txt Until Ubuntu 18.10 this looks like this: /home//Schreibtisch/new document.txt Steps to reproduce: 1. Select files with nautilus 2. Press Ctrl+C 3. open gedit 4. press Ctrl+V ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: nautilus 1:3.32.1-0ubuntu0.19.04.0 ProcVersionSignature: Ubuntu 5.0.0-27.28-generic 5.0.21 Uname: Linux 5.0.0-27-generic x86_64 ApportVersion: 2.20.10-0ubuntu27.1 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Wed Sep 11 15:06:14 2019 ExecutablePath: /usr/bin/nautilus SourcePackage: nautilus UpgradeStatus: No upgrade log present (probably fresh install) usr_lib_nautilus: To manage notifications about this bug go to: https://bugs.launchpad.net/nautilus/+bug/1843588/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1948008] Re: Copying and pasting to/from Nautilus does not work
*** This bug is a duplicate of bug 1843588 *** https://bugs.launchpad.net/bugs/1843588 Thank you Mathew. I assumed it's the same package in later releases. The reason behind splitting the bug was the fact that I believe these are 2 separate problems by coincidence having their root causes in similar portions of code. Bug #1843588 is focal specific and is about altered contents of clipboard and fixing it requires fixing reverting the change in nautilus. This one on the other hand is about not being able to copy from the desktop to nautilus and vice versa. And fixing this should require fixing: For focal (beside fixing bug #1843588): * gnome-shell * gnome-shell-extension-desktop-icons For hirsute & impish: * gnome-shell-extension-desktop-icons-ng -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell-extension-desktop-icons in Ubuntu. https://bugs.launchpad.net/bugs/1948008 Title: Copying and pasting to/from Nautilus does not work Status in gnome-shell-extension-desktop-icons package in Ubuntu: Incomplete Status in gnome-shell-extension-desktop-icons source package in Hirsute: Won't Fix Bug description: [Impact] * After upstream Nautilus has reverted the following commit [1] related to upstream bug [2] the desktop icons extension lost it's ability to copy to/from nautilus. * This is related to the fact that before there was some metadata passed along in the clipboard along with text data. This was causing issues with compatibility with some applications that were not expecting any metadata (MIME type in this case) was glued to the text clipboard contents. Hence, it was reverted upstream [3]. * Fixing the root cause of this issue required changes to Nautilus [3], gnome-shell [4] and desktop-icons [5] [6]. Nautilus and gnome- shell parts are already implemented and present in Hirsute and Impish. [Test Plan] 1) Make sure desktop-icons extension is enabled. 2) Open nautilus window and copy any file from there by right-clicking and selecting "Copy" from the popup menu. 3) Right-click on desktop and select "Paste" from the context menu. Expected result: selected file is copied to the desktop. Actual result: "Paste" item is disabled in the menu. [Where problems could occur] * Mixing a version of nautilus without commit [3] and fixed version of desktop-icons may still lead to a scenario when copying will not work. * Any extension/application copying to desktop using the smuggled-in- text clipboard behavior should be expected to stop working. [Other Info] [1] https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/289 [2] https://gitlab.gnome.org/GNOME/nautilus/-/issues/634 [3] https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/573 [4] https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1321 [5] https://gitlab.gnome.org/World/ShellExtensions/desktop-icons/-/merge_requests/186 [6] https://gitlab.gnome.org/World/ShellExtensions/desktop-icons/-/merge_requests/195 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell-extension-desktop-icons/+bug/1948008/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1843588] Re: Nautilus doesn't copy filenames for paste to other programs anymore
I have reported another bug addressing the desktop-icons extension aspect of this issue: https://bugs.launchpad.net/ubuntu/+source/gnome-shell-extension-desktop- icons/+bug/1948008 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/1843588 Title: Nautilus doesn't copy filenames for paste to other programs anymore Status in Nautilus: New Status in gnome-shell package in Ubuntu: Fix Released Status in gnome-shell-extension-desktop-icons package in Ubuntu: New Status in nautilus package in Ubuntu: Fix Released Status in gnome-shell source package in Focal: New Status in gnome-shell-extension-desktop-icons source package in Focal: New Status in nautilus source package in Focal: New Bug description: [Impact] * One of the upstream changes changed behavior of clipboard copying files/directories from nautilus to applications accepting text only (e.g. gnome-terminal). In such case the pasted input is prefixed with: x-special/nautilus-clipboard copy file:// This was not the case in earlier releases and this change has been reverted in later upstream releases. Reverting the problematic commit will fix the usecase reported in this bug (and all applications where copying from Nautilus and pasting the data into a text-based input makes sense), but will break copying to/from Desktop Icons extension. I recommend reporting the Desktop Icons extension issue (present already in every later Ubuntu release) in a separate bug and track the fix there. [Test Plan] 1. Open nautilus. 2. Right-click on any file or directory and select 'Copy' from the context menu. 3. Open gnome-terminal and right-click paste the contents of the clipboard. Expected result: path of the file/directory is pasted in the terminal. Actual result: pasted input is prefixed with "x-special/nautilus-clipboard copy file://" [Where problems could occur] * There are some workarounds listed in the upstream bug so fixing the root cause may break environments with those workarounds in place. * Reverting this change also limits functionality of the desktop icons extension shipped with Ubuntu. Namely: before the new clipboard API is used in desktop-icons (merge requests [1] and [2]) copying and pasting to/from the desktop extension to a nautilus will not be possible via keyboard shortcuts or context menu (dragging and dropping will remain to work). [1] https://gitlab.gnome.org/World/ShellExtensions/desktop-icons/-/merge_requests/186 [2] https://gitlab.gnome.org/World/ShellExtensions/desktop-icons/-/merge_requests/195 [Other Info] Original bug description: Until Ubuntu 18.10 Nautilus does copy all selected filenames in simple Text format and this way you cold paste the selected files as a list to other programs: for example into the texteditor gedit. This was a very useful function if you have, for example, to upload a file to webmail or other web-service. You cold copy the file within nautilus and paste it directliy to the selection dialog or webfield to upload the file. Or if you wanted a simple List of all your files in a folder you where able to select all files with nautilus, copy and paste into gedit. This is not possible anymore. The output of natilus looks now like this: x-special/nautilus-clipboard copy file:///home//Schreibtisch/new%20document.txt Until Ubuntu 18.10 this looks like this: /home//Schreibtisch/new document.txt Steps to reproduce: 1. Select files with nautilus 2. Press Ctrl+C 3. open gedit 4. press Ctrl+V ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: nautilus 1:3.32.1-0ubuntu0.19.04.0 ProcVersionSignature: Ubuntu 5.0.0-27.28-generic 5.0.21 Uname: Linux 5.0.0-27-generic x86_64 ApportVersion: 2.20.10-0ubuntu27.1 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Wed Sep 11 15:06:14 2019 ExecutablePath: /usr/bin/nautilus SourcePackage: nautilus UpgradeStatus: No upgrade log present (probably fresh install) usr_lib_nautilus: To manage notifications about this bug go to: https://bugs.launchpad.net/nautilus/+bug/1843588/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1948008] [NEW] Copying and pasting to/from Nautilus does not work
Public bug reported: [Impact] * After upstream Nautilus has reverted the following commit [1] related to upstream bug [2] the desktop icons extension lost it's ability to copy to/from nautilus. * This is related to the fact that before there was some metadata passed along in the clipboard along with text data. This was causing issues with compatibility with some applications that were not expecting any metadata (MIME type in this case) was glued to the text clipboard contents. Hence, it was reverted upstream [3]. * Fixing the root cause of this issue required changes to Nautilus [3], gnome-shell [4] and desktop-icons [5] [6]. Nautilus and gnome-shell parts are already implemented and present in Hirsute and Impish. [Test Plan] 1) Make sure desktop-icons extension is enabled. 2) Open nautilus window and copy any file from there by right-clicking and selecting "Copy" from the popup menu. 3) Right-click on desktop and select "Paste" from the context menu. Expected result: selected file is copied to the desktop. Actual result: "Paste" item is disabled in the menu. [Where problems could occur] * Mixing a version of nautilus without commit [3] and fixed version of desktop-icons may still lead to a scenario when copying will not work. * Any extension/application copying to desktop using the smuggled-in- text clipboard behavior should be expected to stop working. [Other Info] [1] https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/289 [2] https://gitlab.gnome.org/GNOME/nautilus/-/issues/634 [3] https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/573 [4] https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1321 [5] https://gitlab.gnome.org/World/ShellExtensions/desktop-icons/-/merge_requests/186 [6] https://gitlab.gnome.org/World/ShellExtensions/desktop-icons/-/merge_requests/195 ** Affects: gnome-shell-extension-desktop-icons (Ubuntu) Importance: Medium Status: New ** Affects: gnome-shell-extension-desktop-icons (Ubuntu Hirsute) Importance: Medium Status: New ** Affects: gnome-shell-extension-desktop-icons (Ubuntu Impish) Importance: Medium Status: New ** Also affects: gnome-shell-extension-desktop-icons (Ubuntu Impish) Importance: Undecided Status: New ** Also affects: gnome-shell-extension-desktop-icons (Ubuntu Hirsute) Importance: Undecided Status: New ** Changed in: gnome-shell-extension-desktop-icons (Ubuntu Impish) Importance: Undecided => Medium ** Changed in: gnome-shell-extension-desktop-icons (Ubuntu Hirsute) Importance: Undecided => Medium ** Changed in: gnome-shell-extension-desktop-icons (Ubuntu) Importance: Undecided => Medium -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-shell-extension-desktop-icons in Ubuntu. https://bugs.launchpad.net/bugs/1948008 Title: Copying and pasting to/from Nautilus does not work Status in gnome-shell-extension-desktop-icons package in Ubuntu: New Status in gnome-shell-extension-desktop-icons source package in Hirsute: New Status in gnome-shell-extension-desktop-icons source package in Impish: New Bug description: [Impact] * After upstream Nautilus has reverted the following commit [1] related to upstream bug [2] the desktop icons extension lost it's ability to copy to/from nautilus. * This is related to the fact that before there was some metadata passed along in the clipboard along with text data. This was causing issues with compatibility with some applications that were not expecting any metadata (MIME type in this case) was glued to the text clipboard contents. Hence, it was reverted upstream [3]. * Fixing the root cause of this issue required changes to Nautilus [3], gnome-shell [4] and desktop-icons [5] [6]. Nautilus and gnome- shell parts are already implemented and present in Hirsute and Impish. [Test Plan] 1) Make sure desktop-icons extension is enabled. 2) Open nautilus window and copy any file from there by right-clicking and selecting "Copy" from the popup menu. 3) Right-click on desktop and select "Paste" from the context menu. Expected result: selected file is copied to the desktop. Actual result: "Paste" item is disabled in the menu. [Where problems could occur] * Mixing a version of nautilus without commit [3] and fixed version of desktop-icons may still lead to a scenario when copying will not work. * Any extension/application copying to desktop using the smuggled-in- text clipboard behavior should be expected to stop working. [Other Info] [1] https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/289 [2] https://gitlab.gnome.org/GNOME/nautilus/-/issues/634 [3] https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/573 [4] https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1321 [5] https://gitlab.gnome.org/World/ShellExtensions/desktop-icons/-/merge_requests/186
[Desktop-packages] [Bug 1843588] Re: Nautilus doesn't copy filenames for paste to other programs anymore
Thanks Robie. I'll add more details to the description. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/1843588 Title: Nautilus doesn't copy filenames for paste to other programs anymore Status in Nautilus: New Status in gnome-shell package in Ubuntu: Fix Released Status in gnome-shell-extension-desktop-icons package in Ubuntu: New Status in nautilus package in Ubuntu: Fix Released Status in gnome-shell source package in Focal: New Status in gnome-shell-extension-desktop-icons source package in Focal: New Status in nautilus source package in Focal: New Bug description: [Impact] * One of the upstream changes changed behavior of clipboard copying files/directories from nautilus to applications accepting text only (e.g. gnome-terminal). In such case the pasted input is prefixed with: x-special/nautilus-clipboard copy file:// This was not the case in earlier releases and this change has been reverted in later upstream releases. Reverting the problematic commit will fix the usecase reported in this bug (and all applications where copying from Nautilus and pasting the data into a text-based input makes sense), but will break copying to/from Desktop Icons extension. I recommend reporting the Desktop Icons extension issue (present already in every later Ubuntu release) in a separate bug and track the fix there. [Test Plan] 1. Open nautilus. 2. Right-click on any file or directory and select 'Copy' from the context menu. 3. Open gnome-terminal and right-click paste the contents of the clipboard. Expected result: path of the file/directory is pasted in the terminal. Actual result: pasted input is prefixed with "x-special/nautilus-clipboard copy file://" [Where problems could occur] * There are some workarounds listed in the upstream bug so fixing the root cause may break environments with those workarounds in place. * Reverting this change also limits functionality of the desktop icons extension shipped with Ubuntu. Namely: before the new clipboard API is used in desktop-icons (merge requests [1] and [2]) copying and pasting to/from the desktop extension to a nautilus will not be possible via keyboard shortcuts or context menu (dragging and dropping will remain to work). [1] https://gitlab.gnome.org/World/ShellExtensions/desktop-icons/-/merge_requests/186 [2] https://gitlab.gnome.org/World/ShellExtensions/desktop-icons/-/merge_requests/195 [Other Info] Original bug description: Until Ubuntu 18.10 Nautilus does copy all selected filenames in simple Text format and this way you cold paste the selected files as a list to other programs: for example into the texteditor gedit. This was a very useful function if you have, for example, to upload a file to webmail or other web-service. You cold copy the file within nautilus and paste it directliy to the selection dialog or webfield to upload the file. Or if you wanted a simple List of all your files in a folder you where able to select all files with nautilus, copy and paste into gedit. This is not possible anymore. The output of natilus looks now like this: x-special/nautilus-clipboard copy file:///home//Schreibtisch/new%20document.txt Until Ubuntu 18.10 this looks like this: /home//Schreibtisch/new document.txt Steps to reproduce: 1. Select files with nautilus 2. Press Ctrl+C 3. open gedit 4. press Ctrl+V ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: nautilus 1:3.32.1-0ubuntu0.19.04.0 ProcVersionSignature: Ubuntu 5.0.0-27.28-generic 5.0.21 Uname: Linux 5.0.0-27-generic x86_64 ApportVersion: 2.20.10-0ubuntu27.1 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Wed Sep 11 15:06:14 2019 ExecutablePath: /usr/bin/nautilus SourcePackage: nautilus UpgradeStatus: No upgrade log present (probably fresh install) usr_lib_nautilus: To manage notifications about this bug go to: https://bugs.launchpad.net/nautilus/+bug/1843588/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1843588] Re: Nautilus doesn't copy filenames for paste to other programs anymore
** Description changed: [Impact] - * One of the upstream changes changed behavior of clipboard copying files/directories from nautilus to applications accepting text only (e.g. gnome-terminal). In such case the pasted input is prefixed with: + * One of the upstream changes changed behavior of clipboard copying files/directories from nautilus to applications accepting text only (e.g. gnome-terminal). In such case the pasted input is prefixed with: x-special/nautilus-clipboard copy file:// This was not the case in earlier releases and this change has been reverted in later upstream releases. + Reverting the problematic commit will fix the usecase reported in this + bug (and all applications where copying from Nautilus and pasting the + data into a text-based input makes sense), but will break copying + to/from Desktop Icons extension. + + I recommend reporting the Desktop Icons extension issue (present already + in every later Ubuntu release) in a separate bug and track the fix + there. + [Test Plan] - 1. Open nautilus. - 2. Right-click on any file or directory and select 'Copy' from the context menu. - 3. Open gnome-terminal and right-click paste the contents of the clipboard. + 1. Open nautilus. + 2. Right-click on any file or directory and select 'Copy' from the context menu. + 3. Open gnome-terminal and right-click paste the contents of the clipboard. Expected result: path of the file/directory is pasted in the terminal. Actual result: pasted input is prefixed with "x-special/nautilus-clipboard copy file://" [Where problems could occur] - * There are some workarounds listed in the upstream bug so fixing the - root cause may break environments with those workarounds in place. + * There are some workarounds listed in the upstream bug so fixing the root cause may break environments with those workarounds in place. + * Reverting this change also limits functionality of the desktop icons extension shipped with Ubuntu. Namely: before the new clipboard API is used in desktop-icons (merge requests [1] and [2]) copying and pasting to/from the desktop extension to a nautilus will not be possible via keyboard shortcuts or context menu (dragging and dropping will remain to work). + + [1] https://gitlab.gnome.org/World/ShellExtensions/desktop-icons/-/merge_requests/186 + [2] https://gitlab.gnome.org/World/ShellExtensions/desktop-icons/-/merge_requests/195 [Other Info] - + Original bug description: Until Ubuntu 18.10 Nautilus does copy all selected filenames in simple Text format and this way you cold paste the selected files as a list to other programs: for example into the texteditor gedit. This was a very useful function if you have, for example, to upload a file to webmail or other web-service. You cold copy the file within nautilus and paste it directliy to the selection dialog or webfield to upload the file. Or if you wanted a simple List of all your files in a folder you where able to select all files with nautilus, copy and paste into gedit. This is not possible anymore. The output of natilus looks now like this: x-special/nautilus-clipboard copy file:///home//Schreibtisch/new%20document.txt Until Ubuntu 18.10 this looks like this: /home//Schreibtisch/new document.txt Steps to reproduce: 1. Select files with nautilus 2. Press Ctrl+C 3. open gedit 4. press Ctrl+V ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: nautilus 1:3.32.1-0ubuntu0.19.04.0 ProcVersionSignature: Ubuntu 5.0.0-27.28-generic 5.0.21 Uname: Linux 5.0.0-27-generic x86_64 ApportVersion: 2.20.10-0ubuntu27.1 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Wed Sep 11 15:06:14 2019 ExecutablePath: /usr/bin/nautilus SourcePackage: nautilus UpgradeStatus: No upgrade log present (probably fresh install) usr_lib_nautilus: -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/1843588 Title: Nautilus doesn't copy filenames for paste to other programs anymore Status in Nautilus: New Status in gnome-shell package in Ubuntu: Fix Released Status in gnome-shell-extension-desktop-icons package in Ubuntu: New Status in nautilus package in Ubuntu: Fix Released Status in gnome-shell source package in Focal: New Status in gnome-shell-extension-desktop-icons source package in Focal: New Status in nautilus source package in Focal: New Bug description: [Impact] * One of the upstream changes changed behavior of clipboard copying files/directories from nautilus to applications accepting text only (e.g. gnome-terminal). In such case the pasted input is prefixed with: x-special/nautilus-clipboard copy file:// This was not the case in earlier releases and this change has been reverted in later upstream releases. Reverting the problematic commit will fix the
[Desktop-packages] [Bug 1843588] Re: Nautilus doesn't copy filenames for paste to other programs anymore
** Also affects: gnome-shell (Ubuntu) Importance: Undecided Status: New ** Changed in: gnome-shell (Ubuntu Focal) Assignee: (unassigned) => Dariusz Gadomski (dgadomski) ** Changed in: gnome-shell (Ubuntu) Status: New => Fix Released ** Changed in: gnome-shell (Ubuntu Focal) Importance: Undecided => Medium ** Changed in: nautilus (Ubuntu Focal) Importance: Undecided => Medium ** Changed in: gnome-shell (Ubuntu) Importance: Undecided => Medium ** Also affects: gnome-shell-extension-desktop-icons (Ubuntu) Importance: Undecided Status: New ** Changed in: gnome-shell-extension-desktop-icons (Ubuntu Focal) Importance: Undecided => Medium ** Changed in: gnome-shell-extension-desktop-icons (Ubuntu Focal) Assignee: (unassigned) => Dariusz Gadomski (dgadomski) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/1843588 Title: Nautilus doesn't copy filenames for paste to other programs anymore Status in Nautilus: New Status in gnome-shell package in Ubuntu: Fix Released Status in gnome-shell-extension-desktop-icons package in Ubuntu: New Status in nautilus package in Ubuntu: Fix Released Status in gnome-shell source package in Focal: New Status in gnome-shell-extension-desktop-icons source package in Focal: New Status in nautilus source package in Focal: New Bug description: [Impact] * One of the upstream changes changed behavior of clipboard copying files/directories from nautilus to applications accepting text only (e.g. gnome-terminal). In such case the pasted input is prefixed with: x-special/nautilus-clipboard copy file:// This was not the case in earlier releases and this change has been reverted in later upstream releases. [Test Plan] 1. Open nautilus. 2. Right-click on any file or directory and select 'Copy' from the context menu. 3. Open gnome-terminal and right-click paste the contents of the clipboard. Expected result: path of the file/directory is pasted in the terminal. Actual result: pasted input is prefixed with "x-special/nautilus-clipboard copy file://" [Where problems could occur] * There are some workarounds listed in the upstream bug so fixing the root cause may break environments with those workarounds in place. [Other Info] Original bug description: Until Ubuntu 18.10 Nautilus does copy all selected filenames in simple Text format and this way you cold paste the selected files as a list to other programs: for example into the texteditor gedit. This was a very useful function if you have, for example, to upload a file to webmail or other web-service. You cold copy the file within nautilus and paste it directliy to the selection dialog or webfield to upload the file. Or if you wanted a simple List of all your files in a folder you where able to select all files with nautilus, copy and paste into gedit. This is not possible anymore. The output of natilus looks now like this: x-special/nautilus-clipboard copy file:///home//Schreibtisch/new%20document.txt Until Ubuntu 18.10 this looks like this: /home//Schreibtisch/new document.txt Steps to reproduce: 1. Select files with nautilus 2. Press Ctrl+C 3. open gedit 4. press Ctrl+V ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: nautilus 1:3.32.1-0ubuntu0.19.04.0 ProcVersionSignature: Ubuntu 5.0.0-27.28-generic 5.0.21 Uname: Linux 5.0.0-27-generic x86_64 ApportVersion: 2.20.10-0ubuntu27.1 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Wed Sep 11 15:06:14 2019 ExecutablePath: /usr/bin/nautilus SourcePackage: nautilus UpgradeStatus: No upgrade log present (probably fresh install) usr_lib_nautilus: To manage notifications about this bug go to: https://bugs.launchpad.net/nautilus/+bug/1843588/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1843588] Re: Nautilus doesn't copy filenames for paste to other programs anymore
I have prepared and uploaded patch for focal for this issue which is a backport of upstream commit https://gitlab.gnome.org/GNOME/nautilus/-/commit/2045f662f26891f5bb8c7ab0a7763227fe5fdf78 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/1843588 Title: Nautilus doesn't copy filenames for paste to other programs anymore Status in Nautilus: New Status in nautilus package in Ubuntu: Fix Released Status in nautilus source package in Focal: New Bug description: [Impact] * One of the upstream changes changed behavior of clipboard copying files/directories from nautilus to applications accepting text only (e.g. gnome-terminal). In such case the pasted input is prefixed with: x-special/nautilus-clipboard copy file:// This was not the case in earlier releases and this change has been reverted in later upstream releases. [Test Plan] 1. Open nautilus. 2. Right-click on any file or directory and select 'Copy' from the context menu. 3. Open gnome-terminal and right-click paste the contents of the clipboard. Expected result: path of the file/directory is pasted in the terminal. Actual result: pasted input is prefixed with "x-special/nautilus-clipboard copy file://" [Where problems could occur] * There are some workarounds listed in the upstream bug so fixing the root cause may break environments with those workarounds in place. [Other Info] Original bug description: Until Ubuntu 18.10 Nautilus does copy all selected filenames in simple Text format and this way you cold paste the selected files as a list to other programs: for example into the texteditor gedit. This was a very useful function if you have, for example, to upload a file to webmail or other web-service. You cold copy the file within nautilus and paste it directliy to the selection dialog or webfield to upload the file. Or if you wanted a simple List of all your files in a folder you where able to select all files with nautilus, copy and paste into gedit. This is not possible anymore. The output of natilus looks now like this: x-special/nautilus-clipboard copy file:///home//Schreibtisch/new%20document.txt Until Ubuntu 18.10 this looks like this: /home//Schreibtisch/new document.txt Steps to reproduce: 1. Select files with nautilus 2. Press Ctrl+C 3. open gedit 4. press Ctrl+V ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: nautilus 1:3.32.1-0ubuntu0.19.04.0 ProcVersionSignature: Ubuntu 5.0.0-27.28-generic 5.0.21 Uname: Linux 5.0.0-27-generic x86_64 ApportVersion: 2.20.10-0ubuntu27.1 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Wed Sep 11 15:06:14 2019 ExecutablePath: /usr/bin/nautilus SourcePackage: nautilus UpgradeStatus: No upgrade log present (probably fresh install) usr_lib_nautilus: To manage notifications about this bug go to: https://bugs.launchpad.net/nautilus/+bug/1843588/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1843588] Re: Nautilus doesn't copy filenames for paste to other programs anymore
** Description changed: + [Impact] - Until Ubuntu 18.10 Nautilus does copy all selected filenames in simple Text format and this way you cold paste the selected files as a list to other programs: for example into the texteditor gedit. This was a very useful function if you have, for example, to upload a file to webmail or other web-service. You cold copy the file within nautilus and paste it directliy to the selection dialog or webfield to upload the file. + * One of the upstream changes changed behavior of clipboard copying files/directories from nautilus to applications accepting text only (e.g. gnome-terminal). In such case the pasted input is prefixed with: + x-special/nautilus-clipboard + copy file:// + + This was not the case in earlier releases and this change has been + reverted in later upstream releases. + + [Test Plan] + + 1. Open nautilus. + 2. Right-click on any file or directory and select 'Copy' from the context menu. + 3. Open gnome-terminal and right-click paste the contents of the clipboard. + + Expected result: path of the file/directory is pasted in the terminal. + Actual result: pasted input is prefixed with "x-special/nautilus-clipboard + copy file://" + + [Where problems could occur] + + * There are some workarounds listed in the upstream bug so fixing the + root cause may break environments with those workarounds in place. + + [Other Info] + + Original bug description: + + Until Ubuntu 18.10 Nautilus does copy all selected filenames in simple + Text format and this way you cold paste the selected files as a list to + other programs: for example into the texteditor gedit. This was a very + useful function if you have, for example, to upload a file to webmail or + other web-service. You cold copy the file within nautilus and paste it + directliy to the selection dialog or webfield to upload the file. Or if you wanted a simple List of all your files in a folder you where able to select all files with nautilus, copy and paste into gedit. This is not possible anymore. The output of natilus looks now like this: x-special/nautilus-clipboard copy file:///home//Schreibtisch/new%20document.txt - Until Ubuntu 18.10 this looks like this: /home//Schreibtisch/new document.txt Steps to reproduce: 1. Select files with nautilus 2. Press Ctrl+C 3. open gedit 4. press Ctrl+V ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: nautilus 1:3.32.1-0ubuntu0.19.04.0 ProcVersionSignature: Ubuntu 5.0.0-27.28-generic 5.0.21 Uname: Linux 5.0.0-27-generic x86_64 ApportVersion: 2.20.10-0ubuntu27.1 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Wed Sep 11 15:06:14 2019 ExecutablePath: /usr/bin/nautilus SourcePackage: nautilus UpgradeStatus: No upgrade log present (probably fresh install) usr_lib_nautilus: ** Tags added: sts sts-sponsor-dgadomski -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/1843588 Title: Nautilus doesn't copy filenames for paste to other programs anymore Status in Nautilus: New Status in nautilus package in Ubuntu: Fix Released Status in nautilus source package in Focal: New Bug description: [Impact] * One of the upstream changes changed behavior of clipboard copying files/directories from nautilus to applications accepting text only (e.g. gnome-terminal). In such case the pasted input is prefixed with: x-special/nautilus-clipboard copy file:// This was not the case in earlier releases and this change has been reverted in later upstream releases. [Test Plan] 1. Open nautilus. 2. Right-click on any file or directory and select 'Copy' from the context menu. 3. Open gnome-terminal and right-click paste the contents of the clipboard. Expected result: path of the file/directory is pasted in the terminal. Actual result: pasted input is prefixed with "x-special/nautilus-clipboard copy file://" [Where problems could occur] * There are some workarounds listed in the upstream bug so fixing the root cause may break environments with those workarounds in place. [Other Info] Original bug description: Until Ubuntu 18.10 Nautilus does copy all selected filenames in simple Text format and this way you cold paste the selected files as a list to other programs: for example into the texteditor gedit. This was a very useful function if you have, for example, to upload a file to webmail or other web-service. You cold copy the file within nautilus and paste it directliy to the selection dialog or webfield to upload the file. Or if you wanted a simple List of all your files in a folder you where able to select all files with nautilus, copy and paste into gedit. This is not possible anymore. The output of natilus looks now like this: x-special/nautilus-clipboard copy
[Desktop-packages] [Bug 1843588] Re: Nautilus doesn't copy filenames for paste to other programs anymore
** Changed in: nautilus (Ubuntu) Assignee: (unassigned) => Dariusz Gadomski (dgadomski) ** Changed in: nautilus (Ubuntu) Status: Triaged => Fix Released ** Also affects: nautilus (Ubuntu Focal) Importance: Undecided Status: New ** Changed in: nautilus (Ubuntu Focal) Assignee: (unassigned) => Dariusz Gadomski (dgadomski) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/1843588 Title: Nautilus doesn't copy filenames for paste to other programs anymore Status in Nautilus: New Status in nautilus package in Ubuntu: Fix Released Status in nautilus source package in Focal: New Bug description: Until Ubuntu 18.10 Nautilus does copy all selected filenames in simple Text format and this way you cold paste the selected files as a list to other programs: for example into the texteditor gedit. This was a very useful function if you have, for example, to upload a file to webmail or other web-service. You cold copy the file within nautilus and paste it directliy to the selection dialog or webfield to upload the file. Or if you wanted a simple List of all your files in a folder you where able to select all files with nautilus, copy and paste into gedit. This is not possible anymore. The output of natilus looks now like this: x-special/nautilus-clipboard copy file:///home//Schreibtisch/new%20document.txt Until Ubuntu 18.10 this looks like this: /home//Schreibtisch/new document.txt Steps to reproduce: 1. Select files with nautilus 2. Press Ctrl+C 3. open gedit 4. press Ctrl+V ProblemType: Bug DistroRelease: Ubuntu 19.04 Package: nautilus 1:3.32.1-0ubuntu0.19.04.0 ProcVersionSignature: Ubuntu 5.0.0-27.28-generic 5.0.21 Uname: Linux 5.0.0-27-generic x86_64 ApportVersion: 2.20.10-0ubuntu27.1 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Wed Sep 11 15:06:14 2019 ExecutablePath: /usr/bin/nautilus SourcePackage: nautilus UpgradeStatus: No upgrade log present (probably fresh install) usr_lib_nautilus: To manage notifications about this bug go to: https://bugs.launchpad.net/nautilus/+bug/1843588/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1930359] Re: glib2.0: Uninitialised memory is written to gschema.compiled, failure to parse this file leads to gdm, gnome-shell failing to start
Thanks Iain. Looks like both of us sponsored it for the queue. I'd
appreciate rejecting either one of them.
Thanks!
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to glib2.0 in Ubuntu.
https://bugs.launchpad.net/bugs/1930359
Title:
glib2.0: Uninitialised memory is written to gschema.compiled, failure
to parse this file leads to gdm, gnome-shell failing to start
Status in GLib:
Unknown
Status in glib2.0 package in Ubuntu:
Fix Released
Status in glib2.0 source package in Focal:
In Progress
Bug description:
[Impact]
A recent SRU of mutter 3.36.9-0ubuntu0.20.04.1 caused an outage for a
user with 300 VDIs running Focal, where GNOME applications would fail
to start, and if you reboot, gdm and gnome-shell both fail to start,
and you are left with a black screen and a blinking cursor.
After much investigation, mutter was not at fault. Instead, mutter-
common calls the libglib2.0-0 hook on upgrade:
Processing triggers for libglib2.0-0:amd64 (2.64.6-1~ubuntu20.04.3)
...
This in turn calls glib-compile-schemas to recompile the gsettings
gschema cache, from the files in /usr/share/glib-2.0/schemas/. The
result is a binary gschemas.compiled file, which is loaded by
libglib2.0 on every invocation of a GNOME application, or gdm or
gnome-shell to fetch application default settings.
Now, glib2.0 2.64.6-1~ubuntu20.04.3 in Focal has some non-
deterministic behaviour when calling glib-compile-schemas, causing
generated gschemas.compiled files to have differing contents on each
run:
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cmp -l /home/ubuntu/schemas/gschemas.compiled
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
376F E3 D0
3771 A4 DB
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cmp -l /home/ubuntu/schemas/gschemas.compiled
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
376F E3 C3
3771 A4 98
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cmp -l /home/ubuntu/schemas/gschemas.compiled
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
376F E3 68
3771 A4 30
3772 55 56
The bytes on the left are from a corrupted gschemas.compiled provided
by an affected user. The changing bytes on the right are non-
deterministic.
I ran valgrind over glib-compile-schemas, and found that we are
writing to uninitialised memory.
https://paste.ubuntu.com/p/hvZccwdzxz/
What is happening is that a submodule of glib, gvdb, contains the
logic for serialising the gschema data structures, and when it
allocates a buffer to store the eventual gschemas.compiled file, it
does not initialise it.
When we populate the fields in the buffer, some bytes are never
overwritten, and these junk bytes find themselves written to
gschemas.compiled.
On boot, when gdm and gnome-shell attempt to parse and load this
corrupted gschemas.compiled file, it can't parse the junk bytes, and
raises and error, which propagates up to a breakpoint in glib logging,
but no debugger is present, so the kernel traps the breakpoint, and
terminates the library, and the calling application, e.g. gdm.
The result is that the user is left starting at a black screen with a
blinking pointer.
[Testcase]
On a Focal system, simply run valgrind over glib-compile-schemas:
# valgrind glib-compile-schemas /usr/share/glib-2.0/schemas
You will get output like this, with the warning "Syscall param
write(buf) points to uninitialised byte(s)":
https://paste.ubuntu.com/p/hvZccwdzxz/
If you happen to have a large amount of gschema overrides present on
your system, like my affected user does, you can save a copy of a
generated gschema.compiled to your home directory and bindiff it
against recompiles:
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cp /usr/share/glib-2.0/schemas/gschema.compiled
/home/ubuntu/schemas/gschemas.compiled
# glib-compile-schemas /usr/share/glib-2.0/schemas
# cmp -l /home/ubuntu/schemas/gschemas.compiled
/usr/share/glib-2.0/schemas/gschemas.compiled | gawk '{printf "%08X %02X
%02X\n", $1, strtonum(0$2), strtonum(0$3)}'
376F E3 C3
3771 A4 98
If you install the test package from the following ppa:
https://launchpad.net/~mruffell/+archive/ubuntu/sf311791-test
When you run valgrind, it will report a clean run with no writing to
uninitialised buffers, and all invocations of glib-compile-schemas
will be deterministic, and generate the file same with the same sha256
hash every time. The unwritten bytes if you do a bindiff from before
and after will be all set to zero.
[Where problems can occur]
I am doubtful that any programs are relying on buggy non-deterministic
[Desktop-packages] [Bug 1931602] Re: [apparmor] Segfault in logs with apparmor enabled
** Summary changed: - [apparmor] Segfault in logss with apparmor enabled + [apparmor] Segfault in logs with apparmor enabled -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox in Ubuntu. https://bugs.launchpad.net/bugs/1931602 Title: [apparmor] Segfault in logs with apparmor enabled Status in firefox package in Ubuntu: New Status in firefox source package in Focal: New Bug description: [Impact] * With apparmor enabled (and usr.bin.firefox in enforce mode) there is a crash happening every time right after launching Firefox. [Test Plan] * sudo aa-enforce /etc/apparmor.d/usr.bin.firefox * launch Firefox * See a similar segfault reported in the syslog: Jun 10 17:25:40 ubuntu kernel: [ 86.775837] firefox[1765]: segfault at 0 ip 7f724dd06384 sp 7fffa7aec450 error 6 in libxul.so[7f724a483000+53b2000] Jun 10 17:25:40 ubuntu kernel: [ 86.775843] Code: 00 0f 1f 44 00 00 50 80 3d f8 56 4c 04 00 74 02 58 c3 c6 05 ed 56 4c 04 01 48 8d 05 24 2c fa 02 48 8b 0d 77 f0 3a 04 48 89 01 04 25 00 00 00 00 8d 01 00 00 e8 74 63 78 fc 66 2e 0f 1f 84 00 [Where problems could occur] [Other Info] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1931602/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1931602] [NEW] [apparmor] Segfault in logss with apparmor enabled
Public bug reported: [Impact] * With apparmor enabled (and usr.bin.firefox in enforce mode) there is a crash happening every time right after launching Firefox. [Test Plan] * sudo aa-enforce /etc/apparmor.d/usr.bin.firefox * launch Firefox * See a similar segfault reported in the syslog: Jun 10 17:25:40 ubuntu kernel: [ 86.775837] firefox[1765]: segfault at 0 ip 7f724dd06384 sp 7fffa7aec450 error 6 in libxul.so[7f724a483000+53b2000] Jun 10 17:25:40 ubuntu kernel: [ 86.775843] Code: 00 0f 1f 44 00 00 50 80 3d f8 56 4c 04 00 74 02 58 c3 c6 05 ed 56 4c 04 01 48 8d 05 24 2c fa 02 48 8b 0d 77 f0 3a 04 48 89 01 04 25 00 00 00 00 8d 01 00 00 e8 74 63 78 fc 66 2e 0f 1f 84 00 [Where problems could occur] [Other Info] ** Affects: firefox (Ubuntu) Importance: Medium Status: New ** Affects: firefox (Ubuntu Focal) Importance: Undecided Status: New ** Tags: sts ** Also affects: firefox (Ubuntu Focal) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox in Ubuntu. https://bugs.launchpad.net/bugs/1931602 Title: [apparmor] Segfault in logss with apparmor enabled Status in firefox package in Ubuntu: New Status in firefox source package in Focal: New Bug description: [Impact] * With apparmor enabled (and usr.bin.firefox in enforce mode) there is a crash happening every time right after launching Firefox. [Test Plan] * sudo aa-enforce /etc/apparmor.d/usr.bin.firefox * launch Firefox * See a similar segfault reported in the syslog: Jun 10 17:25:40 ubuntu kernel: [ 86.775837] firefox[1765]: segfault at 0 ip 7f724dd06384 sp 7fffa7aec450 error 6 in libxul.so[7f724a483000+53b2000] Jun 10 17:25:40 ubuntu kernel: [ 86.775843] Code: 00 0f 1f 44 00 00 50 80 3d f8 56 4c 04 00 74 02 58 c3 c6 05 ed 56 4c 04 01 48 8d 05 24 2c fa 02 48 8b 0d 77 f0 3a 04 48 89 01 04 25 00 00 00 00 8d 01 00 00 e8 74 63 78 fc 66 2e 0f 1f 84 00 [Where problems could occur] [Other Info] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1931602/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1931603] [NEW] [apparmor] Unable to show Downloads with apparmor enabled
Public bug reported: Impact] * After a finished download (or opening the downloads list) it is impossible to "Open Containing Folder" for a downloaded file - pressing the button does nothing visible. [Test Plan] * sudo aa-enforce /etc/apparmor.d/usr.bin.firefox * launch Firefox * Download a file. * Go to downloads list. * Press the "Open Containing Folder" button next to the downloaded file on the list. [Where problems could occur] [Other Info] ** Affects: firefox (Ubuntu) Importance: Medium Status: New ** Affects: firefox (Ubuntu Focal) Importance: Undecided Status: New ** Tags: sts ** Changed in: firefox (Ubuntu) Importance: Undecided => Medium ** Tags added: sts ** Also affects: firefox (Ubuntu Focal) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to firefox in Ubuntu. https://bugs.launchpad.net/bugs/1931603 Title: [apparmor] Unable to show Downloads with apparmor enabled Status in firefox package in Ubuntu: New Status in firefox source package in Focal: New Bug description: Impact] * After a finished download (or opening the downloads list) it is impossible to "Open Containing Folder" for a downloaded file - pressing the button does nothing visible. [Test Plan] * sudo aa-enforce /etc/apparmor.d/usr.bin.firefox * launch Firefox * Download a file. * Go to downloads list. * Press the "Open Containing Folder" button next to the downloaded file on the list. [Where problems could occur] [Other Info] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1931603/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1878155] Re: Thunderbird fails to connect to server in FIPS mode
With latest builds from ppa:ubuntu-mozilla-security/ppa: Xenial - 1:68.8.0+build2-0ubuntu0.16.04.2 Bionic - 1:68.8.0+build2-0ubuntu0.18.04.2 this issue is gone. Thank you! -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to thunderbird in Ubuntu. https://bugs.launchpad.net/bugs/1878155 Title: Thunderbird fails to connect to server in FIPS mode Status in thunderbird package in Ubuntu: Fix Committed Status in thunderbird source package in Xenial: Fix Committed Status in thunderbird source package in Bionic: Fix Committed Status in thunderbird source package in Eoan: Fix Committed Status in thunderbird source package in Focal: Fix Committed Status in thunderbird source package in Groovy: Fix Committed Bug description: [Impact] * Thunderbird may become useless after booting into FIPS mode - it refuses to connect to server displaying the following message: Unexpected response from the server This document cannot be displayed unless you install the Personal Security Manager (PSM). Download and install PSM and try again, or contact your system administrator. This seems to be a result of the fact that despite Thunderbird for Ubuntu being with FIPS support disabled there's a piece of code that ignores the build flag and checks for `/proc/sys/crypto/fips_enabled` status anyway. Looks like upstream fix [1] needs to be applied to Thunderbird source under security/nss. [Test Case] * Configure an email account in Thunderbird. I was able to reproduce it with a gmail account. * Install FIPS modules as described in [2]. * Boot into FIPS mode. * Open Thunderbird. [Regression Potential] * I can't identify regression potential - this is clearly a bug fixed upstream by a simple fix. [Other Info] * Related Firefox bug: https://bugs.launchpad.net/bugs/1843044 * I was able to backport this fix and test it - the problem was gone. Xenial build is available in ppa:dgadomski/thunderbird. [1] https://hg.mozilla.org/projects/nss/raw-rev/55ba54adfcaea2f984a999a511eec5047462eb57 [2] https://docs.ubuntu.com/security-certs/en/fips To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1878155/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1878155] Re: Thunderbird fails to connect to server in FIPS mode
Sure, thanks Olivier. Can you give me an estimate on when this can be
fixed for Xenial and Bionic? For users using FIPS mode currently
Thunderbird is currently unusable.
** Changed in: thunderbird (Ubuntu Xenial)
Assignee: Dariusz Gadomski (dgadomski) => (unassigned)
** Changed in: thunderbird (Ubuntu Bionic)
Assignee: Dariusz Gadomski (dgadomski) => (unassigned)
** Changed in: thunderbird (Ubuntu Eoan)
Assignee: Dariusz Gadomski (dgadomski) => (unassigned)
** Changed in: thunderbird (Ubuntu Groovy)
Assignee: Dariusz Gadomski (dgadomski) => (unassigned)
** Changed in: thunderbird (Ubuntu Focal)
Assignee: Dariusz Gadomski (dgadomski) => (unassigned)
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to thunderbird in Ubuntu.
https://bugs.launchpad.net/bugs/1878155
Title:
Thunderbird fails to connect to server in FIPS mode
Status in thunderbird package in Ubuntu:
New
Status in thunderbird source package in Xenial:
New
Status in thunderbird source package in Bionic:
New
Status in thunderbird source package in Eoan:
New
Status in thunderbird source package in Focal:
New
Status in thunderbird source package in Groovy:
New
Bug description:
[Impact]
* Thunderbird may become useless after booting into FIPS mode - it
refuses to connect to server displaying the following message:
Unexpected response from the server
This document cannot be displayed unless you install the Personal
Security Manager (PSM). Download and install PSM and try again, or
contact your system administrator.
This seems to be a result of the fact that despite Thunderbird for
Ubuntu being with FIPS support disabled there's a piece of code that
ignores the build flag and checks for `/proc/sys/crypto/fips_enabled`
status anyway.
Looks like upstream fix [1] needs to be applied to Thunderbird source
under security/nss.
[Test Case]
* Configure an email account in Thunderbird. I was able to reproduce it with
a gmail account.
* Install FIPS modules as described in [2].
* Boot into FIPS mode.
* Open Thunderbird.
[Regression Potential]
* I can't identify regression potential - this is clearly a bug fixed
upstream by a simple fix.
[Other Info]
* Related Firefox bug: https://bugs.launchpad.net/bugs/1843044
* I was able to backport this fix and test it - the problem was gone. Xenial
build is available in ppa:dgadomski/thunderbird.
[1]
https://hg.mozilla.org/projects/nss/raw-rev/55ba54adfcaea2f984a999a511eec5047462eb57
[2] https://docs.ubuntu.com/security-certs/en/fips
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1878155/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1878155] Re: Thunderbird fails to connect to server in FIPS mode
Groovy fix. ** Patch added: "groovy.debdiff" https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1878155/+attachment/5370320/+files/groovy.debdiff -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to thunderbird in Ubuntu. https://bugs.launchpad.net/bugs/1878155 Title: Thunderbird fails to connect to server in FIPS mode Status in thunderbird package in Ubuntu: New Status in thunderbird source package in Xenial: New Status in thunderbird source package in Bionic: New Status in thunderbird source package in Eoan: New Status in thunderbird source package in Focal: New Status in thunderbird source package in Groovy: New Bug description: [Impact] * Thunderbird may become useless after booting into FIPS mode - it refuses to connect to server displaying the following message: Unexpected response from the server This document cannot be displayed unless you install the Personal Security Manager (PSM). Download and install PSM and try again, or contact your system administrator. This seems to be a result of the fact that despite Thunderbird for Ubuntu being with FIPS support disabled there's a piece of code that ignores the build flag and checks for `/proc/sys/crypto/fips_enabled` status anyway. Looks like upstream fix [1] needs to be applied to Thunderbird source under security/nss. [Test Case] * Configure an email account in Thunderbird. I was able to reproduce it with a gmail account. * Install FIPS modules as described in [2]. * Boot into FIPS mode. * Open Thunderbird. [Regression Potential] * I can't identify regression potential - this is clearly a bug fixed upstream by a simple fix. [Other Info] * Related Firefox bug: https://bugs.launchpad.net/bugs/1843044 * I was able to backport this fix and test it - the problem was gone. Xenial build is available in ppa:dgadomski/thunderbird. [1] https://hg.mozilla.org/projects/nss/raw-rev/55ba54adfcaea2f984a999a511eec5047462eb57 [2] https://docs.ubuntu.com/security-certs/en/fips To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1878155/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1878155] Re: Thunderbird fails to connect to server in FIPS mode
importance for Xenial and Bionic marked as high as this prevents Thunderbird from being used in FIPS mode on those releases. ** Changed in: thunderbird (Ubuntu Groovy) Assignee: (unassigned) => Dariusz Gadomski (dgadomski) ** Changed in: thunderbird (Ubuntu Focal) Assignee: (unassigned) => Dariusz Gadomski (dgadomski) ** Changed in: thunderbird (Ubuntu Eoan) Assignee: (unassigned) => Dariusz Gadomski (dgadomski) ** Changed in: thunderbird (Ubuntu Bionic) Assignee: (unassigned) => Dariusz Gadomski (dgadomski) ** Changed in: thunderbird (Ubuntu Xenial) Assignee: (unassigned) => Dariusz Gadomski (dgadomski) ** Changed in: thunderbird (Ubuntu Xenial) Importance: Undecided => Medium ** Changed in: thunderbird (Ubuntu Bionic) Importance: Undecided => Medium ** Changed in: thunderbird (Ubuntu Eoan) Importance: Undecided => Medium ** Changed in: thunderbird (Ubuntu Focal) Importance: Undecided => Medium ** Changed in: thunderbird (Ubuntu Groovy) Importance: Undecided => Medium ** Changed in: thunderbird (Ubuntu Xenial) Importance: Medium => High ** Changed in: thunderbird (Ubuntu Bionic) Importance: Medium => High ** Tags added: sts -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to thunderbird in Ubuntu. https://bugs.launchpad.net/bugs/1878155 Title: Thunderbird fails to connect to server in FIPS mode Status in thunderbird package in Ubuntu: New Status in thunderbird source package in Xenial: New Status in thunderbird source package in Bionic: New Status in thunderbird source package in Eoan: New Status in thunderbird source package in Focal: New Status in thunderbird source package in Groovy: New Bug description: [Impact] * Thunderbird may become useless after booting into FIPS mode - it refuses to connect to server displaying the following message: Unexpected response from the server This document cannot be displayed unless you install the Personal Security Manager (PSM). Download and install PSM and try again, or contact your system administrator. This seems to be a result of the fact that despite Thunderbird for Ubuntu being with FIPS support disabled there's a piece of code that ignores the build flag and checks for `/proc/sys/crypto/fips_enabled` status anyway. Looks like upstream fix [1] needs to be applied to Thunderbird source under security/nss. [Test Case] * Configure an email account in Thunderbird. I was able to reproduce it with a gmail account. * Install FIPS modules as described in [2]. * Boot into FIPS mode. * Open Thunderbird. [Regression Potential] * I can't identify regression potential - this is clearly a bug fixed upstream by a simple fix. [Other Info] * Related Firefox bug: https://bugs.launchpad.net/bugs/1843044 * I was able to backport this fix and test it - the problem was gone. Xenial build is available in ppa:dgadomski/thunderbird. [1] https://hg.mozilla.org/projects/nss/raw-rev/55ba54adfcaea2f984a999a511eec5047462eb57 [2] https://docs.ubuntu.com/security-certs/en/fips To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1878155/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1878155] Re: Thunderbird fails to connect to server in FIPS mode
It is already included upstream starting from release 75.0b1. ** Also affects: thunderbird (Ubuntu Groovy) Importance: Undecided Status: New ** Also affects: thunderbird (Ubuntu Eoan) Importance: Undecided Status: New ** Also affects: thunderbird (Ubuntu Focal) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to thunderbird in Ubuntu. https://bugs.launchpad.net/bugs/1878155 Title: Thunderbird fails to connect to server in FIPS mode Status in thunderbird package in Ubuntu: New Status in thunderbird source package in Xenial: New Status in thunderbird source package in Bionic: New Status in thunderbird source package in Eoan: New Status in thunderbird source package in Focal: New Status in thunderbird source package in Groovy: New Bug description: [Impact] * Thunderbird may become useless after booting into FIPS mode - it refuses to connect to server displaying the following message: Unexpected response from the server This document cannot be displayed unless you install the Personal Security Manager (PSM). Download and install PSM and try again, or contact your system administrator. This seems to be a result of the fact that despite Thunderbird for Ubuntu being with FIPS support disabled there's a piece of code that ignores the build flag and checks for `/proc/sys/crypto/fips_enabled` status anyway. Looks like upstream fix [1] needs to be applied to Thunderbird source under security/nss. [Test Case] * Configure an email account in Thunderbird. I was able to reproduce it with a gmail account. * Install FIPS modules as described in [2]. * Boot into FIPS mode. * Open Thunderbird. [Regression Potential] * I can't identify regression potential - this is clearly a bug fixed upstream by a simple fix. [Other Info] * Related Firefox bug: https://bugs.launchpad.net/bugs/1843044 * I was able to backport this fix and test it - the problem was gone. Xenial build is available in ppa:dgadomski/thunderbird. [1] https://hg.mozilla.org/projects/nss/raw-rev/55ba54adfcaea2f984a999a511eec5047462eb57 [2] https://docs.ubuntu.com/security-certs/en/fips To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1878155/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1878155] [NEW] Thunderbird fails to connect to server in FIPS mode
Public bug reported: [Impact] * Thunderbird may become useless after booting into FIPS mode - it refuses to connect to server displaying the following message: Unexpected response from the server This document cannot be displayed unless you install the Personal Security Manager (PSM). Download and install PSM and try again, or contact your system administrator. This seems to be a result of the fact that despite Thunderbird for Ubuntu being with FIPS support disabled there's a piece of code that ignores the build flag and checks for `/proc/sys/crypto/fips_enabled` status anyway. Looks like upstream fix [1] needs to be applied to Thunderbird source under security/nss. [Test Case] * Configure an email account in Thunderbird. I was able to reproduce it with a gmail account. * Install FIPS modules as described in [2]. * Boot into FIPS mode. * Open Thunderbird. [Regression Potential] * I can't identify regression potential - this is clearly a bug fixed upstream by a simple fix. [Other Info] * Related Firefox bug: https://bugs.launchpad.net/bugs/1843044 * I was able to backport this fix and test it - the problem was gone. Xenial build is available in ppa:dgadomski/thunderbird. [1] https://hg.mozilla.org/projects/nss/raw-rev/55ba54adfcaea2f984a999a511eec5047462eb57 [2] https://docs.ubuntu.com/security-certs/en/fips ** Affects: thunderbird (Ubuntu) Importance: Undecided Status: New ** Affects: thunderbird (Ubuntu Xenial) Importance: Undecided Status: New ** Affects: thunderbird (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: thunderbird (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: thunderbird (Ubuntu Bionic) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to thunderbird in Ubuntu. https://bugs.launchpad.net/bugs/1878155 Title: Thunderbird fails to connect to server in FIPS mode Status in thunderbird package in Ubuntu: New Status in thunderbird source package in Xenial: New Status in thunderbird source package in Bionic: New Bug description: [Impact] * Thunderbird may become useless after booting into FIPS mode - it refuses to connect to server displaying the following message: Unexpected response from the server This document cannot be displayed unless you install the Personal Security Manager (PSM). Download and install PSM and try again, or contact your system administrator. This seems to be a result of the fact that despite Thunderbird for Ubuntu being with FIPS support disabled there's a piece of code that ignores the build flag and checks for `/proc/sys/crypto/fips_enabled` status anyway. Looks like upstream fix [1] needs to be applied to Thunderbird source under security/nss. [Test Case] * Configure an email account in Thunderbird. I was able to reproduce it with a gmail account. * Install FIPS modules as described in [2]. * Boot into FIPS mode. * Open Thunderbird. [Regression Potential] * I can't identify regression potential - this is clearly a bug fixed upstream by a simple fix. [Other Info] * Related Firefox bug: https://bugs.launchpad.net/bugs/1843044 * I was able to backport this fix and test it - the problem was gone. Xenial build is available in ppa:dgadomski/thunderbird. [1] https://hg.mozilla.org/projects/nss/raw-rev/55ba54adfcaea2f984a999a511eec5047462eb57 [2] https://docs.ubuntu.com/security-certs/en/fips To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/1878155/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1733321] Re: network-manager ADT tests fail with on ppc64el with artful/linux 4.13.0.17.18
** Changed in: network-manager (Ubuntu Eoan) Assignee: Dariusz Gadomski (dgadomski) => (unassigned) ** Changed in: network-manager (Ubuntu Focal) Assignee: Dariusz Gadomski (dgadomski) => (unassigned) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1733321 Title: network-manager ADT tests fail with on ppc64el with artful/linux 4.13.0.17.18 Status in network-manager package in Ubuntu: New Status in network-manager source package in Artful: Won't Fix Status in network-manager source package in Disco: Won't Fix Status in network-manager source package in Eoan: New Status in network-manager source package in Focal: New Bug description: [Impact] The killswitches-no-urfkill autopkgtest fails sometimes because nmcli reports the old state when it's called right after rfkill block/unblock. Adding a sleep before calling nmcli fixes the issue. ppc64el ADT log from failed testcase: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-artful/artful/ppc64el/n/network- manager/20171120_100719_28642@/log.gz Testcase output: - autopkgtest [10:04:48]: test killswitches-no-urfkill: [--- make -C /lib/modules/4.13.0-17-generic/build KBUILD_SRC=/lib/modules/4.13.0-17-generic/build M=/tmp/autopkgtest.yE1hsA/build.62e/src/debian/tests make[1]: Entering directory '/usr/src/linux-headers-4.13.0-17-generic' AR /tmp/autopkgtest.yE1hsA/build.62e/src/debian/tests/built-in.o CC [M] /tmp/autopkgtest.yE1hsA/build.62e/src/debian/tests/fake-rfkill.o Building modules, stage 2. MODPOST 1 modules CC /tmp/autopkgtest.yE1hsA/build.62e/src/debian/tests/fake-rfkill.mod.o LD [M] /tmp/autopkgtest.yE1hsA/build.62e/src/debian/tests/fake-rfkill.ko make[1]: Leaving directory '/usr/src/linux-headers-4.13.0-17-generic' ERROR: NM could not track device state. autopkgtest [10:05:20]: test killswitches-no-urfkill: ---] autopkgtest [10:05:20]: test killswitches-no-urfkill: - - - - - - - - - - results - - - - - - - - - - killswitches-no-urfkill FAIL non-zero exit status 1 - Package versions [artful/ppc64el]: network-manager 1.8.4-1ubuntu3 linux-meta 4.13.0.17.18 [Test Case] 2.1. Download network-manager package source code $ apt-get source network-manager 2.2. Run killswitches-no-urfkill testcase $ cd network-manager-1.8.4 $ sudo ./debian/tests/killswitches-no-urfkill [Regression Potential] No regression potential. The fix touches only the testcase shipped with the source package and it doesn't change the binary package. The sleep time added is very small, so no possibility of causing testcase timeout. [Other Info] On ppc64el architecture, it was observed that a fix for systemd is also needed (see bug 1734908) for the testcase to be successful. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1733321/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1733321] Re: network-manager ADT tests fail with on ppc64el with artful/linux 4.13.0.17.18
Sure Dan, I'm looking into it. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1733321 Title: network-manager ADT tests fail with on ppc64el with artful/linux 4.13.0.17.18 Status in network-manager package in Ubuntu: New Status in network-manager source package in Artful: Won't Fix Status in network-manager source package in Disco: Won't Fix Status in network-manager source package in Eoan: New Status in network-manager source package in Focal: New Bug description: [Impact] The killswitches-no-urfkill autopkgtest fails sometimes because nmcli reports the old state when it's called right after rfkill block/unblock. Adding a sleep before calling nmcli fixes the issue. ppc64el ADT log from failed testcase: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-artful/artful/ppc64el/n/network- manager/20171120_100719_28642@/log.gz Testcase output: - autopkgtest [10:04:48]: test killswitches-no-urfkill: [--- make -C /lib/modules/4.13.0-17-generic/build KBUILD_SRC=/lib/modules/4.13.0-17-generic/build M=/tmp/autopkgtest.yE1hsA/build.62e/src/debian/tests make[1]: Entering directory '/usr/src/linux-headers-4.13.0-17-generic' AR /tmp/autopkgtest.yE1hsA/build.62e/src/debian/tests/built-in.o CC [M] /tmp/autopkgtest.yE1hsA/build.62e/src/debian/tests/fake-rfkill.o Building modules, stage 2. MODPOST 1 modules CC /tmp/autopkgtest.yE1hsA/build.62e/src/debian/tests/fake-rfkill.mod.o LD [M] /tmp/autopkgtest.yE1hsA/build.62e/src/debian/tests/fake-rfkill.ko make[1]: Leaving directory '/usr/src/linux-headers-4.13.0-17-generic' ERROR: NM could not track device state. autopkgtest [10:05:20]: test killswitches-no-urfkill: ---] autopkgtest [10:05:20]: test killswitches-no-urfkill: - - - - - - - - - - results - - - - - - - - - - killswitches-no-urfkill FAIL non-zero exit status 1 - Package versions [artful/ppc64el]: network-manager 1.8.4-1ubuntu3 linux-meta 4.13.0.17.18 [Test Case] 2.1. Download network-manager package source code $ apt-get source network-manager 2.2. Run killswitches-no-urfkill testcase $ cd network-manager-1.8.4 $ sudo ./debian/tests/killswitches-no-urfkill [Regression Potential] No regression potential. The fix touches only the testcase shipped with the source package and it doesn't change the binary package. The sleep time added is very small, so no possibility of causing testcase timeout. [Other Info] On ppc64el architecture, it was observed that a fix for systemd is also needed (see bug 1734908) for the testcase to be successful. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1733321/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1733321] Re: network-manager ADT tests fail with on ppc64el with artful/linux 4.13.0.17.18
** Changed in: network-manager (Ubuntu Eoan) Assignee: (unassigned) => Dariusz Gadomski (dgadomski) ** Changed in: network-manager (Ubuntu Focal) Assignee: (unassigned) => Dariusz Gadomski (dgadomski) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1733321 Title: network-manager ADT tests fail with on ppc64el with artful/linux 4.13.0.17.18 Status in network-manager package in Ubuntu: New Status in network-manager source package in Artful: Won't Fix Status in network-manager source package in Disco: Won't Fix Status in network-manager source package in Eoan: New Status in network-manager source package in Focal: New Bug description: [Impact] The killswitches-no-urfkill autopkgtest fails sometimes because nmcli reports the old state when it's called right after rfkill block/unblock. Adding a sleep before calling nmcli fixes the issue. ppc64el ADT log from failed testcase: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac /autopkgtest-artful/artful/ppc64el/n/network- manager/20171120_100719_28642@/log.gz Testcase output: - autopkgtest [10:04:48]: test killswitches-no-urfkill: [--- make -C /lib/modules/4.13.0-17-generic/build KBUILD_SRC=/lib/modules/4.13.0-17-generic/build M=/tmp/autopkgtest.yE1hsA/build.62e/src/debian/tests make[1]: Entering directory '/usr/src/linux-headers-4.13.0-17-generic' AR /tmp/autopkgtest.yE1hsA/build.62e/src/debian/tests/built-in.o CC [M] /tmp/autopkgtest.yE1hsA/build.62e/src/debian/tests/fake-rfkill.o Building modules, stage 2. MODPOST 1 modules CC /tmp/autopkgtest.yE1hsA/build.62e/src/debian/tests/fake-rfkill.mod.o LD [M] /tmp/autopkgtest.yE1hsA/build.62e/src/debian/tests/fake-rfkill.ko make[1]: Leaving directory '/usr/src/linux-headers-4.13.0-17-generic' ERROR: NM could not track device state. autopkgtest [10:05:20]: test killswitches-no-urfkill: ---] autopkgtest [10:05:20]: test killswitches-no-urfkill: - - - - - - - - - - results - - - - - - - - - - killswitches-no-urfkill FAIL non-zero exit status 1 - Package versions [artful/ppc64el]: network-manager 1.8.4-1ubuntu3 linux-meta 4.13.0.17.18 [Test Case] 2.1. Download network-manager package source code $ apt-get source network-manager 2.2. Run killswitches-no-urfkill testcase $ cd network-manager-1.8.4 $ sudo ./debian/tests/killswitches-no-urfkill [Regression Potential] No regression potential. The fix touches only the testcase shipped with the source package and it doesn't change the binary package. The sleep time added is very small, so no possibility of causing testcase timeout. [Other Info] On ppc64el architecture, it was observed that a fix for systemd is also needed (see bug 1734908) for the testcase to be successful. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1733321/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1762391] Re: pam_group.so is not evaluated by gnome-terminal
** No longer affects: gnome-terminal (Ubuntu) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1762391 Title: pam_group.so is not evaluated by gnome-terminal Status in systemd: New Status in systemd package in Ubuntu: In Progress Status in systemd source package in Xenial: New Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: Won't Fix Status in gnome-terminal source package in Eoan: New Status in systemd source package in Eoan: In Progress Bug description: We are using Ubuntu in a university network with lots of ldap users. To automatically map ldap users/groups to local groups we are using pam_group.so. This has worked for years. With the upgrade from Xenial to Bionic /etc/security/group.conf is not evaluated anymore by gnome-terminal as it runs as systemd --user. Xterm, ssh, su, and tty* however do work as expected. Only the default gnome-terminal behaves different. According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851243 and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756458 this might not be a bug, but a feature. Nevertheless this behavior is very unexpected when upgrading from Xenial to Bionic and therefore should at least added to the changelog. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gnome-terminal 3.28.0-1ubuntu1 ProcVersionSignature: Ubuntu 4.15.0-10.11-generic 4.15.3 Uname: Linux 4.15.0-10-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.9-0ubuntu4 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Mon Apr 9 13:17:52 2018 InstallationDate: Installed on 2018-03-29 (11 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180321) SourcePackage: gnome-terminal UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1762391/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1762391] Re: pam_group.so is not evaluated by gnome-terminal
Please hold on with uploading until https://github.com/systemd/systemd/issues/14567 is resolved. ** Bug watch added: github.com/systemd/systemd/issues #14567 https://github.com/systemd/systemd/issues/14567 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1762391 Title: pam_group.so is not evaluated by gnome-terminal Status in systemd: New Status in gnome-terminal package in Ubuntu: Invalid Status in systemd package in Ubuntu: In Progress Status in systemd source package in Xenial: New Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: Won't Fix Status in gnome-terminal source package in Eoan: New Status in systemd source package in Eoan: In Progress Bug description: We are using Ubuntu in a university network with lots of ldap users. To automatically map ldap users/groups to local groups we are using pam_group.so. This has worked for years. With the upgrade from Xenial to Bionic /etc/security/group.conf is not evaluated anymore by gnome-terminal as it runs as systemd --user. Xterm, ssh, su, and tty* however do work as expected. Only the default gnome-terminal behaves different. According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851243 and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756458 this might not be a bug, but a feature. Nevertheless this behavior is very unexpected when upgrading from Xenial to Bionic and therefore should at least added to the changelog. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gnome-terminal 3.28.0-1ubuntu1 ProcVersionSignature: Ubuntu 4.15.0-10.11-generic 4.15.3 Uname: Linux 4.15.0-10-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.9-0ubuntu4 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Mon Apr 9 13:17:52 2018 InstallationDate: Installed on 2018-03-29 (11 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180321) SourcePackage: gnome-terminal UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1762391/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1762391] Re: pam_group.so is not evaluated by gnome-terminal
SRU proposal for Focal (upstream backport). ** Patch added: "focal_systemd_244-3ubuntu4.debdiff" https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1762391/+attachment/5320077/+files/focal_systemd_244-3ubuntu4.debdiff -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1762391 Title: pam_group.so is not evaluated by gnome-terminal Status in systemd: New Status in gnome-terminal package in Ubuntu: Invalid Status in systemd package in Ubuntu: In Progress Status in systemd source package in Xenial: New Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: Won't Fix Status in gnome-terminal source package in Eoan: New Status in systemd source package in Eoan: In Progress Bug description: We are using Ubuntu in a university network with lots of ldap users. To automatically map ldap users/groups to local groups we are using pam_group.so. This has worked for years. With the upgrade from Xenial to Bionic /etc/security/group.conf is not evaluated anymore by gnome-terminal as it runs as systemd --user. Xterm, ssh, su, and tty* however do work as expected. Only the default gnome-terminal behaves different. According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851243 and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756458 this might not be a bug, but a feature. Nevertheless this behavior is very unexpected when upgrading from Xenial to Bionic and therefore should at least added to the changelog. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gnome-terminal 3.28.0-1ubuntu1 ProcVersionSignature: Ubuntu 4.15.0-10.11-generic 4.15.3 Uname: Linux 4.15.0-10-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.9-0ubuntu4 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Mon Apr 9 13:17:52 2018 InstallationDate: Installed on 2018-03-29 (11 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180321) SourcePackage: gnome-terminal UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1762391/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1762391] Re: pam_group.so is not evaluated by gnome-terminal
This issue has been fixed upstream, I believe it makes sense to also have it in Ubuntu. ** Changed in: systemd (Ubuntu Bionic) Status: Won't Fix => In Progress ** Changed in: systemd (Ubuntu) Status: Won't Fix => In Progress ** Changed in: systemd (Ubuntu) Assignee: (unassigned) => Dariusz Gadomski (dgadomski) ** Changed in: systemd (Ubuntu Bionic) Assignee: (unassigned) => Dariusz Gadomski (dgadomski) ** Also affects: gnome-terminal (Ubuntu Eoan) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Eoan) Importance: Undecided Status: New ** Changed in: systemd (Ubuntu Eoan) Status: New => In Progress ** Changed in: systemd (Ubuntu Eoan) Assignee: (unassigned) => Dariusz Gadomski (dgadomski) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1762391 Title: pam_group.so is not evaluated by gnome-terminal Status in systemd: New Status in gnome-terminal package in Ubuntu: Invalid Status in systemd package in Ubuntu: In Progress Status in systemd source package in Xenial: New Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: Won't Fix Status in gnome-terminal source package in Eoan: New Status in systemd source package in Eoan: In Progress Bug description: We are using Ubuntu in a university network with lots of ldap users. To automatically map ldap users/groups to local groups we are using pam_group.so. This has worked for years. With the upgrade from Xenial to Bionic /etc/security/group.conf is not evaluated anymore by gnome-terminal as it runs as systemd --user. Xterm, ssh, su, and tty* however do work as expected. Only the default gnome-terminal behaves different. According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851243 and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756458 this might not be a bug, but a feature. Nevertheless this behavior is very unexpected when upgrading from Xenial to Bionic and therefore should at least added to the changelog. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gnome-terminal 3.28.0-1ubuntu1 ProcVersionSignature: Ubuntu 4.15.0-10.11-generic 4.15.3 Uname: Linux 4.15.0-10-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.9-0ubuntu4 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Mon Apr 9 13:17:52 2018 InstallationDate: Installed on 2018-03-29 (11 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180321) SourcePackage: gnome-terminal UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1762391/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1851407] Re: NetworkManager 1.10.6-2ubuntu1.2 breaks VPN DNS
Thanks Joe. There has to be another factor coming into play, as my setup contains "use only for resources on its network". $ nmcli connection show my-vpn | grep -e ipv4.never-default -e ipv4.dns-priority ipv4.dns-priority: -30 ipv4.never-default: yes Are you able to test this on Ubuntu 19.10? It does not have the patch and in my tests it's consistent with what I observe on the patched 18.04. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1851407 Title: NetworkManager 1.10.6-2ubuntu1.2 breaks VPN DNS Status in network-manager package in Ubuntu: Confirmed Bug description: NetworkManager as of 1.10.6-2ubuntu1.2 has cause a regression whereby a VPN connection which sets it's dns-priority to a negative value, which should cause the DNS server supplied by the DNS connection to be placed first, instead now refuses to place the DNS server into the resolver under any circumstance. Pinning the 1.10.6-2ubuntu1.1 works around the issue. I suspect the fix-dns-leak-lp1754671.patch has caused this regression. This patch should be reverted as soon as possible to restore proper functionality of network manager with respect to VPN servers with DNS resolvers. $ lsb_release -rd Description: Ubuntu 18.04.3 LTS Release: 18.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1851407/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1851407] Re: NetworkManager 1.10.6-2ubuntu1.2 breaks VPN DNS
Joe, I still can't reproduce your issue. Can you please verify against what I'm trying: 1. Setup a VPN that provides DNS via DHCP 2. Connect to that VPN and verify DNS by: $ systemd-resolve --status (...) Link 4 (tun0) (...) DNS Servers: X.X.X.X (...) 3. Disconnect VPN and edit connection: $ nmcli connection edit myvpn nmcli> set ipv4.dns-priority -30 nmcli> save $ nmcli connection show myvpn | grep dns-priority ipv4.dns-priority: -30 ipv6.dns-priority: 0 4. Re-connect to VPN and try to reach a name within the VPN: $ dig some.host.in.my.vpn I have used: $ apt-cache policy network-manager network-manager: Installed: 1.10.6-2ubuntu1.2 Please tell me in which of the steps in your case network-manager behaves differently. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1851407 Title: NetworkManager 1.10.6-2ubuntu1.2 breaks VPN DNS Status in network-manager package in Ubuntu: Confirmed Bug description: NetworkManager as of 1.10.6-2ubuntu1.2 has cause a regression whereby a VPN connection which sets it's dns-priority to a negative value, which should cause the DNS server supplied by the DNS connection to be placed first, instead now refuses to place the DNS server into the resolver under any circumstance. Pinning the 1.10.6-2ubuntu1.1 works around the issue. I suspect the fix-dns-leak-lp1754671.patch has caused this regression. This patch should be reverted as soon as possible to restore proper functionality of network manager with respect to VPN servers with DNS resolvers. $ lsb_release -rd Description: Ubuntu 18.04.3 LTS Release: 18.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1851407/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1851793] Re: NetworkManager OpenVPN No longer sets up DNS if "Use this connection only for resources on its network" is ticked
Can you connect to that VPN with the same settings, but from a virtual machine with a freshly installed system? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager-openvpn in Ubuntu. https://bugs.launchpad.net/bugs/1851793 Title: NetworkManager OpenVPN No longer sets up DNS if "Use this connection only for resources on its network" is ticked Status in network-manager-openvpn package in Ubuntu: Incomplete Bug description: Hi, after recent update few days ago, I noticed that DNS is not configured if "Use this connection only for resources" on its network is ticked, for OpenVPN, which used to work till latest update. My config: - IPv4 Method: Automatic (DHCP) - DNS: 10.1.0.1, Automatic: Off - Routes: Automatic: On - [x] Use this connection ... If OpenVPN is setup to work for all resources, then DNS is configured properly. It would be nice if DNS is also configured as before. BR Uros Description: Ubuntu 18.04.3 LTS Release: 18.04 network-manager-openvpn: Installed: 1.8.2-1 Candidate: 1.8.2-1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager-openvpn/+bug/1851793/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1851793] Re: NetworkManager OpenVPN No longer sets up DNS if "Use this connection only for resources on its network" is ticked
The behavior described in this bug seems to be consistent with what is the default in Eoan (19.10). Uros, are you able to check if 19.10 network-manager is also affected with this? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager-openvpn in Ubuntu. https://bugs.launchpad.net/bugs/1851793 Title: NetworkManager OpenVPN No longer sets up DNS if "Use this connection only for resources on its network" is ticked Status in network-manager-openvpn package in Ubuntu: Incomplete Bug description: Hi, after recent update few days ago, I noticed that DNS is not configured if "Use this connection only for resources" on its network is ticked, for OpenVPN, which used to work till latest update. My config: - IPv4 Method: Automatic (DHCP) - DNS: 10.1.0.1, Automatic: Off - Routes: Automatic: On - [x] Use this connection ... If OpenVPN is setup to work for all resources, then DNS is configured properly. It would be nice if DNS is also configured as before. BR Uros Description: Ubuntu 18.04.3 LTS Release: 18.04 network-manager-openvpn: Installed: 1.8.2-1 Candidate: 1.8.2-1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager-openvpn/+bug/1851793/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1851793] Re: NetworkManager OpenVPN No longer sets up DNS if "Use this connection only for resources on its network" is ticked
I examined the differences between bionic and upstream NetworkManager source around systemd-resolved interactions. I did not see any significant differences to blame for this. I have just tested it on a build from nm-1-10 branch of upstream NetworkManager and the behavior seems to be identical: the DNS for VPN is lost. This looks like an upstream issue. I will do more testing to confirm. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager-openvpn in Ubuntu. https://bugs.launchpad.net/bugs/1851793 Title: NetworkManager OpenVPN No longer sets up DNS if "Use this connection only for resources on its network" is ticked Status in network-manager-openvpn package in Ubuntu: Incomplete Bug description: Hi, after recent update few days ago, I noticed that DNS is not configured if "Use this connection only for resources" on its network is ticked, for OpenVPN, which used to work till latest update. My config: - IPv4 Method: Automatic (DHCP) - DNS: 10.1.0.1, Automatic: Off - Routes: Automatic: On - [x] Use this connection ... If OpenVPN is setup to work for all resources, then DNS is configured properly. It would be nice if DNS is also configured as before. BR Uros Description: Ubuntu 18.04.3 LTS Release: 18.04 network-manager-openvpn: Installed: 1.8.2-1 Candidate: 1.8.2-1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager-openvpn/+bug/1851793/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1851793] Re: NetworkManager OpenVPN No longer sets up DNS if "Use this connection only for resources on its network" is ticked
I've checked that and what I see is: the DNS setting is visible in nmcli output, but it's not propagated to systemd-resolved (no DNS entry for the VPN connection in systemd-resolved --status). Looking into that. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager-openvpn in Ubuntu. https://bugs.launchpad.net/bugs/1851793 Title: NetworkManager OpenVPN No longer sets up DNS if "Use this connection only for resources on its network" is ticked Status in network-manager-openvpn package in Ubuntu: Incomplete Bug description: Hi, after recent update few days ago, I noticed that DNS is not configured if "Use this connection only for resources" on its network is ticked, for OpenVPN, which used to work till latest update. My config: - IPv4 Method: Automatic (DHCP) - DNS: 10.1.0.1, Automatic: Off - Routes: Automatic: On - [x] Use this connection ... If OpenVPN is setup to work for all resources, then DNS is configured properly. It would be nice if DNS is also configured as before. BR Uros Description: Ubuntu 18.04.3 LTS Release: 18.04 network-manager-openvpn: Installed: 1.8.2-1 Candidate: 1.8.2-1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager-openvpn/+bug/1851793/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1851407] Re: NetworkManager 1.10.6-2ubuntu1.2 breaks VPN DNS
Joe, thanks for reporting the bug. I am unable to reproduce the issue in my test env. Can you please provide a step-by-step procedure to reproduce it on a clean 18.04 installation? Thanks. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1851407 Title: NetworkManager 1.10.6-2ubuntu1.2 breaks VPN DNS Status in network-manager package in Ubuntu: Confirmed Bug description: NetworkManager as of 1.10.6-2ubuntu1.2 has cause a regression whereby a VPN connection which sets it's dns-priority to a negative value, which should cause the DNS server supplied by the DNS connection to be placed first, instead now refuses to place the DNS server into the resolver under any circumstance. Pinning the 1.10.6-2ubuntu1.1 works around the issue. I suspect the fix-dns-leak-lp1754671.patch has caused this regression. This patch should be reverted as soon as possible to restore proper functionality of network manager with respect to VPN servers with DNS resolvers. $ lsb_release -rd Description: Ubuntu 18.04.3 LTS Release: 18.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1851407/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1754671] Re: Full-tunnel VPN DNS leakage regression
I have just run the test case from this bug description on the bionic-proposed version 1.10.6-2ubuntu1.2. tcpdump does not show any leak of the VPN-specific queries. I have not observed other issues in my tests. ** Tags removed: verification-needed verification-needed-bionic ** Tags added: verification-done verification-done-bionic -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1754671 Title: Full-tunnel VPN DNS leakage regression Status in NetworkManager: Confirmed Status in network-manager package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in network-manager source package in Xenial: Confirmed Status in systemd source package in Xenial: Invalid Status in network-manager source package in Bionic: Fix Committed Status in systemd source package in Bionic: Fix Released Status in network-manager source package in Cosmic: Fix Released Status in systemd source package in Cosmic: Fix Released Bug description: [Impact] When using a VPN the DNS requests might still be sent to a DNS server outside the VPN when they should not [Test case] 1) Set up a VPN with split tunneling: a) Configure VPN normally (set up remote host, any ports and options needed for the VPN to work) b) Under the IPv4 tab: enable "Use this connection only for the resources on its network". c) Under the IPv6 tab: enable "Use this connection only for the resources on its network". 2) Connect to the VPN. 3) Run 'systemd-resolve --status'; note the DNS servers configured: a) For the VPN; under a separate link (probably tun0), note down the IP of the DNS server(s). Also note the name of the interface (link). b) For the "main" connection; under the link for your ethernet or wireless devices (wl*, en*, whatever it may be), note down the IP of the DNS server(s). Also note the name of the interface (link). 4) In a separate terminal, run 'sudo tcpdump -ni port 53'; let it run. 5) In a separate terminal, run 'sudo tcpdump -ni port 53'; let it run. 6) In yet another terminal, issue name resolution requests using dig: a) For a name known to be reachable via the public network: 'dig www.yahoo.com' b) For a name known to be reachable only via the VPN: 'dig ' 7) Check the output of each terminal running tcpdump. When requesting the public name, traffic can go through either. When requesting the "private" name (behind the VPN), traffic should only be going through the interface for the VPN. Additionally, ensure the IP receiving the requests for the VPN name is indeed the IP address noted above for the VPN's DNS server. If you see no traffic showing in tcpdump output when requesting a name, it may be because it is cached by systemd-resolved. Use a different name you have not tried before. [Regression potential] The code change the handling of DNS servers when using a VPN, we should check that name resolution still work whne using a VPN in different configurations - In 16.04 the NetworkManager package used to carry this patch: http://bazaar.launchpad.net/~network-manager/network-manager/ubuntu/view/head:/debian/patches/Filter-DNS-servers-to-add-to-dnsmasq-based-on-availa.patch It fixed the DNS setup so that when I'm on the VPN, I am not sending unencrypted DNS queries to the (potentially hostile) local nameservers. This patch disappeared in an update. I think it was present in 1.2.2-0ubuntu0.16.04.4 but was dropped some time later. This security bug exists upstream too: https://bugzilla.gnome.org/show_bug.cgi?id=746422 It's not a *regression* there though, as they didn't fix it yet (unfortunately!) To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager/+bug/1754671/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1754671] Re: Full-tunnel VPN DNS leakage regression
I have backported what was listed as nm-1-10 fix for the bug in the upstream bugzilla [1]. I have also applied fixes for bug #1825946 and bug #1790098 to it. [1] https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=1e486a721de1fec76c81bfc461671a7fbdae531b After testing this build for some time (available at ppa:dgadomski /network-manager) I haven't found any problems. @Till I'd appreciate you having a look at it. Thanks! ** Patch added: "bionic_network-manager_1.10.6-2ubuntu1.2.debdiff" https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1754671/+attachment/5296236/+files/bionic_network-manager_1.10.6-2ubuntu1.2.debdiff -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1754671 Title: Full-tunnel VPN DNS leakage regression Status in NetworkManager: Confirmed Status in network-manager package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in network-manager source package in Xenial: Confirmed Status in systemd source package in Xenial: Invalid Status in network-manager source package in Bionic: In Progress Status in systemd source package in Bionic: Fix Released Status in network-manager source package in Cosmic: Won't Fix Status in systemd source package in Cosmic: Fix Released Bug description: [Impact] When using a VPN the DNS requests might still be sent to a DNS server outside the VPN when they should not [Test case] 1) Set up a VPN with split tunneling: a) Configure VPN normally (set up remote host, any ports and options needed for the VPN to work) b) Under the IPv4 tab: enable "Use this connection only for the resources on its network". c) Under the IPv6 tab: enable "Use this connection only for the resources on its network". 2) Connect to the VPN. 3) Run 'systemd-resolve --status'; note the DNS servers configured: a) For the VPN; under a separate link (probably tun0), note down the IP of the DNS server(s). Also note the name of the interface (link). b) For the "main" connection; under the link for your ethernet or wireless devices (wl*, en*, whatever it may be), note down the IP of the DNS server(s). Also note the name of the interface (link). 4) In a separate terminal, run 'sudo tcpdump -ni port 53'; let it run. 5) In a separate terminal, run 'sudo tcpdump -ni port 53'; let it run. 6) In yet another terminal, issue name resolution requests using dig: a) For a name known to be reachable via the public network: 'dig www.yahoo.com' b) For a name known to be reachable only via the VPN: 'dig ' 7) Check the output of each terminal running tcpdump. When requesting the public name, traffic can go through either. When requesting the "private" name (behind the VPN), traffic should only be going through the interface for the VPN. Additionally, ensure the IP receiving the requests for the VPN name is indeed the IP address noted above for the VPN's DNS server. If you see no traffic showing in tcpdump output when requesting a name, it may be because it is cached by systemd-resolved. Use a different name you have not tried before. [Regression potential] The code change the handling of DNS servers when using a VPN, we should check that name resolution still work whne using a VPN in different configurations - In 16.04 the NetworkManager package used to carry this patch: http://bazaar.launchpad.net/~network-manager/network-manager/ubuntu/view/head:/debian/patches/Filter-DNS-servers-to-add-to-dnsmasq-based-on-availa.patch It fixed the DNS setup so that when I'm on the VPN, I am not sending unencrypted DNS queries to the (potentially hostile) local nameservers. This patch disappeared in an update. I think it was present in 1.2.2-0ubuntu0.16.04.4 but was dropped some time later. This security bug exists upstream too: https://bugzilla.gnome.org/show_bug.cgi?id=746422 It's not a *regression* there though, as they didn't fix it yet (unfortunately!) To manage notifications about this bug go to: https://bugs.launchpad.net/network-manager/+bug/1754671/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1831021] Re: Extremely high memory consumption under heavy workload
** Tags added: sts -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1831021 Title: Extremely high memory consumption under heavy workload Status in cups package in Ubuntu: Triaged Bug description: Under heavy workload conditions cups can reach irrationally high memory consumption very quickly (tens of GBs). Test case: 1. Set MaxJobs to 4 in cupsd.conf. 2. sudo apt install cups-pdf 3. Fill the queue with jobs: while [ 1 ]; lp -d PDF /usr/share/cups/data/default.pdf; done 4. Cancel all jobs cancel -a PDF 5. Restart cups. 6. Start filling the queue again (as in step 3). Expected result: Jobs are processed and memory consumption is proportional to the number of jobs. Actual result: After step 5 or at latest step 6 memory consumption starts to increase exponentially - from ~150-200 MB to 8+GB. Without foreseeing this it's very easy to get cupsd killed by OOM killer. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1831021/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1830022] Re: DirtyCleanInterval should be 0 by default
** Tags added: sts -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1830022 Title: DirtyCleanInterval should be 0 by default Status in cups package in Ubuntu: Confirmed Bug description: Please consider changing DirtyCleanInterval value to 0 as default. Otherwise if cupsd crashes due to (e.g. OOM killer) under a heavy workload even hundreds of jobs may be lost. This concern is backed up by a real-life scenario and leaves the client sending thousands of jobs unaware that many of them are lost during a crash. After cupsd gets restarted it rewinds it's job counter to the last cached and continues unaware about the jobs accepted and lost. Having DirtyCleanInterval set to 0 will cause some performance impact, but not significant under lighter workloads and a completely justified price for reliability under heavy workloads. Test scenario: 1. sudo apt install printer-driver-cups-pdf 2. while [ 1 ]; do lp -d PDF somepdf.pdf; done; 3. # on other terminal kill -9 $(pidof cupsd) 4. Note last job number and wait for cupsd to be restarted by systemd. 5. Once accepting jobs is resumend the job counter is rewound. Expected behavior: Accepted jobs are queued for processing. Actual behavior: Some accepted jobs are lost. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1830022/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1747765] Re: PreserveJobHistory and PreserveJobLog do not respect numeric input as outlined in the docs
** Tags removed: verification-needed verification-needed-xenial ** Tags added: verification-done verification-done-xenial -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1747765 Title: PreserveJobHistory and PreserveJobLog do not respect numeric input as outlined in the docs Status in cups package in Ubuntu: Fix Released Status in cups source package in Xenial: Fix Committed Status in cups source package in Bionic: Fix Committed Status in cups source package in Cosmic: Fix Committed Status in cups source package in Disco: Fix Committed Bug description: [Impact] The documentation allows the following types of arguments for the PreserveJobHistory parameter: PreserveJobHistory Yes PreserveJobHistory No PreserveJobHistory seconds The value in seconds is treated in the same as 'No' resulting in immediate removing of jobs from history, while it is supposed to save it for . [Test Case] 1. Set PreserveJobHistory to 30. Set LogLevel to debug. 2. Schedule a job for printing. 3. Check the error_log. 4. Set PreserveJobHistory to No. Repeat 2-3. 5. Set PreserveJobHistory to Yes. Repeat 2-3. Expected result (for PreserveJobHistory values): 30: Job is save for at least 30 seconds. No: Job is removed right after processing. Yes: Job is never removed. Actual results (for PreserveJobHistory values): 30: Job is immediately removed from history. No: Job is removed right after processing. Yes: Job is never removed. [Regression Potential] * With the fix the jobs will be saved longer than before, so in tight conditions (low disk space) and heavy workload it may affect memory/disk space consumption and lead to running out of free space in worst case. [Other Info] * Original bug description: 1) Ubuntu Release Description: Ubuntu 16.04.3 LTS Release: 16.04 2) Version of the package cups: Installed: 2.1.3-4ubuntu0.3 Candidate: 2.1.3-4ubuntu0.3 Version table: *** 2.1.3-4ubuntu0.3 500 500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 3) What I expected to happen: from man cupsd.conf PreserveJobFiles Yes PreserveJobFiles No PreserveJobFiles seconds Specifies whether job files (documents) are preserved after a job is printed. If a numeric value is specified, job files are preserved for the indicated number of seconds after printing. The default is "86400" (preserve 1 day). PreserveJobHistory Yes PreserveJobHistory No PreserveJobHistory seconds Specifies whether the job history is preserved after a job is printed. If a numeric value is specified, the job history is preserved for the indicated number of seconds after printing. If "Yes", the job history is preserved until the MaxJobs limit is reached. The default is "Yes". 4) What happens instead If I put the following directives in cupsd.conf the job files and history are deleted immediately. PreserveJobFiles 604800 PreserveJobHistory 604800 Debug log showing history being purged: d [06/Feb/2018:15:11:59 -0600] cupsdCheckJobs: 0 active jobs, sleeping=0, ac-power=-1, reload=0, curtime=1517951519 d [06/Feb/2018:15:11:59 -0600] cupsdCleanJobs: MaxJobs=100, JobHistory=604800, JobFiles=604800 D [06/Feb/2018:15:11:59 -0600] [Job 106] Removing from history. D [06/Feb/2018:15:11:59 -0600] [Job 106] Unloading... To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1747765/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1747765] Re: PreserveJobHistory and PreserveJobLog do not respect numeric input as outlined in the docs
Despite some build failures for i386 and s390 which I believe are not related to the scope of the change I have successfully verified it for amd64. apt-cache policy cups-daemon cups: Installed: 2.1.3-4ubuntu0.9 lp -d PDF /usr/share/cups/data/default.pdf PreserveJobHistory 30: I [04/Jun/2019:13:19:56 +] [Job 1] Job completed. D [04/Jun/2019:13:20:27 +] [Job 1] Removing from history. PreserveJobHistory No: I [04/Jun/2019:13:22:32 +] [Job 2] Job completed. D [04/Jun/2019:13:22:32 +] [Job 2] Removing from history. PreserveJobHistory Yes: I [04/Jun/2019:13:23:41 +] [Job 3] Job completed. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1747765 Title: PreserveJobHistory and PreserveJobLog do not respect numeric input as outlined in the docs Status in cups package in Ubuntu: Fix Released Status in cups source package in Xenial: Fix Committed Status in cups source package in Bionic: Fix Committed Status in cups source package in Cosmic: Fix Committed Status in cups source package in Disco: Fix Committed Bug description: [Impact] The documentation allows the following types of arguments for the PreserveJobHistory parameter: PreserveJobHistory Yes PreserveJobHistory No PreserveJobHistory seconds The value in seconds is treated in the same as 'No' resulting in immediate removing of jobs from history, while it is supposed to save it for . [Test Case] 1. Set PreserveJobHistory to 30. Set LogLevel to debug. 2. Schedule a job for printing. 3. Check the error_log. 4. Set PreserveJobHistory to No. Repeat 2-3. 5. Set PreserveJobHistory to Yes. Repeat 2-3. Expected result (for PreserveJobHistory values): 30: Job is save for at least 30 seconds. No: Job is removed right after processing. Yes: Job is never removed. Actual results (for PreserveJobHistory values): 30: Job is immediately removed from history. No: Job is removed right after processing. Yes: Job is never removed. [Regression Potential] * With the fix the jobs will be saved longer than before, so in tight conditions (low disk space) and heavy workload it may affect memory/disk space consumption and lead to running out of free space in worst case. [Other Info] * Original bug description: 1) Ubuntu Release Description: Ubuntu 16.04.3 LTS Release: 16.04 2) Version of the package cups: Installed: 2.1.3-4ubuntu0.3 Candidate: 2.1.3-4ubuntu0.3 Version table: *** 2.1.3-4ubuntu0.3 500 500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 3) What I expected to happen: from man cupsd.conf PreserveJobFiles Yes PreserveJobFiles No PreserveJobFiles seconds Specifies whether job files (documents) are preserved after a job is printed. If a numeric value is specified, job files are preserved for the indicated number of seconds after printing. The default is "86400" (preserve 1 day). PreserveJobHistory Yes PreserveJobHistory No PreserveJobHistory seconds Specifies whether the job history is preserved after a job is printed. If a numeric value is specified, the job history is preserved for the indicated number of seconds after printing. If "Yes", the job history is preserved until the MaxJobs limit is reached. The default is "Yes". 4) What happens instead If I put the following directives in cupsd.conf the job files and history are deleted immediately. PreserveJobFiles 604800 PreserveJobHistory 604800 Debug log showing history being purged: d [06/Feb/2018:15:11:59 -0600] cupsdCheckJobs: 0 active jobs, sleeping=0, ac-power=-1, reload=0, curtime=1517951519 d [06/Feb/2018:15:11:59 -0600] cupsdCleanJobs: MaxJobs=100, JobHistory=604800, JobFiles=604800 D [06/Feb/2018:15:11:59 -0600] [Job 106] Removing from history. D [06/Feb/2018:15:11:59 -0600] [Job 106] Unloading... To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1747765/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1747765] Re: PreserveJobHistory and PreserveJobLog do not respect numeric input as outlined in the docs
** Changed in: cups (Ubuntu Disco) Assignee: Dariusz Gadomski (dgadomski) => (unassigned) ** Description changed: [Impact] The documentation allows the following types of arguments for the PreserveJobHistory parameter: PreserveJobHistory Yes PreserveJobHistory No PreserveJobHistory seconds The value in seconds is treated in the same as 'No' resulting in immediate removing of jobs from history, while it is supposed to save it for . [Test Case] 1. Set PreserveJobHistory to 30. Set LogLevel to debug. 2. Schedule a job for printing. 3. Check the error_log. - 4. Set PreserveJobHistory to Yes. Repeat 2-3. - 5. Set PreserveJobHistory to No. Repeat 2-3. + 4. Set PreserveJobHistory to No. Repeat 2-3. + 5. Set PreserveJobHistory to Yes. Repeat 2-3. + Expected result (for PreserveJobHistory values): 30: Job is save for at least 30 seconds. + No: Job is removed right after processing. Yes: Job is never removed. - No: Job is removed right after processing. Actual results (for PreserveJobHistory values): 30: Job is immediately removed from history. + No: Job is removed right after processing. Yes: Job is never removed. - No: Job is removed right after processing. [Regression Potential] * With the fix the jobs will be saved longer than before, so in tight conditions (low disk space) and heavy workload it may affect memory/disk space consumption and lead to running out of free space in worst case. [Other Info] * Original bug description: 1) Ubuntu Release Description: Ubuntu 16.04.3 LTS Release: 16.04 2) Version of the package cups: Installed: 2.1.3-4ubuntu0.3 Candidate: 2.1.3-4ubuntu0.3 Version table: *** 2.1.3-4ubuntu0.3 500 500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 3) What I expected to happen: from man cupsd.conf PreserveJobFiles Yes PreserveJobFiles No PreserveJobFiles seconds Specifies whether job files (documents) are preserved after a job is printed. If a numeric value is specified, job files are preserved for the indicated number of seconds after printing. The default is "86400" (preserve 1 day). PreserveJobHistory Yes PreserveJobHistory No PreserveJobHistory seconds Specifies whether the job history is preserved after a job is printed. If a numeric value is specified, the job history is preserved for the indicated number of seconds after printing. If "Yes", the job history is preserved until the MaxJobs limit is reached. The default is "Yes". 4) What happens instead If I put the following directives in cupsd.conf the job files and history are deleted immediately. PreserveJobFiles 604800 PreserveJobHistory 604800 Debug log showing history being purged: d [06/Feb/2018:15:11:59 -0600] cupsdCheckJobs: 0 active jobs, sleeping=0, ac-power=-1, reload=0, curtime=1517951519 d [06/Feb/2018:15:11:59 -0600] cupsdCleanJobs: MaxJobs=100, JobHistory=604800, JobFiles=604800 D [06/Feb/2018:15:11:59 -0600] [Job 106] Removing from history. D [06/Feb/2018:15:11:59 -0600] [Job 106] Unloading... -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1747765 Title: PreserveJobHistory and PreserveJobLog do not respect numeric input as outlined in the docs Status in cups package in Ubuntu: Fix Released Status in cups source package in Xenial: Fix Committed Status in cups source package in Bionic: Fix Committed Status in cups source package in Cosmic: Fix Committed Status in cups source package in Disco: Fix Committed Bug description: [Impact] The documentation allows the following types of arguments for the PreserveJobHistory parameter: PreserveJobHistory Yes PreserveJobHistory No PreserveJobHistory seconds The value in seconds is treated in the same as 'No' resulting in immediate removing of jobs from history, while it is supposed to save it for . [Test Case] 1. Set PreserveJobHistory to 30. Set LogLevel to debug. 2. Schedule a job for printing. 3. Check the error_log. 4. Set PreserveJobHistory to No. Repeat 2-3. 5. Set PreserveJobHistory to Yes. Repeat 2-3. Expected result (for PreserveJobHistory values): 30: Job is save for at least 30 seconds. No: Job is removed right after processing. Yes: Job is never removed. Actual results (for PreserveJobHistory values): 30: Job is immediately removed from history. No: Job is removed right after processing. Yes: Job is never removed. [Regression Potential] * With the fix the jobs will be saved longer than before, so in tight conditions (low disk space) and heavy workload it may affect memory/disk spac
[Desktop-packages] [Bug 1747765] Re: PreserveJobHistory and PreserveJobLog do not respect numeric input as outlined in the docs
Verified for cosmic: apt-cache policy cups-daemon cups-daemon: Installed: 2.2.8-5ubuntu1.4 lp -d PDF /usr/share/cups/data/default.pdf PreserveJobHistory 30: I [04/Jun/2019:09:12:13 +] [Job 1] Job completed. D [04/Jun/2019:09:12:44 +] [Job 1] Removing from history. PreserveJobHistory No: I [04/Jun/2019:09:13:03 +] [Job 2] Job completed. D [04/Jun/2019:09:13:03 +] [Job 2] Removing from history. PreserveJobHistory Yes: I [04/Jun/2019:09:13:30 +] [Job 3] Job completed. ** Tags removed: verification-needed-cosmic ** Tags added: verification-done-cosmic -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1747765 Title: PreserveJobHistory and PreserveJobLog do not respect numeric input as outlined in the docs Status in cups package in Ubuntu: Fix Released Status in cups source package in Xenial: Fix Committed Status in cups source package in Bionic: Fix Committed Status in cups source package in Cosmic: Fix Committed Status in cups source package in Disco: Fix Committed Bug description: [Impact] The documentation allows the following types of arguments for the PreserveJobHistory parameter: PreserveJobHistory Yes PreserveJobHistory No PreserveJobHistory seconds The value in seconds is treated in the same as 'No' resulting in immediate removing of jobs from history, while it is supposed to save it for . [Test Case] 1. Set PreserveJobHistory to 30. Set LogLevel to debug. 2. Schedule a job for printing. 3. Check the error_log. 4. Set PreserveJobHistory to Yes. Repeat 2-3. 5. Set PreserveJobHistory to No. Repeat 2-3. Expected result (for PreserveJobHistory values): 30: Job is save for at least 30 seconds. Yes: Job is never removed. No: Job is removed right after processing. Actual results (for PreserveJobHistory values): 30: Job is immediately removed from history. Yes: Job is never removed. No: Job is removed right after processing. [Regression Potential] * With the fix the jobs will be saved longer than before, so in tight conditions (low disk space) and heavy workload it may affect memory/disk space consumption and lead to running out of free space in worst case. [Other Info] * Original bug description: 1) Ubuntu Release Description: Ubuntu 16.04.3 LTS Release: 16.04 2) Version of the package cups: Installed: 2.1.3-4ubuntu0.3 Candidate: 2.1.3-4ubuntu0.3 Version table: *** 2.1.3-4ubuntu0.3 500 500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 3) What I expected to happen: from man cupsd.conf PreserveJobFiles Yes PreserveJobFiles No PreserveJobFiles seconds Specifies whether job files (documents) are preserved after a job is printed. If a numeric value is specified, job files are preserved for the indicated number of seconds after printing. The default is "86400" (preserve 1 day). PreserveJobHistory Yes PreserveJobHistory No PreserveJobHistory seconds Specifies whether the job history is preserved after a job is printed. If a numeric value is specified, the job history is preserved for the indicated number of seconds after printing. If "Yes", the job history is preserved until the MaxJobs limit is reached. The default is "Yes". 4) What happens instead If I put the following directives in cupsd.conf the job files and history are deleted immediately. PreserveJobFiles 604800 PreserveJobHistory 604800 Debug log showing history being purged: d [06/Feb/2018:15:11:59 -0600] cupsdCheckJobs: 0 active jobs, sleeping=0, ac-power=-1, reload=0, curtime=1517951519 d [06/Feb/2018:15:11:59 -0600] cupsdCleanJobs: MaxJobs=100, JobHistory=604800, JobFiles=604800 D [06/Feb/2018:15:11:59 -0600] [Job 106] Removing from history. D [06/Feb/2018:15:11:59 -0600] [Job 106] Unloading... To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1747765/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1747765] Re: PreserveJobHistory and PreserveJobLog do not respect numeric input as outlined in the docs
Verified for disco: apt-cache policy cups-daemon cups-daemon: Installed: 2.2.10-4ubuntu2 lp -d PDF /usr/share/cups/data/default.pdf PreserveJobHistory 30: I [04/Jun/2019:09:03:14 +] [Job 1] Job completed. D [04/Jun/2019:09:03:45 +] [Job 2] Removing from history. PreserveJobHistory No: I [04/Jun/2019:09:04:06 +] [Job 2] Job completed. D [04/Jun/2019:09:04:06 +] [Job 2] Removing from history. PreserveJobHistory Yes: I [04/Jun/2019:09:04:50 +] [Job 3] Job completed. ** Tags removed: verification-needed-disco ** Tags added: verification-done-disco -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1747765 Title: PreserveJobHistory and PreserveJobLog do not respect numeric input as outlined in the docs Status in cups package in Ubuntu: Fix Released Status in cups source package in Xenial: Fix Committed Status in cups source package in Bionic: Fix Committed Status in cups source package in Cosmic: Fix Committed Status in cups source package in Disco: Fix Committed Bug description: [Impact] The documentation allows the following types of arguments for the PreserveJobHistory parameter: PreserveJobHistory Yes PreserveJobHistory No PreserveJobHistory seconds The value in seconds is treated in the same as 'No' resulting in immediate removing of jobs from history, while it is supposed to save it for . [Test Case] 1. Set PreserveJobHistory to 30. Set LogLevel to debug. 2. Schedule a job for printing. 3. Check the error_log. 4. Set PreserveJobHistory to Yes. Repeat 2-3. 5. Set PreserveJobHistory to No. Repeat 2-3. Expected result (for PreserveJobHistory values): 30: Job is save for at least 30 seconds. Yes: Job is never removed. No: Job is removed right after processing. Actual results (for PreserveJobHistory values): 30: Job is immediately removed from history. Yes: Job is never removed. No: Job is removed right after processing. [Regression Potential] * With the fix the jobs will be saved longer than before, so in tight conditions (low disk space) and heavy workload it may affect memory/disk space consumption and lead to running out of free space in worst case. [Other Info] * Original bug description: 1) Ubuntu Release Description: Ubuntu 16.04.3 LTS Release: 16.04 2) Version of the package cups: Installed: 2.1.3-4ubuntu0.3 Candidate: 2.1.3-4ubuntu0.3 Version table: *** 2.1.3-4ubuntu0.3 500 500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 3) What I expected to happen: from man cupsd.conf PreserveJobFiles Yes PreserveJobFiles No PreserveJobFiles seconds Specifies whether job files (documents) are preserved after a job is printed. If a numeric value is specified, job files are preserved for the indicated number of seconds after printing. The default is "86400" (preserve 1 day). PreserveJobHistory Yes PreserveJobHistory No PreserveJobHistory seconds Specifies whether the job history is preserved after a job is printed. If a numeric value is specified, the job history is preserved for the indicated number of seconds after printing. If "Yes", the job history is preserved until the MaxJobs limit is reached. The default is "Yes". 4) What happens instead If I put the following directives in cupsd.conf the job files and history are deleted immediately. PreserveJobFiles 604800 PreserveJobHistory 604800 Debug log showing history being purged: d [06/Feb/2018:15:11:59 -0600] cupsdCheckJobs: 0 active jobs, sleeping=0, ac-power=-1, reload=0, curtime=1517951519 d [06/Feb/2018:15:11:59 -0600] cupsdCleanJobs: MaxJobs=100, JobHistory=604800, JobFiles=604800 D [06/Feb/2018:15:11:59 -0600] [Job 106] Removing from history. D [06/Feb/2018:15:11:59 -0600] [Job 106] Unloading... To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1747765/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1747765] Re: PreserveJobHistory and PreserveJobLog do not respect numeric input as outlined in the docs
Verified for bionic. apt-cache policy cups-daemon cups-daemon: Installed: 2.2.7-1ubuntu2.6 lp -d PDF /usr/share/cups/data/default.pdf PreserveJobHistory 30: I [04/Jun/2019:08:52:25 +] [Job 1] Job completed D [04/Jun/2019:08:52:56 +] [Job 1] Removing from history. PreserveJobHistory No: I [04/Jun/2019:08:53:58 +] [Job 2] Job completed. D [04/Jun/2019:08:53:58 +] [Job 2] Removing from history. PreserveJobHistory Yes: I [04/Jun/2019:08:54:55 +] [Job 5] Job completed. (...) ** Description changed: [Impact] - The documentation allows the following types of arguments for the PreserveJobHistory parameter: + The documentation allows the following types of arguments for the PreserveJobHistory parameter: PreserveJobHistory Yes PreserveJobHistory No PreserveJobHistory seconds - - The value in seconds is treated in the same as 'No' resulting in immediate removing of jobs from history, while it is supposed to save it for . + + The value in seconds is treated in the same as 'No' resulting in + immediate removing of jobs from history, while it is supposed to save it + for . [Test Case] - * Set PreserveJobHistory to 300. - * Schedule a job for printing. - * Check the error_log. + 1. Set PreserveJobHistory to 300. + 2. Schedule a job for printing. + 3. Check the error_log. + 4. Set PreserveJobHistory to Yes. Repeat 2-3. + 5. Set PreserveJobHistory to No. Repeat 2-3. + - Expected result: - Job is save for at least 300 seconds. + Expected result (for PreserveJobHistory values): + 300: Job is save for at least 300 seconds. + Yes: Job is never removed. + No: Job is removed right after processing. - Actual results: - Job is immediately removed from history. + + Actual results (for PreserveJobHistory values): + 300: Job is immediately removed from history. + Yes: Job is never removed. + No: Job is removed right after processing. [Regression Potential] - * With the fix the jobs will be saved longer than before, so in tight + * With the fix the jobs will be saved longer than before, so in tight conditions (low disk space) and heavy workload it may affect memory/disk space consumption and lead to running out of free space in worst case. [Other Info] - - * Original bug description: + + * Original bug description: 1) Ubuntu Release Description: Ubuntu 16.04.3 LTS Release: 16.04 2) Version of the package cups: Installed: 2.1.3-4ubuntu0.3 Candidate: 2.1.3-4ubuntu0.3 Version table: *** 2.1.3-4ubuntu0.3 500 500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 3) What I expected to happen: from man cupsd.conf PreserveJobFiles Yes PreserveJobFiles No PreserveJobFiles seconds Specifies whether job files (documents) are preserved after a job is printed. If a numeric value is specified, job files are preserved for the indicated number of seconds after printing. The default is "86400" (preserve 1 day). PreserveJobHistory Yes PreserveJobHistory No PreserveJobHistory seconds Specifies whether the job history is preserved after a job is printed. If a numeric value is specified, the job history is preserved for the indicated number of seconds after printing. If "Yes", the job history is preserved until the MaxJobs limit is reached. The default is "Yes". 4) What happens instead If I put the following directives in cupsd.conf the job files and history are deleted immediately. PreserveJobFiles 604800 PreserveJobHistory 604800 Debug log showing history being purged: d [06/Feb/2018:15:11:59 -0600] cupsdCheckJobs: 0 active jobs, sleeping=0, ac-power=-1, reload=0, curtime=1517951519 d [06/Feb/2018:15:11:59 -0600] cupsdCleanJobs: MaxJobs=100, JobHistory=604800, JobFiles=604800 D [06/Feb/2018:15:11:59 -0600] [Job 106] Removing from history. D [06/Feb/2018:15:11:59 -0600] [Job 106] Unloading... ** Description changed: [Impact] The documentation allows the following types of arguments for the PreserveJobHistory parameter: PreserveJobHistory Yes PreserveJobHistory No PreserveJobHistory seconds The value in seconds is treated in the same as 'No' resulting in immediate removing of jobs from history, while it is supposed to save it for . [Test Case] - 1. Set PreserveJobHistory to 300. + 1. Set PreserveJobHistory to 30. 2. Schedule a job for printing. 3. Check the error_log. - 4. Set PreserveJobHistory to Yes. Repeat 2-3. - 5. Set PreserveJobHistory to No. Repeat 2-3. - + 4. Set PreserveJobHistory to Yes. Repeat 2-3. + 5. Set PreserveJobHistory to No. Repeat 2-3. Expected result (for PreserveJobHistory values): - 300: Job is save for at least 300 seconds. + 300: Job is save for at least 30 seconds. Yes: Job is never removed. No: Job is
[Desktop-packages] [Bug 1831021] Re: Extremely high memory consumption under heavy workload
Thank you for the explanation Till. I believe the lack of previous complaints is because this happens in a pretty unique conditions (very high MaxJobs and large batches of jobs). The test case however was based on a real-life scenario reported to me. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1831021 Title: Extremely high memory consumption under heavy workload Status in cups package in Ubuntu: Triaged Bug description: Under heavy workload conditions cups can reach irrationally high memory consumption very quickly (tens of GBs). Test case: 1. Set MaxJobs to 4 in cupsd.conf. 2. sudo apt install cups-pdf 3. Fill the queue with jobs: while [ 1 ]; lp -d PDF /usr/share/cups/data/default.pdf; done 4. Cancel all jobs cancel -a PDF 5. Restart cups. 6. Start filling the queue again (as in step 3). Expected result: Jobs are processed and memory consumption is proportional to the number of jobs. Actual result: After step 5 or at latest step 6 memory consumption starts to increase exponentially - from ~150-200 MB to 8+GB. Without foreseeing this it's very easy to get cupsd killed by OOM killer. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1831021/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1831021] Re: Extremely high memory consumption under heavy workload
In a recent test with MaxJobs of 4 I was easily able to reach over 65 GB of memory consumption within 60 mins, while with LogDebugHistory set to 0 the consumption was below 400 MB. My recommendation is to lower the default LogDebugHistory value back to what is upstream: 200. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1831021 Title: Extremely high memory consumption under heavy workload Status in cups package in Ubuntu: Confirmed Bug description: Under heavy workload conditions cups can reach irrationally high memory consumption very quickly (tens of GBs). Test case: 1. Set MaxJobs to 4 in cupsd.conf. 2. sudo apt install cups-pdf 3. Fill the queue with jobs: while [ 1 ]; lp -d PDF /usr/share/cups/data/default.pdf; done 4. Cancel all jobs cancel -a PDF 5. Restart cups. 6. Start filling the queue again (as in step 3). Expected result: Jobs are processed and memory consumption is proportional to the number of jobs. Actual result: After step 5 or at latest step 6 memory consumption starts to increase exponentially - from ~150-200 MB to 8+GB. Without foreseeing this it's very easy to get cupsd killed by OOM killer. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1831021/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1831021] Re: Extremely high memory consumption under heavy workload
** Tags added: rls-ee-incoming -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1831021 Title: Extremely high memory consumption under heavy workload Status in cups package in Ubuntu: Confirmed Bug description: Under heavy workload conditions cups can reach irrationally high memory consumption very quickly (tens of GBs). Test case: 1. Set MaxJobs to 4 in cupsd.conf. 2. sudo apt install cups-pdf 3. Fill the queue with jobs: while [ 1 ]; lp -d PDF /usr/share/cups/data/default.pdf; done 4. Cancel all jobs cancel -a PDF 5. Restart cups. 6. Start filling the queue again (as in step 3). Expected result: Jobs are processed and memory consumption is proportional to the number of jobs. Actual result: After step 5 or at latest step 6 memory consumption starts to increase exponentially - from ~150-200 MB to 8+GB. Without foreseeing this it's very easy to get cupsd killed by OOM killer. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1831021/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1747765] Re: PreserveJobHistory and PreserveJobLog do not respect numeric input as outlined in the docs
Thanks Till. I've fixed cosmic debdiff, sorry about the mistake.
** Patch removed: "cosmic_cups_2.2.8-5ubuntu1.4.debdiff"
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1747765/+attachment/5267676/+files/cosmic_cups_2.2.8-5ubuntu1.4.debdiff
** Patch added: "cosmic_cups_2.2.8-5ubuntu1.4.debdiff"
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1747765/+attachment/5267712/+files/cosmic_cups_2.2.8-5ubuntu1.4.debdiff
** Changed in: cups (Ubuntu Xenial)
Assignee: Dariusz Gadomski (dgadomski) => (unassigned)
** Changed in: cups (Ubuntu Cosmic)
Importance: Undecided => Medium
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to cups in Ubuntu.
https://bugs.launchpad.net/bugs/1747765
Title:
PreserveJobHistory and PreserveJobLog do not respect numeric input as
outlined in the docs
Status in cups package in Ubuntu:
Fix Released
Status in cups source package in Xenial:
New
Status in cups source package in Bionic:
New
Status in cups source package in Cosmic:
New
Status in cups source package in Disco:
New
Bug description:
[Impact]
The documentation allows the following types of arguments for the
PreserveJobHistory parameter:
PreserveJobHistory Yes
PreserveJobHistory No
PreserveJobHistory seconds
The value in seconds is treated in the same as 'No' resulting in immediate
removing of jobs from history, while it is supposed to save it for .
[Test Case]
* Set PreserveJobHistory to 300.
* Schedule a job for printing.
* Check the error_log.
Expected result:
Job is save for at least 300 seconds.
Actual results:
Job is immediately removed from history.
[Regression Potential]
* With the fix the jobs will be saved longer than before, so in tight
conditions (low disk space) and heavy workload it may affect
memory/disk space consumption and lead to running out of free space in
worst case.
[Other Info]
* Original bug description:
1) Ubuntu Release
Description: Ubuntu 16.04.3 LTS
Release: 16.04
2) Version of the package
cups:
Installed: 2.1.3-4ubuntu0.3
Candidate: 2.1.3-4ubuntu0.3
Version table:
*** 2.1.3-4ubuntu0.3 500
500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64
Packages
3) What I expected to happen:
from man cupsd.conf
PreserveJobFiles Yes
PreserveJobFiles No
PreserveJobFiles seconds
Specifies whether job files (documents) are preserved after a
job is printed. If a numeric value is specified, job files are preserved
for the indicated number of seconds after printing. The default
is "86400" (preserve 1 day).
PreserveJobHistory Yes
PreserveJobHistory No
PreserveJobHistory seconds
Specifies whether the job history is preserved after a job is
printed. If a numeric value is specified, the job history is preserved for
the indicated number of seconds after printing. If "Yes", the
job history is preserved until the MaxJobs limit is reached. The default
is "Yes".
4) What happens instead
If I put the following directives in cupsd.conf the job files and
history are deleted immediately.
PreserveJobFiles 604800
PreserveJobHistory 604800
Debug log showing history being purged:
d [06/Feb/2018:15:11:59 -0600] cupsdCheckJobs: 0 active jobs, sleeping=0,
ac-power=-1, reload=0, curtime=1517951519
d [06/Feb/2018:15:11:59 -0600] cupsdCleanJobs: MaxJobs=100,
JobHistory=604800, JobFiles=604800
D [06/Feb/2018:15:11:59 -0600] [Job 106] Removing from history.
D [06/Feb/2018:15:11:59 -0600] [Job 106] Unloading...
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1747765/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1747765] Re: PreserveJobHistory and PreserveJobLog do not respect numeric input as outlined in the docs
SRU proposal for Cosmic. ** Patch added: "cosmic_cups_2.2.8-5ubuntu1.4.debdiff" https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1747765/+attachment/5267676/+files/cosmic_cups_2.2.8-5ubuntu1.4.debdiff -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1747765 Title: PreserveJobHistory and PreserveJobLog do not respect numeric input as outlined in the docs Status in cups package in Ubuntu: Fix Released Status in cups source package in Xenial: New Status in cups source package in Bionic: New Status in cups source package in Cosmic: New Status in cups source package in Disco: New Bug description: [Impact] The documentation allows the following types of arguments for the PreserveJobHistory parameter: PreserveJobHistory Yes PreserveJobHistory No PreserveJobHistory seconds The value in seconds is treated in the same as 'No' resulting in immediate removing of jobs from history, while it is supposed to save it for . [Test Case] * Set PreserveJobHistory to 300. * Schedule a job for printing. * Check the error_log. Expected result: Job is save for at least 300 seconds. Actual results: Job is immediately removed from history. [Regression Potential] * With the fix the jobs will be saved longer than before, so in tight conditions (low disk space) and heavy workload it may affect memory/disk space consumption and lead to running out of free space in worst case. [Other Info] * Original bug description: 1) Ubuntu Release Description: Ubuntu 16.04.3 LTS Release: 16.04 2) Version of the package cups: Installed: 2.1.3-4ubuntu0.3 Candidate: 2.1.3-4ubuntu0.3 Version table: *** 2.1.3-4ubuntu0.3 500 500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 3) What I expected to happen: from man cupsd.conf PreserveJobFiles Yes PreserveJobFiles No PreserveJobFiles seconds Specifies whether job files (documents) are preserved after a job is printed. If a numeric value is specified, job files are preserved for the indicated number of seconds after printing. The default is "86400" (preserve 1 day). PreserveJobHistory Yes PreserveJobHistory No PreserveJobHistory seconds Specifies whether the job history is preserved after a job is printed. If a numeric value is specified, the job history is preserved for the indicated number of seconds after printing. If "Yes", the job history is preserved until the MaxJobs limit is reached. The default is "Yes". 4) What happens instead If I put the following directives in cupsd.conf the job files and history are deleted immediately. PreserveJobFiles 604800 PreserveJobHistory 604800 Debug log showing history being purged: d [06/Feb/2018:15:11:59 -0600] cupsdCheckJobs: 0 active jobs, sleeping=0, ac-power=-1, reload=0, curtime=1517951519 d [06/Feb/2018:15:11:59 -0600] cupsdCleanJobs: MaxJobs=100, JobHistory=604800, JobFiles=604800 D [06/Feb/2018:15:11:59 -0600] [Job 106] Removing from history. D [06/Feb/2018:15:11:59 -0600] [Job 106] Unloading... To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1747765/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1747765] Re: PreserveJobHistory and PreserveJobLog do not respect numeric input as outlined in the docs
** Also affects: cups (Ubuntu Cosmic) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1747765 Title: PreserveJobHistory and PreserveJobLog do not respect numeric input as outlined in the docs Status in cups package in Ubuntu: Fix Released Status in cups source package in Xenial: New Status in cups source package in Bionic: New Status in cups source package in Cosmic: New Status in cups source package in Disco: New Bug description: [Impact] The documentation allows the following types of arguments for the PreserveJobHistory parameter: PreserveJobHistory Yes PreserveJobHistory No PreserveJobHistory seconds The value in seconds is treated in the same as 'No' resulting in immediate removing of jobs from history, while it is supposed to save it for . [Test Case] * Set PreserveJobHistory to 300. * Schedule a job for printing. * Check the error_log. Expected result: Job is save for at least 300 seconds. Actual results: Job is immediately removed from history. [Regression Potential] * With the fix the jobs will be saved longer than before, so in tight conditions (low disk space) and heavy workload it may affect memory/disk space consumption and lead to running out of free space in worst case. [Other Info] * Original bug description: 1) Ubuntu Release Description: Ubuntu 16.04.3 LTS Release: 16.04 2) Version of the package cups: Installed: 2.1.3-4ubuntu0.3 Candidate: 2.1.3-4ubuntu0.3 Version table: *** 2.1.3-4ubuntu0.3 500 500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 3) What I expected to happen: from man cupsd.conf PreserveJobFiles Yes PreserveJobFiles No PreserveJobFiles seconds Specifies whether job files (documents) are preserved after a job is printed. If a numeric value is specified, job files are preserved for the indicated number of seconds after printing. The default is "86400" (preserve 1 day). PreserveJobHistory Yes PreserveJobHistory No PreserveJobHistory seconds Specifies whether the job history is preserved after a job is printed. If a numeric value is specified, the job history is preserved for the indicated number of seconds after printing. If "Yes", the job history is preserved until the MaxJobs limit is reached. The default is "Yes". 4) What happens instead If I put the following directives in cupsd.conf the job files and history are deleted immediately. PreserveJobFiles 604800 PreserveJobHistory 604800 Debug log showing history being purged: d [06/Feb/2018:15:11:59 -0600] cupsdCheckJobs: 0 active jobs, sleeping=0, ac-power=-1, reload=0, curtime=1517951519 d [06/Feb/2018:15:11:59 -0600] cupsdCleanJobs: MaxJobs=100, JobHistory=604800, JobFiles=604800 D [06/Feb/2018:15:11:59 -0600] [Job 106] Removing from history. D [06/Feb/2018:15:11:59 -0600] [Job 106] Unloading... To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1747765/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1747765] Re: PreserveJobHistory and PreserveJobLog do not respect numeric input as outlined in the docs
SRU proposal for Xenial. ** Patch added: "xenial_cups_2.1.3-4ubuntu0.9.debdiff" https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1747765/+attachment/5267662/+files/xenial_cups_2.1.3-4ubuntu0.9.debdiff -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1747765 Title: PreserveJobHistory and PreserveJobLog do not respect numeric input as outlined in the docs Status in cups package in Ubuntu: Fix Released Status in cups source package in Xenial: New Status in cups source package in Bionic: New Status in cups source package in Disco: New Bug description: [Impact] The documentation allows the following types of arguments for the PreserveJobHistory parameter: PreserveJobHistory Yes PreserveJobHistory No PreserveJobHistory seconds The value in seconds is treated in the same as 'No' resulting in immediate removing of jobs from history, while it is supposed to save it for . [Test Case] * Set PreserveJobHistory to 300. * Schedule a job for printing. * Check the error_log. Expected result: Job is save for at least 300 seconds. Actual results: Job is immediately removed from history. [Regression Potential] * With the fix the jobs will be saved longer than before, so in tight conditions (low disk space) and heavy workload it may affect memory/disk space consumption and lead to running out of free space in worst case. [Other Info] * Original bug description: 1) Ubuntu Release Description: Ubuntu 16.04.3 LTS Release: 16.04 2) Version of the package cups: Installed: 2.1.3-4ubuntu0.3 Candidate: 2.1.3-4ubuntu0.3 Version table: *** 2.1.3-4ubuntu0.3 500 500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 3) What I expected to happen: from man cupsd.conf PreserveJobFiles Yes PreserveJobFiles No PreserveJobFiles seconds Specifies whether job files (documents) are preserved after a job is printed. If a numeric value is specified, job files are preserved for the indicated number of seconds after printing. The default is "86400" (preserve 1 day). PreserveJobHistory Yes PreserveJobHistory No PreserveJobHistory seconds Specifies whether the job history is preserved after a job is printed. If a numeric value is specified, the job history is preserved for the indicated number of seconds after printing. If "Yes", the job history is preserved until the MaxJobs limit is reached. The default is "Yes". 4) What happens instead If I put the following directives in cupsd.conf the job files and history are deleted immediately. PreserveJobFiles 604800 PreserveJobHistory 604800 Debug log showing history being purged: d [06/Feb/2018:15:11:59 -0600] cupsdCheckJobs: 0 active jobs, sleeping=0, ac-power=-1, reload=0, curtime=1517951519 d [06/Feb/2018:15:11:59 -0600] cupsdCleanJobs: MaxJobs=100, JobHistory=604800, JobFiles=604800 D [06/Feb/2018:15:11:59 -0600] [Job 106] Removing from history. D [06/Feb/2018:15:11:59 -0600] [Job 106] Unloading... To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1747765/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1830022] Re: DirtyCleanInterval should be 0 by default
Discussion upstream: https://lists.cups.org/pipermail/cups/2019-May/074657.html ** Tags added: rls-ee-incoming -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1830022 Title: DirtyCleanInterval should be 0 by default Status in cups package in Ubuntu: Confirmed Bug description: Please consider changing DirtyCleanInterval value to 0 as default. Otherwise if cupsd crashes due to (e.g. OOM killer) under a heavy workload even hundreds of jobs may be lost. This concern is backed up by a real-life scenario and leaves the client sending thousands of jobs unaware that many of them are lost during a crash. After cupsd gets restarted it rewinds it's job counter to the last cached and continues unaware about the jobs accepted and lost. Having DirtyCleanInterval set to 0 will cause some performance impact, but not significant under lighter workloads and a completely justified price for reliability under heavy workloads. Test scenario: 1. sudo apt install printer-driver-cups-pdf 2. while [ 1 ]; do lp -d PDF somepdf.pdf; done; 3. # on other terminal kill -9 $(pidof cupsd) 4. Note last job number and wait for cupsd to be restarted by systemd. 5. Once accepting jobs is resumend the job counter is rewound. Expected behavior: Accepted jobs are queued for processing. Actual behavior: Some accepted jobs are lost. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1830022/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1747765] Re: PreserveJobHistory and PreserveJobLog do not respect numeric input as outlined in the docs
@sponsors: Eoan already has the fix from Debian. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1747765 Title: PreserveJobHistory and PreserveJobLog do not respect numeric input as outlined in the docs Status in cups package in Ubuntu: Fix Released Status in cups source package in Xenial: New Status in cups source package in Bionic: New Status in cups source package in Disco: New Bug description: [Impact] The documentation allows the following types of arguments for the PreserveJobHistory parameter: PreserveJobHistory Yes PreserveJobHistory No PreserveJobHistory seconds The value in seconds is treated in the same as 'No' resulting in immediate removing of jobs from history, while it is supposed to save it for . [Test Case] * Set PreserveJobHistory to 300. * Schedule a job for printing. * Check the error_log. Expected result: Job is save for at least 300 seconds. Actual results: Job is immediately removed from history. [Regression Potential] * With the fix the jobs will be saved longer than before, so in tight conditions (low disk space) and heavy workload it may affect memory/disk space consumption and lead to running out of free space in worst case. [Other Info] * Original bug description: 1) Ubuntu Release Description: Ubuntu 16.04.3 LTS Release: 16.04 2) Version of the package cups: Installed: 2.1.3-4ubuntu0.3 Candidate: 2.1.3-4ubuntu0.3 Version table: *** 2.1.3-4ubuntu0.3 500 500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 3) What I expected to happen: from man cupsd.conf PreserveJobFiles Yes PreserveJobFiles No PreserveJobFiles seconds Specifies whether job files (documents) are preserved after a job is printed. If a numeric value is specified, job files are preserved for the indicated number of seconds after printing. The default is "86400" (preserve 1 day). PreserveJobHistory Yes PreserveJobHistory No PreserveJobHistory seconds Specifies whether the job history is preserved after a job is printed. If a numeric value is specified, the job history is preserved for the indicated number of seconds after printing. If "Yes", the job history is preserved until the MaxJobs limit is reached. The default is "Yes". 4) What happens instead If I put the following directives in cupsd.conf the job files and history are deleted immediately. PreserveJobFiles 604800 PreserveJobHistory 604800 Debug log showing history being purged: d [06/Feb/2018:15:11:59 -0600] cupsdCheckJobs: 0 active jobs, sleeping=0, ac-power=-1, reload=0, curtime=1517951519 d [06/Feb/2018:15:11:59 -0600] cupsdCleanJobs: MaxJobs=100, JobHistory=604800, JobFiles=604800 D [06/Feb/2018:15:11:59 -0600] [Job 106] Removing from history. D [06/Feb/2018:15:11:59 -0600] [Job 106] Unloading... To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1747765/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1747765] Re: PreserveJobHistory and PreserveJobLog do not respect numeric input as outlined in the docs
SRU proposal for Disco ** Patch added: "disco_cups_2.2.10-4ubuntu2.debdiff" https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1747765/+attachment/5267599/+files/disco_cups_2.2.10-4ubuntu2.debdiff -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1747765 Title: PreserveJobHistory and PreserveJobLog do not respect numeric input as outlined in the docs Status in cups package in Ubuntu: Fix Released Status in cups source package in Xenial: New Status in cups source package in Bionic: New Status in cups source package in Disco: New Bug description: [Impact] The documentation allows the following types of arguments for the PreserveJobHistory parameter: PreserveJobHistory Yes PreserveJobHistory No PreserveJobHistory seconds The value in seconds is treated in the same as 'No' resulting in immediate removing of jobs from history, while it is supposed to save it for . [Test Case] * Set PreserveJobHistory to 300. * Schedule a job for printing. * Check the error_log. Expected result: Job is save for at least 300 seconds. Actual results: Job is immediately removed from history. [Regression Potential] * With the fix the jobs will be saved longer than before, so in tight conditions (low disk space) and heavy workload it may affect memory/disk space consumption and lead to running out of free space in worst case. [Other Info] * Original bug description: 1) Ubuntu Release Description: Ubuntu 16.04.3 LTS Release: 16.04 2) Version of the package cups: Installed: 2.1.3-4ubuntu0.3 Candidate: 2.1.3-4ubuntu0.3 Version table: *** 2.1.3-4ubuntu0.3 500 500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 3) What I expected to happen: from man cupsd.conf PreserveJobFiles Yes PreserveJobFiles No PreserveJobFiles seconds Specifies whether job files (documents) are preserved after a job is printed. If a numeric value is specified, job files are preserved for the indicated number of seconds after printing. The default is "86400" (preserve 1 day). PreserveJobHistory Yes PreserveJobHistory No PreserveJobHistory seconds Specifies whether the job history is preserved after a job is printed. If a numeric value is specified, the job history is preserved for the indicated number of seconds after printing. If "Yes", the job history is preserved until the MaxJobs limit is reached. The default is "Yes". 4) What happens instead If I put the following directives in cupsd.conf the job files and history are deleted immediately. PreserveJobFiles 604800 PreserveJobHistory 604800 Debug log showing history being purged: d [06/Feb/2018:15:11:59 -0600] cupsdCheckJobs: 0 active jobs, sleeping=0, ac-power=-1, reload=0, curtime=1517951519 d [06/Feb/2018:15:11:59 -0600] cupsdCleanJobs: MaxJobs=100, JobHistory=604800, JobFiles=604800 D [06/Feb/2018:15:11:59 -0600] [Job 106] Removing from history. D [06/Feb/2018:15:11:59 -0600] [Job 106] Unloading... To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1747765/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1747765] Re: PreserveJobHistory and PreserveJobLog do not respect numeric input as outlined in the docs
The patch doesn't apply cleanly to Xenial, working on backport. ** Changed in: cups (Ubuntu Xenial) Assignee: (unassigned) => Dariusz Gadomski (dgadomski) ** Changed in: cups (Ubuntu Xenial) Importance: Undecided => Medium ** Changed in: cups (Ubuntu Bionic) Importance: Undecided => Medium ** Changed in: cups (Ubuntu Disco) Importance: Undecided => Medium -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1747765 Title: PreserveJobHistory and PreserveJobLog do not respect numeric input as outlined in the docs Status in cups package in Ubuntu: Fix Released Status in cups source package in Xenial: New Status in cups source package in Bionic: New Status in cups source package in Disco: New Bug description: [Impact] The documentation allows the following types of arguments for the PreserveJobHistory parameter: PreserveJobHistory Yes PreserveJobHistory No PreserveJobHistory seconds The value in seconds is treated in the same as 'No' resulting in immediate removing of jobs from history, while it is supposed to save it for . [Test Case] * Set PreserveJobHistory to 300. * Schedule a job for printing. * Check the error_log. Expected result: Job is save for at least 300 seconds. Actual results: Job is immediately removed from history. [Regression Potential] * With the fix the jobs will be saved longer than before, so in tight conditions (low disk space) and heavy workload it may affect memory/disk space consumption and lead to running out of free space in worst case. [Other Info] * Original bug description: 1) Ubuntu Release Description: Ubuntu 16.04.3 LTS Release: 16.04 2) Version of the package cups: Installed: 2.1.3-4ubuntu0.3 Candidate: 2.1.3-4ubuntu0.3 Version table: *** 2.1.3-4ubuntu0.3 500 500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 3) What I expected to happen: from man cupsd.conf PreserveJobFiles Yes PreserveJobFiles No PreserveJobFiles seconds Specifies whether job files (documents) are preserved after a job is printed. If a numeric value is specified, job files are preserved for the indicated number of seconds after printing. The default is "86400" (preserve 1 day). PreserveJobHistory Yes PreserveJobHistory No PreserveJobHistory seconds Specifies whether the job history is preserved after a job is printed. If a numeric value is specified, the job history is preserved for the indicated number of seconds after printing. If "Yes", the job history is preserved until the MaxJobs limit is reached. The default is "Yes". 4) What happens instead If I put the following directives in cupsd.conf the job files and history are deleted immediately. PreserveJobFiles 604800 PreserveJobHistory 604800 Debug log showing history being purged: d [06/Feb/2018:15:11:59 -0600] cupsdCheckJobs: 0 active jobs, sleeping=0, ac-power=-1, reload=0, curtime=1517951519 d [06/Feb/2018:15:11:59 -0600] cupsdCleanJobs: MaxJobs=100, JobHistory=604800, JobFiles=604800 D [06/Feb/2018:15:11:59 -0600] [Job 106] Removing from history. D [06/Feb/2018:15:11:59 -0600] [Job 106] Unloading... To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1747765/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1747765] Re: PreserveJobHistory and PreserveJobLog do not respect numeric input as outlined in the docs
SRU proposal for Bionic ** Patch added: "bionic_cups_2.2.7-1ubuntu2.6.debdiff" https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1747765/+attachment/5267600/+files/bionic_cups_2.2.7-1ubuntu2.6.debdiff -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1747765 Title: PreserveJobHistory and PreserveJobLog do not respect numeric input as outlined in the docs Status in cups package in Ubuntu: Fix Released Status in cups source package in Xenial: New Status in cups source package in Bionic: New Status in cups source package in Disco: New Bug description: [Impact] The documentation allows the following types of arguments for the PreserveJobHistory parameter: PreserveJobHistory Yes PreserveJobHistory No PreserveJobHistory seconds The value in seconds is treated in the same as 'No' resulting in immediate removing of jobs from history, while it is supposed to save it for . [Test Case] * Set PreserveJobHistory to 300. * Schedule a job for printing. * Check the error_log. Expected result: Job is save for at least 300 seconds. Actual results: Job is immediately removed from history. [Regression Potential] * With the fix the jobs will be saved longer than before, so in tight conditions (low disk space) and heavy workload it may affect memory/disk space consumption and lead to running out of free space in worst case. [Other Info] * Original bug description: 1) Ubuntu Release Description: Ubuntu 16.04.3 LTS Release: 16.04 2) Version of the package cups: Installed: 2.1.3-4ubuntu0.3 Candidate: 2.1.3-4ubuntu0.3 Version table: *** 2.1.3-4ubuntu0.3 500 500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 3) What I expected to happen: from man cupsd.conf PreserveJobFiles Yes PreserveJobFiles No PreserveJobFiles seconds Specifies whether job files (documents) are preserved after a job is printed. If a numeric value is specified, job files are preserved for the indicated number of seconds after printing. The default is "86400" (preserve 1 day). PreserveJobHistory Yes PreserveJobHistory No PreserveJobHistory seconds Specifies whether the job history is preserved after a job is printed. If a numeric value is specified, the job history is preserved for the indicated number of seconds after printing. If "Yes", the job history is preserved until the MaxJobs limit is reached. The default is "Yes". 4) What happens instead If I put the following directives in cupsd.conf the job files and history are deleted immediately. PreserveJobFiles 604800 PreserveJobHistory 604800 Debug log showing history being purged: d [06/Feb/2018:15:11:59 -0600] cupsdCheckJobs: 0 active jobs, sleeping=0, ac-power=-1, reload=0, curtime=1517951519 d [06/Feb/2018:15:11:59 -0600] cupsdCleanJobs: MaxJobs=100, JobHistory=604800, JobFiles=604800 D [06/Feb/2018:15:11:59 -0600] [Job 106] Removing from history. D [06/Feb/2018:15:11:59 -0600] [Job 106] Unloading... To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1747765/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1831021] Re: Extremely high memory consumption under heavy workload
** Description changed: Under heavy workload conditions cups can reach irrationally high memory consumption very quickly (tens of GBs). Test case: 1. Set MaxJobs to 4 in cupsd.conf. 2. sudo apt install cups-pdf 3. Fill the queue with jobs: while [ 1 ]; lp -d PDF /usr/share/cups/data/default.pdf; done 4. Cancel all jobs cancel -a PDF 5. Restart cups. 6. Start filling the queue again (as in step 3). Expected result: Jobs are processed and memory consumption is proportional to the number of jobs. Actual result: - After step 5 or at latest step 6 memory consumption starts to increase exponentially - from ~150-200 MB to 8+GB. Without foreseeing this it's very easy to get cups killed by OOM killer. + After step 5 or at latest step 6 memory consumption starts to increase exponentially - from ~150-200 MB to 8+GB. Without foreseeing this it's very easy to get cupsd killed by OOM killer. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1831021 Title: Extremely high memory consumption under heavy workload Status in cups package in Ubuntu: New Bug description: Under heavy workload conditions cups can reach irrationally high memory consumption very quickly (tens of GBs). Test case: 1. Set MaxJobs to 4 in cupsd.conf. 2. sudo apt install cups-pdf 3. Fill the queue with jobs: while [ 1 ]; lp -d PDF /usr/share/cups/data/default.pdf; done 4. Cancel all jobs cancel -a PDF 5. Restart cups. 6. Start filling the queue again (as in step 3). Expected result: Jobs are processed and memory consumption is proportional to the number of jobs. Actual result: After step 5 or at latest step 6 memory consumption starts to increase exponentially - from ~150-200 MB to 8+GB. Without foreseeing this it's very easy to get cupsd killed by OOM killer. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1831021/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1747765] Re: PreserveJobHistory and PreserveJobLog do not respect numeric input as outlined in the docs
** Description changed: + [Impact] + + The documentation allows the following types of arguments for the PreserveJobHistory parameter: + PreserveJobHistory Yes + PreserveJobHistory No + PreserveJobHistory seconds + + The value in seconds is treated in the same as 'No' resulting in immediate removing of jobs from history, while it is supposed to save it for . + + [Test Case] + + * Set PreserveJobHistory to 300. + * Schedule a job for printing. + * Check the error_log. + + Expected result: + Job is save for at least 300 seconds. + + Actual results: + Job is immediately removed from history. + + [Regression Potential] + + * With the fix the jobs will be saved longer than before, so in tight + conditions (low disk space) and heavy workload it may affect memory/disk + space consumption and lead to running out of free space in worst case. + + [Other Info] + + * Original bug description: + 1) Ubuntu Release Description: Ubuntu 16.04.3 LTS Release: 16.04 2) Version of the package cups: - Installed: 2.1.3-4ubuntu0.3 - Candidate: 2.1.3-4ubuntu0.3 - Version table: - *** 2.1.3-4ubuntu0.3 500 - 500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages + Installed: 2.1.3-4ubuntu0.3 + Candidate: 2.1.3-4ubuntu0.3 + Version table: + *** 2.1.3-4ubuntu0.3 500 + 500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 3) What I expected to happen: from man cupsd.conf - PreserveJobFiles Yes + PreserveJobFiles Yes -PreserveJobFiles No + PreserveJobFiles No -PreserveJobFiles seconds - Specifies whether job files (documents) are preserved after a job is printed. If a numeric value is specified, job files are preserved - for the indicated number of seconds after printing. The default is "86400" (preserve 1 day). + PreserveJobFiles seconds + Specifies whether job files (documents) are preserved after a job is printed. If a numeric value is specified, job files are preserved + for the indicated number of seconds after printing. The default is "86400" (preserve 1 day). -PreserveJobHistory Yes + PreserveJobHistory Yes -PreserveJobHistory No + PreserveJobHistory No -PreserveJobHistory seconds - Specifies whether the job history is preserved after a job is printed. If a numeric value is specified, the job history is preserved for - the indicated number of seconds after printing. If "Yes", the job history is preserved until the MaxJobs limit is reached. The default - is "Yes". + PreserveJobHistory seconds + Specifies whether the job history is preserved after a job is printed. If a numeric value is specified, the job history is preserved for + the indicated number of seconds after printing. If "Yes", the job history is preserved until the MaxJobs limit is reached. The default + is "Yes". 4) What happens instead If I put the following directives in cupsd.conf the job files and history are deleted immediately. PreserveJobFiles 604800 PreserveJobHistory 604800 - Debug log showing history being purged: d [06/Feb/2018:15:11:59 -0600] cupsdCheckJobs: 0 active jobs, sleeping=0, ac-power=-1, reload=0, curtime=1517951519 d [06/Feb/2018:15:11:59 -0600] cupsdCleanJobs: MaxJobs=100, JobHistory=604800, JobFiles=604800 D [06/Feb/2018:15:11:59 -0600] [Job 106] Removing from history. D [06/Feb/2018:15:11:59 -0600] [Job 106] Unloading... ** Changed in: cups (Ubuntu) Importance: Undecided => Medium ** Also affects: cups (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: cups (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: cups (Ubuntu Bionic) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1747765 Title: PreserveJobHistory and PreserveJobLog do not respect numeric input as outlined in the docs Status in cups package in Ubuntu: Fix Released Status in cups source package in Xenial: New Status in cups source package in Bionic: New Status in cups source package in Disco: New Bug description: [Impact] The documentation allows the following types of arguments for the PreserveJobHistory parameter: PreserveJobHistory Yes PreserveJobHistory No PreserveJobHistory seconds The value in seconds is treated in the same as 'No' resulting in immediate removing of jobs from history, while it is supposed to save it for . [Test Case] * Set PreserveJobHistory to 300. * Schedule a job for printing. * Check the error_log. Expected result: Job is save for at least 300 seconds. Actual results:
[Desktop-packages] [Bug 1747765] Re: PreserveJobHistory and PreserveJobLog do not respect numeric input as outlined in the docs
This has been fixed in 19.10 for cups 2.2.10-6 (backport from upstream). ** Changed in: cups (Ubuntu) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1747765 Title: PreserveJobHistory and PreserveJobLog do not respect numeric input as outlined in the docs Status in cups package in Ubuntu: Fix Released Status in cups source package in Xenial: New Status in cups source package in Bionic: New Status in cups source package in Disco: New Bug description: [Impact] The documentation allows the following types of arguments for the PreserveJobHistory parameter: PreserveJobHistory Yes PreserveJobHistory No PreserveJobHistory seconds The value in seconds is treated in the same as 'No' resulting in immediate removing of jobs from history, while it is supposed to save it for . [Test Case] * Set PreserveJobHistory to 300. * Schedule a job for printing. * Check the error_log. Expected result: Job is save for at least 300 seconds. Actual results: Job is immediately removed from history. [Regression Potential] * With the fix the jobs will be saved longer than before, so in tight conditions (low disk space) and heavy workload it may affect memory/disk space consumption and lead to running out of free space in worst case. [Other Info] * Original bug description: 1) Ubuntu Release Description: Ubuntu 16.04.3 LTS Release: 16.04 2) Version of the package cups: Installed: 2.1.3-4ubuntu0.3 Candidate: 2.1.3-4ubuntu0.3 Version table: *** 2.1.3-4ubuntu0.3 500 500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages 3) What I expected to happen: from man cupsd.conf PreserveJobFiles Yes PreserveJobFiles No PreserveJobFiles seconds Specifies whether job files (documents) are preserved after a job is printed. If a numeric value is specified, job files are preserved for the indicated number of seconds after printing. The default is "86400" (preserve 1 day). PreserveJobHistory Yes PreserveJobHistory No PreserveJobHistory seconds Specifies whether the job history is preserved after a job is printed. If a numeric value is specified, the job history is preserved for the indicated number of seconds after printing. If "Yes", the job history is preserved until the MaxJobs limit is reached. The default is "Yes". 4) What happens instead If I put the following directives in cupsd.conf the job files and history are deleted immediately. PreserveJobFiles 604800 PreserveJobHistory 604800 Debug log showing history being purged: d [06/Feb/2018:15:11:59 -0600] cupsdCheckJobs: 0 active jobs, sleeping=0, ac-power=-1, reload=0, curtime=1517951519 d [06/Feb/2018:15:11:59 -0600] cupsdCleanJobs: MaxJobs=100, JobHistory=604800, JobFiles=604800 D [06/Feb/2018:15:11:59 -0600] [Job 106] Removing from history. D [06/Feb/2018:15:11:59 -0600] [Job 106] Unloading... To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1747765/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1831021] Re: Extremely high memory consumption under heavy workload
After some analysis I believe the very high default value of LogDebugHistory (9) is to blame for this (attaching massif report from the test case). With a high number of jobs it's very easy to get hunderds-thousands of messages in LogDebugHistory which in turn will lead to enormous memory consumption, e.g. 4 jobs * 2000 lines * (16 bytes for cupsd_joblog_t structure + 50-60 chars per message on average) - 5.66 GB. After setting LogDebugHistory to 0 the memory consumption never exceeded 300 MB in my tests under the same heavy load. That's a very significant difference. The possible workarounds: 1. Decrease LogDebugHistory to a low value (even to 0, upstream it's set to 200 by default). 2. Change LogLevel to debug (it will slow down cupsd operation significantly, but at the price of lower memory consumption as the LogDebugHistory is unused). 3. Make sure jobs are cleaned periodically by setting e.g. PreserveJobHistory 300. I am wondering what was the rationale behind increasing LogDebugHistory to such a high value. ** Attachment added: "massif.out.xz" https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1831021/+attachment/5267574/+files/massif.out.xz -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1831021 Title: Extremely high memory consumption under heavy workload Status in cups package in Ubuntu: New Bug description: Under heavy workload conditions cups can reach irrationally high memory consumption very quickly (tens of GBs). Test case: 1. Set MaxJobs to 4 in cupsd.conf. 2. sudo apt install cups-pdf 3. Fill the queue with jobs: while [ 1 ]; lp -d PDF /usr/share/cups/data/default.pdf; done 4. Cancel all jobs cancel -a PDF 5. Restart cups. 6. Start filling the queue again (as in step 3). Expected result: Jobs are processed and memory consumption is proportional to the number of jobs. Actual result: After step 5 or at latest step 6 memory consumption starts to increase exponentially - from ~150-200 MB to 8+GB. Without foreseeing this it's very easy to get cups killed by OOM killer. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1831021/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1831021] [NEW] Extremely high memory consumption under heavy workload
Public bug reported: Under heavy workload conditions cups can reach irrationally high memory consumption very quickly (tens of GBs). Test case: 1. Set MaxJobs to 4 in cupsd.conf. 2. sudo apt install cups-pdf 3. Fill the queue with jobs: while [ 1 ]; lp -d PDF /usr/share/cups/data/default.pdf; done 4. Cancel all jobs cancel -a PDF 5. Restart cups. 6. Start filling the queue again (as in step 3). Expected result: Jobs are processed and memory consumption is proportional to the number of jobs. Actual result: After step 5 or at latest step 6 memory consumption starts to increase exponentially - from ~150-200 MB to 8+GB. Without foreseeing this it's very easy to get cups killed by OOM killer. ** Affects: cups (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1831021 Title: Extremely high memory consumption under heavy workload Status in cups package in Ubuntu: New Bug description: Under heavy workload conditions cups can reach irrationally high memory consumption very quickly (tens of GBs). Test case: 1. Set MaxJobs to 4 in cupsd.conf. 2. sudo apt install cups-pdf 3. Fill the queue with jobs: while [ 1 ]; lp -d PDF /usr/share/cups/data/default.pdf; done 4. Cancel all jobs cancel -a PDF 5. Restart cups. 6. Start filling the queue again (as in step 3). Expected result: Jobs are processed and memory consumption is proportional to the number of jobs. Actual result: After step 5 or at latest step 6 memory consumption starts to increase exponentially - from ~150-200 MB to 8+GB. Without foreseeing this it's very easy to get cups killed by OOM killer. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1831021/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1830022] Re: DirtyCleanInterval should be 0 by default
** Tags removed: rls-nn-incoming -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1830022 Title: DirtyCleanInterval should be 0 by default Status in cups package in Ubuntu: Confirmed Bug description: Please consider changing DirtyCleanInterval value to 0 as default. Otherwise if cupsd crashes due to (e.g. OOM killer) under a heavy workload even hundreds of jobs may be lost. This concern is backed up by a real-life scenario and leaves the client sending thousands of jobs unaware that many of them are lost during a crash. After cupsd gets restarted it rewinds it's job counter to the last cached and continues unaware about the jobs accepted and lost. Having DirtyCleanInterval set to 0 will cause some performance impact, but not significant under lighter workloads and a completely justified price for reliability under heavy workloads. Test scenario: 1. sudo apt install printer-driver-cups-pdf 2. while [ 1 ]; do lp -d PDF somepdf.pdf; done; 3. # on other terminal kill -9 $(pidof cupsd) 4. Note last job number and wait for cupsd to be restarted by systemd. 5. Once accepting jobs is resumend the job counter is rewound. Expected behavior: Accepted jobs are queued for processing. Actual behavior: Some accepted jobs are lost. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1830022/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1830022] Re: DirtyCleanInterval should be 0 by default
** Tags added: rls-nn-incoming -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1830022 Title: DirtyCleanInterval should be 0 by default Status in cups package in Ubuntu: Confirmed Bug description: Please consider changing DirtyCleanInterval value to 0 as default. Otherwise if cupsd crashes due to (e.g. OOM killer) under a heavy workload even hundreds of jobs may be lost. This concern is backed up by a real-life scenario and leaves the client sending thousands of jobs unaware that many of them are lost during a crash. After cupsd gets restarted it rewinds it's job counter to the last cached and continues unaware about the jobs accepted and lost. Having DirtyCleanInterval set to 0 will cause some performance impact, but not significant under lighter workloads and a completely justified price for reliability under heavy workloads. Test scenario: 1. sudo apt install printer-driver-cups-pdf 2. while [ 1 ]; do lp -d PDF somepdf.pdf; done; 3. # on other terminal kill -9 $(pidof cupsd) 4. Note last job number and wait for cupsd to be restarted by systemd. 5. Once accepting jobs is resumend the job counter is rewound. Expected behavior: Accepted jobs are queued for processing. Actual behavior: Some accepted jobs are lost. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1830022/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1830022] [NEW] DirtyCleanInterval should be 0 by default
Public bug reported: Please consider changing DirtyCleanInterval value to 0 as default. Otherwise if cupsd crashes due to (e.g. OOM killer) under a heavy workload even hundreds of jobs may be lost. This concern is backed up by a real-life scenario and leaves the client sending thousands of jobs unaware that many of them are lost during a crash. After cupsd gets restarted it rewinds it's job counter to the last cached and continues unaware about the jobs accepted and lost. Having DirtyCleanInterval set to 0 will cause some performance impact, but not significant under lighter workloads and a completely justified price for reliability under heavy workloads. Test scenario: 1. sudo apt install printer-driver-cups-pdf 2. while [ 1 ]; do lp -d PDF somepdf.pdf; done; 3. # on other terminal kill -9 $(pidof cupsd) 4. Note last job number and wait for cupsd to be restarted by systemd. 5. Once accepting jobs is resumend the job counter is rewound. Expected behavior: Accepted jobs are queued for processing. Actual behavior: Some accepted jobs are lost. ** Affects: cups (Ubuntu) Importance: Undecided Status: New ** Affects: cups (Ubuntu Xenial) Importance: Undecided Status: New ** Affects: cups (Ubuntu Bionic) Importance: Undecided Status: New ** Affects: cups (Ubuntu Cosmic) Importance: Undecided Status: New ** Affects: cups (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: cups (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: cups (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: cups (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: cups (Ubuntu Cosmic) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1830022 Title: DirtyCleanInterval should be 0 by default Status in cups package in Ubuntu: New Status in cups source package in Xenial: New Status in cups source package in Bionic: New Status in cups source package in Cosmic: New Status in cups source package in Disco: New Bug description: Please consider changing DirtyCleanInterval value to 0 as default. Otherwise if cupsd crashes due to (e.g. OOM killer) under a heavy workload even hundreds of jobs may be lost. This concern is backed up by a real-life scenario and leaves the client sending thousands of jobs unaware that many of them are lost during a crash. After cupsd gets restarted it rewinds it's job counter to the last cached and continues unaware about the jobs accepted and lost. Having DirtyCleanInterval set to 0 will cause some performance impact, but not significant under lighter workloads and a completely justified price for reliability under heavy workloads. Test scenario: 1. sudo apt install printer-driver-cups-pdf 2. while [ 1 ]; do lp -d PDF somepdf.pdf; done; 3. # on other terminal kill -9 $(pidof cupsd) 4. Note last job number and wait for cupsd to be restarted by systemd. 5. Once accepting jobs is resumend the job counter is rewound. Expected behavior: Accepted jobs are queued for processing. Actual behavior: Some accepted jobs are lost. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1830022/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1762391] Re: pam_group.so is not evaluated by gnome-terminal
** Also affects: gnome-terminal (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Xenial) Importance: Undecided Status: New ** No longer affects: gnome-terminal (Ubuntu Xenial) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1762391 Title: pam_group.so is not evaluated by gnome-terminal Status in systemd: New Status in gnome-terminal package in Ubuntu: Invalid Status in systemd package in Ubuntu: Won't Fix Status in systemd source package in Xenial: New Status in systemd source package in Bionic: Won't Fix Status in systemd source package in Cosmic: Won't Fix Bug description: We are using Ubuntu in a university network with lots of ldap users. To automatically map ldap users/groups to local groups we are using pam_group.so. This has worked for years. With the upgrade from Xenial to Bionic /etc/security/group.conf is not evaluated anymore by gnome-terminal as it runs as systemd --user. Xterm, ssh, su, and tty* however do work as expected. Only the default gnome-terminal behaves different. According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851243 and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756458 this might not be a bug, but a feature. Nevertheless this behavior is very unexpected when upgrading from Xenial to Bionic and therefore should at least added to the changelog. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gnome-terminal 3.28.0-1ubuntu1 ProcVersionSignature: Ubuntu 4.15.0-10.11-generic 4.15.3 Uname: Linux 4.15.0-10-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.9-0ubuntu4 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Mon Apr 9 13:17:52 2018 InstallationDate: Installed on 2018-03-29 (11 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180321) SourcePackage: gnome-terminal UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1762391/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1762391] Re: pam_group.so is not evaluated by gnome-terminal
According to my tests GDM works as expected - checking groups the user belongs to on different terminal emulators (e.g. xterm) proves that the /etc/security/group.conf groups are correctly applied. The problem in this case affects gnome-terminal alone (and the problem is present also if using e.g. LightDM instead of GDM). This is related to the way gnome-terminal-server is started via DBus and executed under systemd --user. It is started under the systemd-user PAM service, so pam_group entry should be added to /etc/pam.d/systemd-user. The problem is systemd will never apply pam_group settings because it does not call pam_setcred. The issue is reported to systemd along with a PR fixing it: https://github.com/systemd/systemd/issues/11198 ** Bug watch added: github.com/systemd/systemd/issues #11198 https://github.com/systemd/systemd/issues/11198 ** Also affects: gnome-terminal via https://github.com/systemd/systemd/issues/11198 Importance: Unknown Status: Unknown ** Project changed: gnome-terminal => systemd ** Changed in: gnome-terminal (Ubuntu) Status: Confirmed => Invalid ** Also affects: systemd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1762391 Title: pam_group.so is not evaluated by gnome-terminal Status in systemd: Unknown Status in gnome-terminal package in Ubuntu: Invalid Status in systemd package in Ubuntu: New Bug description: We are using Ubuntu in a university network with lots of ldap users. To automatically map ldap users/groups to local groups we are using pam_group.so. This has worked for years. With the upgrade from Xenial to Bionic /etc/security/group.conf is not evaluated anymore by gnome-terminal as it runs as systemd --user. Xterm, ssh, su, and tty* however do work as expected. Only the default gnome-terminal behaves different. According to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851243 and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756458 this might not be a bug, but a feature. Nevertheless this behavior is very unexpected when upgrading from Xenial to Bionic and therefore should at least added to the changelog. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: gnome-terminal 3.28.0-1ubuntu1 ProcVersionSignature: Ubuntu 4.15.0-10.11-generic 4.15.3 Uname: Linux 4.15.0-10-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.9-0ubuntu4 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Mon Apr 9 13:17:52 2018 InstallationDate: Installed on 2018-03-29 (11 days ago) InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180321) SourcePackage: gnome-terminal UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1762391/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1804576] Re: MaxJobTime=0 results in jobs being cancelled immediately instead of never
I have finished verification of cosmic. With 2.2.8-5ubuntu1.1: $ grep -i cancel /var/log/cups/error_log I [13/Dec/2018:09:23:02 +0100] [Job 1] Canceling stuck job after 0 seconds. After upgrading to 2.2.8-5ubuntu1.2: $ grep -i -e cancel -e complete /var/log/cups/error_log I [13/Dec/2018:09:25:00 +0100] Full reload complete. I [13/Dec/2018:09:25:28 +0100] [Job 2] Job completed. ** Tags removed: verification-needed-cosmic ** Tags added: verification-done-cosmic -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1804576 Title: MaxJobTime=0 results in jobs being cancelled immediately instead of never Status in CUPS: Fix Released Status in cups package in Ubuntu: Fix Released Status in cups source package in Trusty: Invalid Status in cups source package in Xenial: Fix Committed Status in cups source package in Bionic: Fix Committed Status in cups source package in Cosmic: Fix Committed Status in cups source package in Disco: Fix Released Status in cups package in Debian: Fix Released Bug description: [Impact] Setting the cupsd option MaxJobTime to 0 should make the server wait indefinitely for the job to be ready for print. Instead, after updating job-cancel-after option with MaxJobTime=0 value it results in immediate cancelling. This leads to problems with using filters that take some time to process - the user needs to set MaxJobTime to a ridiculously high value to ensure the job is not going to get cancelled instead of just disabling the cancelling timeout. [Test Case] 1. Add MaxJobTime 0 option to /etc/cups/cupsd.conf. 2. Setup a filter that takes at least several seconds to process. (please find a sample imagetopdf wrapper introducing 5s delay) 3. Submit a print job matching the filter, e.g. lp -d my-printer someimage.jpg # jpg uses the imagetopdf wrapper Expected result: The job is printed after the 5s delay. Actual result: The job is cancelled. [Regression Potential] The scope of the change is limited to fixing the MaxJobTime handling in scheduler/job.c and scheduler/printers.c. There should be no difference in behavior except for the special value of MaxJobTime=0. [Other Info] Original bug description: When using CUPS filters, these filters can take a few seconds to complete. In this case no documents are allowed to be lost on printing failures, so we used to set "MaxJobTime 0" in cupsd.conf which worked on Ubuntu 14.04. With cups on 18.04, you get the following message in /var/log/cups/error_log whenever the filter takes a little longer: I [12/Nov/2018:14:43:26 +0100] [Job 18] Canceling stuck job after 0 seconds. Then, the job is deleted and lost. "MaxJobTime 0" is documented as "indefinite wait", but apparently cups treats is as "wait almost not at all". This issue appears to have also been filed upstream: https://github.com/apple/cups/issues/5438 Temporary workaround is to set the MaxJobTime to a very large value instead (e.g. 3 years) Trusty is not affected by this bug. To manage notifications about this bug go to: https://bugs.launchpad.net/cups/+bug/1804576/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1804576] Re: MaxJobTime=0 results in jobs being cancelled immediately instead of never
Verification of xenial is positive as well: 2.1.3-4ubuntu0.6 $ grep -i cancel error_log I [13/Dec/2018:09:28:50 +0100] [Job 1] Canceling stuck job after 0 seconds. 2.1.3-4ubuntu0.7 $ grep -i -e cancel -e completed error_log I [13/Dec/2018:09:31:22 +0100] [Job 2] Job completed. ** Tags removed: verification-needed verification-needed-xenial ** Tags added: verification-done verification-done-xenial -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1804576 Title: MaxJobTime=0 results in jobs being cancelled immediately instead of never Status in CUPS: Fix Released Status in cups package in Ubuntu: Fix Released Status in cups source package in Trusty: Invalid Status in cups source package in Xenial: Fix Committed Status in cups source package in Bionic: Fix Committed Status in cups source package in Cosmic: Fix Committed Status in cups source package in Disco: Fix Released Status in cups package in Debian: Fix Released Bug description: [Impact] Setting the cupsd option MaxJobTime to 0 should make the server wait indefinitely for the job to be ready for print. Instead, after updating job-cancel-after option with MaxJobTime=0 value it results in immediate cancelling. This leads to problems with using filters that take some time to process - the user needs to set MaxJobTime to a ridiculously high value to ensure the job is not going to get cancelled instead of just disabling the cancelling timeout. [Test Case] 1. Add MaxJobTime 0 option to /etc/cups/cupsd.conf. 2. Setup a filter that takes at least several seconds to process. (please find a sample imagetopdf wrapper introducing 5s delay) 3. Submit a print job matching the filter, e.g. lp -d my-printer someimage.jpg # jpg uses the imagetopdf wrapper Expected result: The job is printed after the 5s delay. Actual result: The job is cancelled. [Regression Potential] The scope of the change is limited to fixing the MaxJobTime handling in scheduler/job.c and scheduler/printers.c. There should be no difference in behavior except for the special value of MaxJobTime=0. [Other Info] Original bug description: When using CUPS filters, these filters can take a few seconds to complete. In this case no documents are allowed to be lost on printing failures, so we used to set "MaxJobTime 0" in cupsd.conf which worked on Ubuntu 14.04. With cups on 18.04, you get the following message in /var/log/cups/error_log whenever the filter takes a little longer: I [12/Nov/2018:14:43:26 +0100] [Job 18] Canceling stuck job after 0 seconds. Then, the job is deleted and lost. "MaxJobTime 0" is documented as "indefinite wait", but apparently cups treats is as "wait almost not at all". This issue appears to have also been filed upstream: https://github.com/apple/cups/issues/5438 Temporary workaround is to set the MaxJobTime to a very large value instead (e.g. 3 years) Trusty is not affected by this bug. To manage notifications about this bug go to: https://bugs.launchpad.net/cups/+bug/1804576/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1804576] Re: MaxJobTime=0 results in jobs being cancelled immediately instead of never
Of course the above setup should include setting MaxJobTime to 0 in /etc/cups/cupsd.conf. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1804576 Title: MaxJobTime=0 results in jobs being cancelled immediately instead of never Status in CUPS: Fix Released Status in cups package in Ubuntu: Fix Released Status in cups source package in Trusty: Invalid Status in cups source package in Xenial: Fix Committed Status in cups source package in Bionic: Fix Committed Status in cups source package in Cosmic: Fix Committed Status in cups source package in Disco: Fix Released Status in cups package in Debian: Fix Released Bug description: [Impact] Setting the cupsd option MaxJobTime to 0 should make the server wait indefinitely for the job to be ready for print. Instead, after updating job-cancel-after option with MaxJobTime=0 value it results in immediate cancelling. This leads to problems with using filters that take some time to process - the user needs to set MaxJobTime to a ridiculously high value to ensure the job is not going to get cancelled instead of just disabling the cancelling timeout. [Test Case] 1. Add MaxJobTime 0 option to /etc/cups/cupsd.conf. 2. Setup a filter that takes at least several seconds to process. (please find a sample imagetopdf wrapper introducing 5s delay) 3. Submit a print job matching the filter, e.g. lp -d my-printer someimage.jpg # jpg uses the imagetopdf wrapper Expected result: The job is printed after the 5s delay. Actual result: The job is cancelled. [Regression Potential] The scope of the change is limited to fixing the MaxJobTime handling in scheduler/job.c and scheduler/printers.c. There should be no difference in behavior except for the special value of MaxJobTime=0. [Other Info] Original bug description: When using CUPS filters, these filters can take a few seconds to complete. In this case no documents are allowed to be lost on printing failures, so we used to set "MaxJobTime 0" in cupsd.conf which worked on Ubuntu 14.04. With cups on 18.04, you get the following message in /var/log/cups/error_log whenever the filter takes a little longer: I [12/Nov/2018:14:43:26 +0100] [Job 18] Canceling stuck job after 0 seconds. Then, the job is deleted and lost. "MaxJobTime 0" is documented as "indefinite wait", but apparently cups treats is as "wait almost not at all". This issue appears to have also been filed upstream: https://github.com/apple/cups/issues/5438 Temporary workaround is to set the MaxJobTime to a very large value instead (e.g. 3 years) Trusty is not affected by this bug. To manage notifications about this bug go to: https://bugs.launchpad.net/cups/+bug/1804576/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1804576] Re: MaxJobTime=0 results in jobs being cancelled immediately instead of never
I have just verified bionic with version 2.2.7-1ubuntu2.3. My testing procedure: 1. Switch cups log level to info. 2. Restart cups. 3. Install printer-driver-cups-pdf to have a virtual printer. 4. Replace imagetopdf filter: sudo mv /usr/lib/cups/filter/imagetopdf /usr/lib/cups/filter/imagetopdf.bkp 5. Install wrapper from comment #6 as replacement: sudo install -m 755 ~/imagetopdf /usr/lib/cups/filter/imagetopdf 6. Print an image (so it gets picked by the filter wrapper): lp -d PDF some_image.tiff With 2.2.7-1ubuntu2.3 (Job 1): $ grep -i cancel /var/log/cups/error_log I [13/Dec/2018:08:49:02 +0100] [Job 1] Canceling stuck job after 0 seconds. After upgrading to 2.2.7-1ubuntu2.3 (please look at Job 2) $ grep -i -e cancel -e complete /var/log/cups/error_log I [13/Dec/2018:08:49:02 +0100] [Job 1] Canceling stuck job after 0 seconds. I [13/Dec/2018:08:50:09 +0100] Full reload complete. I [13/Dec/2018:08:50:41 +0100] [Job 2] Job completed. ** Tags removed: verification-needed-bionic ** Tags added: verification-done-bionic -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1804576 Title: MaxJobTime=0 results in jobs being cancelled immediately instead of never Status in CUPS: Fix Released Status in cups package in Ubuntu: Fix Released Status in cups source package in Trusty: Invalid Status in cups source package in Xenial: Fix Committed Status in cups source package in Bionic: Fix Committed Status in cups source package in Cosmic: Fix Committed Status in cups source package in Disco: Fix Released Status in cups package in Debian: Fix Released Bug description: [Impact] Setting the cupsd option MaxJobTime to 0 should make the server wait indefinitely for the job to be ready for print. Instead, after updating job-cancel-after option with MaxJobTime=0 value it results in immediate cancelling. This leads to problems with using filters that take some time to process - the user needs to set MaxJobTime to a ridiculously high value to ensure the job is not going to get cancelled instead of just disabling the cancelling timeout. [Test Case] 1. Add MaxJobTime 0 option to /etc/cups/cupsd.conf. 2. Setup a filter that takes at least several seconds to process. (please find a sample imagetopdf wrapper introducing 5s delay) 3. Submit a print job matching the filter, e.g. lp -d my-printer someimage.jpg # jpg uses the imagetopdf wrapper Expected result: The job is printed after the 5s delay. Actual result: The job is cancelled. [Regression Potential] The scope of the change is limited to fixing the MaxJobTime handling in scheduler/job.c and scheduler/printers.c. There should be no difference in behavior except for the special value of MaxJobTime=0. [Other Info] Original bug description: When using CUPS filters, these filters can take a few seconds to complete. In this case no documents are allowed to be lost on printing failures, so we used to set "MaxJobTime 0" in cupsd.conf which worked on Ubuntu 14.04. With cups on 18.04, you get the following message in /var/log/cups/error_log whenever the filter takes a little longer: I [12/Nov/2018:14:43:26 +0100] [Job 18] Canceling stuck job after 0 seconds. Then, the job is deleted and lost. "MaxJobTime 0" is documented as "indefinite wait", but apparently cups treats is as "wait almost not at all". This issue appears to have also been filed upstream: https://github.com/apple/cups/issues/5438 Temporary workaround is to set the MaxJobTime to a very large value instead (e.g. 3 years) Trusty is not affected by this bug. To manage notifications about this bug go to: https://bugs.launchpad.net/cups/+bug/1804576/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1804576] Re: MaxJobTime=0 results in jobs being cancelled immediately instead of never
Updated debdiff for bionic. ** Patch added: "bionic_cups_2.2.7-1ubuntu2.3.debdiff" https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1804576/+attachment/5221596/+files/bionic_cups_2.2.7-1ubuntu2.3.debdiff -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1804576 Title: MaxJobTime=0 results in jobs being cancelled immediately instead of never Status in CUPS: Fix Released Status in cups package in Ubuntu: Fix Released Status in cups source package in Trusty: Invalid Status in cups source package in Xenial: In Progress Status in cups source package in Bionic: In Progress Status in cups source package in Cosmic: In Progress Status in cups source package in Disco: Fix Released Status in cups package in Debian: Fix Released Bug description: [Impact] Setting the cupsd option MaxJobTime to 0 should make the server wait indefinitely for the job to be ready for print. Instead, after updating job-cancel-after option with MaxJobTime=0 value it results in immediate cancelling. This leads to problems with using filters that take some time to process - the user needs to set MaxJobTime to a ridiculously high value to ensure the job is not going to get cancelled instead of just disabling the cancelling timeout. [Test Case] 1. Add MaxJobTime 0 option to /etc/cups/cupsd.conf. 2. Setup a filter that takes at least several seconds to process. (please find a sample imagetopdf wrapper introducing 5s delay) 3. Submit a print job matching the filter, e.g. lp -d my-printer someimage.jpg # jpg uses the imagetopdf wrapper Expected result: The job is printed after the 5s delay. Actual result: The job is cancelled. [Regression Potential] The scope of the change is limited to fixing the MaxJobTime handling in scheduler/job.c and scheduler/printers.c. There should be no difference in behavior except for the special value of MaxJobTime=0. [Other Info] Original bug description: When using CUPS filters, these filters can take a few seconds to complete. In this case no documents are allowed to be lost on printing failures, so we used to set "MaxJobTime 0" in cupsd.conf which worked on Ubuntu 14.04. With cups on 18.04, you get the following message in /var/log/cups/error_log whenever the filter takes a little longer: I [12/Nov/2018:14:43:26 +0100] [Job 18] Canceling stuck job after 0 seconds. Then, the job is deleted and lost. "MaxJobTime 0" is documented as "indefinite wait", but apparently cups treats is as "wait almost not at all". This issue appears to have also been filed upstream: https://github.com/apple/cups/issues/5438 Temporary workaround is to set the MaxJobTime to a very large value instead (e.g. 3 years) Trusty is not affected by this bug. To manage notifications about this bug go to: https://bugs.launchpad.net/cups/+bug/1804576/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1804576] Re: MaxJobTime=0 results in jobs being cancelled immediately instead of never
Updated debdiff for xenial. ** Patch added: "xenial_cups_2.1.3-4ubuntu0.7.debdiff" https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1804576/+attachment/5221597/+files/xenial_cups_2.1.3-4ubuntu0.7.debdiff -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1804576 Title: MaxJobTime=0 results in jobs being cancelled immediately instead of never Status in CUPS: Fix Released Status in cups package in Ubuntu: Fix Released Status in cups source package in Trusty: Invalid Status in cups source package in Xenial: In Progress Status in cups source package in Bionic: In Progress Status in cups source package in Cosmic: In Progress Status in cups source package in Disco: Fix Released Status in cups package in Debian: Fix Released Bug description: [Impact] Setting the cupsd option MaxJobTime to 0 should make the server wait indefinitely for the job to be ready for print. Instead, after updating job-cancel-after option with MaxJobTime=0 value it results in immediate cancelling. This leads to problems with using filters that take some time to process - the user needs to set MaxJobTime to a ridiculously high value to ensure the job is not going to get cancelled instead of just disabling the cancelling timeout. [Test Case] 1. Add MaxJobTime 0 option to /etc/cups/cupsd.conf. 2. Setup a filter that takes at least several seconds to process. (please find a sample imagetopdf wrapper introducing 5s delay) 3. Submit a print job matching the filter, e.g. lp -d my-printer someimage.jpg # jpg uses the imagetopdf wrapper Expected result: The job is printed after the 5s delay. Actual result: The job is cancelled. [Regression Potential] The scope of the change is limited to fixing the MaxJobTime handling in scheduler/job.c and scheduler/printers.c. There should be no difference in behavior except for the special value of MaxJobTime=0. [Other Info] Original bug description: When using CUPS filters, these filters can take a few seconds to complete. In this case no documents are allowed to be lost on printing failures, so we used to set "MaxJobTime 0" in cupsd.conf which worked on Ubuntu 14.04. With cups on 18.04, you get the following message in /var/log/cups/error_log whenever the filter takes a little longer: I [12/Nov/2018:14:43:26 +0100] [Job 18] Canceling stuck job after 0 seconds. Then, the job is deleted and lost. "MaxJobTime 0" is documented as "indefinite wait", but apparently cups treats is as "wait almost not at all". This issue appears to have also been filed upstream: https://github.com/apple/cups/issues/5438 Temporary workaround is to set the MaxJobTime to a very large value instead (e.g. 3 years) Trusty is not affected by this bug. To manage notifications about this bug go to: https://bugs.launchpad.net/cups/+bug/1804576/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1804576] Re: MaxJobTime=0 results in jobs being cancelled immediately instead of never
Updated debdiff for cosmic. ** Patch removed: "cosmic_cups_2.2.8-5ubuntu2.debdiff" https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1804576/+attachment/5219665/+files/cosmic_cups_2.2.8-5ubuntu2.debdiff ** Patch removed: "bionic_cups_2.2.7-1ubuntu2.2.debdiff" https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1804576/+attachment/5219666/+files/bionic_cups_2.2.7-1ubuntu2.2.debdiff ** Patch removed: "xenial_cups_2.1.3-4ubuntu0.6.debdiff" https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1804576/+attachment/5219667/+files/xenial_cups_2.1.3-4ubuntu0.6.debdiff ** Patch added: "cosmic_cups_2.2.8-5ubuntu1.2.debdiff" https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1804576/+attachment/5221595/+files/cosmic_cups_2.2.8-5ubuntu1.2.debdiff -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1804576 Title: MaxJobTime=0 results in jobs being cancelled immediately instead of never Status in CUPS: Fix Released Status in cups package in Ubuntu: Fix Released Status in cups source package in Trusty: Invalid Status in cups source package in Xenial: In Progress Status in cups source package in Bionic: In Progress Status in cups source package in Cosmic: In Progress Status in cups source package in Disco: Fix Released Status in cups package in Debian: Fix Released Bug description: [Impact] Setting the cupsd option MaxJobTime to 0 should make the server wait indefinitely for the job to be ready for print. Instead, after updating job-cancel-after option with MaxJobTime=0 value it results in immediate cancelling. This leads to problems with using filters that take some time to process - the user needs to set MaxJobTime to a ridiculously high value to ensure the job is not going to get cancelled instead of just disabling the cancelling timeout. [Test Case] 1. Add MaxJobTime 0 option to /etc/cups/cupsd.conf. 2. Setup a filter that takes at least several seconds to process. (please find a sample imagetopdf wrapper introducing 5s delay) 3. Submit a print job matching the filter, e.g. lp -d my-printer someimage.jpg # jpg uses the imagetopdf wrapper Expected result: The job is printed after the 5s delay. Actual result: The job is cancelled. [Regression Potential] The scope of the change is limited to fixing the MaxJobTime handling in scheduler/job.c and scheduler/printers.c. There should be no difference in behavior except for the special value of MaxJobTime=0. [Other Info] Original bug description: When using CUPS filters, these filters can take a few seconds to complete. In this case no documents are allowed to be lost on printing failures, so we used to set "MaxJobTime 0" in cupsd.conf which worked on Ubuntu 14.04. With cups on 18.04, you get the following message in /var/log/cups/error_log whenever the filter takes a little longer: I [12/Nov/2018:14:43:26 +0100] [Job 18] Canceling stuck job after 0 seconds. Then, the job is deleted and lost. "MaxJobTime 0" is documented as "indefinite wait", but apparently cups treats is as "wait almost not at all". This issue appears to have also been filed upstream: https://github.com/apple/cups/issues/5438 Temporary workaround is to set the MaxJobTime to a very large value instead (e.g. 3 years) Trusty is not affected by this bug. To manage notifications about this bug go to: https://bugs.launchpad.net/cups/+bug/1804576/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1804576] Re: MaxJobTime=0 results in jobs being cancelled immediately instead of never
SRU proposal for disco (fixed) ** Patch removed: "disco_cups_2.2.9-3ubuntu1.debdiff" https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1804576/+attachment/5219664/+files/disco_cups_2.2.9-3ubuntu1.debdiff ** Patch added: "disco_cups_2.2.9-3ubuntu1.debdiff" https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1804576/+attachment/5219720/+files/disco_cups_2.2.9-3ubuntu1.debdiff -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/1804576 Title: MaxJobTime=0 results in jobs being cancelled immediately instead of never Status in CUPS: New Status in cups package in Ubuntu: In Progress Status in cups source package in Trusty: Invalid Status in cups source package in Xenial: In Progress Status in cups source package in Bionic: In Progress Status in cups source package in Cosmic: In Progress Status in cups source package in Disco: In Progress Bug description: [Impact] Setting the cupsd option MaxJobTime to 0 should make the server wait indefinitely for the job to be ready for print. Instead, after updating job-cancel-after option with MaxJobTime=0 value it results in immediate cancelling. This leads to problems with using filters that take some time to process - the user needs to set MaxJobTime to a ridiculously high value to ensure the job is not going to get cancelled instead of just disabling the cancelling timeout. [Test Case] 1. Add MaxJobTime 0 option to /etc/cups/cupsd.conf. 2. Setup a filter that takes at least several seconds to process. (please find a sample imagetopdf wrapper introducing 5s delay) 3. Submit a print job matching the filter, e.g. lp -d my-printer someimage.jpg # jpg uses the imagetopdf wrapper Expected result: The job is printed after the 5s delay. Actual result: The job is cancelled. [Regression Potential] The scope of the change is limited to fixing the MaxJobTime handling in scheduler/job.c and scheduler/printers.c. There should be no difference in behavior except for the special value of MaxJobTime=0. [Other Info] Original bug description: When using CUPS filters, these filters can take a few seconds to complete. In this case no documents are allowed to be lost on printing failures, so we used to set "MaxJobTime 0" in cupsd.conf which worked on Ubuntu 14.04. With cups on 18.04, you get the following message in /var/log/cups/error_log whenever the filter takes a little longer: I [12/Nov/2018:14:43:26 +0100] [Job 18] Canceling stuck job after 0 seconds. Then, the job is deleted and lost. "MaxJobTime 0" is documented as "indefinite wait", but apparently cups treats is as "wait almost not at all". This issue appears to have also been filed upstream: https://github.com/apple/cups/issues/5438 Temporary workaround is to set the MaxJobTime to a very large value instead (e.g. 3 years) Trusty is not affected by this bug. To manage notifications about this bug go to: https://bugs.launchpad.net/cups/+bug/1804576/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
