[Bug 1872255] Re: mate-tweak doesn't save custom panels correctly 20.04 beta
Sorry Wimpy - I just did fresh installs of two machines with 20.04.4, and the bug triggered on one of them, i.e. the fix is incomplete. Examining the .panel and .layout files in pluma, I can see that the problem element (mate-control-center) is listed in the files twice (elements 2 and 15) - which is "correct", in that I had to add it a second time because the panel failed to show it after the first reboot - but removing the second instance (via the UI) means that on the next reboot the element isn't displayed at all, UNTIL another item (of any type) is added to the panel. If that "new" item is a duplicate, then the same "either 0 or 2, but never 1" bug triggers again, repeat ad infinitum. ISTR a very detailed breakdown of this a few years ago in the UM forums here: https://ubuntu-mate.community/t/19-10-loading-saving-custom-panel- layouts-is-utterly-broken/20340/10 which I think certainly provides everything one could ever want to know about the *bug*, but obv doesn't provide the solution. add> To be clear, this is not a multi-monitor issue: both of today's machines are laptops with a single inbuilt screen and no external display. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1872255 Title: mate-tweak doesn't save custom panels correctly 20.04 beta To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mate-tweak/+bug/1872255/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1845822] Re: marco / mate-session-restore misplaces windows
wb. :) I'll try to tackle it, but my health's not that great right now. IMO one should really prioritize fixing "easy" bugs ahead of doing massive rewrites to things, but you don't work for me, so... :) The bug's already made it into one LTS. It would be pretty ridiculous for it to still be there in 22.04 as well. But we'll see how it goes. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1845822 Title: marco / mate-session-restore misplaces windows To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/marco/+bug/1845822/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1845822] Re: marco / mate-session-restore misplaces windows
I take it Victor is no longer involved with the project. For whoever picks this up: when I discussed this with him at the time, he knew exactly what had caused the bug: he'd "hacked the window borders wider so that they could still be grabbed properly after gtk3 broke that" - I assume by padding the bounding rect etc - but wasn't adjusting them back from that when saving them for session restore. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1845822 Title: marco / mate-session-restore misplaces windows To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/marco/+bug/1845822/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1847479] Re: update-manager window expands off-screen (which effectively stops distribution upgrade)
Just happened with 21.04 (on a pi4), albeit with a minor variation: this time, the suggestion was "change the home directory of user irc?" (the pi was a server install originally, with the desktop packages added later). When I clicked "Help" it resized the window to fill the desktop, and I can JUST see what I'm guessing is the top of a "Close" button at the very bottom of the screen. Once again, the window CANNOT be moved, and CANNOT be resized vertically (although it CAN be resized horizontally). IDK what toolkit the installer is using and how it manages to apparently default to being this broken, but the fix is the same as it was 18 months ago: if the layout is going to keep breaking like this - and empirically, it obviously is - then we need to stop disabling basic functionality like resize so the user can at least work around it! Cheers. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1847479 Title: update-manager window expands off-screen (which effectively stops distribution upgrade) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1847479/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1758642] Re: eom incorrectly fails with unrecognised format on TGA collections
Also still broken in 18.04. I should have some free time in the next couple of months, so I'll see if i can turn it into an ACE. :) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1758642 Title: eom incorrectly fails with unrecognised format on TGA collections To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/eom/+bug/1758642/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1718658] Re: ecryptfs-mount-private fails to initialize ecryptfs keys
One additional note for anyone still stuck using this trainwreck for whatever reason: Even if you use the keyctl hack to get mounting your private data to work, you will be unable to UNmount it because of bugs in ecryptfs- umount-private. The workaround for THAT bug is to just call "/sbin/umount.ecryptfs_private" directly. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1718658 Title: ecryptfs-mount-private fails to initialize ecryptfs keys To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1718658/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1847892] Re: large performance regression (~30-40%) in wifi with 19.10 / 5.3 kernel
Sorry Kai - I got swamped by real-life issues. I finally got the time to look into this a few days ago, and when I went to check on it then in case a kernel update had fixed things already, it looks like it has (or at least, mostly so) - peaks are back to 80+, so that's within wifi variance again. It did show a strange very severe falloff in a couple of tests - down to 40-ish for several seconds during large file transfer, which is new. But I haven't been able to repeat that anything like enough to be able to test versions against it. I'm set up to DO that testing if I can find a good way to repro that, or for the next time performance goes in the tank. For now though, this is going to have to sit in the "I'll keep an eye on it, but can't do anything right now" pile. Thanks again for all your help. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1847892 Title: large performance regression (~30-40%) in wifi with 19.10 / 5.3 kernel To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1847892/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1849004] Re: update-manager stopped loading update descriptions / changelog
The package update-manager/xenial-proposed 1:16.04.17 fixes the bug for me as well. enabled -proposed and pulled in those files via synaptic, leaving the other packages as is. ran update-manager and changelogs show properly again on those packages. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1849004 Title: update-manager stopped loading update descriptions / changelog To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1849004/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1847479] Re: update-manager window expands off-screen (which effectively stops distribution upgrade)
I wonder what the thought process was that led to disabling user resize of this window in the first place. As with the absence of the other window controls there's no reason for it at all, and simply not doing so would have prevented this bug from being application-breaking. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1847479 Title: update-manager window expands off-screen (which effectively stops distribution upgrade) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1847479/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1847479] Re: update-manager window expands off-screen (which effectively stops distribution upgrade)
No, you can't. The window EXPANDS to where it's unusable, but then doesn't resize back DOWN when you toggle details back off. The only way out is to kill update-manager (which doesn't even have a Close icon, so you also have to know that you can do it from the main menu, which some distros are now disabling by default, so then you're looking at the terminal for it. :P) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1847479 Title: update-manager window expands off-screen (which effectively stops distribution upgrade) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1847479/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1847892] Re: large performance regression (~30-40%) in wifi with 19.10 / 5.3 kernel
Thanks Kai. Yes, I really want to use Ubuntu kernel to bisect: or at least, I need the option to be able to - because if the problem is coming from the Ubuntu patchset, I could spend weeks bisecting mainline and never find it, whereas if I bisect the Ubuntu tree I'm guaranteed to find it and that one can be mapped back to mainline if needed, whereas we can't go the other way around. The other critical aspect to having the Ubuntu tree available is that it gives me the Ubuntu 5.0.0-23 build as a sanity check, it case the problem is being caused elsewhere. Remember, this is *wifi* we're talking about: any number of pieces could be to blame, from a power outage resetting something in the router (20/40 coexistence, for example) to physical antennas in multiple devices, and so on. I need a way to validate beyond question that it IS the kernel that's at fault before I go any further with this to avoid risking wasting everybody's time, including yours. :) Anyway, now that I have that info I'll free up a Passport and get things underway. Thanks again. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1847892 Title: large performance regression (~30-40%) in wifi with 19.10 / 5.3 kernel To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1847892/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1847892] Re: large performance regression (~30-40%) in wifi with 19.10 / 5.3 kernel
Had the affected machine in here (i.e. "where the router is") for other reasons, so I was able to check those conditions too. As expected, it's a power / antenna / etc issue: Linux 5.3.0-19-generic #20-Ubuntu SMP Fri Oct 18 09:04:39 UTC 2019 x86_64 Fri 08-Nov-19 03:29 sent 459,277,171 bytes received 35 bytes 7,467,922.05 bytes/sec iwlist scan, WHILE the rsync was running (so it shouldn't be power-saving at all) with the router 6' away with clear LOS showed: Frequency:2.422 GHz (Channel 3) Quality=62/70 Signal level=-48 dBm Looking at 1795116, I used to get 70/70 at -32 dBm upstairs and through half a dozen walls, so obviously this is a significant drop in link quality given the hugely better conditions. Compared to 4.15.0-36 - which, bear in mind was one of the BROKEN kernels, the performance is 7,467,922 / 11,167,414, or 66.9% of what it should be in that scenario. The good news is, that difference suggests it's at least not a simple merge regression of 1795116. The bad news is, of course, that it'll need a new round of investigation track down. As I've said, I'm willing to set things up to help out, but I'm still waiting for you to provide me with the ACTUAL Ubuntu kernel tree to bisect against. In the meantime, I'll probaby try a couple of the mainline builds since I can just dpkg those, but with no way to map the working Ubuntu ones to the mainline tree I'll never have a baseline to compare against in case something stupid has happened like one of the antenna connectors has become disconnected or etc. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1847892 Title: large performance regression (~30-40%) in wifi with 19.10 / 5.3 kernel To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1847892/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1851974] [NEW] changelogs not displayed
Public bug reported:
For the last few weeks, update-manager fails to show the changes for new
packages. Running it from a terminal, I see:
~ $ update-manager
/usr/bin/update-manager:28: PyGIWarning: Gtk was imported without specifying a
version first. Use gi.require_version('Gtk', '3.0') before import to ensure
that the right version gets loaded.
from gi.repository import Gtk
/usr/lib/python3/dist-packages/UpdateManager/UnitySupport.py:29: PyGIWarning:
Dbusmenu was imported without specifying a version first. Use
gi.require_version('Dbusmenu', '0.4') before import to ensure that the right
version gets loaded.
from gi.repository import Dbusmenu, Unity
/usr/lib/python3/dist-packages/UpdateManager/UnitySupport.py:29: PyGIWarning:
Unity was imported without specifying a version first. Use
gi.require_version('Unity', '7.0') before import to ensure that the right
version gets loaded.
from gi.repository import Dbusmenu, Unity
Exception in thread Thread-1:
Traceback (most recent call last):
File "/usr/lib/python3.5/threading.py", line 914, in _bootstrap_inner
self.run()
File "/usr/lib/python3.5/threading.py", line 862, in run
self._target(*self._args, **self._kwargs)
File "/usr/lib/python3/dist-packages/UpdateManager/Core/MyCache.py", line
320, in get_news_and_changelog
self.get_changelog(name)
File "/usr/lib/python3/dist-packages/UpdateManager/Core/MyCache.py", line
376, in get_changelog
changelog = self._get_changelog_or_news(name, "changelog")
File "/usr/lib/python3/dist-packages/UpdateManager/Core/MyCache.py", line
245, in _get_changelog_or_news
"https locations with username/password are not"
UpdateManager.Core.MyCache.HttpsChangelogsUnsupportedError: https locations
with username/password are notsupported to fetch changelogs
So, IDK exactly when the new version was pushed out, but that error's
nicely self-diagnosed at least: good job! :)
ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: update-manager 1:16.04.16
ProcVersionSignature: Ubuntu 4.15.0-66.75~16.04.1-generic 4.15.18
Uname: Linux 4.15.0-66-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.21
Architecture: amd64
CurrentDesktop: MATE
Date: Sat Nov 9 21:32:42 2019
EcryptfsInUse: Yes
GsettingsChanges:
b'com.ubuntu.update-manager' b'window-height' b'893'
b'com.ubuntu.update-manager' b'first-run' b'false'
b'com.ubuntu.update-manager' b'window-width' b'757'
b'com.ubuntu.update-manager' b'launch-time' b'int64 1573363939'
InstallationDate: Installed on 2015-04-29 (1655 days ago)
InstallationMedia: Ubuntu MATE 14.04.1 "Trusty Tahr" - final amd64 (2014)
PackageArchitecture: all
SourcePackage: update-manager
UpgradeStatus: Upgraded to xenial on 2018-03-18 (602 days ago)
** Affects: update-manager (Ubuntu)
Importance: Undecided
Status: New
** Tags: amd64 apport-bug xenial
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1851974
Title:
changelogs not displayed
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1851974/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1718658] Re: ecryptfs-mount-private fails to initialize ecryptfs keys
#34 said: This bug affects a cryptographic (read: highly sensitive) feature, is 15 months old, a patch was proposed 12 months ago, but it is still of "Undecided" importance and still "Unassigned"? Come on! Are the ecryptfs-utils and systemd packages unmaintained at Ubuntu? Well, this bug is now over TWO YEARS old, and is still broken in 19.10. Expecting the systemd devs to care is, frankly, naive. I would have expected Canonical to at least do SOMETHING by now, even if it was just to add the keyctl hack to .profile, but that still leaves a ton of problems like non-root users never being unable to unmount their encrypted data - especially when you add in the OTHER systemd bugs that cause it to stay mounted and unencrypted even after logout. The problem here is that Kirkland was the one who was hot for ecryptfs, and he left Canonical a long time ago. While he may technically still be listed as the maintainer of the package, he clearly gives 0 f**ks about it. (He was still on Ubuntu staff when this bug first surfaced, and didn't even care THEN when it was literally (part of) his job, so it's no surprise he still doesn't now). The package needs to be demoted out of the repos, and the default behavior for encrypted /home changed to use something else - anything else, really - if it hasn't been already. In the meantime, the best thing you can do is just warn people not to use it, because at 2 years and counting I wouldn't hold my breath waiting for it to ever get sorted out... TLDR: use the keyctl hack from #26 to get your data back, then get the hell off ecryptfs as fast as possible. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1718658 Title: ecryptfs-mount-private fails to initialize ecryptfs keys To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1718658/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1847892] Re: large performance regression (~30-40%) in wifi with 19.10 / 5.3 kernel
Okay - the 18.04.3 release I tested in September, which was fine, has 5.0.0-23. -29 is broken, as mentioned above. That's a pretty narrow window to work with. I'd prefer it if someone from Canonical took it from here. (Heck, there are probably few enough commits to that driver in that timeframe that I could find the bad one more easily just by browsing the source than getting that machine to build it). Since it's the HWE stack that's broken, I could still install 18.04 from the image I have and switch back to the original Bionic kernel series, though it's anybody's guess if the same regression was merged into 4.15 again as well. Having to do a fresh install sucks pretty hard, but I'd at least be able to pin the last unbroken kernel, whereas on 19.10 there aren't any working ones in the repos at all (AFAIK) so I'm basically screwed until a fix makes its way through the system or I brute-force an older one onto it. I'm still trying to decide if I really want to go down that road or not. I found https://people.canonical.com/~kernel/info/kernel-version-map.html , but it's basically useless. All the 4.15 kernels from the working -32 through the 7 months of buggy ones and out the other side to -55 when it was fixed are all just "4.15.18 mainline". Maybe I'm missing something here, but without the tree that you guys are *actually building from* I don't see how me bisecting mainline is going to achieve anything. If that page is accurate it has nothing to do with mainline at all and the bug only exists in the Ubuntu tree in the first place, neh? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1847892 Title: large performance regression (~30-40%) in wifi with 19.10 / 5.3 kernel To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1847892/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1847892] Re: large performance regression (~30-40%) in wifi with 19.10 / 5.3 kernel
16.04.6 turned out to have 4.15.0-45, which is one of the known-broken releases. Unsurprisingly, it delivered the same poor results as 5.3. I'm running low on sensible options here. I no longer have the bootable 18.04 stick I used before, but I can create a new one easily enough (as long as I remember to use the .0 image and avoid the HWE stack). But it's not going to tell us anything we don't already know, and it's no use for either normal use or testing. I could wipe the machine and install 18.04, which would cost me years of customisation and bugfixing. Since the bug is in the HWE kernels it would also be possible to test those separately, though it would need a lot of messing around each time. This is sort-of tempting for other reasons anyway, but it'll take weeks of elapsed time to get everything repaired, which is time I won't be able to spend on this bug. I can't really repartition it while doing that, unfortunately. It just has a very small SSD to boot off, and is heavily dependent on the LAN. I could probably JUST about carve out another very small partition to put 18.04 on, which would make the backwards-migration easier and leave me able to validate a fix for this at some point, but it's already seriously hurting for space at times. I'll give it some thought. In the meantime, do you have a preference or any suggestions that might influence that decision? Returning to your original bisection request: since Ubuntu generates its own kernels, if you can give me the mapping from the not-broken 4.15.0-55 to the equivalent starting point in Linus's tree, and likewise for the broken 5.0.0-29, I'll see about sacrificing a USB HDD to that machine for a while for it to build on. No promises, and it'll still take weeks to actually complete, but I'll do what I can. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1847892 Title: large performance regression (~30-40%) in wifi with 19.10 / 5.3 kernel To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1847892/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1847892] Re: large performance regression (~30-40%) in wifi with 19.10 / 5.3 kernel
Any specific params you want for iperf BTW? I ran some basic tests against a VM after all: it might have lost a few %, but wireless is so slow that it's not going to make any meaningful difference. [ ID] IntervalTransferBandwidth Reads Dist(bin=16.0K) [ 4] 0.-11.4354 sec 45.8 MBytes 33.6 Mbits/sec 22348 22341:6:0:1:0:0:0:0 [ 4] local 192.168.1.34 port 5001 connected with 192.168.1.33 port 45314 [ 4] 0.-10.3068 sec 68.6 MBytes 55.9 Mbits/sec 35906 35901:2:3:0:0:0:0:0 [ 4] local 192.168.1.34 port 5001 connected with 192.168.1.33 port 45316 [ 4] 0.-10.3491 sec 71.6 MBytes 58.1 Mbits/sec 35522 35512:2:4:4:0:0:0:0 [ 4] local 192.168.1.34 port 5001 connected with 192.168.1.33 port 45324 [ 4] 0.-10.3927 sec 75.1 MBytes 60.6 Mbits/sec 35410 35397:7:3:2:1:0:0:0 [ 4] local 192.168.1.34 port 5001 connected with 192.168.1.33 port 45326 [ 4] 0.-10.3910 sec 59.8 MBytes 48.2 Mbits/sec 30683 30675:3:4:1:0:0:0:0 The first run may well have had the wifi at low power: the client had just been woken up a couple of minutes earlier, but it tends to dial that back quite quickly. I left it in for completeness. An rsync right after the last run was 6,906,424.15 bytes/sec, so ~58.65 Mb/s. I think that's a good indicator of being able to trust the historical data from it. I may have the machine in here at some point in the next few days, and will test that too if so. For 1795116, the performance in that scenario (~6' and LOS) was fine: it wasn't that the driver was broken across the board, it just wasn't managing power properly so it fell apart if conditions weren't perfect. (Not saying this is the same bug, just reminding myself what a result like that means). I still need to boot into 16.04 / etc to try and find a working kernel. AFAICT 16.04.6 shipped with one that has the post-1795116 fix in it, so it should be okay off a USB. If not though I'll have to get creative, as there isn't a spare partition on that machine to install to. My notes show 4.15.0-55 as the first version with the old bug fixed. It would be helpful if there was a reasonable way for me to just install that, since there are multiple dist-upgrade's worth of other changes since then. While that specific kernel would be ideal from a testing standpoint, isn't there somewhere I can just grab the current Bionic kernel from, as a dpkg, and just install the damn thing without having to jump through any hoops? Surely there must be a better system in place already than randomly guessing at versions or doing builds on a system that is totally unsuitable for such tasks. :( -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1847892 Title: large performance regression (~30-40%) in wifi with 19.10 / 5.3 kernel To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1847892/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1847892] Re: large performance regression (~30-40%) in wifi with 19.10 / 5.3 kernel
I expect so. I don't usually have a machine available to run as a server though, hence the preference for rsync. If you're concerned that the NAS might be the bottleneck, don't be. That's a sensible point to raise, but it's GbE and saturates it wired. (To say nothing of the months during which the rsync consistenly hit 80+). If you think iperf might narrow the scope of where to look though, let me know and I'll try it next time I can dedicate a machine to it: shouldn't be more than a week. (hmm - I could run one up in a VM at will, which would still have more than enough network performance for this, but I'm not sure I'd fully trust the results from that until I've got a baseline to compare against. I'll try to remember it when I boot the client off an older kernel). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1847892 Title: large performance regression (~30-40%) in wifi with 19.10 / 5.3 kernel To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1847892/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1847892] Re: large performance regression (~30-40%) in wifi with 19.10 / 5.3 kernel
The dist-upgrades have wiped out all the previous kernels, of course. The only one left on the machine at all was the 5.0 from 19.04, and that's no good either. :( Linux 5.0.0-29-generic #31-Ubuntu SMP Thu Sep 12 13:05:32 UTC 2019 x86_64 Wed 23-Oct-19 04:47 sent 459,277,171 bytes received 35 bytes 5,635,303.14 bytes/sec The window is too large for me to bisect any time soon. The machine is inconveniently located for such things, but needs to stay there for the testing to be valid; and I don't expect to be able to average more than one build every few days. I'll do what I can to at least narrow things down a little, but since it took more than 6 months to get the last regression fixed after I'd already provided the exact release that introduced it, I'm sure you can understand why I'm not too keen on burning days of my free time on this. 4.15.0-55 is the last *recorded* good, but I did test 18.04 from a USB prior to installing that and hit 80+, so at least one version of 4.18 is okay. I'll re-check that build first just in case, then try a Live 18.04.3. If that one's good, the range would only be 5.0-xx to 5.0-29, and i can probably get that covered in a few weeks. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1847892 Title: large performance regression (~30-40%) in wifi with 19.10 / 5.3 kernel To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1847892/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1847892] Re: large performance regression (~30-40%) in wifi with 19.10 / 5.3 kernel
That machine doesn't have access to launchpad, so until someone fixes the bugs (referenced out in the other thread) so that "ubuntu-bug -c" works, I can't provide that info. Kai - this is a low-power HTPC, with very little disk space. Assuming it can even clone the kernel, it will likely take weeks for me to bisect the problem. I'll do what I can, but unless we get very lucky it'll be a long time before we have an answer. Remember, the LKG is the 18.04 kernel, which is now mostly 18 months old. :( -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1847892 Title: large performance regression (~30-40%) in wifi with 19.10 / 5.3 kernel To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1847892/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1847892] Re: large performance regression (~30-40%) in wifi with 19.10 / 5.3 kernel
** Changed in: linux (Ubuntu) Status: Incomplete => Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1847892 Title: large performance regression (~30-40%) in wifi with 19.10 / 5.3 kernel To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1847892/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1847892] [NEW] large performance regression (~30-40%) in wifi with 19.10 / 5.3 kernel
Public bug reported: Probably relevant: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1795116 Card is an RTL8723BE. On 16.04 with the HWE stack, after 1795116 was fixed performance was a stable 75-80Mb/s. Linux 4.15.0-55-generic #60~16.04.2-Ubuntu SMP Thu Jul 4 09:03:09 UTC 2019 x86_64 Fri 26-Jul-19 12:28 sent 459,277,171 bytes received 35 bytes 9,278,327.39 bytes/sec Linux 4.15.0-55-generic #60~16.04.2-Ubuntu SMP Thu Jul 4 09:03:09 UTC 2019 x86_64 Sat 27-Jul-19 01:23 sent 459,277,171 bytes received 35 bytes 10,320,836.09 bytes/sec On 18.04, performance was still a stable 75-80Mb/s. After updating to 19.10, performance is typically ~50Mb/s, or about a 37% regression. $ iwconfig wlan0 wlan0 IEEE 802.11 ESSID:"**" Mode:Managed Frequency:2.442 GHz Access Point: 4C:60:DE:FB:A8:AB Bit Rate=150 Mb/s Tx-Power=20 dBm Retry short limit:7 RTS thr=2347 B Fragment thr:off Power Management:on Link Quality=59/70 Signal level=-51 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:315 Missed beacon:0 $ ./wifibench.sh Linux 5.3.0-13-generic #14-Ubuntu SMP Tue Sep 24 02:46:08 UTC 2019 x86_64 Sat 12-Oct-19 20:30 sent 459,277,171 bytes received 35 bytes 5,566,996.44 bytes/sec $ iwconfig wlan0 wlan0 IEEE 802.11 ESSID:"**" Mode:Managed Frequency:2.442 GHz Access Point: 4C:60:DE:FB:A8:AB Bit Rate=150 Mb/s Tx-Power=20 dBm Retry short limit:7 RTS thr=2347 B Fragment thr:off Power Management:on Link Quality=68/70 Signal level=-42 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:315 Missed beacon:0 So no corrupted packets or etc during that transfer. $ ifconfig wlan0 wlan0: flags=4163 mtu 1500 inet 192.168.1.33 netmask 255.255.255.0 broadcast 192.168.1.255 ether dc:85:de:e4:17:a3 txqueuelen 1000 (Ethernet) RX packets 56608204 bytes 79066485957 (79.0 GB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 21634510 bytes 8726094217 (8.7 GB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 No issues of any kind in the week that it's been up. Just terrible performance. I'm painfully aware of all the module's parameters etc, and have tried them all, with no change in the results outside of typical wifi variance. ** Affects: linux (Ubuntu) Importance: Undecided Status: Incomplete ** Tags: bionic eoan regression rtl8723be wifi ** Project changed: ubuntu-mate => linux (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1847892 Title: large performance regression (~30-40%) in wifi with 19.10 / 5.3 kernel To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1847892/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1664006] Re: I wish window control buttons scaled in size with window title font size
Don't know if this has been fixed at some point, but *with the theme I use* on 19.10 the buttons resize correctly. So either it's fixed, or the problem is with the specific theme (Ambient-Dark or whatever) that you're using. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1664006 Title: I wish window control buttons scaled in size with window title font size To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-mate/+bug/1664006/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1846474] Re: Distribution Upgrade unusable on low-res displays
IDK why launchpad insists on filling in the Package field incorrectly every time I file a bug! I expect firefox is actually to blame and has decided to autofill things. Sorry about that. ** Package changed: marco (Ubuntu) => update-manager (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1846474 Title: Distribution Upgrade unusable on low-res displays To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1846474/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1846474] Re: Distribution Upgrade unusable on low-res displays
Also note that the window doesn't even have a Close button, so they can't exit it that way either. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1846474 Title: Distribution Upgrade unusable on low-res displays To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/marco/+bug/1846474/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1846474] [NEW] Distribution Upgrade unusable on low-res displays
Public bug reported: When performing a distribution upgrade, update-manager initially presents a usable (though badly-sized) window. Clicking the "Details" button though resizes that window (by, I'm guessing, the vertical space needed for the new information) and pushes the window's buttons off the bottom of the screen. The window cannot be moved up, because the titlebar blocks that; and it can't be resized vertically either. The end result is that there is no way to see the buttons, no way for mouse users to click them, and no way for the user to either continue or abort the upgrade other than by guessing at which button MIGHT be highlighted if they TAB around blindly. This bug is present in the updaters used for (at least) both 19.04 and 19.10. ** Affects: marco (Ubuntu) Importance: Undecided Status: New ** Attachment added: "update-unusable-720p.png" https://bugs.launchpad.net/bugs/1846474/+attachment/5293939/+files/update-unusable-720p.png -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1846474 Title: Distribution Upgrade unusable on low-res displays To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/marco/+bug/1846474/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1841854] Re: netspeed applet icon not correctly sized
Both bugs, that is. (Sorry, forgot to check the second one before). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1841854 Title: netspeed applet icon not correctly sized To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-mate/+bug/1841854/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1841854] Re: netspeed applet icon not correctly sized
Just to confirm, the bug is still present in 19.10 Beta. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1841854 Title: netspeed applet icon not correctly sized To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-mate/+bug/1841854/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1845822] Re: marco / mate-session-restore misplaces windows
I got tired of putting them back in the right place, and after the next reboot I noticed that they actually KEEP moving up (and left, when possible) each time. Funky. :) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1845822 Title: marco / mate-session-restore misplaces windows To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/marco/+bug/1845822/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1845822] Re: marco / mate-session-restore misplaces windows
** Attachment added: "session-restore-position-bug.png" https://bugs.launchpad.net/ubuntu/+source/marco/+bug/1845822/+attachment/5292438/+files/session-restore-position-bug.png -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1845822 Title: marco / mate-session-restore misplaces windows To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/marco/+bug/1845822/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1845822] Re: marco / mate-session-restore misplaces windows
Some more info, without which that session file isn't much use: The display is 1920x1200. Ignore the bottom edge, since that has a panel on it. The caja window is @ 791 x, + w = 1,902. The x="-10" for a window on the LHS means the borders are that wide (even though they clearly aren't, so there's some other adjustments going on for whatever reason) so that's 1912, and the 8px guess was dead on. I'll upload a screenshot as well. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1845822 Title: marco / mate-session-restore misplaces windows To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/marco/+bug/1845822/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1845822] Re: marco / mate-session-restore misplaces windows
Launchpad made a bad guess on the package, and ignored my change to it on the submission. :) ** Package changed: mate-screensaver (Ubuntu) => marco (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1845822 Title: marco / mate-session-restore misplaces windows To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/marco/+bug/1845822/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1845822] [NEW] marco / mate-session-restore misplaces windows
Public bug reported: In the 19.10 Beta: session restore is moving all windows placed at the bottom of the screen up by ~8 pixels, and moving all windows placed at the right-hand edge of the screen left by ?about? the same amount. 19.04 didn't have this problem. A window that was "docked" in the top right corner appeared on the left- hand edge of the screen after restarting. I added that one just to test how broken things were, so I don't know what 19.04 would have done. Leaving that extra (terminal) window in (and moving it back to the RHS) and running mate-session-save before restarting, it came back on the RHS this time, but inset by 8px or so, i.e. suffering from the same bug as the (caja) window in the bottom right corner. I've grabbed the session file, which I expect will make it clear whether the bug is in the saving or the loading phase of things. My guess is it's simply being given bad information about the screen size, but either way this should help in it down: .config/marco/sessions/1075926a43f24e4a81569721562090017420063.ms ** Affects: marco (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1845822 Title: marco / mate-session-restore misplaces windows To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/marco/+bug/1845822/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1842757] Re: update-manager does not follow settings and fails to update packages on time
> We'll eventually add phased updates to APT too, but we're not there yet. I'm not sure it's a good idea to go out of your way to make it impossible for users to get the current version of a package by any means. The update-manager behavior is defensible, and even sensible; but there's enormous value to users still having the option to get an update through a different path if they need it. 2+ days, when a package that you need has been broken by a bad update, can be a very long time. I don't think tampering with APT that way as well is at all defensible, unless part of that work fixes the oversights in the original spec and allows users to override the behavior. For example, designating one machine as a canary at 0% into the phased update cycle, i.e. immediately; and the others as 80%+ into it. Anyway, the reason I'm here now is to confirm that update-manager just now offered the non-security updates from two days ago, so it's working as designed. (Although the communication of that behavior within the app itself could certainly be better: i.e. "not absolutely none"... :P) Forcing phased updates on APT itself though, in the absence of better controls, is a terrible idea. Please don't. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1842757 Title: update-manager does not follow settings and fails to update packages on time To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1842757/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1842757] Re: update-manager does not follow settings and fails to update packages on time
Thanks for the link. It's a bit hard to defend it as "not technically a bug, because we're *deliberately* ignoring what you said to do", but I do understand the position (and even mostly agree with it, for what that's worth). It's very confusing when you have multiple machines though, with some randomly getting updates and some not. A more complete design of the behavior would have allowed for a user-side threshhold control, but I imagine nobody wants to revisit it at this point, and I wouldn't blame them. :) Anyway, I should expect them all to update sometime in the next couple of days; and as long as that happens it's As Designed and the only "real" problem is that the behavior isn't communicated to users at all. Hopefully I'll remember to check then, and update this accordingly. Thanks again for the info. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1842757 Title: update-manager does not follow settings and fails to update packages on time To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1842757/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1842757] [NEW] update-manager does not follow settings and fails to update packages on time
Public bug reported: With "Security" and "Other" updates both set to "Display Immediately", Update Manager simply ignores any "Other" updates. It's done this for all of 16.04, IIRC, and certainly for months even if not that long. Today, for example: $ apt list --upgradable Listing... Done bsdutils/xenial-updates 1:2.27.1-6ubuntu3.8 amd64 [upgradable from: 1:2.27.1-6ubuntu3.7] firefox/xenial-updates,xenial-security 69.0+build2-0ubuntu0.16.04.4 amd64 [upgradable from: 68.0.2+build1-0ubuntu0.16.04.1] firefox-esr/xenial 60.8.0esr+build1-0ubuntu0.16.04.3 amd64 [upgradable from: 52.9.0esr+build2-0ubuntu0.16.04.1] firefox-locale-en/xenial-updates,xenial-security 69.0+build2-0ubuntu0.16.04.4 amd64 [upgradable from: 68.0.2+build1-0ubuntu0.16.04.1] libblkid1/xenial-updates 2.27.1-6ubuntu3.8 amd64 [upgradable from: 2.27.1-6ubuntu3.7] libfdisk1/xenial-updates 2.27.1-6ubuntu3.8 amd64 [upgradable from: 2.27.1-6ubuntu3.7] libmount1/xenial-updates 2.27.1-6ubuntu3.8 amd64 [upgradable from: 2.27.1-6ubuntu3.7] libsmartcols1/xenial-updates 2.27.1-6ubuntu3.8 amd64 [upgradable from: 2.27.1-6ubuntu3.7] libuuid1/xenial-updates 2.27.1-6ubuntu3.8 amd64 [upgradable from: 2.27.1-6ubuntu3.7] mount/xenial-updates 2.27.1-6ubuntu3.8 amd64 [upgradable from: 2.27.1-6ubuntu3.7] util-linux/xenial-updates 2.27.1-6ubuntu3.8 amd64 [upgradable from: 2.27.1-6ubuntu3.7] uuid-runtime/xenial-updates 2.27.1-6ubuntu3.8 amd64 [upgradable from: 2.27.1-6ubuntu3.7] Meanwhile, in Update Manager only the Firefox updates are offered at all. Nothing seems to be able to persuade it to work correctly (restarting it etc), and once the security updates have been installed it returns to falsely stating that "The machine is up to date", while apt and even the abandoned Synaptic correctly show all the other packages as being upgradeable. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: update-manager 1:16.04.15 ProcVersionSignature: Ubuntu 4.15.0-58.64~16.04.1-generic 4.15.18 Uname: Linux 4.15.0-58-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.19 Architecture: amd64 CurrentDesktop: MATE Date: Wed Sep 4 14:40:56 2019 EcryptfsInUse: Yes GsettingsChanges: b'com.ubuntu.update-manager' b'window-height' b'893' b'com.ubuntu.update-manager' b'first-run' b'false' b'com.ubuntu.update-manager' b'window-width' b'757' b'com.ubuntu.update-manager' b'launch-time' b'int64 1567633200' InstallationDate: Installed on 2015-04-29 (1589 days ago) InstallationMedia: Ubuntu MATE 14.04.1 "Trusty Tahr" - final amd64 (2014) PackageArchitecture: all SourcePackage: update-manager UpgradeStatus: Upgraded to xenial on 2018-03-18 (535 days ago) ** Affects: update-manager (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug xenial -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1842757 Title: update-manager does not follow settings and fails to update packages on time To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1842757/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1758642] Re: eom incorrectly fails with unrecognised format on TGA collections
This bug is still present in 16.04, but seems to be fixed in 19.04. I don't see an explicit commit for it though, which makes me wonder if it's a memory corruption issue in the GTK layer. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1758642 Title: eom incorrectly fails with unrecognised format on TGA collections To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/eom/+bug/1758642/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1827727] Re: All plugins disabled due to expired cert
This shouldn't be marked as "Fix Released" when the LTS's still don't have an update available. I realise the "real" work is done, but we can't have LTS's being treated as second-class citizens to the extent that this crippling defect doesn't even show up as an active issue to their users in Launchpad. /opinion :) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1827727 Title: All plugins disabled due to expired cert To manage notifications about this bug go to: https://bugs.launchpad.net/firefox/+bug/1827727/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1795116] Re: large performance regression (~20-40%) in wifi with 4.15.0-33 and later
That bad run was an outlier. No idea what caused it, but cron'd tests over the past couple of days have all shown results similar to the pre-33 breakage. So it looks like this is finally fixed, thanks. It's a shame testing didn't catch it, but understandable. It's a bit more worrying that the regression took seven months to get repaired, but at least it's all good now. ** Changed in: linux (Ubuntu) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1795116 Title: large performance regression (~20-40%) in wifi with 4.15.0-33 and later To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1795116/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1795116] Re: large performance regression (~20-40%) in wifi with 4.15.0-33 and later
Hooray, it seems that it has - but possibly only partially. Peak and Avg throughput were both a few % down compared to -32, but well within the sort of variance wifi suffers from. High-70s for download is certainly good enough to use. What's less encouraging, to the point of being an outright concern, is the UPLOAD rate. That has consistently peaked at 100Mb/s with -32 over the past several months, with averages not much lower, but remains massively worse in the current kernel: somewhere around 60Mb/s. I've only had time to run one batch of tests on it, so it could have been an extremely unlucky fluke, but like I say, it's worrying. I'll do some more testing when I get the chance. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1795116 Title: large performance regression (~20-40%) in wifi with 4.15.0-33 and later To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1795116/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1795116] Re: large performance regression (~20-40%) in wifi with 4.15.0-33 and later
Thanks, but that seems unlikely: I'm aware of the ant_sel issue on HP laptops etc, but this machine isn't one and has never benefitted from it. If it was using the wrong one of two antennae, it wouldn't hit 70/70 at 20ft away through walls, nor would the throughput be almost half of what it was with the good kernels when registering that signal quality. I'll try it to see, of course, but if it does fix it then the driver's got some drastic bugs with its information reporting! :P -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1795116 Title: large performance regression (~20-40%) in wifi with 4.15.0-33 and later To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1795116/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1795116] Re: large performance regression (~20-40%) in wifi with 4.15.0-33 and later
Although, I see what appears to be an unrelated (to ant_sel) + if (rtlpriv->cfg->ops->get_btc_status()) + rtlpriv->btcoexist.btc_ops->btc_power_on_setting(rtlpriv); added in that commit as well. I can't go digging into the source right now to see what that's doing, but since THIS bug reeks of bad power management you're hopefully right that the patch as a whole will also fix this issue. I'll try it over the weekend - thanks again for the heads up. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1795116 Title: large performance regression (~20-40%) in wifi with 4.15.0-33 and later To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1795116/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1795116] Re: large performance regression (~20-40%) in wifi with 4.15.0-33 and later
Still hopelessly broken. :( Throughput with the latest kernel was down to about 45Mb/s when I tested it a few days ago. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1795116 Title: large performance regression (~20-40%) in wifi with 4.15.0-33 and later To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1795116/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1818049] Re: virtualbox dkms modules fail to build with linux 4.4.0-143.169 [error: too many arguments to function ‘get_user_pages’]
Just reverted to the -142 to double-check, and that does indeed build just fine. 5.1.38 is of course the version in the Ubuntu repository for xenial, so the obsolescence issues have to be ignored. I don't know what the process for resolving the conflict is here, but -143 breaks xenial guests, and that's definitely a Bad Thing. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1818049 Title: virtualbox dkms modules fail to build with linux 4.4.0-143.169 [error: too many arguments to function ‘get_user_pages’] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1818049/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1818049] Re: virtualbox dkms modules fail to build with linux 4.4.0-143.169 [error: too many arguments to function ‘get_user_pages’]
This appears to have either gone too far or not far enough, since the current xenial of: 4.4.0-143-generic #169-Ubuntu SMP Thu Feb 7 07:56:38 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux now fails to build the virtualbox client modules with: --- /tmp/vbox.0/r0drv/linux/memobj-r0drv-linux.c: In function ‘rtR0MemObjNativeLockUser’: /tmp/vbox.0/r0drv/linux/memobj-r0drv-linux.c:1123:33: warning: passing argument 6 of ‘get_user_pages’ makes pointer from integer without a cast [-Wint-conversion] fWrite, /* force write access. */ ^ In file included from /tmp/vbox.0/r0drv/linux/the-linux-kernel.h:101:0, from /tmp/vbox.0/r0drv/linux/memobj-r0drv-linux.c:31: include/linux/mm.h:1222:6: note: expected ‘struct page **’ but argument is of type ‘int’ long get_user_pages(struct task_struct *tsk, struct mm_struct *mm, ^ /tmp/vbox.0/r0drv/linux/memobj-r0drv-linux.c:1125:33: warning: passing argument 7 of ‘get_user_pages’ from incompatible pointer type [-Wincompatible-pointer-types] >apPages[0], /* Page array. */ ^ In file included from /tmp/vbox.0/r0drv/linux/the-linux-kernel.h:101:0, from /tmp/vbox.0/r0drv/linux/memobj-r0drv-linux.c:31: include/linux/mm.h:1222:6: note: expected ‘struct vm_area_struct **’ but argument is of type ‘struct page **’ long get_user_pages(struct task_struct *tsk, struct mm_struct *mm, ^ /tmp/vbox.0/r0drv/linux/memobj-r0drv-linux.c:1113:18: error: too many arguments to function ‘get_user_pages’ rc = get_user_pages(pTask, /* Task for fault accounting. */ ^ In file included from /tmp/vbox.0/r0drv/linux/the-linux-kernel.h:101:0, from /tmp/vbox.0/r0drv/linux/memobj-r0drv-linux.c:31: include/linux/mm.h:1222:6: note: declared here long get_user_pages(struct task_struct *tsk, struct mm_struct *mm, ^ scripts/Makefile.build:285: recipe for target '/tmp/vbox.0/r0drv/linux/memobj-r0drv-linux.o' failed --- against the current virtualbox release (6.04). The -142 kernels didn't have this problem. Sidenote: my understanding is that the dkms modules haven't been required by virtualbox in several years now. The 5.1.xx series is also probably obsolete. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1818049 Title: virtualbox dkms modules fail to build with linux 4.4.0-143.169 [error: too many arguments to function ‘get_user_pages’] To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1818049/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1803782] [NEW] autoremoval of kernels breaks unless other packages need updating
Public bug reported: after updating multiple packages including the kernel, choose "restart later". note: in this particular case i deferred the update for a specific package (thunderbird) - no idea if that's required to trigger this bug or not. when update manager pops up again after about 10s (which is technically "later", i suppose, but pointlessly short) it will then correctly show the grandfather kernel as "unused" for autoremoval - but when the checkbox for the unwanted thunderbird update is cleared, the "install now" button greys out since there are then no updates to install, which blocks the removal of the now-obsolete kernel. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: update-manager 1:16.04.15 ProcVersionSignature: Ubuntu 4.4.0-138.164-generic 4.4.155 Uname: Linux 4.4.0-138-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.18 Architecture: amd64 CurrentDesktop: MATE Date: Fri Nov 16 12:57:36 2018 EcryptfsInUse: Yes GsettingsChanges: b'com.ubuntu.update-manager' b'window-height' b'893' b'com.ubuntu.update-manager' b'first-run' b'false' b'com.ubuntu.update-manager' b'window-width' b'757' b'com.ubuntu.update-manager' b'launch-time' b'int64 1542401633' InstallationDate: Installed on 2015-04-29 (1297 days ago) InstallationMedia: Ubuntu MATE 14.04.1 "Trusty Tahr" - final amd64 (2014) PackageArchitecture: all SourcePackage: update-manager UpgradeStatus: Upgraded to xenial on 2018-03-18 (243 days ago) ** Affects: update-manager (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug xenial -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1803782 Title: autoremoval of kernels breaks unless other packages need updating To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1803782/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1795116] Re: large performance regression (~20-40%) in wifi with 4.15.0-33 and later
given the link quality observations in #11 and the behavior in #12, it's pretty clear that the problem is with the radio power management. since it isn't improved at all via any of the PM settings, that suggests it's simply broken rather than overly-aggressive. for reference, the head for the last good version of the driver is 6A56582B1FEECB841E329C4 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1795116 Title: large performance regression (~20-40%) in wifi with 4.15.0-33 and later To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1795116/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1795116] Re: large performance regression (~20-40%) in wifi with 4.15.0-33 and later
the machine is usually ~20 feet away from the router, through multiple walls and a floor. i moved it last night so it was 6 feet away with LOS, and the results from that are very interesting: Linux brix 4.15.0-36-generic #39~16.04.1-Ubuntu SMP Tue Sep 25 08:59:23 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux Current Frequency:2.452 GHz (Channel 9) Link Quality=70/70 Signal level=-30 dBm Sat 20-Oct-18 17:23 429,840,384 100% 10.91MB/s0:00:37 (xfr#1, to-chk=0/1) sent 429,945,420 bytes received 35 bytes 11,167,414.42 bytes/sec and under the same ideal conditions: Linux brix 4.15.0-32-generic #35~16.04.1-Ubuntu SMP Fri Aug 10 21:54:34 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux Current Frequency:2.452 GHz (Channel 9) Link Quality=70/70 Signal level=-32 dBm Sat 20-Oct-18 17:29 429,840,384 100%9.10MB/s0:00:45 (xfr#1, to-chk=0/1) sent 429,945,420 bytes received 35 bytes 9,449,350.66 bytes/sec so the newer kernel is MUCH better in that situation, whereas the old kernel essentially performs exactly the same. the machine has a fairly weak cpu, and basically has one core pegged with iowait during these transfers, so optimisations (either in general for meltdown etc, or the stack, or in the driver specifically) could certainly account for that sort of speedup. however, that only further highlights just how bad this regression is, because the driver is now nearly 20% faster in the abstract but still massively slower at range despite all that improvement. it also explains why nobody would notice the regression during development. i'm happy to test proposed fixes or provide more information, but i don't think there's anything more i can do at my end until somebody else steps in. @joseph - do you have a tracking reference for upstream yet? TIA -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1795116 Title: large performance regression (~20-40%) in wifi with 4.15.0-33 and later To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1795116/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1795116] Re: large performance regression (~20-40%) in wifi with 4.15.0-33 and later
> prior to the transfer [on the buggy versions] the link quality is 62-64 and the signal similarly weaker because of power saving, but once packets are in flight it looks perfect -32 doesn't seem to have that problem: it's been 70/70 every time i've looked, even with the link speed showing as 15Mb/s rather than 150, indicating power saving. so i modprobed the driver with all the power- saving options (ips, fwlps, and aspm) set to 0 while running one of the broken kernels (i don't remember if it was -36 or the 4.19 build, sorry) to see if that made any difference, but AFAICT it didn't. (i.e. still around 55Mb/s, when -32 was hitting 70+ 5 mins before/after). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1795116 Title: large performance regression (~20-40%) in wifi with 4.15.0-33 and later To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1795116/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1795116] Re: large performance regression (~20-40%) in wifi with 4.15.0-33 and later
> on channel 8(+4), 4.19 typically performed on par with -32 and older. apparently only because of some fluke. the router switched to 4(+8) some time in the past couple of days, and the newer kernels are certainly sucking hard on that too: --- Linux brix 4.15.0-32-generic #35~16.04.1-Ubuntu SMP Fri Aug 10 21:54:34 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux Current Frequency:2.427 GHz (Channel 4) Link Quality=70/70 Signal level=-36 dBm Sun 07-Oct-18 03:30 429,840,384 100%9.00MB/s0:00:45 (xfr#1, to-chk=0/1) sent 429,945,420 bytes received 35 bytes 9,449,350.66 bytes/sec --- Linux brix 4.15.0-36-generic #39~16.04.1-Ubuntu SMP Tue Sep 25 08:59:23 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux Current Frequency:2.427 GHz (Channel 4) Link Quality=64/70 Signal level=-46 dBm Sun 07-Oct-18 05:05 429,840,384 100%6.46MB/s0:01:03 (xfr#1, to-chk=0/1) sent 429,945,420 bytes received 35 bytes 6,665,821.01 bytes/sec --- this is a major regression. is there any activity on it upstream? i can't imagine it's ALL wifi, or people would be screaming for blood, but it would be good to at least get it in front of larry finger (the rtl driver author) as a starting point. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1795116 Title: large performance regression (~20-40%) in wifi with 4.15.0-33 and later To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1795116/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1795116] Re: large performance regression (~20-40%) in wifi with 4.15.0-33 and later
so, the methodology is, reboot, wait for things to settle (i.e. for the initial "performance" cpu period ubuntu uses to pass), run a simple script that dumps out some diags and rsyncs that 400MB iso. -- Linux brix 4.19.0-041900rc6-generic #201809301631 SMP Sun Sep 30 16:32:51 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux Current Frequency:2.452 GHz (Channel 9) Link Quality=62/70 Signal level=-48 dBm Wed 03-Oct-18 01:35 429,840,384 100%6.80MB/s0:01:00 (xfr#1, to-chk=0/1) sent 429,945,420 bytes received 35 bytes 7,106,536.45 bytes/sec --- Linux brix 4.15.0-34-generic #37~16.04.1-Ubuntu SMP Tue Aug 28 10:44:06 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux Current Frequency:2.452 GHz (Channel 9) Link Quality=62/70 Signal level=-48 dBm Wed 03-Oct-18 01:40 429,840,384 100%6.38MB/s0:01:04 (xfr#1, to-chk=0/1) sent 429,945,420 bytes received 35 bytes 6,665,821.01 bytes/sec --- Linux brix 4.15.0-32-generic #35~16.04.1-Ubuntu SMP Fri Aug 10 21:54:34 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux Current Frequency:2.452 GHz (Channel 9) Link Quality=70/70 Signal level=-32 dBm Wed 03-Oct-18 01:43 429,840,384 100%8.14MB/s0:00:50 (xfr#1, to-chk=0/1) sent 429,945,420 bytes received 35 bytes 8,348,455.44 bytes/sec -- that was the best run 4.19 had, at -18%, out of about a dozen. as with 4.15.0-33 and later most were down by 25-30%. so, "still exists" it is. here's where things get weird though... --- Linux brix 4.19.0-041900rc6-generic #201809301631 SMP Sun Sep 30 16:32:51 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux Current Frequency:2.447 GHz (Channel 8) Link Quality=66/70 Signal level=-44 dBm Wed 03-Oct-18 01:12 429,840,384 100%8.07MB/s0:00:50 (xfr#1, to-chk=0/1) sent 429,945,420 bytes received 35 bytes 8,348,455.44 bytes/sec --- on channel 8(+4), 4.19 typically performed on par with -32 and older. on channel 9(+5) though it consistently showed the same regression as -33. again, this is over about a dozen runs (and multiple reboots switching between kernels), not a onetime event. -32 though consistently performed at 70+Mb/s averages regardless of channel. i'm way out of my depth at this point, but that seemed a remarkable weirdness and worth pointing out. :) ** Tags added: kernel-bug-exists-upstream ** Changed in: linux (Ubuntu) Status: Incomplete => Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1795116 Title: large performance regression (~20-40%) in wifi with 4.15.0-33 and later To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1795116/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1795116] Re: large performance regression (~20-40%) in wifi with 4.15.0-33 and later
ok - it's a failure in the doc, since the kernel image can't be installed without them. also note that the headers package can't be installed on 16.04 because of a change in the ?libssl? dependency. (from memory: might be the wrong dependency). that aside, the results with 4.19 are ... odd, so far. i need to test a bit more before committing to a call. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1795116 Title: large performance regression (~20-40%) in wifi with 4.15.0-33 and later To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1795116/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1795116] Re: large performance regression (~20-40%) in wifi with 4.15.0-33 and later
sure, i'll try. sidenote, https://wiki.ubuntu.com/KernelMainlineBuilds is missing any reference to kernel modules, which seem like they might be kind of important for bugs like this. is that a failure in the doc, or is the goal here just to test e.g. the tcp changes in -33 rather than any changes in the device driver itself? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1795116 Title: large performance regression (~20-40%) in wifi with 4.15.0-33 and later To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1795116/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1795116] Re: large performance regression (~20-40%) in wifi with 4.15.0-33 and later
marked as confirmed per #3 and #4. i have the apport file stashed away and can upload it as an attachment upon request if anyone's interested. ** Changed in: linux (Ubuntu) Status: Incomplete => Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1795116 Title: large performance regression (~20-40%) in wifi with 4.15.0-33 and later To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1795116/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1795116] Re: large performance regression (~20-40%) in wifi with 4.15.0-33 and later
unfortunately, the instructions on https://help.ubuntu.com/community/ReportingBugs don't seem to work: >> If this is to be added to an existing bug report, also use the -u option: ubuntu-bug -c FILENAME.apport -u BUGNUMBER << $ ubuntu-bug -c /mnt/nas/wifi.apport -u 1795116 Usage: ubuntu-bug [options] [symptom|pid|package|program path|.apport/.crash file] ubuntu-bug: error: -u/--update-bug option cannot be used together with options for a new report and since -c is the only option that allows me to specify an apport file, i'm not sure how to proceed from here... -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1795116 Title: large performance regression (~20-40%) in wifi with 4.15.0-33 and later To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1795116/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1795116] Re: large performance regression (~20-40%) in wifi with 4.15.0-33 and later
obviously i've tested this with 32/33/34 a dozen or so times, but the performance regression shows up in all of them, so i've only copied that particular one. the best (i.e. "least bad for the bugged kernel") result so far was "only" -18%, and most runs are down by 25-30%. ** Package changed: ubuntu => linux (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1795116 Title: large performance regression (~20-40%) in wifi with 4.15.0-33 and later To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1795116/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1795116] [NEW] large performance regression (~20-40%) in wifi with 4.15.0-33 and later
Public bug reported: 16.04 install using the HWE stack. after several weeks of uptime on -32, an update to -34 showed a major drop in wifi throughput, dependent solely on the kernel chosen: $ uname -a && ./wifibench.sh Linux brix 4.15.0-32-generic #35~16.04.1-Ubuntu SMP Fri Aug 10 21:54:34 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux Tue 25-Sep-18 06:07 PlatformSDK-SVR2003R2.iso 429,840,384 100%8.41MB/s0:00:48 (xfr#1, to-chk=0/1) sent 429,945,420 bytes received 35 bytes 8,685,766.77 bytes/sec $ uname -a && ./wifibench.sh Linux brix 4.15.0-34-generic #37~16.04.1-Ubuntu SMP Tue Aug 28 10:44:06 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux Tue 25-Sep-18 06:14 PlatformSDK-SVR2003R2.iso 429,840,384 100%4.83MB/s0:01:24 (xfr#1, to-chk=0/1) sent 429,945,420 bytes received 35 bytes 5,028,601.81 bytes/sec (the script is a simple rsync from a NAS. nothing in the NAS, or the router, or the physical positions of the devices or etc etc has changed, let alone in those 7 minutes). there is no interference, no other devices connected, etc. prior to the transfer, the link quality is 62-64 and the signal similarly weaker because of power saving, but once packets are in flight it looks perfect: $ iwconfig wlan0 IEEE 802.11 ESSID:"" Mode:Managed Frequency:2.452 GHz Access Point: Bit Rate=150 Mb/s Tx-Power=20 dBm Retry short limit:7 RTS thr=2347 B Fragment thr:off Power Management:on Link Quality=70/70 Signal level=10 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:15 Missed beacon:0 the client is a J1900-based (baytrail) machine with a RTL8723BE wifi module. average performance while on -32 was consistently 70-80 Mb/s, over a period of several weeks. with -33 and later, it's generally 50-65. (that machine has no access to launchpad. i'll try apport-cli over the weekend). ** Affects: ubuntu Importance: Undecided Status: New ** Tags: kernel-bug wifi -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1795116 Title: large performance regression (~20-40%) in wifi with 4.15.0-33 and later To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+bug/1795116/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1760401] [NEW] caja counts files on cifs mount despite being set to "Count Local Files Only"
Public bug reported: With a cifs device (a NAS, in my case) mounted via a "normal" mount, caja counts the files in subdirectories despite being set not to. This destroys the performance of the NAS if you have a few hundred directories at any given level in an open caja window, and takes forever to actually finish. This doesn't happen with the same remote folder mounted via gvfs, but that has less than half the performance of a cifs mount because of gvfs's terrible samba configuration/use and isn't really an option. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: caja 1.12.7-1ubuntu0.1 ProcVersionSignature: Ubuntu 4.4.0-116.140-generic 4.4.98 Uname: Linux 4.4.0-116-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.15 Architecture: amd64 CurrentDesktop: MATE Date: Sun Apr 1 03:17:40 2018 EcryptfsInUse: Yes InstallationDate: Installed on 2015-04-29 (1068 days ago) InstallationMedia: Ubuntu MATE 14.04.1 "Trusty Tahr" - final amd64 (2014) SourcePackage: caja UpgradeStatus: Upgraded to xenial on 2018-03-18 (14 days ago) ** Affects: caja (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug xenial ** Description changed: - With a cifs device (a NAS, in my case) mounted via fstab, caja counts - the files in subdirectories despite being set not to. This destroys the - performance of the NAS if you have a few hundred directories at any - given level in an open caja window, and takes forever to actually - finish. + With a cifs device (a NAS, in my case) mounted via a "normal" mount, + caja counts the files in subdirectories despite being set not to. This + destroys the performance of the NAS if you have a few hundred + directories at any given level in an open caja window, and takes forever + to actually finish. This doesn't happen with the same remote folder mounted via gvfs, but that has less than half the performance of a cifs mount because of gvfs's terrible samba configuration/use and isn't really an option. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: caja 1.12.7-1ubuntu0.1 ProcVersionSignature: Ubuntu 4.4.0-116.140-generic 4.4.98 Uname: Linux 4.4.0-116-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.15 Architecture: amd64 CurrentDesktop: MATE Date: Sun Apr 1 03:17:40 2018 EcryptfsInUse: Yes InstallationDate: Installed on 2015-04-29 (1068 days ago) InstallationMedia: Ubuntu MATE 14.04.1 "Trusty Tahr" - final amd64 (2014) SourcePackage: caja UpgradeStatus: Upgraded to xenial on 2018-03-18 (14 days ago) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1760401 Title: caja counts files on cifs mount despite being set to "Count Local Files Only" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/caja/+bug/1760401/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1758642] Re: eom incorrectly fails with unrecognised format on TGA collections
** Description changed: When a directory of TGAs is opened in eom, either from caja or via "eom ", it displays the first image correctly. Advancing to the next image then fails with "Unrecognized image file format", and returning to the first image at that point also then fails. + + 14.04 didn't have this bug. PNG and JPEG collections seem to work fine. This suggests some form of memory corruption in the TGA handling, but I haven't had a chance to look into it yet. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: eom 1.12.2-2 ProcVersionSignature: Ubuntu 4.4.0-116.140-generic 4.4.98 Uname: Linux 4.4.0-116-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.15 Architecture: amd64 CurrentDesktop: MATE Date: Sun Mar 25 03:40:23 2018 EcryptfsInUse: Yes InstallationDate: Installed on 2015-04-29 (1061 days ago) InstallationMedia: Ubuntu MATE 14.04.1 "Trusty Tahr" - final amd64 (2014) SourcePackage: eom UpgradeStatus: Upgraded to xenial on 2018-03-18 (7 days ago) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1758642 Title: eom incorrectly fails with unrecognised format on TGA collections To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/eom/+bug/1758642/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1758642] [NEW] eom incorrectly fails with unrecognised format on TGA collections
Public bug reported: When a directory of TGAs is opened in eom, either from caja or via "eom ", it displays the first image correctly. Advancing to the next image then fails with "Unrecognized image file format", and returning to the first image at that point also then fails. PNG and JPEG collections seem to work fine. This suggests some form of memory corruption in the TGA handling, but I haven't had a chance to look into it yet. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: eom 1.12.2-2 ProcVersionSignature: Ubuntu 4.4.0-116.140-generic 4.4.98 Uname: Linux 4.4.0-116-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.15 Architecture: amd64 CurrentDesktop: MATE Date: Sun Mar 25 03:40:23 2018 EcryptfsInUse: Yes InstallationDate: Installed on 2015-04-29 (1061 days ago) InstallationMedia: Ubuntu MATE 14.04.1 "Trusty Tahr" - final amd64 (2014) SourcePackage: eom UpgradeStatus: Upgraded to xenial on 2018-03-18 (7 days ago) ** Affects: eom (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug xenial -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1758642 Title: eom incorrectly fails with unrecognised format on TGA collections To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/eom/+bug/1758642/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1756933] [NEW] mate-screensaver fails to disable X dpms and blanking
Public bug reported: as a result, X blanks the screen after 10 minutes regardless of what the screensaver is told to do (ie "don't blank the screen"). $ ps ax |grep screensa 1478 ?Sl 0:00 mate-screensaver $ xset q [snip] Screen Saver: prefer blanking: yesallow exposures: yes timeout: 600cycle: 600 DPMS (Energy Star): Standby: 600Suspend: 600Off: 600 DPMS is Enabled Monitor is On This worked correctly in 14.04 without needing the user to hack up a .xessionrc file. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: mate-screensaver 1.12.0-1 ProcVersionSignature: Ubuntu 4.4.0-116.140-generic 4.4.98 Uname: Linux 4.4.0-116-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.15 Architecture: amd64 CurrentDesktop: MATE Date: Mon Mar 19 09:28:17 2018 EcryptfsInUse: Yes InstallationDate: Installed on 2015-04-29 (1055 days ago) InstallationMedia: Ubuntu MATE 14.04.1 "Trusty Tahr" - final amd64 (2014) SourcePackage: mate-screensaver UpgradeStatus: Upgraded to xenial on 2018-03-18 (1 days ago) ** Affects: mate-screensaver (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug xenial -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1756933 Title: mate-screensaver fails to disable X dpms and blanking To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mate-screensaver/+bug/1756933/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 255030] Re: Eog creates thumbnails even when deactivated in gnome
other way around sebastien: those are all added lines. which i guess means the files were diffed the wrong way round, sigh - i'm used to real sccs's, not diffpatches. thanks for spotting it: re-uploaded with the inversion fixed ** Patch removed: eog-bug-551171.patch https://bugs.launchpad.net/eog/+bug/255030/+attachment/1942207/+files/eog-bug-551171.patch -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/255030 Title: Eog creates thumbnails even when deactivated in gnome -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 255030] Re: Eog creates thumbnails even when deactivated in gnome
** Patch added: eog-bug-551171.patch https://bugs.launchpad.net/eog/+bug/255030/+attachment/1949305/+files/eog-bug-551171.patch -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/255030 Title: Eog creates thumbnails even when deactivated in gnome -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 255030] Re: Eog creates thumbnails even when deactivated in gnome
** Attachment removed: foo https://bugs.launchpad.net/eog/+bug/255030/+attachment/1939623/+files/foo -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/255030 Title: Eog creates thumbnails even when deactivated in gnome -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 255030] Re: Eog creates thumbnails even when deactivated in gnome
replaced the patch with a debdiff (was rcs) and used the gnome bug id rather than a distro-specific one. semi-pointless i know, but it'll be easier for anyone who wants to patch eog themselves. ** Patch added: eog-bug-551171.patch https://bugs.launchpad.net/eog/+bug/255030/+attachment/1942207/+files/eog-bug-551171.patch -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/255030 Title: Eog creates thumbnails even when deactivated in gnome -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 255030] Re: Eog creates thumbnails even when deactivated in gnome
and sent to the mailing list, which is what i actually came here to post but forgot... heh - i'm not going to redesign and rewrite *that*, Mike: it's so integral it would probably be quicker to just start again from (near-)scratch. it's not ideal, but it seems to work for everything outside of the pathological cases i spotted, so i think i'll stick to lower-hanging fruit instead. :P thanks for the feedback/suggestions/etc -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/255030 Title: Eog creates thumbnails even when deactivated in gnome -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 255030] Re: Eog creates thumbnails even when deactivated in gnome
It's not about paranoia Mike: it's that a user who has explicitly stated that they don't want thumbnails, ever; in the only place they *can* specify that preference, is given the impression that their decision is being ignored. I don't think you can blame them for considering it to be a bug. eog certainly does not have the right to ignore user instructions, and especially not in a case like this where it has noticeable negative impacts (slow startup times in extreme cases, disk thrash, and so on) and provides no benefit at all to those users (or indeed to *any* user by default IIRC, because thumbnail display isn't even enabled). Deleting the thumbnails after the fact doesn't address any of those issues (and in fact makes them worse, since eog will then re-thrash). A better option is to just symlink ~/.thumbnails to /dev/null, but that obviously means that if you ever do actually want a thumbnail for some reason, you can't have it. This particular bug seems to be filed repeatedly in every distro, but nobody will take ownership of it. Whether the bug is that eog doesn't have its own setting or it doesn't honor Nautilus's is for them to decide, but failing to address it by either approach for 8? years now is ridiculous. Felix said in https://bugzilla.gnome.org/show_bug.cgi?id=633292 that the thumbnails were necessary. Since he's the eog maintainer it seems unlikely GNOME will ever fix this bug, though that claim is perhaps a little misleading: the only thing that needs thumbnails is the image collection pane, and imposing this overhead regardless of whether someone actually uses that feature or not seems completely unjustified to me. -- [snipped a bunch of performance numbers] To sum up, the CPU overhead of thumbnails is meaninglessly-small, especially since eog is keypress/timer driven anyway. Between JPEG decoding, image resizing, etc, generating a 128x128 PNG from a pixbuf is barely a blip. The IO overhead of thumbnails OTOH can be quite significant, and warrants fixing (ie honoring user preference) for the annoyance factor alone, especially since the current behavior is wrong anyway for the defaults eog/ubuntu uses. [snipped discussion of some other eog bugs i noticed along the way: they're noted in the patch] -- patch is against eog-2.32.1 (15 Nov 2010), which is the current stable, though lucid is still using 2.32.0 hopefully it'll save someone some time/frustration even if it never gets merged upstream. ** Bug watch added: GNOME Bug Tracker #633292 https://bugzilla.gnome.org/show_bug.cgi?id=633292 ** Attachment added: foo https://bugs.launchpad.net/eog/+bug/255030/+attachment/1939623/+files/foo -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/255030 Title: Eog creates thumbnails even when deactivated in gnome -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 565722] Re: eog fails to start
note that the GLib-GIO-CRITICAL errors in the OP are red herrings caused by https://bugs.launchpad.net/ubuntu/+source/eog/+bug/578061 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/565722 Title: eog fails to start -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 635506] Re: Repeated (eog:21535): GLib-GIO-CRITICAL **: g_app_info_equal: assertion `G_IS_APP_INFO (appinfo1)' failed every time I open a file in eog
duplicate of https://bugs.launchpad.net/ubuntu/+source/eog/+bug/578061 , but this identifies the root of the problem and that one doesn't luis: debian introduced the bug, so installing from the GNOME repository will fix it, though you'll probably have to compile it yourself. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/635506 Title: Repeated (eog:21535): GLib-GIO-CRITICAL **: g_app_info_equal: assertion `G_IS_APP_INFO (appinfo1)' failed every time I open a file in eog -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 255030] Re: Eog creates thumbnails even when deactivated in gnome
There is no gnome-wide disable-thumbnail setting, and I doubt you'll
convince anyone that it is worth having one.
Exactly so Mike: except that piece appears to have been oversnipped from
my notes, yay 4am editing...
gThumb has a disable-thumbnail setting, although it can only be
enabled through gconf-editor. Maybe you can convince eog to do the same
Which is exactly what I did, but you'd have had to read the patch to see
it since I didn't make that clear. My bad.
The chmod fix isn't a fix for the same reason that dev/null isn't. A
user may want thumbs for a photo collection in Shotwell/etc or a set of
active images, but not want them for images sent in email etc where
they just use eog to view them once (which now that I think of it is a
perfect example of a case where mindless thumb creation is an
especially-bad policy).
Here's the rest of the notes:
===
These bugfixes expose an interesting bug in eog where the Properties page
fails to update properly on Next/Prev if thumbnails are disabled.
This appears to be because it's using eog_thumb_view_select_single() to step
through the list rather than the actual images themselves. It correctly
advances the MAIN window to the next image, but since it's dereferencing the
wrong object for the dialog, not only does that not update, but attempting to
get the properties of any image always shows those of the one from the first
USE of the properties dialog (not necessarily the first image in the directory).
This is a major design error rather than a simple implementation bug, but the
bigger problem is image_thumb_changed_cb() failing to handle null thumbnails
correctly. Since that's a valid return from eog_thumbnail_load(), this is a
pre-existing bug in eog (##). The best fix for that bug is probably to just use
image-loading or image-missing, and that's very convenient, because
correcting the design would be a huge amount of work, but once we have this
other fix we can leverage that to fix the original bug as well, like so:
eog_thumbnail_load (EogImage *image, GError **error)
{
g_object_ref( eog_missing_image );
return eog_missing_image;
}
and all we have to do to wrap things up is add eog_missing_image to eog-
thumbnail.c as a static and initialise it in eog_thumbnail_init.
## This bug may well be what Felix really meant: it's not so much that
there are any genuine reasons for the thumbnail-dependency, just that
there are parts of the implementation that don't cope properly with them
being absent.
Given the existing code this is about as non-invasive as you can get;
and it fixes the bug. Those are two pretty compelling arguments for it
as a solution.
Note that this is the *correct* implementation of a Nautilus-equivalent Never
Create Thumbnails setting.
It's arguably not the most *desirable* implementation for eog though, because
it essentially makes the image collection function useless. Preserving
support for that is only slightly more work: all you have to do is replace the
flag with a policy: Never; RAM-only; Persistent and add another half-dozen
lines. So I've done that too.
Although I personally don't find image collection useful anyway, even that
second approach is a significant improvement over the current behavior, because
it saves all the IO (and file system pollution, security issues, etc). It
does come with CPU and RAM costs, but we've already established that the CPU
cost is trivial; and although the RAM cost is ?64K+overhead? per image, if you
do want thumbnails you have to accept that they don't come for free.
--
Anyway, getting back to the original bug:
Whether the bug is that eog doesn't have its own setting or it doesn't
honor Nautilus's ...
eog has its own gconf schema, so that's where it belongs. Users will
continue to *expect* that Nautilus's setting has global effect, but that
ship's long since sailed.
For Nautilus, the flag is apps/nautilus/preferences/show_image_thumbnails.
eog has 4 subkeys: full_screen, plugins, ui, view; none of which are really an
appropriate place for this.
GNOME says it prefers that apps not use the (app) root node for keys,
but since gconf-editor doesn't allow the creation of subnodes and plenty
of official GNOME apps ignore that anyway, we will too.
apps/eog/thumbnail_policy (int)
0 - Never create thumbnails (or use them even if they exist).
This matches the behavior of the Nautilus setting.
1 - Create and use thumbnails, but don't write them to disk.
This preserves all of the current functionality while removing the IO
thrash (nice for SSD, important for USB or non-local /home)
2 - Save thumbnails
As pre-patch
===
Sebastien: sorry for the lack of clarity last night. This is a proper
fix for the bug, fully tested, not some random hack; and from what Mike
says it's *at worst* consistent with the gThumb (and Nautilus) behavior,
and arguably a superset of it.
--
You received this bug notification because you
[Bug 526925] [NEW] delete does not work
Public bug reported: Binary package hint: eog (no apport - it failed to ever complete after over a minute, and btw, the cancel button on it doesn't work) not a dupe of #42571, since that's supposedly fixed - despite reports to the contrary since the claimed fix... also not a dupe of #192629, since that says can't move to trash and then offers delete. eog in current 9.10 does neither. file on ntfs partition cannot be moved to trash in eog, and can't be deleted outright because eog is also ignoring the preferences specified in nautilus to allow real deletes, and has no such option of its own. file is 777, and can be rm'd from a terminal. *nautilus* exhibits the (correct) behavior of 192629. eog is simply broken. Error on deleting image foo bar.tga Couldn't access trash. as an aside, eog also whines for confirmation of move to TRASH, which is about as redundant and user-time-wasteful as you can get. how many prompts do you need for a RECOVERABLE action? ** Affects: eog (Ubuntu) Importance: Undecided Status: New -- delete does not work https://bugs.launchpad.net/bugs/526925 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 523241] [NEW] mouse motion_acceleration key
Public bug reported: Binary package hint: gconf-editor setting to 0 by double-clicking on the key and getting the *dialog box* turns into 1.1754943508222875e-38 etc setting to -1 in the dialog is reset to 0 both work correctly if edited directly into the value column short description is single click (yes, this is technically 3 bugs, split them or not as you wish) ProblemType: Bug Architecture: i386 Date: Wed Feb 17 07:04:53 2010 DistroRelease: Ubuntu 9.10 ExecutablePath: /usr/bin/gconf-editor InstallationMedia: Ubuntu 9.10 Karmic Koala - Release i386 (20091028.5) Package: gconf-editor 2.28.0-0ubuntu1 ProcEnviron: LANG=en_US.UTF-8 SHELL=/bin/bash ProcVersionSignature: Ubuntu 2.6.31-19.56-generic SourcePackage: gconf-editor Uname: Linux 2.6.31-19-generic i686 XsessionErrors: (gnome-settings-daemon:1587): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed (gnome-settings-daemon:1587): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed (polkit-gnome-authentication-agent-1:1689): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed (nautilus:1683): Eel-CRITICAL **: eel_preferences_get_boolean: assertion `preferences_is_initialized ()' failed (firefox:1762): GLib-WARNING **: g_set_prgname() called multiple times ** Affects: gconf-editor (Ubuntu) Importance: Undecided Status: New ** Tags: apport-bug i386 -- mouse motion_acceleration key https://bugs.launchpad.net/bugs/523241 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 523241] Re: mouse motion_acceleration key
** Attachment added: Dependencies.txt http://launchpadlibrarian.net/39305095/Dependencies.txt ** Attachment added: ProcMaps.txt http://launchpadlibrarian.net/39305096/ProcMaps.txt ** Attachment added: ProcStatus.txt http://launchpadlibrarian.net/39305097/ProcStatus.txt -- mouse motion_acceleration key https://bugs.launchpad.net/bugs/523241 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 522714] [NEW] gdm simple-greeter ignores gconf settings
Public bug reported: gconf-editor / apps / gdm / simple-greeter / settings-manager-plugins / sound / active: unchecked gdm still plays the incredibly annoying drums when showing the login panel after a logout (it may also play them on first-logins, but i can't tell because of pulse/alsa auto-mute-on-startup bugs) ** Affects: ubuntu Importance: Undecided Status: New -- gdm simple-greeter ignores gconf settings https://bugs.launchpad.net/bugs/522714 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 522714] Re: gdm simple-greeter ignores gconf settings
** Changed in: ubuntu Status: New = Invalid ** Changed in: ubuntu Status: Invalid = New -- gdm simple-greeter ignores gconf settings https://bugs.launchpad.net/bugs/522714 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 522714] Re: gdm simple-greeter ignores gconf settings
jep, that's why i set it to invalid. then i reopened it to put the right key in for the next of the 5000 people looking for a way to disable it, but it took 20 minutes to find it. $ sudo -u gdm gconftool-2 --set /desktop/gnome/sound/event_sounds --type bool false sorry to have wasted your time - perhaps some day gnome will actually add the gui for this to admin/login in so they don't waste everyone else's. -- gdm simple-greeter ignores gconf settings https://bugs.launchpad.net/bugs/522714 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 521343] [NEW] package grub-pc 1.97~beta4-1ubuntu4.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1
Public bug reported: Binary package hint: grub2 grub crashed during 9.10 auto-update after first reboot after installing to a new machine. apparently (faict) because after diffing my+upgrade /etc/default/grub, i clicked back and it wanted me to click forward instead, as ridiculous as that sounds. since the answer to do you want file A or file B? was actually neither: i want to edit the file to fix it, there may have been a contention at that point that grub failed to check or handle properly. debconf (understandably) sulked a lot when grub crashed. don't know if it also duped 472298, since i haven't rebooted yet. (funnily enough, after a dozen perfect installs on all sorts of different hw, this one has been terrible so far. i'd be willing to bet i can hit well over 25 papercuts from install and initial configuration alone, without. seriously). :/ ProblemType: Package Architecture: i386 Date: Sat Feb 13 02:39:33 2010 DistroRelease: Ubuntu 9.10 ErrorMessage: subprocess installed post-installation script returned error exit status 1 InstallationMedia: Ubuntu 9.10 Karmic Koala - Release i386 (20091028.5) Package: grub-pc 1.97~beta4-1ubuntu4.1 ProcVersionSignature: Ubuntu 2.6.31-14.48-generic SourcePackage: grub2 Title: package grub-pc 1.97~beta4-1ubuntu4.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 Uname: Linux 2.6.31-14-generic i686 ** Affects: grub2 (Ubuntu) Importance: Undecided Status: New ** Tags: apport-package i386 -- package grub-pc 1.97~beta4-1ubuntu4.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 https://bugs.launchpad.net/bugs/521343 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 521343] Re: package grub-pc 1.97~beta4-1ubuntu4.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1
** Attachment added: AptOrdering.txt http://launchpadlibrarian.net/39141543/AptOrdering.txt ** Attachment added: Dependencies.txt http://launchpadlibrarian.net/39141544/Dependencies.txt ** Attachment added: Dmesg.txt http://launchpadlibrarian.net/39141545/Dmesg.txt ** Attachment added: DpkgTerminalLog.txt http://launchpadlibrarian.net/39141546/DpkgTerminalLog.txt -- package grub-pc 1.97~beta4-1ubuntu4.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 https://bugs.launchpad.net/bugs/521343 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
