They do but KDE has a problem: Plasma. Many of its components (like the almighty KWin) are separate but then Plasma is this bin that they throw all the other stuff in. And Plasma is BIG, too. So we don’t want Plasma. I’m pretty sure using their network tool would be problematic for us in this regard.
That’s terrible. I’m so sorry to hear that.
You mean that there are so many people or that there’s actually a corporation behind Ubuntu? If you mean the latter, it’s not really all that evident. Most folks working in Ubuntu (myself included) aren’t related to Canonical at all. In that sense, we’re more like Debian, which is where Ubuntu comes from and where many Ubuntu developers are also developers (such as @tsimonq2). Debian is big, has many contributors, has a bunch of different flavors and derivatives. The great thing about that is that many people can help with support.
FYI: I tested the 2020 0226 daily today on the Ryzen 5/Vega 8. I verified checksums (even though I should have to using zsynch), ran the command-line (md5sum) to verify the LiveUSB before booting it. Everything was fine.
At grub, I chose “verify media.” That again went a screen like it was booting, but hung after the “IOMMU error” I always get with other distros too. (I don’t think it’s related to that error. It’s just an immediate message that appears. Usually everything continues after that msg. I think it was hung on something else. It’s only mildly similar to the first daily image I tried, when it was hung on after that msg, and would periodically emit error msgs about a timing out on a hung cpu, etc. That’s the one I opened the bug report about. This hang doesn’t emit msgs. I don’t think it’s the same thing.).
When I rebooted & chose the first option (install, or try it. Whatever it says.), when Lubuntu started to boot, the check-media ran. It ran everytime I rebooted. I don’t know if that was due to my first (failed) attempt to run that. Or, if it’s now a part of the normal install? (I actually think that would make sense. If it’s that important to run that grub option, why not run it as the first step to reaching the desktop? Maybe write a success indicator to the boot media so that step can be skipped next time?).
After install (uneventful) and reboot, I still experienced the 20-second black screen before the desktop appears (5 seconds until the mouse pointer appears in center of screen. 15 seconds until the desktop appears). It’s not a problem to me. I don’t get that black screen when booting the LiveUSB. (Same kernel. Same Mesa driver.).
When the installed desktop appeared, there was a msg that updates were available. When I rebooted, the wifi wouldn’t work. Clicking my access point did nothing.
BTW: I noticed that the first boot after install remembers the wifi used during install. That’s a nice touch. I’ve seen some distros do that, some don’t.
I’ll open a bug report the next time. I’m nervous about opening bug reports if things are in a state of flux.
It’s a Qualcomm Atheros QCA6174 (driver: ath10k_pci). I fixed the problem by reinstalling the daily image.
I don’t know what the system update loaded, or if I was supposed to run it. If it happens again next time, I’ll open a bug report.
What did you think about running the media-verification by default the first time the media is booted? I’ve used Linux many years, and never knew the significance of that grub option. I bet new users wouldn’t. Why not run it by default the first time the install media boots? (I think I’ve seen a distro that does that. I can’t remember now.).
I imagine one strike against that idea is “curb appeal.” You want to boot fast and impress visitors. Get straight to the desktop before losing anyone’s interest. The average person might think “so and so boots faster, without that [whatever’s happening] delay.” But, maybe some explanatory text could say “This is the first time this media has been booted. This verification step will ensure it was created without errors. You’ll never see this again unless you create the boot media again, or choose the verify option from the grub menu.”
Also… this kind of goes back to my comment about heavy screen savers (in a lightweight distro). Isn’t 4 desktops a bit much? I can see having two in order to demonstrate the capability. New users might not know multiple desktops can be created if they don’t see it. But, four? I can’t think of any distro that starts with that many. Especially a lightweight distro.
Maybe creating those two extra doesn’t use that much more ram.
FYI: Today I installed daily 2020 0227 on my Ryzen 3/Vega 3. It appears the media check is happening by default. That might be a good idea. (I don’t know if people would be annoyed about it happening each time they boot the LiveUSB. Or, if this might be an opportunity to educate them when offering “skip” that it’s important to let it run at least once.
The grub menu item to run check media worked (it didn’t work yesterday on my Ryzen 5/8). I.e., it boots to the normal “install Lubuntu” grub menu item, and the check occurs before proceeding to the Live desktop. That’s what happens when I choose the first grub item. So, it seems superfluous to offer the “check media” option at grub. (But, if the unsolicited check only happened once when newly-created media is detected, then the grub menu option to check would make sense. Someone might want to do it someday long after the automatic check happens. I’m referring to my suggestion that this unsolicited check write something to the LiveUSB, and not perform the check again if that file is present on the LiveUSB.).
I’m getting the 5-second black screen, cursor appears, 15-second black. (That’s what I get on the Ryzen 5/8. I don’t think it takes as long on this Ryzen 3/3. I didn’t time it. But, definitely the 2nd part doesn’t take 15 seconds. Maybe 8-10 seconds. I’m pretty sure this didn’t happen the last time I installed a daily to the 3/3. It just went straight to the desktop. That’s why the 5- & 15-second delay stood out to me on the 5/8 machine. Seems like something changed since the last time I tried the 3/3. It’s not a problem though. Just an observation.).
There was no solicitation to apply updates (like yesterday’s daily on the Ryzen 5/8 machine, which left it with a broken wifi or nm-tray.).
I’m going to try to penetrate QA-Tracker today. I’ll also look at the “watch for these bugs” at the bottom of that page. Next time I’ll install to the 5/8 machine and report the grub media-check option hanging (if it does). But, it looks like the unsolicited media-check is happening by design. It happened today (on the 3/3 machine) before I even chose that on the grub menu. (I.e., it’s not a state that got stuck because I checked media first, and then it continued. It checked before I said to check. Again, that might be a good idea to do.).
No. Go read my reply to your original inquiry. There is zero difference.
I’ve come to learn it is. If you have further comments, please direct them at the Ubuntu Discourse post as this is something that affects all Ubuntu flavors.
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.