[Desktop-packages] [Bug 1966780] [NEW] transmission-qt crashes when UI element is destroyed before RPC call gets to update it
Public bug reported: Currently Transmission (Qt client) crashes really often when you just use it against a distant server. This is because the RPC callback tries to update an UI element that is often destroyed. Please backport this patch to Ubuntu releases as soon as possible as this crash is very frequent for some users. https://github.com/transmission/transmission/pull/1604 ** Affects: transmission Importance: Unknown Status: Unknown ** Affects: transmission (Ubuntu) Importance: Undecided Status: Confirmed ** Changed in: transmission (Ubuntu) Status: New => Confirmed ** Bug watch added: github.com/transmission/transmission/issues #1510 https://github.com/transmission/transmission/issues/1510 ** Also affects: transmission via https://github.com/transmission/transmission/issues/1510 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to transmission in Ubuntu. https://bugs.launchpad.net/bugs/1966780 Title: transmission-qt crashes when UI element is destroyed before RPC call gets to update it Status in Transmission: Unknown Status in transmission package in Ubuntu: Confirmed Bug description: Currently Transmission (Qt client) crashes really often when you just use it against a distant server. This is because the RPC callback tries to update an UI element that is often destroyed. Please backport this patch to Ubuntu releases as soon as possible as this crash is very frequent for some users. https://github.com/transmission/transmission/pull/1604 To manage notifications about this bug go to: https://bugs.launchpad.net/transmission/+bug/1966780/+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 1965535] Re: Stop recommending snap
It's also worth pointing out how snap does not offer feature parity. VA- API and native-component extensions are broken to this day with Chromium snap, for four years now. The latter meaning that entire countries can not use chromium snap if they wish to use their national authentication and signature system on the web. Broken for millions of potential users and nobody cares. Seeing how shipping fully-working software seems not doable with snaps, recommending it as a default is an user-hostile decision at this point in time. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to ubuntu-meta in Ubuntu. https://bugs.launchpad.net/bugs/1965535 Title: Stop recommending snap Status in ubuntu-meta package in Ubuntu: Opinion Bug description: Currently, ubuntu recommends installing snap by default, and some apps are slowly transitioning from DEB-based installation to Snap-based installation. APT is great, and facilitates having a clean, maintainable system. The snap project is not very well designed or engineered (just changing the location of where snap data is located is taking the project more than 5 years because it was hardcoded: https://bugs.launchpad.net/snapd/+bug/1575053). Snaps are large and VERY slow. The design of snap, as well as the way that decisions are made, are very questionable, and are receiving increasing amounts of criticism. I'd like to request that Ubuntu stops recommending snap, stops transitioning towards snaps, and we come back to defaulting to DEB/APT-based installation for all apps. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1965535/+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 1960307] Re: No gstreamer dependency causes high-fidelity codecs to be missing for Bluetooth devices
** Bug watch added: Debian Bug tracker #991597 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991597 ** Also affects: pulseaudio via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991597 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1960307 Title: No gstreamer dependency causes high-fidelity codecs to be missing for Bluetooth devices Status in PulseAudio: Unknown Status in gst-plugins-bad1.0 package in Ubuntu: Confirmed Status in gstreamer1.0 package in Ubuntu: Confirmed Status in pulseaudio package in Ubuntu: Confirmed Bug description: After the announcements of PulseAudio 15 and Gstreamer 1.20, which both advertised LDAC and AptX (HD) support, I expected that jammy (22.04) would support those codecs. Though in reality it seems that something is missing, gstreamer reports that those codecs are supported but "pactl [...] list-codec" only lists sbc (and variants). Checking here https://packages.ubuntu.com/jammy/pulseaudio-module- bluetooth it seems that PulseAudio is not built with gstreamer support, is that the current blocker? To manage notifications about this bug go to: https://bugs.launchpad.net/pulseaudio/+bug/1960307/+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 1960307] Re: No gstreamer dependency causes high-fidelity codecs to be missing for Bluetooth devices
** Also affects: gstreamer1.0 (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1960307 Title: No gstreamer dependency causes high-fidelity codecs to be missing for Bluetooth devices Status in gst-plugins-bad1.0 package in Ubuntu: Confirmed Status in gstreamer1.0 package in Ubuntu: New Status in pulseaudio package in Ubuntu: Confirmed Bug description: After the announcements of PulseAudio 15 and Gstreamer 1.20, which both advertised LDAC and AptX (HD) support, I expected that jammy (22.04) would support those codecs. Though in reality it seems that something is missing, gstreamer reports that those codecs are supported but "pactl [...] list-codec" only lists sbc (and variants). Checking here https://packages.ubuntu.com/jammy/pulseaudio-module- bluetooth it seems that PulseAudio is not built with gstreamer support, is that the current blocker? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gst-plugins-bad1.0/+bug/1960307/+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 1960307] [NEW] No gstreamer dependency causes high-fidelity codecs to be missing for Bluetooth devices
Public bug reported: After the announcements of PulseAudio 15 and Gstreamer 1.20, which both advertised LDAC and AptX (HD) support, I expected that jammy (22.04) would support those codecs. Though in reality it seems that something is missing, gstreamer reports that those codecs are supported but "pactl [...] list-codec" only lists sbc (and variants). Checking here https://packages.ubuntu.com/jammy/pulseaudio-module- bluetooth it seems that PulseAudio is not built with gstreamer support, is that the current blocker? ** Affects: gst-plugins-bad1.0 (Ubuntu) Importance: Undecided Status: New ** Affects: pulseaudio (Ubuntu) Importance: Undecided Status: New ** Also affects: gst-plugins-bad1.0 (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1960307 Title: No gstreamer dependency causes high-fidelity codecs to be missing for Bluetooth devices Status in gst-plugins-bad1.0 package in Ubuntu: New Status in pulseaudio package in Ubuntu: New Bug description: After the announcements of PulseAudio 15 and Gstreamer 1.20, which both advertised LDAC and AptX (HD) support, I expected that jammy (22.04) would support those codecs. Though in reality it seems that something is missing, gstreamer reports that those codecs are supported but "pactl [...] list-codec" only lists sbc (and variants). Checking here https://packages.ubuntu.com/jammy/pulseaudio-module- bluetooth it seems that PulseAudio is not built with gstreamer support, is that the current blocker? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gst-plugins-bad1.0/+bug/1960307/+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 1914918] Re: The snap being updated in the background causes both old and new tabs to die to SIGTRAP
> I've seen no problems for last 5 days, while before, I had to restart browser every couple hours. Similar experience here with refresh-app-awareness + no robust-mount- namespace-updates. One problem I did see was related to audio output breaking. Restart fixed it. Might just be a Chromium anomaly I wouldn't attribute to snap. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1914918 Title: The snap being updated in the background causes both old and new tabs to die to SIGTRAP Status in chromium-browser package in Ubuntu: Confirmed Status in snapd package in Ubuntu: Confirmed Bug description: The last few background updates of chromium have made some old tabs suddenly crash with SIGTRAP and it also makes it impossible to open new tabs, those die instantly with a SIGTRAP as well. This is incredibly destructive to whatever might be the dying tabs' unsaved state and there's no warning about it. Yet again a snap- related change rolled out to users with absolutely amateur-tier testing. Ubuntu: 20.04.2 Snap: 2.48+20.04 Chromium: 88.0.4324.150 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1914918/+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 1914918] Re: The snap being updated in the background causes both old and new tabs to die to SIGTRAP
Ran it, will report back how it affects behaviour, thanks. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1914918 Title: The snap being updated in the background causes both old and new tabs to die to SIGTRAP Status in chromium-browser package in Ubuntu: Confirmed Status in snapd package in Ubuntu: New Bug description: The last few background updates of chromium have made some old tabs suddenly crash with SIGTRAP and it also makes it impossible to open new tabs, those die instantly with a SIGTRAP as well. This is incredibly destructive to whatever might be the dying tabs' unsaved state and there's no warning about it. Yet again a snap- related change rolled out to users with absolutely amateur-tier testing. Ubuntu: 20.04.2 Snap: 2.48+20.04 Chromium: 88.0.4324.150 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1914918/+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 1914918] Re: The snap being updated in the background causes both old and new tabs to die to SIGTRAP
There are no good workarounds either, it observably causes anomalies in apps. Some PWAs lose their state after a restart and it's infuriating. Canonical should dogfood their own known breaking changes. ** Also affects: snapd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1914918 Title: The snap being updated in the background causes both old and new tabs to die to SIGTRAP Status in chromium-browser package in Ubuntu: Confirmed Status in snapd package in Ubuntu: New Bug description: The last few background updates of chromium have made some old tabs suddenly crash with SIGTRAP and it also makes it impossible to open new tabs, those die instantly with a SIGTRAP as well. This is incredibly destructive to whatever might be the dying tabs' unsaved state and there's no warning about it. Yet again a snap- related change rolled out to users with absolutely amateur-tier testing. Ubuntu: 20.04.2 Snap: 2.48+20.04 Chromium: 88.0.4324.150 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1914918/+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 1914918] [NEW] The snap being updated in the background causes both old and new tabs to die to SIGTRAP
Public bug reported: The last few background updates of chromium have made some old tabs suddenly crash with SIGTRAP and it also makes it impossible to open new tabs, those die instantly with a SIGTRAP as well. This is incredibly destructive to whatever might be the dying tabs' unsaved state and there's no warning about it. Yet again a snap-related change rolled out to users with absolutely amateur-tier testing. Ubuntu: 20.04.2 Snap: 2.48+20.04 Chromium: 88.0.4324.150 ** Affects: chromium-browser (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1914918 Title: The snap being updated in the background causes both old and new tabs to die to SIGTRAP Status in chromium-browser package in Ubuntu: New Bug description: The last few background updates of chromium have made some old tabs suddenly crash with SIGTRAP and it also makes it impossible to open new tabs, those die instantly with a SIGTRAP as well. This is incredibly destructive to whatever might be the dying tabs' unsaved state and there's no warning about it. Yet again a snap- related change rolled out to users with absolutely amateur-tier testing. Ubuntu: 20.04.2 Snap: 2.48+20.04 Chromium: 88.0.4324.150 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1914918/+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 1900679] Re: [snap] Apparmor audit messages for calls to sched_setaffinity
Ubuntu 20.04.1 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1900679 Title: [snap] Apparmor audit messages for calls to sched_setaffinity Status in chromium-browser package in Ubuntu: Confirmed Status in snapd package in Ubuntu: Incomplete Bug description: [T okt 20 12:25:09 2020] audit: type=1326 audit(1603185912.099:210734): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:09 2020] audit: type=1326 audit(1603185912.099:210735): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:12 2020] audit: type=1326 audit(1603185915.095:210736): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:12 2020] audit: type=1326 audit(1603185915.095:210737): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:14 2020] audit: type=1326 audit(1603185917.419:210738): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:14 2020] audit: type=1326 audit(1603185917.419:210739): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 Things like these just get repeated endlessly and very often, making any potential debugging very annoying. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1900679/+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 1900679] Re: [snap] chromium spams dmesg
I see sched_setaffinity also used in base/cpu_affinity_posix.cc, so I doubt it's only beneficial on ARM. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1900679 Title: [snap] chromium spams dmesg Status in chromium-browser package in Ubuntu: New Status in snapd package in Ubuntu: Incomplete Bug description: [T okt 20 12:25:09 2020] audit: type=1326 audit(1603185912.099:210734): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:09 2020] audit: type=1326 audit(1603185912.099:210735): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:12 2020] audit: type=1326 audit(1603185915.095:210736): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:12 2020] audit: type=1326 audit(1603185915.095:210737): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:14 2020] audit: type=1326 audit(1603185917.419:210738): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:14 2020] audit: type=1326 audit(1603185917.419:210739): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 Things like these just get repeated endlessly and very often, making any potential debugging very annoying. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1900679/+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 1900679] Re: [snap] chromium spams dmesg
> @avamander, do you have a reproducer for this? I'm just using it on a Ryzen 9 3900x and Radeon R7 360. I have GPU acceleration enabled to the extent it is possible. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1900679 Title: [snap] chromium spams dmesg Status in chromium-browser package in Ubuntu: New Status in snapd package in Ubuntu: Incomplete Bug description: [T okt 20 12:25:09 2020] audit: type=1326 audit(1603185912.099:210734): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:09 2020] audit: type=1326 audit(1603185912.099:210735): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:12 2020] audit: type=1326 audit(1603185915.095:210736): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:12 2020] audit: type=1326 audit(1603185915.095:210737): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:14 2020] audit: type=1326 audit(1603185917.419:210738): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:14 2020] audit: type=1326 audit(1603185917.419:210739): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 Things like these just get repeated endlessly and very often, making any potential debugging very annoying. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1900679/+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 1887804] Re: chromium-browser does not follow XDG base directory specification
@~malakai1197 You're out of luck really, switch distributions that don't use half- baked snaps. Maintainers think that this usability regression is an "opinion" and that tells really more than enough. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1887804 Title: chromium-browser does not follow XDG base directory specification Status in Chromium Browser: Invalid Status in chromium-browser package in Ubuntu: Opinion Bug description: Currently Chromium does not follow the XDG base directory specification which means that the cache and configuration folder aren't properly used. This causes the issue that it's nearly impossible to properly migrate or back up Chromium configuration (between computers) and it makes for example mounting cache as tmpfs or wiping it very very difficult. I felt those both immensely when trying to migrate my home folder, gigabytes of cache in ~/snap/chromium/[id]/.config/chromium/[folder] (and ~/snap itself is also not XDG base directory specification compliant, shame!). There's also the issue that the previous configuration that is located properly, isn't migrated by the migrational package. In order to fix this bug, it would require making the snap package follow the XDG base directory specification. To manage notifications about this bug go to: https://bugs.launchpad.net/chromium-browser/+bug/1887804/+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 1900679] Re: [snap] chromium spams dmesg
[pid 1278569] sched_setaffinity(1278640, 128, [18, 19, 20, 21, 22, 23] [pid 1278569] <... sched_setaffinity resumed>) = -1 EPERM (Operation not permitted) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1900679 Title: [snap] chromium spams dmesg Status in chromium-browser package in Ubuntu: New Status in snapd package in Ubuntu: Incomplete Bug description: [T okt 20 12:25:09 2020] audit: type=1326 audit(1603185912.099:210734): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:09 2020] audit: type=1326 audit(1603185912.099:210735): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:12 2020] audit: type=1326 audit(1603185915.095:210736): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:12 2020] audit: type=1326 audit(1603185915.095:210737): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:14 2020] audit: type=1326 audit(1603185917.419:210738): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:14 2020] audit: type=1326 audit(1603185917.419:210739): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 Things like these just get repeated endlessly and very often, making any potential debugging very annoying. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1900679/+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 1900679] Re: [snap] chromium spams dmesg
[pid 1278591] sched_setaffinity(1278591, 128, [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217, 218, 219, 220, 221, 222, 223, 224, 225, 226, 227, 228, 229, 230, 231, 232, 233, 234, 235, 236, 237, 238, 239, 240, 241, 242, 243, 244, 245, 246, 247, 248, 249, 250, 251, 252, 253, 254, 255, 256, 257, 258, 259, 260, 261, 262, 263, 264, 265, 266, 267, 268, 269, 270, 271, 272, 273, 274, 275, 276, 277, 278, 279, 280, 281, 282, 283, 284, 285, 286, 287, 288, 289, 290, 291, 292, 293, 294, 295, 296, 297, 298, 299, 300, 301, 302, 303, 304, 305, 306, 307, 308, 309, 310, 311, 312, 313, 314, 315, 316, 317, 318, 319, 320, 321, 322, 323, 324, 325, 326, 327, 328, 329, 330, 331, 332, 333, 334, 335, 336, 337, 338, 339, 340, 341, 342, 343, 344, 345, 346, 347, 348, 349, 350, 351, 352, 353, 354, 355, 356, 357, 358, 359, 360, 361, 362, 363, 364, 365, 366, 367, 368, 369, 370, 371, 372, 373, 374, 375, 376, 377, 378, 379, 380, 381, 382, 383, 384, 385, 386, 387, 388, 389, 390, 391, 392, 393, 394, 395, 396, 397, 398, 399, 400, 401, 402, 403, 404, 405, 406, 407, 408, 409, 410, 411, 412, 413, 414, 415, 416, 417, 418, 419, 420, 421, 422, 423, 424, 425, 426, 427, 428, 429, 430, 431, 432, 433, 434, 435, 436, 437, 438, 439, 440, 441, 442, 443, 444, 445, 446, 447, 448, 449, 450, 451, 452, 453, 454, 455, 456, 457, 458, 459, 460, 461, 462, 463, 464, 465, 466, 467, 468, 469, 470, 471, 472, 473, 474, 475, 476, 477, 478, 479, 480, 481, 482, 483, 484, 485, 486, 487, 488, 489, 490, 491, 492, 493, 494, 495, 496, 497, 498, 499, 500, 501, 502, 503, 504, 505, 506, 507, 508, 509, 510, 511, 512, 513, 514, 515, 516, 517, 518, 519, 520, 521, 522, 523, 524, 525, 526, 527, 528, 529, 530, 531, 532, 533, 534, 535, 536, 537, 538, 539, 540, 541, 542, 543, 544, 545, 546, 547, 548, 549, 550, 551, 552, 553, 554, 555, 556, 557, 558, 559, 560, 561, 562, 563, 564, 565, 566, 567, 568, 569, 570, 571, 572, 573, 574, 575, 576, 577, 578, 579, 580, 581, 582, 583, 584, 585, 586, 587, 588, 589, 590, 591, 592, 593, 594, 595, 596, 597, 598, 599, 600, 601, 602, 603, 604, 605, 606, 607, 608, 609, 610, 611, 612, 613, 614, 615, 616, 617, 618, 619, 620, 621, 622, 623, 624, 625, 626, 627, 628, 629, 630, 631, 632, 633, 634, 635, 636, 637, 638, 639, 640, 641, 642, 643, 644, 645, 646, 647, 648, 649, 650, 651, 652, 653, 654, 655, 656, 657, 658, 659, 660, 661, 662, 663, 664, 665, 666, 667, 668, 669, 670, 671, 672, 673, 674, 675, 676, 677, 678, 679, 680, 681, 682, 683, 684, 685, 686, 687, 688, 689, 690, 691, 692, 693, 694, 695, 696, 697, 698, 699, 700, 701, 702, 703, 704, 705, 706, 707, 708, 709, 710, 711, 712, 713, 714, 715, 716, 717, 718, 719, 720, 721, 722, 723, 724, 725, 726, 727, 728, 729, 730, 731, 732, 733, 734, 735, 736, 737, 738, 739, 740, 741, 742, 743, 744, 745, 746, 747, 748, 749, 750, 751, 752, 753, 754, 755, 756, 757, 758, 759, 760, 761, 762, 763, 764, 765, 766, 767, 768, 769, 770, 771, 772, 773, 774, 775, 776, 777, 778, 779, 780, 781, 782, 783, 784, 785, 786, 787, 788, 789, 790, 791, 792, 793, 794, 795, 796, 797, 798, 799, 800, 801, 802, 803, 804, 805, 806, 807, 808, 809, 810, 811, 812, 813, 814, 815, 816, 817, 818, 819, 820, 821, 822, 823, 824, 825, 826, 827, 828, 829, 830, 831, 832, 833, 834, 835, 836, 837, 838, 839, 840, 841, 842, 843, 844, 845, 846, 847, 848, 849, 850, 851, 852, 853, 854, 855, 856, 857, 858, 859, 860, 861, 862, 863, 864, 865, 866, 867, 868, 869, 870, 871, 872, 873, 874, 875, 876, 877, 878, 879, 880, 881, 882, 883, 884, 885, 886, 887, 888, 889, 890, 891, 892, 893, 894, 895, 896, 897, 898, 899, 900, 901, 902, 903, 904, 905, 906, 907, 908, 909, 910, 911, 912, 913, 914, 915, 916, 917, 918, 919, 920, 921, 922, 923, 924, 925, 926, 927, 928, 929, 930, 931, 932, 933, 934, 935, 936, 937, 938, 939, 940, 941, 942, 943, 944, 945, 946, 947, 948, 949, 950, 951, 952, 953, 954, 955, 956, 957, 958, 959, 960, 961, 962, 963, 964, 965, 966, 967, 968, 969, 970, 971, 972, 973, 974, 975, 976, 977, 978, 979, 980, 981, 982, 983, 984, 985, 986, 987, 988, 989, 990, 991, 992, 993, 994, 995, 996, 997, 998, 999, 1
[Desktop-packages] [Bug 1900679] Re: [snap] chromium spams dmesg
> Can someone who is experiencing this bug run an strace to determine what argument chromium is trying to use with sched_setaffinity ? I'm not sure how its possible to strace a snap container ran under a specific user. Could you provide the command? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1900679 Title: [snap] chromium spams dmesg Status in chromium-browser package in Ubuntu: New Status in snapd package in Ubuntu: Incomplete Bug description: [T okt 20 12:25:09 2020] audit: type=1326 audit(1603185912.099:210734): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:09 2020] audit: type=1326 audit(1603185912.099:210735): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:12 2020] audit: type=1326 audit(1603185915.095:210736): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:12 2020] audit: type=1326 audit(1603185915.095:210737): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:14 2020] audit: type=1326 audit(1603185917.419:210738): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:14 2020] audit: type=1326 audit(1603185917.419:210739): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 Things like these just get repeated endlessly and very often, making any potential debugging very annoying. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1900679/+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 1900679] Re: [snap] chromium spams dmesg
It doesn't break it visibly. I would prefer if it were allowed to set its affinity, but if that can't be done, silencing is a must. This is incredibly spammy. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1900679 Title: [snap] chromium spams dmesg Status in chromium-browser package in Ubuntu: New Status in snapd package in Ubuntu: Incomplete Bug description: [T okt 20 12:25:09 2020] audit: type=1326 audit(1603185912.099:210734): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:09 2020] audit: type=1326 audit(1603185912.099:210735): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:12 2020] audit: type=1326 audit(1603185915.095:210736): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:12 2020] audit: type=1326 audit(1603185915.095:210737): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:14 2020] audit: type=1326 audit(1603185917.419:210738): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:14 2020] audit: type=1326 audit(1603185917.419:210739): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 Things like these just get repeated endlessly and very often, making any potential debugging very annoying. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1900679/+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 1900679] Re: [snap] chromium spams dmesg
The rulesets still don't explicitly forbid this syscall and it still gets massively logged into dmesg, making it totally unusable. ``` audit: type=1326 audit(1610482813.754:1835962): auid=1000 uid=1000 gid=1000 ses=4 pid=2201984 comm="chrome" exe="/snap/chromium/1444/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f1190d36c7f code=0x5 ``` Current Chromium snap AppArmor profile needs fixing, this level of logging is not okay. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1900679 Title: [snap] chromium spams dmesg Status in chromium-browser package in Ubuntu: New Status in snapd package in Ubuntu: New Bug description: [T okt 20 12:25:09 2020] audit: type=1326 audit(1603185912.099:210734): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:09 2020] audit: type=1326 audit(1603185912.099:210735): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:12 2020] audit: type=1326 audit(1603185915.095:210736): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:12 2020] audit: type=1326 audit(1603185915.095:210737): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:14 2020] audit: type=1326 audit(1603185917.419:210738): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:14 2020] audit: type=1326 audit(1603185917.419:210739): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 Things like these just get repeated endlessly and very often, making any potential debugging very annoying. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1900679/+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 1900679] Re: snap chromium spams dmesg
Your rulesets are bad, it's not apparmor's fault. ** Changed in: chromium-browser (Ubuntu) Status: Invalid => New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1900679 Title: snap chromium spams dmesg Status in chromium-browser package in Ubuntu: New Status in snap package in Ubuntu: New Bug description: [T okt 20 12:25:09 2020] audit: type=1326 audit(1603185912.099:210734): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:09 2020] audit: type=1326 audit(1603185912.099:210735): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:12 2020] audit: type=1326 audit(1603185915.095:210736): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:12 2020] audit: type=1326 audit(1603185915.095:210737): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:14 2020] audit: type=1326 audit(1603185917.419:210738): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:14 2020] audit: type=1326 audit(1603185917.419:210739): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 Things like these just get repeated endlessly and very often, making any potential debugging very annoying. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1900679/+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 1900679] [NEW] snap chromium spams dmesg
Public bug reported: [T okt 20 12:25:09 2020] audit: type=1326 audit(1603185912.099:210734): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:09 2020] audit: type=1326 audit(1603185912.099:210735): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:12 2020] audit: type=1326 audit(1603185915.095:210736): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:12 2020] audit: type=1326 audit(1603185915.095:210737): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:14 2020] audit: type=1326 audit(1603185917.419:210738): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:14 2020] audit: type=1326 audit(1603185917.419:210739): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 Things like these just get repeated endlessly and very often, making any potential debugging very annoying. ** Affects: chromium-browser (Ubuntu) Importance: Undecided Status: New ** Affects: snap (Ubuntu) Importance: Undecided Status: New ** Also affects: chromium (Ubuntu) Importance: Undecided Status: New ** No longer affects: chromium (Ubuntu) ** Also affects: chromium-browser (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1900679 Title: snap chromium spams dmesg Status in chromium-browser package in Ubuntu: New Status in snap package in Ubuntu: New Bug description: [T okt 20 12:25:09 2020] audit: type=1326 audit(1603185912.099:210734): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:09 2020] audit: type=1326 audit(1603185912.099:210735): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:12 2020] audit: type=1326 audit(1603185915.095:210736): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:12 2020] audit: type=1326 audit(1603185915.095:210737): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:14 2020] audit: type=1326 audit(1603185917.419:210738): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 [T okt 20 12:25:14 2020] audit: type=1326 audit(1603185917.419:210739): auid=1000 uid=1000 gid=1000 ses=3 pid=53766 comm="chrome" exe="/snap/chromium/1350/usr/lib/chromium-browser/chrome" sig=0 arch=c03e syscall=203 compat=0 ip=0x7f46a3f19b9f code=0x5 Things like these just get repeated endlessly and very often, making any potential debugging very annoying. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1900679/+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 1892093] Re: mem_encrypt=on makes radeon driver crash during startup
Dmesg output of encountering non-working graphics ** Attachment added: "dmesg2" https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/1892093/+attachment/5402600/+files/dmesg2 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xserver-xorg-video-ati in Ubuntu. https://bugs.launchpad.net/bugs/1892093 Title: mem_encrypt=on makes radeon driver crash during startup Status in xserver-xorg-video-ati package in Ubuntu: New Bug description: lspci output: 08:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Bonaire XTX [Radeon R7 260X/360] [1002:6658] dmesg error output: [drm:cik_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x3010C)=0xCAFEDEAD) radeon :08:00.0: disabling GPU acceleration kernel parameters with issue: quiet splash amd_iommu=on mem_encrypt=on Issue appears on kernels 5.4.0-26-generic 5.4.0-40-generic 5.4.0-42-generic 5.6.0-1021-oem To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/1892093/+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 1892093] [NEW] mem_encrypt=on makes radeon driver crash during startup
Public bug reported: lspci output: 08:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Bonaire XTX [Radeon R7 260X/360] [1002:6658] dmesg error output: [drm:cik_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x3010C)=0xCAFEDEAD) radeon :08:00.0: disabling GPU acceleration kernel parameters with issue: quiet splash amd_iommu=on mem_encrypt=on Issue appears on kernels 5.4.0-26-generic 5.4.0-40-generic 5.4.0-42-generic 5.6.0-1021-oem ** Affects: xserver-xorg-video-ati (Ubuntu) Importance: Undecided Status: New ** Package changed: ubuntu => xserver-xorg-video-ati (Ubuntu) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xserver-xorg-video-ati in Ubuntu. https://bugs.launchpad.net/bugs/1892093 Title: mem_encrypt=on makes radeon driver crash during startup Status in xserver-xorg-video-ati package in Ubuntu: New Bug description: lspci output: 08:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Bonaire XTX [Radeon R7 260X/360] [1002:6658] dmesg error output: [drm:cik_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x3010C)=0xCAFEDEAD) radeon :08:00.0: disabling GPU acceleration kernel parameters with issue: quiet splash amd_iommu=on mem_encrypt=on Issue appears on kernels 5.4.0-26-generic 5.4.0-40-generic 5.4.0-42-generic 5.6.0-1021-oem To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/1892093/+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 1887804] Re: chromium-browser does not follow XDG base directory specification
> Bug reports should stick to fact, using wording like 'Snap-mangled' I'm sorry, that's factually what happened. Should I have worded it Snap- disfigured, Snap-distorted, Snap-impaired or Snap-wrecked instead? > isn't appropriate and not a basis for any discussion. I have **never** had any software on Linux in the past ten years that has caused this many issues because of the stuff it does, how that behaviour is forced on me and which's developers are **this** dismissive and inappropriate. Issues, some major, have been open for years. You should have enough empathy to understand that users don't take that behaviour very kindly for any significant period of time. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1887804 Title: chromium-browser does not follow XDG base directory specification Status in Chromium Browser: Invalid Status in chromium-browser package in Ubuntu: Opinion Bug description: Currently Chromium does not follow the XDG base directory specification which means that the cache and configuration folder aren't properly used. This causes the issue that it's nearly impossible to properly migrate or back up Chromium configuration (between computers) and it makes for example mounting cache as tmpfs or wiping it very very difficult. I felt those both immensely when trying to migrate my home folder, gigabytes of cache in ~/snap/chromium/[id]/.config/chromium/[folder] (and ~/snap itself is also not XDG base directory specification compliant, shame!). There's also the issue that the previous configuration that is located properly, isn't migrated by the migrational package. In order to fix this bug, it would require making the snap package follow the XDG base directory specification. To manage notifications about this bug go to: https://bugs.launchpad.net/chromium-browser/+bug/1887804/+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 1887804] Re: chromium-browser does not follow XDG base directory specification
Just to be sure you didn't miss a few facts here as you really like to rub it under people's noses: * Snap mangles Chromium's configuration directory * Snap-mangled Chromium configuration directory is not backupable * Snap-mangled Chromium configuration directory is not compliant with the de facto interpretation of XDG-BD specification * Snap-mangled Chromium configuration directory is not compliant with the spirit of the XDG-BD specification * Snap-mangled Chromium configuration directory is unnecessarily not portable between distributions because it assumes the existence of snap I see a common denominator here - snap's mangling that should really not be done. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1887804 Title: chromium-browser does not follow XDG base directory specification Status in Chromium Browser: New Status in chromium-browser package in Ubuntu: New Bug description: Currently Chromium does not follow the XDG base directory specification which means that the cache and configuration folder aren't properly used. This causes the issue that it's nearly impossible to properly migrate or back up Chromium configuration (between computers) and it makes for example mounting cache as tmpfs or wiping it very very difficult. I felt those both immensely when trying to migrate my home folder, gigabytes of cache in ~/snap/chromium/[id]/.config/chromium/[folder] (and ~/snap itself is also not XDG base directory specification compliant, shame!). There's also the issue that the previous configuration that is located properly, isn't migrated by the migrational package. In order to fix this bug, it would require making the snap package follow the XDG base directory specification. To manage notifications about this bug go to: https://bugs.launchpad.net/chromium-browser/+bug/1887804/+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 1887804] Re: chromium-browser does not follow XDG base directory specification
> Anything else has little objective value. That's just your opinion. > That's not an assumption, it's a fact: https://snapcraft.io/docs /installing-snapd. It's an assumption, there are a lot of distributions that stay away from snap. > Most (average) users don't care about packaging formats at all (nor do they care where software stores their cache/config, for that matter). That's just your opinion and really not up to you to decide. > That's just your opinion/perception. That's really just your opinion. > I'm marking again this bug as a duplicate of bug #1575053. It's not! The location of the snap directory is totally separate from where chromium's configuration is stored. ** This bug is no longer a duplicate of bug 1575053 Please move the "$HOME/snap" directory to a less obtrusive location -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1887804 Title: chromium-browser does not follow XDG base directory specification Status in Chromium Browser: New Status in chromium-browser package in Ubuntu: New Bug description: Currently Chromium does not follow the XDG base directory specification which means that the cache and configuration folder aren't properly used. This causes the issue that it's nearly impossible to properly migrate or back up Chromium configuration (between computers) and it makes for example mounting cache as tmpfs or wiping it very very difficult. I felt those both immensely when trying to migrate my home folder, gigabytes of cache in ~/snap/chromium/[id]/.config/chromium/[folder] (and ~/snap itself is also not XDG base directory specification compliant, shame!). There's also the issue that the previous configuration that is located properly, isn't migrated by the migrational package. In order to fix this bug, it would require making the snap package follow the XDG base directory specification. To manage notifications about this bug go to: https://bugs.launchpad.net/chromium-browser/+bug/1887804/+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 1887804] Re: chromium-browser does not follow XDG base directory specification
> I don't think the specification¹ mandates how folders should be structured under $XDG_DATA_HOME and $XDG_CONFIG_HOME. `$XDG_CONFIG_HOME/$SOFTWARE_NAME` is the de facto way, snap ignores it. Technically, yes, you're absolutely free to use hashes instead of your software's name when you store things in the configuration folder, really doesn't mean it's a good idea. > Hopefully snapd behaves (mostly) the same on all supported distributions, so distro-hopping shouldn't be a concern either. You're making three assumptions. That snap will behave the same across distributions, that snap is supported on different distributions at all, and that someone even wants to install the snap package. All of them are frankly really bad assumptions and just cause people pain. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1887804 Title: chromium-browser does not follow XDG base directory specification Status in Chromium Browser: New Status in chromium-browser package in Ubuntu: New Bug description: Currently Chromium does not follow the XDG base directory specification which means that the cache and configuration folder aren't properly used. This causes the issue that it's nearly impossible to properly migrate or back up Chromium configuration (between computers) and it makes for example mounting cache as tmpfs or wiping it very very difficult. I felt those both immensely when trying to migrate my home folder, gigabytes of cache in ~/snap/chromium/[id]/.config/chromium/[folder] (and ~/snap itself is also not XDG base directory specification compliant, shame!). There's also the issue that the previous configuration that is located properly, isn't migrated by the migrational package. In order to fix this bug, it would require making the snap package follow the XDG base directory specification. To manage notifications about this bug go to: https://bugs.launchpad.net/chromium-browser/+bug/1887804/+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 1887804] Re: chromium-browser does not follow XDG base directory specification
> How so? The actual software of which the configuration belongs to is chromium (or "notes"), not snap, snap is "just there" in the middle. Say I want to wipe snap's configuration, I should be able to wipe `$XDG_DATA_HOME/snap` without losing my n+1 snap application's data. Very simply put, `$XDG_DATA_HOME/snap` is for snap, `$XDG_DATA_HOME/chromium` is for chromium. It would be equally silly to have i386 software use ``$XDG_DATA_HOME/i386/software`. Thirdly, it creates a discrepancy in configuration folder location between distributions, which is pointlessly annoying and hinders distro- hopping. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1887804 Title: chromium-browser does not follow XDG base directory specification Status in Chromium Browser: New Status in chromium-browser package in Ubuntu: New Bug description: Currently Chromium does not follow the XDG base directory specification which means that the cache and configuration folder aren't properly used. This causes the issue that it's nearly impossible to properly migrate or back up Chromium configuration (between computers) and it makes for example mounting cache as tmpfs or wiping it very very difficult. I felt those both immensely when trying to migrate my home folder, gigabytes of cache in ~/snap/chromium/[id]/.config/chromium/[folder] (and ~/snap itself is also not XDG base directory specification compliant, shame!). There's also the issue that the previous configuration that is located properly, isn't migrated by the migrational package. In order to fix this bug, it would require making the snap package follow the XDG base directory specification. To manage notifications about this bug go to: https://bugs.launchpad.net/chromium-browser/+bug/1887804/+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 1887804] Re: chromium-browser does not follow XDG base directory specification
> Therefore snap packages should base the value of SNAP_USER_DATA on the value of XDG_DATA_HOME (or its specified default). For the "notes" snap, this would be "$HOME/.local/share/snap/notes/1". That's still incorrect. > As to comment #6, can you elaborate on how you copied the existing profile? Literally just did that, copied the folder over. It didn't work. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1887804 Title: chromium-browser does not follow XDG base directory specification Status in Chromium Browser: New Status in chromium-browser package in Ubuntu: New Bug description: Currently Chromium does not follow the XDG base directory specification which means that the cache and configuration folder aren't properly used. This causes the issue that it's nearly impossible to properly migrate or back up Chromium configuration (between computers) and it makes for example mounting cache as tmpfs or wiping it very very difficult. I felt those both immensely when trying to migrate my home folder, gigabytes of cache in ~/snap/chromium/[id]/.config/chromium/[folder] (and ~/snap itself is also not XDG base directory specification compliant, shame!). There's also the issue that the previous configuration that is located properly, isn't migrated by the migrational package. In order to fix this bug, it would require making the snap package follow the XDG base directory specification. To manage notifications about this bug go to: https://bugs.launchpad.net/chromium-browser/+bug/1887804/+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 1887804] Re: chromium-browser does not follow XDG base directory specification
Oh and I didn't confirm my own bug, that was done by the janitor because someone else felt that this affects them, I just restored the previous status. ** Also affects: chromium-browser Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1887804 Title: chromium-browser does not follow XDG base directory specification Status in Chromium Browser: New Status in chromium-browser package in Ubuntu: New Bug description: Currently Chromium does not follow the XDG base directory specification which means that the cache and configuration folder aren't properly used. This causes the issue that it's nearly impossible to properly migrate or back up Chromium configuration (between computers) and it makes for example mounting cache as tmpfs or wiping it very very difficult. I felt those both immensely when trying to migrate my home folder, gigabytes of cache in ~/snap/chromium/[id]/.config/chromium/[folder] (and ~/snap itself is also not XDG base directory specification compliant, shame!). There's also the issue that the previous configuration that is located properly, isn't migrated by the migrational package. In order to fix this bug, it would require making the snap package follow the XDG base directory specification. To manage notifications about this bug go to: https://bugs.launchpad.net/chromium-browser/+bug/1887804/+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 1887804] Re: chromium-browser does not follow XDG base directory specification
Upstream bug report that would resolve a half of this issue: https://bugs.chromium.org/p/chromium/issues/detail?id=1106754 Just to summarize what's left broken by this specific Ubuntu package: * Config and cache are not in the folders defined by the base directory specification * Current `common`/configuration folder is incomplete - can't be backed up and restored -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1887804 Title: chromium-browser does not follow XDG base directory specification Status in Chromium Browser: New Status in chromium-browser package in Ubuntu: New Bug description: Currently Chromium does not follow the XDG base directory specification which means that the cache and configuration folder aren't properly used. This causes the issue that it's nearly impossible to properly migrate or back up Chromium configuration (between computers) and it makes for example mounting cache as tmpfs or wiping it very very difficult. I felt those both immensely when trying to migrate my home folder, gigabytes of cache in ~/snap/chromium/[id]/.config/chromium/[folder] (and ~/snap itself is also not XDG base directory specification compliant, shame!). There's also the issue that the previous configuration that is located properly, isn't migrated by the migrational package. In order to fix this bug, it would require making the snap package follow the XDG base directory specification. To manage notifications about this bug go to: https://bugs.launchpad.net/chromium-browser/+bug/1887804/+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 1887804] Re: chromium-browser does not follow XDG base directory specification
I also have to repeat that currently, copying over the folder contents you mentioned did NOT result in a working instance of Chromium. All of my extensions broke, databases failed to open, the common folder is just incomplete and needs attention. Please do try it yourself. That absolutely 100% NOT a duplicate of the general snap lunacy. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1887804 Title: chromium-browser does not follow XDG base directory specification Status in Chromium Browser: New Status in chromium-browser package in Ubuntu: New Bug description: Currently Chromium does not follow the XDG base directory specification which means that the cache and configuration folder aren't properly used. This causes the issue that it's nearly impossible to properly migrate or back up Chromium configuration (between computers) and it makes for example mounting cache as tmpfs or wiping it very very difficult. I felt those both immensely when trying to migrate my home folder, gigabytes of cache in ~/snap/chromium/[id]/.config/chromium/[folder] (and ~/snap itself is also not XDG base directory specification compliant, shame!). There's also the issue that the previous configuration that is located properly, isn't migrated by the migrational package. In order to fix this bug, it would require making the snap package follow the XDG base directory specification. To manage notifications about this bug go to: https://bugs.launchpad.net/chromium-browser/+bug/1887804/+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 1887804] Re: chromium-browser does not follow XDG base directory specification
> You're right, it does contain cache data. That would be an upstream bug, can you please file it at https://bugs.chromium.org/p/chromium/issues/entry ? I will > I just found bug #1575053 which looks very similar to your issue, so I'm going to mark it as duplicate, and I encourage you to read all the comments to understand the rationale. They're not duplicates because that one is about moving ~/snap, this one is making the package actually XDG base directory specification compliant. If Snap does not offer basic mount features, then this is also a bug in snapd. ** This bug is no longer a duplicate of bug 1575053 Please move the "$HOME/snap" directory to a less obtrusive location -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1887804 Title: chromium-browser does not follow XDG base directory specification Status in chromium-browser package in Ubuntu: New Bug description: Currently Chromium does not follow the XDG base directory specification which means that the cache and configuration folder aren't properly used. This causes the issue that it's nearly impossible to properly migrate or back up Chromium configuration (between computers) and it makes for example mounting cache as tmpfs or wiping it very very difficult. I felt those both immensely when trying to migrate my home folder, gigabytes of cache in ~/snap/chromium/[id]/.config/chromium/[folder] (and ~/snap itself is also not XDG base directory specification compliant, shame!). There's also the issue that the previous configuration that is located properly, isn't migrated by the migrational package. In order to fix this bug, it would require making the snap package follow the XDG base directory specification. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1887804/+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 1887804] Re: chromium-browser does not follow XDG base directory specification
> The chromium snap is strictly confined, and that means that it cannot read/write to hidden directories inside the user's home folder (such as $HOME/.config or $HOME/.cache). Change the folder it's confined to. > That one is stored in $HOME/chromium/common/.cache/ No, not really. The profile folder contains gigabytes of cache files. > The default profile directory is stored in $HOME/chromium/common/chromium/. No, not really. Copying it over resulted in a utterly broken profile, some vital files are not in the common folder. > Given all this, I'm not really sure what the bug really is about? Can you share concrete use cases? I'm not sure what's unclear, XDG base directory specification is NOT followed, my environment variables are ignored and the wrong folder is used for everything. That has multiple negative effects, as I listed. ** Changed in: chromium-browser (Ubuntu) Status: Incomplete => Confirmed -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1887804 Title: chromium-browser does not follow XDG base directory specification Status in chromium-browser package in Ubuntu: Confirmed Bug description: Currently Chromium does not follow the XDG base directory specification which means that the cache and configuration folder aren't properly used. This causes the issue that it's nearly impossible to properly migrate or back up Chromium configuration (between computers) and it makes for example mounting cache as tmpfs or wiping it very very difficult. I felt those both immensely when trying to migrate my home folder, gigabytes of cache in ~/snap/chromium/[id]/.config/chromium/[folder] (and ~/snap itself is also not XDG base directory specification compliant, shame!). There's also the issue that the previous configuration that is located properly, isn't migrated by the migrational package. In order to fix this bug, it would require making the snap package follow the XDG base directory specification. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1887804/+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 1616650] Re: snap refresh while command is running may cause issues
This issue is related to it and probably both could be fixed at the same time. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1616650 Title: snap refresh while command is running may cause issues Status in snapd: In Progress Status in chromium-browser package in Ubuntu: In Progress Bug description: In testing a desktop snap that saves state in $HOME on close, I noticed that if I snap refresh the snap while the command is running that it will try to save its state to the previous snap version's data directory. For the snap I was testing (a browser), this resulted in a very poor user experience (the browser on restart complained about an improper shutdown). What is happening is that: 1. on launch the snap's HOME is set to SNAP_USER_DATA, which is something like /home/user/snap/foo/x1. The security policy correctly allows writes to SNAP_USER_DATA 2. on snap refresh to 'x2', the security policy for the snap is updated for the running process such that /home/user/snap/foo/x1 is readonly and /home/user/snap/foo/x2 is read/write 3. the command in '1's environment is not changed and HOME (as well as SNAP_USER_DATA and SNAP_DATA) are all still using 'x1' in the path 4. the command tries to shutdown gracefully and save state to the 'x1' HOME and security policy blocks it Snappy's design for rollbacks relies on the previous SNAP_DATA and SNAP_USER_DATA directories not being writable and IMHO we should not change the policy to make other snap version's data dirs writable. The design of the snappy state engine ensures (among other things) that there is only ever one security policy in place for the snap. In snappy 15.04 this problem was (intentionally) avoided because we used snap security policy that was versioned such that the new policy would not apply until the next app invocation. Gustavo and Zygmunt, you both advocated strongly for only one version of the policy on disk and loaded in the kernel and I recall bringing up this type of bug as a counter-argument, and if IIRC for daemons we said that snapd could simply restart them (makes perfect sense). Have you thought of the mechanism for restarting non-daemons? To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1616650/+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 1616650] Re: snap refresh while command is running may cause issues
I opened https://bugs.launchpad.net/ubuntu/+source/chromium- browser/+bug/1887804 to address the fact that chromium-browser-snap is not following XDG base directory specification and that breaks backing up the snap's configuration and wiping it's cache properly. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1616650 Title: snap refresh while command is running may cause issues Status in snapd: In Progress Status in chromium-browser package in Ubuntu: In Progress Bug description: In testing a desktop snap that saves state in $HOME on close, I noticed that if I snap refresh the snap while the command is running that it will try to save its state to the previous snap version's data directory. For the snap I was testing (a browser), this resulted in a very poor user experience (the browser on restart complained about an improper shutdown). What is happening is that: 1. on launch the snap's HOME is set to SNAP_USER_DATA, which is something like /home/user/snap/foo/x1. The security policy correctly allows writes to SNAP_USER_DATA 2. on snap refresh to 'x2', the security policy for the snap is updated for the running process such that /home/user/snap/foo/x1 is readonly and /home/user/snap/foo/x2 is read/write 3. the command in '1's environment is not changed and HOME (as well as SNAP_USER_DATA and SNAP_DATA) are all still using 'x1' in the path 4. the command tries to shutdown gracefully and save state to the 'x1' HOME and security policy blocks it Snappy's design for rollbacks relies on the previous SNAP_DATA and SNAP_USER_DATA directories not being writable and IMHO we should not change the policy to make other snap version's data dirs writable. The design of the snappy state engine ensures (among other things) that there is only ever one security policy in place for the snap. In snappy 15.04 this problem was (intentionally) avoided because we used snap security policy that was versioned such that the new policy would not apply until the next app invocation. Gustavo and Zygmunt, you both advocated strongly for only one version of the policy on disk and loaded in the kernel and I recall bringing up this type of bug as a counter-argument, and if IIRC for daemons we said that snapd could simply restart them (makes perfect sense). Have you thought of the mechanism for restarting non-daemons? To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1616650/+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 1887804] [NEW] chromium-browser does not follow XDG base directory specification
Public bug reported: Currently Chromium does not follow the XDG base directory specification which means that the cache and configuration folder aren't properly used. This causes the issue that it's nearly impossible to properly migrate or back up Chromium configuration (between computers) and it makes for example mounting cache as tmpfs or wiping it very very difficult. I felt those both immensely when trying to migrate my home folder, gigabytes of cache in ~/snap/chromium/[id]/.config/chromium/[folder] (and ~/snap itself is also not XDG base directory specification compliant, shame!). There's also the issue that the previous configuration that is located properly, isn't migrated by the migrational package. In order to fix this bug, it would require making the snap package follow the XDG base directory specification. ** Affects: chromium-browser (Ubuntu) Importance: Undecided Status: New ** Summary changed: - chromium-browser does not follow xdg base directory specification + chromium-browser does not follow XDG base directory specification ** Description changed: Currently Chromium does not follow the XDG base directory specification which means that the cache and configuration folder aren't properly used. This causes the issue that it's nearly impossible to properly migrate or back up Chromium configuration (between computers) and it makes for example mounting cache as tmpfs or wiping it very very difficult. I felt those both immensely when trying to migrate my home folder, - gigabytes of cache in ~/snap (also not XDG base directory specification + gigabytes of cache in ~/snap/chromium/[id]/.config/chromium/[folder] + (and ~/snap itself is also not XDG base directory specification compliant, shame!). There's also the issue that the previous configuration that is located properly, isn't migrated by the migrational package. In order to fix this bug, it would require making the snap package follow the XDG base directory specification. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1887804 Title: chromium-browser does not follow XDG base directory specification Status in chromium-browser package in Ubuntu: New Bug description: Currently Chromium does not follow the XDG base directory specification which means that the cache and configuration folder aren't properly used. This causes the issue that it's nearly impossible to properly migrate or back up Chromium configuration (between computers) and it makes for example mounting cache as tmpfs or wiping it very very difficult. I felt those both immensely when trying to migrate my home folder, gigabytes of cache in ~/snap/chromium/[id]/.config/chromium/[folder] (and ~/snap itself is also not XDG base directory specification compliant, shame!). There's also the issue that the previous configuration that is located properly, isn't migrated by the migrational package. In order to fix this bug, it would require making the snap package follow the XDG base directory specification. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1887804/+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 307152] Re: Get rid of .hplip folder and follow fd.o specifications
Unfortunately this is still a minor problem. It would be nice to not have hplip clutter people's home directories. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to hplip in Ubuntu. https://bugs.launchpad.net/bugs/307152 Title: Get rid of .hplip folder and follow fd.o specifications Status in HPLIP: Triaged Status in hplip package in Ubuntu: Confirmed Bug description: There should not be an .hplip folder in $HOME. According to Freedesktop specification it should be put in $XDG_CONFIG_HOME (if removing this folder will impact the user) or in $XDG_CACHE_HOME (if it's there only for performance reason). Personnally, I don't see any difference if I plug my printer after removing this folder so I suggest that it should be put in $XDG_CACHE_HOME.. If this folder exist to permit some manual tweaks, then it should be put in $XDG_CONFIG_HOME but should not be created automatically. More infos : http://standards.freedesktop.org/basedir-spec/latest/ar01s03.html The reason why I'm reporting this bug : http://ploum.frimouvy.org/?184-cleaning-user-preferences-keeping-user-data To manage notifications about this bug go to: https://bugs.launchpad.net/hplip/+bug/307152/+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 1616650] Re: snap refresh while command is running may cause issues
This is still an issue. The notification is a nice rub of salt in the wound, but doesn't fix the issue. Absolutely inane, I hope whoever decided to turn chromium-browser gets a kernel panic when they're updating their system. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1616650 Title: snap refresh while command is running may cause issues Status in snapd: In Progress Status in chromium-browser package in Ubuntu: Confirmed Bug description: In testing a desktop snap that saves state in $HOME on close, I noticed that if I snap refresh the snap while the command is running that it will try to save its state to the previous snap version's data directory. For the snap I was testing (a browser), this resulted in a very poor user experience (the browser on restart complained about an improper shutdown). What is happening is that: 1. on launch the snap's HOME is set to SNAP_USER_DATA, which is something like /home/user/snap/foo/x1. The security policy correctly allows writes to SNAP_USER_DATA 2. on snap refresh to 'x2', the security policy for the snap is updated for the running process such that /home/user/snap/foo/x1 is readonly and /home/user/snap/foo/x2 is read/write 3. the command in '1's environment is not changed and HOME (as well as SNAP_USER_DATA and SNAP_DATA) are all still using 'x1' in the path 4. the command tries to shutdown gracefully and save state to the 'x1' HOME and security policy blocks it Snappy's design for rollbacks relies on the previous SNAP_DATA and SNAP_USER_DATA directories not being writable and IMHO we should not change the policy to make other snap version's data dirs writable. The design of the snappy state engine ensures (among other things) that there is only ever one security policy in place for the snap. In snappy 15.04 this problem was (intentionally) avoided because we used snap security policy that was versioned such that the new policy would not apply until the next app invocation. Gustavo and Zygmunt, you both advocated strongly for only one version of the policy on disk and loaded in the kernel and I recall bringing up this type of bug as a counter-argument, and if IIRC for daemons we said that snapd could simply restart them (makes perfect sense). Have you thought of the mechanism for restarting non-daemons? To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1616650/+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 1616650] Re: snap refresh while command is running may cause issues
@osomon No, as already said, refresh-app-awareness doesn't work as a solution. I still get unannounced data loss. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1616650 Title: snap refresh while command is running may cause issues Status in snapd: In Progress Status in chromium-browser package in Ubuntu: Confirmed Bug description: In testing a desktop snap that saves state in $HOME on close, I noticed that if I snap refresh the snap while the command is running that it will try to save its state to the previous snap version's data directory. For the snap I was testing (a browser), this resulted in a very poor user experience (the browser on restart complained about an improper shutdown). What is happening is that: 1. on launch the snap's HOME is set to SNAP_USER_DATA, which is something like /home/user/snap/foo/x1. The security policy correctly allows writes to SNAP_USER_DATA 2. on snap refresh to 'x2', the security policy for the snap is updated for the running process such that /home/user/snap/foo/x1 is readonly and /home/user/snap/foo/x2 is read/write 3. the command in '1's environment is not changed and HOME (as well as SNAP_USER_DATA and SNAP_DATA) are all still using 'x1' in the path 4. the command tries to shutdown gracefully and save state to the 'x1' HOME and security policy blocks it Snappy's design for rollbacks relies on the previous SNAP_DATA and SNAP_USER_DATA directories not being writable and IMHO we should not change the policy to make other snap version's data dirs writable. The design of the snappy state engine ensures (among other things) that there is only ever one security policy in place for the snap. In snappy 15.04 this problem was (intentionally) avoided because we used snap security policy that was versioned such that the new policy would not apply until the next app invocation. Gustavo and Zygmunt, you both advocated strongly for only one version of the policy on disk and loaded in the kernel and I recall bringing up this type of bug as a counter-argument, and if IIRC for daemons we said that snapd could simply restart them (makes perfect sense). Have you thought of the mechanism for restarting non-daemons? To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1616650/+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 1616650] Re: snap refresh while command is running may cause issues
Enabled the "refresh-app-awareness", still, without warning Chromium suddenly stops recording history, keeping state and sessions. Incredibly annoying and causes unavoidable data loss. It's is frankly inane to roll out new snaps when it has been known for FOUR. YEARS. that there's a major bug that causes data loss. ** Also affects: chromium-browser (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1616650 Title: snap refresh while command is running may cause issues Status in snapd: In Progress Status in chromium-browser package in Ubuntu: New Bug description: In testing a desktop snap that saves state in $HOME on close, I noticed that if I snap refresh the snap while the command is running that it will try to save its state to the previous snap version's data directory. For the snap I was testing (a browser), this resulted in a very poor user experience (the browser on restart complained about an improper shutdown). What is happening is that: 1. on launch the snap's HOME is set to SNAP_USER_DATA, which is something like /home/user/snap/foo/x1. The security policy correctly allows writes to SNAP_USER_DATA 2. on snap refresh to 'x2', the security policy for the snap is updated for the running process such that /home/user/snap/foo/x1 is readonly and /home/user/snap/foo/x2 is read/write 3. the command in '1's environment is not changed and HOME (as well as SNAP_USER_DATA and SNAP_DATA) are all still using 'x1' in the path 4. the command tries to shutdown gracefully and save state to the 'x1' HOME and security policy blocks it Snappy's design for rollbacks relies on the previous SNAP_DATA and SNAP_USER_DATA directories not being writable and IMHO we should not change the policy to make other snap version's data dirs writable. The design of the snappy state engine ensures (among other things) that there is only ever one security policy in place for the snap. In snappy 15.04 this problem was (intentionally) avoided because we used snap security policy that was versioned such that the new policy would not apply until the next app invocation. Gustavo and Zygmunt, you both advocated strongly for only one version of the policy on disk and loaded in the kernel and I recall bringing up this type of bug as a counter-argument, and if IIRC for daemons we said that snapd could simply restart them (makes perfect sense). Have you thought of the mechanism for restarting non-daemons? To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1616650/+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 1741074] Re: [snap] chrome-gnome-shell extension fails to detect native host connector
** Also affects: kdeconnect (Ubuntu) Importance: Undecided Status: New ** Also affects: goopg (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1741074 Title: [snap] chrome-gnome-shell extension fails to detect native host connector Status in chromium-browser package in Ubuntu: Triaged Status in goopg package in Ubuntu: New Status in kdeconnect package in Ubuntu: New Bug description: (initially reported at https://forum.snapcraft.io/t/chrome-gnome- shell-does-not-work-with-chromium-snap/3377) See attached screenshot. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1741074/+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 1870829] [NEW] AptX and AptX HD unavailable as Bluetooth audio quality options
Public bug reported: Current situation: When one connects a Bluetooth audio device, at best one can choose between "Headset Head Unit (HSP/HFP)" and "High Fidelity Playback (A2DP Sink)". That is sad when the audio device supports AptX or AptX HD. Expected situation: One can select AptX or AptX HD as the Bluetooth audio output profile. ** Affects: pulseaudio (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/1870829 Title: AptX and AptX HD unavailable as Bluetooth audio quality options Status in pulseaudio package in Ubuntu: New Bug description: Current situation: When one connects a Bluetooth audio device, at best one can choose between "Headset Head Unit (HSP/HFP)" and "High Fidelity Playback (A2DP Sink)". That is sad when the audio device supports AptX or AptX HD. Expected situation: One can select AptX or AptX HD as the Bluetooth audio output profile. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1870829/+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 1860137] Re: Chromium-browser Snap is amnesiac
I enabled the flag, still encountered this issue. This time when I restarted Chromium my tabs were lost and restoring previous session just did nothing. Thankfully the extension "Tab Suspender" allowed me to recover my tabs but a few services logged me off. I guess the flag improves situation, thanks for that, but isn't flawless. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1860137 Title: Chromium-browser Snap is amnesiac Status in chromium-browser package in Ubuntu: Incomplete Bug description: I'm using Ubuntu 19.10, latest Chromium(-browser) installed. The issue is that after the switch to snap-based Chromium it started forgetting my logged in sessions very very often. This is not isolated to one online service, I have to log back in to everything I use, including Chromium itself. It also forgets any "Remember this device" checkmarks. History, downloads or extensions however do not suffer from any data loss. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1860137/+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 1741074] Re: [snap] chrome-gnome-shell extension fails to detect native host connector
KDE Connect is also affected by this. I'm wondering though, unable to find the answer online, why was the transition to snap-based chromium made? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1741074 Title: [snap] chrome-gnome-shell extension fails to detect native host connector Status in chromium-browser package in Ubuntu: Triaged Bug description: (initially reported at https://forum.snapcraft.io/t/chrome-gnome- shell-does-not-work-with-chromium-snap/3377) See attached screenshot. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1741074/+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 1860137] Re: Chromium-browser Snap is amnesiac
I enabled the flag, will report back. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1860137 Title: Chromium-browser Snap is amnesiac Status in chromium-browser package in Ubuntu: Incomplete Bug description: I'm using Ubuntu 19.10, latest Chromium(-browser) installed. The issue is that after the switch to snap-based Chromium it started forgetting my logged in sessions very very often. This is not isolated to one online service, I have to log back in to everything I use, including Chromium itself. It also forgets any "Remember this device" checkmarks. History, downloads or extensions however do not suffer from any data loss. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1860137/+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 1860137] [NEW] Chromium-browser Snap is amnesiac
Public bug reported: I'm using Ubuntu 19.10, latest Chromium(-browser) installed. The issue is that after the switch to snap-based Chromium it started forgetting my logged in sessions very very often. This is not isolated to one online service, I have to log back in to everything I use, including Chromium itself. It also forgets any "Remember this device" checkmarks. History, downloads or extensions however do not suffer from any data loss. ** Affects: chromium-browser (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to chromium-browser in Ubuntu. https://bugs.launchpad.net/bugs/1860137 Title: Chromium-browser Snap is amnesiac Status in chromium-browser package in Ubuntu: New Bug description: I'm using Ubuntu 19.10, latest Chromium(-browser) installed. The issue is that after the switch to snap-based Chromium it started forgetting my logged in sessions very very often. This is not isolated to one online service, I have to log back in to everything I use, including Chromium itself. It also forgets any "Remember this device" checkmarks. History, downloads or extensions however do not suffer from any data loss. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1860137/+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 1833793] Re: Updating to 19.04 audio keeps clicking when nothing is playing audio
@hui.wang Your suggestion worked and you saved my sanity. Thank you so much. Could Ubuntu developers please sort out the power saving, so that the sound card actually shuts down instead of continuous clicking (reinitialization?), just for the sake of others on this chipset. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to alsa-driver in Ubuntu. https://bugs.launchpad.net/bugs/1833793 Title: Updating to 19.04 audio keeps clicking when nothing is playing audio Status in alsa-driver package in Ubuntu: Incomplete Bug description: My Ubuntu version: Ubuntu 19.04 My sound card: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02) What I expect to happen: Sound is absolutely quiet when no audio is playing What happens now: Audio output starts clicking every second incredibly annoyingly and loud. What previously happened on Ubuntu 18.10: I heard the click twice during boot and then it worked properly (without clicking during the time it should have been silent) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1833793/+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 1833793] Re: Updating to 19.04 audio keeps clicking when nothing is playing audio
Is this some kind of new power optimization to constantly reinitialize my sound card? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to alsa-driver in Ubuntu. https://bugs.launchpad.net/bugs/1833793 Title: Updating to 19.04 audio keeps clicking when nothing is playing audio Status in alsa-driver package in Ubuntu: New Bug description: My Ubuntu version: Ubuntu 19.04 My sound card: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02) What I expect to happen: Sound is absolutely quiet when no audio is playing What happens now: Audio output starts clicking every second incredibly annoyingly and loud. What previously happened on Ubuntu 18.10: I heard the click twice during boot and then it worked properly (without clicking during the time it should have been silent) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1833793/+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 1833793] Re: Updating to 19.04 audio keeps clicking when nothing is playing audio
It literally doesn't go away, only reliable way is playing something 24/7 just to get Ubuntu to shut the f*** up. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to alsa-driver in Ubuntu. https://bugs.launchpad.net/bugs/1833793 Title: Updating to 19.04 audio keeps clicking when nothing is playing audio Status in alsa-driver package in Ubuntu: New Bug description: My Ubuntu version: Ubuntu 19.04 My sound card: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02) What I expect to happen: Sound is absolutely quiet when no audio is playing What happens now: Audio output starts clicking every second incredibly annoyingly and loud. What previously happened on Ubuntu 18.10: I heard the click twice during boot and then it worked properly (without clicking during the time it should have been silent) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1833793/+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 1833793] Re: Updating to 19.04 audio keeps clicking when nothing is playing audio
This is seriously infuriating, why do I have to keep something playing at 1% volume just for stuff to stay quiet. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to alsa-driver in Ubuntu. https://bugs.launchpad.net/bugs/1833793 Title: Updating to 19.04 audio keeps clicking when nothing is playing audio Status in alsa-driver package in Ubuntu: New Bug description: My Ubuntu version: Ubuntu 19.04 My sound card: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02) What I expect to happen: Sound is absolutely quiet when no audio is playing What happens now: Audio output starts clicking every second incredibly annoyingly and loud. What previously happened on Ubuntu 18.10: I heard the click twice during boot and then it worked properly (without clicking during the time it should have been silent) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1833793/+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 1833793] Re: Updating to 19.04 audio keeps clicking when it should be silent
** Package changed: ubuntu => alsa-driver (Ubuntu) ** Summary changed: - Updating to 19.04 audio keeps clicking when it should be silent + Updating to 19.04 audio keeps clicking when nothing is playing audio ** Description changed: My Ubuntu version: Ubuntu 19.04 My sound card: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02) What I expect to happen: Sound is absolutely quiet when no audio is playing What happens now: - Audio output starts clicking every second incredibly annoyingly and loud. + Audio output starts clicking every second incredibly annoyingly and loud. What previously happened on Ubuntu 18.10: - I heard the click twice during boot and then it worked properly (without clicking all the time) + I heard the click twice during boot and then it worked properly (without clicking during the time it should have been silent the time) ** Description changed: My Ubuntu version: Ubuntu 19.04 My sound card: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02) What I expect to happen: Sound is absolutely quiet when no audio is playing What happens now: Audio output starts clicking every second incredibly annoyingly and loud. What previously happened on Ubuntu 18.10: - I heard the click twice during boot and then it worked properly (without clicking during the time it should have been silent the time) + I heard the click twice during boot and then it worked properly (without clicking during the time it should have been silent) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to alsa-driver in Ubuntu. https://bugs.launchpad.net/bugs/1833793 Title: Updating to 19.04 audio keeps clicking when nothing is playing audio Status in alsa-driver package in Ubuntu: New Bug description: My Ubuntu version: Ubuntu 19.04 My sound card: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02) What I expect to happen: Sound is absolutely quiet when no audio is playing What happens now: Audio output starts clicking every second incredibly annoyingly and loud. What previously happened on Ubuntu 18.10: I heard the click twice during boot and then it worked properly (without clicking during the time it should have been silent) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1833793/+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