OE-related posts Mar. 11 to Apr. 28 2022
I usually post OpenEmbedded-related blog posts in the "easy" category, not in the "oe" category. Here they are, from March 11, 2022, to now:
- OE and woofQ projects for Easy 3.4.7 — April 27, 2022
- Droidcam and deps compiled in OE — April 26, 2022
- AWF compiled in OpenEmbedded — April 23, 2022
- GUVCView webcam viewer compiled in OE — April 22, 2022
- Dependencies for new app (Oomox) compiled in OE — April 11, 2022
- OE and woofQ project tarballs used for Easy 3.4.5 — April 08, 2022
- gpptp internationalized, now version 2.1 — March 29, 2022
- OE and woofQ project tarballs used for Easy 3.4.4 — March 26, 2022
- OE and woofQ tarballs for EasyOS 3.4.3 — March 20, 2022
- OE recompile pending tonight — March 17, 2022
Good!
Tags: oe
OE-related posts Dec. 27 2021 to Mar. 10 2022
I usually post OE-related blog posts in the "easy" category, not in the "oe" category. Here they are, from December 27, 2021 to now:
- recordMyDesktop 0.5.1 compiled in OpenEmbedded — March 10, 2022
- JWM 2.4.1 compiled in OE — March 09, 2022
- xf86-video-mach64 compiled in OE — March 09, 2022
- OpenEmbedded Dunfell revision-8 compile — March 08, 2022
- EasyOS update fix for JWM — February 15, 2022
- More exotic cross-compile path fixing — February 02, 2022
- Hack to fix OE cross-compile paths — February 01, 2022
- gst-editing-services compiled in OE — January 29, 2022
- More dependencies for Pitivi video editor — January 28, 2022
- Gstreamer packages compiled in OE — January 26, 2022
- Osmo PIM 0.2.14 compiled in OE — January 17, 2022
- Opencv compiled in OpenEmbedded — January 16, 2022
- Frei0r compiled in OpenEmbedded — January 15, 2022
- Python modules for Flowblade — January 12, 2022
- xxd from vim replaces busybox xxd — January 10, 2022
- Pyqt5 and MLT compiled in OE — January 05, 2022
- MPV bumped to 0.34.1 — January 04, 2022
- VLC 3.0.12 with Qt5 GUI compiled — December 27, 2021
Good!
Tags: oe
OpenEmbedded-related blog posts
I usually post OE-related blog posts in the "easy" category, not in the "oe" category. Here they are, from August 28 2021 to now:
- OBS-Studio compiled in OpenEmbedded — December 27, 2021
- LiVES compiled in OpenEmbedded — December 26, 2021
- OBS Studio and dependencies compiled — December 21, 2021
- LiVES video editor compiled — December 20, 2021
- Deps compiled for video editor — December 19, 2021
- Scribus and VYM Qt5 apps compiled in OE — December 18, 2021
- Qt5 qtbase compiled in OE — December 18, 2021
- Qt4 and Scribus 1.4.8 compiled — December 17, 2021
- Fixes for samba — December 15, 2021
- How to cross-compile 850+ packages using Yocto/OpenEmbedded — December 12, 2021
- OpenEmbedded Dunfell 3.1.12 recompile — December 11, 2021
- Claws Mail compiled in OE — December 10, 2021
- libetpan and bogofilter compiled in OE — December 09, 2021
- litehtml compiled in OpenEmbedded — December 09, 2021
- Mercurial source control manager now in devx — December 02, 2021
- Nemiver debugger now in devx SFS — November 28, 2021
- Package libxres compiled — November 19, 2021
- Mesa package much bigger than it needs to be — November 06, 2021
- Latest libcamera and pipewire compiled — November 01, 2021
- libcamera compiled in OpenEmbedded — October 30, 2021
- LibreOffice fr de fully translated — October 30, 2021
- Bluez 5.62 compiled in OpenEmbedded — October 27, 2021
- Meson version bumped to 0.59.2 — October 26, 2021
- OpenEmbedded Dunfell complete recompile — October 20, 2021
- More python3 modules in devx SFS — October 19, 2021
- mesa recompiled with gallium drivers — October 18, 2021
- Remmina GUI for RDP and VNC — October 10, 2021
- xrdp, xorgxrdp and freerdp compiled — October 10, 2021
- gtk-vnc compiled for EasyOS — October 09, 2021
- x11vnc remote X11 VNC server compiled — October 09, 2021
- Dropbear ssh server and client compiled — October 09, 2021
- powerapplet-tray fixed for recent kernels — October 09, 2021
- nodejs compiled in OpenEmbedded — September 23, 2021
- Rolled back to gtk2 version of yad — September 15, 2021
OK!
Tags: oe
OpenEmbedded project 20210828 uploaded
This blog supports posting in different categories, for example
"oe", "easy" and "light". In theory, a post can be to more than one
category, but I have never tested that. The OpenEmbedded "oe" project is
intertwined with EasyOS "easy", so I often post OpenEmbedded news to
the "easy" category. But that is a problem if you go to the "oe" URL,
you won't see those posts:
https://bkhome.org/news/tag_oe.html
So, this post is to the "oe" category, with links to recent OpenEmbedded posts.
As I have pretty much decided to stay with the Dunfell-series for
EasyOS, packages compiled in OpenEmbedded, have been through the
exercise of updating and improving the OE build. These are the relevant
posts over the last few days:
- Statically linked packages with musl in OpenEmbedded — August 28, 2021
- OpenEmbedded Dunfell aarch64 rebuild — August 27, 2021
- 807 packages compiled in OpenEmbedded for EasyOS — August 26, 2021
- OpenEmbedded Dunfell updated rebuild — August 26, 2021
The latest OE-Dunfell project tarball is 'dunfell-20210828.tar.gz', uploaded here:
http://distro.ibiblio.org/easyos/project/oe/dunfell/
There are some large packages that are not compiled in OE, such as
SeaMonkey. Reason, they are very cross-compiler unfriendly. I am
planning to enhance woofQ with automated package compiler functionality
in a running EasyOS.
Tags: oe
Inkscape compiled in OpenEmbedded
As already posted, I have recompiled everything in OE:
https://bkhome.org/news/202104/dunfell-recompile-commencing-in-openembedded.html
Also added 'pngoverlay-cairo':
https://bkhome.org/news/202104/pngoverlay-cairo-utility-now-in-woofq.html
Cross-compiling can be a challenge with some packages, and some of
the big ones, such as SeaMonkey, LibreOffice and Inkscape, I have
compiled in a running EasyOS (with the "devx" SFS loaded).
I have previously compiled LibreOffice in OE, see the Pyro series. But it was a lot of work.
Today I have imported Inkscape into OE. Had to import these dependencies into OE:
double-conversion potrace gdl
Then inkscape compiled, no issues. Good, I congratulate the developers on a well-behaved build. It is version 1.0.2.
My latest OE, based on the Dunfell release, is available as a
tarball. It is really just the Dunfell release of OE with my
"meta-quirky" layer. The tarball has some documentation. Available here:
http://distro.ibiblio.org/easyos/project/oe/dunfell/dunfell-20210410.tar.gz
...there is no git repo, just these tarballs, that are snapshots of
my local system. My host OS is EasyOS Dunfell-series 2.6.2 x86_64, with
"devx" loaded. You need a partition with at least 350GB free -- my build
was done on a new 1TB SATA SSD (connected via USB3), and so far using
326GB. If I was to do another build, for a different target, say i686,
then the used storage would jump way up -- so good to have 1TB
drive.
Tags: oe
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
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