| View previous topic :: View next topic |
| Author |
Message |
__name__
n00b
Joined: 06 Feb 2024
Posts: 46
Location: where the wind blows
|
 Posted: Wed Jul 10, 2024 6:03 am Post subject: [SOLVED] Update packages in custom set to masked version |
 |
|
I have a custom set for my kde plasma packages, is there a simple way other than unmasking the kde*/* wildcard and then adding all the dependency keywords and use flags?
my kde plasma is 5.27 but I am interested in trying kde plasma 6.1.2 however I don't use the plasma-meta package.
Last edited by __name__ on Thu Jul 11, 2024 4:43 am; edited 1 time in total |
|
| Back to top |
|
 |
logrusx
Advocate
Joined: 22 Feb 2018
Posts: 2418
|
| Posted: Wed Jul 10, 2024 9:41 am Post subject: |
|
|
I read this several times and didn't understand it. Could you please clarify what your question is?
Best Regards,
Georgi |
|
| Back to top |
|
|
__name__
n00b
Joined: 06 Feb 2024
Posts: 46
Location: where the wind blows
|
| Posted: Thu Jul 11, 2024 12:02 am Post subject: |
|
|
| logrusx wrote: | I read this several times and didn't understand it. Could you please clarify what your question is?
Best Regards,
Georgi |
What part are you not understanding? I will try to clarify that.
I'm referring to a user defined custom portage set as described here: https://wiki.gentoo.org/wiki/Package_sets#Custom_sets
I have defined my own custom-plasma set instead of using the plasma-meta package to install plasma desktop, etc.
I want to know if there is a way to update my custom-plasma set to a masked version ie. 6.1.2 as my set is currently based on the 5.27.11 packages which are the current stable release.
Here are the packages I have defined in my custom-plasma set:
| Code: | $ cat /etc/portage/sets/custom-plasma
kde-apps/dolphin
kde-apps/konsole
kde-apps/kwalletmanager
kde-frameworks/breeze-icons
kde-frameworks/kconfig
kde-plasma/bluedevil
kde-plasma/breeze
kde-plasma/breeze-grub
kde-plasma/drkonqi
kde-plasma/kactivitymanagerd
kde-plasma/kde-cli-tools
kde-plasma/kdecoration
kde-plasma/kdeplasma-addons
kde-plasma/kgamma
kde-plasma/khotkeys
kde-plasma/kinfocenter
kde-plasma/kmenuedit
kde-plasma/kscreen
kde-plasma/kscreenlocker
kde-plasma/ksshaskpass
kde-plasma/ksystemstats
kde-plasma/kwallet-pam
kde-plasma/kwayland
kde-plasma/kwayland-integration
kde-plasma/kwin
kde-plasma/layer-shell-qt
kde-plasma/libkscreen
kde-plasma/libksysguard
kde-plasma/libkworkspace
kde-plasma/libplasma
kde-plasma/milou
kde-plasma/plasma-browser-integration
kde-plasma/plasma-desktop
kde-plasma/plasma-integration
kde-plasma/plasma-pa
kde-plasma/plasma-systemmonitor
kde-plasma/plasma-workspace
kde-plasma/plasma-workspace-wallpapers
kde-plasma/polkit-kde-agent
kde-plasma/powerdevil
kde-plasma/sddm-kcm
kde-plasma/systemsettings
kde-plasma/xdg-desktop-portal-kde |
Last edited by __name__ on Thu Jul 11, 2024 1:01 am; edited 2 times in total |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22648
|
| Posted: Thu Jul 11, 2024 12:44 am Post subject: |
|
|
| Your set has no version qualifiers, so I would expect that Portage should automatically pick the best available version of each of those atoms, subject to keyword constraints, mask constraints, etc. You first wrote that you want to match masked versions, and now you write that you want it to be an unmasked version. Which is it? |
|
| Back to top |
|
|
__name__
n00b
Joined: 06 Feb 2024
Posts: 46
Location: where the wind blows
|
| Posted: Thu Jul 11, 2024 1:00 am Post subject: |
|
|
| Hu wrote: | | Your set has no version qualifiers, so I would expect that Portage should automatically pick the best available version of each of those atoms, subject to keyword constraints, mask constraints, etc. You first wrote that you want to match masked versions, and now you write that you want it to be an unmasked version. Which is it? |
I mistakenly typed the "unmasked".
kde plasma 6 is currently masked, correct?
So I am wanting to unmask kde plasma 6 but only install/upgrade the packages within my custom set.
It seems to me that I can just add version qualifiers in my set definition as you alluded to, correct?
Thanks. |
|
| Back to top |
|
|
kimchi_sg
Advocate
Joined: 26 Nov 2004
Posts: 3038
|
| Posted: Thu Jul 11, 2024 1:04 am Post subject: |
|
|
| __name__ wrote: |
kde plasma 6 is currently masked, correct? |
It is only masked by keyword, not by package.mask, the distinction is important.
mask by keyword = unmask via package.accept_keywords (or do nothing if you default to running ~arch)
mask by package.mask = unmask via package.unmask |
|
| Back to top |
|
|
__name__
n00b
Joined: 06 Feb 2024
Posts: 46
Location: where the wind blows
|
| Posted: Thu Jul 11, 2024 1:30 am Post subject: |
|
|
| kimchi_sg wrote: | | __name__ wrote: |
kde plasma 6 is currently masked, correct? |
It is only masked by keyword, not by package.mask, the distinction is important.
mask by keyword = unmask via package.accept_keywords (or do nothing if you default to running ~arch)
mask by package.mask = unmask via package.unmask |
Thanks for this clarification. I understood that but your clarification certainly solidifies my understanding.
Is there a simple way I can add version qualifiers to my custom set definition? Maybe with a simple bash script? |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22648
|
| Posted: Thu Jul 11, 2024 2:23 am Post subject: |
|
|
| Adding version qualifiers will not, on its own, fix anything. With no qualifier, Portage picks the best available version. With a qualifier that requests an unavailable version, you will get an error and be forced to make other changes to accept that unavailable version. |
|
| Back to top |
|
|
__name__
n00b
Joined: 06 Feb 2024
Posts: 46
Location: where the wind blows
|
| Posted: Thu Jul 11, 2024 2:50 am Post subject: |
|
|
| Hu wrote: | | Adding version qualifiers will not, on its own, fix anything. With no qualifier, Portage picks the best available version. With a qualifier that requests an unavailable version, you will get an error and be forced to make other changes to accept that unavailable version. |
So adding the wildcard kde-*/* ~amd64 to /etc/portage/package.accept_keywords/custom-plasma would unmask the packages I am using (as well as all the matching packages) but this is really the only way, correct?
And this will most likely require dependencies to be unmasked via the ~amd64 keyword. |
|
| Back to top |
|
|
__name__
n00b
Joined: 06 Feb 2024
Posts: 46
Location: where the wind blows
|
| Posted: Thu Jul 11, 2024 4:42 am Post subject: |
|
|
| __name__ wrote: | | Hu wrote: | | Adding version qualifiers will not, on its own, fix anything. With no qualifier, Portage picks the best available version. With a qualifier that requests an unavailable version, you will get an error and be forced to make other changes to accept that unavailable version. |
So adding the wildcard kde-*/* ~amd64 to /etc/portage/package.accept_keywords/custom-plasma would unmask the packages I am using (as well as all the matching packages) but this is really the only way, correct?
And this will most likely require dependencies to be unmasked via the ~amd64 keyword. |
I gave this a go and it is not so simple and begins to pull in many more packages than I probably want however I guess they could be required dependencies but at this point I'll wait a little longer.
I'm going to mark this SOLVED and not worry about it.
I may just move to the global ACCEPT_KEYWORDS="~amd64" in make.conf soon though I'll have to see what that entails...
Thanks everyone. |
|
| Back to top |
|
|
logrusx
Advocate
Joined: 22 Feb 2018
Posts: 2418
|
| Posted: Thu Jul 11, 2024 6:47 am Post subject: |
|
|
| __name__ wrote: |
What part are you not understanding? I will try to clarify that. |
All of it. You tried to stuff too much information into too few words with too little context. Maybe I would have understood that if your system was my system.
| __name__ wrote: | | __name__ wrote: | | Hu wrote: | | Adding version qualifiers will not, on its own, fix anything. With no qualifier, Portage picks the best available version. With a qualifier that requests an unavailable version, you will get an error and be forced to make other changes to accept that unavailable version. |
So adding the wildcard kde-*/* ~amd64 to /etc/portage/package.accept_keywords/custom-plasma would unmask the packages I am using (as well as all the matching packages) but this is really the only way, correct?
And this will most likely require dependencies to be unmasked via the ~amd64 keyword. |
I gave this a go and it is not so simple and begins to pull in many more packages than I probably want however I guess they could be required dependencies but at this point I'll wait a little longer.
I'm going to mark this SOLVED and not worry about it.
I may just move to the global ACCEPT_KEYWORDS="~amd64" in make.conf soon though I'll have to see what that entails...
Thanks everyone. |
This is a bad approach. Portage will pick more than you needs and ask for more changes than necessary. You should start with adding a more general package to package.accept_keywords that'll pull the testing versions of most of the dependencies required, then make your way up to the more specific packages you want to use. kde-plasma/plasma-workspace looks like such package. Using one of the autounmask options you can get as many packages to be added to package.accept_keywords as possible at once. You can combine this with putting ACCEPT_KEYWORDS="~amd64" on the command line and inspecting the output of emerge. However this way you lose a very important part of the output - the ~ sign in front of the packages added to package.accept_keywords, which makes it a bit less useful. BUT DO NOT LET THIS COMMAND GO, JUST USE THE OUTPUT.
You can temporarily comment lines from your set so you don't have to deal with too many errors at once. The uncomment them one by one until you fix all errors.
If you want to try something, I'm here to help, just report what you did with the full command and its output.
Another tip I can give you is use separate files in package.use/accpet_keywords so that if you can stash them away if you decide to revert back easily.
Best Regards,
Georgi |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 9270
|
| Posted: Thu Jul 11, 2024 10:44 am Post subject: |
|
|
KDE overlay has readymade unmask files for all of this, but that still leaves kf6compat USE in use.stable.mask.
Either way this is opening a can of worms for people not used to solving portage conflicts, going forward.
Making matters worse, OP has declared to not use plasma-meta. Do they know why? |
|
| Back to top |
|
|
__name__
n00b
Joined: 06 Feb 2024
Posts: 46
Location: where the wind blows
|
| Posted: Thu Jul 11, 2024 7:05 pm Post subject: |
|
|
| logrusx wrote: | | __name__ wrote: |
What part are you not understanding? I will try to clarify that. |
All of it. You tried to stuff too much information into too few words with too little context. Maybe I would have understood that if your system was my system.
|
I have a hard time expanding my thoughts. Sorry.
| logrusx wrote: | | __name__ wrote: | | __name__ wrote: | | Hu wrote: | | Adding version qualifiers will not, on its own, fix anything. With no qualifier, Portage picks the best available version. With a qualifier that requests an unavailable version, you will get an error and be forced to make other changes to accept that unavailable version. |
So adding the wildcard kde-*/* ~amd64 to /etc/portage/package.accept_keywords/custom-plasma would unmask the packages I am using (as well as all the matching packages) but this is really the only way, correct?
And this will most likely require dependencies to be unmasked via the ~amd64 keyword. |
I gave this a go and it is not so simple and begins to pull in many more packages than I probably want however I guess they could be required dependencies but at this point I'll wait a little longer.
I'm going to mark this SOLVED and not worry about it.
I may just move to the global ACCEPT_KEYWORDS="~amd64" in make.conf soon though I'll have to see what that entails...
Thanks everyone. |
This is a bad approach. Portage will pick more than you needs and ask for more changes than necessary. You should start with adding a more general package to package.accept_keywords that'll pull the testing versions of most of the dependencies required, then make your way up to the more specific packages you want to use. kde-plasma/plasma-workspace looks like such package. Using one of the autounmask options you can get as many packages to be added to package.accept_keywords as possible at once. You can combine this with putting ACCEPT_KEYWORDS="~amd64" on the command line and inspecting the output of emerge. However this way you lose a very important part of the output - the ~ sign in front of the packages added to package.accept_keywords, which makes it a bit less useful. BUT DO NOT LET THIS COMMAND GO, JUST USE THE OUTPUT.
You can temporarily comment lines from your set so you don't have to deal with too many errors at once. The uncomment them one by one until you fix all errors.
|
I assumed this was not the greatest of ways, but I didn't think about doing it package by package as you suggest.
If I start with plasma-workspace or plasma-desktop will they pull in the others in my set if those depend on plasma-workspace or plasma-desktop? I assume they may pull in new dependencies that are not in my set but this approach seems to me to require going through each package in my set until they are all unmasked, correct?
| logrusx wrote: |
If you want to try something, I'm here to help, just report what you did with the full command and its output.
|
Thanks, I appreciate it.
| logrusx wrote: |
Another tip I can give you is use separate files in package.use/accpet_keywords so that if you can stash them away if you decide to revert back easily.
Best Regards,
Georgi |
I already use separate files in my package.* folders. I group them by categories or something like the name of my set.
| asturm wrote: | KDE overlay has readymade unmask files for all of this, but that still leaves kf6compat USE in use.stable.mask.
Either way this is opening a can of worms for people not used to solving portage conflicts, going forward.
|
I realized I was missing the kf6compat USE flag when I looked at the output of ACCEPT_KEYWORDS="~amd64" emerge -avuDN @world
| asturm wrote: |
Making matters worse, OP has declared to not use plasma-meta. Do they know why? |
I am using a custom set for my plasma install because I know what types of programs I will use and I don't want unused programs on my system taking up space unnecessarily. I only have a 256GB nvme drive currently.
Can you explain how this is "Making matters worse"? |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 9270
|
| Posted: Thu Jul 11, 2024 8:06 pm Post subject: |
|
|
| plasma-meta does not install programs, it installs only the desktop. You won't even get dolphin or konsole from it. It is highly configurable through USE flags and makes sure you're not ending up with strange errors caused by missing "unnecessary" dependencies. |
|
| Back to top |
|
|
__name__
n00b
Joined: 06 Feb 2024
Posts: 46
Location: where the wind blows
|
| Posted: Thu Jul 11, 2024 8:19 pm Post subject: |
|
|
| asturm wrote: | | plasma-meta does not install programs, it installs only the desktop. You won't even get dolphin or konsole from it. It is highly configurable through USE flags and makes sure you're not ending up with strange errors caused by missing "unnecessary" dependencies. |
My set still pulls in the necessary dependencies for the programs within the set...
Like you said Konsole and Dolphin aren't pulled in with plasma-meta however those are programs I wanted and therefore added to my set.
If it is configurable through USE flags then that is essentially the same as my set however I can add programs that are not in plasma-meta.
There are programs in plasma-meta that are "unnecessary" for a minimally working desktop. I don't understand the problem. |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 9270
|
| Posted: Thu Jul 11, 2024 8:26 pm Post subject: |
|
|
A lot of people think they know what is necessary for a working desktop of their definition, until there is a problem, for which quite often someone else will spend time on finding out what's missing in the first place.
In this transition phase, additionally it makes sure to block dead-end cruft that would otherwise be left behind from Plasma 5 since there is no succeeding package version, getting it cleaned up on upgrade. Not doing that will end up as a big nasty Portage conflict, for which quite often someone else will spend time on finding out what it is. |
|
| Back to top |
|
|
__name__
n00b
Joined: 06 Feb 2024
Posts: 46
Location: where the wind blows
|
| Posted: Thu Jul 11, 2024 8:38 pm Post subject: |
|
|
| asturm wrote: | A lot of people think they know what is necessary for a working desktop of their definition, until there is a problem, for which quite often someone else will spend time on finding out what's missing in the first place.
In this transition phase, additionally it makes sure to block dead-end cruft that would otherwise be left behind from Plasma 5 since there is no succeeding package version, getting it cleaned up on upgrade. Not doing that will end up as a big nasty Portage conflict, for which quite often someone else will spend time on finding out what it is. |
I haven't had a problem related to my custom set as of yet and this is how I got my system working a couple years ago. I only recently started asking for help on the forums and "other people spending time on finding out what's missing" is their prerogative, my forum posts could have gone unanswered and I would have eventually figured out what was the problem. This is a community and community is what makes things like gentoo better.
I was simply curious about a way to unmask the packages that I have in my custom set, I wasn't having any problems with my system. I just wanted to further explore gentoo and kde plasma. Is that a problem? |
|
| Back to top |
|
|
logrusx
Advocate
Joined: 22 Feb 2018
Posts: 2418
|
| Posted: Thu Jul 11, 2024 9:20 pm Post subject: |
|
|
| asturm wrote: | A lot of people think they know what is necessary for a working desktop of their definition, until there is a problem, for which quite often someone else will spend time on finding out what's missing in the first place.
In this transition phase, additionally it makes sure to block dead-end cruft that would otherwise be left behind from Plasma 5 since there is no succeeding package version, getting it cleaned up on upgrade. Not doing that will end up as a big nasty Portage conflict, for which quite often someone else will spend time on finding out what it is. |
There's no need to make a big deal out of this. While I appreciate the time and effort you're putting into Gentoo, there's no need for you to deal with dependency conflicts for people who want to customize their installation. There are plenty of people here who can do it. I personally prefer this approach too, although I'm not using plasma. There are fewer surprises.
Best Regards,
Georgi |
|
| Back to top |
|
|
pietinger
Moderator
Joined: 17 Oct 2006
Posts: 5104
Location: Bavaria
|
| Posted: Thu Jul 11, 2024 9:27 pm Post subject: |
|
|
| __name__ wrote: | | [...] I just wanted to further explore gentoo and kde plasma. Is that a problem? |
No, of course that's not a problem ... but if our Gentoo developer of KDE/Plasma: @asturm gives good advice, you can follow it without hesitation 
I also love to have a minimal system and also use KDE/Plasma ... I have the two packages as a basis:
- kde-plasma/plasma-meta
- kde-apps/kdecore-meta
(everything else then individually).
Just check whether these two packages install something you don't want.
For example, I had the problem that I don't need (and don't want) "accessibility" and therefore deactivated the use flag globally ... which is unfortunately not completely possible due to a bug: I had to re-enable it for the package qtgui in package.use:
| Code: | # temporary because of bug: https://bugs.gentoo.org/916267
>=dev-qt/qtgui-5.15.11-r2 accessibility |
Guess who helped me ... 
_________________
https://wiki.gentoo.org/wiki/User:Pietinger |
|
| Back to top |
|
|
logrusx
Advocate
Joined: 22 Feb 2018
Posts: 2418
|
| Posted: Thu Jul 11, 2024 9:28 pm Post subject: |
|
|
| __name__ wrote: |
I have a hard time expanding my thoughts. Sorry. |
It's alright, I experience that often too. What helps in this cases is to take a step back and star over, formulating short sentences.
| __name__ wrote: |
So adding the wildcard kde-*/* ~amd64 to /etc/portage/package.accept_keywords/custom-plasma would unmask the packages I am using (as well as all the matching packages) but this is really the only way, correct?
And this will most likely require dependencies to be unmasked via the ~amd64 keyword. |
This can be used in conjunction with individual entries but ultimately, you would want to have only specific packages in package.accept_keywords. This will prevent future surprises.
| __name__ wrote: | I may just move to the global ACCEPT_KEYWORDS="~amd64" in make.conf soon though I'll have to see what that entails...
Thanks everyone. |
That'll move you to testing completely. Only thing you must be careful is if you go back, to keep packages like glibc and I'm not sure if there are others, at their current version, because downgrading it is not supported and known to break systems.
| __name__ wrote: | I assumed this was not the greatest of ways, but I didn't think about doing it package by package as you suggest.
If I start with plasma-workspace or plasma-desktop will they pull in the others in my set if those depend on plasma-workspace or plasma-desktop? I assume they may pull in new dependencies that are not in my set but this approach seems to me to require going through each package in my set until they are all unmasked, correct?
|
As I said earlier, ultimately you want only individual entries in package.accepet_keywords. The point is to identify them in as big chunks of packages as possible, so that you don't run countless emerge attempts for every single entry that requires ~amd64.
Sorry but it's very late here and I have to go to sleep. See you tomorrow.
Maybe start with KDE overlay as suggested by astrum, I guess it'll be easier for you to just try stuff until you decide if you want to stay with it. Then you can customize it more. In fact I often started with meta packages when I created my sets. Back then I run a very old and tired computer and I had no choice but to make everything possible to reduce the list of packages emerge was throwing at me.
Best Regards,
Georgi |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 9270
|
| Posted: Fri Jul 12, 2024 7:42 pm Post subject: |
|
|
__name__: I am merely sharing my opinion based on *a little* bit of experience - you can take it or not, just as much as I get to measure the extent of my support. Your set actually contains much more than what is necessary - it contains libraries not normally "visible" to the user that should not be pulled in by @selected, trading a perceived minimalism for technical debt. Right now your set is like a polluted @world file, guaranteeing failure on Plasma-6 upgrade attempt. This would not happen, too, if you were relying on kde-plasma/plasma-meta instead.
| logrusx wrote: | | I personally prefer this approach too, although I'm not using plasma. There are fewer surprises. |
They will be instantly surprised by Portage conflicts if they proceed with using their own set as shown.
And yes, as I mentioned in my first post in this thread, KDE overlay files (in Documentation subdir - I am not talking about the sets, which are mostly for maintenance purpose) are *absolutely* the way to go, because they limit the unmasking scope to current versions, not kicking off an avalanche of ever more entries going to your /etc/portage/ directories. |
|
| Back to top |
|
|
logrusx
Advocate
Joined: 22 Feb 2018
Posts: 2418
|
| Posted: Sat Jul 13, 2024 7:45 am Post subject: |
|
|
@astrum, you've made your point and it's heard. I still prefer my way and I'm ready to show it to someone else and gladly learn something along the way. Ultimately, it's OP's decision what to do. Although I myself might go the route you're suggesting for quicker results, if I was in this situation.
Best Regards,
Georgi |
|
| Back to top |
|
|
__name__
n00b
Joined: 06 Feb 2024
Posts: 46
Location: where the wind blows
|
| Posted: Sat Jul 13, 2024 6:41 pm Post subject: |
|
|
Taking in all the viewpoints provided here I decided that I would remove my set and utilize the plasma-meta and kdecore-meta packages taking advantage of the USE flags.
| Code: | $ cat /etc/portage/package.use/kde
kde-apps/kdecore-meta -webengine
kde-plasma/plasma-meta kf6compat sddm browser-integration colord crash-handler crypt desktop-portal discover display-manager firewall kwallet legacy-systray pulseaudio wallpapers smart xwayland -plymouth -cups -unsupported -sdk -oxygen-theme -webengine -flatpak -thunderbolt -wacom
# required by kde-plasma/kwin-6.1.2-r1::gentoo
# required by kde-plasma/plasma-desktop-6.1.2-r1::gentoo
# required by kde-plasma/plasma-meta-6.1.2::gentoo
# required by =plasma-meta-6.1.2 (argument)
>=x11-base/xwayland-23.2.6 libei |
I have successfully upgraded to kde plasma 6 with ease.
| Code: | $ cat /etc/portage/package.accept_keywords/kde
kde-apps/kdecore-meta ~amd64
kde-apps/* ~amd64
kde-frameworks/* ~amd64
kde-plasma/plasma-meta ~amd64
kde-plasma/* ~amd64
kde-misc/kio-fuse ~amd64
dev-libs/qcoro ~amd64
x11-misc/sddm ~amd64
gui-apps/xwaylandvideobridge ~amd64
media-libs/pulseaudio-qt ~amd64
dev-libs/kirigami-addons ~amd64
dev-libs/appstream ~amd64
dev-python/pygdbmi ~amd64 |
This thread has helped me learn a lot more about gentoo and that's always the best outcome. I appreciate everyone's input! Thanks. |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 9270
|
| Posted: Sat Jul 13, 2024 8:17 pm Post subject: |
|
|
| __name__ wrote: | | Code: | # required by kde-plasma/kwin-6.1.2-r1::gentoo
# required by kde-plasma/plasma-desktop-6.1.2-r1::gentoo
# required by kde-plasma/plasma-meta-6.1.2::gentoo
# required by =plasma-meta-6.1.2 (argument)
>=x11-base/xwayland-23.2.6 libei |
I have successfully upgraded to kde plasma 6 with ease. |
Thanks for checking back, improvement in progress: https://github.com/gentoo/gentoo/pull/37547 |
|
| Back to top |
|
|
|
Portage & Programming
