Even in companies, even with RHEL, you don't patch your servers like that ... one by one
This is not a "mainstream" problem, this is about automation

with
BATCH=on
DEFAULT_ANSWER=y
in all your slackpkg.conf

and it doesn't matter if you have 10 or 1000 computers
After that, we have enough time to share a beer and talk about the weather

4 members found this post helpful.

One thing I have wished for was a version of the stable tree where instead of having updates come in .../patches/packages/ it has them updated in-place (replacing the obsolete package files in the main tree) like current has. After 5 years, patches/packages does start to get a little big.

I have occasionally thought of writing a script to scan packages/ and do it for me, but I'm not sure how best to handle rebuilding the CHECKSUMs files and dealing with signatures.

Anyway, I never had enough enthusiasm for writing one, and if I wanted to do mass installs where something like this would matter, I'd likely just keep one master install of slackware updated and clone it using rsync or even tar.¹

___
1) Just because Pat provides and official installer doesn't mean one has to use it.

Does someone know a good reason that two versions of urxvt are shipped?
Maybe the 88-colors-version should be ditched.
From https://github.com/jrcharney/rigel/wiki/URXVT:

Latte-dock 0.10.6

https://psifidotos.blogspot.com/2021...x-release.html

I think thats their point, with 14.2 5.5 yrs old, they are installing 4 gigs of data, then updating with another 4 gigs of data.
So their suggestion the installer seeks out and checks updates before installing and have those packaged supersede the base, makes sense, especially since nobody wants to bog down all the mirrors - twice.

2 members found this post helpful.

Even better an ISO can include only a minimum set of packages beyond the installer to start the installation, then complete it fetching the other packages from a remote mirror. That is what is called a net install. This is easy to do, and this mini ISO can be an additional one, provided after the release of Slackware 15 not to delay it. It is also possible that the installer in this mini ISO fetches remotely packages it includes in case newer are available. Then this ISO would not need to be rebuilt during the life of the version, or very rarely. It is also possible to provide an already installed mini Slackware as an image, including just what is needed to run and be able to expand and complete itself after installation. Hint. Maybe these things could be handled by members of the community, as Eric does for liveslak.

2 members found this post helpful.

I've done that, for around 250 computers, on multiple occasions. Undergraduate labs at a university computing science department. Install on one computer, apply patches, do any needed extra configuration (get it into the NIS domain, automount NFS home dirs, configure mail, syslog to log server, etc.), then clone it out to another computer over ssh. One of the nice things about Slackware is how few things need to be changed to give a clone its own identity, so the clone and identity changes are easily scripted. Once that computer is finished and rebooted you now have two computers to clone from. Then four, then eight, then before you know it you're done. IIRC, the first time I did this the dominant bottleneck ended up being the network bandwidth between labs on different switches.

4 members found this post helpful.

At my university we set up PCs with udpcast, where you set up one PC and then stream that setup to all PCs on the LAN.

1 members found this post helpful.

After more than 4 years & 620 pages, the good news is that we probably mark this thread as solved in (more or less) 1 month

https://www.linuxquestions.org/quest...ml#post6310775

2 members found this post helpful.

Hi,

A fix version of tcsh is available, see for issues fixed:

https://github.com/tcsh-org/tcsh/blob/master/Fixes

Files:
https://astron.com/pub/tcsh/tcsh-6.23.01.tar.gz
https://astron.com/pub/tcsh/tcsh-6.23.01.tar.gz.asc

6.23* is mainly a bug fix release per the mailing list

Thanks
John

last xine, crash at start here on two machine, on current:

( xiTK received SIGSEGV signal, RIP.
Abandon )

I came across three issues, two of which I already reported in the kde5 thread, but didn't seem to provoke any reaction, and one that I reported via email. Perhaps this is the right place? Or perhaps my suggestions aren't any good? Either way, let me know :-)

1. plasma-firewall has hardcoded dependencies on systemd. Suggestion: Remove plasma-firewall from Slackware.

Plasma-firewall doesn't work out of the box but prompts to install either ufw or firewalld. I've tested with both. With firewalld, it complains about org.freedesktop.systemd1 missing. With ufw, it does seem to work, but some further googling suggests that this is probably luck, since the plasma-firewall code for both firewall packages contains hard-coded references to systemd. See here for more details:

https://bugs.gentoo.org/778527

2. libgpod isn't used anymore. Suggestion: Remove libgpod from Slackware

I was trying to use my ipod with Slackware, but couldn't find how anymore. Upon further reflection, I noticed that nothing seems to depend on libgpod anymore anyway (NOTE: I didn't install xfce, maybe some xfce package still uses it?) Grep-ing for libgpod in /usr/lib64 only turns up parts of libgpod itself. So, for Slackware, this lib seems entirely obsolete. (I did manage to compile gtkpod in the end, but given the waning popularity of ipods in general, perhaps libgpod should be left to sbo.)

3. plasma-nm doesn't import private keys from ovpn profiles. Suggestion: Patch plasma-nm with upstream patch

I ran across this problem when I tried to import my employer's ovpn profile. I sorted through the plasma-nm source code and wrote a patch, which just got accepted upstream: https://invent.kde.org/plasma/plasma...48e17c1a7e460f Is there any chance that such a patch could also be applied to plasma-nm in Slackware-15?

Regardless of what will happen, I am really curious for some reactions to the above three suggestions, and I hope this is the best place to report them. Let me know!

3 members found this post helpful.

With all respect, what you claim here is, very respectfully saying: bullshit!

You know what's the difference between me and you regarding those things? You "experimented" while I for one I literally use the firewalld and its Plasma5 integration since over ONE freaking year! Heck! I even made a relative complicated custom router using it!

However, the firewalld works as expected on Slackware -current, near to be Slackware 15.0 on my all boxes. Maybe your box(es) are setup on a really wacky way? No elogind? No DBUS? OR, you just talk from what you have read on Internet, while personally still hanging on Slackware 14.2 ?

I for one, I even proposed the firewalld addition on Slackware, but looks like this contradicts some religious beliefs.

And that's OK, after all even the Church still debates if the Holly Gospels are more appropriate of original meaning, on Latin or Old Greek. Still undecided after 2000 years.

PS. To not repeat all the explanations about firewalld, please be kind to look back on this very thread - there was a very heated discussion about firewalld adoption proposal - worth of over 20 pages, including even screenshots, and yet NOBODY raised this silly point that it depends on systemd.

PS2. I hope you are aware that Slackware 15.0 RC2 ships Plasma 5.23.4, not that 5.21.3 which is the subject of that Gentoo bug report, right?

3 members found this post helpful.

Well, good for you, but like I said, my experience is very different. And I am on -current. And I did install firewalld. And I did receive that error message about systemd. So, at the least, I wonder what others´ experiences are. Because I am talking from experience, just like you.

I'm on an up-to-date current with all package series installed except xfce. I haven´t modified too much, and of course elogind and dbus and udev are running here. I talk from experience, and identified a bug report that mirrored that experience.

Note that I wasn´t talking about whether or not to add firewalld. It seemed to have a nice GUI itself, so I didn't even see what plasma-firewall adds to firewalld at all. No religious beliefs on my part here! Even if Slackware would add firewalld, I still would argue that we might be better off without plasma-firewall. I mean, why not use the native firewalld gui anyway.

I didn´t say that. Please note, I'm not talking about firewalld at all! The issue was about plasma-firewall trying to launch firewalld using a systemd interface. Well, that's not going to work. I´m well aware that firewalld doesn't depend on systemd. But plasma-firewall does (see below).

Yes, of course I am! I did mention that I patched plasma-nm myself? Then of course I know which plasma branch we´re using. And while that Gentoo report is about 5.21.3, a cursory glance at the plasma-firewall sources confirm that systemd is still hardcoded in master. For the firewalld backend, relevant sources are here:
https://invent.kde.org/plasma/plasma...ends/firewalld

Notice especially https://invent.kde.org/plasma/plasma...systemdjob.cpp

See how plasma-firewall is calling firewalld through systemd, hardcoded https://invent.kde.org/plasma/plasma...ent.cpp#L58-77 , in the function for enabling firewalld. The ufw backend code in plasma-firewall contains a hardcoded reference to systemctl: https://invent.kde.org/plasma/plasma...t.cpp#L641-654

This is all in the master branch of plasma-firewall, so apparently that Gentoo bug report is fully applicable to Slackware's version of plasma-firewall.

Maybe we need to agree to disagree, or maybe we were talking at cross-purposes - you about firewalld, and I about plasma-firewall? So please note: I'm not doing any suggestion about firewalld, only about plasma-firewall.

3 members found this post helpful.

Don't mind the explosion from LuckyCyborg, with this level of expletives he's bound to follow where his companion hysteric igadoter went before him.

I looked up the commit introducing the systemctl call: https://github.com/KDE/plasma-firewa...3ed85d4cf10d49
It seems that in the case where systemctl is not present (which produces the same result as when systemctl finds the firewall application not loaded) Plasma-firewall will poke the ufw or firewalld binary instead. So this is why it still works on Slackware according to LuckyCyborg.

I think you are right. Nothing in Slackware depends on libgpod anymore, just some stuff on SlackBuilds.org still does.

Looking at the commit, it'll likely be included in Plasma 5.23.5 which according to this post by volkerdi will still make it into -current before the release of Slackware 15.0.

4 members found this post helpful.