BookwormDog build script

A very great thing about the Puppy Linux Forum is that it has been the home to incredible creativity. There are many derivatives of Puppy Linux, including the *Dog distributions. I use the word "derivative" rather loosely; The *Dog distros are really Debian or Ubuntu or Devuan distributions made to look like Puppy Linux. Which they do very well.

I want to checkout the latest offerings on the Puppy Forum. Apart from the *Dog distros, there are others including FatDog (nothing to do with the *Dogs; a different pedigree), the KL* distros, VanillaDpup. etc.

Starting with DebianDog, there is a build script for Bookworm:

https://forum.puppylinux.com/viewtopic.php?t=5069

I ran the script:

# ./mklive-bookworm -gui

A huge selection to choose from:

...I chose the Jwm minimal. Next-up, ticked some checkboxes:

First error:

...however, the script did download the deboostrap deb and I was able to install it. Had to run the script again from the start. Then it put up another message that package dpkg is missing. I installed that from PKGget, and it required starting the script from start again.

A few more windows came up, all good, and packages got downloaded. I did see some errors flash by on the terminal:

Preparing to unpack debootstrap_1.0.134_all.deb ...
Unpacking debootstrap (1.0.134) ...
dpkg: dependency problems prevent configuration of debootstrap:
 debootstrap depends on wget; however:
  Package wget is not installed.

dpkg: error processing package debootstrap (--install):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 debootstrap
Setting up debootstrap in bookworm/chroot

...note, wget is installed. Another error:

Reading package lists... Done         
W: GPG error: http://dl.google.com/linux/chrome/deb stable InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY E88979FB9B30ACF2
E: The repository 'http://dl.google.com/linux/chrome/deb stable InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
Hit:1 http://deb.debian.org/debian bookworm InRelease
Hit:2 http://security.debian.org bookworm-security InRelease                                                
Hit:3 http://deb.debian.org/debian bookworm-updates InRelease                                               
Hit:4 http://deb.debian.org/debian bookworm-proposed-updates InRelease                
Get:6 http://dl.google.com/linux/chrome/deb stable InRelease [1825 B]                 
Get:5 https://github.com/doglinux/book-worm/raw/master/amd64 ./ InRelease [2304 B]
Err:6 http://dl.google.com/linux/chrome/deb stable InRelease 
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY E88979FB9B30ACF2
Reading package lists... Done
W: GPG error: http://dl.google.com/linux/chrome/deb stable InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY E88979FB9B30ACF2
E: The repository 'http://dl.google.com/linux/chrome/deb stable InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

The script asked a question about squashfs compression and I chose "xz":

Now we will create compressed kernel: k-6.1.0-25-amd64.squashfs and filesystem: '01-filesystem.squashfs'
Please enter your choice, xz compression will give smaller size than gzip,
but xz takes much longer time to compress
Type gzip or xz : 

This is where things went wrong, or so it seems. Lots of error messages flashed by, captured some of them:

[===/    ]   690/21205   3%Failed to read file chroot/proc/irq/6/node, creating empty file
[===/    ]   690/21205   3%Failed to read file chroot/proc/irq/6/smp_affinity, creating empty file
[===/    ]   690/21205   3%Failed to read file chroot/proc/irq/6/smp_affinity_list, creating empty file
[===/    ]   690/21205   3%Failed to read file chroot/proc/irq/6/spurious, creating empty file
[===/    ]   690/21205   3%Failed to read file chroot/proc/irq/7/affinity_hint, creating empty file
[===/    ]   690/21205   3%Failed to read file chroot/proc/irq/7/effective_affinity, creating empty file
[===/    ]   690/21205   3%Failed to read file chroot/proc/irq/7/effective_affinity_list, creating empty file
[===/    ]   690/21205   3%Failed to read file chroot/proc/irq/7/node, creating empty file
[===/    ]   690/21205   3%Failed to read file chroot/proc/irq/7/smp_affinity, creating empty file
[===/    ]   690/21205   3%Failed to read file chroot/proc/irq/7/smp_affinity_list, creating empty file
[===/    ]   690/21205   3%Failed to read file chroot/proc/irq/7/spurious, creating empty file

Then it seemed to be stopped, though the hard drive remained very busy. After about 15 minutes, I typed CTRL-C to quit:

[===/    ]   690/21205   3%Failed to read file chroot/proc/keys, creating empty file
[===|    ]   690/21205   3%^CUnmounting mount binds in chroot
# 

Should I have waited longer? I will ask on the forum.    

Tags: linux

EasyOS and Bedrock Linux

I have posted about Guix, an application manager that can run in any Linux distribution, and provide an alternative repository:

• Decided not to integrate Guix into EasyOS — September 21, 2024
• Guix works with EasyOS — September 20, 2024

Nix package manager is similar. Guix and Nix install packages that run as though they are native apps, with full access to the filesystem and I/O.

Forum member Caramel investigated Nix, see here:

https://forum.puppylinux.com/viewtopic.php?t=8904

AppImages and Flatpaks also behave like native apps, though the Flatpak sandbox can sometimes make this difficult.

Running apps in a container or VM (virtual machine), on the otherhand, is an isolated environment. Apps do not see the main filesystem and may have very limited I/O capability. It is possible to punch holes, for example could bind-mount /files inside the container or VM. But then, that's the whole idea; run the app securely, isolated from the rest of the system. Note also, some apps do not work properly in the container or VM environment, despite punching holes.

Now along comes Bedrock. It was forum member antithesis who mentioned Bedrock and (just now) got me interested in it:

https://forum.puppylinux.com/viewtopic.php?t=6592

What you do is bootup an installed Linux distribution, then run the Bedrock script. This "hijacks" the Linux distribution, moves it all to a different location, and replaces the main filesystem with its own. I have done this with EasyOS, and after being hijacked, everything was moved to /bedrock/strata/easyos

At first, I attempted with a normal EasyOS; however, Bedrock choked on the aufs layered filesystem. It wants a normal full installation, so I created a usb-stick with EasyOS fully installed, no SFS layers, no initrd. I then ran the Bedrock script and hijacking worked. Rebooted and got the normal EasyOS desktop. Almost everything works, except apps that require dbus coud not find the dbus socket -- should be able to sort that out.

Jesse at Distrowatch wrote a very nice review of Bedrock a couple of years ago:

https://distrowatch.com/weekly.php?issue=20210705#bedrock

Here is the Bedrock homepage:

https://bedrocklinux.org/

What I can do next, is add another strata, say Alpine Linux, and install apps that will run just like native apps.

Very interesting; however, EasyOS as-is is not suitable. I need to create a variant that is only a full install, which would be an entirely different distro, going back to what Quicky Linux was. QV (Quantum Vis, or Quirky Void) is a full install -- might use that as the starting point, except build from Scarthgap and do not use btrfs.

Stay tuned!    

Tags: easy

Decided not to integrate Guix into EasyOS

I posted yesterday about Guix package manager:

• Guix works with EasyOS — September 20, 2024

After a couple of enthusiastic days intensely working on Guix, and planning to integrate it into EasyOS, doubts started to creep in.

In balance, I decided that it doesn't bring enough "to the table" to warrant inclusion. Yes, I want to expand the package repository; however, will focus on improving the existing package managers. For example, can add more Flatpaks to Flapi.

Regarding Flatpaks, I installed ShotCut and OpenShot video editors, just to confirm they work OK. Reason for doing that, is OpenShot installed via Guix, sound didn't work; sound with ShotCut was OK. Midori web browser installed via Guix didn't work.

With Guix, it is advised to run "guix pull" which performs package updates -- unfortunately, this takes a very very long time. Then there's the size of downloads; I used to think Flatpaks were big, but now think they are not so bad. Flatpak downloads are bundles of packages, whereas Guix downloads individual packages; prefer the former.

The "last straw" was when I shutdown and saved the session, shutdown hung. Somehow, $PATH got stuffed up. Yeah, I was experimenting with guix-binary tarball from git master branch, so could not expect high degree of stability. Even so, it has been years since Easy hung at shutdown.

I think Guix will work best in the Guix OS, not as a foreign package manager.

Another thing I didn't like, is although Guix claims to only install to /gnu and /var/guix; in fact, it creates or requires (or requires editing) folders and files in other places. Trying to recall... /etc/guix, /root/.config/guix, /root/.guix-profile, /etc/profile.d/guix, /etc/.bashrc, /etc/init.d/guix-daemon

It's an OK product, just don't think it is a good fit with EasyOS.   

Tags: easy

Guix works with EasyOS

This is extremely interesting!

What originally motivated me to consider Guix was a forum post by member Stogie:

https://forum.puppylinux.com/viewtopic.php?p=130981#p130981

...see my reply, that there are ways to install more applications, such as AppImages, Flatpaks and another OS running in a container.

Each of those, though, has issues. It got me wondering about distro-independent package managers. These are package managers that can install in any Linux distribution. They have a large package repository and install packages with all dependencies separate from the host system. Yes, that is similar to AppImages, Flatpaks and another OS in a container.

As far as I can make out though, these package managers do not have paranoid sandboxes like Flatpaks and containers, nor do they duplicate all dependencies for each app as with AppImages. It looks like the possibility of smaller overall size and run nicely on the host system.

I found three different distro-independent package managers. Firstly, Homebrew:

https://github.com/Homebrew/brew

...designed originally for MacOS, now also works in Linux. Secondly, Nix:

https://nixos.org/

And thirdly, Guix:

https://guix.gnu.org/

The website provides an install script, that I had to hack on quite a bit, but got there. Ha ha, the script ended reporting successful install, and I didn't know what to do next. Baby steps seemed to be missing. A search, found lots of tutorials and videos, so was able to take the baby steps and install a package.

The Guix project is hosted here:

https://savannah.gnu.org/projects/guix/

...I went there to see just how active it is; and yeah, very active. Lots of developers; that's good.

Regarding my baby steps after running the install script, I rebooted and then did this; I didn't really know what that does, but some documentation said to do it:

# guix pull
Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'...
Authenticating channel 'guix', commits 9edb3f6 to 59db76c (37,220 new commits)...
Building from this channel:
  guix      https://git.savannah.gnu.org/git/guix.git	59db76c
substitute: updating substitutes from 'https://ci.guix.gnu.org'...   0.0%guix substitute: warning: ci.guix.gnu.org: host not found: Servname not supported for ai_socktype
substitute: 
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'...   0.0%guix substitute: warning: bordeaux.guix.gnu.org: host not found: Servname not supported for ai_socktype
substitute: 
substitute: updating substitutes from 'https://ci.guix.gnu.org'...   0.0%
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'...   0.0%
...

Thanks to Giuliano, for his very grass-roots explanation on installing Guix:

https://gist.github.com/giuliano108/49ec5bd0a9339db98535bc793ceb5ab4

...yes, I had to modify /etc/services file. I used his cut-down file, but do need to find what is required to edit the original /etc/services

It took awhile, downloaded lots of packages. Played with it right until 4.30am this morning. Now back at it at 9.00am and checking sizes:

# du -h -s /gnu /var/guix
4.2G	/gnu
35M	/var/guix

...yeah, big.

What I did in the early hours of this morning, is firstly installed a "Hello World" app:

# guix install hello
...
# hello
Hello, world!

Then got more ambitious:

# guix install shotcut
...
# shotcut

...it works! Well, it started anyway, didn't actually use it.

There are some more setup details for the Guix apps to run nicely in a host OS, that I have yet to do.

Here is a list of online Guix resources:

https://github.com/techenthusiastsorg/awesome-guix

I can see potential here, to add many more packages to EasyOS. Maybe a fifth package manager, complimenting PKGget, SFSget, Flapi and Appi. Or, a completely new approach...

I wonder... over the years, there have been so many exploratory projects on the Puppy Forum, perhaps someone has considered Guix. Yes, Caramel has explored both Nix and Guix:

https://forum.puppylinux.com/viewtopic.php?t=8904

...I would have seen that before, but forgot. Caramel has discovered the fix required for /etc/services

Stay tuned; quite likely there is going to be a very interesting outcome.    

Tags: easy

EasyOS Scarthgap-series version 6.3.1 released

The previous release, 6.3, was on September 10:

• EasyOS Scarthgap-series version 6.3 released — September 10, 2024

Release notes for 6.3.1:

https://distro.ibiblio.org/easyos/amd64/releases/scarthgap/2024/6.3.1/release-notes.htm

Download:

https://distro.ibiblio.org/easyos/amd64/releases/scarthgap/2024/6.3.1/

Feedback welcome at the forum:

https://forum.puppylinux.com/viewtopic.php?p=131141#p131141

Have fun!    

Tags: easy

Russian menu translations improved

New forum member bulatsib posted improvements for the Russian translations of menu entries:

https://forum.puppylinux.com/viewtopic.php?p=130855#p130855

Myself and forum member Maybe (who has been previously contributing Russian translations) have reviewed the new contribution, and it is very good, now merged into WoofQ.   

Tags: easy

Geany mysterious Chinese behaviour

I used MoManager to create Simplified Chinese zh_CN.UTF-8 translations for /usr/bin/quicksetup, using MoManager's automatic translation feature. The result is in Easy 6.3. However, there is something weird with geany text editor...

A quicksetup.pot file is created like this:

# cp /usr/bin/quicksetup quicksetup.sh
# xgettext -o quicksetup.pot --no-wrap quicksetup.sh

The automatic translations are applied to quicksetup.pot and it becomes quicksetup.po and the latter is then opened in geany for review:

The translations are Chinese characters, and under the Document menu the filetype is UTF-8; yet something weird is displayed instead of the Chinese characters.

Now, take that .po file, convert it to .mo binary format, then back to .po:

...now geany displays the Chinese characters correctly! Including the "Quick Setup":

For the record, here is how I converted po -> mo -> po:

# msgfmt --check --output-file=quicksetup3.mo quicksetup1.po
# msgunfmt --no-wrap quicksetup3.mo > quicksetup3.po

Well, I discovered that it is the comments at the beginning of quicksetup1.po that cause the problem; deleted them and quicksetup1.po displayed correctly in geany.

I have put a fix into MoManager, but left puzzled with geany's behaviour.

EDIT:
It turns out I was barking up the wrong tree. The quicksetup.po file had an invalid UTF-8 sequence on line 123, and this caused the entire file not to display the Chinese characters. Weird. I fixed it by using 'iconv' utility to cleanup the file. This removes the invalid UTF-8 (inserted about line 1077 in /usr/local/momanager/momanager):

    mv -f /tmp/momanager/${ATEXTDOMAIN}.po /tmp/momanager/orig1.po
    iconv -f utf-8 -t utf-8 -c -o /tmp/momanager/${ATEXTDOMAIN}.po /tmp/momanager/orig1.po
    LANG=C defaulttexteditor /tmp/momanager/${ATEXTDOMAIN}.po

That fixed it.     

Tags: easy

Easy Buster running in container

I am prompted to revisit this mechanism after reading this post by forum member Stogie:

https://forum.puppylinux.com/viewtopic.php?p=130981#p130981

One of the reasons for creating Easy Containers was to be able to run other Linux distributions. There was a blog post in 2018 showing how to run XenialPup:

https://bkhome.org/news/201811/xenialpup-75-running-in-easyos.html

Quite a while since I tested this, so having a go with installing Easy Buster 2.6.2. Firstly, click on the "pkg" desktop icon and choose SFSget:

Now choose the buster SFS:

It downloads, then click on the "NEW" button:

And that's it, now have "buster" icon on the desktop:

Click on "buster" and it works:

...what I have done as shown in the photo, is clicked on "petget" icon, then updated the package database, then installed Eye Of Gnome image viewer. It appears in the menu as "Image Viewer" but I ran it from a terminal to check that it didn't output any error messages. Yep, eog works fine.

Simple to flip back to the main desktop with Alt-F6, or on some keyboards the function keys require another key, like Fn-Alt-F6. On the main desktop, can click on "buster" to flip back, or "buster" in the tray.

As running in a container has security restrictions, this may impede some applications. What you can try is to run Buster with minimum security settings. In the menu "Filesystem -> Easy Container Management" you can choose "A container with absolute minimum security" for buster.   

Tags: easy