frameworks-5.116.0

https://kde.org/fr/announcements/frameworks/5/5.116.0/

2 members found this post helpful.

less-655
https://greenwoodsoftware.com/less/
(less-654 doesn't display ISO-8859 characters C0...FF.)

Wasn't libgcc_s version supposed to be the same in aaa_libraries and gcc packages? At the moment they're not.

gi-docgen-2024.1
https://download.gnome.org/sources/g...-2024.1.tar.xz

could we stole this idea to SBo to put it in Slackware.

This with a RC.LOCAL_SHUTDOWN that clean/temp/SBO and TEMP/SLACKware would be good.

I have already written that in /etc/rc.d/rc.local_shutdown
/usr/bin/find /tmp -mindepth 1 -maxdepth 1 -delete

Thanks to the old Slackware users.
https://www.linuxquestions.org/quest...nt-4175560283/

1 members found this post helpful.

I long have liked the SBo method of OUTPUT=${OUTPUT:-/tmp}. I am able to set the OUTPUT environment variable to my local repositories. With the output set to $TMP, I have to modify the build script or manually copy the package to my local repositories. Perhaps I am the only person affected, perhaps not. Seems this would be a straightforward change though without causing commotion?

Isn't it the same as: TMP=${TMP:-/tmp} ?

1 members found this post helpful.

Yes.

No.

Securitywise it would be a good idea to build the distro under /tmp/slackware if a root-owned /tmp/slackware were automatically created in rc.S like /tmp/.X11-unix is. Or under some other directory other than /tmp which wouldn't be writable to all. The situation now is that there are many binaries with RPATH or RUNPATH in the elf header pointing to a directory under /tmp. For example

because ruby was built in /tmp/ruby-3.3.1.

A non-root perpetrator can create a directory /tmp/ruby-3.3.1 and plant a malicious library there, containing a modified function which /usr/lib64/ruby/3.3.0/x86_64-linux/enc/iso_8859_1.so wants to load.

If the ruby package had been built in /tmp/slackware/ruby-3.3.1, it would be RPATH=/tmp/slackware/ruby-3.3.1 and the perpetrator could not plant the malicious library there if there were /tmp/slackware with no write access.

Even better would be to use another build directory, not writable for non-root, not placed under /tmp, so it would not depend on a /tmp/slackware place holder directory to exist.

I wrote a script to search for dangerous RPATH/RUNPATH: https://www.linuxquestions.org/quest...ml#post6472015

5 members found this post helpful.

xorg-xwayland 24.1.0

1 members found this post helpful.

This is another one of those things where perhaps I'm the only one trying to build for 32-bit x86.

3 members found this post helpful.

Ah I see...it will wait then

2 members found this post helpful.

Do I gather correctly from that comment
that it (along with other items), either will not build or is at-least difficult to build for 32bit ?

And if so, is there a possibility that 15.1 might be the last 32bit Slackware ?

Heh. There's always that possibility. Hell, there's a possibility that 15.0 might be the last 32-bit Slackware.

7 members found this post helpful.

Well then, if that be the case, anyone running 32bit 15.0 had better hurry up
and get upgraded to 32bit -current before it disappears and there is no 32bit 15.1

BTW, my only bare metal 32bit machine is a circa 1997 P-II that is dropped-back to 14.0
because it is just too slow and has too little RAM to run anything newer.
(tried 15.0 and it just can't handle it, in-fact X crashes right back to the cli with "invalid instruction")

1 members found this post helpful.