KLV To-Do List

[wiak]

@wiak I had to fix up the FRmake_initrd.sh that I have by replacing the download block in the code.

From this :

Code: Select all

_get_FR_initrd (){
  wget -c --no-check-certificate https://owncloud.rockedge.org/index.php/s/HRZhsnouSm3Gpf3/download -O modify_initrd_gz.sh && chmod +x modify_initrd_gz.sh
  wget -c --no-check-certificate https://owncloud.rockedge.org/index.php/s/CXixDo8Dd2rtxSQ/download -O initrd-latest.gz
  wget -c --no-check-certificate https://owncloud.rockedge.org/index.php/s/8aFjxy5QrjfyI8o/download -O w_init
}

To this :

Code: Select all

_get_FR_initrd (){
wget -c https://owncloud.rockedge.org/index.php/s/HRZhsnouSm3Gpf3/download -O modify_initrd_gz.sh && chmod +x modify_initrd_gz.sh
wget -c https://owncloud.rockedge.org/index.php/s/BQm758UXWSJ2O1k/download -O initrd-latest.gz
wget -c https://owncloud.rockedge.org/index.php/s/bolhoXwFylKi335/download -O w_init-latest
}

Now again producing Void Kernels components for KLV!!!

That's fine. Yes, the links had changed. I needed the no-check-certificates for a while - must have been something wrong at your owncloud which you've since fixed.

[fredx181]

Though I'm taking a break from further development work at present I note that the likes of run-as-spot is not necessarily most appropriate form of such script.

In line with something I mentioned elsewhere, when you are usually booting between several distros it is normal that the first regular user is known to Linux as UID 1000. So for Puppy Linux distros, user spot is that user who has UID 1000. But on my Zorin lite installation, user wiak is my first added user.....
.....
.....

Perhaps it's best that every distro has it's own "run-as-spot" (e.g. "run-as-firstrib", edit: easy to change all instances of "spot" to e.g. "firstrib") ) but anyway here's an attempt to make it work in general.
Attached run-as-spot-mod.
It works by checking all 1000 and above UID's and picking the first username that has an existing "home" directory (e.g. /home/wiak, for KLV it will be 'spot' (edit: see EDIT)) (not necessarily assuming UID 1000, could be 1001 or 1002 too in some cases).

run-as-spot-mod.gz

Remove fake .gz and make executable (and rename as desired)

(3.24 KiB) Downloaded 95 times

EDIT; Correction, on KLV it's not 'spot' that has the first numbered UID (1000 or above), it's "weedog" (UID 1000).

[rockedge]

on KLV it's not 'spot' that has the first numbered UID (1000 or above), it's "weedog" (UID 1000).

I think during the build phase in the PLUG file it is determined which user will be UID 1000. Perhaps we should change that to allow user spot to be UID 1000 but I don't really see the need too at this time.

[fredx181]

on KLV it's not 'spot' that has the first numbered UID (1000 or above), it's "weedog" (UID 1000).

I think during the build phase in the PLUG file it is determined which user will be UID 1000. Perhaps we should change that to allow user spot to be UID 1000 but I don't really see the need too at this time.

Agreed, I don't see the need too as KLV has user spot already builtin, the run-as-spot-mod is possibly just for to use on any distro where it's not (as suggested by @wiak)

[wiak]

run-as-spot-mod.gz

EDIT; Correction, on KLV it's not 'spot' that has the first numbered UID (1000 or above), it's "weedog" (UID 1000).

Thanks fred, I'll take a look. When it comes to sharing resources/permissions and so on it is certainly the UID and GID that are important and not the human names for these.

[wiak]

Not sure why I thought it was a good idea to drop my not-so-old HP ProBook 430 G8 business laptop today, but within seconds of picking it up, a cable I had accidentally left attached snagged and pulled it out of my hand whereupon it swung violently on that cable in an arc, smashing off the bottom metal edge of my computer table. Oh dear... Re-connected it and switched it on and, oh dear again, screen was cracked (and big dent in case body I managed to straighten with careful use of pliers). Connected it to HDMI external monitor and adjusted the screen resolution via xfce4-display program (xrandr-based I guess). But proved tricky to use since cracked laptop screen insisted on coming on first and couldn't read BIOS setup from HDMI screen at all...hmmm...what to do I wondered in tears (haha)??? Anyway, despite the despicable negative situation one good thing I discovered was a great disassembly video from HP and showed me that this particular laptop is nicely put together in terms of being easy to take apart and access and change pretty much all its main components (even the BIOS battery is simple to access, and the fan... how unusual - even more unusual that HP even provides official video telling you how to do it all). Nevertheless, LCD display panel replacement remains, unsurprisingly, somewhat expensive and tricky to take apart and replace, but I am going to order new raw display panel and hope to later manage the repair per the excellent video instructions (display panel coming from China so over a month before I get it).

In the meantime, I opened up the HP per the disassembly video, and disconnected the internal LCD cable. Good thing about doing that is that it automatically now detects the HDMI external monitor on boot and correctly sets its resolution and I can interrupt the boot process and even get into the EFI BIOS set up screen (I was surprised that was possible). So, even in worst scenario, if I mess up the installation of the new LCD panel this will HDMI arrangement works fine in the 'office' and also as a server...sigh. Oh well, yet another item added to my KL (and so on) To-Do List... Despite the many tricky repairs I have successfully performed over the years, I have these moments when I completely destroy something in seconds, particularly if I'm over-tired and trying to perform a particularly delicate repair - but the disaster today was somewhat different; bit like a self-implemented booby-trap that inevitably worked. Stupid other thing is that I usually treat this particular laptop with a particularly great amount of care, probably why I dropped it cos holding it too gently - so much for that strategy...

[wiak]

Hopefully temporary till I fix up the cracked other HP machine... Using KLA_XFCEbase (pristine followed by pacman -Syu to upgrade; kernel 5.15.94). The 2008 old HP 2530p 4GB RAM laptop is fast enough using that. Nice low power using CPU on this: Intel(R) Core(TM)2 Duo CPU U9300 @ 1.20GHz; Typical TDP: 10 W
I'll install zram onto it later.

[wiak]

In terms of 'future', it seems to me that this forum would benefit from further exploration of 'better' package management since quality of package management is fundamental to distro quality in practice.

As we most all know, there are currently several approaches to package management, the main two approaches being:

1. distro-specific package manager such as Puppy Package Managers like PPM and pkg, Debian-based dpkg/apt, pacman, Void Linux xbps and so on.at
2. Portable package formats, some of which include some form of containerisation and some, such as FlatPak, able to share some dependencies. Major examples of these being FlatPak, Snap, and AppImage though this forum also advocates a simpler 'portable app' sfs-addon-based design which tends to be less disk-storage hungry since often works on the basis that some libs are provided in standard shared lib form by the underlying distro filesystem.

However... if you really need to 'rely on' a portable app solution for say your business, a choice between FlatPak, Snap, AppImage (or alternative containerised possibilities such as Docker, Podman based app release mechanisms) appears, to me, pretty much essential despite the usefulness of home-grown solution for less critical Linux distro usage.

Since my family does have a small business operation some, though not all, of my own distro dev thoughts are influenced by what I need for that. Currently I use a number of AppImages, but avoid both Snap and FlatPak. However, I get the feeling that AppImage is an overly simplified mechanism that doesn't entirely address the real issue of making business distro maintenance as inexpensive (in every sense) as possible. So right now I'm deciding whether to prefer FlatPak or Snap; I'm tending towards FlatPak because of the way it stores apps in repositories in a similar to Git way (albeit binaries) and can share dependencies between apps when some apps using same runtimes. So... it strikes me that FlatPak functionality might be able to be provideed via an addon squashed filesystem (sfs), which could then be shared between different KL/FR-based distros. Similarly, the individual user-based per-app config information is shared in specific folders by FlatPak so if these were made mountpoints (rather than duplicated data per KL/FR-based distros) then any such-design KL/FR-based distro could share (without any duplication) the same FlatPaks including configuration and cache details.

I'm not just thinking of something to-do long in the future, business-related thoughts like I have are on-going so I'm planning my new Zorin OS install (which I use in business), including new use of FlatPaks for some major apps, and thereafter I plan to mount parts of this new Zorin install in such a way (per above brief description) that I can share the FlatPak local repo with my later KL/FR-based distro dual-boot arrangements.

Some just write off the use of Snap, FlatPak, AppImage, Docker/Podman container solutions and so on, but really such systems are not being created to 'take over' control of Linux, but rather they are attempted solutions to the genuine issues of reliable, maintainable, less-resource-intensive (particularly human labour/tech support), package management issues that complex Linux system use and management/maintenance involves.

Oh, I should mention, when I use Linux (Zorin currently) for business I log in as normal user and, actually, I do think that nowadays that is the best approach to using Linux (i.e. an idea not popular on this forum). However, when I develop a FirstRib-based distro I generally always arrange for it to be able to boot to desktop as root user, but, via a menu click or two, be able instead to login as normal user to desktop. I do prefer a root user login desktop for admin work, but am perfectly happy to login as normal user and simply set up file access permissions for that normal user to wherever I want to store files and so on. Having to be root user to access files is just bad organisation in my opinion - but main thing is that many apps nowadays simply do not happily run as root user(!) so I personally feel no need to fight that reality, since trying to fight it becomes far too time-consuming and limits actual other development work that would be a better use of dev time IMO.

EDIT: NOTE: https://www.apertis.org/architecture/flatpak-overview/
"...for storage-constrained devices, a customized runtime can be built that includes just the common libraries needed by its typical applications. This will avoid much of the unneeded “bloat” resulting from using a more generic runtime.

However, there is a trick to minimizing disk usage, which is that Flatpak will unconditionally de-duplicate all files from installed runtimes and applications. This means that, if two different runtimes or applications have the exact same files inside, only one copy of the files is stored on disk."
"...because Flatpaks use a different version of their libraries than the host system, the library memory will not be shared with the host. Despite this, Flatpaks still share the libraries in RAM with each other, as the kernel only ever considers if the same library is being loaded twice, regardless of which application is loading it. In other words, multiple Flatpak applications using the exact same library version will have it shared in memory, but they will not share it with any applications using that library on the host system."

However, the negative of the likes of FlatPak might be well-expressed here: https://ludocode.com/blog/flatpak-is-not-the-future

Hmmm... thus far to me AppImages is in practice still 'winning' for me (outside of using distro's own package manager); AppImages end to be much smaller than FlatPak solutions, but I guess that size-differential would drastically change if I did indeed employ LOTS of FlatPaks that had common runtimes. However, AppImages need certain core system libs on underlying system (i.e. excluded from AppImage) so do not it seems allow for newer libc for example to be included in AppImage).

[mikeslr]

When you have all the RAM and Storage Space you could ever want, how applications are packaged doesn't matter. But I hate waste on the one hand, and the creation of 'priesthoods' on the other. Both snaps and flatpaks waste space (and I suspect RAM). And they are both offered to us with a sneer "Take it or lump it." I've posted on the Forum several times suggesting that we do the latter.

Even I can follow the instructions for creating an AppImage if the actual publishers of applications continue to offer them other than as a flatpak. Regretfully, some aren't.

There's a 4th (albeit, hybrid) way of deploying packages. fredx181 (and IIRC watchdog) developed it; but Mikewalsh has championed its use: a portable-framework surrounding an AppImage. Within the portable folder are the AppImage itself; files which --via script-- will be copied or symlinked to /usr/share/applications and /usr/bin creating menu entries; and scripts to execute the AppImage with instructions. Those instructions can include any or all of the following, maybe others: (a) store settings and customizatons within the portable folder, copying them to and on closing removing them from the location the Application expects to find them within the Operating System; (b) run as root or spot, as needed/desired [TBH, my programming skills aren't at the level where I could always figure out how to offer both within the same folder]; and (c) make use of libraries within the portable folder.

If you run several operating systems, the last is important. An AppImage can be extracted and (at least under Puppys) there are tools for determining what libraries are missing. Those libraries could be installed into the Operating System. But providing them exclusively to the Application (with the launch script requiring their use) is often the better option. I've noticed, for example, that some applications use one iteration of Qt5 while another uses a different version and you can't install both. I'll bet there are others. The main stumbling block (at least for me) is that I don't have the programming skills to manage conflicting glibc libraries.

[wiak]

The main stumbling block (at least for me) is that I don't have the programming skills to manage conflicting glibc libraries.

There is a mechanism that I don't remember anyone using here, which is to run a different glibc in parallel to older distro glibc. That mechanism might help those who are trying to run newer browser with older distro. It generally requires compiling the newer glibc and installing it somewhere such as in /opt hierarchy, but as long as you have devx installed if using say Puppy then the instructions are pretty simple and well described here for anyone wanting to experiment with that: https://www.jertype.com/upgrading-glibc/

Aside from installing the new glibc in parallel, the trick is to use LD_PRELOAD mechanism to employ it rather than LD_LIBRARY_PATCH
Given as an example (back in 2018, using glibc-2.14) you would run the 'app', from the directory the app is in, using the command:

Code: Select all

LD_PRELOAD=/opt/glibc-2.14/lib/libc.so.6 ./app

The reason this method might be pretty good is that you are not removing the old glibc and existing distro apps were only compiled to work correctly with that older glibc, but by using LD_PRELOAD you are using the newer glibc with the application that needs it. I've seen others simply replacing the old glibc with a newer version and hoping that will reliably work, but truth is that results in a broken system because glibc is a core component and specific version is expected and often required by many existing distro components; even if pure replacement seems to work you can't rely on it but using newer version in parallel only for components that need that is better/safer approach. Still, whatever suits the user - their risk how they run their own system.

[dimkr]

You can use patchelf to force an application to load libraries from a given directory, i.e. patchelf --force-rpath --set-rpath /directory/with/.so/files /path/to/executable. It's a bit 'stronger' than LD_PRELOAD.

[mikeslr]

I'm not sure whether I should thank or curse Wiak and dimkr for their suggestions about how to implement alternate versions of glibc. I had updated Bionicpup64 as much as I was able, commenting that I might revisit it by trying to modifying initrd to employ additional 'alphabet drives' ala gyrog and amethyst. I buried that project. After a lot of work flinching libraries from Jammy --glibc and those needed by web-facing applications-- the product failed to sync on bootup. The same package --renamed as a ydrv for fossapup64-- was more successful. However, many important applications built-into fossapup64 no longer functioned. [Fixing that I would have ended up with Jammy: so why bother?] Now you've provided clues which would require studying and expanding my understanding of bash. I'm having serious doubts that resurrecting old puppys has value commensurate with the effort required.

It was comparatively late when I posted the above reply. I had in mind a specific post critiquing flatpaks, but couldn't recall its details. It was this one: viewtopic.php?p=87295#p87295. Gramps is an application which fully functional can be packaged as a 30 Mb deb. It's available as a 1.1 Gb flatpak which, in order to use, requires the installation of the flatpak framework, itself (IIRC) about 1 Gb. Flatpak --as a 1Gb installation which must always be present if you are to use flatpak'd application-- must have some impact on RAM availability.

The other application discussed in that post was Brave available as a 103 Mb deb or a 250 Mb flatpak. Not a particularly important distinction with today's computers. But with a weak internet signal it took three attempts to achieve a successful download of the flatpak. Can wget or uget even be used to download a flatpak? Edit: See my follow-up post below.

Both Gramps and Brave are web-facing applications. So flatpak's containerization provides a security advantage over direct installation. But containerization is not needed for applications which don't access the web. And aren't there more efficient ways to provide protection against malware?

As I wrote, anyone can create an AppImage or decompress an AppImage, examine its contents and modify it if necessary or desirable. I haven't checked*. But can that be done with flatpaks and snaps? If the publisher only provides an application as a flatpak or snapd, do those applications even qualify as 'open source' ? Edit: snaps can, see below. flatpaks can't. See follow-up post.

p.s. Just read wiak's link to https://ludocode.com/blog/flatpak-is-not-the-future. It's author did a much better, and more technically oriented, job than I could at explaining the flaws in packaging systems.

* I wouldn't know what to look for or at; so figuring out how hasn't been a high priority. Edit: Seems snaps are SFSes which dropped the suffix; and wget can be used to obtain a snap. See, watchdog's post, viewtopic.php?t=9043.

Watchdog's post may be particularly relevant to wiak's original query: what to use if dual-booting with Zorin. Snap is already installed. So snaps can be easily downloaded, and with the proper tools manipulated.

[mikeslr]

Follow-up. I wondered if watchdog's recipe for managing snaps could be imitated with flatpaks. So I opened my web-browser (Brave) to flathup.org and selected Brave. A download link was provided which I copied into uget. Uget downloaded a file named "com.brave.Browser.flatpakref."
Opening that in a text editor revealed:
[Flatpak Ref]
Name=com.brave.Browser
Branch=stable
Title=com.brave.Browser from flathub
IsRuntime=false
Url=https://dl.flathub.org/repo/
SuggestRemoteName=flathub
GPGKey= [VERY, VERY LONG GPGKey not copied here]
RuntimeRepo=https://dl.flathub.org/repo/flathub.flatpakrepo

Copying the last line into uget produces an error notification. Copying it into a web-browser results in

direct access to repo.png (9.95 KiB) Viewed 8446 times

Or, as I suggested a priesthood: "You need us to mediate communication and be grateful with what we give you"

[Sofiya]

Follow-up. I wondered if watchdog's recipe for managing snaps could be imitated with flatpaks. So I opened my web-browser (Brave) to flathup.org and selected Brave. A download link was provided which I copied into uget. Uget downloaded a file named "com.brave.Browser.flatpakref."
Opening that in a text editor revealed:
[Flatpak Ref]
Name=com.brave.Browser
Branch=stable
Title=com.brave.Browser from flathub
IsRuntime=false
Url=https://dl.flathub.org/repo/
SuggestRemoteName=flathub
GPGKey= [VERY, VERY LONG GPGKey not copied here]
RuntimeRepo=https://dl.flathub.org/repo/flathub.flatpakrepo

Copying the last line into uget produces an error notification. Copying it into a web-browser results in
direct access to repo.png

Or, as I suggested a priesthood: "You need us to mediate communication and be grateful with what we give you"

the same is true when choosing Brave from flathub https://flathub.org/ru/apps/search?q=Brave
so flatpak is so so idea.

[mikeslr]

I posted that there was a 4th (albeit hybrid) method of running applications: initiating an AppImage via a wrapper script providing instructions, viewtopic.php?p=93384#p93384. I wonder why that doesn't work?

I downloaded and deployed KLU-Jam as I'm more familiar with Ubuntus than other OSes in this Section. In fact, IIRC, I ran into the same problem with LinuxMint and a weedoged Pop_OS. I then filed browsed into the portable folders of MikeWalsh's latest Brave-Portable. While its AppImage could be started directly, it's LAUNCH script to control it would not run. This was also the case with other portables so constructed. I'm pretty sure I also tried what is essentially a version of fredx181's portable firefox, updated to use a newer version of firefox.

Neither KLU-jam, nor the others mentioned have Right-Click options. But scripts can be set to run in a terminal.

As all those portables use bash-scripts as wrappers, my guesses are that either (a) the bash version acceptable to Puppy Linux isn't to the 'Mainstream' distros I tested; or (b) some argument used in Puppy's bash 'dialect' isn't acceptable. But those are guesses and I'd really like to know the reason and if there's a work-around.

[geo_c]

I posted that there was a 4th (albeit hybrid) method of running applications: initiating an AppImage via a wrapper script providing instructions, viewtopic.php?p=93384#p93384. I wonder why that doesn't work?

I downloaded and deployed KLU-Jam as I'm more familiar with Ubuntus than other OSes in this Section. In fact, IIRC, I ran into the same problem with LinuxMint and a weedoged Pop_OS. I then filed browsed into the portable folders of MikeWalsh's latest Brave-Portable. While its AppImage could be started directly, it's LAUNCH script to control it would not run. This was also the case with other portables so constructed. I'm pretty sure I also tried what is essentially a version of fredx181's portable firefox, updated to use a newer version of firefox.

Neither KLU-jam, nor the others mentioned have Right-Click options. But scripts can be set to run in a terminal.

As all those portables use bash-scripts as wrappers, my guesses are that either (a) the bash version acceptable to Puppy Linux isn't to the 'Mainstream' distros I tested; or (b) some argument used in Puppy's bash 'dialect' isn't acceptable. But those are guesses and I'd really like to know the reason and if there's a work-around.

I run appimages and portables in KLV-airedale, KLA-XFCE, KLA-OT2,and KLV-spectrwm all the time successfully. I think the only mikewalsh portable that wouldn't fire up for me is Xnview image editor. So I'm running LibreWolf appimage, Ungoogled Chromium Portable, Gimp portable, Musescore Portable, Musescore appimage, Thunderbird portable, also Brave and Iron portable.

However I either boot them from Xfe or from a symlink to the launch script. Rox in Kennel Linux distros don't generally have the right-click options found in most puppies. But symlinking to a portable launch script should work. However, a few of the Kennel Linux variants, like Jammy I believe are barebones and may need a few utilities or run actions set in the file managers.

The most developed are KLV-airedale and KLA-Ot2/tint

EDIT: and there is a package that needs to be installed and active to run appimages, but I don't remember what it's called. Maybe @Sofiya knows.

EDIT2: Oh yeah I remember, it's fuse, or fusemount, or something like that. Needs to be installed and configed as a run action somehow.

[fredx181]

@mikeslr To add to what @geo_c wrote: For me too, Appimages and other Portable setups (e.g. from @mikewalsh) work in KLV, but ONLY from /mnt/home (which is a symlink to a partition that's mounted at boot (automatically).
NOT from other mounted partitions, reason is probably the mount method by "gvfs" which is "noexec", I'm getting a "permission denied" when e.g. running LAUNCH from terminal.
Not sure if it's same problem for you, but if it is, solutions can be:
- Run the Portable from /mnt/home, or:
- Mount the partition manually from terminal, e.g. if it's sda2 : mkdir /mnt/sda2_mount; mount /dev/sda2 /mnt/sda2_mount
(then it should work running the portable from mountpoint /mnt/sda2).

Btw, indeed Appimages work (from "gvfs mount", I guess that's because an appimage is mounted in /tmp.

EDIT: Curious, can anyone else confirm that a portable setup (such as @mikewalsh's) doesn't work on a "gvfs mount" ?
EDIT: Correction, the problem seems to appear when "run-as-spot" is used, e.g. when I edit the LAUNCH script (e.g. from my Brave-portable), remove run-as-spot and add --no-sandbox, it runs OK from a gvfs-mount.

[wiak]

EDIT: Curious, can anyone else confirm that a portable setup (such as @mikewalsh's) doesn't work on a "gvfs mount" ?
EDIT: Correction, the problem seems to appear when "run-as-spot" is used, e.g. when I edit the LAUNCH script (e.g. from my Brave-portable), remove run-as-spot and add --no-sandbox, it runs OK from a gvfs-mount.

I haven't tried it, but I have an educated guess... As I've said before, the first 'regular user' on FirstRib-based distros is user firstrib, not user spot, meaning firstrib has UID 1000 (spot has UID 1001). I suspect mikewalsh portable might work if arranged to run-as-firstrib rather than run-as-spot for that all-important UID reason. On Puppy Linux user spot is UID 1000 so actually firstrib in KL distros is actually spot in terms of ownerships and perimissions ... That's why I always run my KL and any other FR-based distro as regular user firstrib at home (when not doing admin work as user root).

An alternative would of course be to build your KL distros making spot (rather than firstrib) the first regular user added to the system for compatibility with Puppy Linux spot situation.

[fredx181]

EDIT: Curious, can anyone else confirm that a portable setup (such as @mikewalsh's) doesn't work on a "gvfs mount" ?
EDIT: Correction, the problem seems to appear when "run-as-spot" is used, e.g. when I edit the LAUNCH script (e.g. from my Brave-portable), remove run-as-spot and add --no-sandbox, it runs OK from a gvfs-mount.

I haven't tried it, but I have an educated guess... As I've said before, the first 'regular user' on FirstRib-based distros is user firstrib, not user spot, meaning firstrib has UID 1000 (spot has UID 1001). I suspect mikewalsh portable might work if arranged to run-as-firstrib rather than run-as-spot for that all-important UID reason. On Puppy Linux user spot is UID 1000 so actually firstrib in KL distros is actually spot in terms of ownerships and perimissions ... That's why I always run my KL and any other FR-based distro as regular user firstrib at home (when not doing admin work as user root).

An alternative would of course be to build your KL distros making spot (rather than firstrib) the first regular user added to the system for compatibility with Puppy Linux spot situation.

On KLV-Airedale, for me, run-as-spot works fine generally, but not from a portable setup on a "gvfs-mounted" partition (as I said, it does work OK from the boot partition (/mnt/home) ).

[geo_c]

On KLV-Airedale, for me, run-as-spot works fine generally, but not from a portable setup on a "gvfs-mounted" partition (as I said, it does work OK from the boot partition (/mnt/home) ).

I also have no problem with run-as-spot portables like UngoogledChromium, but I also locate all my portables on /mnt/home, so essentially every drive that contains my OS's has it's own directory of portables and appimages located in /mnt/home and they all run fine, which is why I'm such of fan of them, they run in every OS I'm using, except for Xnview, which might be due to some other issue entirely. Xnview-portable runs in pups, but not KLV-airedale.

I keep the portable directory in sync with different machines and drives using rsync scripts like:

Code: Select all

#!/bin/bash
rsync -r -t -v --progress --delete --modify-window=1 -l -H -s /mnt/home/portableAPP /mnt/sdb2

MYDIR=$(cd `dirname $0` && pwd)
cd $MYDIR
cd ..
cd ..
cd ..
touch APP--$(date +"%m%d.%H%M").log

The second half of the script drops a marker file on the drive from where it's run named with the date and time it was run, so I can quickly look at the drive and tell when the portableAPP directory was last synced to my other machines.

With that approach I can update an appimage or portable, add new portables, and quickly sync the changes and profiles folders on other machines by running the script using "run in terminal" from Xfe or Rox, which is advisable to see what was done. Rox will run the script with a left click, but you won't know how it's working or when it's completed.

[rockedge]

in KLV-Airedale user weedog is UID 1000 and user spot UID 1001

Try with the run-as-weedog script

[fredx181]

in KLV-Airedale user weedog is UID 1000 and user spot UID 1001

Try with the run-as-weedog script

Tried that, with Brave from "gvfs mounted" /run/media/root/disk2/Brave-portable64/brave , from terminal in that directory

Code: Select all

root# cd /run/media/root/disk2/Brave-portable64/brave
 run-as-weedog ./brave
bash: line 1: cd: /run/media/root/disk2/Brave-portable64/brave: Permission denied
[0711/184452.027007:ERROR:icu_util.cc(240)] Invalid file descriptor to ICU data received.
Trace/breakpoint trap
root# 

Same error as running as spot.
So still my experience is that run-as.. (spot, weedog) doesn't work from a "gvfs mounted" partition, but it may have to do with my setup (having nvme... partitions), not sure, so I'm still curious if anyone can reproduce this problem.

[Sofiya]

Brave-portable64 works fine for me
but I have rewritten the LAUNCH

Code: Select all

#!/bin/sh
#
# Launcher for 'portable' Brave browser
#
HERE="$(dirname "$(readlink -f "$0")")"
#
mkdir "$HERE/PROFILE" 2> /dev/null
mkdir "$HERE/PROFILE/root" 2> /dev/null
mkdir "$HERE/PROFILE/root/Brave-Browser" 2> /dev/null
#
chown -R root:root "$HERE/brave"
chown -R root:root "$HERE/lib"
chown -R root:root "$HERE/PROFILE/root"
#
if  grep -q 'puppy_tahr64' /etc/os-release
then
	LD_LIBRARY_PATH=$HERE/:$HERE/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
	"$HERE/brave/brave" --user-data-dir=$HERE/PROFILE/root/Brave-Browser --no-sandbox --disk-cache-size=5000000 --media-cache-size=5000000 --allow-outdated-plugins "$@"
elif grep -q 'puppy_xenialpup64' /etc/os-release
then
	LD_LIBRARY_PATH=$HERE/:$HERE/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
	"$HERE/brave/brave" --user-data-dir=$HERE/PROFILE/root/Brave-Browser --no-sandbox --disk-cache-size=5000000 --media-cache-size=5000000 --allow-outdated-plugins "$@"
else
	"$HERE/brave/brave" --user-data-dir=$HERE/PROFILE/root/Brave-Browser --no-sandbox --disk-cache-size=5000000 --media-cache-size=5000000 --allow-outdated-plugins "$@"
fi

[fredx181]

Brave-portable64 works fine for me
but I have rewritten the LAUNCH

Yes, as root it works, but the question is if it works with run-as-spot or run-as-... (on a gvfs/udisks mounted partition).

[wiak]

In old version of KLV-Airedale I have installed:

Code: Select all

root# run-as-spot ./viber.AppImage 
bash: line 1: cd: /run/media/root/5fdab471-5732-48f6-b04e-f46b0586e915/home/mcewanw/Downloads/AppImages: Permission denied
execv error: No such file or directory

But I tried with different AppImage (Ferdium) in KLU-jam and that seemed to work okay. I'll post again in a few minutes from KLU-jam to see if viber AppImage working there (it is stored on different partition, where I have full install of Zorin in my Zorin mcewanw home directory in /home/mcewanw/Downloads/AppImages).

[wiak]

Okay, I am trying Ferdium AppImage instead since have missing library related to viber on KLU-jam which is a different issue...

Same permission issue using Ferdium AppImage with KLV-Airedale, and also with KLA-OT2base (but yes, works if put Ferdium under /mnt/home). However, again with KLU-jam, Ferdium starts up from that same gvfs mounted partition... No idea what the difference might be.

The following was KLA-OT2base result:

Code: Select all

┌──[ root@archlinux ] [ 00:44:51 ]
├── /run/media/root/5fdab471-5732-48f6-b04e-f46b0586e915/home/mcewanw/Downloads/AppImages
└># run-as-spot ./Ferdium-linux-Portable-6.2.2-x86_64.AppImage 
bash: line 1: cd: /run/media/root/5fdab471-5732-48f6-b04e-f46b0586e915/home/mcewanw/Downloads/AppImages: Permission denied
execv error: No such file or directory

But as I say, from same mounted location with KLU-jamXFCE there is no issue (EDIT: except, needed to install fuse) - Ferdium AppImage starts fine. I have no idea how to track this difference down, but would be good to do so. Perhaps the gvfs in KLU-jamXFCE doesn't have that noexec situation? How to check that? Show with simple command 'mount'?

[wiak]

I don't know anything much about gvfs and fuse, but in KLU-jamXFCEbase, the mount command doesn't show any gvfsd-fuse, instead looks like this (including trying to install gvfs and fuse just to show already installed really):

Code: Select all

root@ubuntu:~# apt install gvfs
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
gvfs is already the newest version (1.48.2-0ubuntu1).
0 upgraded, 0 newly installed, 0 to remove and 126 not upgraded.
root@ubuntu:~# apt install fuse
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
fuse is already the newest version (2.9.9-5ubuntu3).
0 upgraded, 0 newly installed, 0 to remove and 126 not upgraded.
root@ubuntu:~# mount | grep gvfs
root@ubuntu:~# mount | grep fuse
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
root@ubuntu:~#

In KLV-Airedale a gvfsd-fuse is shown after mount command, but no fusectl. No idea what that all means though except somewhat different.

EDIT: Just also tried KLA-OT2baseCE (older release than current) and it also indicated gvfsd-fuse when mount command run, but also fusectl. It also has the permissions and execv error when trying to run AppImage not in /mnt/home though. So only KLU-jam working without that error in what I tested.

[fredx181]

@wiak thanks for your efforts anyway, but there's a misunderstanding, Appimages work fine for me from what I tested (edit: but I see you have problems with that too), what I was talking about in the first place was that the "mikewalsh" type portable setup (folder) doesn't work when it's not running as root.
Later I found that if I try to execute directly (with run-as-spot or run-as-...) e.g. the brave binary, see https://forum.puppylinux.com/viewtopic. ... 736#p93736 it errors out (so nothing to do with "portable" or "appimage", I guess).
(and works OK on the "boot" partition (which is not a gvfs type mount such as mounted in /run/media/...).
EDIT: may have to do with how gvfs (or... it is probably udisks) mounts ("noexec") but not sure.

EDIT2: Sorry didn't read well your posts in the first place, now I understand more (I think )
EDIT3:

Perhaps the gvfs in KLU-jamXFCE doesn't have that noexec situation? How to check that? Show with simple command 'mount'?.

Just check mount for /run/media and it's probably saying "noexec" and "nodev".

[wiak]

So, after more than a year for sure I'd say, I decided to check out build_firstrib_rootfs script code for Ubuntu, Debian, and Devuan, but unfortunately I have hit a stumbling block there, so I likely have to forget about these variants for the moment...

The problem is: in the script the following line exists:

Code: Select all

# Download pkgdetails from wiak github repo, for debootstrap
	wget -c https://raw.githubusercontent.com/firstrib/firstrib/master/pkgdetails_uclibc_i686_static_wiak -O usr/lib/debootstrap/pkgdetails && chmod +x usr/lib/debootstrap/pkgdetails

What is pkgdetails, you may wonder. Well, it was a little trick to avoid needing to have perl in the chroot in which I was using debootstrap. I compiled that pkgdetails_uclibc_i686_static some years ago when I implemented these Debian-based firstrib builds. Would be fine still, except, for some reason unknown that github site of mine is gone (at least not mine anymore...). I don't seem to have a local copy of pkgdetails - I've searched like crazy - and I've only done a cross compile like that once before so not something I can do again quickly tomorrow... It maybe isn't best way to do the debootstrap routine anyway, but was convenient so would work in even very simply host distros without perl. Actually, I have compiled the source code for pkgdetails again tonight - seems to work as a static standalone, but I'm not sure and debootstrap is not working so I think something wrong with it... I can do it another way via host installed debootstrap and perl, but I don't like that. For now I just don't have time to work further on this. However if, by very slim chance, anyone has a clone or copy of firstrib github that actually has that file in it (so long ago, I only briefly remember even making it...) then please let me know. It is not something you would find in the build directories after use since the clean-up stage removes unnecessary build script helpers... I usually also have a copy emailed to myself of things like that, but I must have been busy and didn't imagine github losing it for me.... Oh well... Void and Arch builds should remain fine - Fedora, I haven't had time to check. Bit annoyed about the loss, but c'est la vie - doesn't really matter to me.

EDIT: But is is a roadblock stopping Ubuntu/Devuan/Debian build_firstrib_rootfs builds working and a waste of future time addressing the issue, so if anyone happens to have clone of that vanished (somehow) github firstrib site that includes only missing package pkgdetails_uclibs_i686_static_wiak that would be a big help since time to address such a difficult matter in future isn't certain to me; other scripts fine, but cross-compile uclibc stuff a headache to me now. As I said, pkgdetails is not something that will be found in actual isos or other builds produced - it simply gets downloaded and then removed once used during the build process - doesn't effect Void, Arch, or Fedora builds.

Don't be alarmed by any such though. I'm busy till March 2024, but will be able to fix that Debian-based build stuff even if pkgdetails doesn't get found. What happened to my github!!! I scratch my head. Anyway, I have no idea about that (I have no idea about jstree, whatever that is - I know nothing much about java script at all if that is what that is about... weird... can't work out what happened...). Not considering anything sinister - maybe I suddently had interest in something about jstree - no idea, maybe just forgot about pkgdetails and deleted old repository or something... I will just have to rework that uclibc pkgdetails package later, or do it a different way.

[wiak]

Thank you Void Linux... replacement statically-linked package for my Debian-based build_firstrib_rootfs variants. Still some work to do, but probably getting there now...

A little smaller once stripped of course, but not much.

All good now, Ubuntu, Debian, Devuan builds now working in my under-fix build_firstrib_rootfs script. Will have to change the docs slightly too to explain an issue that needs addressed, when doing Debian-based build on some systems (e.g. this nvme SSD system of mine with thunar...). Don't need that old pkgdetails lost file now... whew. I'm not as rusty as I thought I was. Fluke maybe.