And I didn't say you should. If your argument was that slackware should be configured to use a 'named' user as shipped then I'd be inclined to agree. I simply pointed out that it's the default behaviour of 'tar' rather than "a brain-dead install script" that's causing your issue.

Actually thinking on it a little more, I'm leaning towards the idea that Pat should specify --no-overwrite-dir on tar in the upgradepkg script: it would sort out your issue, but also it would stop broken packages clobbering the permissions of /usr/bin or other system directories, which has been known to happen sometimes.

As I said though: it would mean that any intentional directory/permission changes if future would need to be coded into doinst.sh scripts... but maybe that's not a common enough occurrence for it to be a consideration.

Thanks for this, i think , one of the best "LAST MINUTE" , updates. , becaus its mantained and patched frequently.

2 members found this post helpful.

Because now , we are using qt5 from kde git , we can try upgrade mariadb again to 10.6.x , cause kde branch patch the issue from this.

2 members found this post helpful.

Did you are really sure that no other software than Qt5 is affected by version reporting changes from MariaDB 10.6.x ?

I for one, I have the suspicion that there are other software affected, even we do not know yet which ones.

4 members found this post helpful.

@LuckyCyborg

And you are very sure other software affected ?

Thats the point of """WE CAN TRY""" , in the forum i read problems only in qt5 and obiously kde apps , but thinking in rc1 , is late to try test , and is time to make fixes.

Its funny when some one in same phrase say "i suspicious...but we do not know"

We can skip mariadb 10.6 for now , but not forever , im not interested on this update, im not use mariadb more than the apps linked to this.


The next choose is what happen with linux kernel , 5.13.13 EOL soon for 5.13 , but 5.14 is out , not sure if confused but i read something arround removing IDE DRIVERS , probably this not good ,im not have ide in my machines but probably some servers use it , or old machines.

Well, probably it's, because I doubt that only Qt5 checks the MySQL version compliance.

I believe that there are software which uses MySQL much more than Qt, for example the big portal engines. That's WHY I said that I suspect that NOT every other software is NOT affected.

For example, did you tested Moodle or Chamilo if they works with that MariaDB?

Those are software big like Plasma5, and they are in fact sites.

They removed the legacy IDE drivers, which given you the devices like /dev/hda and so on.

BUT today everybody uses the modern libata drivers for the IDE hard drives, which drivers gives you devices like /dev/sda and so on.

Even the Slackware moved to libata drivers many years ago, on Slacwkare 13.0 if I remember right.

There is nothing to scare you there, unless you still use Slackware 12.2 - but I doubt that the kernel 5.14 could be even built on this particular distro release.

1 members found this post helpful.

After building procps-ng with elogind support libprocps.so links against libelogind.so.0, which prevents a bunch of important system tools (like ps, pidof, pgrep/pkill, and also sysctl) from running. As a consequence, quite a lot of the /etc/rc.d/ scripts fail to work, potentially leaving a lot of processes for the final killall5 to reap. On the other hand, elogind itself is optional for procps-ng - if it is not running, ps just shows fewer fields, and other tools seem to ignore it completely.

elogind package is still marked as "recommended" in the tagfile, and really though most of the Slackers are desktop users - where either elogind or systemd is a strong requirement these days - a headless server wouldn't have much (or, well, any) use for it.

I have checked packages in a/ap/l/n (the "headless" bunch, for lack of a better name) to see other dependencies on libelogind. I have spotted the following:

- dbus (optional but useful) links to libelogind.so.0 directly
- there is an optional PAM module in pam package (required) which doesn't make sense without elogind running
- udisks2 and polkit - mostly GUI staff but elogind support is optional in those

All in all I *think* rather than promoting elogind to a full "required" package it is better to include /lib64/libelogind.so.0 into aaa_libraries instead.

This would make a "minimal" Slackware install to be one package "thinner", and make upgrading from previous versions smoother (e.g., no elogind previously installed -> procps-ng is updated -> ps and pidof don't work -> puzzled sysadmin).


PS Tried reporting this over e-mail but alas this communication channel seems quite dead at the moment.

6 members found this post helpful.

As Jean-Pierre André just posted:The project has migrated on GitHub and the new release can be downloaded from https://github.com/tuxera/ntfs-3g/re.../tag/2021.8.22. Changelog is available at https://github.com/tuxera/ntfs-3g/wi...elease-History

2 members found this post helpful.

A little catch up with updates on Vim ?

Vim 8.2.3388
https://github.com/vim/vim/archive/r....2.3388.tar.gz

Python 3.9.7

https://www.python.org/downloads/release/python-397/

https://www.python.org/ftp/python/3....thon-3.9.7.tgz
https://www.python.org/ftp/python/3....-3.9.7.tgz.asc

Heplfull ! Did mean ~10Mb ~30Mb very old MFM IDE era. :-)


Example: Seagate MFM 30 Mb , random search pic from net.

Also say goodby to old chip's, controllers, motherboards.. t. only IDE connector's ?
No, because it have work with libata. So from example Pentium D/Celeron/AMD k8.

1 members found this post helpful.

Lately I experienced at times an extremely poor performance when accessing Linuxquestions via Firefox. I also noticed glxtest error messages on the console. Installing libvulkan.so.1 from the vulkan-sdk resolved these problems.

Well, probably is time for us to become habituated with idea that vulkan-sdk is part of the graphics stack and not some "optional" package.

Times change, World changes, Slackware changes too...

That's why evolution happens.