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.
Moderator: 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.
There is even woofV, if anyone wants to dare try it.
I'll give it a drive around the block.........
BarryK wrote: Fri Mar 08, 2024 3:04 pmHere is 240308 pre-alpha, if anyone wants to take it for a spin:
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.
Caramel,
I have posted a fix to your other bug report:
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 wrote: Fri Mar 08, 2024 4:26 pmProblem 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.
Caramel wrote: Fri Mar 08, 2024 4:26 pmAfter 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.bin0xfe seems to launch xfe.bin
xfe.bin launchs xfe.bin0
xfe.bin0 launchs xfe.binNEW 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 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.
BarryK wrote: Sat Mar 09, 2024 3:16 pmCaramel wrote: Fri Mar 08, 2024 4:26 pmAfter 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.bin0xfe seems to launch xfe.bin
xfe.bin launchs xfe.bin0
xfe.bin0 launchs xfe.binNEW 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.
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.
New Laptop - ASUS ZenBook Ryzen 7 5800H Vega 7 iGPU / 16 GB RAM
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
Caramel wrote: Sat Mar 09, 2024 3:53 pmBarryK wrote: Sat Mar 09, 2024 3:16 pmCaramel wrote: Fri Mar 08, 2024 4:26 pmAfter 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.bin0xfe seems to launch xfe.bin
xfe.bin launchs xfe.bin0
xfe.bin0 launchs xfe.binNEW 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.
I cannot provide a solution to this. I have looked and looked at the code, and cannot see how it is possible for this problem to occur.
yet it did!
I will have to "hope" that it happens to me, then maybe will get a clue how it could have happened.
TerryH wrote: Sat Mar 09, 2024 10:21 pmI 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.
Yes, @Thanos also posted about the web browser unable to save directly to a mounted partition:
Puppy Linux users are accustomed to apps running as root, and having write access anywhere.
I didn't mention it in that other thread -- sometimes there is too much to remember -- but there is a simple fix...
I'm running Chromium browser right now, running as user "chromium". I can write to any folder anywhere just by doing this:
Code: Select all
# chgrp -R filesgrp /mnt/sda1/temp16
...that is, I have partition sda1 mounted and it has folder "temp16". Just by changing the group of temp16 to "filesgrp", then all of the apps that run non-root can write into it. The "-R" means recursive, and that is optional, only if there are sub-folders that you also require to be writable.
I should probably put this information somewhere where users will be aware of it.
The technical reason why this works can be seen in /etc/group. User "chromium" belongs to "filesgrp", and the permission on the temp16 folder are 775, meaning that any app belonging to group filesgrp has "7" permissions, that is, read, write and execute.
Don't worry about that technical explanation if it is unclear -- the result is what matters!
In the other thread, I also mentioned another fix:
Code: Select all
# chown -R chromium:chromium /mnt/sda1/temp16
...do this if you want only Chromium to have write access and not other apps that run non-root. And if you really want to tighten up security, do this:
Code: Select all
# chmod 700 /mnt/sda1/temp16
...then only Chromium will be able to write into it. Other apps won't even be able to see inside temp16 folder.
Caramel wrote: Sun Mar 10, 2024 7:49 amTo 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 25In 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
Fixed:
Caramel wrote: Sat Mar 09, 2024 3:53 pmLike 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.
I have read doc about execution order of commands in script bash. Commands run one after the other. So my idea was stupid.
Another assumption, The script steup-client was applied twice to xfe. First time xfe is renamed xfe.bino0 and a script xfe is created. Second time, the script xfe is moved to xfe.bin0 and xfe is recreated as the same script.
Xfe was installed with a dependency, maybe there is a link.
Anyway the problem did not recur in my other tests (for example with okular that have a lot of dependencies)
EDIT: there are 4 .desktop files in the xfe package
Hi @BarryK
i saw this from you today and it got me to thinking a little:
Forum member shinobar wrote that script in 2010, minor mods in 2012, 2015, 2016 and one small change in 2023.
I really should fix those scripts to look at /usr/share/X11/xkb, but for now have just implemented the easy solution; made /usr/share/X11/xkb into a symlink. Here is the woofV commit:
As you are progressing, I am sure you have your eye on the increasing movement in Void, Arch, and others to present-day Pipewire, Wayland, GTK4 and QT6 along with the myriad of packages .
This is just a mentions as your efforts to fix, might take-on a "directional fix" that will map easily for you in WoofV going forward.
I personally think that @shinobar's "FirstRUN" is a fabulous, unique to the Linux community, utility ever developed. It makes life simple with the facets of the system, up-front, for user handling all in one screen at desktop arrivals. One of many found in the forum, but one of best, IMHO.
Just a thought.
Caramel wrote: Sun Mar 10, 2024 7:01 pmCaramel wrote: Sat Mar 09, 2024 3:53 pmLike 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.I have read doc about execution order of commands in script bash. Commands run one after the other. So my idea was stupid.
Another assumption, The script steup-client was applied twice to xfe. First time xfe is renamed xfe.bino0 and a script xfe is created. Second time, the script xfe is moved to xfe.bin0 and xfe is recreated as the same script.
Xfe was installed with a dependency, maybe there is a link.
Anyway the problem did not recur in my other tests (for example with okular that have a lot of dependencies)
EDIT: there are 4 .desktop files in the xfe package
I have made some changes to setup-client:
https://github.com/bkauler/woofq/commit ... bf3bf46f9f
Don't know for sure if it will fix the problem.
BarryK wrote: Mon Mar 11, 2024 2:54 amI have made some changes to setup-client:
https://github.com/bkauler/woofq/commit ... bf3bf46f9f
Don't know for sure if it will fix the problem.
@BarryK , thanks again for all your amazing work.
I started the test of WoofV. It requires a lot of spàce. After several hours I arrived at the step 6post-process-rootfs. The free space on my partition has gone down 9GB.
PS : In the terminal i saw the message.
./6post-process-rootfs: line 332: strip: command not found
Caramel wrote: Mon Mar 11, 2024 5:48 pmI started the test of WoofV. It requires a lot of spàce. After several hours I arrived at the step 6post-process-rootfs. The free space on my partition has gone down 9GB.
PS : In the terminal i saw the message.
./6post-process-rootfs: line 332: strip: command not found
I ran "du -m woofV" in /mnt/wkg/data and it reported a total of 6909, so almost 7GB.
Thanks for spotting the missing 'strip'. It is a utility in the 'binutils' package, which will be in the devx only.
However, I do have the strip utility linked statically with musl, and have created a package 'strip-static-2.28.pet' with just that one utility. Will include that in the next build.
I have fixed the "www" and "console" containers, but need to think some more about the fix.
With the next release of easyVoid, we will be able to test that updating works.
Installation test of easy_240311_amd64 obtained yesterday in /mnt/wkg/data/woofV/export.
It seems like usual but there is a little surprise. The icons in ROX-Filer are very small.
EDIT: the symlinks inode-directory.png and inode-mount-point.png was missing in /usr/local/apps/ROX-Filer/ROX/MIME
NEW EDIT : After fscheck of the partition, new install of easyvoid_240308, new test de woofV, same error with missing symlinks
rockedge wrote: Sun Jan 21, 2024 1:44 pmKennel Linux's have in general both a xbps GUI using OctoXBPS and xbps via command line.
Screenshot_2024-01-21_08-44-22.pngWe added in a program called
xdeb
in/usr/local/bin
which will convert a Debian or Ubuntu.deb
packages into.xbps
packages. xdeb on GitHub
I'm about to try and convert a Musescore .deb package to xbps, and I'm looking at the xdeb github, which says to "set XDEB_PKGROOT=${HOME}/.config/xdeb to avoid cluttering your current working directory. Binaries will then be exported to ${XDEB_PKGROOT-.}/binpkgs."
typing echo $XDEB_PKGROOT
in terminal yields no output. So I'm guessing this location variable is not set already in Airedale.
Anything I should consider or avoid as this is the first time I'm trying this conversion procedure?
geo_c
Old School Hipster, and Such
@geo_c I usually just did the conversion in a /root/Build directory, and let it rip. Then cleaned up which is not much.
I am in Boulder Colorado at the moment but will be home Saturday night!