Joshua Watt [Tue, 2 Jun 2020 13:42:05 +0000 (08:42 -0500)]
wic: Add --offset argument for partitions
Add support for an --offset argument when defining a partition. Many
SoCs require that boot partitions be located at specific offsets. Prior
to this argument, most WKS files were using the --align attribute to
specify the location of these fixed partitions but this is not ideal
because in the event that the partition couldn't be placed in the
specified location, wic would move it to the next sector with that
alignment, often preventing the device from booting. Unlike the --align
argument, wic will fail if a partition cannot be placed at the exact
offset specified with --offset.
Changes in V2:
* Fixed a small typo that prevented test_fixed_size_error from passing
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Hongxu Jia [Wed, 3 Jun 2020 06:55:31 +0000 (14:55 +0800)]
rpm: fix rpm -Kv xxx.rpm failed if signature header is larger than 64KB
Since commits [Place file signatures into the signature header where they
belong][1] applied, run `rpm -Kv **.rpm' failed if signature header
is larger than 64KB. Here are steps:
1) A unsigned rpm package, the size is 227560 bytes
$ ls -al xz-src-5.2.5-r0.corei7_64.rpm
-rw-------. 1 mockbuild 1000 227560 Jun 3 09:59
2) Sign the rpm package
$ rpmsign --addsign ... xz-src-5.2.5-r0.corei7_64.rpm
3) The size of signed rpm is 312208 bytes
$ ls -al xz-src-5.2.5-r0.corei7_64.rpm
-rw-------. 1 mockbuild 1000 312208 Jun 3 09:48
4) Run `rpm -Kv' failed with signature hdr data out of range
$ rpm -Kv xz-src-5.2.5-r0.corei7_64.rpm
xz-src-5.2.5-r0.corei7_64.rpm:
error: xz-src-5.2.5-r0.corei7_64.rpm: signature hdr data: BAD, no. of
bytes(88864) out of range
>From 1) and 3), the size of signed rpm package increased
312208 - 227560 = 84648, so the check of dl_max (64KB,65536)
is not enough.
As [1] said:
This also means the signature header can be MUCH bigger than ever
before,so bump up the limit (to 64MB, arbitrary something for now)
Jan Luebbe [Wed, 3 Jun 2020 08:12:37 +0000 (10:12 +0200)]
classes/buildhistory: capture package config
As the PACKAGECONFIG variable has a large influence on the resulting
package sizes and dependencies, it's useful to capture it in the
recipe-level buildhistory. This makes it straightforward to analyze the
impact of PACKAGECONFIG changes on the resulting image size.
Signed-off-by: Jan Luebbe <jlu@pengutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Andreas Müller [Tue, 2 Jun 2020 18:37:10 +0000 (20:37 +0200)]
vte: Pack ${libexecdir}/vte-urlencode-cwd to vte-prompt
Have vte-prompt in my images. Since upgrade 0.60.2 all terminals complain with:
| bash: /usr/libexec/vte-urlencode-cwd: No such file or directory
Grepping sources shows that vte.csh and vte.sh are the only callers of
vte-urlencode-cwd. Both are installed by vte-prompt so move vte-urlencode-cwd
where it's used.
Signed-off-by: Andreas Müller <schnitzeltony@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Ralph Siemsen [Tue, 2 Jun 2020 18:21:13 +0000 (14:21 -0400)]
cve-check: include epoch in product version output
In the generated cve.log files, include the epoch in the product
version. This better matches how versions are displayed elsewhere,
in particular the bb.warn("Found unpatched CVE...") that appears
on the terminal when CVEs are found.
Signed-off-by: Ralph Siemsen <ralph.siemsen@linaro.org> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
which can only be caused by the qemu.stop() method not being called.
Tweak the error handling to fix the blanket exception handler which
is likely meaning this function isn't getting called.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
cairo: Do not try to remove nonexistent directories
Commit 0e1f8fa0 (bitbake.conf: propagate 'opengl' DISTRO_FEATURE to
native/nativesdk from target) changed the default PACKAGECONFIG for
native and nativesdk so that it becomes empty unless "x11" is in
DISTRO_FEATURES since "trace" was also removed (propbably
unintentionally). This highlighted than an empty PACKAGECONFIG would
lead to a build failure since /usr/bin is never created under these
conditions, but the recipe still tried to remove it.
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Konrad Weihmann [Sun, 31 May 2020 20:57:48 +0000 (22:57 +0200)]
sysfsutils: rem leftover settings for libsysfs-dev
22af6a2595dbec98ce4a2e3b1324ad8d400390ad removed the PACKAGES
setting, but left the FILES-assignments of libsysfs-dev and -staticdev.
As these have no use anymore they can be safely removed
Signed-off-by: Konrad Weihmann <kweihmann@outlook.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
License-Update: http changed to https Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Replace pcre-cross.patch with the (default) option
to use pre-built tables; the README says it's ok, and
recommended in cross-compile situations. The option
was in the recipe from the start and neither the commit
that adds the recipe, nor the patch to make it work explain
why.
License-Update: copyright years Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
License-Update: copyright years Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
License-Update: copyright years, formatting Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
License-Update: additional copyright statements, all BSD Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* With the missing Subject line fixed in GitApplyTree.prepareCommit()
we should be able to revert, the fix which was trying to help it by
parsing GitApplyTree.patch_line_prefix ("%% original patch:") also
from Subject line, now GitApplyTree.patch_line_prefix should always
end on separate line which is then skipped when copying the lines to
resulting patch, see original commit message from Paul:
lib/oe/patch: fix handling of patches with no header
If a patch applied by a recipe has no header and we turn the recipe's
source into a git tree (when PATCHTOOL = "git" or when using devtool
extract / modify / upgrade), the commit message ends up consisting only
of the original filename marker ("%% original patch: filename.patch").
When we come to do turn the commits back into a set of patches in
extractPatches(), this first line ends up in the "Subject: " part of
the file, but we were ignoring it because the line didn't start with the
marker text. The end result was we weren't able to get the original
patch name. Strip off any "Subject [PATCH x/y]" part before looking for
the marker text to fix.
This caused "devtool modify openssl" followed by "devtool update-recipe
openssl" (without any changes in-between) to remove version-script.patch
because that patch has no header and we weren't able to determine the
original filename.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Martin Jansa [Fri, 29 May 2020 22:03:26 +0000 (00:03 +0200)]
lib/oe/patch: GitApplyTree: save 1 echo in commit-msg hook
* also remove the extra blank lines which is often added to patches
when refreshed with devtool (GitApplyTree.patch_line_prefix lines
are ignored when refreshing .patch files, but newly added blank
lines aren't - the leading blank line wasneeded for patches with
just the subject line (to prevent the GitApplyTree.patch_line_prefix
line ending appended to the commit summary), but we can add it
in prepareCommit instead
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Martin Jansa [Fri, 29 May 2020 22:03:25 +0000 (00:03 +0200)]
lib/oe/patch: prevent applying patches without any subject
* this was discovered with
$ devtool finish --force-patch-refresh
where it was removing some patches and replacing them with
patch in filename called "patch:"
e.g. this .patch file:
https://github.com/OSSystems/meta-browser/blob/311067d2d8a50cee5c836892606444f63f2bb3ab/dynamic-layers/rust-layer/recipes-browser/firefox/firefox/fixes/fix-camera-permission-dialg-doesnot-close.patch
confuses devtool which results to create new .patch file called "patch:"
$ devtool finish --force-patch-refresh firefox meta-browser
NOTE: Starting bitbake server...
WARNING: Host distribution "ubuntu-20.04" has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution.
Loading cache: 100% |###################################################################################################################################################################################################################################| Time: 0:00:00
Loaded 2480 entries from dependency cache.
Parsing recipes: 100% |#################################################################################################################################################################################################################################| Time: 0:00:00
Parsing of 1718 .bb files complete (1717 cached, 1 parsed). 2480 targets, 68 skipped, 0 masked, 0 errors.
Summary: There was 1 WARNING message shown.
INFO: Updating patch 0001-Bug-1554949-Fix-WebRTC-build-failure-with-newer-linu.patch
...
INFO: Updating patch pre-generated-old-configure.patch
INFO: Adding new patch patch:
INFO: Updating recipe firefox_68.0esr.bb
INFO: Removing file /OE/build/test-oe-build-time/poky/meta-browser/dynamic-layers/rust-layer/recipes-browser/firefox/firefox/fixes/fix-camera-permission-dialg-doesnot-close.patch
INFO: Cleaning sysroot for recipe firefox...
INFO: Leaving source tree /OE/build/test-oe-build-time/poky/build/workspace/sources/firefox as-is; if you no longer need it then please delete it manually
this looked like incorrect parsing of the git format-patch
files exported from workspace/sources (the git format-patch
version of fix-camera-permission-dialg-doesnot-close.patch
starts like this:
$ head 0008-original-patch-fix-camera-permission-dialg-doesnot-c.patch
From 37dfa11961b48024bedcfb9336f49107c9535638 Mon Sep 17 00:00:00 2001
From: Takuro Ashie <ashie@clear-code.com>
Date: Mon, 20 Aug 2018 10:16:20 +0900
Subject: [PATCH 08/34] %% original patch:
fix-camera-permission-dialg-doesnot-close.patch
so first I've modified GitApplyTree.extractPatches() to be able to
parse the original patch name correctly even in this case where subject
is wrapped, but then it still wasn't right, because we ended with
correctly named .patch file, but all we could use for Subject line
was the name of the original .patch file (instead of the Subject
from metadata commit which introduced this .patch files as some other
.patch files get when refreshed with devtool.
In the end the issue happens even sooner in GitApplyTree.prepareCommit()
where it correctly found the Subject from metadata commit, but then
didn't apply it when there weren't any other outlines from patch headers.
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Martin Jansa [Fri, 29 May 2020 22:03:23 +0000 (00:03 +0200)]
devtool: use -f and don't use --exclude-standard when adding files to workspace
* I see a case where a tarball contains .gitignore and bunch of files
which are normally ignored in git, but still included in the tarball
(e.g. configure script next to configure.ac)
* when devtool is creating a git repo in workspace it won't include these
files from tarball in the initial devtool-base commit, because
git ls-files won't list them
* but then the first .patch file (without git headers) when applied with
GitApplyTree._applypatch() will add all these still ignored files to a
commit which used to only modify some files, because it's using -f:
# Add all files
shellcmd = ["git", "add", "-f", "-A", "."]
output += runcmd(["sh", "-c", " ".join(shellcmd)], self.dir)
at least in this case it would be better to add all ignored files in
the initial devtool-base commit and then --force-patch-refresh will just
include the small modification as before instead of adding unrelated
files, just because they were initially ignored - this behavior will
also match with the do_patch task in the actual build where the
.gitignore is ignored when unpacking some tarball
* my use-case is fixed in setup_git_repo, but similar function is in
devtool upgrade, I've changed it there as well
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Khem Raj [Tue, 26 May 2020 23:10:37 +0000 (16:10 -0700)]
armv8/tunes: Set TUNE_PKGARCH_64 based on ARMPKGARCH
The setting is to modify TUNE_PKGARCH which is filled with
TUNE_PKGARCH_64 or TUNE_PKGARCH_32 in arm-arch64.inc
This lets higher up tune files for arm64 SOCs override them if needed,
this can help building multiple armv8 machines with different tunes in
same workspace.
No need to set TUNE_PKGARCH in tune files as it is synthesized from ARMPKGARCH
Add ARMPKGARCH for aarch64 tunes
Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
