**** BEGIN LOGGING AT Tue Mar 16 03:03:12 2021 Mar 16 07:44:34 yo dudX Mar 16 07:46:47 * LetoThe2nd opens mail, facepalms, calms down, then is auhbombed. nice way to start out a day. where's my beer? Mar 16 07:54:29 hello Mar 16 07:58:52 good morning Mar 16 08:16:42 BSPs, sigh. I wonder if SoC users should collectively start talking to SoC vendors about their layers and problems. When sstate cache goes *gaboom* after BSP update, that isn't a good sign. Surely others have seen or will see this too. Sadly yocto-check-layers also fails on meta-openembedded so running it on BSP layers feels like overkill right now. There would need to be some subset of the checks that I Mar 16 08:16:49 could run on BSP layers. Mar 16 08:25:16 mcfrisk: I feel like having BSP of proper quality would already be a HUGE improvement. I feel like build system is more accessible to newcomers than kernel/bootloader/authentication/signing/optee/atf/whatever. But I feel you, sometimes it seems they just throw some stuff at you and say "deal with it" Mar 16 08:25:22 mornin' folks Mar 16 08:31:35 BSP layer with custom npm bbclasses, what could possibly go wrong /fp Mar 16 08:33:09 fully forked gobject-introspection.bbclass, wtf's per minute is increasing rapidly Mar 16 09:03:08 @RP: you seem to be familiar with meson in poky. Could you help me find an answer to the nativesdk-meson question (i.e. `TARGET_SYS`) I posted above? Mar 16 09:18:26 I don't know why my recipe work when I put in local.conf IMAGE_INSTALL_append = " program" but if I do IMAGE_INSTALL = " program" I got cannot set terminal process group (-1): Inappropriate ioctl for device error when I launch runqemu qemux64-86 Mar 16 09:21:10 jdrol: you override the IMAGE_INSTALL variable, which is the variable telling Yocto which packages to install, so you'll be missing a hell of a lot Mar 16 09:21:48 qschulz, oups I wrote += no = Mar 16 09:24:00 jdrol: and where do you do put those? both in local.conf? you can always inspect the whole evalutation history in bitbake -e and look for differences. Mar 16 09:24:20 jdrol: also, see https://theyoctojester.info/session_14/main.html Mar 16 09:24:34 ok ... Mar 16 09:24:37 thanks Mar 16 09:28:22 jdrol: rule of thumb, no += =+ .= =. in configuration files to append/prepend stuff Mar 16 09:28:30 jdrol: only _append or _prepend Mar 16 09:29:21 the issue is in which order files are parsed. conf files are parsed before classes and recipes, therefore += will actually make ?= ??= to not be applied, because += assign directly the variable if it does not exist already Mar 16 09:29:24 ok thanks Mar 16 09:30:04 I know the theory of immediate ... and at running .. Mar 16 09:30:10 many thanks Mar 16 09:44:10 other think I installed my recipe with cmake and I added do_install() ... is it possible to ask to cmake to install directly in /usr/bin ? Mar 16 09:45:01 jdrol: you can always hardcode stuff. you should never hardcode stuff. Mar 16 09:47:33 do-install() is not hardcoded ? Mar 16 09:49:19 jdrol: yes it is possible, you need an install target in your CmakeLists.txt and install in the correct path (NOT /usr/bin, something like CMAKE_BIN_TARGET or something like that, something Cmake specific and I don't do cmake so can't help more :) ) Mar 16 09:49:31 do_install adheres to the cmake install targets you define and the bindir variable. so no, do_install is essentially not hardcoded. Mar 16 09:50:17 thanks Mar 16 09:52:12 I lost time with scripts from yoctoproject.net now It is fine Mar 16 09:59:41 just so I get this straight: assuming a setup with `{host=x86_64-win, target=arm-linux, build=x86_64-linux}`, `nativesdk` recipes will set `TARGET_SYS` to `x86_64-win`? Mar 16 10:08:48 t_unix[m]: meson nativesdk should target whatever SDKMACHINE/SDK_ARCH is set to Mar 16 10:09:20 in master it defaults to the build host, previously it was x86-64 Mar 16 10:12:03 SDK* refers to the machine, the SDK will be executed on, right? Mar 16 10:14:42 yes Mar 16 10:15:04 I build on arm64-linux but I can set SDKMACHINE to x86-mingw64 (or whatever it is) to build a windows/x86 SDK Mar 16 10:16:41 why are the `target` variables values set to those of the corresponding `host` (i.e. `SDK`)? Mar 16 10:49:51 rburton: the crossfile provided by `nativesdk-meson` is intended to be used to cross compile to the target, isn't it? So it's `[host_machine]` section should refer to the target, shouldn't it? Unless it is intended to be used to cross compile a compiler itself, in which case `[host_machine]` should refer to `SDK*` and a `[target_machine]` section should be introduced? Mar 16 11:28:36 RP: did not forget the AB-helper changes ... they'll come asap. Did TSC receive the form ? Any questions/feedback ? Mar 16 11:33:00 dl9pf: We messed up agenda but its on the list for today. Several positive feedbacks so far Mar 16 11:33:19 roger Mar 16 11:47:25 hello. I'm using dunfell and whenever I do "devtool modify virtual/kernel" it fails at preconfigure step with "cannot open /path/linux-fslc/5.4.51+gitAUTOINC+d051c7c9af-r0/devtooltmp-/workdir/defconfig: No such file". Mar 16 11:47:36 is this a known issue? my kernel builds fine with my defconfig Mar 16 11:48:07 I can't create any kernel patches because of this.. Mar 16 11:48:35 my defconfig is appended in SRC_URI with "file://defconfig" Mar 16 12:01:26 cengiz_io_: http://git.yoctoproject.org/cgit/cgit.cgi/meta-freescale/tree/classes/fsl-kernel-localversion.bbclass?h=dunfell Mar 16 12:02:51 check that ${WORKDIR} is correctly set Mar 16 12:03:03 otherwise it might just be some ordering of tasks or something no idea frankly speaking Mar 16 12:04:13 qschulz: I will check the bb file that I'm appending. Mar 16 12:04:48 qschulz: and there's this also, which I can't apply manually, don't know if it fixes anything Mar 16 12:04:49 https://github.com/Freescale/meta-freescale/pull/652 Mar 16 12:06:45 qschulz: what baffles me is, kernel gets compiled with right defconfig but only devtool complains Mar 16 12:07:10 cengiz_io_: devtool has a different file layout, so I'm not surprised Mar 16 12:07:34 e.g. ${WORKDIR} is not where SRC_URI files are unpacked Mar 16 12:07:40 qschulz: is there a super-hacky way of generating patches without devtool? bitbake -c menuconfig simply won't help Mar 16 12:08:03 cengiz_io_: just override this task Mar 16 12:08:20 or do_preconfigure[noexec] = "1" Mar 16 12:08:29 thank you Mar 16 12:08:41 otherwise, I always do the kernel modification on my own with a cloned kernel git repo outside of yocto Mar 16 12:09:07 qschulz: that introduces too much maintainence work for me.. Mar 16 12:09:23 I just want whatever meta-freescale distributes Mar 16 12:09:30 with 2-3 patches Mar 16 12:11:35 qschulz: if, say I would do that mirror repo with my patches, how can I override my meta-freescale choice? by forcing it in machine conf? Mar 16 12:12:05 cengiz_io_: ? no, you git clone meta-freescale kernel git repo locally, do your changes, create the patches with git format-patch, then put the patches in your layer, get rid of you local kernel repo, and voilà Mar 16 12:12:37 ah. Mar 16 12:13:16 that makes sense. devtool will be still broken, patches will still reside in my recipes-kernel and bbappend will still be needed then Mar 16 12:18:14 cengiz_io_: yup, anyway I'm not sure devtool'ed kernel works well with out-of-tree kernel drivers if you have any. Mar 16 12:18:38 I'd need to check one day why it does not work for me on thud and if it still the case for newer Yocto releases Mar 16 12:18:46 qschulz: I actually did the thing in reverse. Mar 16 12:19:15 cloned linux-fslc, checked out specific commit, patched my driver in, enabled configs, compiled. Mar 16 12:19:32 I was going to replicate those as patches into my recipe Mar 16 12:19:48 I always loved how devtool handled things Mar 16 12:20:05 never been able to get it to work since I switched to dunfell Mar 16 12:20:26 cengiz_io_: might be an issue with meta-freescale honestly Mar 16 12:20:38 there's a pr from 29 days ago Mar 16 12:20:51 I know, I read it, is it fixing your issue? Mar 16 12:21:06 (I read the PR not the linked mail) Mar 16 12:21:07 now I only have to wait for 1) meta-freescale to be tagged 2) AGL to update their revision number of meta-freescale Mar 16 12:21:17 have no idea :D Mar 16 12:23:04 cengiz_io_: backport the commit locally and test Mar 16 12:24:15 cengiz_io_: actually, pretty simple, create a bbappend for your kernel recipe Mar 16 12:24:27 qschulz: I have one Mar 16 12:24:57 cengiz_io_: KBRANCH = "5.4.x+fslc" Mar 16 12:25:08 just add it huh? Mar 16 12:25:19 cengiz_io_: SRC_URI = "git://github.com/Freescale/linux-fslc.git;branch=${KBRANCH} \ file://defconfig" Mar 16 12:25:22 and you're good to go Mar 16 12:25:57 bb already does have a git:// scm url Mar 16 12:26:07 will this override it? Mar 16 12:26:23 or a duplicate Mar 16 12:28:35 qschulz: it worked! wohoo Mar 16 12:30:50 cengiz_io_: it'll override, that's the whole point Mar 16 12:31:07 once you upgrade meta-freescale/AGL, remove those Mar 16 12:31:20 yeah I have SRC_URI += " Mar 16 12:31:26 so I assumed it will append Mar 16 12:31:35 cengiz_io_: no, you should have =, not += Mar 16 12:31:41 in bbappend? Mar 16 12:31:42 ok Mar 16 12:31:52 cengiz_io_: for THIS very SPECIFIC case yes Mar 16 12:32:24 yeah. .bb does all the other things for me EXCEPT for this one Mar 16 12:32:26 cengiz_io_: I would suggest to have the SRC_URI with the git URL and defconfig in one SRC_URI in your bbappend (with =_ Mar 16 12:32:49 and then += for your patches so it's easy to remove the overridden SRC_URI without making mistakes when upgrading :) Mar 16 12:32:58 good idea. thanks a lot Mar 16 12:46:10 yesterday Saur suggested (thanks Saur) to use "bitbake -g -u taskexp Mar 16 12:46:10 ` to get a GUI to explore the task Mar 16 12:46:15 dependencies Mar 16 12:46:25 what is "taskexp"? Mar 16 12:48:05 is it "comile", "install", configure", "patch", etc. as shown here: https://www.aosabook.org/en/yocto.html Mar 16 12:51:49 yates: https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#migration-2.3-bitbake-changes Mar 16 12:53:06 oh! no, that is the name ofa gui Mar 16 12:53:51 yates: exactly, taskexp is the keyword for the viewer. Mar 16 13:25:51 are yocto .bbclass files essentially python? Mar 16 13:27:11 for exanmple in one .bbclass file i see "COMPLEMENTARY_GLOB[dev-pkgs] = '*-dev'". is this setting up a python dict? Mar 16 13:28:37 rburton: you stated "12:06 yates: the gcc and binutils recipes". are those usually part of the meta-toolchain layer? Mar 16 13:47:46 yates: there is no meta-toolchain layer. they are in oe-core, just look at the files. Mar 16 13:51:54 in what timezone is the weekly call? is it in ~1h10m? Mar 16 13:54:46 rburton: i see you are correct. by "the files" (of which there are thousands...), to you mean starting with meta/recipes-core/meta/meta-toolchain.bb? Mar 16 13:55:21 are yocto .bbclass files essentially python? Mar 16 13:55:29 meta-toolchain is a recipe that builds a minimal SDK Mar 16 13:55:37 bbclass files can contain python, just like a recipe can Mar 16 13:56:49 tlwoerner: afaik its pinned to UK time so two hours away Mar 16 14:06:50 was the "Application Development Toolkit (ADT)" document removed from the yocto documentation? i found this 1.8.2 version but substituting "latest" comes up empty Mar 16 14:07:14 was it replaced with https://docs.yoctoproject.org/sdk-manual/index.html ? Mar 16 14:07:24 yates: no replacement Mar 16 14:08:15 qschulz: so yocto no longer provides an ADT? or did you just remove the document for some strange reason? Mar 16 14:15:24 yates: I was wrong, see https://docs.yoctoproject.org/ref-manual/migration-2.1.html#adt-removed Mar 16 14:31:08 hello guys ! I have some applications under the /myapp folder  on the target board Mar 16 14:31:26 how can I "instruct" bitbake to add that folder to the PATH variable ? Mar 16 14:31:42 when compiling the image Mar 16 14:32:46 Hey, I would like to modify an image right before flashing. I uncompressed the .bzip2 image, mounted the partition I would like to change. I then modified what I needed and ran `bmaptool create` to generate a new `.bmap` file. Unfortunately, the new bmap file simply maps the entire filesystem with a single entry. Is there any way to recycle the original much more fine grained (and therefore faster to write) Mar 16 14:32:47 bmap file? Mar 16 14:37:28 emrius: what about creating your own IMAGE_CMD? Mar 16 14:37:47 just giving paths to explore Mar 16 14:53:30 rburton: it seems the meeting is now-ish Mar 16 14:54:19 rburton: I'm pretty sure it's phrased in terms of Pacific Standard Time, so in 5 minutes Mar 16 15:01:13 JPEW: so you'll be joining then? Mar 16 15:02:44 qschulz: Thanks for the incentive. I'd like to have this as a post-processing step. So, this is not really an option. Mar 16 15:16:17 RP: The oeselftest directory is missing from gatesgarth (and dunfell): https://git.yoctoproject.org/cgit.cgi/yocto-testresults/tree/ vs https://git.yoctoproject.org/cgit.cgi/yocto-testresults/tree/?h=gatesgarth Mar 16 15:17:18 JPEW: hmm. it shouldn't be :/ Mar 16 15:19:54 JPEW: they are run in the releases: http://downloads.yoctoproject.org/releases/yocto/yocto-3.2.2/testresults/oe-selftest-centos/ Mar 16 15:25:13 Hmm, but where are the results for non-tagged builds placed? Mar 16 15:28:21 JPEW: non-release on the autobuilder Mar 16 15:29:12 JPEW: https://autobuilder.yocto.io/pub/non-release/20210304-5/testresults/ but the idea was the git repo collected things up Mar 16 15:29:53 the git repo is now large and unmanagable :( Mar 16 15:41:33 Is there a yocto variable to execute a host script after a successful build to e.g. prepare a release tarball? Mar 16 15:45:48 so the calendar entry i have is utc not pst Mar 16 15:54:23 JPEW: looks like there are multiple commits on the gatesgarth head. gatesgarth~1 does have an oe selftest file Mar 16 15:55:00 RP: Huh... weird Mar 16 16:28:55 RP: from the minutes, "some high-profile issues have highlighted the need for reproducible builds" Mar 16 16:29:08 RP: I'm curious about the specifics :) Mar 16 16:29:14 what high profile issues? :) Mar 16 16:55:30 How do you guys handle the built images for release tarballs for example. Do you wrap the bitbake call into a custom script or do you integrate the release generation (or whatever post-build steps) into the bitbake process? Mar 16 17:01:21 qschulz: ok thanks. the clarification is much-appreciated. Mar 16 17:03:54 vdl: depends what makes the release generation step. If it involves signing, probably something manual to be done with your images on an air-gapped PC Mar 16 17:04:31 kanavin: the solarwinds hack - people are waking up to the issues Mar 16 17:24:21 RP: thanks, this is the link most relevant to us I guess https://www.linuxfoundation.org/en/blog/preventing-supply-chain-attacks-like-solarwinds/ Mar 16 17:24:50 kanavin: right, it has people thinking about supply chain Mar 16 17:40:57 RP: we certainly need to engage with go upstream, it's the hairiest item to address Mar 16 17:41:17 or you know, take it out of core, which doesn't solve the real problem Mar 16 17:45:06 go was kind of a disaster to use when it was out of core. Mar 16 17:45:13 * zeddii remembers it well. Mar 16 17:47:10 heh. for fun, I just searched for reproducibility and go. And my first hit claims it is reproducible by default :D Mar 16 17:48:54 kanavin: we do indeed need to talk to them... Mar 16 17:49:15 hah. these jokers are reproducing builds by putting them in the same path all the time. FAIL. Mar 16 17:49:16 zeddii: can you fix our build then please? Mar 16 17:49:39 I did wonder if we could fool it with chroots Mar 16 17:50:39 does diffoscope tear into the go binaries ? or are they just black blobs of pain ? Mar 16 17:50:47 zeddii, I have a horrible pile of hacks that achieves go reproducibilty even for different paths Mar 16 17:51:23 zeddii, go binaries contain a 'build id' which is not that dissimilar to sstate hash Mar 16 17:51:37 zeddii: It does to an extent, the differences are fairly obvious. We also have kanavin's code changes which highlight it Mar 16 17:51:55 zeddii, go toolchain environment is very sensitive to anything, and will change the build id at slightest provication Mar 16 17:52:01 yah. so do c compiled ones. My searches found that most people pass the buildid to the linker. Mar 16 17:52:20 as does the C one :D I just went through that with perf. Mar 16 17:53:00 yah. and I see they are messing about with trimpath and some linker things as well .. but then it seems you slam into cgo, which is more pain. Mar 16 18:03:54 Hmm, need to tweak the multiple value handling, but I wonder if something like https://gist.github.com/135f6fb2253da84cffd0f2279a062014 would be of use to anyone else for legal, as certain licenses require information about what files have or haven't been modified Mar 16 18:06:49 zeddii: the c build-ids don't change with the build paths! Mar 16 18:08:09 kergoth: I can see it being useful in some contexts, yes Mar 16 18:10:35 perf's did, well, because it was capturing the build path as variables. but yah, I know what you mean. Mar 16 18:10:55 k, might clean it up and submit as a rfc possible addition to scripts/contrib Mar 16 18:12:51 zeddii, the harder part about go's build ids is that the process to compute them is completely non-transparent, and hidden inside the toolchain source code Mar 16 18:13:30 with no debugging, short of running the toolchain itself inside a debugger Mar 16 18:15:44 yah. The only way out of that I can see is to just always generate your own, and pass them in. assuming that some reproducibility issues aren't masked by that, etc. Mar 16 18:37:03 kergoth: please do! Mar 16 18:37:18 kergoth: SBoM is a big thing atm and that is part of it Mar 16 19:05:43 sakoman: RP: Since it hasn't been seen in a while, I've closed: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13810 -- systemd file executable bits disappearing Mar 16 19:05:59 If anyone is still seeing this bug, please re-open. Mar 16 19:07:02 vmeson: OK, with me, I can't even remember the last time I encountered it! Mar 16 19:14:01 ssajal: cool. Yes, limiting the files tracked by pseudo and forcing an error rather than a warning seemed to do the trick. I see lots of pseudo backported changes in dunfell since last fall. Those commits are the more relelevant reason to close the bug and we've waited ~6 months to be extra sure that it's not happening! Mar 16 19:37:10 err I meant sakoman, not ssajal but you guys probably knew that. Mar 16 19:37:11 vmeson: agreed, seems reasonable Mar 16 19:37:24 RP: good. Mar 16 21:06:15 the word "image" is used in yocto in various places (e.g. https://docs.yoctoproject.org/sdk-manual/intro.html); what precisely is an "image"? Mar 16 21:11:16 nm Mar 16 21:11:17 https://docs.yoctoproject.org/ref-manual/terms.html#term-Image Mar 16 21:37:41 RP: whats the way to let ltp run as part of -ctestimage ? Mar 16 21:38:38 I have been using DEFAULT_TEST_SUITES but that does not track whats in image Mar 16 21:59:10 khem: http://git.yoctoproject.org/cgit.cgi/yocto-autobuilder-helper/tree/config.json#n105 Mar 16 21:59:25 khem: TEST_SUITES = 'ping ssh ltp ltp_compliance Mar 16 22:57:07 Hey armpit just a small reminder for https://lists.openembedded.org/g/openembedded-devel/message/89698 as we might have missed it in the last pushes to dunfell. Mar 17 01:21:35 alephan, I have that sitting in dunfell-next. I just need to ask for a merge Mar 17 01:22:01 Great. Thanks! **** ENDING LOGGING AT Wed Mar 17 02:59:56 2021