site  contact  subhomenews

meta-qt5 layer now in oe-qky-src

July 15, 2018 — BarryK

A little over a week ago, I added the meta-qt5 layer to oe-qky-src, my fork of OpenEmbedded. However, it broke the build of some packages.

So, I went on a journey, exploring how to compile Qt5 without the meta-qt5 layer, from basic principles. A very intense several days, ended with frustration. Well, lots of frustration during those several days!

I did get it to build, using autotools only, but only for x86_64 host and x86_64 target. Kept getting errors when attempted cross-compile for aarch64 target.

Yesterday, gave up, and went back to the meta-qt5 layer, this time hunted down why it's introduction caused some other packages to fail.

Got it sorted, qt5 5.10.1 now builds, but have not yet ported any qt5-based apps into oe-qky-src. Did attempt Scribus, but got a compile error. For now, will build Scribus in the final running system.

This morning, tried to use Smartgit to commit the latest changes. Did something wrong... it seems, when committed a couple of files and a directory together, Smartgit got confused. Smartgit seems to be thinking that the 'meta-qt5' folder is a file!

Git is very powerful, but when something goes wrong, you can really get your knickers in a twist.

To get it uploaded, here it is as a tarball:

Expand somewhere, it will expand to folder 'oe-qky-src', and there is a readme inside.

Right, now to fix Smartgit...

OK, fixed. The problem was, folder meta-qt5 had a .git folder in it, which confused Smartgit. See commits for July 15, 2018:

EDIT 20180717:
I built EasyOS in woofQ from binary packages imported from oe-qky-src, then attempted to compile Scribus. Lots of configure errors. I found that .cmake files in /usr/lib/cmake are somewhat broken. They are setup to work inside OE. I have fixed them, the fixes are in the template files in woofQ, woof-code/packages-templates/qtbase, qttools, etc.

Interesting observation: cmake seems a lot more troublesome in a cross-compiling environment than autotools-based projects. This is an interesting observation due to the praise for cmake that I read everywhere, and some projects, such as Scribus going over to it.

Tags: oe

coreutils cp utility broken compiled with musl

July 02, 2018 — BarryK

In the latest build of EasyOS I am getting file copy errors when using 'cp'. This build is using a statically compiled coreutils single-binary (with applets symlinked to it, just like busybox), that was compiled in OE.

Here is an example:

# coreutils --coreutils-prog=cp -a -f /mnt/sdb1/projects/woof/woof-project/builds/quirky-out_amd64_amd64_oe_pyro_easy/sandbox3/rootfs-complete/var varX
coreutils: failed to preserve ownership for varX/local/pupdial/isp: Not supported

"isp" is a symlink to a folder, target with permissions '777'. That is what causes the error message, though the copy does succeed.

Alright, trying busybox cp:

# rm -rf varX
# busybox cp -a -f /mnt/sdb1/projects/woof/woof-project/builds/quirky-out_amd64_amd64_oe_pyro_easy/sandbox3/rootfs-complete/var varX

...good, no error message.

OK, compiling coreutils with uClibc. I used a very old uClibc, refer to, and bumped coreutils to 8.30. Have a static single binary, test it:

# rm -rf varX
# coreutils --coreutils-prog=cp -a -f /mnt/sdb1/projects/woof/woof-project/builds/quirky-out_amd64_amd64_oe_pyro_easy/sandbox3/rootfs-complete/var varX


Grumble, grumble, this reinforces my dislike of musl. I did a search on the Internet, this bug has been reported over several years.

Tags: easy, oe

Busybox 1.28.4 compiled statically

June 29, 2018 — BarryK

I have created a new recipe "busybox-static" in my fork of OpenEmbedded (June 28, 2018):

Busybox is compiled statically for amd64 and aarch64, and I have created PETs.

The amd64 PET will be used in future builds of EasyOS and Quirky, and there is a aarch64 build planned sometime, after I get my hands on the Librem 5 phone dev kit.

Which I am hanging out for...

The Purism website has the occasional blog post to keep us updated. This latest is interesting:

...but, where does the trust start and end? We have always trusted the major hardware manufacturers such as Intel -- after all, their chips are just big "binary blobs" -- the hardware inside a chip could be doing anything, we have no way of knowing.

What is different about firmware blobs? Nothing really. But I suppose, if firmware blobs can be removed, it is reducing the attack-surface.

Tags: oe

Packages recompiled in oe-qky-src

June 23, 2018 — BarryK

Finalised, for now, the backporting of packages from the Sumo release of OpenEmbedded, in my fork 'oe-qky-src', see commits (June 23, 2018):

Did a build overnight, and have now imported the binary packages, all 724 of them, into woofQ, for future builds of EasyOS and Quirky. The packages will be available in the "oe-pyro" repository in the PPM (Package Manager), and so are uploaded.

Here they are:

Now, I am keen to get back to EasyPak, an exciting new idea for "universal packages"...

Tags: oe, easy, quirky

Backporting Sumo to Pyro-based OE-port

June 22, 2018 — BarryK

I forked OpenEmbedded in June 2017, when the Pyro version was released. My fork, named oe-qky-src, is on GitHub, and is very different from the mainline OE project, so I can't easily sync with it.

The latest release of OE is Sumo, and I am working around the sync problem by gradually backporting Sumo recipes. To that end, I created a "sumo" layer, and have made some commits (June 22, 2018):

In particular, meta/recipes-graphics and meta-oe/recipes-graphics have been backported, which includes Xorg and mesa.

Tags: oe

rox-filer, shared-mime-info tweaks

June 09, 2018 — BarryK

In ROX-Filer file manager, when you click on the little "home" icon at top of window, it will open a window at the user's home directory. In the case of Puppy that is /root, however with Quirky I want to open at /file, and for Easy at /mnt/wkg/home.

I have modified the rox-filer source so that it detects if running in Quirky or Easy, or if not then opens at ~ (/root for Puppy).

Some of my shell scripts have a shebang line "#!/bin/ash" and ROX-Filer does not recognise this as an executable. The reason for this is the shared-mime-info package, which recognises such a file as plain-text only.

I have patched shared-mime-info to recognise "ash" and "dash" scripts as shell executables.

These fixes are to be found in my online "oe-qky-src" fork of OpenEmbedded ( June 8 and 9):

Note, I deliberately use an old version of shared-mime-info, 0.90, as I found that recent versions have stuffed up recognition of text files. Many text files in woofQ and Easy/Quirky/Puppy are mis-identified, which results in Geany and other text editors refusing to open them, and in the case of ROX-Filer not offering to open in a text-editor in the right-click "Open With..." menu.

Tags: oe

First OE aarch64 build, updates

April 17, 2018 — BarryK

I have done a first build for aarch64 (64-bit arm) on my fork of OpenEmbedded. project page:

Modifications for first aarch64 build:

Some packages failed, so I need to fix them. However, most of the big apps, such as Firefox and LibreOffice, compiled.

Have also started to update some packages:

jwm 1679:

bacon 3.7.2:

pup-tools 20180417:


Plowing ahead, fixing packages for aarch64, and updating some, adding some new packages.

Won't itemise here, look at the repo.

Tags: oe