S15Pup - Discussion

[norgo]

S15Pup RC3 - short test

1. System doesn't boot
bootparameter edd=off solved this problem in my case

2. pkeys=xy will be ignored in case of xorg-autoconf usage
my ugly hack

Code: Select all

--- /usr/sbin/xorg-autoconf	2022-11-15 22:18:29.000000000 +0800
+++ /root/Downloads/xorg-autoconf	2022-11-16 01:13:13.000000000 +0800
@@ -20,10 +20,13 @@
 [ "$MODLIST" == "" ] && MODLIST="$(lsmod 2>/dev/null)" 
 [ "$PCILIST" == "" ] && PCILIST="$(lspci -nD 2>/dev/null | sed "s#^0000:##g")"
 
+
 if [ -e /etc/keymap.conf ]; then
  KBSELECT="$(cat /etc/keymap.conf | head -n 1)"
+ [ -f ~/.xkbrc ] && sed -i "/^XKB_DEFAULT_LAYOUT=/ c XKB_DEFAULT_LAYOUT=${KBSELECT}" ~/.xkbrc
 elif [ -e /etc/keymap ]; then
  KBSELECT="$(cat /etc/keymap | head -n 1)"
+ [ -f ~/.xkbrc ] && sed -i "/^XKB_DEFAULT_LAYOUT=/ c XKB_DEFAULT_LAYOUT=${KBSELECT}" ~/.xkbrc
 else
  KBSELECT="us"
 fi

3. udev error "specified group 'input' unknown"
defined in '/lib/udev/rules.d/50-udev-default.rules' line 29-30
but group 'input' does not exist in '/etc/group'
needs to be added

Thank you very much for your work

[peebee]

Downloaded S15Pup64-22.11-RC3 and noticed that Psip Sip Phone does not start because of a symbol lookup error.

Bit of a mystery as exactly the same Psip is used in ScPup which (probably) has even newer libs and it works OK there..... still trying to work out why this might be and why S15Pup differs from ScPup as it shouldn't having been built from the same "recipe"......

Error is:
undefined symbol: EVP_CIPHER_CTX_init

:openssl:|compat|Packages-slackware64-15.0-s15pup|openssl-1.1.1m|openssl|1.1.1m|1|BuildingBlock|11540K|slackware64/n|openssl-1.1.1m-x86_64-1.txz||Secure Sockets Layer toolkit|slackware64|15.0||

:openssl:|compat|Packages-slackware64-current-lxpup|openssl-1.1.1s|openssl|1.1.1s|1|BuildingBlock|8710K|slackware64/n|openssl-1.1.1s-x86_64-1.txz||Secure Sockets Layer toolkit|slackware64|current||

[ozsouth]

@peebee - I get that psip error on any ScPup64 after 20.06+2. It has openssl 1.1.1h & curl 7.73.
I note that the pjlib version is 2.6. As 2.12 is now out, I would be concerned enough about security to omit psip.

[OscarTalks]

What I am finding is that PSIP runs in fresh boot of 32bit, but has the error in 64bit and that applies to both S15Pup and ScPup

It is all coming back to me now. I have these versions which people can install and test. I believe everything is working including TLS transport because older versions of libcrypto and libssl are included in the package ( I believe it won't compile against openssl-1.1.1*). It is latest version with some improvements to default settings and buddies list. Includes the much nicer bell.wav ringtone instead of using "two barks".

Easy to have a play around with it without needing to configure anything or register any user accounts. Expand the "test addresses" in the main window, select one and press the Call button. To end the call, press the Hangup button in the call window before closing it.

If everyone is happy, perhaps they should be candidates to be in the list of packages in the recipe, not sure exactly how that all works. The only thing to note is that if you do this, the file /lib/libcrypto.so.1.0.0 and /lib/libssl.so.1.0.0 (or /lib64/libcrypto.so.1.0.0 and /lib64/libssl.so.1.0.0 in 64bit) should now become the real libraries instead of being symlinks to the later .so.1.1 versions in the output of the woof-CE build process. Actually, this should be better anyway because a compiled version of that older library is better than a symlink workaround which tries to pretend that different numbers are the same thing.

http://smokey01.com/OscarTalks/psip-1.4 ... 4-s15p.pet (64bit)
http://smokey01.com/OscarTalks/psip-1.42-i686-s15p.pet (32bit)

[ozsouth]

@OscarTalks - certainly works in S15Pup64. I earlier tested with some earlier 64bit pup's libbssl/libcrypto 1.0.0 - ok too. My concern with using old libs is security, so I hesitated to suggest that, as if anything else prefers 1.0.0, it will use those old insecure libs.
Perhaps the .pet should be available to those who want psip, but psip not be in S15 final.

[thinkpadfreak]

I am testing RC3, and as far as I am concerned, it is working fine.
The interface of mtPaint is in Japanese in the Japanese environment. Thanks.

I am looking forward to S15Pup becoming a stable/official release.

Edit:
One thing I am sorry for is that, as is often the case with recent puppies, we cannot use IME with Chrome.

[peebee]

RC4 makes psip available via PPM rather than pre-installed - still in menu with stub to prompt download.

No other changes from RC3.

[Duprate]

Hello! I'm using S15Pup64 with kernel 6.0.9-lxpup64. Booting with an Overlayfs initrd and another (initrd-2) for aufs + devx. Perfect working! Congratulations, Peebee!

[mikeslr]

Hi Duprate,
I like your wallpaper.

Hello! I'm using S15Pup64 with kernel 6.0.9-lxpup64. Booting with an Overlayfs initrd and another (initrd-2) for aufs + devx. Perfect working! Congratulations, Peebee!

I take the above to mean you have two menu listings, each pointing to a different folder containing S15Pup64; one with an Overlaysfs initrd and the other not. If I'm wrong, can you detail what you've done?

[Duprate]

I take the above to mean you have two menu listings, each pointing to a different folder containing S15Pup64; one with an Overlaysfs initrd and the other not. If I'm wrong, can you detail what you've done?

How are you, Mikeslr? In the same folder, there are two initrd. One is creation of Wiak, responsible for initializing Overlayfs. The other one is the original one from S15Pup64 which does the AUFS initialization. If you look at the image, you will notice that the files are numbered (00,01,02,03). This is the form created by Wiak, to work in Overlayfs and it is possible to load 100 modules. In Puppy's traditional mode (AUFS), the modules to be loaded have to be listed in DISTRO_SPECS, inside the initrd. So to use the same modules we have to rename as below:
DISTRO_BDRVSFS='devx.sfs'
DISTRO_PUPPYSFS='02-S15Pup64.sfs'
DISTRO_ZDRVSFS='00-modules.sfs'
DISTRO_FDRVSFS='01-firmware.sfs'
DISTRO_ADRVSFS='04-firefox.sfs'
DISTRO_YDRVSFS='03-changeS15.sfs'
Thus, numbered modules are loaded in both modes (Overlay and AUFS). The "devx.sfs" module is not numbered, so it is only loaded in "AUFS" mode.

Same files, two "initrd" and two grub entries:

menuentry "S15Pup64 Kernel 6.0.9-lxpup64 OVERLAYFS" {
linux /S15Pup64/vmlinuz w_bootfrom=UUID=xxxxxx-xxxx-xxx-xxx-xxxxxxxxx=/S15Pup64 w_changes=RAM w_copy2ram
initrd /S15Pup64/ucode.cpio /S15Pup64/initrd
}

menuentry "S15PupDEVX64 Kernel 6.0.9-lxpup64 AUFS" {
linux /S15Pup64/vmlinuz pfix=fsck,copy pmedia=atahd psubdir=S15Pup64
initrd /S15Pup64/ucode.cpio /S15Pup64/initrd-2
}

Why that?
1- The S15Pup64 + devx.sfs works best in AUFS mode.
2- I can test the system the way it was designed (aufs) and if I find a bug, I know it's not "Overlay's" fault.

[OscarTalks]

VLC Media Player version 3.0.17.4 in S15Pup
Experimental builds from source code uploaded as .pet in case anyone wants to take a look. Treat them as "for testing" or in case they are useful to anyone for anything.
EDIT:- packages taken down for now as they may need re-compiling due to library upgrades in RC5

In the build environment I did try the Qt5 .sfs packages but found that they did not contain all of the needed development tools and files for compiling, so instead I installed the full Qt5 Slackware package via PPM. This was all OK but the installation process takes an unusually long time with lots of dependencies dragged in including python3. The needed libs are then plucked out to be included in the package, so users should be aware of the unconventional structure and the slim possibilty of issues if installing and then uninstalling other "overlapping" packages.

In my own testing, most things work and most formats play. In terminal there are messages about a buffer function failing when pressing the stop button while a video is playing, but I see no evidence of anything failing to function in practice.

The library libdvdnav was too old so I had to include an upgrade. Perhaps this needs to be done in the S15Pup recipe prior to release as I think the included version is older than Slackware 15.0
I am not sure if DVD playing works, I need to hook up an external optical drive or try a different machine in order to test.
EDIT:- Using USB optical drive, DVD does play in VLC but installing it may interfere with playing DVD in gnome-mplayer

Also I note that hevc video playing works better in 64bit than it does in the 32bit version.
The ffmpeg package version numbers are different between 64bit and 32bit. Not sure if this has something to do with it. In fact the 32bit has a newer version 4.0 ffmpeg whereas the 64bit is an older 3.x series ffmpeg

So something else to consider prior to any official release (though it is not strictly essential) is that it might be an idea, since lots of multimedia apps depend on ffmpeg libs, to compile builds of ffmpeg with the same version number as the official Slackware 15.0 version, but with carefully considered custom Puppy configure options and include those as .pet packages in the S15Pup recipe. It would improve compatibilty and reduce dependecy bulk when users install official Slackware packages via PPM.

[Clarity]

Gparted problems. Checked version seem OLD. Run but will NOT do its device recovery feature as it is missing GPart componene.

[peebee]

RC5 is available....... see post #1

x264 x265 & ffmpeg updates (@OscarTalks )

gparted update (@Clarity )

[Clarity]

RC5 booted via ISO file on bare-metal pristine.

The mysterious 'popping' noise reported in Void64, here, a month ago has also surfaced here. It requires the same solution to clik the "Line" entry in Retrovol to stop it.

FYI

[OscarTalks]

I have re-compiled VLC-3.0.17.4 in S15Pup RC5
Linking to the upgraded libraries, I think it is an improvement to the build configuration of the Pup. People should ditch the previous VLC if using RC5 onwards. This VLC build also has the newer libdvdnav in a private directory and launches via a wrapper script. That means that gnome-mplayer still plays DVD when VLC is installed so either of the 2 players can be used. Uploaded for testing or in case they are useful to anyone.
EDIT:- Now updated to version 3.0.18 which apparently fixes some security issues
http://smokey01.com/OscarTalks/vlc-3.0. ... 4-s15p.pet (64bit)
http://smokey01.com/OscarTalks/vlc-3.0.18-i686-s15p.pet (32bit)

[ozsouth]

I've made a dual-boot S15Pup64RC5 iso (aufs & overlayfs) & have peebee's permission to mention it. The aufs option works as expected, but the overlayfs option does not have save working from cd. Also, trying to install the overlayfs version from cd simply gets the aufs version installed via puppyinstaller. One would have to add initrdo.gz to the boot folder & edit the grub script to call it. (pmedia, pdrv, psubdir are essentials in the grub 'linux' line. pdrv must specify exact partition, i.e. sdaX). Note sfs files can't be installed on the fly (view is OK) - must be loaded at boot time. Not really good for usb, if intending to save sessions. Not a newbie thing, so am limiting distribution to interested, experienced users for now.

[dimkr]

@ozsouth S15Pup already supports overlay if you boot with punionfs=overlay

overlay.png (19.7 KiB) Viewed 5107 times

[OscarTalks]

guvcview-2.0.8 compiled from source code in S15Pup RC5
This is a small .pet package of this Webcam viewer which also captures still pictures and video/audio.
It has SDL2 and portaudio dependencies included as shared libs, self-contained in a private directory location and launches via a simple wrapper script.
PPM offers a salix build of guvcview-2.0.7 but drags in a massive stack of dependencies, so I think this custom Puppy build is a much better option.
Uploaded in case anyone wants to try it out:-
http://smokey01.com/OscarTalks/guvcview ... 4-s15p.pet (64bit)
http://smokey01.com/OscarTalks/guvcview ... 6-s15p.pet (32bit)

[ozsouth]

@dimkr wrote:

@ozsouth S15Pup already supports overlay if you boot with punionfs=overlay

Ok, now I'm completely confused. I did the above & bootup showed switch to overlayfs, so definitely working.
Running df in a terminal only shows 'unionfs', whereas my setup shows 'overlayfs'.
Upon exit, I was allowed to use a savefile, which loaded on the next boot. I was sure this was not an option.
Under my method, it certainly isn't. Earlier posts of yours seem to confirm overlayfs lacks that option. Help.

[dimkr]

Running df in a terminal only shows 'unionfs', whereas my setup shows 'overlayfs'.

Look closer at my screenshot. The mount is called "unionfs" but the type is "overlay". The init script uses the name "unionfs" with either aufs or overlay and it's probably one of the few remains of unionfs (what Puppy used before aufs) in Puppy. It's just a name.

[ozsouth]

@dimkr - thanks - I get that now. Re-savefile - I notice it contains a folder 'upper' - obviously the differences to the upper layer created from my a,b,c,d,e,y drvs being merged, after I make changes. So I guess it's safe data-wise to proceed with it.
(I amended peebee's original initrd.gz to include b,c,d,e between a & y drvs).

[dimkr]

@ozsouth overlay support in woof-CE is in good shape, I've been using it for months. But save files created when using aufs are incompatible with it, because overlay needs a non-overlapping working directory under the same file system: the init script has to create two directories under the save file/folder, save to one and use the other as the working directory.

[amethyst]

@ozsouth overlay support in woof-CE is in good shape, I've been using it for months. But save files created when using aufs are incompatible with it, because overlay needs a non-overlapping working directory under the same file system: the init script has to create two directories under the save file/folder, save to one and use the other as the working directory.

A question here. I don't use a save file but save my changes to an additional drive like an adrv (which is then automatically loaded with the other Puppy files at bootup the way we are used to with traditional Puppys). Does this situation change when using overlays and also if so - since it will be useful to use additional drives, how many additional drives can be loaded and in which order of preference? With aufs the adrv has preference to the base sfs for instance.

[ozsouth]

@amethyst - I made a ydrv settings file (due to my initrd.gz changes), & as it loads last, it updates previous drvs. It works with overlayfs. In the standard init, if you don't have ydrv or bdrv or a savefile, adrv would load last. If you have other drvs, starting a disposable test system, then running df will show you loading order. Main thing for everyone to note is you can't mix aufs & overlayfs savefiles.

[amethyst]

@amethyst - I made a ydrv settings file (due to my initrd.gz changes), & as it loads last, it updates previous drvs. It works. In the standard init, if you don't have ydrv or bdrv, adrv would load last. If you have other drvs, starting a disposable test system, then running df will show you loading order.

My question is with regards to overlays (which I don't have a clue how it works). So my question is whether my current adrv with system changes will work the same with overlays (I suppose the overlay system has a different initrd)? So you have changed the initrd for the overlay filesystem and extended it with an additional ydrv only? Will renaming my adrv to a ydrv using your initrd work for the overlay system and how easy/difficult is it to envoke more additional drives to work with overlays)? From what I have gathered it's not that easy to load extra sfs as it is with sfs_load so more additional drives for use with overlays seems beneficial? With my current setup (aufs) - adrv, ydrv, bdrv, cdrv... loads in order of preference.

[dimkr]

woof-CE's init script behaves mostly the same, regardless of aufs/overlay. None of the patches floating around in the forums, which add cdrv, ddrv, etc' are merged into woof-CE. If you submit them for inclusion in https://github.com/puppylinux-woof-CE/woof-CE/pulls, we'll be able to integrate them and then you won't have to maintain your fork of initrd.gz with extra changes.

[ozsouth]

Re-github pull requests - Can I upvote this one?

https://github.com/puppylinux-woof-CE/w ... 05e03049e3

[amethyst]

And just a mention - I have one initrd (with all the extended additional drives) that works for all the Puppys I use from Racy through to Buster (I just edit DISTRO_SPECS for the different Puppy names). They are all 32-bit but it also works with the one 64-bit system I have. So maybe an initrd to fit all?

[Duprate]

@ozsouth S15Pup already supports overlay if you boot with punionfs=overlay

Interesting! I hadn't tested this feature yet (punionfs=overlay). Good alternative, for those who want to test a non-AUFS kernel, without having to change a lot of things.
I usually use the Wiak initrd, which allows loading up to 100 modules!
Here on the forum, there is always something new to learn.... We just need to read!

Reading some more ..... viewtopic.php?t=7448
The parameter "punionfs=overlay" is unnecessary if the used kernel only accepts "overlayfs". S15Pup64 will use overlayfs, having detected this kernel.
Happiness! I can compile the kernel from the tarball downloaded directly from the source (https://kernel.org/), no more worries......

[ozsouth]

Linked below is an update my initrd.gz for S15Pup64-22.11 - allows b,c,d,e drvs in addition to the a,y,f,z,puppy drvs in standard iso.
EDIT: Now Redundant - 2212 version posted a couple of pages later.