gjs-1.68.0
https://download.gnome.org/sources/g...-1.68.0.tar.xz

It could be useful to have a script that updates initrd and the bootloader when a new kernel is installed. I know about the zlookkernel.sh script, but would it work better if the script does this?

Search for the installed bootloader (I have made a script to find the bootloader)
Run "geninitird"
Run bootloader command (f.ex. eliloconfig, lilo, grub-mkconfig -o /boot/grub/grub.cfg)

Then some kernel panics could be avoided for more recent users of Slackware.

@jostber - Have you seen posts #4513 and #4514 in this thread?

I had not seen these posts, thanks for the links. The best thing might be to have this functionality in a separate script like zlookkernel.sh. The last part of the script would be better though with a discovery of the bootloader and then running genitird and the bootloader command in my opinion.

wrapupgradepkg does that. Adapting it to Slackware is left to the reader as an exercise. Hint: replace the calls to spkg (not shipped in Slint) by calls to a script shipped in pkgtools. Users didn't complain so far. Call it like this:the new package can be any one that you want to upgrade, this is not limited to a kernel package, but kernel packages are processed in a specific way.

Attached Files

wrapupgradepkg.txt (7.6 KB, 20 views)

re-request for CONFIG_FONT_TER16x32=y in the kernel config.

Please.

2 members found this post helpful.

You should add gforth to slackware current so it can be a part of slackware 15.
https://ftp.gnu.org/gnu/gforth/gforth-0.7.3.tar.gz
gforth is the official GNU implementation of ANSI FORTH. Forth is a stack based language that can be extremely powerful and incredibly tiny at the same time.
Here is a slackbuild script that will make adding gforth a two minute job.
http://slackbuilds.org/slackbuilds/1.../gforth.tar.gz
FORTH is a wonderful and unique language, don't overlook it.

I would highly recommend adding in the Ffcall package as well. It's an optional dependency, but it will allow calling C libraries with gforth. Install Ffcall first before gforth to make use of it.
http://cvs.savannah.gnu.org/viewvc/libffcall/ffcall/

1 members found this post helpful.

This is just a suggestion:

Perhaps Slackware64 should be renamed to just "Slackware", and the 32-bit version renamed to "Slackware32" or similar.

Grounds: 64-bit builds are now widespread and considered as the new default. Thus, it would make sense that this build carries the default "Slackware" name.

I'm not suggesting to retire 32-bit, just a rename.

3 members found this post helpful.

I agree that your suggestion to rename 32-bit Slackware to “Slackware32” makes sense, but I would keep the “Slackware64” name, if I had any say in it (which I don’t). Otherwise, you would have to rename it back to “Slackware64” once “Slackware128” comes along.

Please consider adding this small daemon supervisor developed by @raforg for a proper handing of the PipeWire daemons.

https://github.com/raforg/daemon

The latest version 0.8 added an unique support for interacting with elogind and auto-quitting on user logout, at our feature request accepted by this friendly developer.

https://github.com/raforg/daemon/releases/tag/v0.8

I can say that this elogind integration was added specially for Slackware and developed under Debian and its systemd(-logind) then this is a supplementary guarantee that the logind API is fully respected, until it works similarly under systemd, but of course there is no need for this feature.

This feature of auto-quitting on user logout is particularly useful for running programs which are developed as "user target" daemons for systemd, like are the three PipeWire daemons. But the daemon itself is a program developed since 12 years, for multiple operating systems, and it could be generally useful to run system services which has no ways to daemonize themselves.

For example, it can help to create a complete rc.d script/service (with start/restart/stop/status) for xBrowserSync, which is a NodeJS based server.

Also, please note that this daemon supervisor has a really small footprint, and it could be packaged in a 100KB package, which installs a 200KB program (the daemon itself), a man file and a configuration file.

I should also note that I use this daemon supervisor with great success since its elogind integration development started, as I described also in a dedicated thread, where I described also a packaging approach:

https://www.linuxquestions.org/quest...ed-4175691414/

In other hand, please consider to add on the PipeWire package the following three sample files for the global XDG autostart.

/etc/xdg/autostart/pipewire.desktop-sample
/etc/xdg/autostart/pipewire-media-session.desktop-sample
/etc/xdg/autostart/pipewire-pulse.desktop-sample
The first two files, IF renamed with a proper .desktop extension, will start the main daemons of PipeWire, and this will enable the standard support from PipeWire, as expected by Wayland/Plasma5 and various features of it will start working, for example the taskbar thumbnails.

The third file, IF renamed with a proper .desktop extension, will start the Pulse Audio replacement daemon (just like Fedora intends to do), and this will need also the disabling of PA server by the user, by renaming the file /etc/xdg/autostart/pulseaudio.desktop and changing on /etc/pulse/client.conf
So, probably somewhere should be added those instructions of how to disable the PulseAudio server while using the PipeWire Pulse-compat server.

However, please note that I do NOT ask for enabling the PipeWire daemons by default, BUT about adding a consistent infrastructure at user decision whether s/he would enable those PipeWire daemons, considering our past experiences with them.

So, I would say that my proposal is about transforming the Slackware-current on being "PipeWire ready", to facilitate for its users to experiment with the PipeWire features, and definitely is NOT about requesting a fully switching to PipeWire, like Fedora intends to do.

7 members found this post helpful.

I'm sorry for bumping this, below changes are needed for /usr/bin/sddm to let the init process properly supervise SDDM. Also "$*" is changed to "$@" since I think that is more appropriate for propagating the positional parameters in this script.

Thanks for the consideration!

5 members found this post helpful.

gdk-pixbuf-2.42.4
https://download.gnome.org/sources/g...-2.42.4.tar.xz

I don't see why not to adding fasm to slackware.
https://flatassembler.net/download.php
It's written in x86 assembly making it lightning fast compared to other assemblers.

I fully subscribe to this feature request, as from my own experience this daemon supervisor do a quite fine job on handing the PipeWire daemons, which themselves looks being a quite stable software.

I used the PipeWire main daemons (pipewire and pipewire-media-session) since this software was added in KTown (via lauching them from global XDG autostart and configuring the elogind to kill the user processes on logout) and since some time I use also the PulseAudio compat server, mainly because I observed that it works way better with the Bluetooth devices than the PulseAudio server itself.

Of course, just like you, I for one I do not expect Slackware to use PipeWire as main Audio server, and probably there's no one wanting this. However, I believe too that having a good infrastructure (like you proposed), for the user to run eventually those PipeWire daemons in a "recommended way" would be very nice.

And here I would like to note a very cool behavior of this method of running the PipeWire daemon via this particular daemon supervisor, which makes it probably the best way to do this job.

So, the three PipeWire daemons have, as you suspect, a certain order of execution. From what I read and did, this order is:

pipewire -> pipewire-media-session -> pipewire-pulse

That's not a problem for systemd, which have a dependencies resolution for its services, but if someone use (just like me) those XDG auto-start files named just like was proposed by you (from a logical POV, I guess, and I agree with it), in fact their execution order is:

pipewire-media-session -> pipewire-pulse -> pipewire

Which is is totally wrong, as both pipewire-media-session and pipewire-pulse will suddenly quit because the main daemon (pipewire) is not running yet.

BUT, their daemon supervisor instances (because all of them runs with the --respawn option) will wait a bit after that premature quitting, then every one will execute again its client program. Then, the cycle will be repeated again and again.

The final result is that this tandem (PipeWire daemon and its daemon supervisor) manages to "synchronize" the execution of the three PipeWire daemons just like there is a "services dependency resolution", no matter on which order you execute them initially.

2 members found this post helpful.

Add an option to pkgtool and setup that is called Repair which runs these commands in one - Find bootloader installed, Run geninitrd, Run bootloader command, Output kernel version and bootload conf file at the end.