I’m installing Ubuntu Budgie 19.10 on my Ryzen 3/3 (which has the Lubuntu daily installed from earlier today). I noticed when Bbuntu’s installer reaches the “erase, partition, something else” screen that it identifies the existing system as merely “Ubuntu Focal Fossa.”
That seems ambiguous. Shouldn’t that identify “Lubuntu Focal Fossa?” If so, I wanted to mention it in case it’s something controlled from Lubuntu’s side (how the daily image installed itself?). If it’s supposed to look the way it does, I’m fine. (Or, if it’s a Budgie issue, I can mention it to them.).
FYI: I installed 0228 daily image to my Ryzen 3/3. I added test results on QAtracker. But, I wanted to mention here that the “Screensaver Preferences” has two entries at the top of available screensavers which are grayed out. Named 14.0985 & 26.3163.
That doesn’t look right. I wasn’t sure if that warrants a bug report, or just a casual mention.
Ooh that’s fun. Never noticed that before. So a couple things to note:
The xscreensaver package (and its dependencies) includes a bunch of “available screensavers” (the upstream developer calls them “hacks”) but does not include all of them. This results in options being shown that are greyed out. You can install additional packages to add them. For example, see “WebCollage” or “BSOD” which are in separate packages that we don’t seed by default.
Outside of the two I mentioned, though, oddly, none of the greyed out options are shown in the upstream developer’s list of available hacks nor do I find it in the codebase.
I do seem to remember that “Wireframe” was a hack, but it seems that it’s actually an option (for example, look at “Settings” on “Flurry” and you’ll see you can actually run it from the command line as flurry -root -preset water and in this case, -preset water is an option. If you man flurry, you will find other options. A more interesting one is atlantis which includes the -wireframe option as well as several others), along with “Elasticity,” “Effect,” “Length,” and “Maxradius” (actually some of those might be variables used within the code rather than actually exposed options).
“Unicode” is not a hack, but “Unicrud” is. Luckily, “Unicrud” is showing, but I have no idea where “Unicode” comes from as it does not seem to be an option or a variable used in the code.
Nowhere do I see any reference to those two you mentioned.
I have an inkling that somehow the parsing of the list of available screensavers is somehow failing and it’s pulling information from the code itself and perhaps those two are values of particular variables.
HERE’S WHERE THINGS GET REALLY WEIRD: the same version of the source package has been used since 19.04/Disco Dingo. No changes. At all. And yet something is different.
Either way, looks like you have a bug to report (perhaps multiple ones) against the package.
ubuntu-bug is the command to use. If you want to go all out and then triage the bug and report it upstream as well, that’s another thing, but that would require you to ensure you have the latest upstream software (which likely means compiling it yourself) first.
FYI: I encountered the XScreenSaver (grayed-out oddball entries) again yesterday and opened bug 1865381
I’m still experiencing a 20-second black screen before seeing the desktop (on my Ryzen 5 3500/Vega 8). I still feel like this isn’t a problem. (I think it’s just the nature of newer hardware not supported too well yet.). But, I was wondering if there’s something I could look at to see what’s happening during that period?
Also, would a progress indicator (until desktop appears) be feasible? I’ve seen distros that have a spinning wheel. But, I don’t know if such an indicator would persist through such hiccups? (Maybe they look nice when things are working, but would disappear during problematic mode changes and such?).
On my other laptop, Lubuntu’s desktop pops up so quickly that a “working” indicator wouldn’t serve much purpose. But, when something odd happens, an indicator would be helpful (I’m just not sure how persistent it could be during oddness).
I’m testing 2020 0303 on an older Toshiba Satellite C55-B5299. In the Live Dekstop, I clicked nm-tray and typed the wrong wifi password. It did not give an error message saying it couldn’t connect. It just appeared to do nothing, And, it kept that connection. Trying to click that access point in nm-tray does nothing.
I right-clicked nm-tray, edit connections, fixed the password. It worked great after that.
Would that be considered a bug? To me, that behavior seems problematic. It silently lets you do the wrong thing, and acts like it’s doing nothing.
Also, I’m installing 2020 0303 on a disk that previously had MX Linux installed with / and /home partitions.
The installer doesn’t give me an “erase disk” option. It only lets me choose replace partition, install alongside, or manual partitioning.
If I choose manual partitioning, it objects to no partition having an ESP flag. But, when I look at the flags available (for that 510mb Fat32 partiton, there is no ESP flag available to set. When I started over and examined the existing partition, it has a “boot” flag set.
It sounds like the flag terminology is different between the warning I receive about the flag (which calls it ESP), and the flags available when I create it.
Bug: 1865949 nm-tray silently fails, saves connection
Bug: 1865955 Calamares warns of ESP flag, but the flag is called boot.
Question: In the QA tracker, would I say “fail” just because I opened a bug about other things? In my mind, I think the testcase itself succeeded, but I found a couple oddities. (Or, maybe because calamares is integral to the install testcase, it that one would be a fail? But, the boot LiveUSB testcase would be successful even though nm-tray has issues?).
I would say no. My reasoning is any bugs reported will be picked up by the system & suggested for later testers to look for in QA-testing. The QA testing is also about the testcase.
I usually just add the bug ID URL in the comment section, and add anything new to the bug report.
This is a really a good question. I updated the testing wiki on this point:
Do not mark a testcase as failed unless there is a critical error . This would mean a failed boot, a failed installation, crashes, lack of intended functionality, etc. Often when we’re right about to release, the Release Manager is scanning quickly to see the state of testing and these “false negatives” can be distracting. However, if in doubt, mark it as failed.
Something has apparently changed? I definitely tested the bad password on Feb 8, and it didn’t save it. Did you guys switch back to the not-so-robust nm-tray?
The strange thing is: Chris and the maintainer(?) can’t recreate what I’m seeing (the part about no progress nor failure msg. It’s like a bad password does nothing, but get saved as a “known connection.”).
I’m testing Xubuntu’s daily image right now. Its “nm-tray” seems good. I don’t know how all these things might (or might not) fit together. You mentioned using a gtk nm-tray. Would it be possible to use Xfce’s? (I’m assuming the gtk one is not being used now?).
What we switched is what would come up when you clicked on “Edit Connections” in the nm-tray right click menu. This was nmtui-edit, a ncurses-powered terminal application. We changed it to nm-connection-editor, which is a regular old GNOME thing.
I guess I misunderstood something. A month ago I tried a bad passphrase and praised nm-tray that that problem didn’t exist anymore. It seemed more robust than I remember in 19.04. You said something which sounded like it explained why nm-tray worked better.
Now it’s acting like 19.04 again, and I’m getting the impression it was never expected to be different. If that’s true, I’m ok with that. I just had the impression that that had changed. When I saw it behave like the old nm-tray I’m familiar with, I thought it was a problem. (I’m still unclear whether it is or isn’t).
Regarding the silent handling of a bad passphrase: when I test the Lubuntu daily again, I will use the journalctl you mentioned.
This part is strange to me because I’ve done it on three laptops, and they all do the same thing (silent handling of a bad passphrase). It’s hard to comprehend why three people are seeing a failure msg. I don’t see how that could be possible unless my daily image was bad. (The checksum matched. And, the files verified during boot.). Hopefully that’s what it is, and a new ISO will make it work the way you guys are experiencing.
We all did. tl;dr only passwords 8-63 characters are valid, but nm-tray appears to take invalid ones and silently fails. Other NetworkManager front ends just refuse to proceed, which is what we should have in nm-tray. Triaged.
Maybe I should mark this solved. This topic started off with my concern about Ryzen 3/Vega 3 (and Ryzen 5/Vega 8) laptops not being able to boot the upcoming LTS (not just Lubuntu, but any Ubuntu-base derivative). Then it turned into how to test. That turned into testing more generically, not just to ensure those laptops will work. (Then, testing more Lubuntu-specific issues.). The tread turned into a collection of topics.
This seems like a good point to call it all “solved.” I’ll start a new thread as more comes up.
