We’ve got them fixed now, but we need people to be testing the betas with their personal hardware setups! There’s simply no way for a small pool of KDE developers to test all of these hardware setups themselves.
I’d love to but can’t, unless there’s an easy way to install it onto my current setup and easily revert.
Installing neon or running it temporarily is not realistic, in fact I did that and never faced an issue.
In a nutshell, if I can install it on my Fedora system easily, I’ll forever be a beta tester, I have no problems with that.
Been testing Garuda’s new prereleases and in there Mokka after the install and reboot I did the updates that gave me Plasma 6.3. Did a reboot, added my leftside panel, wen into edit mode, attempted to clone it and the desktop crashed for a quick second and the panel wan’t duplicated. Tried twice more with the same results.
Unfortunately not every-distro allow this easily, and it is partly due to our release cycle that does not match classic bi-annual releaset distros (Ubuntu/Fedora). More on that on Nate’s blog.
That’s something I’d encourage Fedora KDE people to look at. This requires some work setting up the packaging and all that jazz.
Worse opening a bug for them.
Arch does have its KDE-unstable repo, and neon have Testing Edition, unstable and developer edition for this.
I might forget others.
Plasma 6.3 is out! So far the response has been very good, but of course a few issues were found once it was in the wild.
I find this a bit too sweet-coating, the reality is most of X11 users got a broken system if not all.
They represent supposedly about 20% of Plasma 6 user base (and decreasing).
That’s mostly a failure of a beta period and a testament that Wayland development has been and is the main focus.
Arch did backport the main fix to 6.3.0 so those users should be fine but not fedora, tumbleweed or neon users.
If you don’t mind spending some CPU time and have disk space to spare, setting up kde-builder to compile from master is relatively easy on Fedora as the requirements are typically up-to-date (lots of people use Fedora so it gets a good amount of testing). You can then just select the Plasma development version as you log in, and easily switch back. The new stuff will be kept in your home (except for registering a few things), so your Fedora stock Plasma session will not be affected.
You should be able to afford around 50-100 GiB of disk space for source code, output, and dependencies though, and be able to spare some CPU time (how much depends on how fast your computer is). And setup usually isn’t difficult, but does require pasting some commands (and maybe asking for help should it get stuck)
But I have 2 machines where My discover-notifier icon does not show up (from task manager it seems to be running, however) and no automatic update gets ready either…
anyone else with this problem???
About beta testing: I would also be open to it if there was an easy switch to enter beta testing in fedora (and out if I ever wanted)… I would gladly do it!!!
But the problem is it does not have a latest release branch, it is a repo compiled directly from git, so it offers nightly builds from master. If there were a way to enable “newest release branch”, then it would be useful.
I don’t mind testing a beta release or a rc release.
Actually it would be very nice to do so.
I’m using fedora atomic, so reverting should be easy to solve (just pin a snapshot and off we go), but I’m not aware of a easy way to enable unstable testing just for Plasma.
I was running the beta version of Plasma with Arch’s KDE unstable repos on a test machine. When the update to 6.3 landed, Plasma broke both for Wayland and X.
Why? Because a bunch of Qt libraries where still beta versions and didn’t play well with the now stable 6.3 version of Plasma.
The solution was to boot into Arch’s install medium, chroot (using arch-chroot) into the installation’s root directory and do a
pacman -Syuu --overwrite "*"
update to remove the beta libraries and substitute them with the stable versions.
FWIW, making it easier to test betas is a goal of the upcoming KDE Linux OS that’s being worked on: you’ll be able to download a new OS image with the beta release on it and test it out. If it breaks, you’ll be able to simply reboot into the OS image for the stable release.
Also, the bug reporting is maybe too cumbersome and time consuming for many people, especially when there is many bugs and they get fixed in few days during betas.
Maybe a simple KDE app, only available for beta testing, could allow testers to simply enter some details (reason, app, etc.), with screenshots and automatically provide all relevant system data (because it could be a lot of very technical details that most users won’t know how to get them), with user registered KDE bugs credentials (to prevent spam), and then just submit.
This wouldn’t create a ticket automatically but could be added to a database for triaging, and being ignored once fixed.
My experience with KDE betas is that it’s often minor UI glitches (often the bugs fixed very fast), or random crashes mostly of inactive apps that could take time to try to reproduce sometimes with no luck at all.
It would bear the burden on KDE contributors but could also much easily to find few rare bugs with much more details provided than with a single ticket.
On Bazzite, which is based on Fedora Atomic, I can run bazzite-rollback-helper rebase unstable to rebase to the unstable branch with Plasma 6.3.
Fedora Atomic (and other immutable distros) are perfect for this. Fedora Kionite could offer an unstable release of Kionite with the latest KDE Plasma version to which you can rebase. As you said reverting won’t be a problem.
You don’t need to build Qt, I just use my distro’s qt, same for the dependencies that kde-builder doesn’t handle.
I have all of Plasma built (workspace component so including apps assigned to Plasma like Discover), plus Dolphin, Kate, Konsole, and a few others. It’s less than 100gb total, including ccache, all the binaries and build directories etc, plus a few months of old logs I could clean out sometime. This is an almost 10 year old Thinkpad, so compilation speed isn’t great, but with ccache it’s ok, sometimes I just need to let it run for a bit (and the initial build is a bit annoying, that one took a while esp. for things like kwin).
I can’t speak to distrobox, I don’t have any experience with it. There’s some instructions on the wiki though. Personally I don’t see a reason unless your distro packages are too old, but I might be missing something - I’m just not a container-minded person.
Yes bro, that’s the point of basing it on Arch (amongst other reasons too) and it will be working the way SteamOS does (atomic image-based A/B updates with rollback functionality). You can read design details here: KDE Linux - KDE Community Wiki
The issue with Plasma 6.3. is rather a sign that Plasma releasing independently from distro release schedules is not an optimal scenario! Again we come back to the discussion surrounding releasing 3x a year vs 2x a year and align with release targets of the major distros, specifically Fedora and Ubuntu like GNOME does. The underlying distro matters as much as the Plasma release, so KDE OS makes sense!
Take the example of Fedora, Plasma 6.1 Beta aligned perfectly with Fedora 40 Beta, while Plasma 6.2. Beta aligned perfectly with Fedora 41 Beta. This time Plasma 6.3. released ahead of the beta testing stage of Fedora 42, so a lot less users were compelled to beta test Plasma 6.3. because they were happily using the latest stable Fedora 41 as there’s no beta for Fedora 42 yet, and like me couldn’t be bothered to install KDE Neon or whatever just to test Plasma 6.3. But how many people actually installed Plasma 6.3. Beta on top of Fedora 41 stable? Almost no one!!
Many people like me try Fedora Beta as soon as it’s out because it’s usually already in great shape and allows to get our hands on the newer kernel and hardware support sooner. Having the beta periods of Fedora and KDE overlapping was actually one of the most beneficial factors to smooth Plasma releases without major issues in Fedora 40 and Fedora 41. And let’s not forget KDE bugs are considered release blockers on Fedora! This bug with GCC compiler would very likely have been caught and fixed in a beta stage of Fedora! It’s no surprise to me that this time around the Plasma release was not as smooth.
Thank you so much for bringing attention to this. I would love to see this feature tested and talked about, it did not even get considered for the 6.3 beta.
The bikeshed debate on the visual presentation of the option constitutes the bulk of the discussion on that page, but hey, at least they’re considering allowing one measly row to honor a user’s choice. Hopefully this feature will make 6.4 for everyone else, but i’m kinda done pumping the bellows upstream.
As it were, I’ve had several discussions on the Matrix channels with the Kwin maintainers regarding this and other missing Overview features relative to the Desktop Grid that it replaced: They explicitly do not want the Overview effect to provide as many granular features and options to the user as the old Present Windows+Desktop Grid UX previously did, opting instead to try and assume the workflow of “most users”.
I disagree for several reasons and it makes me very concerned for how “polished” they’re willing to make other effects I use, but at this point i’m just working on a full Overview fork in my spare time. Not getting very far with it because of how much it links from other parts of Kwin that have to be included in the script, and it’s not very fun to go back to. Fun to write the actual feature but not to port!
You’re referring to the Overview’s Desktop Bar right, where it left-aligns when using several rows of virtual desktops and would normally top-align otherwise?
That’s definitely a case that we’d want feedback for, and I know it would also be useful as a manual choice on it’s own (Desktop Bar left-aligned, top-aligned, etc).
By the way, yes this is absolutely true, not just on Fedora. It’s feasible to do builds inside systemd-nspawn (or other) containers, and even run sessions from the container builds in real time by means of bind mounting the build directories.
Definitely worth the time setting up, one command and the whole project is refreshed and ready to test, with the host system un-touched.
You can do that today with Fedora Kinoite: Rebase to a version with the beta release, test, and when done, rollback.
We did not do a KDE Plasma Beta over stable Fedora build of Kinoite this time but we used to and I should start doing that again. It sounds lake it even less risky to test as you could daily drive it as only the KDE stack would be “unstable”.
Indeed openSUSE doesn’t have a beta preview version, at least AFAIK.
Though now I’m curious: does KDE actually have release candidate / beta branches? How does Fedora and Arch get their RC/beta versions, are those just snapshots?
I didn’t expect the first bug I filed to be such a doozy, but glad the root cause was quickly discovered!
I did just get a SATA-pluggable bay for one of my boxes, and have spare SSDs to install on. Should be easier to test betas and add debugging on physical hardware attached to devices I use, but not be one I absolutely rely on for regular work.
Thank you for making me (and others I assume) aware of what the situation is, to be honest I had never expected that, nor imagined it! I haven’t followed the discussion at all, because I was maybe naive thinking “it’s just a matter of time”, but for surely everything sounds completely absurd now! What is the problem of presenting the virtual desktops in an order way saner and less problematic (in my case having 6-8 useless, tiny Virtual Desktops with even tinier windows inside of them in a row! -even with 4 if you have some windows open you can’t recognize which is which-), especially when you have done everything so well and well-thought, covering all cases.
KDE is full of options and things and bells and whistles but the problem is the so much improved-now Grid View? I’m frankly speechless and extremely dissapointed tbh. Instead of being proud that some member picked this up and improved it, instead of embracing it, actively supporting it, cheering up for it and thanking for it, this was simply left to rot. I guess what matters with the new “direction” is not useful features but how the close button of notifications should look like instead, if the rounded corners should be 3px, 5px or 8px, or if the Breeze Theme should be 10% or 20% or 25% darker. Until I see that in 6.4, I’m out, disgusted by this new direction and contempt.
This discussion was in the Kwin Matrix room for reference, i’d voice feedback there
My big thing was that the Overview was initially intended to fully replace the old Grid+Window effects, and at first it was missing many features just to ship the new effect. Some were ported back (like hiding minimized windows, but there’s such reluctance now to add options back in. Disappointing thorn of an issue where the rest of KDE Plasma really does shine.
Or you could just boot normally, switch to another tty with alt + function keys, fix the issue (, logout of the broken session if you have autologin set up), move to the tty that shows your display manager and login.
Hi!
I’m using Tumbleweed and I would like to help with beta testing, but i also need my pc to resume working if something happen with the beta.
Is there some way to easily switch between stable and beta without restoring previuos snapshot?
Hi! I’m not familiar with specifics of Tumbleweed and beta software, but in general, the perfect state would be creating a dedicated OS installation on a separate hard drive, just for testing. That way, you get the safety of not installing anything over top of your existing system, and the testing accuracy of using your real, “bare metal” hardware.
If that’s not an option, a virtual machine can get you the relative safety, although it won’t as accurately reflect performance with your hardware. Dual-booting on a single drive is also an option, although partitioning always freaks me out
I would caution that, as far as I remember and understand it, the default configuration for snapshots in Tumbleweed covers system software, but not your own home directory files - so it seems like there’d be some risk in relying on a snapper rollback if you need to recover from a beta issue.
From the beta announcement page, click on “Download live images with Plasma” - in the “Ships the latest KDE release including Beta and Release Candidate” section, Fedora Rawhide is listed there with a link to download ISOs.
The only way I know is by using Krypton, which is 4 repositories. I named the four kdeu-something, where kdeu stands for kde-unstable, so I can force-upgrade to it with sudo zypper dup --from kdeu-apps --from kdeu-extra --from kdeu-kf6 --from kdeu-qt6 --force-resolution --replacefiles (possibly just a sudo zypper dup may suffice), and to revert back to Tumbleweed I can force-downgrade to it with sudo zypper dup --from oss --force-resolution --allow-vendor-change --allow-downgrade (as I renamed the default repo’s alias to oss). I have an old but similar explanation in My current Plasma Wayland from git :: rabbiticTranslator.
I used Krypton for a whole year like so on my main machine, switching back between the two occasionally. The only trick is you absolutely need to clear your ~/.cache after updates on Krypton. It still doesn’t change the fact that Krypton is everything from KDE built directly from git master (and therefore possibly more dangerous than a beta), but it’s definitely something you can do.
