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 ?= " \
confirm layer is picked up:
# bitbake-layers show-layers
keep the downloaded src pkgs outside:
# ln -s ../../downloads downloads
change these lines:
MACHINE ??= "qemux86-64"
PACKAGE_CLASSES ?= "package_deb"
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:
In libreoffice.bb I took out these two lines:
In libreoffice-native.bb I took out:
To get rid of postgresql, edit libreoffice.bb
remove postgresql line from here, in libreoffice.bb:
PACKAGECONFIG ??= " \
insert this configure option:
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:
insert this configure option:
added dep to libreoffice.bb:
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!
No comments My play with OpenEmbedded/Yocto is continuing, with success. For a very long time, I have dreamed of compiling OpenOffice, then LibreOffice, from source. It has been a couple of years since I last tried, but the few times that I had a go, just never got there. Too big and complex, too many failures. This was attempted on various flavours of Puppy and Quirky.
Now, having another go at being able to build a Quirky (or pup) from packages that I have compiled entirely from source, rather than relying on the effort of some other distro, I thought the cherry on the cake would be if I could actually get it to compile LibreOffice.
This blog post is to report success. Well, almost. There was a little fudge that I had to do to get Libreoffice to compile, then the "do_install" function failed. However, it is all there, and I can create a binary package manually.
I am communicating with Andreas, the maintainer of the LibreOffice recipe in OpenEmbedded, so hopefully the "fudge" can get fixed. For now, it would be good to document how I got this far. Remember, I am an almost absolute beginner with OE/Yocto, so there is room for improvement. However, documenting my steps might help others. So, here we go...
The host system
The host operating system has to be setup to be OE-friendly. There are online instructions for the major OS's, but I am running Quirky Linux 8.1.6, x86_64. This is a full installation, not one of those frugal thingies that you can do with Puppy Linux.
Quirky, being built with Ubuntu 16.04 Xenial Xerus DEBs, is pretty close to OK, just needs some tweaks, as documented here:
Running Quirky 8.1.6 x86_64
'devx' PET must be installed.
Needs 'setterm' utility, this is in the 'util-linux' DEB, download and extract
this utility, to /usr/bin:
check (ok in quirky):
must have "messagebus" and "shutdown" groups in /etc/group
(had to add this to quirky):
must have "crontab" group.
bitbake requires python 3.4.0 or later.
have installed "python3" from the PPM.
this symlink is needed:
# ln -s python3.5 /usr/bin/python3
Previously, I had followed the getting-started page for Yocto, and checked out the "morty" release.
However, I ran into issues when trying to incorporate the "meta-office" layer (which has LibreOffice recipe).
So, I decided to do things at a bit differently. I downloaded from the OpenEmbedded git repository, like this:
create these folders, then cd into:
# cd /mnt/sda1/projects/oe/downloads-oe
# git clone git://git.openembedded.org/meta-openembedded meta-openembedded --depth 1
# git clone git://git.openembedded.org/openembedded-core openembedded-core --depth 1
# git clone git://github.com/schnitzeltony/meta-office.git meta-office --depth 1
# git clone git://git.openembedded.org/bitbake bitbake --depth 1
# cd ..
# mkdir oe-project
# cp -a downloads/openembedded-core/* oe-project/
# cp -a downloads/openembedded-core/.templateconf oe-project/
# cp -a -f --remove-destination downloads/meta-openembedded/* oe-project/
# cp -a downloads/meta-office oe-project/
# cp -a downloads/bitbake oe-project/
The "--depth 1" means that no history is being downloaded, so I am working with the very latest only, of master branch.
Folder "oe-project" is now ready for action!
There is just one little hack needed, before can get going. Quirky, like Puppy, we run as the root user. We could probably set this up for a non-root user, but leaving things as they are, a couple of lines need to be commented out:
edit meta/classes/sanity.bbclass, comment-out:
if 0 == os.getuid():
raise_sanity_error("Do not use Bitbake as root.", d)
Like this (keep the indentation):
# if 0 == os.getuid():
# raise_sanity_error("Do not use Bitbake as root.", d)
The only downside to doing this, at completion of the build a whole lot of warning messages will be spitted out on the terminal, containing the text "is owned by uid 0, which is the same as the user running bitbake". These are warnings only, not errors.
The next step is to setup the build environment. That will be the next blog post.
1 Comment Have completed all of the steps. Compiled from source in Yocto, imported the x86_64 binary packages into woofQ, and built a Quirky distribution. It works, there is a desktop.
So far, have only done a "core-image-sato-dev" build in Yocto, with target-native SDK components included, as described here:
It is configured to create binary DEB packages, however, I ran into multiple issues with importing them into woofQ.
Instead, I wrote a script named '0pre-yocto' in woofQ, that imports entire un-split binary packages, as .tar.xz files. It also creates the Puppy-format database.
As this is early days with Yocto, to get a reasonable desktop I used many packages from April, for example Gnumeric and Dia. These work fine in the Yocto build.
Installed to a USB stick, booted, got a desktop. Although a "devx" PET has been created, have not yet tested whether there is a sane compiling environment.
'core-image-sato-dev' has some packages that I would rather do without, 'pulseaudio' for example. Next on the to-do list is to have a go at removing pulseaudio, see if it will still compile.
No comments After learning that it is possible to create target-native compiling tools, such as gcc, my interest in OE/Yocto got revitalised. See previous blog post:
I have just completed a build with Yocto, and it creates binary DEB packages for the target machine, and yes, that includes 'gcc', 'automake', 'autoconf', 'make', etc. Looks good.
Haven't actually installed it into a partition and tested if can actually compile anything, but intrigued enough to want to learn more about Yocto. It is a very big and complicated project, and the online docs are daunting. So, I have ordered a couple of books:
Embedded Linux Systems with the Yocto Project
Embedded Linux Development with Yocto Project
There are ebooks, but I like to have the paper! Costs a bit more -- total was just on AU$100, about US$75, including shipping to Australia.
Amazon's international shipping is odd. I say this from past experience. This order, that second book came up as does not ship to Australia, so clicked on the "22 New" link, and found that Amazon ships it to Australia, just costs a little more.
Had to go through this rigmarole even though I was logged in and had ticked the checkbox to only show items that can ship to Australia.
Anyway, looking forward to getting them!
No comments Native compiling
My misunderstanding of the word "native" in the OpenEmbedded documentation, has been bothering me.
I posted about my latest go at using OE here:
I thought a "native toolchain" would be one that runs in the target machine. But not so. As clarified here:
..."native" refers to the host system.
However, this site is using "native" to refer to Yocto compiling in the target machine:
...so, it can be done!
Slackware from Scratch
Changing the subject, I was wondering how Slackware is built from scratch. Well, it seems that it isn't, or rather, it is a cobbled-together approach. Apparently, they have used LFS to get going, then their build scripts to build packages.
There is no automated equivalent to LFS, however, some guys have been developing Slackware from Scratch, with automated build scripts, see this thread:
Pages:      ...