Qsync fixed on the Pi4 and FF compiled
The Raspberry Pi4 does not have a hardware battery-backed clock,
so relies on getting the date and time from an Internet time server. In
EasyOS, Qsync is the utility that does that.
At first bootup, QuickSetup has a checkbox to enable getting time
from the Internet, which will launch Qsync. At first bootup on the Pi4,
if you are going to connect to Internet via wifi, not ethernet, then
there won't be an immediate Internet access. No problem, Qsync will run
once the Internet connection is established.
Qsync will run just once at bootup and after Internet connection.
That's fine, but I couldn't understand why it would suddenly stop
working. Then discovered that /etc/init.d/qsync was getting its
executable-flag cleared.
Ah ha, then I knew where things were going wrong. I was adding the
'devx' SFS layer, and /sbin/fixlayers in the initrd does a lot of sanity
checking whenever layers change. What it does, amongst other things, is
check that the scripts in /etc/init.d are the same as those in easy.sfs
(the bottom layer).
Anyway, to cut the story short, /etc/init.d/qsync in the top
read-write layer was getting deleted, allowing the one in easy.sfs to
appear on top, and that one does not have the executable-flag set.
Fixed it. Won't try to explain the logic, an interested developer can
open up the initrd and examine the code in /sbin/fixlayers. That will
be the next release of Easy of course, expected to be version 2.6.1. Not
just for the Pi4, have to bring out a Dunfell-series 2.6.x for the
x86_64 PC also.
Very pleased how Easy is performing on the Pi4, now a very snappy
performer. Still can only play 1080p videos, but that is OK for now.
Today had a go at compiling SeaMonkey 2.53.6 on the Pi4. It objected to these lines in file 'mozconfig':
mk_add_options MOZ_CO_PROJECT=suite
ac_add_options --enable-application=suite
So took them out. And hey, guess what, it created Firefox. Yep, real
Firefox. Well it is the same Mozilla code-base. Firefox latest version
is, I think, 86. However, Wikipedia explains that SM is currently built
from the Firefox version 60 ESR (Extended Support Release):
https://en.wikipedia.org/wiki/SeaMonkey
Tags: easy
Easy Version Control rollback device-tree files
EasyOS on the PC has not been concerned with device-tree files,
but they are a big thing on the ARM boards. They are in the boot
partition, and are read at bootup. Information:
https://www.kernel.org/doc/html/latest/devicetree/usage-model.html
It is still a mystery to me how they work, but they are needed by the
Raspberry Pi, and, as I discovered, getting the latest is important.
However, with Easy Version Control, if we roll back to an older
version of Easy, we should really roll back the device-tree also. Ditto
when roll forward.
The current device-tree files are in /boot/device-tree, which you can
view in a running Easy. These are actually located inside easy.sfs. So,
if roll back or forward to a different easy.sfs, then extract the
device-tree files out of easy.sfs and copy them to the boot partition.
That is what Easy Version Control now does. The modified scripts are
/usr/local/easy_version/easy-update and easy-version-control.
If you are running Easy 2.6, the "update" icon on the desktop will
run /usr/local/easy_version/easy-update, which does not have this
device-tree awareness, so will not copy the latest device-tree files to
the boot-partition.
In that case, after upgrading to version 2.6.1, manually copy the files
from /boot/device-tree to the boot-partition, replacing the old ones.
This manual step is only for 2.6. After that, every time you click
"update", the device-tree files will update in the boot-partition
automatically.
Tags: easy
Fixed compile of libvdpau-va-gl in OE
I posted yesterday about the problem in OpenEmbedded when the compile of a package requires execution of a binary:
https://bkhome.org/news/202101/fixed-compile-of-samba-without-krb5-in-oe.html
This problem does not occur if the build-architecture and
target-architectures are the same. The problem occurs with a
cross-compile.
Today I had the same problem, with package 'libvdpau-va-gl'. I had
previously compiled this in OE, but now the build-arch is x86_64 and the
target-arch is aarch64.
So, I used the same trick as with samba, of using pre-compiled
binaries, in this case it is just the one binary, 'shader-bundle-tool'.
The package uses cmake and ninja, and my knowledge of these is minimal.
This is the recipe meta-quirky/recipes-quirky/libvdpau-va-gl/libvdpau-va-gl_0.4.2.bb:
# Recipe created by recipetool
# recipetool create -o libvdpau-va-gl_0.4.2.bb https://github.com/i-rinat/libvdpau-va-gl/releases/download/v0.4.2/libvdpau-va-gl-0.4.2.tar.gz
# 20210121 PR_NUM is defined in local.conf...
#PR = "r${@int(PR_NUM) + 1}"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://LICENSE;md5=5a9126e7f56a0cf3247050de7f10d0f4"
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
#20210124 wants to run a binary:
#| /bin/sh: /mnt/sda1/nvme/oe-builds/oe-quirky/build-aarch64/tmp/work/aarch64-poky-linux/libvdpau-va-gl/0.4.2-r1/build/glsl/shader-bundle-tool: cannot execute binary file: Exec format error
SRC_URI = "https://github.com/i-rinat/libvdpau-va-gl/releases/download/v${PV}/libvdpau-va-gl-${PV}.tar.gz \
file://${BUILD_ARCH}/shader-bundle-tool"
SRC_URI[md5sum] = "8db21dcfd5cd14c6ec51b992e20369dc"
SRC_URI[sha256sum] = "7d9121540658eb0244859e63da171ca3869e784afbeaf202f44471275c784af4"
DEPENDS = "libx11 ffmpeg libvdpau libva mesa xserver-xorg"
inherit cmake pkgconfig
EXTRA_OECMAKE = "-DCMAKE_BUILD_TYPE=Release"
do_compile_prepend() {
mkdir -p ${B}/glsl/
cp -a -f ${WORKDIR}/${BUILD_ARCH}/shader-bundle-tool ${B}/glsl
touch -d '+1 hour' ${B}/glsl/shader-bundle-tool
#fool ninja not to overwrite shader-bundle-tool...
sed -i -e 's%TARGET_FILE = glsl/shader-bundle-tool%TARGET_FILE = glsl/shader-bundle-toolXXX%' ${B}/build.ninja
}
FILES_${PN} += "${libdir}/vdpau"
INSANE_SKIP_${PN} += "dev-so"
HOMEPAGE = "https://github.com/i-rinat/libvdpau-va-gl"
SUMMARY = "VDPAU driver with OpenGL/VAAPI backend"
Notice the line "touch -d '+1 hour' ${B}/glsl/shader-bundle-tool" -- I
thought that setting the modify date ahead would prevent ninja from
recompiling it, but that didn't work. Ninja does not work like make.
Instead, I found the 'build.ninja' file, which specified the name of
the compiled file, so I just changed that from 'shader-bundle-tool' to
'shader-bundle-toolXXX'. Great, worked, left the pre-compiled binary
intact.
The recipe works. I have added this package to the Pi4 package-list,
although I don't know what use it will be. By setting
VDPAU_DRIVER=va_gl, it causes VDPAU to use the GL backend, but I don't
now much about VDPAU either.
Here is the libvdpau-va-gl project page:
https://github.com/i-rinat/libvdpau-va-gl
Only including this in the next Pi4 build as something extra to play with.
Tags: oe
SeaMonkey on Pi4 no longer freezes
In the release notes for EasyOS version 2.6 on the Raspberry Pi4, I reported that SeaMonkey would often freeze, temporarily:
http://distro.ibiblio.org/easyos/aarch64/releases/dunfell/rpi4/2.6/release-notes-2.6.htm
The kernel offers "mq-deadline", "kyber" or "none" IO schedulers, and the default is "mq-deadline". I changed to "kyber":
echo kyber > /sys/block/${WKG_DRV}/queue/scheduler
Ans now SM is behaving nicely, no appreciable freezing. I am testing
version 2.6.1, and playing around on youtube.com do get a segmentation
fault sometimes. I can live with that, better than freezing. Running SM
2.53.5.1.
One other thing: The SM cache is in /root/.mozilla, not happy with
this, as always trying to reduce writes to the drive. So have changed it
to /tmp. SM creates a folder named /tmp/Cache2. In EasyOS, /tmp is a
tmpfs, in RAM. The downside of this is the cache will be lost at
shutdown. Probably an upside is a possible security benefit.
Tags: easy
Kernel 5.10.9 compiled for Pi4
EasyOS for the Raspberry Pi4, version 2.6, has the 5.10.4 Linux
kernel. I have now compiled the 5.10.9 kernel, that will be used in the
next release of Easy.
Kernel source, patches and build script are here:
http://distro.ibiblio.org/easyos/source/kernel/5.10.9-rpi4/
Overnight also did a complete recompile in OpenEmbedded, with changes as reported yesterday:
https://bkhome.org/news/202101/fixed-compile-of-samba-without-krb5-in-oe.html
Also bumped ffmpeg to 4.3.1.
Tags: easy
Fixed compile of Samba without krb5 in OE
Yesterday I posted about improvements compiling in OpenEmbedded:
https://bkhome.org/news/202101/tweaks-for-openembedded-dunfell.html
EasyOS on the Pi4 does not have samba, as compile failed in OE. Yes, I
could compile it in a running EasyOS on the Pi4, but would rather fix
it in OE.
I have a 'samba_%.bbappend' file, the main objective being to remove
the 'pam' and 'krb5' dependencies. I worked on this recipe this morning.
The problem is that instead of 'krb5', the internal 'heimdahl' is used,
and this compiles two binaries, that are then executed during compile.
The problem is that the binaries are compiled for the target system,
in this case aarch64, whereas the build system is x86_64, so the
binaries cannot run.
Fine, except that exactly how to do this is very poorly documented.
The official documentation is very vague. A couple of years ago, I
bought a book, "Embedded Linux Systems with the Yocto Project", but
found that it also said hardly anything about this. I consider this to
be an important topic, yet it seems that many OE experts don't know much
about it either.
Perhaps it is explained somewhere, and I have just overlooked it.
Anyway, when I hit this problem, I just use pre-compiled binaries, by compiling the package separately on my build-system.
In the case of samba, that is what Uri has done:
http://samba.2283325.n4.nabble.com/Samba4-4-5-cross-compilation-for-PowerPC-td4710972.html
...not on OE, but I can apply the same principle. This is my 'samba_%.bbappend':
#heimdahl compiles these and want to run them during compile...
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
SRC_URI_append = "\
file://${BUILD_ARCH}/asn1_compile \
file://${BUILD_ARCH}/compile_et"
DEPENDS = "readline virtual/libiconv zlib popt libtalloc libtdb libtevent libldb libaio libtasn1 jansson libbsd gpgme acl gnutls libarchive openldap"
REQUIRED_DISTRO_FEATURES = ""
SYSTEMD_PACKAGES = ""
SYSTEMD_SERVICE_${PN}-base = ""
SYSTEMD_SERVICE_${PN}-ad-dc = ""
SYSTEMD_SERVICE_winbind = ""
SYSTEMD_AUTO_ENABLE_${PN}-ad-dc = ""
PACKAGECONFIG = ""
EXTRA_OECONF = "--enable-fhs \
--with-piddir=/run \
--with-sockets-dir=/run/samba \
--with-modulesdir=${libdir}/samba \
--with-lockdir=${localstatedir}/lib/samba \
--with-cachedir=${localstatedir}/lib/samba \
--disable-rpath-install \
${@oe.utils.conditional('TARGET_ARCH', 'x86_64', '', '--disable-glusterfs', d)} \
--with-cluster-support \
--with-profiling-data \
--with-libiconv=${STAGING_DIR_HOST}${prefix} \
--without-pam --without-sendfile-support \
--without-ad-dc --without-ntvfs-fileserver --nopyc --nopyo \
--without-fam --without-lttng --without-systemd --disable-avahi \
--enable-cups --with-acl-support --with-automount --with-quotas \
--with-syslog --with-ldap --enable-gnutls --with-gpgme --with-libbsd \
--with-libarchive --without-valgrind \
--bundled-libraries=!asn1_compile,!compile_et"
RDEPENDS_${PN}-ad-dc = ""
# ref: http://samba.2283325.n4.nabble.com/Samba4-4-5-cross-compilation-for-PowerPC-td4710972.html
export USING_SYSTEM_ASN1_COMPILE = "1"
export ASN1_COMPILE = "${WORKDIR}/${BUILD_ARCH}/asn1_compile"
export USING_SYSTEM_COMPILE_ET = "1"
export COMPILE_ET = "${WORKDIR}/${BUILD_ARCH}/compile_et"
ERROR_QA_remove = "file-rdeps"
WARN_QA_remove = "file-rdeps"
As my build-system is EasyOS x86_64 on a PC, I placed those two
'asn1_compile' and 'compile_et' into
meta-quirky/recipes-connectivity/samba/samba/x86_64. I also grabbed the
two that were compiled in OE and put them into samba/samba/aarch64. The
'samba_%.bbappend' is in meta-quirky/recipes-connectivity/samba.
Note, 'meta-quirky' is my layer in OE, with all of my customizations and extra packages.
Good, it compiled and installed.
Just a little detail: in OE, HOST_ARCH is "aarch64", that is, the target architecture. Not, as you might think, the build system architecture. We often use the term "host system", but that is misleading with OE, so I use the term "build system".
Tags: oe
Tweaks for OpenEmbedded Dunfell
I am currently working on changes to my fork of OE, Dunfell release. Working through a to-do list, here is progress so far...
When I compiled LibreOffice recently on the Pi4, was unable to use
the 'boost', 'harfbuzz' and 'neon' system packages, had to use internal
versions. This is duplication, means that the final LibreOffice binary
package will be bigger that is could be.
- Boost was missing headers for the locale library. Fixed.
- Neon version was too old. Have bumped 0.30.2 to 0.31.2.
- Harfbuzz was missing graphite support. Fixed.
After working through the to-do list, I will do a complete recompile
in OE, and want to bump the "revision number" of all packages by one.
For example, a package is currently 'harfbuzz-2.6.4-r0-aarch64.tar.xz',
and for the upcoming rebuild, want it to become
'harfbuzz-2.6.4-r1-aarch64.tar.xz'.
The basic reason for wanting this, is it makes rsync with the package
repository at ibiblio.org simpler. Plus, the distinction is helpful
locally.
I couldn't find anything suitable in the official OE/Yocto docs, nor
in forum discussion, so implemented my own simple method. In the
'local.conf' file, I have added these two lines:
#20210121 radical, this globally changes the base revision from r0...
PR = "r1"
#.bbappend recipes can use this to bump PR. ex: PR = "r${@int(PR_NUM) + 1}"
PR_NUM = "1"
In a .bbappend file, where I had previously hard-coded a revision number, have changed to a dynamic calculation. For example:
#PR = "r1"
PR = "r${@int(PR_NUM) + 1}"
...it was previously "r1", now it will be "1 + 1", that is, "r2", so will get a package name bumped one-up from before.
Have added 'tigervnc' to the package list -- that one is for rufwoof.
Lot more on the to-do list, will get onto it soon. Right now, going for a walk then lunch.
EDIT:
'disktype' is a great little utility, but the official release is stuck
at version 9 for many years. Consequently, it does not support some
filesystems. However, over the years people have added patches. In OE I
had just one patch, for ext4, that I got from Pardus Linux, and it was
good at the time, however no longer works.
Have updated OE with a collection of patches from here:
https://packages.debian.org/sid/disktype
ext4 detection now works, and now have f2fs, exfat and btrfs detection.
Tags: easy
Fix for 2createpackages in woofQ
WoofQ is the build system for EasyOS. It has scripts '0setup',
'1download', '2createpackages' and '3buildeasydistro', that are run in
that order. The script '2createpackages' splits each input package into
_EXE, _DEV, _DOC and _NLS components.
Recently, when compiling LibreOffice in EasyOS on the Pi4, the
configure step reported that the system boost libraries cannot be used,
as some header files were missing. So, I had to use the internal boost,
which does make the final LibreOffice PET bigger than it could have
been.
Today, found the culprit. '2createpackages' places files with path
"*/locale/*", with some conditions, into _NLS. However, boost has
header files in usr/include/boost/locale, and '2createpackages' was
placing these into _NLS, whereas they should go into _EXE. Fixed.
Tags: easy