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

That's good, I will convert Firefox into an SFS and make it available for the next release of the Pi4.  But the question now, is how to get the source to compile as 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.

OE does have a mechanism to handle this. It is possible to compile 'samba-native', that is, samba compiled to run on the build-system, and then use the two binaries from that when compile 'samba'.

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.

1. Boost was missing headers for the locale library. Fixed.
2. Neon version was too old. Have bumped 0.30.2 to 0.31.2.
3. 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. 

Every now and again, tweak something in woofQ and usually don't report it to the blog. '2createpackages' for example, previously had a small fix on 2020-04-02. 

Tags: easy