SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Having a separate theme altogether seems more predictable. If we went with overlays, we'd need to override the index.theme lookup definitions and take care about file conflicts. I concluded that it is probably not a problem to do fallback from Adwaita to AdwaitaLegacy, since in that case the two kinds of fallback (themeA -> themeB and foo-symbolic to foo) go in the same direction. This is why I presented a seperate package to be used but if we where to put them all together it would be best to use AdwaitaLegacy instead of putting the old icons with the new symbolic icons. This way the icon.theme file can appropriately use the correct icon theme.
Understood Pat, I am just simply stating that if we keep the new and the old if would be best to have 2 directories in the adwaita-icon-theme package (1) Adwaita and (2) AdwaitaLegacy that way users have the ability to switch between icon theme's if they so choose to.
This is why I presented a seperate package to be used but if we where to put them all together it would be best to use AdwaitaLegacy instead of putting the old icons with the new symbolic icons. This way the icon.theme file can appropriately use the correct icon theme.
OK, you have a point here. Perhaps it is easier to just go along with what upstream has presented, although my initial reaction was that it was a compromise between the two sides more than the best approach to the problem, which was that stuff had gone missing so put it back (or at least symlink to the previously supported icon names).
Understood Pat, I am just simply stating that if we keep the new and the old if would be best to have 2 directories in the adwaita-icon-theme package (1) Adwaita and (2) AdwaitaLegacy that way users have the ability to switch between icon theme's if they so choose to.
If we do this, then will more changes need to be made elsewhere in order for AdwaitaLegacy to be the default FDo icon theme in order to avoid missing icons?
Is it likely that anyone would want to "switch between"? I can't see it hurting for the overall theme to be providing extra icons that apps designed for Adwaita aren't going to ask for by those names.
OK, you have a point here. Perhaps it is easier to just go along with what upstream has presented, although my initial reaction was that it was a compromise between the two sides more than the best approach to the problem, which was that stuff had gone missing so put it back (or at least symlink to the previously supported icon names).
It technically is a compromise and the best approach to the issue at hand.
If we do this, then will more changes need to be made elsewhere in order for AdwaitaLegacy to be the default FDo icon theme in order to avoid missing icons?
Is it likely that anyone would want to "switch between"? I can't see it hurting for the overall theme to be providing extra icons that apps designed for Adwaita aren't going to ask for by those names.
Again Pat, it would be up to you. I am just giving my feed back on this issue that was presented.
Again Pat, it would be up to you. I am just giving my feed back on this issue that was presented.
Well you've nearly got me convinced.
Thanks, I'll look into it. One issue on my end is that I wasn't able to actually reproduce the problem. I don't get any missing icons with this adwaita-icon-theme package nor with the previous one.
OK, other than the selection of a theme, am I supposed to see a difference here?
To paraphrase an old Wendy's commercial, where's the bug?
If you look at the way the icon's are in the Xfce menu some user's mite not mind the symbolic look and missing icons well if you look at the other Xfce menu picture all full color icons are being used and there is no missing icons what so ever. If you put all icons in one folder you will have a mixture of symbolic and full color icons. But if you leave them separate then the user has the option to choose which one they would like to use and be able to use the icon theme at it's fullest.
I'm going to offer a different opinion here. The missing icons used to be there, in the adwaita-icon-theme. Gnome removed them, so the ones that get placed on menus are ugly symbolic only things, all separating the themes does is break the theme again.
It seems to make the most sense to me to have one theme which works, than two half broken themes*.
EDIT: *ok, maybe the "classic" theme isn't broken to begin with, so my statement makes little sense. But the new theme shouldn't conflict with the old one, as the objects were removed from the theme entirely. Putting them back just stops the breakage.
Now I have to investigate deeper..
Last edited by jloco; 05-08-2024 at 08:14 PM.
Reason: poor choice of words
Can we have zram as a service from the box mister BDFL ? If You include it, it would percipitate to the arm branch as well, where it might find the most usage but even at the x86 desktop it has it's fair use case:
Blender keeps it's massive data in ram as plain text - offloading it to a zram swap device might decrease it's foot print as much as to a fourth.
I am most certain there might be other use cases in the wild...
TIA
FWIW there are two zram packages on SBO already i tried the zramen and it is low fuss just works apporach (edit some sane defaults in /etc/defaults/* and that's it)
Here's a problem that seems to exist on all of install DVDs that I tried.
(14.0, 14.1, 14.2, 15.0)
[edit ...scratch reference to the 14.x versions, they seem to be OK, I was doing something wrong]
Mounted the partition containing the version to be upgraded.
mount /dev/sdb2 /mnt
Attempting to use pkgtool fails to remove existing packages before doing an upgrade.
Tracked it down to the version of grep which is not recognizing the -Z option.
The fix was...
rm /bin/grep
cp /mnt/bin/grep /bin
Now the pkgtool script displays the existing packages which when selected then does remove them.
Current is working OK via the DVD I created from a full download of the tree.
_________
Tried a 14.2 32bit DVD and it's working OK.
So, the only one that really matters that I tried and is failing is slackware64-15.0
________
Ah ha... /bin/grep is a symlink to /bin/busybox
ls -l /bin/grep
lrwxrwxrwx 1 root root 7 Feb 2 2022 /bin/grep -> busybox*
ls -l /bin/busybox
-rwxr-xr-x 1 root root 865880 Feb 2 2022 /bin/busybox*
ls -l /mnt/bin/grep
-rwxr-xr-x 1 root root 163232 May 14 2023 /mnt/bin/grep*
____
Tested and confirmed... exactly the same failure with the 32bit slackware-15.0 install DVD
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.