Changelog:
===========
- Nano refuses to start when standard output is not a terminal.
- Options --newbuffer and 'set newbuffer' were added as better
synonyms of --multibuffer and 'set multibuffer'.
- Legacy keystroke pairs ^W^T and ^/^T are recognized again.
Signed-off-by: Wang Mingyu <wangmy@fujitsu.com>
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
uim-module-manager crashes in uim_init() while requiring key.scm:
#0 __strlen_evex ()
#1 make_loaded_str (filename=0x7e)
#2 scm_p_require ()
...
#29 uim_init ()
scm_p_require() dereferences its FILENAME argument again after the
nested scm_load(), but nothing keeps a tagged ScmObj reference to it.
SigScheme's conservative collector only accepts properly tagged words
(within_heapp() / SCM_TAG_CONSISTENTP()), while the compiler keeps just
SCM_DROP_TAG(filename) and the interior char *, so the string is swept
and its cell recycled mid-load:
before load: cell=0x7ffff7d5a090 obj_x=0x555555569180 "key.scm"
after load: cell=0x7ffff7d5a090 obj_x=0x7e <- recycled
Whether it triggers is pure allocation timing, which is why uim-native
fell over while the cross-built uim ran the same scm files fine.
Add the patch to the common SRC_URI rather than the class-target one,
since it is uim-native that scm/Makefile runs at build time.
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
A full check-upgrade-status sweep of meta-oe found 121 recipes reporting
UNKNOWN_BROKEN: their upstream version check resolved no version. This
adds the correct check metadata to each so the version check works again.
Fixes, by mechanism:
- wget/tarball recipes: add UPSTREAM_CHECK_URI + UPSTREAM_CHECK_REGEX
pointing at the real release listing (SourceForge files pages, GitHub
releases pages, GNU/ftp mirrors, distro pools).
- git recipes with release tags in a non-default format: add
UPSTREAM_CHECK_GITTAGREGEX matching the actual tag scheme.
- git repos with no tags at all: UPSTREAM_CHECK_COMMITS = "1".
- recipes whose upstream has no checkable release channel, or whose PV
format cannot be compared against upstream tags (CPAN zero-padded
versions, AUTOINC "git" PVs, dash-separated tags the checker cannot
convert): UPSTREAM_VERSION_UNKNOWN = "1" with an explanatory comment.
Also override GITHUB_BASE_URI for libppd's sibling libcupsfilters where the
github-releases class default pointed at a non-existent org (404).
Only version-check metadata is touched; no SRC_URI, SRCREV, PV, or checksum
is changed, so nothing that gets built is affected. Each fix was verified
with devtool check-upgrade-status: 120 of 121 now resolve (MATCH, UPDATE,
COMMITS, or an honestly-declared UNKNOWN). The remaining recipe (libubox)
already has correct metadata and only fails locally because the git://
port to git.openwrt.org is firewalled on the build host.
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
Needed since our cargo class now stops the git2-sys and sqlite3-sys
crates from using a bundled copies of the libraries.
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
Needed since our cargo class now stops the git2-sys crate from using a
bundled copy of libgit2. Also inherit pkgconfig as that is used to find
the system libgit2.
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
rice-proto isn't really bundled but is a subproject in librice that is
built using the pkg-config crate. However the cargo class now disables
bundled dependencies, so explicitly allow rice-proto to be built.
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
Not sure why an AV1 encoder needs libgit2 but that's rust's dependency
tree for you. Needed since our cargo class now stops the git2-sys crate
from using a bundled copy of libgit2.
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
Export libsparse, libbase, and liblog headers and libraries to the sysroot.
Currently, these are often internal to the build.
Reorganise header installation to ${includedir}/sparse to match the expected
include paths for e2fsprogs contrib tools.
Signed-off-by: AshishKumar Mishra <emailaddress.ashish@gmail.com>
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
Add a custom do_compile step to build the ext2simg_android utility (ext2simg)
when building for the native class.
This can be used to generate ext* based sparse image
Signed-off-by: AshishKumar Mishra <emailaddress.ashish@gmail.com>
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
oe-core 6b2defb521 ("utils: Move functions from utils.bbclass to utils.py")
moved all_multilib_tune_values out of utils.bbclass, so the unqualified name
is no longer available to recipes. Update the packagegroup snippet in the
comment block so that copying it still works.
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
The variable was pruned from oe-core already in 2020 since
commit 3fdd772b419b ("recipes: Remove remaining INC_PR variables")
Signed-off-by: Niko Mauno <niko.mauno@vaisala.com>
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
configure.ac uses AX_COMPILER_FLAGS, AX_PROG_JAVAC and AX_PROG_JAVA
from autoconf-archive, and autoreconf regenerates aclocal.m4 so the
copy in the tarball doesn't help.
| configure.ac:61: error: undefined or overquoted macro: AX_COMPILER_FLAGS
| autoreconf: error: autoconf failed with exit status: 1
Works today only because relp depends on libidn which depends on
autoconf-archive. Depend on it directly.
Signed-off-by: Jaipaul Cheernam <jaipaul.cheernam@est.tech>
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
Move `rich` and `shellingham` from `ptest` to main package as `typer`
depends on them. Remove `click` since it was vendored in 0.26.0 and
`typing-extensions` since it isn't mentioned in pyproject.toml, and the
only use is in module that is loaded when running on Windows.
Add missing `annotated-doc` package rdependency, and missing python3
modules (went through the code to check the imports)
Signed-off-by: iwanicki92 <iwanicki92@gmail.com>
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
`python3-markdown-it-py` was missing along with some python3 modules.
I went through the code and added everything imported that I noticed,
except modules imported on Windows.
Signed-off-by: iwanicki92 <iwanicki92@gmail.com>
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
python3-mpv RDEPENDS on mpv, which requires ffmpeg (LICENSE_FLAGS =
"commercial"). With "commercial" not in LICENSE_FLAGS_ACCEPTED, parsing
the universe target - which ignores EXCLUDE_FROM_WORLD - reports:
WARNING: Nothing RPROVIDES 'mpv' (but .../python3-mpv_1.0.8.bb
RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'python3-mpv' is unbuildable, removing...
Now that mpv carries LICENSE_FLAGS = "commercial" and is skipped, carry
the same flag here so python3-mpv is likewise skipped cleanly in both
world and universe instead of surfacing as an unbuildable dependency.
The redundant EXCLUDE_FROM_WORLD is dropped.
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
mpv has an unconditional DEPENDS on ffmpeg, which carries
LICENSE_FLAGS = "commercial". When "commercial" is not in
LICENSE_FLAGS_ACCEPTED (the default), ffmpeg is skipped, and parsing the
universe target - which, unlike world, ignores EXCLUDE_FROM_WORLD -
reports mpv as an unbuildable dependency chain:
WARNING: Nothing PROVIDES 'ffmpeg' (but .../mpv_0.41.0.bb DEPENDS on
or otherwise requires it)
ffmpeg was skipped: Has a restricted license 'commercial' ...
NOTE: Runtime target 'mpv' is unbuildable, removing...
Since mpv cannot be built or shipped without accepting ffmpeg's terms,
propagate the flag onto mpv itself. bitbake then skips mpv cleanly (in
both world and universe) with the same "restricted license" note as
ffmpeg, and no longer emits the confusing unbuildable-dependency
warnings. This mirrors how oe-core's gstreamer1.0-libav (which also
DEPENDS on ffmpeg) carries LICENSE_FLAGS = "commercial".
The explicit EXCLUDE_FROM_WORLD is now redundant - a recipe skipped for
its license flags is already excluded from world - so drop it.
Signed-off-by: Khem Raj <khem.raj@oss.qualcomm.com>
oe-core commit b980106560 ("lib/oe/kernel: Move python functions from
linux-kernel-base to library code") moved the kernel helpers out of
linux-kernel-base.bbclass into meta/lib/oe/kernel.py and renamed them from
get_kernelXXX to oe.kernel.get_XXX, so get_kernelversion_file no longer exists
and expanding KERNEL_VERSION raises NameError.
turbostat is COMPATIBLE_HOST x86 only, so this does not show up when parsing for
other architectures, but it breaks the same way as zabbix did.
Switch to the new name. The functions now live in the oe library, which is
always available in python expressions, so the linux-kernel-base inherit is no
longer needed -- it only exports KBUILD_BUILD_* now, which is of no use here,
and upstream intends to remove the class entirely.
Signed-off-by: Khem Raj <raj.khem@gmail.com>
oe-core commit b980106560 ("lib/oe/kernel: Move python functions from
linux-kernel-base to library code") moved the kernel helpers out of
linux-kernel-base.bbclass into meta/lib/oe/kernel.py and renamed them from
get_kernelXXX to oe.kernel.get_XXX. In-tree users were updated, out of tree
layers were not, so parsing now fails:
ExpansionError: Failure expanding variable KERNEL_VERSION, expression was
${@get_kernelversion_headers('.../work-shared/raspberrypi4-64/kernel-source')}
which triggered exception NameError: name 'get_kernelversion_headers' is not defined
The variable dependency chain for the failure is: KERNEL_VERSION -> do_configure
Switch to the new name. The functions now live in the oe library, which is
always available in python expressions, so the linux-kernel-base inherit is no
longer needed -- it only exports KBUILD_BUILD_* now, which is of no use here,
and upstream intends to remove the class entirely.
Signed-off-by: Khem Raj <raj.khem@gmail.com>
fwupd 2.1.7 fails to configure on every non-x86 machine:
../sources/fwupd-2.1.7/meson.build:288:68: ERROR: Feature hsi cannot be enabled
HSI (Host Security ID) has always been implemented for x86 only, but the way
meson.build enforces that changed in 2.1.x. 2.0.19 had:
hsi = get_option('hsi').disable_auto_if(host_machine.system() != 'linux').disable_auto_if(
host_cpu != 'x86' and host_cpu != 'x86_64'
).allowed()
while 2.1.7 has:
hsi = get_option('hsi').require(host_machine.system() == 'linux').require(
host_cpu in ['x86', 'x86_64']
).allowed()
disable_auto_if() only downgrades features that are set to 'auto', so passing
-Dhsi=enabled on e.g. aarch64 used to go through silently. require() is an
assertion, so the same option is now a hard error.
The recipe lists hsi unconditionally in the default PACKAGECONFIG and therefore
always passes -Dhsi=enabled. Restrict that to the architectures whose meson
cpu_family is x86 or x86_64. Non-x86 now gets -Dhsi=disabled, and require() on
an explicitly disabled feature is a no-op rather than an error.
PACKAGECONFIG[hsi] is left alone so it can still be requested explicitly.
Verified on qemuarm64 (do_configure now succeeds, meson reports "hsi: disabled",
recipe builds through to packaging) and on qemux86-64 (hsi remains in
PACKAGECONFIG, so the feature is unchanged where it is supported).
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Wang Mingyu
Khem Raj
Ross Burton
AshishKumar Mishra
Ankur Tyagi
Niko Mauno
Jaipaul Cheernam
Markus Volk
iwanicki92