Chasing bugs in Pyro64

As I posted to the Puppy Forum this morning, Kodi now has text, and is working. Forum thread:
http://murga-linux.com/puppy/viewtopic.php?t=110453

The problem that I am now working on, is both Firefox and SeaMonkey are very unstable. From past experience, there are various system libraries that are the cause of this, such as icu, cairo, pango, glib/gio.

I experimented with different configure options, eventually configured with almost everything internal, except, I think system libvpx. Beautiful, completely stable.

Then I introduced system hunspell and icu ...crashes again.

Most likely it is icu, so now I am doing a compile with all the other system libs reintroduced, except using internal icu. Hopefully that will be stable.

If it turns out to definitely be icu, I might do a complete rebuild in OE, using the same version of icu as used in seamonkey (56.1) with the same patches (OE has 58.x).

Read more...

OE/Yocto Pyro released

There was a post on one of the Yocto mail lists, that Pyro, version 2.3, is released:
https://lists.yoctoproject.org/pipermail/yocto-announce/2017-May/000112.html

I have cloned it, and merged my customization layer, and started the build. This is a big build, with "the works", including Firefox, Gimp, Pidgin, Libreoffice, Kodi.

However, I have not solved the problem of no text in Kodi, so I will build Quirky with Xine. Also, Quirky will have SeaMonkey, rather than Firefox.

The plan is that once I am satisfied everything is reasonably sane, I will upload a tarball "oe-qky-src", which is OE with my customizations, so it is ready-to-go for anyone who is interested.

Also, intend to release a Quirky build. It will still have some issues, so might have to be classed as pre-alpha or alpha.

Read more...

Forum thread to discuss OE and Pyro

I have started a thread on the Puppy forum to discuss OpenEmbedded and compiling for Puppy/Quirky:
http://murga-linux.com/puppy/viewtopic.php?t=110453

I mentioned in the first post of that thread, that OE could replace Woof*. A clarification: yes theoretically, but it will require in-depth knowledge of OE and be a lot of work.
It is quite likely something that will never happen.

The compiling environment of Quirky Pyro64 0.1.1, my second build, is sane, and right now I am compiling SeaMonkey 2.48b1. That is, a native compile in a running Pyro64, not using OE.

Tags: oe

First build of Pyro64

Quirky built from packages compiled in OpenEmbedded, is codenamed "Pyro64". I have just done the very first build, version 0.1, and get a desktop -- and some bugs, which is to be expected.

The file is 297MB, and it has big apps, including LibreOffice, Kodi, Gimp, Pidgin and Firefox.

Most of the bugs look fixable, but Kodi displays without any text, and after a brief google, no solution has jumped out at me.
It is a common problem, but there does not seem to be any definitive fix.

Fixing Kodi is number one on the to-do list.

What I might do is install the devx pet, and have a go at compiling the latest version.

Tags: oe

Classic OE recipes

I have struck gold!

I want to add more packages to my "core-image-quirky" build in OpenEmbedded. For example, JWM, ROX-Filer, Minimum-Profit and Dia.

Today I discovered a treasure trove of old recipes:
http://cgit.openembedded.org/openembedded/

I downloaded the whole lot:
# git clone git://cgit.openembedded.org/openembedded oe-classic --depth 1

There is a recipe in there named "mped", which is the Minimum Profit text editor (executable name is "mp").
Yes, it is old and broken. A great starting point, and I fixed it.

In OE, I have a new layer, named "meta-quirky", and new recipes such as "mped" go in here, as well as fixes for existing recipes and other configuration.

Read more...

Big build in OE underway

The last couple of days, I have been fixing the build of some packages in OpenEmbedded. In particular, I have had to modify the build "recipes" to fit my requirements for dependencies.

Packages that are not in my build include these:
avahi, gtk+3, libpam, pulseaudio, systemd

My core-image-quirky recipe now builds a large collection of packages, including very big ones such as libreoffice, kodi and firefox.

I have just started the build from scratch, the cache deleted so that it is truly a build from scratch, and we shall see how long it takes...

Next, I plan to import the packages into woofQ and build a Quirky. I will put the big apps in, including libreoffice, kodi and firefox, as I am very interested to find out how big the resultant distro will be.

Not every binary package that you find in a typical Quirky or Puppy, is compiled in OE, but that is no problem, will use packages from elsewhere, such as April. Eventually, hope to compile everything in OE.

Tags: oe

New Quirky layer in OpenEmbedded

Having lots of fun. Recently posted about getting started with Yocto/OpenEmbedded:
http://bkhome.org/news/201704/part-2-libreoffice-compiled-in-oe.html

The Yocto books from Amazon arrived a few days ago, and I have had my nose down. Complicated, but making progress.

I decided to use OpenEmbedded from git as the basis for building packages for Quirky, not Yocto.

I have created a new layer, named 'meta-quirky', and so far it builds a basic X11 system with development tools.

Kernel also. I have just now looked at how to substitute my own '.config' file, will give that a go.

I will add more packages later. But very carefully, as want to build a very lean-and-mean distro.

Currently, just compiling packages, which are then imported into woofQ. However, in theory, OE could do the whole thing, build an image file ready to be written to a flash stick.
Down the track, might aim to achieve this, if I can master OE sufficiently.

Then, I could provide a single tarball, that someone can download, then run just a couple of commands and it builds the entire Quirky (or Puppy) image file. All it would need is a compatible host system, such as Quirky 8.1.6 or one of the ubuntu-pups or debian-pups (with some small fixes and extra pkgs installed).

The biggest problem right now is how long a build takes. Even a minimal build takes 12 hours, a big one (LibreOffice etc.) more like 24 hours.
That's because it is running one core only on my laptop.
Maybe I should invest in a fast PC/laptop, maybe i5 or i7 CPU, 8GB RAM, 256GB SSD ....don't want to spend the money right now though...

Tags: oe

Part 2, LibreOffice compiled in OE

I am documenting how I compiled LibreOffice in OpenEmbedded. Part 1 is the previous blog post:
http://bkhome.org/news/201704/libreoffice-compiled-in-oe.html

One thing about that previous post. I changed the number of parallel processes to one. That is because I have an overheating problem with my laptop, but you might want leave those out, and it will default to using all CPU cores.

Setup OE environment
As explained in the previous post, folder "oe-project" has been created. There needs to be a bit of preliminary work before the actual build can take place...

# cd oe-project

# source ./oe-init-build-env buildQ



...working dir is now in buildQ



buildQ/conf/bblayers.conf, add the layers that we want:

BBLAYERS ?= " 
  /mnt/sda1/projects/oe/oe-project/meta 
  /mnt/sda1/projects/oe/oe-project/meta-oe 
  /mnt/sda1/projects/oe/oe-project/meta-python 
  /mnt/sda1/projects/oe/oe-project/meta-office 
  "



confirm layer is picked up:

# bitbake-layers show-layers



keep the downloaded src pkgs outside:

# ln -s ../../downloads downloads



edit buildQ/conf/local.conf:

----------------------------

change these lines:

MACHINE ??= "qemux86-64"

PACKAGE_CLASSES ?= "package_deb"



append:

BB_NUMBER_THREADS = "1"

PARALLEL_MAKE = "-j 1"

BB_NUMBER_PARSE_THREADS = "1"



# in yocto, got an error when building initramfs, default maxsize is too small.

# INITRAMFS_MAXSIZE is set in meta/conf/bitbake.conf (= 131072 kb, 128MB).

# override here, 160MB:

INITRAMFS_MAXSIZE = "163840"



# yocto/poky/meta/conf/bitbake.conf has this line:

# DISTRO_FEATURES_BACKFILL = "pulseaudio sysvinit bluez5 gobject-introspection-data"

# ...this could be edited, or insert this into build/conf/local.conf:

#DISTRO_FEATURES_BACKFILL_CONSIDERED = "pulseaudio"



# want to add libreoffice. have already installed meta-office layer

DISTRO_FEATURES_append = " opengl"

IMAGE_INSTALL_append = " libreoffice"

<

I personally would prefer not to have 'pulseaudio'. Unfortunately, it is required to be there in some recipes in OE. Then there is the problem of the latest Firefox requiring it.
So, I have left 'pulseaudio' in the build for now.

Fix LibreOffice recipes
I am posting fixes to the recipes here, after failures occurred, so hopefully if someone follows my instructions, the build will just sail through.

The Libreoffice recipes specify two dependencies, 'clucene' and 'postgresql', however, these packages failed to build. So, I removed them from the LibreOffice recipes.

These are the two recipe files:

/mnt/sda1/projects/oe/oe-project/meta-office/recipes-libreoffice/libreoffice/libreoffice.bb,

libreoffice-native.bb



In libreoffice.bb I took out these two lines:

    clucene-core 
    --with-system-clucene 


In libreoffice-native.bb I took out:

    clucene-core-native 
    --with-system-clucene 


To get rid of postgresql, edit libreoffice.bb

remove postgresql line from here, in libreoffice.bb:

PACKAGECONFIG ??= " 
    gtk 
    mariadb 
    postgresql 
"

insert this configure option:

    --disable-postgresql-sdbc 
and comment-out this line:

PACKAGECONFIG[postgresql] = "--enable-postgresql-sdbc --with-system-postgresql, --disable-postgresql-sdbc, postgresql"

<

Not there yet. Unpacking of libreoffice-native failed, reported that 'unzip' does not exist. Then, configuring, failed, reported something about 'neon' package not being in the repository.
To fix both of these:

have added these deps to libreoffice-native.bb:

    unzip-native 
    neon-native 
insert this configure option:

    --with-system-neon 


added dep to libreoffice.bb:

    unzip 

<

Start the build
Having already run that "source ./oe-init-build-env buildQ" command, "pwd" will show that you are now in the "buildQ" folder, and everything is setup ready to build. Do this:

# bitbake core-image-sato-sdk

If you get a failure somewhere, it may not be a show-stopper, and you can keep going with:

# bitbake --continue core-image-sato-sdk

Be prepared to wait a very long time!

Read more...