site  contact  history  index

Devuan will be repo for EasyPak

June 18, 2018 — BarryK

I posted yesterday about the genesis of EasyPak, my take on "universal packages":

I decided to use the Devuan "ascii" repository for building the universal packages. I have created script /usr/local/EasyPak/create_db and a repository spec file /usr/local/EasyPak/DISTRO_COMPAT_REPOS-devuan.

It works, creates the Puppy-format package files in /usr/local/EasyPak, for "main", "contrib" and "non-free". Script create_db can be rerun at any time in a running EasyOS to update these db files.

EasyOS "Pyro" series is built from packages compiled in my fork of OpenEmbedded. That is, a distro compiled entirely from source. However, the "universal packages" will be constructed from Devuan DEBs. This does not matter, as that is the whole idea of universal packages, that they will run on any Linux distro. Implementing this will be "proof of the pudding".

The next step... taking a break, will think about that later.

Tags: easy

Devuan package repositories

June 17, 2018 — BarryK

I mystery. I am getting woofQ setup for building from Devuan DEB packages. There used to be a 'merged' directory, which I think had all of the specially-modified non-systemd DEBs, plus everything else from the Debian repo.

However, looking in the Devuan repo for the latest release, Ascii (2.0), which is based upon Debian Stretch (9.0), the 'merged' path is, well, not merged.

It seems that we have to get the Devuan-modified DEBs from the Devuan repo, and the rest from the Debian repo.

Here is a mirror of the Devuan repo:

...look in folder 'a', no 'abiword' (for example).

To get abiword, we have to go to the Debian repo, for example here, look in 'a':

Some guys have been creating Devuan-based Puppies.  Forum member musher0 did a Jessie-based Devuan:

Forum member Sailor Enceladus did a Ascii-based Devuan:

...which I have just downloaded, to see how he tackled the DEB repository problem.

The light has come on. The package database at merged/dists/ascii/binary-amd64/Packages.xz has everything, the Devuan and the Debian DEBs. In the field that has the path to the DEB, there is "pool/DEVUAN/..." or "pool/DEBIAN/...", and the online repository at merged/pool/main has a server rewrite rule, that redirects to wherever the DEB actual is.

Tags: linux

Applying the KISS principle to universal packages

June 17, 2018 — BarryK

The main contenders for "universal packages", that is, apps that will run on any Linux distribution, are AppImages, Flatpaks and Snaps.

I have been studying them. AppImages seem a bit too limited, though a simple concept. Flatpaks and Snaps are very complicated, and after much reading, I think that there is a much easier way to achieve similar goals.

Thinking about a very simple mechanism for universal packages, it would seem that I need a proper CLI package manager, instead of PPM (PETget Package Manager, or Puppy Package Manager). Then I remember, there is such as project, named Pkg.

Pkg is a mammoth effort by Puppy Forum member sc0ttman. The project is described here:

There is older discussion here:

The project is online, at gitlab:

I downloaded:

# git clone git:// --depth 1

My idea for a universal package system, is to use what is already there, the DEB and RPM repositories, and their superb versioning and updating handling. The idea is simple: choose a package from a Debian/Ubuntu/Devuan/whatever repo, in a container in Easy, download it and all deps -- the secret is to download most deps, overwriting many packages that are already in the underlying q.sfs. A few details to fill in, but that's it, essentially.

The important point here, is that containers in Easy are complete, containing the entire Easy filesystem. This is because every container has q.sfs as a read-only layer in it. Other distros do not have this, they construct cut-down containers.

Each container in Easy has its own complete package manager. Which is where sc0ttman's Pkg may have a roll to play. I need to be able to do many operations from scripts.

So, although Easy now supports Flatpaks, from the commandline anyway, I might not use it.

Of course, my idea needs a name, so I reckon EasyPaks is appropriate! That's it, I officially name my universal packaging system EasyPak. With due acknowledgement of these guys!:

Tags: easy

EasyOS built with Flatpak support, take-1

June 16, 2018 — BarryK

I have posted about compiling the 'flatpak' package and its dependencies:

And generation of the signed-key pair needed to use Flatpak:

I had compiled 'flatpak' and several dependencies in a running EasyOS, so yesterday and today I ported them to my fork of OpenEmbedded. See the commits for June 16 and June 14, 2018:

The packages are:

flatpak, libseccomp, npth, libassuan, pinentry, appstream-glib, rng-tools, gnupg1-static (statically compiled 'gpg' utility, used in initrd), gpgme, gnupg, gcab, ostree, polkit105 (polkit version 0.105), libsoup, glib-networking

These were imported into woofQ and EasyOS built.

Now for a sanity test. Booting from a USB-stick, pristine first-boot, typed this in a terminal (requires Internet access):

# flatpak remote-add flathub
# flatpak install asked to confirm, I entered "y", then off it went. This time I watched the download, it was 566MB ...yikes!

Now to run it:

# flatpak run org.kde.krita


What I want to do next, is create a nice GUI. Probably will replace "petget" icon on the desktop with "appget", to run the Flatpak GUI.
When a Flatpak app is chosen, I want it to automatically install as an Easy Container, with icon on the desktop. So, each Flatpak app will run in its own container. This already happens, with Bubblewrap, but EasyContainers is more efficient, and from a tentative examination even looks more secure. times ahead!

Tags: easy

Auto-generated gnupg signed-key pair

June 15, 2018 — BarryK

I posted yesterday about getting Flatpaks working in EasyOS. This required a signed-key pair in /root/.gnupg, which is created using the 'gpg' utility.

I wanted to automate this, so that it is something that the user will not have to bother with setting up. I want Flatpak apps installation to "just work".

To this end, I compiled 'gpg' statically in OE, with the musl library. I used version 1.4.23, not the 2.x series of gnupg. The old 1.4.x series is still being maintained, due to its usefulness in embedded systems. The 'gpg' utility in gnupg 1.4.23 has less dependencies, but the static stripped executable was still big, at 850KB.

In the gnupg source package, the 'configure' script has the '--enable-minimal' option, to build a very small executable, however, it was so cut-down as to be broken. Instead, I configured as follows, which actually created a smaller executable:

# ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --build=x86_64-pc-linux-gnu --with-tar=/bin --disable-nls --disable-keyserver-path --disable-mailto --disable-finger --disable-hkp --disable-ldap --disable-keyserver-helpers --disable-photo-viewers --disable-bzip2 --disable-twofish --disable-blowfish --disable-idea --disable-agent-support --disable-card-support --disable-gnupg-iconv --disable-asm --enable-dev-random --enable-static-rnd=linux --without-readline --without-libusb --disable-camellia

Now for something contentious...

Prior to compiling, I edited 'config.h' and set NAME_OF_DEV_RANDOM to "/dev/urandom" instead of "/dev/random". The reason is, the kernel feeds activity to /dev/random, and when gpg is generating the signed-keys, it can suck everything from /dev/random and then block, waiting for the kernel to feed more random activity to /dev/random. On a running distro, this random activity is generated by usage, such as running an application, using the mouse, just about anything.

At bootup in the initrd, the situation is bleak if blocking happens. The way around it is for gpg to use /dev/urandom, which is like /dev/random except that it does not stop. If it runs out of random data, the kernel repeats whatever has already been sent. So no blocking occurs, and gpg generates the keys fast.

However, it must be understood that the generated keys are not as secure.

At first bootup, after the password is asked for, to encrypt folders in the working-partition, the same password is used as the passphrase to generate signed keys. The "real name" of the user is auto-generated as "EasyOS user $RANDOM". After bootup, look in /root/.gnupg and there they are, the signed-keys.

Note, there is /dev/hwrng, which apparently generates random data from the hardware, however, I do not know if it will work on all PCs, nor whether it is usable so early in the bootup.

Tags: easy

Testing flatpak in EasyOS

June 14, 2018 — BarryK

As the Purism guys might be using flatpaks for the Librem 5 phone, I decided to check it out. They could also be used in EasyOS, as there is a nice collection available online.

Flatpaks, like Ubuntu's snaps, are self-contained applications, with everything bundled to run in any Linux distro. They may also be configured to run in a sandbox, basically, a container. Flatpak uses a container mechanism called Bubblewrap.

I thought that it might be possible to use Easy Containers, as they are far more efficient to setup a container, compared with the way Flatpak/Bubblewrap does it.

It took many hours chasing dependencies, and I compiled it all, and finally got Flatpak to work. I won't document it here, yet, as need to sort out some details, where I was messing around.

I installed Krita, a KDE app, from this Flatpak repository:

...and it was a massive download, 359.7MB, actually, it might have been more than that, I went away for awhile, and it downloaded some more stuff.

Finally, ran it:

# flatpak run org.kde.krita

...surprise, it actually worked. However, I saved a file, at "/root", but I haven't got a clue where that "/root" is actually located. Somewhere in /var/lib/flatpak probably, but I couldn't find it. It was there somewhere, was able to open it.

Updates, apparently, are smaller, as it uses a delta difference system.

However, the initial download is too big. I don't think that this is suitable for a phone, as is.

Tags: easy

PureOS 8.0 Linux distribution

June 13, 2018 — BarryK

As I have ordered the Librem 5 phone dev-kit, which will have a PureOS-based distribution on it, I thought that probably the upcoming docs might assume a host development PC to be running their x86_64 PureOS, so I installed it. Downloaded from here:

Burnt it to a DVD, booted and the menu offered "Test or Install", which booted up running in RAM. Clicking top-left, some icons dropdown, and I chose "install", which runs the "PureOS Installer".

It is quite a nice installer. I was able to chose one partition that had nothing in it (sda5), and not to install a boot manager (as I already have ReFind, that I will edit manually). I took the precaution of unplugging one of the hard drives, my main work drive.

It installed OK, except changed some of the drive partition numbering, which was odd. Even odder, it changed the labels on all of the partitions -- unexpected and not nice!

Also, it changed the hardware clock to UTC, whereas I have it set to localtime. I hate it when an installer does that. It is saying, to hell with the other OSs, this is how it is going to be! There was nowhere after bootup to choose UTC or localtime for the hardware clock. Later, I booted Easy and changed the hardware clock back to localtime. Then rebooting PureOS, it was still correct time, as it was reading it from the Internet.

The file manager is the usual awful Gnome thing, so dumbed down.

One more thing: at first bootup it asked for a new password, and there was a checkbox to bootup without password -- except it doesn't work, requires a password.

Using PureOS was OK, just a matter of getting familiar with where everything is, but whenever I test a Linux distro, I always feel relieved when I get back to Easy/Quirky/Puppy.

Here is the PureOS website:

Back in mid-2016, I compared the Ubuntu and Debian installers:

Tags: linux

Librem 5, an open-source Linux phone

June 12, 2018 — BarryK

We all recall the failed attempt by Canonical to crowd-fund a phone that would run Ubuntu Touch. More recently, another group had a go, a company named Purism. Their crowd-funding proposal was for the Librem 5, a phone that would run PureOS, their security-focused flavour of Linux.

Purism aimed for at least US$1,500,000, but reached US$2,479,000, so a success, and the project was underway. Crowd-funding page here:

I was initially interested, but then it seemed that they were going to use the NXP i.mx6 CPU, which is 32-bit and very long-in-the-tooth. So, I lost interest, but it got piqued a few times, when there were some interesting announcements that came to my favourite Linux news site,

A couple of those news items were that UBPorts, the team who are continuing to develop Ubuntu Touch after Canonical dumped it, signaled their intention to port to the Librem 5 phone. Also, the developers of Plasma Mobile, another Linux-based phone OS, will be doing the same.

So, there will be a choice of three OSs, most interesting.

I found out just a couple of days ago, all the latest happenings, at their blog:

They delayed the project a bit and decided to go for the i.MX8M CPU, a somewhat more modern and power-efficient 64-bit chip. That got me interested again. However, this chip is not really designed for phones, and does not have a modem (to provide the 2G/3G/4G connectivity). The modem has to be a separate chip, and I looked up the specs on the modem chip that will be shipping with the developer-kit, and it lacks 4G 700MHz (B28), a frequency extensively used by Telstra here in Australia.

So, interest waned again. However, I then read something most interesting, that the modem will plug into an m.2 socket in the phone, so they will be able to provide the right one for different regions of the world. I don't know if it is quite that simple though, as the antennas have to be tuned.

I was also pleased that they decided to go for a bigger screen. Originally, it was going to be 5 inches, but they have now upped it to 5.5 or 5.7, with 18:9 ratio.

I don't know if this phone will ever become more than a toy for developer-nerds like myself, but I decided I'm in. I contacted them after the deadline had expired for ordering the dev-kit, but they reckoned that they could find one extra for me, and accepted my late order.

Note for anyone else who wants to get involved as a developer: you will have to wait until the phone arrives in January (or more likely later, based on my previous experience with crowd-funded projects). The dev-kit is just a one-off production-run, and it is intended that development can be on the phone itself after it arrives.

So, a i.MX8M-based board, costing US$399, which came to AU$527, due in August/September, I guess that I will have to pay GST when it arrives here. Specs are here:

Here is a recent render of what the phone will look like:


This is the layout of the dev-kit:


I am intrigued that the dev-kit is pretty much what will be in the final phone, and that everything is going to be open-source, with all hardware specs published, and lots of guys working on getting the hardware to play nice with Linux.
I wonder how many of those interfaces will end up in the phone ...notice the smartcard socket.

My plan, after the dev-kit arrives, is pretty wide-open at this stage. Lots of learning to do of course. 

Tags: tech