Latest release 0.31 needs some more bits during build. Add them
at right SHA checkouts, from
tools/install-build-deps
Signed-off-by: Khem Raj <raj.khem@gmail.com>
According to the used desktop environment there are high level xdg-desktop-portal
backends available. There are implementations for kde, lxde, gnome, wlroots.
Even hyprland provides its own portal backend addition.
These backends are known to cause unexpected behavior if mixed together,
so it was a little bit overambitious to set the gnome portal as a
runtime dependency by default as it may break other environments.
Remove it from RDEPENDS
Signed-off-by: Markus Volk <f_l_k@t-online.de>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Importing private keys into a PKCS#11 token is broken with OpenSC 0.23.0
and OpenSSL 3. Fix it by backporting the corresponding upstream fixes.
Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
The use of `>&` assumes we are using a shell that supports this syntax.
In case of running this through `sh`, we get "Syntax error: Bad fd number"
Signed-off-by: Khem Raj <raj.khem@gmail.com>
The extract-cert tool is used to fetch the X.509 certificate associated
with a key from a PKCS#11 token (such as a HSM or YubiKey). This version
is derived from certs/extract-cert in the Linux kernel as a stand-alone
tool to make it available when signing other software components besides
the kernel.
Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
For now syslog-ng segfaults on ppc64le. The problem could be reproduced
by simply adding syslog-ng to IMAGE_INSTALL and then building and starting
an image for qemuppc64.
The underlying root cause is unknown yet. This workaround, on the other hand,
helps improve the situation a little bit in the sense that users can at least
use syslog-ng on ppc64le targets.
Note that this workaround should be dropped once the upstream issues[1][2]
are fixed. This has also stated very clearly in the patch.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=30062
[2] https://github.com/syslog-ng/syslog-ng/issues/4285
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
* ispellaff2myspell: A program to convert ispell affix tables to myspell format
pulls perl into the images
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
We already depend on sqlite, but the objectstore backend using it is not
enabled by default. Add the necessary configure option.
The db backend is more robust when accessing the objectstore from many
parallel processes (such as during kernel module signing).
Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
SoftHSMv2 actually only uses the sqlite library. With the check for the
sqlite3 binary, building with the DB backend would mean depending on
sqlite-native.
Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
This helps in overcoming a problem when using scons with ccache enabled.
When commands get longer, then it resorts to using response files to do
the operations e.g. @/tmp/tmp96j6icra.lnk when this response file is
inboked by compiler it works ok, however, this does not when ccache is
used to invoke the complilation. We see errors e.g.
ccache @/tmp/tmppsyij_0v.lnk
ccache: error: execute_noreturn of @/tmp/tmppsyij_0v.lnk failed: No such file or directory
Using MAXLINELENGTH setting ensures that we can use ARG_MAX to extend
the length of commandline and hence avoid using response files. This
issue is also reported in mongodb [1]
[1] https://jira.mongodb.org/browse/SERVER-38389
Signed-off-by: Khem Raj <raj.khem@gmail.com>
It uses python3-config during build to grok the python specific
includedirs, therefore its important to ensure that target specific
python3-config is used, otherwise currently it defaults to native
python3-config which ends up adding native python3 include paths
which might work out ok but is exposed when target is 32bit + lfs
enabled, the headers don't match between native and target python
Signed-off-by: Khem Raj <raj.khem@gmail.com>
It uses python3-config during build to grok the python specific
includedirs, therefore its important to ensure that target specific
python3-config is used, otherwise currently it defaults to native
python3-config which ends up adding native python3 include paths
which might work out ok but is exposed when target is 32bit + lfs
enabled, the headers don't match between native and target python
Signed-off-by: Khem Raj <raj.khem@gmail.com>
- Switch to using meson
- Fix build with gcc13
- Use packageconfig for enabling python support and static libs
Signed-off-by: Khem Raj <raj.khem@gmail.com>
They are not implemented for all arches e.g. RISCV on gcc 13 yet
Fixes
riscv64-yoe-linux/gcc/riscv64-yoe-linux/13.0.1/ld: lib/libPocoFoundation.so.94: unde
fined reference to `__atomic_exchange_1'
Signed-off-by: Khem Raj <raj.khem@gmail.com>
