Re: [OE-core] Recent runqueue changes destablized hardknott release for multiconfig builds
On 2021-05-17 10:57 a.m., akuster808 wrote: > > > On 5/17/21 10:29 AM, Scott Branden via lists.openembedded.org wrote: >> I tried updating to the latest hardknott and various multiconfig builds now >> fail. >> >> I had to revert the following changes to get back to a stable build: >> Revert "bitbake: runqueue: Handle deferred task rehashing in multiconfig >> builds" >> >> >> >> This reverts commit 58cbdaecf75b0248f96780b6882e8d4f232d038a. >> >> >> and >> >> Revert "bitbake: runqueue: Fix multiconfig deferred task sstate validity >> caching issue" >> >> >> >> This reverts commit 8aad4c243a542c8720cd23b6d1c4267916393df3. >> >> Also note; I see other changes sitting in master-next attempting to fix >> runqueue and multiconfig issues. >> So I tried cherry-picking and still have build issues. > > Can you provide more info like error messages or even a way to reproduce > this? To reproduce we build with no yocto-cache populated. Here is the start of the error messages with hardknott: Sat May 8 21:08:05 2021: ERROR: mc:valkyrie:initramfs-framework-1.0-r4 do_deploy_archives_setscene: No suitable staging package found Sat May 8 21:08:05 2021: NOTE: recipe initramfs-framework-1.0-r4: task do_package_qa_setscene: Started Sat May 8 21:08:05 2021: ERROR: Logfile of failure stored in: /tmp/yocto_builds/20630387_vxc_valkyrie-genericx86-64/poky/build/tmp-valkyrie/work/all-poky-linux/initramfs-framework/1.0-r4/temp/log.do_deploy_archives_setscene.78226 Sat May 8 21:08:05 2021: NOTE: recipe initramfs-framework-1.0-r4: task do_deploy_archives_setscene: Failed Sat May 8 21:08:05 2021: ERROR: mc:valkyrie:initramfs-framework-1.0-r4 do_package_qa_setscene: No suitable staging package found Sat May 8 21:08:05 2021: ERROR: Logfile of failure stored in: /tmp/yocto_builds/20630387_vxc_valkyrie-genericx86-64/poky/build/tmp-valkyrie/work/all-poky-linux/initramfs-framework/1.0-r4/temp/log.do_package_qa_setscene.78235 Sat May 8 21:08:05 2021: NOTE: recipe initramfs-framework-1.0-r4: task do_package_qa_setscene: Failed Sat May 8 21:08:05 2021: WARNING: Setscene task (mc:valkyrie:/tmp/yocto_builds/20630387_vxc_valkyrie-genericx86-64/poky/build/../meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb:do_deploy_archives_setscene) failed with exit code '1' - real task will be run instead Sat May 8 21:08:05 2021: NOTE: Running setscene task 4875 of 5643 (mc:valkyrie:/tmp/yocto_builds/20630387_vxc_valkyrie-genericx86-64/poky/build/../meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb:do_package_write_rpm_setscene) Sat May 8 21:08:05 2021: WARNING: Setscene task (mc:valkyrie:/tmp/yocto_builds/20630387_vxc_valkyrie-genericx86-64/poky/build/../meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb:do_package_qa_setscene) failed with exit code '1' - real task will be run instead Sat May 8 21:08:05 2021: NOTE: recipe initramfs-framework-1.0-r4: task do_populate_sysroot_setscene: Started Sat May 8 21:08:05 2021: NOTE: recipe update-rc.d-0.8-r0: task do_deploy_archives_setscene: Started Sat May 8 21:08:05 2021: NOTE: recipe initramfs-framework-1.0-r4: task do_populate_lic_setscene: Started Sat May 8 21:08:05 2021: NOTE: recipe netbase-1_6.2-r0: task do_package_qa_setscene: Started Sat May 8 21:08:05 2021: ERROR: mc:valkyrie:update-rc.d-0.8-r0 do_deploy_archives_setscene: No suitable staging package found Sat May 8 21:08:05 2021: ERROR: Logfile of failure stored in: /tmp/yocto_builds/20630387_vxc_valkyrie-genericx86-64/poky/build/tmp-valkyrie/work/all-poky-linux/update-rc.d/0.8-r0/temp/log.do_deploy_archives_setscene.78309 Sat May 8 21:08:05 2021: NOTE: recipe update-rc.d-0.8-r0: task do_deploy_archives_setscene: Failed Sat May 8 21:08:05 2021: NOTE: recipe netbase-1_6.2-r0: task do_deploy_archives_setscene: Started ... (see full log) > > -armin >> >> Regards, >> Scott >> >> >> > smime.p7s Description: S/MIME Cryptographic Signature -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#151986): https://lists.openembedded.org/g/openembedded-core/message/151986 Mute This Topic: https://lists.openembedded.org/mt/82892551/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] Recent runqueue changes destablized hardknott release for multiconfig builds
I tried updating to the latest hardknott and various multiconfig builds now fail. I had to revert the following changes to get back to a stable build: Revert "bitbake: runqueue: Handle deferred task rehashing in multiconfig builds" This reverts commit 58cbdaecf75b0248f96780b6882e8d4f232d038a. and Revert "bitbake: runqueue: Fix multiconfig deferred task sstate validity caching issue" This reverts commit 8aad4c243a542c8720cd23b6d1c4267916393df3. Also note; I see other changes sitting in master-next attempting to fix runqueue and multiconfig issues. So I tried cherry-picking and still have build issues. Regards, Scott smime.p7s Description: S/MIME Cryptographic Signature -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#151983): https://lists.openembedded.org/g/openembedded-core/message/151983 Mute This Topic: https://lists.openembedded.org/mt/82892551/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] util-linux-uuid: include /usr/lib/debug in FILES_util-linux-libuuid-dbg
I can confirm this patch fixes the QA problem I reported.
On 2021-03-24 10:07 a.m., luca.bocca...@gmail.com wrote:
> From: Luca Boccassi
>
> Apparently some users have /usr/lib/debug instead of /usr/lib/.debug
> so add it to the FILES matching.
>
> Signed-off-by: Luca Boccassi
> ---
> meta/recipes-core/util-linux/util-linux-uuid_2.36.2.bb | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-core/util-linux/util-linux-uuid_2.36.2.bb
> b/meta/recipes-core/util-linux/util-linux-uuid_2.36.2.bb
> index 65e4d23b7e..1ff37a4dcb 100644
> --- a/meta/recipes-core/util-linux/util-linux-uuid_2.36.2.bb
> +++ b/meta/recipes-core/util-linux/util-linux-uuid_2.36.2.bb
> @@ -11,7 +11,7 @@ PACKAGES = "util-linux-libuuid util-linux-libuuid-dev
> util-linux-libuuid-staticd
> FILES_util-linux-libuuid = "${libdir}/libuuid.so.*"
> FILES_util-linux-libuuid-dev = "${libdir}/libuuid.so ${includedir}
> ${libdir}/pkgconfig"
> FILES_util-linux-libuuid-staticdev = "${libdir}/libuuid.a"
> -FILES_util-linux-libuuid-dbg = "/usr/src ${libdir}/.debug"
> +FILES_util-linux-libuuid-dbg = "/usr/src ${libdir}/.debug ${libdir}/debug"
>
> do_install_append() {
> rm -rf ${D}${datadir} ${D}${bindir} ${D}${base_bindir} ${D}${sbindir}
> ${D}${base_sbindir} ${D}${exec_prefix}/sbin
>
smime.p7s
Description: S/MIME Cryptographic Signature
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149904):
https://lists.openembedded.org/g/openembedded-core/message/149904
Mute This Topic: https://lists.openembedded.org/mt/81582206/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v11] util-linux: split uuid in separate recipe to allow bootstrapping
I have not debugged yet, but I suspect this change is causing the following failure if I merge the latest poky into our builds: ERROR: mc:host:util-linux-uuid-2.36.2-r0 do_package: QA Issue: util-linux-uuid: Files/directories were installed but not shipped in any package: /usr/lib/debug /usr/lib/debug/usr /usr/lib/debug/usr/lib /usr/lib/debug/usr/lib/libuuid.so.1.3.0.debug Please set FILES such that these items are packaged. Alternatively if they are unneeded, avoid installing them or delete them within do_install. util-linux-uuid: 4 installed and not shipped files. [installed-vs-shipped] ERROR: mc:host:util-linux-uuid-2.36.2-r0 do_package: Fatal QA errors found, failing task. ERROR: Logfile of failure stored in: /hdd/yocto/genx/poky/build/tmp/work/core2-64-poky-linux/util-linux-uuid/2.36.2-r0/temp/log.do_package.31753 ERROR: Task (mc:host:/hdd/yocto/genx/poky/build/../meta/recipes-core/util-linux/util-linux-uuid_2.36.2.bb:do_package) failed with exit code '1' On 2021-03-15 2:51 p.m., Richard Purdie wrote: > On Mon, 2021-03-15 at 13:57 +, Richard Purdie via lists.openembedded.org > wrote: >> On Mon, 2021-03-15 at 14:55 +0100, Martin Jansa wrote: >>> On Mon, Mar 15, 2021 at 12:21:37PM +, Richard Purdie wrote: On Mon, 2021-03-15 at 11:50 +, Luca Boccassi wrote: > On Mon, 2021-03-15 at 10:49 +, Richard Purdie wrote: >> On Mon, 2021-03-15 at 10:44 +, Luca Boccassi wrote: >>> On Sun, 2021-03-14 at 22:10 +, Richard Purdie wrote: On Thu, 2021-03-11 at 15:09 +, luca.bocca...@gmail.com wrote: > From: Luca Boccassi > > Recently util-linux gained an (optional) build dependency on > libcryptsetup. > But libcryptsetup build-depends on util-linux for blkid (optional, > can be disabled) > and uuid (mandatory). > Split out util-linux-uuid in a different recipe to break the cycle. > > https://github.com/karelzak/util-linux/pull/898 > > Signed-off-by: Luca Boccassi Unfortunately I noticed we had a performance regression in buildtimes in recent changes. The closest I have this narrowed down to so far: https://autobuilder.yocto.io/pub/non-release/20210314-14/testresults/buildperf-ubuntu1604/perf-ubuntu1604_master_20210314181831_d42487bf52.html suggests it may be this change. I have more tests queued to confirm that definitively, if so we'll have to figure out why as this shouldn't really happen, its an 8% regression :(. >>> >>> Very strange that a single recipe could do that - is there something >>> wrong in the new .bb that I missed and could cause this? >> >> I'm wondering if it is because we're building util-linux twice now and >> there is some key choke point in the dependency chain. I have no evidence >> for that yet, it is just speculation though. > > With the autoconf options I've set, on my laptop it takes 32s to do > configure + make -j2. Most of that is autoconf - make -j2 takes 8s. > > Only 3 libraries are built with this combination: libcommon.a, > libtcolors.a, and libuuid.a/so. No executables or anything else is > built. It doesn't look like libtcolors is actually needed, I'll see if > I can prepare a patch to skip it, but I don't think it will buy more > than 1s, it's just two object files. > > The good news is that meson support is about to land upstream, which > should be significantly faster than autoconf + make: > > https://github.com/karelzak/util-linux/commits/topic/meson Meson definitely improves the speed! I was wondering if it was from configure for example. I now have more performance test results in (takes time to interleave them with testing of master): https://autobuilder.yocto.io/pub/non-release/20210315-1/testresults/buildperf-ubuntu1604/perf-ubuntu1604_master_20210315005048_6bb1621815.html and I think this means it isn't from the util-linux change but one of another three. I'm not entirely convinced those changes could do this but it is what the data says. I've queued more bisection to narrow it down from there... >>> >>> BTW: this split also needs manual cleanup in the TMPDIR, right? >> >> It shouldn't. The system should spot that util-linux has changed and >> uninstall >> it from the sysroots as it goes. There is something not working right there >> :( > > I was wrong about that, the system doesn't have code for this, it has code for > the sysroots but not for other sstate tasks. > > I think this is an oversight and we need to simplify things and make this > cleanup > happen pre-build, much like the "unreachable" tasks cleanup happens today. If > we > do make this happen, we probably need to add parallelism as the number of > stale > sstate tasks being cleaned could be
Re: [OE-core] unwanted linux kernel image added to /boot directory
It appears that inherit of the kernel_do_install routine is called which causes
the linux
image to be installed in /boot. I added a quick and dirty hack to inhibit this
behaviour.
Could someone please comment on a proper solution:
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index ddff2ddcd2..527f6ca85d 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -428,7 +428,9 @@ kernel_do_install() {
for imageType in ${KERNEL_IMAGETYPES} ; do
if [ $imageType != "fitImage" ] || [
"${INITRAMFS_IMAGE_BUNDLE}" != "1" ] ; then
- install -m 0644 ${KERNEL_OUTPUT_DIR}/$imageType
${D}/${KERNEL_IMAGEDEST}/$imageType-${KERNEL_VERSION}
+ if [ "${INHIBIT_IMAGE_IN_BOOT}" != "1" ] ; then
+ install -m 0644 ${KERNEL_OUTPUT_DIR}/$imageType
${D}/${KERNEL_IMAGEDEST}/$imageType-${KERNEL_VERSION}
+ fi
fi
done
On 2021-03-15 4:39 p.m., Scott Branden via lists.openembedded.org wrote:
> Hello,
>
> There seems to be a problem when a kernel module is added to an initramfs
> image.
>
> As soon as I add a recipe which installs an external kernel module into an
> initramfs image it automatically installs the linux kernel image in a /boot
> directory.
>
> This is really bad as it increases the size of the initramfs image.
>
> /boot/Image should not be installed in the image when an external kernel
> module is added to an image.
>
> Can someone suggest a fix to this issue?
>
> Thanks,
> Scott
>
>
>
>
>
smime.p7s
Description: S/MIME Cryptographic Signature
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149549):
https://lists.openembedded.org/g/openembedded-core/message/149549
Mute This Topic: https://lists.openembedded.org/mt/81364677/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] unwanted linux kernel image added to /boot directory
Hello, There seems to be a problem when a kernel module is added to an initramfs image. As soon as I add a recipe which installs an external kernel module into an initramfs image it automatically installs the linux kernel image in a /boot directory. This is really bad as it increases the size of the initramfs image. /boot/Image should not be installed in the image when an external kernel module is added to an image. Can someone suggest a fix to this issue? Thanks, Scott smime.p7s Description: S/MIME Cryptographic Signature -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#149543): https://lists.openembedded.org/g/openembedded-core/message/149543 Mute This Topic: https://lists.openembedded.org/mt/81364677/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core][PATCH] ffmpeg: add ptest install for ffmpeg
Thanks for the work on this Suji. We can now buidl and test ffmpeg using FATE
in yocto.
On 2021-02-22 5:17 p.m., suji.velupil...@broadcom.com wrote:
> From: Suji Velupillai
>
> [YOCTO #5605] Add ptest for ffmpeg
>
> ffmpeg fate test requires full source code and copy of test suite
> data to run the full test. Test data is over 1GB thus cannot be
> included within Yocto. But it can be mounted on the target during
> the test or fate test can run limited tests without test suite
> data as well.
>
> Add ptest install such that it will only copy ffmpeg source code
> to the target image. The run-ptest script gets necessary
> configuration information from the shell environment variables
> at run time, which must be set prior to running the test.
>
> FATEWORKDIR - working directory to run fate testing,
> full test with samples requires about 6GB
> FATECONFIG - ffmpeg config options for fate
> FATESAMPLES - fate test suite samples directory, optional,
> but required for full test
> FATEIGNORE_TESTS - list of tests to ignore during fate testing
> FATECLEANUP - set to 1 to cleanup fate compile and install
> directories after testing
>
> Signed-off-by: Suji Velupillai
Acked-by: Scott Branden
> ---
> .../ffmpeg/ffmpeg/run-ptest | 130 ++
> .../recipes-multimedia/ffmpeg/ffmpeg_4.3.1.bb | 16 ++-
> 2 files changed, 145 insertions(+), 1 deletion(-)
> create mode 100644 meta/recipes-multimedia/ffmpeg/ffmpeg/run-ptest
>
> diff --git a/meta/recipes-multimedia/ffmpeg/ffmpeg/run-ptest
> b/meta/recipes-multimedia/ffmpeg/ffmpeg/run-ptest
> new file mode 100644
> index 00..ee866a58b2
> --- /dev/null
> +++ b/meta/recipes-multimedia/ffmpeg/ffmpeg/run-ptest
> @@ -0,0 +1,130 @@
> +#!/bin/sh
> +
> +# Following can be set in the environment to overwrite
> +# FATEWORKDIR - working directory for the fate test, needs about 6GB
> +# FATECONFIG - ffmpeg config options
> +# FATESAMPLES - fate test suite samples directory
> +# FATEIGNORE_TESTS - tests to ignore during fate test run (comma separated)
> +# FATECLEANUP - set to 0 or 1 (default) to clean up after fate test
> +
> +# Following variables are set during Yocto build time
> +VERSION=""
> +FATECONFIG_DEFAULT=""
> +
> +CLEANUP_DEFAULT=1
> +make=make
> +src="$(dirname $(readlink -f $0))"
> +
> +echo "-"
> +echo "ffmpeg fate test env config info: "
> +echo " workdir : [${FATEWORKDIR}]"
> +echo " config: [${FATECONFIG}]"
> +echo " config_default: [${FATECONFIG_DEFAULT}]"
> +echo " samplesdir: [${FATESAMPLES}]"
> +echo " ignore tests : [${FATEIGNORE_TESTS}]"
> +echo " clean up : [${FATECLEANUP}]"
> +echo "-"
> +
> +die() {
> + echo "$@"
> + echo "ffmpeg fate: FAILED"
> + exit 1
> +}
> +
> +lock() {
> + lock=$1/fate.lock
> + (set -C; exec >$lock) 2>/dev/null || return
> + trap 'rm $lock' EXIT
> +}
> +
> +prep_test_vector() {
> + # If samples directory not provided, run the fate without samples.
> + # In this case, limited test warning printed out to report by fate test.
> + test -f "${FATESAMPLES}/md5sum" || FATESAMPLES=""
> +}
> +
> +prep_work_space() {
> + test -z ${FATEWORKDIR} && die "Error: empty workdir: ${FATEWORKDIR}"
> + test -d ${FATEWORKDIR} || die "Error: invalid workdir: ${FATEWORKDIR}"
> + cd ${FATEWORKDIR}
> + mkdir -p fatetest
> + FATEWORKDIR+="/fatetest"
> +}
> +
> +check_version() {
> + # if version is not set then try to get the version from src
> + [ -z "${VERSION}" ] && VERSION=$(${src}/ffbuild/version.sh ${src})
> +}
> +
> +configure() {
> + cd ${build} || return
> +
> + ${src}/configure \
> + --prefix="${install}" \
> + ${FATESAMPLES:+--samples="$FATESAMPLES"} \
> + ${FATEIGNORE_TESTS:+--ignore-tests="$FATEIGNORE_TESTS"} \
> + ${FATECONFIG_DEFAULT:+$FATECONFIG_DEFAULT} \
> + ${FATECONFIG:+$FATECONFIG}
> +}
> +
> +compile() {
> + cd ${build} || return
> + ${make} && ${make} install
> +}
> +
> +fate() {
> + cd ${build} || return
> + ${make} fate
> +}
> +
> +report() {
> + date=$(date -u +%Y%m%d%H%M%S)
> + echo "fate:1:${date}:${VERSION}:$1:$2" >${FATEWORKDIR}/report
> + cat ${build}/ffbuild/config.fate >>${FATEWORKDIR}/report
> + cat ${build}/tests/data/fate/*.rep >>${FATEWORKDIR}/report 2>/dev/null ||
> \
> + for i in ${build}/tests/data/fate/*.rep ; do cat "$i"
> >>${FATEWORKDIR}/report 2>/dev/null; done
> + echo "fate test logs are in [${FATEWORKDIR}]"
> +}
> +
> +clean() {
> + [ -z "${FATECLEANUP}" ] && FATECLEANUP=${CLEANUP_DEFAULT}
> + if [[ "${FATECLEANUP}" -eq 1 ]]; then
> + echo "Cleaning up fate build and install directories"
> + rm -rf ${build} ${install}
> + fi
> +}
> +
> +fail() {
> +report "$@"
> +clean
> +echo "ffmpeg fate: FAILED"
> +exit 1
> +}
> +
> +prep_work_space
>
Re: [OE-core] [PATCH] externalsrc: Detect code changes in submodules
This patch, now integrated in master branch of poky, appears to also fix
this yocto bug:
"Bug 13748 - bitbake doesn't detect changes in code to run do_compile
when using devtool modify on recipe with destsuffix"
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13748
On 2021-01-27 12:33 a.m., Tomasz Dziendzielski wrote:
The srctree_hash was calculated only from main source directory ignoring
changes in submodules.
[YOCTO #13748]
Use submodule--helper to determine all submodules, and calculate hash
from all git tree objects names combined.
Signed-off-by: Tomasz Dziendzielski
---
meta/classes/externalsrc.bbclass | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/meta/classes/externalsrc.bbclass b/meta/classes/externalsrc.bbclass
index 7a7d31e311..64e94e3301 100644
--- a/meta/classes/externalsrc.bbclass
+++ b/meta/classes/externalsrc.bbclass
@@ -190,6 +190,7 @@ def srctree_hash_files(d, srcdir=None):
import shutil
import subprocess
import tempfile
+import hashlib
s_dir = srcdir or d.getVar('EXTERNALSRC')
git_dir = None
@@ -214,7 +215,16 @@ def srctree_hash_files(d, srcdir=None):
env = os.environ.copy()
env['GIT_INDEX_FILE'] = tmp_index.name
subprocess.check_output(['git', 'add', '-A', '.'], cwd=s_dir,
env=env)
-sha1 = subprocess.check_output(['git', 'write-tree'], cwd=s_dir,
env=env).decode("utf-8")
+git_sha1 = subprocess.check_output(['git', 'write-tree'], cwd=s_dir,
env=env).decode("utf-8")
+submodule_helper = subprocess.check_output(['git', 'submodule--helper',
'list'], cwd=s_dir, env=env).decode("utf-8")
+for line in submodule_helper.splitlines():
+module_dir = os.path.join(s_dir, line.rsplit(maxsplit=1)[1])
+proc = subprocess.Popen(['git', 'add', '-A', '.'],
cwd=module_dir, env=env, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)
+proc.communicate()
+proc = subprocess.Popen(['git', 'write-tree'], cwd=module_dir,
env=env, stdout=subprocess.PIPE, stderr=subprocess.DEVNULL)
+stdout, _ = proc.communicate()
+git_sha1 += stdout.decode("utf-8")
+sha1 = hashlib.sha1(git_sha1.encode("utf-8")).hexdigest()
with open(oe_hash_file, 'w') as fobj:
fobj.write(sha1)
ret = oe_hash_file + ':True'
smime.p7s
Description: S/MIME Cryptographic Signature
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#147719):
https://lists.openembedded.org/g/openembedded-core/message/147719
Mute This Topic: https://lists.openembedded.org/mt/80152944/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] kmod: update 27 -> 28
Upgrade kmod from 27 to 28. Signed-off-by: Scott Branden --- meta/recipes-kernel/kmod/kmod.inc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/recipes-kernel/kmod/kmod.inc b/meta/recipes-kernel/kmod/kmod.inc index dabda2d57e..ccda9f2b73 100644 --- a/meta/recipes-kernel/kmod/kmod.inc +++ b/meta/recipes-kernel/kmod/kmod.inc @@ -15,9 +15,9 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=a6f89e2100d9b6cdffcea4f398e37343 \ " inherit autotools gtk-doc pkgconfig manpages -SRCREV = "819a125ca756003dce2d11624035b7fb605a8e99" +SRCREV = "1ccfe994287119cc6cef37a7ca4c529d89de4b95" # Lookout for PV bump too when SRCREV is changed -PV = "27" +PV = "28" SRC_URI = "git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git \ file://depmod-search.conf \ -- 2.17.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#146665): https://lists.openembedded.org/g/openembedded-core/message/146665 Mute This Topic: https://lists.openembedded.org/mt/79665195/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] commit breaks menuconfig on upstream kernel "cml1.bbclass: Handle ncurses-native being available via pkg-config"
Could we have the commit reverted if a fix is not imminent?
On 2020-12-03 10:22 p.m., Nathan Rossi wrote:
> On Fri, 4 Dec 2020 at 14:58, Richard Purdie
> wrote:
>> On Fri, 2020-12-04 at 10:53 +1000, Nathan Rossi wrote:
>>> On Fri, 4 Dec 2020 at 08:31, Andrey Zhizhikin
>>> wrote:
>>>> Hello Scott and Nathan,
>>>>
>>>> On Thu, Dec 3, 2020 at 7:18 PM Scott Branden via
>>>> lists.openembedded.org
>>>> wrote:
>>>>>
>>>>> On 2020-12-02 4:19 p.m., Nathan Rossi wrote:
>>>>>> On Thu, 3 Dec 2020 at 05:17, Scott Branden <
>>>>>> scott.bran...@broadcom.com> wrote:
>>>>>>> Hi Nathan,
>>>>>>>
>>>>>>> Your commit:
>>>>>>> "cml1.bbclass: Handle ncurses-native being available via pkg-
>>>>>>> config"
>>>>>>> https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=master-next=ce447d70df386ca55ce1672478b245851556374e
>>>>>>>
>>>>>>> breaks bitbake menuconfig when using the upstream kernel.
>>>>>> Interesting. The purpose of the commit was to actually fix that
>>>>>> exact
>>>>>> use case since previously the mainline kernel menuconfig was
>>>>>> relying
>>>>>> on hardcoded paths to the host ncurses libraries.
>>>>>>
>>>>>> Would you be able to provide the error messages you are getting
>>>>>> (and
>>>>>> anything else that can help to reproduce the failure), because
>>>>>> I am
>>>>>> not able to reproduce any failures with a mainline kernel,
>>>>>> linux-yocto
>>>>>> (with and without the below mention patch) or with other
>>>>>> projects that
>>>>>> are using cml1 (e.g. u-boot).
>>>>>>
>>>>>>> It only works with the linux-yocto kernel due to this
>>>>>>> workaround which is not upstream.
>>>>>>> If you revert this commit in linux-yocto menuconfig will not
>>>>>>> work in linux-yocto:
>>>>>>> "menuconfig,mconf-cfg: Allow specification of ncurses
>>>>>>> location"
>>>>>>> https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/commit/scripts/kconfig/mconf-cfg.sh?h=v5.8/standard/base=1714a5ad9cf61f4d0f4b8432f327cca2998aba77
>>>>>> This change should not be required to have menuconfig working
>>>>>> when
>>>>>> pkg-config is used.
>>>>>>
>>>>>>> Seems like your commit needs to be reverted or a change made
>>>>>>> to work with the upstream kernel.
>>>>>>> Or, the linux-yocto change needs to actually be
>>>>>>> upstreamed. I submitted it and the upstream maintainer
>>>>>>> questioned why the change is needed:
>>>>>>> https://lore.kernel.org/lkml/cak7lnatd0j3c_mfrxaju8-wmdcmrpmrfn7um0yebnfl-_zc...@mail.gmail.com/
>>>>>> The problem is if it was accepted, every kernel prior to its
>>>>>> inclusion
>>>>>> would need to be patched, as well as other projects (u-boot,
>>>>>> busybox).
>>>>>> This makes supporting menuconfig using that change for kconfig
>>>>>> generically problematic. This is why the pkg-config solution is
>>>>>> preferable.
>>>> As I've already said before I had similar issues with doing
>>>> menuconfig
>>>> kernel task. I took a deeper look and actually found out that the
>>>> recipe-sysroot-native/usr/lib/pkgconfig/ncursesw.pc in the kernel
>>>> recipe build folder contained the absolute path to the ld, which
>>>> for
>>>> me was taken from the SSTATE_MIRROR produced on the CI system.
>>>>
>>>> The string inside ncursesw.pc looked like this (note the -Wl,
>>>> --dynamic-linker):
>>>> Libs: -L${pcfiledir}/../../../usr/lib -Wl,--enable-new-dtags
>>>> -Wl,-rpath-link,${pcfiledir}/../../../usr/lib
>>>> -Wl,-rpath-link,${pcfiledir}/../../../lib
>>>> -Wl,-rpath,${pcfiledir}/../../../usr/lib
>>>> -Wl,-rpath,${pcfiledir}/../../../lib -Wl,-O1
>>>> -Wl,--allow-shlib-undefined
>>>> -Wl,--dynamic-linker=/teamcity/work/c3acfc3a6f255dcb/build-
>>>> output/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2
>>
Re: [OE-core] commit breaks menuconfig on upstream kernel "cml1.bbclass: Handle ncurses-native being available via pkg-config"
On 2020-12-02 4:19 p.m., Nathan Rossi wrote: > On Thu, 3 Dec 2020 at 05:17, Scott Branden wrote: >> Hi Nathan, >> >> Your commit: >> "cml1.bbclass: Handle ncurses-native being available via pkg-config" >> https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=master-next=ce447d70df386ca55ce1672478b245851556374e >> >> breaks bitbake menuconfig when using the upstream kernel. > Interesting. The purpose of the commit was to actually fix that exact > use case since previously the mainline kernel menuconfig was relying > on hardcoded paths to the host ncurses libraries. > > Would you be able to provide the error messages you are getting (and > anything else that can help to reproduce the failure), because I am > not able to reproduce any failures with a mainline kernel, linux-yocto > (with and without the below mention patch) or with other projects that > are using cml1 (e.g. u-boot). > >> It only works with the linux-yocto kernel due to this workaround which is >> not upstream. >> If you revert this commit in linux-yocto menuconfig will not work in >> linux-yocto: >> "menuconfig,mconf-cfg: Allow specification of ncurses location" >> https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/commit/scripts/kconfig/mconf-cfg.sh?h=v5.8/standard/base=1714a5ad9cf61f4d0f4b8432f327cca2998aba77 > This change should not be required to have menuconfig working when > pkg-config is used. > >> >> Seems like your commit needs to be reverted or a change made to work with >> the upstream kernel. >> Or, the linux-yocto change needs to actually be upstreamed. I submitted it >> and the upstream maintainer questioned why the change is needed: >> https://lore.kernel.org/lkml/cak7lnatd0j3c_mfrxaju8-wmdcmrpmrfn7um0yebnfl-_zc...@mail.gmail.com/ > The problem is if it was accepted, every kernel prior to its inclusion > would need to be patched, as well as other projects (u-boot, busybox). > This makes supporting menuconfig using that change for kconfig > generically problematic. This is why the pkg-config solution is > preferable. The kernel works with menuconfig without your yocto change today. Only linux-yocto (with the patch mentioned above) works with your yocto change. > > Regards, > Nathan smime.p7s Description: S/MIME Cryptographic Signature -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#145245): https://lists.openembedded.org/g/openembedded-core/message/145245 Mute This Topic: https://lists.openembedded.org/mt/78667947/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] commit breaks menuconfig on upstream kernel "cml1.bbclass: Handle ncurses-native being available via pkg-config"
On 2020-12-02 4:19 p.m., Nathan Rossi wrote: > On Thu, 3 Dec 2020 at 05:17, Scott Branden wrote: >> Hi Nathan, >> >> Your commit: >> "cml1.bbclass: Handle ncurses-native being available via pkg-config" >> https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=master-next=ce447d70df386ca55ce1672478b245851556374e >> >> breaks bitbake menuconfig when using the upstream kernel. > Interesting. The purpose of the commit was to actually fix that exact > use case since previously the mainline kernel menuconfig was relying > on hardcoded paths to the host ncurses libraries. > > Would you be able to provide the error messages you are getting (and > anything else that can help to reproduce the failure), because I am > not able to reproduce any failures with a mainline kernel, linux-yocto > (with and without the below mention patch) or with other projects that > are using cml1 (e.g. u-boot). Here is the result of menuconfig with your yocto change in place: GEN Makefile HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/confdata.o HOSTCC scripts/kconfig/expr.o HOSTCC scripts/kconfig/lexer.lex.o HOSTCC scripts/kconfig/parser.tab.o HOSTCC scripts/kconfig/preprocess.o HOSTCC scripts/kconfig/symbol.o HOSTCC scripts/kconfig/util.o UPD scripts/kconfig/mconf-cfg HOSTCC scripts/kconfig/mconf.o HOSTCC scripts/kconfig/lxdialog/checklist.o HOSTCC scripts/kconfig/lxdialog/inputbox.o HOSTCC scripts/kconfig/lxdialog/menubox.o HOSTCC scripts/kconfig/lxdialog/textbox.o HOSTCC scripts/kconfig/lxdialog/util.o HOSTCC scripts/kconfig/lxdialog/yesno.o HOSTLD scripts/kconfig/mconf scripts/kconfig/mconf Kconfig make[2]: scripts/kconfig/mconf: Command not found /mnt/2ndHDD/yocto/nxs/poky/build/workspace/sources/brcm-linux/scripts/kconfig/Makefile:29: recipe for target 'menuconfig' failed make[2]: *** [menuconfig] Error 127 /mnt/2ndHDD/yocto/nxs/poky/build/workspace/sources/brcm-linux/Makefile:606: recipe for target 'menuconfig' failed make[1]: *** [menuconfig] Error 2 /mnt/2ndHDD/yocto/nxs/poky/build/workspace/sources/brcm-linux/Makefile:185: recipe for target '__sub-make' failed make: *** [__sub-make] Error 2 Command failed. Press any key to continue... > >> It only works with the linux-yocto kernel due to this workaround which is >> not upstream. >> If you revert this commit in linux-yocto menuconfig will not work in >> linux-yocto: >> "menuconfig,mconf-cfg: Allow specification of ncurses location" >> https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/commit/scripts/kconfig/mconf-cfg.sh?h=v5.8/standard/base=1714a5ad9cf61f4d0f4b8432f327cca2998aba77 > This change should not be required to have menuconfig working when > pkg-config is used. > >> >> Seems like your commit needs to be reverted or a change made to work with >> the upstream kernel. >> Or, the linux-yocto change needs to actually be upstreamed. I submitted it >> and the upstream maintainer questioned why the change is needed: >> https://lore.kernel.org/lkml/cak7lnatd0j3c_mfrxaju8-wmdcmrpmrfn7um0yebnfl-_zc...@mail.gmail.com/ > The problem is if it was accepted, every kernel prior to its inclusion > would need to be patched, as well as other projects (u-boot, busybox). > This makes supporting menuconfig using that change for kconfig > generically problematic. This is why the pkg-config solution is > preferable. > > Regards, > Nathan smime.p7s Description: S/MIME Cryptographic Signature -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#145244): https://lists.openembedded.org/g/openembedded-core/message/145244 Mute This Topic: https://lists.openembedded.org/mt/78667947/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] commit breaks menuconfig on upstream kernel "cml1.bbclass: Handle ncurses-native being available via pkg-config"
Hi Nathan, Your commit: "cml1.bbclass: Handle ncurses-native being available via pkg-config" https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=master-next=ce447d70df386ca55ce1672478b245851556374e breaks bitbake menuconfig when using the upstream kernel. It only works with the linux-yocto kernel due to this workaround which is not upstream. If you revert this commit in linux-yocto menuconfig will not work in linux-yocto: "menuconfig,mconf-cfg: Allow specification of ncurses location" https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/commit/scripts/kconfig/mconf-cfg.sh?h=v5.8/standard/base=1714a5ad9cf61f4d0f4b8432f327cca2998aba77 Seems like your commit needs to be reverted or a change made to work with the upstream kernel. Or, the linux-yocto change needs to actually be upstreamed. I submitted it and the upstream maintainer questioned why the change is needed: https://lore.kernel.org/lkml/cak7lnatd0j3c_mfrxaju8-wmdcmrpmrfn7um0yebnfl-_zc...@mail.gmail.com/ Regards, Scott smime.p7s Description: S/MIME Cryptographic Signature -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#145183): https://lists.openembedded.org/g/openembedded-core/message/145183 Mute This Topic: https://lists.openembedded.org/mt/78667947/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] menuconfig,mconf-cfg: Allow specification of ncurses location
Hi Bruce, On 2020-12-01 11:01 a.m., Bruce Ashfield wrote: > On Tue, Dec 1, 2020 at 12:19 PM Scott Branden > wrote: >> Hi Masahiro, >> >> On 2020-12-01 4:25 a.m., Masahiro Yamada wrote: >>> On Sat, Nov 28, 2020 at 9:45 AM Scott Branden >>> wrote: From: Bruce Ashfield In some cross build environments such as the Yocto Project build environment it provides an ncurses library that is compiled differently than the host's version. This causes display corruption problems when the host's curses includes are used instead of the includes from the provided compiler are overridden. There is a second case where there is no curses libraries at all on the host system and menuconfig will just fail entirely. The solution is simply to allow an override variable in check-lxdialog.sh for environments such as the Yocto Project. Adding a CROSS_CURSES_LIB and CROSS_CURSES_INC solves the issue and allowing compiling and linking against the right headers and libraries. Signed-off-by: Jason Wessel cc: Michal Marek cc: linux-kbu...@vger.kernel.org Signed-off-by: Bruce Ashfield Signed-off-by: Scott Branden --- >>> Some people solve the cross-compiling in Yocto >>> by using pkg-config. >>> >>> >>> For example, >>> >>> commit 067c650c456e758f933aaf87a202f841d34be269 >>> Author: Pavel Modilaynen >>> Date: Fri Jul 12 13:52:19 2019 +0200 >>> >>> dtc: Use pkg-config to locate libyaml >>> >>> Using Makefile's wildcard with absolute path to detect >>> the presence of libyaml results in false-positive >>> detection when cross-compiling e.g. in yocto environment. >>> >>> >>> >>> mconf-cfg.sh already allows the path flexibility with pkg-config. >>> Why do you want yet another hook? >> I hope the yocto community can provide more details on this patch. >> The yocto environment isolates the build environment from the host tools. >> Running menuconfig with the upstream kernel does not work on the latest >> yocto without this patch. > Sorry for not commenting on the origin patch, gmail buried it within > some other threads, but luckily this one popped up. > > It is true that we've been carrying this for several years to deal with > the fact that the native sysroot is not searched by the pkg-config > called by mconf-cfg.sh (since it is separate from host and target > pkg-config). > > As it turns out, in the past few weeks, we have come up with a way > to inject those native sysroot components into pkg-config without > the need for any changes to the scripts. > > Scott: if you try again the the latest oe-core, and are still seeing > the problem with the mainline kernel, ping me, and we can see if > the pkg-config fix isn't holding for you, at that point, yes, we may > still need a hook like this to solve the problem. Try reverting this kernel patch from linux-yocto and menuconfig will fail. menuconfig actually did work with the upstream kernel until the yocto change below was introduced: "cml1.bbclass: Handle ncurses-native being available via pkg-config" https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=master-next=ce447d70df386ca55ce1672478b245851556374e > Cheers, > > Bruce > > > scripts/kconfig/mconf-cfg.sh | 8 1 file changed, 8 insertions(+) mode change 100755 => 100644 scripts/kconfig/mconf-cfg.sh diff --git a/scripts/kconfig/mconf-cfg.sh b/scripts/kconfig/mconf-cfg.sh old mode 100755 new mode 100644 index aa68ec95620d..32448bc198a5 --- a/scripts/kconfig/mconf-cfg.sh +++ b/scripts/kconfig/mconf-cfg.sh @@ -4,6 +4,14 @@ PKG="ncursesw" PKG2="ncurses" +if [ "$CROSS_CURSES_LIB" != "" ]; then +echo libs=\'$CROSS_CURSES_LIB\' +if [ x"$CROSS_CURSES_INC" != x ]; then + echo cflags=\'$CROSS_CURSES_INC\' +fi +exit 0 +fi + if [ -n "$(command -v pkg-config)" ]; then if pkg-config --exists $PKG; then echo cflags=\"$(pkg-config --cflags $PKG)\" -- 2.17.1 > smime.p7s Description: S/MIME Cryptographic Signature -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#145164): https://lists.openembedded.org/g/openembedded-core/message/145164 Mute This Topic: https://lists.openembedded.org/mt/78639179/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] menuconfig,mconf-cfg: Allow specification of ncurses location
Hi Masahiro, On 2020-12-01 4:25 a.m., Masahiro Yamada wrote: > On Sat, Nov 28, 2020 at 9:45 AM Scott Branden > wrote: >> From: Bruce Ashfield >> >> In some cross build environments such as the Yocto Project build >> environment it provides an ncurses library that is compiled >> differently than the host's version. This causes display corruption >> problems when the host's curses includes are used instead of the >> includes from the provided compiler are overridden. There is a second >> case where there is no curses libraries at all on the host system and >> menuconfig will just fail entirely. >> >> The solution is simply to allow an override variable in >> check-lxdialog.sh for environments such as the Yocto Project. Adding >> a CROSS_CURSES_LIB and CROSS_CURSES_INC solves the issue and allowing >> compiling and linking against the right headers and libraries. >> >> Signed-off-by: Jason Wessel >> cc: Michal Marek >> cc: linux-kbu...@vger.kernel.org >> Signed-off-by: Bruce Ashfield >> Signed-off-by: Scott Branden >> --- > > Some people solve the cross-compiling in Yocto > by using pkg-config. > > > For example, > > commit 067c650c456e758f933aaf87a202f841d34be269 > Author: Pavel Modilaynen > Date: Fri Jul 12 13:52:19 2019 +0200 > > dtc: Use pkg-config to locate libyaml > > Using Makefile's wildcard with absolute path to detect > the presence of libyaml results in false-positive > detection when cross-compiling e.g. in yocto environment. > > > > mconf-cfg.sh already allows the path flexibility with pkg-config. > Why do you want yet another hook? I hope the yocto community can provide more details on this patch. The yocto environment isolates the build environment from the host tools. Running menuconfig with the upstream kernel does not work on the latest yocto without this patch. >> scripts/kconfig/mconf-cfg.sh | 8 >> 1 file changed, 8 insertions(+) >> mode change 100755 => 100644 scripts/kconfig/mconf-cfg.sh >> >> diff --git a/scripts/kconfig/mconf-cfg.sh b/scripts/kconfig/mconf-cfg.sh >> old mode 100755 >> new mode 100644 >> index aa68ec95620d..32448bc198a5 >> --- a/scripts/kconfig/mconf-cfg.sh >> +++ b/scripts/kconfig/mconf-cfg.sh >> @@ -4,6 +4,14 @@ >> PKG="ncursesw" >> PKG2="ncurses" >> >> +if [ "$CROSS_CURSES_LIB" != "" ]; then >> +echo libs=\'$CROSS_CURSES_LIB\' >> +if [ x"$CROSS_CURSES_INC" != x ]; then >> + echo cflags=\'$CROSS_CURSES_INC\' >> +fi >> +exit 0 >> +fi >> + >> if [ -n "$(command -v pkg-config)" ]; then >> if pkg-config --exists $PKG; then >> echo cflags=\"$(pkg-config --cflags $PKG)\" >> -- >> 2.17.1 >> > smime.p7s Description: S/MIME Cryptographic Signature -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#145136): https://lists.openembedded.org/g/openembedded-core/message/145136 Mute This Topic: https://lists.openembedded.org/mt/78639179/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v2] kernel: provide module.lds for out of tree builds in v5.10+
On 2020-11-16 11:50 a.m., Scott Branden wrote:
> This version works better for me.
*when the kernel is devtool checked out. When the kernel is not checked out it
fails to compile the external kernel module.
>
> On 2020-11-13 9:27 p.m., Bruce Ashfield wrote:
>> From: Bruce Ashfield
>>
>> The upstream commit 596b0474d3d [kbuild: preprocess module linker
>> script], adds a dependency on module.lds for external module
>> building.
>>
>> Since module.lds is generated as part of 'modules_prepare', we
>> must make it available with the other kernel artifacts in the
>> kernel shared workdir, otherwise out of tree builds fail.
>>
>> This fixes errors like:
>>
>> | make[4]: *** No rule to make target 'scripts/module.lds', needed by
>>
>> 'build/tmp/work/qemuarm64-poky-linux/cryptodev-module/1.11-r0/git/cryptodev.ko'.
>> Stop.
>> | make[4]: *** Waiting for unfinished jobs
>>
>> We also ensure that kernel-devsrc has a copy to support on
>> target module builds that are often prepared with 'make scripts
>> prepare'. Those targets won't regenerate it, so the build fails.
>> If 'make modules_prepare' is used, the file will be regenerated
>> and overwrite our copy (as expected).
>>
>> Signed-off-by: Pan, Kris
>> Signed-off-by: Lili Li
>> Signed-off-by: Bruce Ashfield
> Tested-by: Scott Branden
>> ---
>>
>> v2:
>> - I was right that we really only should be copying this in one
>> location, but it wasn't clear that the main kernel build no
>> longer runs modules_prepare so the do_shared_workdir task will
>> *never* fine module.lds on a clean run.
>>
>> So we just need the single copy after we've build our modules
>> to ensure that the file is available.
>>
>> Tested against a clean kernel and module build, just building
>> the module. Dependencies are correct and the file is copied
>> for the module to build.
>>
>> We could do the same thing for Module.symvers, but historically
>> it was generated during the main kernel build .. so we can leave
>> it there for old kernel support.
>>
>>
>> meta/classes/kernel.bbclass| 1 +
>> meta/recipes-kernel/linux/kernel-devsrc.bb | 6 ++
>> 2 files changed, 7 insertions(+)
>>
>> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
>> index be93a258f6..af4c891de4 100644
>> --- a/meta/classes/kernel.bbclass
>> +++ b/meta/classes/kernel.bbclass
>> @@ -391,6 +391,7 @@ do_compile_kernelmodules() {
>> # other kernel modules and will look at this
>> # file to do symbol lookups
>> cp ${B}/Module.symvers ${STAGING_KERNEL_BUILDDIR}/
>> +[ -e ${B}/scripts/module.lds ] && install -Dm 0644
>> ${B}/scripts/module.lds ${STAGING_KERNEL_BUILDDIR}/scripts/module.lds
>> else
>> bbnote "no modules to compile"
>> fi
>> diff --git a/meta/recipes-kernel/linux/kernel-devsrc.bb
>> b/meta/recipes-kernel/linux/kernel-devsrc.bb
>> index 81b1e36041..5f0dedbdf7 100644
>> --- a/meta/recipes-kernel/linux/kernel-devsrc.bb
>> +++ b/meta/recipes-kernel/linux/kernel-devsrc.bb
>> @@ -100,6 +100,12 @@ do_install() {
>> # be dealt with.
>> # cp -a scripts $kerneldir/build
>>
>> +# although module.lds can be regenerated on target via 'make
>> modules_prepare'
>> +# there are several places where 'makes scripts prepare' is done, and
>> that won't
>> +# regenerate the file. So we copy it onto the target as a migration to
>> using
>> +# modules_prepare
>> +cp -a --parents scripts/module.lds $kerneldir/build/ 2>/dev/null || :
>> +
>> if [ -d arch/${ARCH}/scripts ]; then
>> cp -a arch/${ARCH}/scripts $kerneldir/build/arch/${ARCH}
>> fi
>>
>>
>>
>
smime.p7s
Description: S/MIME Cryptographic Signature
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144670):
https://lists.openembedded.org/g/openembedded-core/message/144670
Mute This Topic: https://lists.openembedded.org/mt/78246068/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v2] kernel: provide module.lds for out of tree builds in v5.10+
This version works better for me.
On 2020-11-13 9:27 p.m., Bruce Ashfield wrote:
> From: Bruce Ashfield
>
> The upstream commit 596b0474d3d [kbuild: preprocess module linker
> script], adds a dependency on module.lds for external module
> building.
>
> Since module.lds is generated as part of 'modules_prepare', we
> must make it available with the other kernel artifacts in the
> kernel shared workdir, otherwise out of tree builds fail.
>
> This fixes errors like:
>
> | make[4]: *** No rule to make target 'scripts/module.lds', needed by
>
> 'build/tmp/work/qemuarm64-poky-linux/cryptodev-module/1.11-r0/git/cryptodev.ko'.
> Stop.
> | make[4]: *** Waiting for unfinished jobs
>
> We also ensure that kernel-devsrc has a copy to support on
> target module builds that are often prepared with 'make scripts
> prepare'. Those targets won't regenerate it, so the build fails.
> If 'make modules_prepare' is used, the file will be regenerated
> and overwrite our copy (as expected).
>
> Signed-off-by: Pan, Kris
> Signed-off-by: Lili Li
> Signed-off-by: Bruce Ashfield
Tested-by: Scott Branden
> ---
>
> v2:
> - I was right that we really only should be copying this in one
> location, but it wasn't clear that the main kernel build no
> longer runs modules_prepare so the do_shared_workdir task will
> *never* fine module.lds on a clean run.
>
> So we just need the single copy after we've build our modules
> to ensure that the file is available.
>
> Tested against a clean kernel and module build, just building
> the module. Dependencies are correct and the file is copied
> for the module to build.
>
> We could do the same thing for Module.symvers, but historically
> it was generated during the main kernel build .. so we can leave
> it there for old kernel support.
>
>
> meta/classes/kernel.bbclass| 1 +
> meta/recipes-kernel/linux/kernel-devsrc.bb | 6 ++
> 2 files changed, 7 insertions(+)
>
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index be93a258f6..af4c891de4 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -391,6 +391,7 @@ do_compile_kernelmodules() {
> # other kernel modules and will look at this
> # file to do symbol lookups
> cp ${B}/Module.symvers ${STAGING_KERNEL_BUILDDIR}/
> + [ -e ${B}/scripts/module.lds ] && install -Dm 0644
> ${B}/scripts/module.lds ${STAGING_KERNEL_BUILDDIR}/scripts/module.lds
> else
> bbnote "no modules to compile"
> fi
> diff --git a/meta/recipes-kernel/linux/kernel-devsrc.bb
> b/meta/recipes-kernel/linux/kernel-devsrc.bb
> index 81b1e36041..5f0dedbdf7 100644
> --- a/meta/recipes-kernel/linux/kernel-devsrc.bb
> +++ b/meta/recipes-kernel/linux/kernel-devsrc.bb
> @@ -100,6 +100,12 @@ do_install() {
> # be dealt with.
> # cp -a scripts $kerneldir/build
>
> + # although module.lds can be regenerated on target via 'make
> modules_prepare'
> + # there are several places where 'makes scripts prepare' is done, and
> that won't
> + # regenerate the file. So we copy it onto the target as a migration to
> using
> + # modules_prepare
> + cp -a --parents scripts/module.lds $kerneldir/build/ 2>/dev/null || :
> +
> if [ -d arch/${ARCH}/scripts ]; then
> cp -a arch/${ARCH}/scripts $kerneldir/build/arch/${ARCH}
> fi
>
>
>
smime.p7s
Description: S/MIME Cryptographic Signature
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144668):
https://lists.openembedded.org/g/openembedded-core/message/144668
Mute This Topic: https://lists.openembedded.org/mt/78246068/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] kernel: provide module.lds for out of tree builds in v5.10+
On 2020-11-13 9:09 p.m., Bruce Ashfield wrote:
> On Fri, Nov 13, 2020 at 11:41 PM Bruce Ashfield via
> lists.openembedded.org
> wrote:
>> On Fri, Nov 13, 2020 at 11:27 PM Bruce Ashfield via
>> lists.openembedded.org
>> wrote:
>>> On Fri, Nov 13, 2020 at 11:19 PM Scott Branden
>>> wrote:
Sorry, spoke too soon. Doesn't seem to work from a clean build now.
>>> How so ? Works on repeated clean builds here. For 5.4/5.8 and 5.10
>>>
>> I have a theory on this. Did you directly bitbake your external module
>> ? versus building the kernel first and then the module ?
Yes, I was doing a direct bitbake of the external module.
>>
>> I'll see what I can come up with.
> Confirmed.
>
> I have it sorted now. Doing one more clean build and will send a v2.
Glad you were able to reproduce.
>
> Thanks for the follow up!!
Looks to be merged to master now.
Will pickup the latest and if anything still not working let you know.
>
> Bruce
>
>> Bruce
>>
>>> Bruce
>>>
On 2020-11-13 9:53 a.m., Scott Branden wrote:
Thanks, works for me building external kernel modules.
On 2020-11-12 10:32 p.m., Bruce Ashfield wrote:
From: Bruce Ashfield
The upstream commit 596b0474d3d [kbuild: preprocess module linker
script], adds a dependency on module.lds for external module
building.
Since module.lds is generated as part of 'modules_prepare', we
must make it available with the other kernel artifacts in the
kernel shared workdir, otherwise out of tree builds fail.
This fixes errors like:
| make[4]: *** No rule to make target 'scripts/module.lds', needed by
'build/tmp/work/qemuarm64-poky-linux/cryptodev-module/1.11-r0/git/cryptodev.ko'.
Stop.
| make[4]: *** Waiting for unfinished jobs
We also ensure that kernel-devsrc has a copy to support on
target module builds that are often prepared with 'make scripts
prepare'. Those targets won't regenerate it, so the build fails.
If 'make modules_prepare' is used, the file will be regenerated
and overwrite our copy (as expected).
Signed-off-by: Pan, Kris
Signed-off-by: Lili Li
Signed-off-by: Bruce Ashfield
Tested-by: Scott Branden
---
meta/classes/kernel.bbclass| 1 +
meta/recipes-kernel/linux/kernel-devsrc.bb | 6 ++
2 files changed, 7 insertions(+)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index be93a258f6..ccd74e61e8 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -494,6 +494,7 @@ do_shared_workdir () {
# Copy files required for module builds
cp System.map $kerneldir/System.map-${KERNEL_VERSION}
[ -e Module.symvers ] && cp Module.symvers $kerneldir/
+ [ -e scripts/module.lds ] && install -Dm 0644 scripts/module.lds
$kerneldir/scripts/module.lds
cp .config $kerneldir/
mkdir -p $kerneldir/include/config
cp include/config/kernel.release $kerneldir/include/config/kernel.release
diff --git a/meta/recipes-kernel/linux/kernel-devsrc.bb
b/meta/recipes-kernel/linux/kernel-devsrc.bb
index 81b1e36041..5f0dedbdf7 100644
--- a/meta/recipes-kernel/linux/kernel-devsrc.bb
+++ b/meta/recipes-kernel/linux/kernel-devsrc.bb
@@ -100,6 +100,12 @@ do_install() {
# be dealt with.
# cp -a scripts $kerneldir/build
+ # although module.lds can be regenerated on target via 'make
modules_prepare'
+ # there are several places where 'makes scripts prepare' is done, and
that won't
+ # regenerate the file. So we copy it onto the target as a migration to
using
+ # modules_prepare
+ cp -a --parents scripts/module.lds $kerneldir/build/ 2>/dev/null || :
+
if [ -d arch/${ARCH}/scripts ]; then
cp -a arch/${ARCH}/scripts $kerneldir/build/arch/${ARCH}
fi
>>>
>>> --
>>> - Thou shalt not follow the NULL pointer, for chaos and madness await
>>> thee at its end
>>> - "Use the force Harry" - Gandalf, Star Trek II
>>>
>>>
>>>
>>
>> --
>> - Thou shalt not follow the NULL pointer, for chaos and madness await
>> thee at its end
>> - "Use the force Harry" - Gandalf, Star Trek II
>>
>>
>>
>
smime.p7s
Description: S/MIME Cryptographic Signature
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144624):
https://lists.openembedded.org/g/openembedded-core/message/144624
Mute This Topic: https://lists.openembedded.org/mt/78224757/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] kernel: provide module.lds for out of tree builds in v5.10+
Sorry, spoke too soon. Doesn't seem to work from a clean build now.
On 2020-11-13 9:53 a.m., Scott Branden wrote:
> Thanks, works for me building external kernel modules.
>
> On 2020-11-12 10:32 p.m., Bruce Ashfield wrote:
>> From: Bruce Ashfield
>>
>> The upstream commit 596b0474d3d [kbuild: preprocess module linker
>> script], adds a dependency on module.lds for external module
>> building.
>>
>> Since module.lds is generated as part of 'modules_prepare', we
>> must make it available with the other kernel artifacts in the
>> kernel shared workdir, otherwise out of tree builds fail.
>>
>> This fixes errors like:
>>
>> | make[4]: *** No rule to make target 'scripts/module.lds', needed by
>>
>> 'build/tmp/work/qemuarm64-poky-linux/cryptodev-module/1.11-r0/git/cryptodev.ko'.
>> Stop.
>> | make[4]: *** Waiting for unfinished jobs
>>
>> We also ensure that kernel-devsrc has a copy to support on
>> target module builds that are often prepared with 'make scripts
>> prepare'. Those targets won't regenerate it, so the build fails.
>> If 'make modules_prepare' is used, the file will be regenerated
>> and overwrite our copy (as expected).
>>
>> Signed-off-by: Pan, Kris
>> Signed-off-by: Lili Li
>> Signed-off-by: Bruce Ashfield
> Tested-by: Scott Branden
>> ---
>> meta/classes/kernel.bbclass| 1 +
>> meta/recipes-kernel/linux/kernel-devsrc.bb | 6 ++
>> 2 files changed, 7 insertions(+)
>>
>> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
>> index be93a258f6..ccd74e61e8 100644
>> --- a/meta/classes/kernel.bbclass
>> +++ b/meta/classes/kernel.bbclass
>> @@ -494,6 +494,7 @@ do_shared_workdir () {
>> # Copy files required for module builds
>> cp System.map $kerneldir/System.map-${KERNEL_VERSION}
>> [ -e Module.symvers ] && cp Module.symvers $kerneldir/
>> +[ -e scripts/module.lds ] && install -Dm 0644 scripts/module.lds
>> $kerneldir/scripts/module.lds
>> cp .config $kerneldir/
>> mkdir -p $kerneldir/include/config
>> cp include/config/kernel.release
>> $kerneldir/include/config/kernel.release
>> diff --git a/meta/recipes-kernel/linux/kernel-devsrc.bb
>> b/meta/recipes-kernel/linux/kernel-devsrc.bb
>> index 81b1e36041..5f0dedbdf7 100644
>> --- a/meta/recipes-kernel/linux/kernel-devsrc.bb
>> +++ b/meta/recipes-kernel/linux/kernel-devsrc.bb
>> @@ -100,6 +100,12 @@ do_install() {
>> # be dealt with.
>> # cp -a scripts $kerneldir/build
>>
>> +# although module.lds can be regenerated on target via 'make
>> modules_prepare'
>> +# there are several places where 'makes scripts prepare' is done, and
>> that won't
>> +# regenerate the file. So we copy it onto the target as a migration to
>> using
>> +# modules_prepare
>> +cp -a --parents scripts/module.lds $kerneldir/build/ 2>/dev/null || :
>> +
>> if [ -d arch/${ARCH}/scripts ]; then
>> cp -a arch/${ARCH}/scripts $kerneldir/build/arch/${ARCH}
>> fi
>>
>>
>>
>
smime.p7s
Description: S/MIME Cryptographic Signature
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144581):
https://lists.openembedded.org/g/openembedded-core/message/144581
Mute This Topic: https://lists.openembedded.org/mt/78224757/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] kernel: provide module.lds for out of tree builds in v5.10+
Thanks, works for me building external kernel modules.
On 2020-11-12 10:32 p.m., Bruce Ashfield wrote:
> From: Bruce Ashfield
>
> The upstream commit 596b0474d3d [kbuild: preprocess module linker
> script], adds a dependency on module.lds for external module
> building.
>
> Since module.lds is generated as part of 'modules_prepare', we
> must make it available with the other kernel artifacts in the
> kernel shared workdir, otherwise out of tree builds fail.
>
> This fixes errors like:
>
> | make[4]: *** No rule to make target 'scripts/module.lds', needed by
>
> 'build/tmp/work/qemuarm64-poky-linux/cryptodev-module/1.11-r0/git/cryptodev.ko'.
> Stop.
> | make[4]: *** Waiting for unfinished jobs
>
> We also ensure that kernel-devsrc has a copy to support on
> target module builds that are often prepared with 'make scripts
> prepare'. Those targets won't regenerate it, so the build fails.
> If 'make modules_prepare' is used, the file will be regenerated
> and overwrite our copy (as expected).
>
> Signed-off-by: Pan, Kris
> Signed-off-by: Lili Li
> Signed-off-by: Bruce Ashfield
Tested-by: Scott Branden
> ---
> meta/classes/kernel.bbclass| 1 +
> meta/recipes-kernel/linux/kernel-devsrc.bb | 6 ++
> 2 files changed, 7 insertions(+)
>
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index be93a258f6..ccd74e61e8 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -494,6 +494,7 @@ do_shared_workdir () {
> # Copy files required for module builds
> cp System.map $kerneldir/System.map-${KERNEL_VERSION}
> [ -e Module.symvers ] && cp Module.symvers $kerneldir/
> + [ -e scripts/module.lds ] && install -Dm 0644 scripts/module.lds
> $kerneldir/scripts/module.lds
> cp .config $kerneldir/
> mkdir -p $kerneldir/include/config
> cp include/config/kernel.release
> $kerneldir/include/config/kernel.release
> diff --git a/meta/recipes-kernel/linux/kernel-devsrc.bb
> b/meta/recipes-kernel/linux/kernel-devsrc.bb
> index 81b1e36041..5f0dedbdf7 100644
> --- a/meta/recipes-kernel/linux/kernel-devsrc.bb
> +++ b/meta/recipes-kernel/linux/kernel-devsrc.bb
> @@ -100,6 +100,12 @@ do_install() {
> # be dealt with.
> # cp -a scripts $kerneldir/build
>
> + # although module.lds can be regenerated on target via 'make
> modules_prepare'
> + # there are several places where 'makes scripts prepare' is done, and
> that won't
> + # regenerate the file. So we copy it onto the target as a migration to
> using
> + # modules_prepare
> + cp -a --parents scripts/module.lds $kerneldir/build/ 2>/dev/null || :
> +
> if [ -d arch/${ARCH}/scripts ]; then
> cp -a arch/${ARCH}/scripts $kerneldir/build/arch/${ARCH}
> fi
>
>
>
smime.p7s
Description: S/MIME Cryptographic Signature
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144572):
https://lists.openembedded.org/g/openembedded-core/message/144572
Mute This Topic: https://lists.openembedded.org/mt/78224757/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
