do I modify /etc/pacman.conf — add IgnoreGroup = plasma
to keep Plasma v6.5 active while v6.6 is debugged ?
do I modify /etc/pacman.conf — add IgnoreGroup = plasma
to keep Plasma v6.5 active while v6.6 is debugged ?
NOT a good idea…
Better to not update at all instead.
Or, if these types of things are overwhelming for you (or disrupt your workflow or experience too much), switch to openSUSE Tumbleweed Slowroll. It’s a rolling release with updates once a week or twice a month and was made for users who want to avoid exactly these kinds of issues.
Slowroll: https://en.opensuse.org/Portal:Slowroll
Oh, and before you say “But it’s in beta!”, Arch Linux is in beta
.
That’s why we get all the bugs.
PS: Just kidding. But it can feel that way sometimes.
I’m not familiar, so honest question: How does Slowroll help? Are they explicitly slowrolling KDE plasma? Because if it’s just fewer releases, what’s preventing a snapshot just after a new KDE plasma release? Or kernel release? Or mesa release? Are they holding back packages and patching them, even if upstream is newer? What make them decide that e.g. 6.6.0 is broken - what is the threshold/metric of plasma bugs to consider a release broken?
That’s not how it works. Think of Slowroll as a snapshot-based rolling release. I mean, regular Tumbleweed is the same, but for TW it’s daily.
For Slowroll, they test the packages for a week to a month, then send out the snapshot to users. Kinda like Manjaro, but longer.
If you’ve ever used something like Ubuntu Studio, for instance, you’d have the best KDE Plasma experience possible, but based on an older version with all the bug fixes backported.
So, no, there would be no zero-day bugs because the snapshots are tested and bug fixed first before they are sent out.
This, of course, doesn’t stop you from getting a lingering bug that has taken time to be fixed and was still not fixed upstream prior to the snapshot.
The idea is to limit the number of bugs a rolling release is likely to encounter.
So they are always rolling forward, and after testing release a snapshots they consider stable, or are they also backporting to fix and stabilize snapshots they want to release?
Always rolling with a longer snapshot release schedule that TW, so that the issues present on day one are likely fixed by the time users update.
Thanks. Interesting. ![]()
With an understanding of “Partial upgrades are unsupported” there is a memory problem affecting some users, not just me. This memory issue is not a problem with Plasma 6.5.
My system runs well when I revert to Plasma 6.5 and when updating, not allowing the 6.6 update to run.
So my alternative to modifying /etc/pacman.conf — add IgnoreGroup = plasma, is to switch to a different linux distribution ?
I’m just going to keep Rolling. I haven’t had any issues on any of my systems with Plasma 6.6 ![]()
It’s your system. To be honest, just do as you see fit. But just realize that partial upgrades may break your system.
To directly answer your question, yes. Perhaps another slow-roll, or static distro my be better for you.
What’s the problem??
EDIT:
Plasma 6.6.1 update is just around the corner. It’s been released already. It just hasn’t hit Arch repos yet. Perhaps that may address any “memory issues” you may be experiencing.
What @UncleSpellbinder said.
TL;DR: Don’t marry yourself to a distro simply because you are part of its community. Use what works for you.
I made a suggestion, not an assertion. On weekends and after work, I’ve been using MX Linux for the last year and half, and regular Tumbleweed for the last month. I learned about Slowroll, and based on my experience with Tumbleweed and Arch-based distros, I realized the benefits of Slowroll, so I suggested it to you based on your original post.
On Arch, every big KDE Plasma, Gnome, Cinnamon, Grub, etc. update causes issues for a subset of users. On regular Tumbleweed, I didn’t experience the freezing I experienced on Arch, even though I updated it the same day 6.6 was released. This means that Slowroll users would not even know such issues existed if they stayed in their bubble.
Linux is about freedom of choice and individuality. Although I’m part of the EndeavourOS community because I used to use it daily, I don’t use EndeavourOS at all anymore.
This is due to an issue with using Noisetorch/EasyEffects. An issue I’ve recently learned that is due to EndeavourOS’s default ALSA/Pipewire/Wireplumber settings. I’ve since found out that I can just copy the settings from the Arch distro I’ve been using (Archcraft) to seemingly any distro (I’ve done it with Tumbleweed and MX Linux) and things will work properly.
So, if Arch’s constant and quick updates are causing issues you can’t handle, switch to something you can that is more suited for your needs and/or patience.
For anyone interested in testing this, the folders I copied from Archcraft are:
usr/share/alsa
usr/share/alsa-card-profile
usr/share/pipewire
usr/share/wireplumber
You would need to do this as root, so make a backup of the EndeavourOS folders and the Archcraft folders like so:
usr/share/alsa-distroName
usr/share/alsa-card-profile-distroName
usr/share/pipewire-distroName
usr/share/wireplumber-distroName
After this, backup your user’s Wireplumber settings and restart your device.
mv .local/state/wireplumber .local/state/wireplumber-bkp
PS: I’m thinking of copying Tumbleweed’s KDE Plasma settings over to an Archcraft installation to see if it would fix the speed issues I’ve mentioned in another topic. My KDE experience on Tumbleweed has been smooth, but laggy on Arch (for Archcraft - current, ArcoLinux, XeroLinux, and EndeavourOS - in the past).
Oh, and I imagine that updating Tumbleweed will wipe out my Archcraft modifications, so I will see what happens the next time alsa/pipewire/wireplumber are updated.
I may need to “just” create my own personal distro. ![]()
I concur with @ddnn.
Use what suits your needs and what you enjoy using, because in the end, it’s you and only you who is using your system. I currently use Ubuntu 25.10, because even though I had no issues with my latest EOS install, I realized, that in the end, working in shifts is not necessary the best combination with rolling release right now and I don’t have energy to get something to work, if there’s need for something to work right at that moment.
Although this community is build around EOS, it doesn’t mean that you have to use EOS to be part of it.
I did not know that openSUSE had a Slowroll. Will have to check it out. Thanks .
I heard that the issue with openSUSE is the lack of LTS Kernel branches, i.e. 6.12.x/6.6x or the latest Linux kernel releases like 6.18/6.19 or the zen kernel or Liquorix Linux Kernels?
Can you please elaborate on this? Is this because of a specific combination of cpu+gpu or a particular brand computers, like dell/hp/asus/etc?
I have also held off updating for the past few days, to see the dust settle for the new Plasma-Login-Manager introduction. Your info would help.
@ddnn what is the issue with Noisetorch/EasyEffects? Can you please give more details?
You’re welcome.
You can check this out. I’ve “pre-filtered” it to show Slowroll packages since you seem interested in that, but you can filter it to other versions as you like. The newest mainline and LTS kernels are available. I’m not that experienced with their system yet, though, so I’m not sure how to list all the available kernels.
openSUSE Repos Link: https://software.opensuse.org/search?baseproject=openSUSE%3ASlowroll&q=kernel
The issue is that on some distros, when I use Noisetorch or EasyEffects, my microphone sounds like I’m not using a dedicated mid-tier mic, and instead sounds like I’m using my built-in microphone with passable and very inconsistent noise cancellation.
So far, this has been the case for all the distros I’ve tested in the last 6 years since I’ve been using this microphone, except Archcraft and Ubuntu Studio. On either of these distros, when I’m speaking to my clients or colleagues, they sometimes compliment the quality. On other distros, I can see their faces wince when I’m speaking, and I get the frequent “Hold on. I’m hearing a noise in your background.”
This has been my main reason for going with Archcraft as my daily driver. It’s an issue I now know I can fix with a simple copy and paste.
Makes me think of this meme:
For anyone considering Slowroll or even regular Tumbleweed, please know that your mileage may vary. My experience has been awesome so far in terms of the speed and stability of KDE, but yours may not. My system may just not like Arch’s version of KDE? I really have no idea why it’s different.
Also, you can implement your own “Arch Slowroll” by simply updating once a month.
The main difference between this and the actual Slowroll, though, is that you can safely install updates every day on Slowroll knowing that the snapshot you are updating to has been thoroughly tested for a while. So, no, it’s not a case where there aren’t daily updates. It’s just that the updates are always like a week or more old when you receive them.
I will just sum up what I would do, Not update yet and do it next week to see if any bugs arise, I left mine til yesterday and hadn’t checked in weeks (no issues but lett it just in case at the time)
Moment of truth? A Pipewire update. Will it wipe out my copy and paste fix?
Rebooting to find out then bedtime.
All good!
Notice that the snapshot date shows Feb 24 even though this is regular Tumbleweed. This is because both Slowroll and TW get extensive testing.
It’s not about bleeding edge. It’s about leading edge.
At the end of the day it’s exactly the same plasma 6.6.0 though.
To be honest, 95% of problems are people who use outdated themes or widgets, slow rolling doesn’t matter for them. The other 5% don’t pay attention to package management when updating or have a different underlying issue but aren’t solving it.