**** BEGIN LOGGING AT Tue Apr 13 02:59:56 2021 Apr 13 07:26:34 yo dudX Apr 13 09:05:23 Mornin' folks Apr 13 09:07:23 vdl: IIRC, dm-verity requires a squashfs, so if there's a way to specify config fragments dependencies, do it that way. But as khem said, it's up to you, you can have config fragments per feature or per "machine" configruation. It's up to the BSP layer maintainer to decide Apr 13 09:30:17 i'm trying to backport openssl 1.1.1k in our thud branch (openssl 1.1.1b is the default in poky)... I do not understand why Yocto is complaining "Multiple versions of openssl are due to be built. . Only one version of a given PN should be built in any given build. You likely need to set PREFERRED_VERSION_opens Apr 13 09:30:35 sl to select the correct version or don't depend on multiple versions." Apr 13 09:30:59 I even set PREFERRED_VERSION_openssl in my machine configuration file (which IMO shouldn't be needed?) but to no avail Apr 13 09:31:57 is this an issue with the 1.1.1k and 1.1.1b version not being different enough (does Yocto take correctly into account the k/b part of PN?) Apr 13 09:41:55 qschulz: it absolutely does take the full version string into account Apr 13 09:42:34 probably worth running bitbake -e | less and then search for PREFERRED_VERSION_openssl to see if your setting is being overridden somewhere Apr 13 09:48:15 bluelightning: PREFERRED_VERSION is correctly set, but why is it needed in the first place? my two layers are of different priorities so the one with the highest prio should be the one providing openssl shouldn't it? Apr 13 09:48:54 qschulz: there must be a a PROVIDES and corresponding DEPENDS which is forcing the other one to be picked as well Apr 13 09:49:43 bitbake -DDD should report more detail about how the selection is happening Apr 13 09:50:00 (it would be nice if it would just do so up front in the warning... hmm) Apr 13 09:51:22 so, it seems to work just fine if I ask to build openssl explicitly (picks the 1.1.1k) Apr 13 09:51:32 I'll let you know but the PROVIDES is a good pointer Apr 13 10:13:05 bluelightning: aaaaaaaaarrrrrrrrrgggggggggggggggggggg http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-connectivity/openssl/openssl_1.1.1b.bb?h=thud#n210 Apr 13 10:13:55 ? Apr 13 10:13:57 (we unfortunately use openssl10-conf (that I expected to be coming from openssl10 recipe and not openssl) Apr 13 10:14:19 oh line 209 Apr 13 10:14:55 bluelightning: ah yeah sorry, it does not seem to highlight the line as on github/gitlab Apr 13 10:19:32 bluelightning: thank you very much for the -DDD pointer, very verbose but very helpful. I think I rely a bit too much on bitbake -e those days :) Apr 13 10:19:44 no worries Apr 13 10:30:16 and to be complete, for the IRC archive, RPROVIDES_openssl-conf = "openssl10-conf" RREPLACES_openssl-conf = "openssl10-conf" RCONFLICTS_openssl-conf = "openssl10-conf" needed to be added to 1.1.1k recipe since we are still using openssl10 somewhere else and thus 1.1.1b which has those lines was picked for openssl10-conf instead of 1.1.1k Apr 13 11:41:43 ecdhe: re inotify, if you patch it out, yes. why? doesn't cause problems really. Apr 13 14:52:28 rburton: is inotify hard to patch out? Was attempting specifically to bitbake on not-linux Apr 13 14:55:56 ecdhe: Probably.... I think that's going to be a pretty uphill battle Apr 13 14:56:57 ecdhe: if you're thinking BSD then the code isn't *hard* to patch out Apr 13 14:57:09 that's where I'm headed with this Apr 13 14:57:15 but building a linux platform on BSD isn't trivial Apr 13 14:57:27 rburton: any prior art I could reference? Apr 13 14:57:33 I've heard the failure stories Apr 13 14:57:40 poky-contrib:ross/darwin if it exists Apr 13 14:57:57 it was basically commenting out the inotify bits Apr 13 14:58:08 the problem is building on bsd, inotify is trivial Apr 13 15:00:57 rburton: I was going to start just by bitbaking a few recipes Apr 13 15:01:09 all the breakage will be in bootstrap Apr 13 15:01:31 feel free to give it a go Apr 13 15:01:36 but its a world of pain Apr 13 15:01:43 bootstrap... bootstrapping gcc? Apr 13 15:01:52 all the native stuff, but yes gcc included Apr 13 15:02:10 feel free to give it a go but there's a reason containers are awesome Apr 13 15:02:41 containers are indeed very useful Apr 13 15:04:39 one of the most annoying things is packages that assume tools are gnu tools Apr 13 15:05:01 especially in tools which are linux specific so don't expect to be cross-compiled on bsd Apr 13 15:05:20 rburton: it helps that flags like sed -i are becoming more common in non gnu tools Apr 13 15:05:51 and i've no idea when pseudo on bsd was last tested Apr 13 15:06:57 rburton: just to be honest, that's the first thing you've mentioned that unfamiliar to me Apr 13 15:07:17 I've looked at the gcc bootstrapping process and all dependencies Apr 13 15:07:39 I'd say the problems are 1) pseudo 2) gnu-assumptions Apr 13 15:08:00 start by building pseudo outside of OE and running the test suite Apr 13 15:08:41 rburton: gnumptions? Apr 13 15:13:31 ross/darwin is gone https://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=ross/darwin Apr 13 15:13:56 i probably blew it away as it didn't work, was years old, and was mostly just commenting stuff out Apr 13 15:14:09 start with pseudo, then you don't have to worry about bitbake yet :) Apr 13 15:41:17 I'm having a really weird issue fetching something with git. I can't pass git a git:// link, I must use ssh://. but when I use ssh:// bitbake tries to use scp Apr 13 15:41:24 how do I change this behavior Apr 13 15:42:32 I am absolutely positive this is the issue, even if that solution is not the one, because normal git invocations can't accept git:// uris Apr 13 15:49:50 R0b0t1: missing a protocol= parameter, maybe? Apr 13 15:50:57 haha I just found that Apr 13 15:50:59 thanks Apr 13 15:53:09 R0b0t1: have fun. Apr 13 16:26:03 RP: they reason they probably said 5.10 is that there were some filesystem fixes in 5.10 for y2038 Apr 13 16:26:33 and the other version is more 5.6 than 5.5 Apr 13 16:39:29 Hi Apr 13 16:39:39 Is anyone here who uses icecream? Apr 13 16:43:59 i think JPEW does but we're in the technical call right now Apr 13 16:45:01 I know he does, he helped me earlier Apr 13 16:45:13 Thanks, than I'll wait for him Apr 13 16:47:14 JPEW: poky-contrib:ross/taskthreads is something related i kicked a bit at a while ago Apr 13 16:59:26 I actually have pretty basic issue with it, so if someone could point to a description, I would be happy with it Apr 13 17:00:35 I'm building arm right now, and I don't understand the concept how the compiler and stuff should be deployed to the machines Apr 13 17:44:45 linums: what's the question? Apr 13 17:53:30 I would like to know how can I copy the cross compiler, and the libs needed for the packages to the build agents through yocto Apr 13 17:54:06 Because they're not present during the build on the slave build agents Apr 13 17:54:48 But it is pretty obvious that I should not do it manually :D Apr 13 18:13:23 hi there, is there any known problem about missing licenses when rebuilding some image using yocto? Apr 13 18:13:30 here's the background Apr 13 18:13:54 i am working on some proprietary project and was able to completely build an image Apr 13 18:14:00 linums: icecc will copy the toolchain to the builders; this should happen automatically if you are using icecc.bbclass Apr 13 18:14:19 now during a rebuild, get lot's of warnings about: The license listed Zlib was not in the licenses collected for recipe zlib Apr 13 18:14:33 in the end the whole build fails, due to some missing file Apr 13 18:15:00 @creich: which Yocto version do you use? Apr 13 18:15:55 https://dpaste.com/94VMQ43LM Apr 13 18:16:12 RobertBerger: how can i find out? Apr 13 18:16:25 i am new to the project and the image configuration was already there Apr 13 18:16:43 i encountered the problem several time now and always ended up rebuilding everything from scratch Apr 13 18:16:50 @creich: all your layers should have the same version, so it would be a good idea to find out ;) Apr 13 18:16:58 but i would like to get a deeper understanding and probably fix it Apr 13 18:17:01 @creich: typically it's branches Apr 13 18:17:44 @creich: let's see your layers first: bitbake-layers show layers Apr 13 18:17:59 show-layers Apr 13 18:18:54 @creich: version: bitbake -e | grep ^DISTRO_VERSION= Apr 13 18:19:26 @creich: which you should also see when you bitbake something Apr 13 18:19:36 i found 'zeus' btw Apr 13 18:19:47 OK - old ;) Apr 13 18:20:31 ok. but old doesn't explain why that problem just occurs out of nothing Apr 13 18:20:55 v2019.12 Apr 13 18:20:57 btw Apr 13 18:21:08 but where should i start to dig? Apr 13 18:21:28 e.g. i tried to rebuild glibc Apr 13 18:21:37 linums: Specifically, the ICECC_ENV_EXEC specifies the script that builds the toolchain archive, the patch of which is stored in the poorly named ICECC_VERSION variable. icecc uses ICECC_VERSION as an environment variable to know which toolchain to send to the remote builder Apr 13 18:22:03 even checked listtasks and tried to run populate_lic Apr 13 18:22:10 nothing worked Apr 13 18:22:31 if i rebuild it from scratch i guess the files will be back and everything works as expected :/ Apr 13 18:22:45 but it feels wrong to always use that kind of 'solution' Apr 13 18:23:24 if there is any doucumentation i should read on 'how to debug..' or smth i'd be glad ti get some hints :) Apr 13 18:25:52 JPEW: now I've realized, that I'm not using icecc properly Apr 13 18:25:56 Thanks Apr 13 18:28:03 #creich: Does your problem only occur when you build an image, or when you build the package? Apr 13 18:28:32 i build an image Apr 13 18:29:44 from reading the error message i posted, it seems like there is some part trying to collect all license information Apr 13 18:29:54 but it doesn't find some files and thus brakes Apr 13 18:30:04 @creich: it tries to create the license manifest and fails Apr 13 18:30:12 the part i don't understand is how those files got lost in the first place Apr 13 18:30:40 just to rule out any local changes, i go back to rebuild on a clean workspace again Apr 13 18:30:50 and try to keep very close track to my steps Apr 13 18:31:00 maybe i broke something without noticing Apr 13 18:31:24 but the only thing i did after the last build was adding a 'one line' bbappend file Apr 13 18:31:33 removing it didn't solve the problem Apr 13 18:32:02 @creich: at least zlib should work ;) Apr 13 18:32:41 i was just trying to disable one systemd service Apr 13 18:32:51 but that shouldn't explain the current problem Apr 13 18:33:01 anyways, thx for the time and help so far Apr 13 18:33:14 @creich: what is this? /home/user/coding/c3ecu/tmp-angstrom-glibc/../deploy/glibc/licenses/hem20/state-scripts-umi/recipeinfo Apr 13 18:33:14 as i said, i'll just try to rebuild and see if that at least works again Apr 13 18:33:44 i don't know.. i thought thats part of the normal build process Apr 13 18:33:54 i can investigate Apr 13 18:35:06 openembedded-core/meta/classes/license.bbclass: with open(os.path.join(destdir, "recipeinfo"), "w") as f: Apr 13 18:35:14 seems to be part of openembedded Apr 13 21:34:22 Recently installed an SDK generated with hardknott and got: tar: ./sysroots/armv7vet2hf-neon-poky-linux-gnueabi/dev/console: Cannot mknod: Operation not permitted Apr 13 21:35:25 Any ideas? Apr 13 21:47:48 can I use the SYSTEMD_SERVICE to run an application which is not a service at boot up? Or what is the preferred way to start an application at boot up if it is not by means of a systemd service? Apr 13 21:51:57 Hi everyone, if I have to add e.g. nodejs into our recipe (I'm using kas and doing the development into a single recipe) what should I do? I've tried to add IMAGE_INSTALL_append = " nodejs" and added the meta-oe layer into the project but I get Apr 13 21:52:01 ERROR: ParseError at /work/deps/meta-oe/meta-oe/recipes-dbs/postgresql/postgresql.inc:39: Could not inherit file classes/python3targetconfig.bbclass#################### Apr 13 21:52:43 unless there's an error with the python3targetconfig recipe because the other inherit mentioned in http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-dbs/postgresql/postgresql.inc#n39 work? Apr 13 21:53:08 are you using same branches for both oe-core/poky and meta-openembedded repo ? Apr 13 21:53:52 I think so, 3.2 is gatesgarth right? https://gist.github.com/alex88/44c484ea81758c63b42e20f2f692bedf Apr 13 21:56:48 Any clue why a cm4 image won't boot when u-boot is enabled. It seems to work fine when not using u-boot Apr 13 22:01:06 hi, is there an intended way to build for a chroot so that things can be run on an x86 machine? Apr 13 22:10:15 seems that changing to gatesgarth-next changes the error to "ERROR: ParseError at /work/deps/meta-oe/meta-oe/recipes-extended/libimobiledevice/libplist_2.2.0.bb:9: Could not inherit file classes/python3targetconfig.bbclass" Apr 13 22:10:39 don't think it's a bug with the layer tho, I mean it's a simple image with nodejs.. nothing too crazy :) Apr 13 22:14:28 oh seems that I have to update oe-core https://github.com/openembedded/meta-openembedded/issues/317 but that needs to be done in the poky repo? Apr 13 22:15:01 because if I try to get oe-core myself I get "Multiple init scripts found (openembedded-core vs. poky)." Apr 13 22:18:09 just use latest dunfell branch of poky Apr 13 22:18:23 and latest dunfell for meta-openembedded Apr 13 22:18:38 dunfell instead of gatesgarth? Apr 13 22:18:58 oh, just saw that 3.2 doesn't 3.2.x but 3.2.0, I'm trying with 3.2.3 now Apr 13 22:19:05 *doesn't mean Apr 13 22:19:56 yeah use latest of gatesgarth if you are on gatesgarrth Apr 13 22:20:15 thanks khem! let's wait for the 1.7k tasks now :) Apr 13 22:25:26 hello, was trying instructions here: https://docs.yoctoproject.org/3.2.3/brief-yoctoprojectqs/brief-yoctoprojectqs.html on fedora 34 and got errors on the `bitbake core-image-sato` or `bitbake core-image-minimal` step. `| ../../elfutils-0.180/libebl/libebl.h:248:46: note: previously declared as an array ‘int[6]’` on the minimal one and `ERROR: Task Apr 13 22:25:26 (virtual:native:/home/craig/src/poky/meta/recipes-devtools/ninja/ninja_1.10.1.bb:do_compile) failed with exit code '1'` with sato. Any tips? Would fedora 33 be a better idea? (obviously not beta so certainly a good idea to revert to 33) Apr 13 22:56:23 hmm, anyone created selftests to deploy into new layers which run yocto-check-layer against it? debating adding selftests to every layer i create to test aspects of it, starting with compatibility Apr 13 23:01:26 I am trying ubuntu 20.04 instead since that is mentioned as supported and ubuntu is mentioned "first" in instructions. :) Apr 14 00:28:44 is there a standard way/config/deamon to manage and configure modems? Apr 14 01:35:58 if I have to wrap a node-red recipe, to create for example a user, a systemd service etc, should I create a recipe? because reading the docs it seems that you need to provide a source path **** ENDING LOGGING AT Wed Apr 14 02:59:56 2021