site  contact  subhomenews

Celluloid compile fail mystery in OE

September 29, 2020 — BarryK

"Celluloid" is the new name for Gnome-MPV, the media player, frontend GUI for MPV, the latter being a CLI media player (with a primitive pseudo-GUI). Project home page:

I have a "meta-quirky" layer for the Dunfell release of OpenEmbedded, see two previous posts in the saga:

All 755 packages compile, except for one, Celluloid. Or rather, it sometimes succeeds, sometimes not. Early this morning, 1.24am,  I started a complete recompile, then went to bed. I had wanted to time the build, but when I got up at 7.30am, I discovered that the build had stopped on an error -- oh no, Celluloid again.

On previous occasions, I had repeated the build of Celluloid, and maybe after a couple of attempts, it would succeed. Like this:

# bitbake -c cleansstate celluloid
# bitbake -c build celluloid

I am getting different error messages each time. This time, it reported a missing termination of a comment, and I discovered that the source file is truncated. Huh!?

How can that even happen?

Here is the recipe, and I have made a comment about the failure, and put in a possible fix:

# Recipe created by recipetool
# recipetool create -o

LIC_FILES_CHKSUM = "file://COPYING;md5=8006d9c814277c1bfc4ca22af94b59ee"

SRC_URI = "${PV}.tar.gz"
SRC_URI[md5sum] = "3fde6852840798ad61b3e39f1513f8d4"
SRC_URI[sha1sum] = "17c7bcc5f34f003140cad407b6a3ecd4d87ce769"
SRC_URI[sha256sum] = "3ce6158097d94786a62de5f26ab2cb71301e9fd0841ede8381e1535489cf0de8"
SRC_URI[sha384sum] = "1f0eafd8b6542178abee06ce68c978ac3a6a9ebd2b479e85136e8db77e2614a4e70aca622ae4a44a4ff383762ec508a2"
SRC_URI[sha512sum] = "acb76bd216100afbe3b083919e122308def1431845955dd418e7b2d57f37fb1353209d1f77f41790d3e01603ee1137fe2c5a57c7bb0ca9b0b13388278cc291f1"

DEPENDS = "libepoxy mpv gtk+3 glib-2.0 appstream-glib glib-2.0-native"

inherit gettext pkgconfig autotools-brokensep


# 20200929 why does build sometimes fail?
# today, error "unterminated comment" line 680 in src/mpris/celluloid-mpris-gdbus.c
# and i see 680 is end of the file -- however, file is supposed to have 8355 lines!
# try this:

SUMMARY = "GUI frontend for MPV media player"

Tried again, this time success. Now the build of all packages is continuing.

All 755 packages compile successfully, consistently, except for Celluloid. Why just Celluloid? The source package looks like a pretty ordinary autotools-based setup, can't see anything odd in the makefiles.

I put in that PARALLEL_MAKE = "j 1", but I don't see how that would have anything to do with a source file getting truncated. Is it something to do with ext4? A kernel problem?

Bitbake, the program that runs the OE build, uses all available cores, in my case 4, and will be building 4 packages at once, swapping between them continuously. Actually, it will be building many more than 4, but only 4 at the same time, rotating through them, like a 4-package moving window. 

Tags: oe

OpenEmbedded/Yocto Dunfell meta-quirky first release

September 27, 2020 — BarryK

A few years ago, I created "oe-qky-src", a port of OpenEmbedded cross-compiler build system, with recipes to build nearly all the packages required for woofQ -- the latter is the build system for Quirky Linux or EasyOS. WoofQ is a derivative of Woof2, as is woof-CE that is used to build the latest official releases of Puppy Linux.

"oe-qky-src" is in a git repository:

...that has my "meta-quirky" layer for OE. It is based on the "Pyro" release of OE/Yocto.

"oe-qky-src" is getting a bit "long in the tooth", so I decided to do a complete update, based on the latest release of OE/Yocto, named "Dunfell".

A couple of weeks of very intense work later, and we now have the first release. I have decided not to put this onto a git repository, instead it is just a tarball:

Download it, expand it, and type in a few commands, and several hours later you have compiled 755 packages! Detailed instructions here:

...the readme is also inside the tarball.

One point: it does include 'pulseaudio'. With "oe-qky-src" there was only 'alsa', but this time I decided to include 'pulseaudio', despite reservations, as it is very difficult to implement bluetooth audio without 'pulseaudio'. I will build EasyOS from these packages and see how it goes.

If I change my mind, it is easy to remove 'pulseaudio' and recompile everything.

Those compiled packages can be imported into any woof* derivative. However, the '0pre-oe' and '0pre-oe-add' scripts are required to perform the import, and they are currently only in woofQ -- furthermore, I fixed some bugs in those scripts yesterday, and have not yet uploaded the latest woofQ tarball. Intend to do so soon.

I think, in theory, if you are a Puppy Linux developer using woof-CE, you should be able to use those scripts, but there are some differences from woofQ, so you would need to look through the scripts and make sure they are woof-CE-compatible.

Oh, another thing, Woof* has a directory 'packages-templates' and the one in woofQ has diverged somewhat from that in woof-CE. This might affect the functioning of some packages when a Puppy build is done, that is when run the '2createpackages' script.

Here is the package list:

Anyway, lots of fun. Certainly a very niche audience, as although 755 packages seems like a lot, it is tiny compared with the package repositories of the major distributions such as Debian -- note though, that 755 is "whole" packages, not split-up ones -- Debian will typically split an original package into 2 - 4 DEBs, so that 755 would become >1500 packages! 

Tags: oe

More patches for an old package in OE

September 22, 2020 — BarryK

I am continuing to compile old packages, that are still good, and included in releases of EasyOS. Some notes have been appended to the previous blog post:

The package 'xlockmore' is an example of very "long in the tooth". It compiled OK in the Pyro-OE, but not in Thud-OE. Nor in the latest OE, Dunfell-OE. There have been patches in the past to get it to compile. This time, the error message is that "DOMAIN" is undefined.

It turns out that the problem is with glibc 2.27+, as explained here:

...jamborm has done what he calls a "horrible hack". Yes, but it works. I appended his code onto the end of any include file, xlock/xlock.h, in the recipe for xlockmore, like this:

    echo '

#ifndef DOMAIN
struct exception {
int type; /* Exception type */
char *name; /* Name of function causing exception */
double arg1; /* 1st argument to function */
double arg2; /* 2nd argument to function */
double retval; /* Function return value */

#define DOMAIN 1
#define SING 2
#define OVERFLOW 3
#define UNDERFLOW 4
#define TLOSS 5
#define PLOSS 6

#endif /* LIBM_ERRNO_AMD_H_INCLUDED */' >> xlock.h

Yay, xlockmore is still alive!

Actually, there is a later version of xlockmore that what I am using. I have 5.31, latest is 5.65. I continue to use the old one as it has many hacks to make it very small. Ideally, I should apply those "smallness" hacks to the latest version. Here is the xlockmore project page:   

Tags: oe

Porting OpenEmbedded Thud release

March 21, 2019 — BarryK

The packages used in EasyOS 0.9.x - 1.0.x were compiled by "oe-qky-src", which is a port of the "Pyro" release of Yocto/OpenEmbedded:

The Yocto/OpenEmbedded release schedule is here:

...Pyro was released in May 2017, and EasyOS is showing its age a bit. Nothing really wrong with the older glibc, gcc, etc., but EasyOS is probably due for a freshen-up with later packages.

I did do a partial upgrade of the Xorg and some multimedia packages, from the "Sumo" release awhile back.

Anyway, now having a go at a complete upgrade, to the latest stable release, codenamed "Thud", version 2.6.1.

Intention is, there will be a new repository, probably at, named "oe-easy-src".

It is doing a compile right now, with the Thud package recipes as-is, just to see if it will compile. If that succeeds, I will port some recipe modifications that were applied in oe-qky-src, and about a hundred extra packages that are not in Yocto/OpenEmbedded -- for which I created recipes. 

Tags: oe

gtk1 and gdk-pixbuf0 compiled in OE

December 13, 2018 — BarryK

glib1 (glib version 1.2.10) got compiled in OpenEmbedded yesterday:

Have now succeeded with gtk+ 1.2.10 and gdk-pixbuf 0.22.0, see the oe-qky-src repository:

In the next release of Easy, will be able to run gtk+ 1.x applications, if desired. I have in mind one that I want to play with... 

Tags: oe

glib 1.2.10 compiled in OpenEmbedded

December 12, 2018 — BarryK

Compiled in 'oe-qky-src' that is, my fork of OpenEmbedded. I have an aim to be able to compile and run gtk+ 1.2.10 applications in EasyOS. For that, it is necessary to compile glib 1.2.10, gtk+ 1.2.10 and gdk-pixbuf 0.22.0.

These are ancient packages, released back around 2001 - 2002. Not surprisingly, there are some issues when compiling them now. I found some patches, from Arch Linux and the T2-project, and was able to compile in a x86_64 host system. Cross-compiling in OE, though, is a challenge.

So far have only done glib. There are some very old patches for compiling glib 1.2.10 in the archived "classical" OE, which were helpful.

It was a struggle, took several hours today, but finally worked:

Fixing the old autotools, etc., was achieved by hacks. 'ltconfig' insisted that it could not create shared libs, was able to override.

Next up, gtk+ 1.2.10 ... 

Tags: oe

Ghostscript compiled with libgs in OE

December 02, 2018 — BarryK

The official OpenEmbedded/Yocto project compiles the ghostscript package with a big monolithic 'gs' binary. However, there are some packages that want 'libgs' as a dependency. So, the recipe in OE needs to be modified to generate a small 'gs' with shared 'libgs'.

Fortunately, Andrew has figured out the required changes to the recipe:

I used that as a basis, and my recipe is here:

And a modification to fix compile fail:

There was a package that I wanted to compile recently, that had libgs as a dependency, which prompted this revisit to OE. 

Tags: oe