easyVoid development

[BarryK]

Another progress report:

https://bkhome.org/news/202402/woofv-po ... ootfs.html

[BarryK]

And another:

https://bkhome.org/news/202402/woofv-dr ... sktop.html

Fixed a few things, and running through the scripts right now. Intention is to boot the new easyVoid, version 240223, and plan to run it and next-up develop PKGget to work as a frontend to XBPS.

[megan183]

Great to hear about the progress version 5.5, it's exciting to see the integration of Void Linux binary packages. Sorry but can we get some knowledge about how are you planning to handle future updates and package management challenges with PKGget?

[rockedge]

@BarryK just a mention here about some wobbly behavior we experienced yesterday with booting KLV's caused by updates from upstream Void Linux repos.

This seems now to be resolved and updates today fixed the problems we had booting certain kernel combinations, mostly involving the newer Void Linux kernels themselves. You have already noticed that occasionally updates/upgrades can outpace themselves........

[BarryK]

woofV build 240224, with snapshot:

https://bkhome.org/news/202402/woofv-bu ... -well.html

@megan183
I still have to think through how PKGget is going to be modified.
Hope to get the various buglets in the 240224 build fixed and start on PKGget tonight.

@rockedge
I'm not using a Void kernel. Still on aufs and compiling my own kernel.

Yes, I experienced Void repository undergoing changes. They have transitioned from libllvm15 to libllvm17, and my "240223" build yesterday got caught in the middle. Some packages required libllvm15, some libllvm17, consequently needed both in the build. They are very big packages and made 'easy.sfs' much larger.

With 240224 build, the transition to libllvm17 has been completed.

[BarryK]

Yes, I experienced Void repository undergoing changes. They have transitioned from libllvm15 to libllvm17, and my "240223" build yesterday got caught in the middle. Some packages required libllvm15, some libllvm17, consequently needed both in the build. They are very big packages and made 'easy.sfs' much larger.

With 240224 build, the transition to libllvm17 has been completed.

Er, libllvm15 was gone, but I did another build this evening, same package selection, and libllvm15 is back. So suddenly easy.sfs has jumped to much bigger size. Still works, but disconcerting.

[rockedge]

The ability to use Puppy Linux huge kernels in KLV using the skeleton version of the initrd.gz gives us some versatility in kernel choices and doesn't force us to use Void kernels. All of the RT kernels used are made with a Fossapup64 or VoidPup64 kernel-kit usually with both AUFS and Overlayfs built in. I'll make the KLV versions for ease of use from these. It is possible to use any Puppy Linux huge kernel that has overlayfs as a module or better, built in.

We have not worked with AUFS directly in KLV builds but can use kernels that have both overlayfs and aufs. Interesting is how easyVoid can use AUFS and now wonder if easyVoid could boot with one of these full real time kernels that have AUFS included. Not pressing or important to the project, but never the less an interesting prospect.

[BarryK]

PKGget (PPM), now a GUI frontend for XBPS, is running on easyVoid, see blog report:

https://bkhome.org/news/202403/pkgget-w ... 40229.html

Still a lot of work to do, hope to bring out a pre-alpha release of easyVoid in a few days, for anyone interested in testing it.

[BarryK]

The ability to use Puppy Linux huge kernels in KLV using the skeleton version of the initrd.gz gives us some versatility in kernel choices and doesn't force us to use Void kernels. All of the RT kernels used are made with a Fossapup64 or VoidPup64 kernel-kit usually with both AUFS and Overlayfs built in. I'll make the KLV versions for ease of use from these. It is possible to use any Puppy Linux huge kernel that has overlayfs as a module or better, built in.

We have not worked with AUFS directly in KLV builds but can use kernels that have both overlayfs and aufs. Interesting is how easyVoid can use AUFS and now wonder if easyVoid could boot with one of these full real time kernels that have AUFS included. Not pressing or important to the project, but never the less an interesting prospect.

The kernel used in EasyOS has a patch for "Linux Capabilities", splitting "cap_sys_mount" out of "cap_sys_admin". The patch is two files, here it is for the 5.15.x kernel:

https://github.com/bkauler/oe-qky-kirks ... ericx86-64

For the 6.6.x kernel, as used in easyVoid, those two patch files needed slight changes to fix fuzziness. They are in tarball here:

https://distro.ibiblio.org/easyos/sourc ... -20240212/

This is used in Easy to drop admin rights for the root user, making it "crippled root", yet retain right to mount filesystems.

[rockedge]

@BarryK noticed on the Blog the year is off a bit. It is a leap day.

Screenshot(24).jpg (9.61 KiB) Viewed 1180 times

[BarryK]

New script 'xbpsget', similar to 'petget':

https://bkhome.org/news/202403/xbpsget- ... kages.html

Have taken a big step to get XBPS to work with the aufs or overlay layered filesystem.
This first step is handling user-installed packages when there is a version update:

https://bkhome.org/news/202403/easyvoid ... kages.html

Haven't tested it yet. Hope there isn't anything about this method that XBPS will object to.

[mimine]

Hey Barry,
what do you think about merging devx with the whole puppy, so it is included by default in the distro ? ok puppy will be bigger, but it is easier to manage that way.
My 2 cents

[BarryK]

Hey Barry,
what do you think about merging devx with the whole puppy, so it is included by default in the distro ? ok puppy will be bigger, but it is easier to manage that way.
My 2 cents

The last time that I built the devx sfs for easyVoid, that was version 6.0.2, it was 402MB, and easy.sfs 798MB.

I wouldn't want to merge the devx into easy.sfs, as that would make loading into RAM at bootup more problematic.

Keep it as a separate devx.sfs and include it in the drive-image file, it bumps the file to about 1.3GB
Actually, the latest easy.sfs 240239 is 848MB, so even bigger. And probably the devx has also grown. A huge file to download.
As most users are not interested in the devx, I don't want users to be hit with a 1.5GB download with content that they don't need. Also, that large size will put many people off from downloading it.

For some people, a 1.5GB download is nothing, but many people have severely limited monthly data allowance. And/or low speed.

[rockedge]

For some people, a 1.5GB download is nothing, but many people have severely limited monthly data allowance. And/or low speed.

Yes totally agree! We work at it to keep the ISO/IMG under 950 M and right now the KLV's hover around 780 M to 860 M. Though KLV-Hyprland is a bit more fancy and is bigger. The rootfs SFS hangs at about 650 M. Although we have really not done any "stripping" or removing any documentation so there is room to improve...but it is not so Easy to get easy....... (wow....)

I would think keeping the Devx separate is the best direction to go.

[dimkr]

A "devx" forces people who want only GCC to download a big bundle with way more than just GCC. This always frustrated me with Puppy, because I always end up installing something that depends on a package in devx, a big SFS - big download, big RAM hog if copied. Some Puppy releases even have Python in devx, although many applications (not development tools) depend on it.

IMO the question is how many users end up downloading devx. If most users do, this separation doesn't have much value, and individual installation of packages (not bundling together) allows data plan savings compared to the current state.

[rockedge]

I don't have Python in the Devx I use with F96-CE_4. I use a lot of programs that need Python, many switches for X10 stuff I assembled I have written in Python2 and Python3. I have some motion/object detection programs for Zoneminder that do the heavy lifting in object recognition, facial identification, license plate readers so a good full featured Python installation is required, Better managed directly installed.

Though most any of the really useful PERL modules happen to be in the Devx. Has been for many Puppy Linux variations. So for example to allow a ZoneMinder installation to really work the Devx has to be loaded, or ZM will not function.

I suppose now a days, keeping the base distro under 700 M or at least under 1 G is not as important.

@dimkr you advocate for all the development tools and or the different language interpreters and their many modules to be installed as needed? This is what we do in Kennel Linux, if one needs or wants developer tools, compilers they'll have to install it via package manager. Same with Python and PERL as dependencies.

There is always the inclusion of scripts that would automate the installation of said base-devel, tools and language interpreters.

It is much easier getting these things running well using upstream Void Linux repos than it is with a Puppy Linux, where there is the advantage the developer tools and utilities will "just work" as a SFS image file when loaded. All prepared and configured for that specific distro to run loaded on the fly. Python is tricky to get working correctly using the usual Puppy Linux package management. PERL easier when using cpanmenu but in the long run the Devx made sense for Puppy's, perhaps not so much for Void Linux based distro's. Though I could see configurations and library paths being packaged in a an SFS to accompany installed components.

[dimkr]

@dimkr you advocate for all the development tools and or the different language interpreters and their many modules to be installed as needed?

Yes, let users install specifically what they want and let the package manager handle dependencies.

I understand the consequences: some users don't know they need libc headers to do anything with GCC, and some want a complete package building setup. However, if the existence of devx causes trouble (like packages that can't be installed because the package manager treats them as installed because they're in devx, or missing dependencies because they're in devx) and these problems affect more users (don't know, don't have numbers), maybe devx can be replaced with a one-liner that installs all included packages and makes 90% of its fans happy.

[rockedge]

maybe devx can be replaced with a one-liner that installs all included packages and makes 90% of its fans happy.

I think this is the best option to help the novice get going in the right direction. One could have several scripts that give some options easy to click on, that will auto-install the developer environment.

[mimine]

I remember I wanted to install an nvidia driver, it needed devx.

[BarryK]

Testing interaction between XBPS and vpm utilities and PPM, looking good:

https://bkhome.org/news/202403/testing- ... kgget.html

Right now, there is just one thing on the to-do list, and might be ready to upload a easyVoid 240308 pre-alpha tonight, or 240309 in the morning.

Haven't thought any more about the devx; postponing that until later.

I think Caramel posted some fixes in other discussion threads, but my mind has been elsewhere recently, focused on this woofV project.

[BarryK]

Here is 240308 pre-alpha, if anyone wants to take it for a spin:

https://bkhome.org/news/202403/easyvoid ... alpha.html

There is even woofV, if anyone wants to dare try it.

[rockedge]

There is even woofV, if anyone wants to dare try it.

I'll give it a drive around the block.........

[Caramel]

Here is 240308 pre-alpha, if anyone wants to take it for a spin:

https://bkhome.org/news/202403/easyvoid ... alpha.html

Problem with non US keyboard.
EDIT 24/03/09 after reruninng quicksetup, it works! I do not know why

The command setxkbmap fr works

EDIT:
New problem.
After installation of xfe via PKGget (repository void-current), xfe do not start.

The real executable was not installed

In /home/xfe/xfe there is a script AppRun to launch xfe (exec xfe)
In /usr/bin there are three scripts xfe, xfe.bin and xfe.bin0

xfe seems to launch xfe.bin
xfe.bin launchs xfe.bin0
xfe.bin0 launchs xfe.bin

NEW EDIT : the scripts xfe.bin0 and xfe are identical

EDIT 3:
After

Code: Select all

xbps-remove xfe

there are no more scripts in /usr/bin but /home/xfe was not deleted

EDIT 4:
Reinstallation of xfe with xbps-install. This time xfe.bin0 is the real executable

EDIT 5:
Test installation abiword with PKGget. No problem.

EDIT 6:
Apparent origin of the bug:

/usr/local/clients/setup-client, lines 561 to 572 (Easyvoid)

Code: Select all

 case $APPflag in
  true)
   #[ ! -e ${PREFIXDIR1}${APPpath}/${APPname}.bin ] && cp -a -f ${PREFIXDIR1}${APPpath}/${APPname} ${PREFIXDIR1}${APPpath}/${APPname}.bin
   gen_bin_func #${PREFIXDIR1}${APPpath}/${APPname} #20230511 20230511
   rm -f ${PREFIXDIR1}${APPpath}/${APPname} #in case it is a symlink.
 echo '#!/bin/bash
if [ "$(whoami)" != "root" ];then exec sudo-sh ${PPID} ${0} ${@}; fi' > ${PREFIXDIR1}${APPpath}/${APPname}
   echo "APPbin='${APPpath}/${APPname}.bin'
APPname='${APPname}'" >> ${PREFIXDIR1}${APPpath}/${APPname}
   echo "$RUNASCLIENT" >> ${PREFIXDIR1}${APPpath}/${APPname}
   chmod 755 ${PREFIXDIR1}${APPpath}/${APPname}
  ;;

In the sub-function gen_bin_fuck there are the commands

Code: Select all

APPin="${PREFIXDIR1}${APPpath}/${APPname}"

and

Code: Select all

mv -f ${APPin} ${APPin}.bin0

If this last command is executed before the long command above

Code: Select all

   echo "APPbin='${APPpath}/${APPname}.bin'
APPname='${APPname}'" >> ${PREFIXDIR1}${APPpath}/${APPname}
   echo "$RUNASCLIENT" >> ${PREFIXDIR1}${APPpath}/${APPname}

there is no problem.

It seems it my first xfe installation, the mv command was executed after the echo command.

[BarryK]

Caramel,
I have posted a fix to your other bug report:

viewtopic.php?t=10909

Notice to everyone, if you want to run the LoginManager to change an app from running as root to non-root, or vice-versa, the fix attached to the above post is required.

[Caramel]

Problem with non US keyboard.
EDIT 24/03/09 after reruninng quicksetup, it works! I do not know why

New test with a fresh install of easyvoid.

Keyboard fr (number 20) is choosen in the first boot.

Then when JWN is displayed, QuickSetup is opened on the desktop.

The fr keyboard is preselected. I made no change about it. Then click on OK.
The XKB Config Manager opened. No need of variant so i only click to apply and quit. (Edit: correction of a typo)

Test in sakura. It's the us keyboard configuration(layout).

It's the script XkbApplyNow in /usr/local/apps/XkbConfigurationManager that is responsible of the configuration used.
XkbApplyNow use the informations of /etc/X11/xorg.conf.d/10-evdev-puppy.conf
At this time it says that the layout is "us" instead of "fr"

Then i reopen quicksetup, change the choice of keyboard layout to another. This time /etc/X11/xorg.conf.d/10-evdev-puppy.conf gives the right layout.

I rechange to fr. Again 10-evdev-puppy.conf changes and so indicates the fr layout.

[BarryK]

After installation of xfe via PKGget (repository void-current), xfe do not start.

The real executable was not installed

In /home/xfe/xfe there is a script AppRun to launch xfe (exec xfe)
In /usr/bin there are three scripts xfe, xfe.bin and xfe.bin0

xfe seems to launch xfe.bin
xfe.bin launchs xfe.bin0
xfe.bin0 launchs xfe.bin

NEW EDIT : the scripts xfe.bin0 and xfe are identical

I am unable to reproduce this problem.
I'm running 240308 right now, and installed xfe via PKGget, and the three xfe, xfe.bin and xfe.bin0 are correct.
I cannot see how the code in setup-client could have produced your result.

Did you do anything else before, like install and uninstall with xbps-install and xbps-remove?
Or with vpm?

I do get a bug though. I used PKGget to uninstall xfe, and /home/xfe is supposed to be renamed to /home/.xfe but that hasn't happened.
Right, will investigate.

[BarryK]

I have received an email from Alfons. He has tested woofV and it went through and created easy-240309-amd64.img which he wrote to a usb-stick and it works.

[Caramel]

After installation of xfe via PKGget (repository void-current), xfe do not start.

The real executable was not installed

In /home/xfe/xfe there is a script AppRun to launch xfe (exec xfe)
In /usr/bin there are three scripts xfe, xfe.bin and xfe.bin0

xfe seems to launch xfe.bin
xfe.bin launchs xfe.bin0
xfe.bin0 launchs xfe.bin

NEW EDIT : the scripts xfe.bin0 and xfe are identical

I am unable to reproduce this problem.
I'm running 240308 right now, and installed xfe via PKGget, and the three xfe, xfe.bin and xfe.bin0 are correct.
I cannot see how the code in setup-client could have produced your result.

Did you do anything else before, like install and uninstall with xbps-install and xbps-remove?
Or with vpm?

I do get a bug though. I used PKGget to uninstall xfe, and /home/xfe is supposed to be renamed to /home/.xfe but that hasn't happened.
Right, will investigate.

I haven't install anything before xfe. Nor used a xbps command.

Like i say in my message (the EDIT 6) i think it's possible that the command to create the script xfe was executed before the command that move xfe to xfe.bin0.
In my next tests there was no problem.

[TerryH]

New frugal install of EasyVoid 240308. After initial set up following first boot i did basic checks of several frequently used installed apps. all functioning as expected, so I rebooted and created the save. On reboot I installed Zoom via AppImage Installer, the program wouldn't run due to being too old, so updated using the AppImage Installer Update functioning. Zoom functions correctly.

I tehn installed Audacious and Audacious_plugins using PKGget. The installation was successful. My local music files are located on a separate partition. After mounting that partition in rox, I was not able to see this partition using Audacious. I ran Audacious as root using audacious.bin0, the partition was now accessible. Playing an audio file failed. I ran the audacious.bin0 from a terminal and got error messages referring to pipewire. In Audacious settings I changed audio output to use pulseaudio. Audio files now played successfully.

I installed smplayer also to check the permissions issue. It also couldn't access the other partition, but had no issues using PulseAudio.

So everything looks pretty good so far. This is looking very positive. Thanks @BarryK for the continued EasyVoid development.

[Caramel]

To reproduce, start with a new install of easyvoid 240308. Just after the choice of the language, choose a non US keyboard (for example fr, fr is number20).
Immediately after the desktop is displayed (ignore quicksetup), look at /etc/X11/xorg.conf.d/10-evdev-puppy.conf line 25

In previous Easy, the layout is the layout choosen (in the example it is "fr") (I just retested with Easy 5.7. Edit: also tested with easyvoid 6.0.1)

In the last easyvoid, the layout is "us" hence the problem