|
Re: [EXT] [yocto] Not adding glibc to an image and avoiding RDEPENDS problem?
Heinz Wrobel
All,
To answer my own question with a solution that is apparently working well.
For all recipes/packages that should be used at build time only but not to be put in an image as opposed to the “otherpackage” that should get put into the image:
This ensures that on recipe processing (including sysroot handling) all the “normal” recipes are used, but none of the packages generated by normal recipes go into the image then because “otherpackage” will be used then. The method also tries to stay away from too many implementation details to be somewhat portable hopefully across future Yocto versions.
It appears to work here at first glance. Your mileage may vary.
Hope this helps,
Heinz
From: yocto@... <yocto@...>
On Behalf Of Heinz Wrobel via Lists.Yoctoproject.Org
Sent: Thursday, January 30, 2020 11:57 To: yocto@... Cc: yocto@... Subject: [EXT] [yocto] Not adding glibc to an image and avoiding RDEPENDS problem?
Caution: EXT Email Hi,
I want to build an image that does in the end NOT contain the virtual/libc used for building the elements of the image because the final target libc is provided pre-built in a different way through another recipe and package. [Yes I understand the version risks]
Given that the virtual/libc sysroot is still needed to build packages properly, I thought that simply not packaging virtual/libc and then adding in the other package into the image would do the trick.
“dtc” is my unmodified test recipe for the concept.
I must be missing some fine point however, because now I can’t even build the test recipe anymore: ERROR: dtc-1.5.1-r0 do_package_qa: QA Issue: /usr/lib/libfdt.so.1 contained in package dtc requires ld-linux-aarch64.so.1(GLIBC_2.17)(64bit), but no providers found in RDEPENDS_dtc? [file-rdeps] ERROR: dtc-1.5.1-r0 do_package_qa: QA Issue: /usr/lib/libfdt.so.1 contained in package dtc requires libc.so.6(GLIBC_2.17)(64bit), but no providers found in RDEPENDS_dtc? [file-rdeps] ERROR: dtc-1.5.1-r0 do_package_qa: QA Issue: /usr/lib/libfdt.so.1 contained in package dtc requires libc.so.6()(64bit), but no providers found in RDEPENDS_dtc? [file-rdeps] ERROR: dtc-1.5.1-r0 do_package_qa: QA Issue: /usr/lib/libfdt.so.1 contained in package dtc requires ld-linux-aarch64.so.1()(64bit), but no providers found in RDEPENDS_dtc? [file-rdeps] ERROR: dtc-1.5.1-r0 do_package_qa: QA run found fatal errors. Please consider fixing them.
I found the change that RDEPENDS are no longer recursively checked, so I thought I should find how the dependency is directly resolved and missed via bitbake -e. Bitbake -e shows that RDEPENDS for dtc is empty, i.e., a shared library glibc file based runtime dependency usually must be filled by some other magic that I can’t seem to grasp. I have not seen receipes all over the place explicitly specifying an RDPENDS for the libc used.
The tmp/pkgdata/*/runtime/ file for my other package clearly shows FILERPROVIDES for exactly the “missing” files.
I could decide to ignore file-rdeps, but I’d rather “consider fixing them”.
I also did read the “shlibdeps” bullet in “Automatically Added Runtime Dependencies” and then grepped quite a bit through meta/classes and bitbake itself. File-rdeps checking does not seem to check on the package database. I couldn’t figure out the mechanism that a) causes the error, and that b) would allow me to fix it properly. What am I missing about implicit runtime dependency handling for the selected libc?
Thanks,
Heinz
|
|
|
|
Re: How to make a local patch without a commit number, or will not be possible?
Quentin Schulz
Hi JH,
On Mon, Feb 03, 2020 at 06:06:18PM +1100, JH wrote: Hi,I think you're looking for `git format-patch`. This creates a patch for the latest commit (HEAD). Take this .patch and add it to your SRC_URI in a bbappend. Also as Gabrielle said, U-Boot is having more and more options in Kconfig instead of board header files, so maybe there's an Kconfig option you can modify with menuconfig to set the mtdparts, bootcmd and/or bootargs in which case I suggest you to follow what Gabrielle said. Note that you could technically pass a local git repo by changing the URL to git:///path/to/local/git/repo (that should be enough) and then you'd be able to use your local SRCREV (BUT, that should be used just for *testing*). BR, Quentin |
|
|
|
Re: How to make a local patch without a commit number, or will not be possible?
Gabriele
Hi JH, since uboot migrated to kconfig for a while, I'd suggest you to patch the Freescale's one with your custom machine defconfig and then specify the UBOOT_MACHINE = "my_machine_defconfig" in your machine conf file. The process is the same as the kernel: - make [...] <some_defconfig> - make [...] menuconfig - make [...] savedefconfig Put the resulting defconfig in configs/ and rename it to <my_machine_defconfig> and then generate a patch. This patch can be applied through a bbappend to the freescale recipe. Hope it helps, Gabriele On Mon, Feb 3, 2020 at 8:06 AM JH <jupiter.hce@...> wrote: Hi, |
|
|
|
How to make a local patch without a commit number, or will not be possible?
JH
Hi,
I want to make a patch file for mx6ullevk.h in meta-freescale/recipes-bsp/u-boot/u-boot-imx_2017.03.bb, to customize mtdparts, bootcmd and bootargs as I could not find a simple way to do it in a bbapaend, but I got an error of unable to fetch URL from any source because the mx6ullevk.h.patch ls my local one, it does have a commit number. Is it possible to do it or not? In general, how did you customize u-boot mtdparts, bootcmd and bootarg? It is very common thing, but I don't see anyone talking about it. Is there a simple way I don't know? What could I be missing? Thank you. Kind regards, -jh |
|
|
|
KeyError: 'getpwuid(): uid not found: 1000' during package nativesdk-glibc-locale
#yocto
#raspberrypi
vstevenpavao@...
error packaging nativesdk-glibc-locale when building at head in master today:
Exception: KeyError: 'getpwuid(): uid not found: 1000'
ERROR: Logfile of failure stored in: /home/parallels/poky/build/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-glibc-locale/2.31-r0/temp/log.do_package.32088
ERROR: Task (virtual:nativesdk:/home/parallels/poky/meta/recipes-core/glibc/glibc-locale_2.31.bb:do_package) failed with exit code '1'
full command result follows: parallels@parallels-Parallels-Virtual-Platform:~/poky/build$ bitbake core-image-base -c populate_sdk Loading cache: 100% |#################################################################################################| Time: 0:00:00
Loaded 3135 entries from dependency cache.
Parsing recipes: 100% |###############################################################################################| Time: 0:00:00
Parsing of 2134 .bb files complete (2133 cached, 1 parsed). 3136 targets, 140 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
Build Configuration:
BB_VERSION = "1.44.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "universal"
TARGET_SYS = "aarch64-poky-linux"
MACHINE = "raspberrypi3-64"
DISTRO = "poky"
DISTRO_VERSION = "3.0+snapshot-20200202"
TUNE_FEATURES = "aarch64 cortexa53 crc"
TARGET_FPU = ""
meta
meta-poky
meta-yocto-bsp = "master:2b9781da7c6d60f8d0ddb36de2666b1ba702f551"
meta-oe
meta-multimedia
meta-networking
meta-python = "master:463f9a3ef0935d772a0be0437a8c09df64ed2f07"
meta-raspberrypi = "master:4801ca3f039f54e6156d761d2a250a8ef9d422eb"
Initialising tasks: 100% |############################################################################################| Time: 0:00:01
Sstate summary: Wanted 3 Found 0 Missed 3 Current 1304 (0% match, 99% complete)
NOTE: Executing Tasks
NOTE: Setscene tasks completed
WARNING: nativesdk-glibc-locale-2.31-r0 do_package: KeyError in .
ERROR: nativesdk-glibc-locale-2.31-r0 do_package: Error executing a python function in exec_python_func() autogenerated:
The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: <module>
0001:
*** 0002:sstate_report_unihash(d)
0003:
File: '/home/parallels/poky/meta/classes/sstate.bbclass', lineno: 833, function: sstate_report_unihash
0829: report_unihash = getattr(bb.parse.siggen, 'report_unihash', None)
0830:
0831: if report_unihash:
0832: ss = sstate_state_fromvars(d)
*** 0833: report_unihash(os.getcwd(), ss['task'], d)
0834:}
0835:
0836:#
0837:# Shell function to decompress and prepare a package for installation
File: '/home/parallels/poky/bitbake/lib/bb/siggen.py', lineno: 512, function: report_unihash
0508:
0509: if "." in self.method:
0510: (module, method) = self.method.rsplit('.', 1)
0511: locs['method'] = getattr(importlib.import_module(module), method)
*** 0512: outhash = bb.utils.better_eval('method(path, sigfile, task, d)', locs)
0513: else:
0514: outhash = bb.utils.better_eval(self.method + '(path, sigfile, task, d)', locs)
0515:
0516: try:
File: '/home/parallels/poky/bitbake/lib/bb/utils.py', lineno: 420, function: better_eval
0416: if extraglobals:
0417: ctx = copy.copy(ctx)
0418: for g in extraglobals:
0419: ctx[g] = extraglobals[g]
*** 0420: return eval(source, ctx, locals)
0421:
0422:@contextmanager
0423:def fileslocked(files):
0424: """Context manager for locking and unlocking file locks."""
File: '<string>', lineno: 1, function: <module>
File "<string>", line 1, in <module>
File: '/home/parallels/poky/meta/lib/oe/sstatesig.py', lineno: 582, function: OEOuthashBasic
0578:
0579: update_hash("\n")
0580:
0581: # Process this directory and all its child files
*** 0582: process(root)
0583: for f in files:
0584: if f == 'fixmepath':
0585: continue
0586: process(os.path.join(root, f))
File: '/home/parallels/poky/meta/lib/oe/sstatesig.py', lineno: 545, function: process
0541: add_perm(stat.S_IXOTH, 'x')
0542:
0543: if include_owners:
0544: try:
*** 0545: update_hash(" %10s" % pwd.getpwuid(s.st_uid).pw_name)
0546: update_hash(" %10s" % grp.getgrgid(s.st_gid).gr_name)
0547: except KeyError:
0548: bb.warn("KeyError in %s" % path)
0549: raise
Exception: KeyError: 'getpwuid(): uid not found: 1000'
ERROR: Logfile of failure stored in: /home/parallels/poky/build/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-glibc-locale/2.31-r0/temp/log.do_package.32088
ERROR: Task (virtual:nativesdk:/home/parallels/poky/meta/recipes-core/glibc/glibc-locale_2.31.bb:do_package) failed with exit code '1'
NOTE: Tasks Summary: Attempted 3799 tasks of which 3798 didn't need to be rerun and 1 failed.
Summary: 1 task failed:
virtual:nativesdk:/home/parallels/poky/meta/recipes-core/glibc/glibc-locale_2.31.bb:do_package
Summary: There was 1 WARNING message shown.
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
|
|
|
|
Re: Yocto Project Status WW04'20
Josef Holzmayr <holzmayr@...>
Howdy!
On Sun, Feb 02, 2020 at 03:09:07PM +0100, Alexander Kanavin wrote: Why separate them? I’d rather have newbies and experts in the same room.My vote is totally on this too! Greetz.
-- ——————————————— Josef Holzmayr Software Developer Embedded Systems Tel: +49 8444 9204-48 Fax: +49 8444 9204-50 R-S-I Elektrotechnik GmbH & Co. KG Woelkestrasse 11 D-85301 Schweitenkirchen www.rsi-elektrotechnik.de ——————————————— Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg Ust-IdNr: DE 128592548 _____________________________________________________________ Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363 Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg USt-IdNr.: DE 128592548 |
|
|
|
Re: Yocto Project Status WW04'20
On Sun, Feb 2, 2020 at 6:09 AM Alexander Kanavin <alex.kanavin@...> wrote: Why separate them? I’d rather have newbies and experts in the same room.. Enthusiastic second to this. If you separate things too much, newbies get no sense of the depth of the project, and experienced people get less of a sense of the "newcomer pain points". Granted, this breaks down when traffic elevates to to LKML levels, but we are not even close to that (yet). ..Ch:W.. |
|
|
|
Re: Yocto Project Status WW04'20
Philip Balister
On 2/2/20 2:28 PM, Adrian Bunk wrote:
On Tue, Jan 28, 2020 at 08:01:23AM -0800, Stephen Jolley wrote:We have openembedded-architecture for this....Would it be possible to also create a yocto-devel or yocto-core http://lists.openembedded.org/mailman/listinfo/openembedded-architecture Philip
|
|
|
|
Re: Yocto Project Status WW04'20
Adrian Bunk
On Sun, Feb 02, 2020 at 03:16:24PM +0000, Ross Burton wrote:
On Sun, 2 Feb 2020 at 13:35, Adrian Bunk <bunk@...> wrote:It would be easier to follow only development discussions if theseWould it be possible to also create a yocto-devel or yocto-coreWhat would it cover that isn't already covered in other lists? would move to a dedicated list. Rosscu Adrian |
|
|
|
[meta-security][PATCH 2/2] ecryptfs-utils: search nspr header files in ${STAGING_INCDIR}/nspr directory
Signed-off-by: Armin Kuster <akuster808@...>
--- recipes-security/ecryptfs-utils/ecryptfs-utils_111.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/recipes-security/ecryptfs-utils/ecryptfs-utils_111.bb b/recipes-security/ecryptfs-utils/ecryptfs-utils_111.bb index e45ee0b..d8cd06f 100644 --- a/recipes-security/ecryptfs-utils/ecryptfs-utils_111.bb +++ b/recipes-security/ecryptfs-utils/ecryptfs-utils_111.bb @@ -41,7 +41,7 @@ PACKAGECONFIG[nss] = "--enable-nss,--disable-nss,nss," PACKAGECONFIG[pam] = "--enable-pam,--disable-pam,libpam," do_configure_prepend() { - export NSS_CFLAGS="-I${STAGING_INCDIR}/nspr4 -I${STAGING_INCDIR}/nss3" + export NSS_CFLAGS="-I${STAGING_INCDIR}/nspr -I${STAGING_INCDIR}/nss3" export NSS_LIBS="-L${STAGING_BASELIBDIR} -lssl3 -lsmime3 -lnss3 -lsoftokn3 -lnssutil3" export KEYUTILS_CFLAGS="-I${STAGING_INCDIR}" export KEYUTILS_LIBS="-L${STAGING_LIBDIR} -lkeyutils" -- 2.17.1 |
|
|
|
[meta-security][PATCH 1/2] swtpm: fix configure error
checking for whether to build with seccomp profile... configure: error: "Is libseccomp-devel installed? -- could not get cflags for libseccomp"
Signed-off-by: Armin Kuster <akuster808@...> --- meta-tpm/recipes-tpm/swtpm/swtpm_0.2.0.bb | 1 + 1 file changed, 1 insertion(+) diff --git a/meta-tpm/recipes-tpm/swtpm/swtpm_0.2.0.bb b/meta-tpm/recipes-tpm/swtpm/swtpm_0.2.0.bb index f3a53dd..35c77c8 100644 --- a/meta-tpm/recipes-tpm/swtpm/swtpm_0.2.0.bb +++ b/meta-tpm/recipes-tpm/swtpm/swtpm_0.2.0.bb @@ -31,6 +31,7 @@ PACKAGECONFIG[openssl] = "--with-openssl, --without-openssl, openssl" PACKAGECONFIG[gnutls] = "--with-gnutls, --without-gnutls, gnutls" PACKAGECONFIG[selinux] = "--with-selinux, --without-selinux, libselinux" PACKAGECONFIG[cuse] = "--with-cuse, --without-cuse, fuse" +PACKAGECONFIG[seccomp] = "--with-seccomp, --without-seccomp, libseccomp" EXTRA_OECONF += "--with-tss-user=${TSS_USER} --with-tss-group=${TSS_GROUP}" -- 2.17.1 |
|
|
|
Re: Yocto Project Status WW04'20
Ross Burton <ross@...>
On Sun, 2 Feb 2020 at 13:35, Adrian Bunk <bunk@...> wrote:
Would it be possible to also create a yocto-devel or yocto-coreWhat would it cover that isn't already covered in other lists? Ross |
|
|
|
Re: Yocto Project Status WW04'20
Alexander Kanavin
Why separate them? I’d rather have newbies and experts in the same room.
toggle quoted message
Show quoted text
Alex On 2 Feb 2020, at 14.28, Adrian Bunk <bunk@...> wrote:On Tue, Jan 28, 2020 at 08:01:23AM -0800, Stephen Jolley wrote:Would it be possible to also create a yocto-devel or yocto-core |
|
|
|
Re: Yocto Project Status WW04'20
Adrian Bunk
On Tue, Jan 28, 2020 at 08:01:23AM -0800, Stephen Jolley wrote:
...Would it be possible to also create a yocto-devel or yocto-core mailing list for discussing development of Yocto? Currently the yocto list is a mixture of core development list and forum for newbie user questions, with no easy way to have them separate. Thanks Adrian |
|
|
|
Difference between: "poky-glibc-i686-core-image-sato-cortexa8hf-neon-toolchain" and "poky-glibc-i686-core-image-sato-cortexa8hf-neon-beaglebone-yocto-toolchain"
#yocto
Milun Jovanovic
I apologize community for disturb but I have one simple question
A colleague has left company and now I have a job to update tool-chain from 2.2.2 to something newer. The latest8by date) release of toolchain with the same name appears in 2.6.4 release. There is something that little confuses me , actually I see "my" processor in 3.0.1 release but it appears extra "beaglebone" sting in toolchain. The question is : May I use 3.0.1 toolchain for cortex8hf ? Does presence of beglebone board name makes difference for cortexa8hf in 3.0.1? http://downloads.yoctoproject.org/releases/yocto/yocto-2.6.4/toolchain/i686/poky-glibc-i686-core-image-sato-cortexa8hf-neon-toolchain-2.6.4.sh http://downloads.yoctoproject.org/releases/yocto/yocto-3.0.1/toolchain/i686/poky-glibc-i686-core-image-sato-cortexa8hf-neon-beaglebone-yocto-toolchain-3.0.1.sh Thank you in advance Milun |
|
|
|
Re: Sad news about Scott Rifenbark
Nicholas Krause
On 1/31/20 4:04 PM, Richard Purdie
wrote:
Richard,I'm sorry to have to pass on the sad news that Scott Rifenbark, our tech writer for the project passed away on Wednesday after a battle with cancer. I remember interviewing Scott over 10 years ago when forming a team at Intel to work on what became the Yocto Project, he was with it from the start. He warned me he wasn't an entirely traditional tech writer but I warned we weren't aiming to be a traditional project either. It was a great match. He stayed with the project ever since in one way or another, he enjoyed working on the project and we enjoyed working with him. The concept of having a tech writer as part of the team was a decision I'm proud of and it shows in the material supporting the project today but that success belongs to Scott and his approach to it. Someone else put that best, "He would first try the procedure or instructions before documenting it, I was really impressed". He was hands on and wanted things to be understandable and correct, a huge challenge with some of the complexities we deal with. Outside of the project he had interesting hobbies and travelled quite a bit, those stories were good over beer and I have many fond memories. Our documentation stands in his memory and its fitting some of his character will always be in those words. Scott will be hugely missed by us all. As someone who's been on and off with the project I've always found the documentation was some of the best documentation I've ever seen rivaling that of the compiler manuals and wikis for LLVM and GCC in terms of being complete technical documents or the ISA manuals. Sorry to hear one if not the major tech writer behind it has passed and I've been spoiled by the great documentation or the parts he wrote, Nick |
|
|
|
Re: [meta-openssl102-fips][PATCH] openssh: Fix patch to properly apply on 7.9 version found in warrior
Mark Hatle
Thanks for the pull request.. pushed.
toggle quoted message
Show quoted text
--Mark On 1/29/20 9:08 PM, Mark Hatle wrote:
|
|
|
|
Sad news about Scott Rifenbark
Richard Purdie
I'm sorry to have to pass on the sad news that Scott Rifenbark, our
tech writer for the project passed away on Wednesday after a battle with cancer. I remember interviewing Scott over 10 years ago when forming a team at Intel to work on what became the Yocto Project, he was with it from the start. He warned me he wasn't an entirely traditional tech writer but I warned we weren't aiming to be a traditional project either. It was a great match. He stayed with the project ever since in one way or another, he enjoyed working on the project and we enjoyed working with him. The concept of having a tech writer as part of the team was a decision I'm proud of and it shows in the material supporting the project today but that success belongs to Scott and his approach to it. Someone else put that best, "He would first try the procedure or instructions before documenting it, I was really impressed". He was hands on and wanted things to be understandable and correct, a huge challenge with some of the complexities we deal with. Outside of the project he had interesting hobbies and travelled quite a bit, those stories were good over beer and I have many fond memories. Our documentation stands in his memory and its fitting some of his character will always be in those words. Scott will be hugely missed by us all. |
|
|
|
Re: QA Cycle report for build (yocto-3.1_M2.rc1)
Sangeeta,
On 1/30/20 11:46 PM, Sangeeta Jain
wrote:
Please bug the test_mmc and test_usb as I am the one who added those storage test.Hello All, This is the full report for yocto-3.1_M2.rc1: https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults ======= Summary ======== No high milestone defects. No new defects are found in this cycle. starce ptest failed (BUG id:13765). Note: failure for test_ltp_help, test_stap, test_mmc_mount, test_usb_mount is observed on Beaglebone, edgerouter and mpc8315erdb. TIA, armin QA team is analysing more on failures. ======= Bugs ======== https://bugzilla.yoctoproject.org/show_bug.cgi?id=13765 Thanks, Sangeeta-----Original Message----- From: Pokybuild User <pokybuild@...> Sent: Thursday, 23 January, 2020 5:25 AM To: yocto@... Cc: otavio@...; yi.zhao@...; Sangal, Apoorv <apoorv.sangal@...>; Yeoh, Ee Peng <ee.peng.yeoh@...>; Chan, Aaron Chun Yew <aaron.chun.yew.chan@...>; richard.purdie@...; akuster808@...; sjolley.yp.pm@...; Jain, Sangeeta <sangeeta.jain@...> Subject: QA notification for completed autobuilder build (yocto-3.1_M2.rc1) A build flagged for QA (yocto-3.1_M2.rc1) was completed on the autobuilder and is available at: https://autobuilder.yocto.io/pub/releases/yocto-3.1_M2.rc1 Build hash information: bitbake: d5a4a352723258b4d499d3a51f340109c4f36f60 meta-gplv2: 6107be140fdec204586850ea1f7e4b968be7670b meta-intel: 0c092dde58bb688dca787c653ee7a3282d58aeab meta-mingw: e3dadc9f28c24a8d182121d0246b3d9ec048846a oecore: 15049c610bcfd0a3e161379651b5ea117ea02715 poky: ca3993cc4b13d4e661228cee6fb9448adfd0a4ba This is an automated message from the Yocto Project Autobuilder Git: git://git.yoctoproject.org/yocto-autobuilder2 Email: richard.purdie@... |
|
|
|
On 1/31/20 4:02 AM, georgi.georgiev via Lists.Yoctoproject.Org wrote:
Hello Community, svn: E170013: Unable to connect to a repository at URL 'http://cocosubversion/svn/Embedded/Valve&Actuator/DVPII/trunk/SOCPACManEnvEngKeys/trunk' svn: E670003: Temporary failure in name resolution can you try checking out the repo out side of fetcher and see if the machine can fetch the url you are using in SRC_URI ? *SUMMARY = "PACMan - Parameter And Configuration MANager"* |
|
|