Puppy Linux Discussion Forum

Caramel wrote: ↑Sat Mar 09, 2024 3:53 pm

BarryK wrote: ↑Sat Mar 09, 2024 3:16 pm

Caramel wrote: ↑Fri Mar 08, 2024 4:26 pm

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.

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 pm

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.

Yes, @Thanos also posted about the web browser unable to save directly to a mounted partition:

viewtopic.php?t=10906

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:

# 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:

# 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:

# 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.

Some uninstall fixes:

https://bkhome.org/news/202403/package- ... fixes.html

Caramel wrote: ↑Sun Mar 10, 2024 7:49 am

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

Fixed:

https://bkhome.org/news/202403/bugfix-e ... board.html

Caramel wrote: ↑Sat Mar 09, 2024 3:53 pm

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 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 pm

Caramel wrote: ↑Sat Mar 09, 2024 3:53 pm

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 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 am

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 , 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 pm

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

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.

Caramel wrote: ↑Mon Mar 11, 2024 5:48 pm

I started the test of WoofV.

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 pm

Kennel Linux's have in general both a xbps GUI using OctoXBPS and xbps via command line.
Screenshot_2024-01-21_08-44-22.png

We 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 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!