LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 03-20-2021, 12:22 PM   #7186
saxa
Member
 
Registered: Aug 2004
Distribution: Slackware
Posts: 843

Rep: Reputation: 167Reputation: 167

gjs-1.68.0
https://download.gnome.org/sources/g...-1.68.0.tar.xz
 
Old 03-21-2021, 01:06 AM   #7187
jostber
Member
 
Registered: Jul 2001
Location: Skien, Norway
Distribution: Slackware 14.2 64-bit
Posts: 510

Rep: Reputation: 166Reputation: 166
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.
 
Old 03-21-2021, 01:24 AM   #7188
allend
LQ 5k Club
 
Registered: Oct 2003
Location: Melbourne
Distribution: Slackware-current
Posts: 5,613

Rep: Reputation: 2185Reputation: 2185Reputation: 2185Reputation: 2185Reputation: 2185Reputation: 2185Reputation: 2185Reputation: 2185Reputation: 2185Reputation: 2185Reputation: 2185
@jostber - Have you seen posts #4513 and #4514 in this thread?
 
Old 03-21-2021, 01:53 AM   #7189
jostber
Member
 
Registered: Jul 2001
Location: Skien, Norway
Distribution: Slackware 14.2 64-bit
Posts: 510

Rep: Reputation: 166Reputation: 166
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.
 
Old 03-21-2021, 05:39 AM   #7190
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-14.2.1.2 on Lenovo Thinkpad W520
Posts: 9,869

Rep: Reputation: Disabled
Quote:
Originally Posted by jostber View Post
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.
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:
Code:
wrapupgradepkg dummyargument /path/to/the/new/package
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
File Type: txt wrapupgradepkg.txt (7.6 KB, 15 views)

Last edited by Didier Spaier; 03-21-2021 at 05:49 AM.
 
Old 03-21-2021, 06:48 AM   #7191
GazL
LQ Veteran
 
Registered: May 2008
Posts: 5,866

Rep: Reputation: 3805Reputation: 3805Reputation: 3805Reputation: 3805Reputation: 3805Reputation: 3805Reputation: 3805Reputation: 3805Reputation: 3805Reputation: 3805Reputation: 3805
re-request for CONFIG_FONT_TER16x32=y in the kernel config.

Please.
 
2 members found this post helpful.
Old 03-21-2021, 07:52 AM   #7192
alnun
LQ Newbie
 
Registered: Mar 2021
Posts: 9

Rep: Reputation: Disabled
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.
Old 03-21-2021, 01:16 PM   #7193
sombragris
Member
 
Registered: Jul 2004
Location: Asuncion, Paraguay, South America
Distribution: Slackware
Posts: 648

Rep: Reputation: 317Reputation: 317Reputation: 317Reputation: 317
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.
Old 03-21-2021, 01:54 PM   #7194
luvr
Member
 
Registered: May 2005
Location: Boom - The Home Town of Tomorrowland, Belgium
Distribution: Slackware, Xubuntu
Posts: 347
Blog Entries: 1

Rep: Reputation: 140Reputation: 140
Quote:
Originally Posted by sombragris View Post
Perhaps Slackware64 should be renamed to just "Slackware", and the 32-bit version renamed to "Slackware32" or similar.
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.
 
Old 03-21-2021, 02:50 PM   #7195
ZhaoLin1457
Member
 
Registered: Jan 2018
Posts: 630

Rep: Reputation: 732Reputation: 732Reputation: 732Reputation: 732Reputation: 732Reputation: 732Reputation: 732
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
Code:
[Desktop Entry]
Version=1.0
Name=PipeWire Media System
Comment=Start the PipeWire Media System
Exec=/usr/bin/daemon -frB --pidfiles=~/.run --name=pipewire /usr/bin/pipewire
Terminal=false
Type=Application
X-GNOME-Autostart-Phase=Initialization
X-KDE-autostart-phase=1
/etc/xdg/autostart/pipewire-media-session.desktop-sample
Code:
[Desktop Entry]
Version=1.0
Name=PipeWire Media Session
Comment=Start the PipeWire Media Session
Exec=/usr/bin/daemon -frB --pidfiles=~/.run --name=pipewire-media-session /usr/bin/pipewire-media-session
Terminal=false
Type=Application
X-GNOME-Autostart-Phase=Initialization
X-KDE-autostart-phase=1
/etc/xdg/autostart/pipewire-pulse.desktop-sample
Code:
Desktop Entry]
Version=1.0
Name=PipeWire Pulse
Comment=Start the PipeWire Pulse
Exec=/usr/bin/daemon -frB --pidfiles=~/.run --name=pipewire-pulse /usr/bin/pipewire-pulse
Terminal=false
Type=Application
X-GNOME-Autostart-Phase=Initialization
X-KDE-autostart-phase=1
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
Code:
autospawn = no
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.

Last edited by ZhaoLin1457; 03-21-2021 at 03:12 PM.
 
5 members found this post helpful.
Old 03-22-2021, 01:52 AM   #7196
mumahendras3
Member
 
Registered: Feb 2018
Location: Indonesia
Distribution: Slackware-current with s6 + s6-rc + s6-linux-init
Posts: 107

Rep: Reputation: Disabled
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!

Code:
--- a/usr/bin/sddm      2021-03-22 13:30:32.209653646 +0700
+++ b/usr/bin/sddm      2021-03-22 13:32:55.810714919 +0700
@@ -3,4 +3,4 @@
 if [ -f /etc/default/sddm ]; then
   . /etc/default/sddm
 fi
-/usr/bin/sddm.bin "$*"
+exec /usr/bin/sddm.bin "$@"
 
5 members found this post helpful.
Old 03-22-2021, 06:12 AM   #7197
saxa
Member
 
Registered: Aug 2004
Distribution: Slackware
Posts: 843

Rep: Reputation: 167Reputation: 167
gdk-pixbuf-2.42.4
https://download.gnome.org/sources/g...-2.42.4.tar.xz
 
Old 03-22-2021, 08:25 AM   #7198
alnun
LQ Newbie
 
Registered: Mar 2021
Posts: 9

Rep: Reputation: Disabled
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.
 
Old 03-22-2021, 01:09 PM   #7199
LuckyCyborg
Senior Member
 
Registered: Mar 2010
Posts: 1,318

Rep: Reputation: 1072Reputation: 1072Reputation: 1072Reputation: 1072Reputation: 1072Reputation: 1072Reputation: 1072Reputation: 1072
Quote:
Originally Posted by ZhaoLin1457 View Post
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
Code:
[Desktop Entry]
Version=1.0
Name=PipeWire Media System
Comment=Start the PipeWire Media System
Exec=/usr/bin/daemon -frB --pidfiles=~/.run --name=pipewire /usr/bin/pipewire
Terminal=false
Type=Application
X-GNOME-Autostart-Phase=Initialization
X-KDE-autostart-phase=1
/etc/xdg/autostart/pipewire-media-session.desktop-sample
Code:
[Desktop Entry]
Version=1.0
Name=PipeWire Media Session
Comment=Start the PipeWire Media Session
Exec=/usr/bin/daemon -frB --pidfiles=~/.run --name=pipewire-media-session /usr/bin/pipewire-media-session
Terminal=false
Type=Application
X-GNOME-Autostart-Phase=Initialization
X-KDE-autostart-phase=1
/etc/xdg/autostart/pipewire-pulse.desktop-sample
Code:
Desktop Entry]
Version=1.0
Name=PipeWire Pulse
Comment=Start the PipeWire Pulse
Exec=/usr/bin/daemon -frB --pidfiles=~/.run --name=pipewire-pulse /usr/bin/pipewire-pulse
Terminal=false
Type=Application
X-GNOME-Autostart-Phase=Initialization
X-KDE-autostart-phase=1
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
Code:
autospawn = no
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.
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.

Last edited by LuckyCyborg; 03-22-2021 at 01:30 PM.
 
2 members found this post helpful.
Old 03-22-2021, 01:50 PM   #7200
jostber
Member
 
Registered: Jul 2001
Location: Skien, Norway
Distribution: Slackware 14.2 64-bit
Posts: 510

Rep: Reputation: 166Reputation: 166
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] Requests for -current (20151216) rworkman Slackware 3441 12-28-2017 03:50 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 01:14 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration