site  contact  subhomenews

Evince imported to OE

June 10, 2017 — BarryK
Evince is a nice PDF viewer. OpenEmbedded does have it, however, it is for gtk3, whereas my build is gtk2 only.

So, I imported the last version of Evince that supports gtk2, 2.32.0, with patches that "bring it up to date". This is the same Evince that I have been using in Quirky for awhile.

Source and patches are here:

I timed myself this time, it took one hour and five minutes to import Evince. Some of them take longer. I am only doing a few per day, so it is going to take awhile.

It is good that I am still able to build a complete distro with gtk2-based apps. Major projects such as seamonkey and libreoffice continue to support gtk2. There are a few "lesser projects" that have abandoned gtk2, such as evince and osmo, however, I am happy with older versions with patches applied.

I think that they made a mistake abandoning support for gtk2!
Mostly because it is a stable API, though I suspect sometimes developers do a bit more to it than they should -- it should just be maintenance patches. Compatible theming between gtk2 and qt is another big factor for me.

There is some interesting reading on this topic, gtk2 versus gtk3:
And about Audacious returning to gtk2:


xdg-puppy imported to OE

June 09, 2017 — BarryK
Took a few hours, have imported 'xdg-puppy' into OpenEmbedded. It also required 'gnome-menus'.

I imported xdg-puppy into T2 a couple of years ago:

OE is a more difficult situation than T2, the makefiles do not work, had to setup $CC, $CFLAGS and $LDFLAGS especially.

xdg-puppy source latest now version 0.7.8:

Still using an old version of gnome-menus, as later versions were found to not follow the XDG specification for inline menus. Version 2.14.3:

A OE tarball with latest customization layer is expected to be uploaded soon.


BaCon imported to OE

June 07, 2017 — BarryK
There are about a dozen source packages that I have not yet imported into OpenEmbedded, 'bacon' is one of them.

BaCon, a BASIC compiler, is needed as there are some utilities in Puppy and Quirky that are written in BaCon. The 'pup-tools' source package has these utilities.

It was a bit tricky to import BaCon, but got there, for a x86_64 target anyway. Reported on this to the BaCon forum, with the recipe for OE:

Next up, import 'pup-tools'.


OE Pi2 desktop works

June 05, 2017 — BarryK
A quick progress report. The build in OpenEmbedded for the Raspberry Pi2 went well and I imported the binary packages into woofQ and created an SD-card image.

Got a desktop, however needs a lot more work.

Some old PETs used in the build, do not work. "ldd" reports that they are "not executable". This is a problem I have had before, do not understand why. With x86, old binary executables can be used, usually without any problem as long as shared library APIs haven't changed.
However, not so with ARM, even though they are all compiled for armv7.

This problem means that I will have to recompile a lot of packages. That is, packages that have not yet been imported into OE.

Tags: oe

Success building for Pi on OE

May 31, 2017 — BarryK
I am very impressed! Having used T2 for many years, where I would struggle for days trying to get packages to compile, this just sailed through.
Furthermore, it is a cross-build, which I have never been very successful with.

My complete package selection compiled, including kernel, kodi, firefox, gimp and libreoffice.
I had to take out nasm, yasm and xresprobe, as they are x86 only.

I am just now doing a rebuild from scratch, as there was one anomaly along the way, configuring mesa to be appropriate for the Pi. Although bitbake (the kind of "make on steroids" in OE) is very intelligent, I decided to do a complete clean rebuild.
That will take just over 9 hours.

Then the plan is to import the binary packages into woofQ and create a SD-image for the Pi2 (and Pi3).

I want to acknowledge the guys on the OE project who do all the hard work. It is a testimony to them, that I can come along with my package selection and have it all build, hardly without any issues, for x86_64 and Pi.

Tags: oe

Building for Pi2 on OpenEmbedded

May 30, 2017 — BarryK
Have just completed an x86 i586 build in OpenEmbedded, and imported the binary packages into woofQ. However, have put that one on the back-burner for now.

Have downloaded the layer for the Raspberry Pi:

Also for the Hardkernel Odroid boards:

I know very little about how these Board Support Package (BSP) layers work. So, starting off slowly. Right now, doing a small build for the Pi2, just a basic CLI interface.

What I have done so far, with Quirky and Easy, is just extract the binary packages out of OE, to woofQ. However, I want to learn how the whole thing, right to an SD-card image, is created in OE.


Pyro for i586 coming

May 30, 2017 — BarryK
I have released alpha builds of "Pyro64", Quirky Linux and Easy Linux built from binary packages compiled in OpenEmbedded.
This is for PCs with a x86_64 CPU.

OpenEmbedded is a cross-compiler, so in theory I can just change the specification for the target architecture, and off it will go, compile all the packages for that architecture.

So, I have given it a first test. I am running Quirky 8.1.6, a x86_64 distro. I configured OpenEmbedded to compile for a target i586 CPU.

I started the build last night. However, about 1am before going to bed, in my sleepiness I accidentally turned off the power to the PC. Grumble, had to clear the caches and start if off again.
Now 10am, it is almost finished, just compiling LibreOffice.

LibreOffice, incidentally, takes longer to compile than all of the other packages put together. It ends up, there is just one task running, LibreOffice compiling, and it seems to be using only one CPU core at that stage.

I am planning to support "old" computers again, with this i586 build. However, had to make a decision with the kernel. I configured the kernel for i586 and a RAM size limit of 4GB. That is fine, but also chose to support SMP (multi-core) CPUs.

It is that latter one that I was uncertain about. There are, I think, a lot of PCs with x86 32-bit multi-core CPUs, mostly two cores I think.
The SMP-enabled Linux kernel will run on uniprocessor CPUs, however, I do recall that it failed with some uniprocessor CPUs. I don't recall any more details.

So, I guess it is a tradeoff. It is nice to use the two (or more) cores if they are available. If I had chosen to configure the kernel to be uniprocessor only, it will run on multi-core CPUs but only use one core.

If you have any thoughts on my decision, you are welcome to post here:

Changing the subject, I am getting to like LibreOffice so much, can't consider doing a build without it. Awhile back, I had to fill in a form that was a MS .docx file -- LibreOffice handled that beautifully (whereas Abiword is useless).
I constructed some nice diagrams in LibreOffice, for the "How Easy works" page.

Yesterday, I was unable to insert colour-highlighted shell code into my "How easy works" page using SeaMonkey Composer (it insisted on removing all of the formatting). So I used LibreOffice, and discovered that it is a very nice WYSIWYG HTML editor.

LibreOffice compiled in OE is version 5.0.x, a bit old. I found that it embedded png images into the html page, was unable to keep the links to external images. I fixed that later, however, found support for external links is in Libreoffice 5.2.0.

So, the plan is to compile the latest LibreOffice soon.


wget, aaaargh!

May 21, 2017 — BarryK
I was fixing a couple of bugs in the package manager, PPM.

I compiled 'vim' in OE, and added it to the online package repository in Then I used the PPM to download and install it, to test all that is working ...which it isn't.

For a start, the "Update database" button was broken. Fixed that.

Then chose 'vim', but it failed to download.

I discovered the reason. The latest release of wget, 1.19.1, no longer logs to stderr, instead to ~/wget-log*

A quick google, this chap has hit the same problem:

I have at least two scripts, probably more, that are now broken. For example "wget .... 2>&1 | .... " or "wget .... 2> logfile" no longer work.

In the latter case, you have to use the "-o" to direct output to a particular logfile. I don't know what to do in the first case, where want to pipe it.

wget has been around since the beginning of time, why make such a fundamental change now? I sent a very polite email to the wget-bugs mail list, asking why.

In the OE build, I have rolled back to wget 1.17.1. This is the same version used in Ubuntu 16.04. In OE, it was easy-peasy to rollabck, I just grabbed the recipe from the "krogoth" release.

In OE:
# bitbake -c clean wget
...then put in the new recipe, in my 'meta-quirky' layer, then...
# bitbake wget

Then, over in woofQ:
# ./0pre-oe-add

...which detects the changed versions in OE, and deletes the old one, imports the 1.17.1 binary tarball.

Oh yeah, vim. It started out early this morning, I compiled vim in OE and imported it to woofQ. Then got distracted by this wget stuff. Now it is 11am.
I want vim as it can convert syntax-highlighted code to HTML output, great for putting code into web pages.

if you want vim for the new Quirky Pyro64, it is here (6MB):

If you download and click on it in Pyro64, Xarchive will open. The mime handler does not (yet) recognise *.tar.xz as possible being a package to install.
Instead, open a terminal where you downloaded it, and run:
# petget `pwd`/vim-8.0.0427-r0-core2-64.tar.xz

Tags: oe