Removed...

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.

Maybe, but it's not simpler. Any problems still existing with this solution? (do the simplest thing that could possibly work)

As far as being predictable, do we need to be? (YAGNI)

If there's a problem later, we can react to it then.

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.

1 members found this post helpful.

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).

1 members found this post helpful.

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.

It technically is a compromise and the best approach to the issue at hand.

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.

I will upload what Gnome 46 looks like if you want?

I ment to say XFCE......

Attached Thumbnails

   

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..

4 members found this post helpful.

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)

1 members found this post helpful.

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

2 members found this post helpful.