redis 8.4 started bundling an xxHash snapshot in deps/xxhash, which is
built and linked into redis-server. The snapshot reports itself as 0.8.3
but does not match that release: it carries RISC-V Vector and LoongArch
LASX backends that landed after the v0.8.3 tag, so the system xxhash is
not a substitute for it.
Its XXH3 accumulate and scramble routines are marked always_inline but
are only ever reached through function pointers, so the compiler has to
resolve the indirect call before it can honour the attribute.
xxHash drops those inline hints on its own when __NO_INLINE__ is
defined, which covers -O0 and -fno-inline, but nothing covers -Og.
Recent GCC no longer resolves the indirect calls at that optimisation
level, so every build with DEBUG_BUILD = "1" fails:
xxhash.h:5476:1: error: inlining failed in call to 'always_inline'
'XXH3_scrambleAcc_neon': function not considered for inlining
make[2]: *** [Makefile:108: xxhash] Error 2
ld: cannot find ../deps/xxhash/libxxhash.a: No such file or directory
Upstream xxHash closed this as not fixable in code (Cyan4973/xxHash#943)
and instead documents XXH_NO_INLINE_HINTS as the supported way to
compile with -Og. Define it when -Og is the selected optimisation,
leaving regular builds untouched so xxHash keeps its inline hints there.
oe-core already carries exactly this workaround for the standalone
xxhash recipe, added in 3464c67cd3 ("xxhash: fix build with gcc 12")
for the same -Og inlining failure, so use the identical expression here
rather than a second spelling of the same condition. The bundled copy
needs its own because redis builds deps/xxhash from its own tree and
never links the system library.
AI-Generated: Uses Claude Code
Signed-off-by: Ricardo Salveti <ricardo.salveti@oss.qualcomm.com>
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
Change bb.error to bb.parse.SkipRecipe so the recipe is skipped at parse
time for unsupported architectures, rather than raising a fatal error
that breaks parsing even when the recipe is not in use.
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
The relax-build-requirements patch capped wheel at <0.48.0, which
excludes exactly the wheel 0.48.0 that oe-core now ships, so do_compile
fails its build-requirement check:
ERROR Unmet dependencies ... wheel<0.48.0,>=0.37.1 found: 0.48.0
Drop the wheel upper cap entirely, mirroring the setuptools change
already in this patch: OE provides wheel via DEPENDS and builds with
--no-isolation, so the cap is spurious.
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Upstream ships its test suite under tests/ (plural), but the recipe
overrode PTEST_PYTEST_DIR to "test" (singular), which doesn't exist in
the source tree. ptest-python-pytest.bbclass's default is already
"tests"; drop the override so the real directory gets installed and
run instead of nothing.
Signed-off-by: Khem Raj <raj.khem@gmail.com>
gevent.monkey.patch_all() internally does "import multiprocessing"
during _gevent_did_monkey_patch (gevent/subprocess.py); without
python3-multiprocessing installed this raises ModuleNotFoundError,
crashing any gunicorn gevent-worker boot. Explains both the direct
import-order test failures and the ConnectionResetError seen in the
control-socket integration tests, since the worker process crashes
mid-boot in both cases.
Signed-off-by: Khem Raj <raj.khem@gmail.com>
python3-misc for timeit, python3-statistics for statistics, both used
by pytest-benchmark's storage/stats machinery.
Signed-off-by: Khem Raj <raj.khem@gmail.com>
tests/test_core.py does GlancesMain(args_begin_at=2) at module import
time, slicing the real process sys.argv. Passing --automake on the
pytest command line (rather than via PYTEST_ADDOPTS) shifted that
slice and broke it; set it via PYTEST_ADDOPTS instead.
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Copy docs_src into the ptest tree since scripts/tests import
docs_src.*. Remove the two settings examples that require
python3-pydantic-settings, which meta-openembedded doesn't package.
Signed-off-by: Khem Raj <raj.khem@gmail.com>
test_SigningKey_from_pem_pkcs8v2_EdDSA embeds its PEM fixture as an
indented triple-quoted string, but der.unpem() only recognizes
"-----BEGIN/END-----" markers with no leading whitespace; the indented
END marker gets swallowed into the base64 payload instead of being
stripped, so it fails with "Incorrect padding" regardless of
environment. Upstream test-authoring bug in 0.19.2, not a packaging
issue.
Signed-off-by: Khem Raj <raj.khem@gmail.com>
setuptools3.bbclass and python_setuptools_build_meta.bbclass no longer
add python3-wheel-native to DEPENDS by default, following oe-core
commit e546c697b7 ("classes/setuptools3: remove wheel dependency"),
since setuptools >= 70.1.0 no longer needs the external wheel package
to build a wheel.
This recipe's pyproject.toml/setup.py still declares wheel as a build
requirement, so pyproject-build's --no-isolation dependency check now
fails:
ERROR Unmet dependencies (checked against .../recipe-sysroot-native/usr/bin/nativepython3):
wheel
wanted: any
found: not installed
Add python3-wheel-native to DEPENDS directly to satisfy it.
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
The current mctp recipe relies on the upstream's conditional build and
install of the mctpd binary if systemd is present, only building the
mctp utility otherwise. Future upstream changes allowing running as
non-root require more control over the build process. We will need to
add a new system user when mctpd is built.
Adding a user requires inheriting useradd, which assumes at least one
user will be created, failing the recipe otherwise. Building without
mctpd would then cause the recipe to fail as conditionally inheriting
useradd seems infeasible.
To make useradd available for the new upstream release, split the recipe
into "mctp" for the utilities and "mctpd" for the daemon, isolating the
systemd dependency to "mctpd".
This makes the two parts of the source explicitly selectable from user
choice, rather than auto-detecting based on the presence of systemd.
This will allow the mctpd daemon to be installed without the mctp
utilities and allow the utilities to be installed without the daemon in
distros without systemd. It will also let us express the useradd rules
only when they're needed for the mctpd installation in the upcoming
version bump.
The mctp/mctpd split cannot be done with different packages within the
same recipe. It would require the systemd and useradd classes be added
to inherit_defer only when mctpd is to be built, and the library
functions cannot be used to detect which packages are built.
Signed-off-by: James Lee james@codeconstruct.com.au
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
do_install ran make with -e, which gives the environment precedence over
the makefile's own assignments. Every CPPFLAGS and CFLAGS use in the
makefile is +=, seeded from the environment, so -e discarded all of the
makefile's additions: the CPPFLAGS += defining PACKAGE, PACKAGE_BUGREPORT
and VERSION, the conditional -DNLS, -pipe and $(WARNINGS). utils/info.c
and utils/set.c then failed to build with "'PACKAGE' undeclared" while
relinking cpufreq-info and cpufreq-set, which install: pulls in via all:.
Dropping -e also makes do_install and do_compile agree on flags, where
the install-time relink previously produced binaries built differently
from the ones do_compile had made.
-e predates 0001-dont-unset-cflags.patch, back when the makefile assigned
CC/LD/AR/STRIP/RANLIB absolutely and -e was the only way to override them.
That patch is dropped here in favour of setting CC on the make command
line, which outranks a makefile assignment without needing a patch at all.
CC is the only one of those variables the makefile ever references: LD, AR
and RANLIB are assigned but never used, and STRIP only feeds STRIPCMD,
which the recipe already overrides. The patch had carried
Upstream-Status: Pending since 2012 against a project whose last commit
was in 2011.
NLS becomes a PACKAGECONFIG rather than an inline USE_NLS expression so it
can be set per-recipe, defaulting from USE_NLS so existing behaviour is
unchanged. gettext-native is named explicitly because gettext.bbclass
substitutes gettext-minimal-native when USE_NLS is no, and that has no
xgettext/msgmerge for the update-gmo target this enables. The gettext
inherit becomes conditional on the same PACKAGECONFIG, deferred because it
reads a value that does not exist yet at that point in the parse.
AI-Generated: Claude Opus 5 (Claude Code)
Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
SRC_URI pointed at github.com/emagii/cpufrequtils. The canonical upstream
repository is still live and its master HEAD is exactly the SRCREV pinned
here, a2f0c39d, so the source is unchanged. The kernel.org URL was already
in the recipe, commented out and malformed (unterminated quote). Both git://
and https:// serve it today, so there was no technical reason for the
mirror; https is used per the usual preference.
The pinned revision is 8 commits past the 008 release that the tarball at
kernel.org/pub/linux/utils/kernel/cpufreq/ contains - removal of the /proc
interface, Catalan translations, MAX_LINE_LEN, two x86 aperf fixes, and the
"make NLS optional" commit that introduces the NLS switch this recipe
relies on. PV gains +git so it stops claiming to be the 2010 release.
Shell function bodies are reindented to tabs. No functional change.
AI-Generated: Claude Opus 5 (Claude Code)
Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
GNUmakefile hardcodes its own CFLAGS= assignment (patched by
0001-Build-so-lib.patch to add -fPIC for the shared-lib build). As a
plain makefile variable, that assignment overrides the CFLAGS bitbake
exports into the build environment -- including the -ffile-prefix-map
flags from DEBUG_PREFIX_MAP. Without those, -g debug info in the
compiled snowball/stemwords/libstemmer.so binaries embeds the absolute
build-tree path, tripping the buildpaths QA check on the -dbg package:
ERROR: libstemmer-3.1.1-r0 do_package_qa: QA Issue: File
/usr/bin/.debug/snowball in package libstemmer-dbg contains
reference to TMPDIR [buildpaths]
Pass CFLAGS via EXTRA_OEMAKE instead, which oe_runmake places on the
make command line and therefore does take precedence over the
makefile's own CFLAGS= assignment.
Verified via cleansstate rebuild: log.do_package_qa no longer contains
any buildpaths warnings, and `strings` on the rebuilt snowball debug
binary no longer contains any build/tmp/work host paths.
AI-Generated: Uses Claude Code
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
Ankur Tyagi
Ricardo Salveti
Kory Maincent
Jaipaul Cheernam
Khem Raj
Khem Raj
James Lee
Trevor Gamblin
Eilís Ní Fhlannagáin
Alex Kiernan