KLV To-Do List

[fredx181]

@wiak @rockedge Yes, for now good to revert back to earlier w_init, indeed weird that it does force unmount the "bootfrom" partition in rc-12, in DebianDog (with XFCE) it has the "bootfrom" drive icon on Desktop and Thunar, but trying to unmount it by right-click "unmount" it refuses (says "busy"), but not very much comparable as it's using pup-volume-monitor instead of gvfs.
To get the proper symlink /mnt/home, the swapper.sh script needs to be changed to earlier version too:

Code: Select all

#!/bin/sh
# utility by fredx181 Jan2022
#
# revison 19Feb2022 by fredx181
#### Load swap ####
 echo "LOAD SWAP"
  for ONESWAP in `fdisk -l | grep ' Linux swap' | cut -f 1 -d ' ' | tr '\n' ' '`
  do
    echo -n "Loading swap partition $ONESWAP..." >/dev/console
    swapon $ONESWAP
  done
#########################

#### Create symlink /mnt/home ####
MNTHOME=$(mount | grep "/mnt/layers/merged/mnt" |  cut -d'/' -f3 | cut -d' ' -f1)
cd /mnt/
ln -sfn $MNTHOME home
#########################

[rockedge]

@wiak @fredx181

I put both fixes into KLV-Airedale-rc13 that is repackaged and uploaded, available for testing!

[fredx181]

I put both fixes into KLV-Airedale-rc13 that is repackaged and uploaded, available for testing!

https://rockedge.org/kernels/data/ISO/K ... e-rc13.iso

EDIT: Tested RC13, changes are OK. here's simple script to show the "bootfrom" drive icon on Desktop and in Thunar.

Code: Select all

#!/bin/bash
MNTHOME=$(mount | grep "/mnt/layers/merged/mnt" |  cut -d'/' -f3 | cut -d' ' -f1)
mkdir -p /media/$MNTHOME
mount /dev/$MNTHOME /media/$MNTHOME

When right-click "unmount" the icon disappears again, as how it was before running the script, that's ok IMO.

[wiak]

I think reverting will do. I installed Puppy dpup to compare and as Pupmode13 in terminal I did a umount of the bootfrom partition and that was allowed there too and thereafter save2flash wouldn't work. The gui Pmount doesn't allow the umount though, but of course Thunar with gvfs and so on can't be easily prevented anyway. So best procedure does in fact seem to be to simply make the mount point less accessible - years go by and nobody tried unmounting the underlying boot partition, so making that mount point appear on Desktop via /media/root handling turned out to be a bad idea afterall... better to hide what isn't wanted!

Save2flash doesn't work in KLV (or in Puppy) after the unmount. However, what I found in experiments to be very dangerous (DO NOT DO THIS) is to remount and try save2flash again.... Then save2flash messed up partition I was in... of course umount the bootfrom partition would have messed up overlayfs view of the layer structure and changing anything involved in layers is undefined in overlayfs usage (according to kernel docs) so is more than ill-advised.

LATER today, I'll revisit this, because other changes in very latest initrd I want to stay so I'll publish fixed latest once I get round to that. I have to change my other KL distro releases anyway to include fixed initrd. I'm not so bothered having bootfrom dir appearing in Thunar via /media/root since I'm used to opening it from /mnt location, but I suppose some may prefer that. Every time a new mount is made a little bit extra RAM is used though.

[wiak]

@rockedge, @fredx181

NEW initrd-latest.gz fetch script uploaded

Download get_WDLskelinitrd_latest.sh.tar from https://firstrib.rockedge.org/viewtopic.php?p=355#p355

Remove dummy tar and chmod +x

Running that script will fetch all of: initrd-latest.gz, w_init-latest, and modify_initrd_gz.sh

Latest is version 7.0.1 rc1

I will be using this initrd.gz version in all my own KL releases (once I have time to rebuild their isos...).

Newly made so needs testing and could, as always, be side-effects I didn't think of... but hopefully not... Been using a similar initrd.gz for a while, only a few changes from what I had under previouos dev test under name ver 700rc2.

IMPORTANT:

1. This is skeleton initrd-latest.gz so if not using huge kernel you need to put any needed initrd modules into its usr/lib/modules directory.

2. You need to remove the "/mnt/home" symlink code from previous KLV release /root/my-applications/bin/swapper.sh

Instead, initrd-latest.gz (actually it is the new w_init-latest) itself makes the link reliably (easy in there since bootpartition is known by the initrd/w_init code).

3. No mount tricks are necessary to put that bootfrom directory onto the Desktop; instead simply copy the /mnt/home symlink and paste it onto the Desktop (prior to constructing the iso)- you can rename Desktop copy of the link mnthome or whatever you want. Similarly, for Thunar, simply drag it across into Thunar bookmarks. Done that way, no issue with umount can arise.

[wiak]

Just a note to myself at least.

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 and so has that UID 1000. On my KL distros user firstrib has UID 1000. The point is that UID is what is used by Linux itself (not the human user name) to know what permissions to any resource have been assigned. In forum distros what we generally therefore want is to run the likes of Chromium as user who has UID 1000, so anything saved from Chromium will be accessible (correct permissions) even when booting up different distro.

i.e. the run-as-spot type of script would best be modified to run as user who has UID 1000 (whoever that turns out to be...). So need to modify that script and rename it to say run-as-1000 (rather than having a run-as-spot, run-as-firstrib, run-as-whoever script and so on).

[rockedge]

We have a run-as-user script from the period early in Kennel Linux development that might be of interest. @fredx181 I think supplied it which I later modified to be run-as-spot and run-as-weedog.

I have not looked at it yet but the thought is it might be a script to quickly modify and try out the idea @wiak has.

[rockedge]

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

[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 58 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 4678 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.