**** BEGIN LOGGING AT Thu Mar 18 02:59:56 2021 Mar 18 03:26:36 rburton: lvgl.io Mar 18 07:26:10 hi, what runs populate_lic_qa_checksum? can't see which task executes it from 'bitbake -e recipe' output Mar 18 07:37:26 ah, the check is called license-checksum in ERROR_QA Mar 18 08:03:12 yo dudX Mar 18 09:07:36 For some stupid third party code reason I have to include aarch64 shared libs into the x86_64 part of the SDK sysroot. populate_sdk now fails with a dnf error, because it cannot satisfy shared objects dependencies. Is there an easy way to configure dnf to ignore such errors for selected natviesdk recipes? Mar 18 09:08:08 Example dnf error: "nothing provides ld-linux-aarch64.so.1()(64bit) needed by nativesdk-my-recipe-6.0.1-r0.x86_64_nativesdk" Mar 18 09:59:08 moto-timo: yes, seen that. very much single-app but a layer would be useful :) Mar 18 10:11:41 I'm using the meta-freescale dunfell layer for my i.MX8M project. I'm having some problems with the u-boot-imx-tools-native saying it's incompatible with my (custom) machine, even though the MACHINEOVERRIDES is something like "mymachine:mx8:mx8n:..." Mar 18 10:12:16 I found some old thread about this but the document the answer refers to is nowhere to be found https://community.nxp.com/t5/i-MX-Processors/yocto/m-p/432469 Mar 18 10:13:35 It also seems like the poky/meta/classes/native.bbclass just forcefully sets MACHINEOVERRIDES="" Mar 18 10:14:22 I am clueless how this is supposed to work Mar 18 10:23:37 simonpe^^: well, why would a target machine matter for a native package? Mar 18 10:29:20 qschulz: I guess it won't Mar 18 10:29:53 simonpe^^: If you "guess", we need to explain a bit more then :) Mar 18 10:30:42 Well I understand why it won't matter, but the u-boot-imx-tools bb is written like that Mar 18 10:31:19 simonpe^^: a native package is built for the host architecture and to be used solely on the host (building) machine. It is essential the native packages aren't poluted by target machines/packages because they are supposed to be shared between all builds (of the same distro) Mar 18 10:31:19 ✦ ❯ cat -p meta-freescale/recipes-bsp/u-boot/u-boot-imx-tools_2020.04.bb Mar 18 10:31:19 require recipes-bsp/u-boot/u-boot-tools.inc Mar 18 10:31:19 require u-boot-imx-common.inc Mar 18 10:31:19 PROVIDES_append_class-target = " ${MLPREFIX}u-boot-tools" Mar 18 10:31:19 PROVIDES_append_class-native = " u-boot-tools-native" Mar 18 10:31:22 PROVIDES_append_class-nativesdk = " nativesdk-u-boot-tools" Mar 18 10:31:24 PACKAGE_ARCH = "${MACHINE_ARCH}" Mar 18 10:31:27 COMPATIBLE_MACHINE = "(mx6|mx7|mx8)" Mar 18 10:32:52 simonpe^^: what is there in this u-boot-tools*native that you're interested in? Mar 18 10:34:15 I assume it's the mkimage_imx8 that the freescale u-boot is looking for Mar 18 10:35:06 it wraps the spl, firmware, and itb with u-boot + dtb in a flashable image Mar 18 10:35:52 honestly I don't need that because I do that packaging myself outside of bitbake but I just need to have the build going Mar 18 10:36:33 simonpe^^: then remove the package from the dependencies :) Mar 18 10:39:48 simonpe^^: we use a slimmed down version of https://source.codeaurora.org/external/imx/meta-fsl-bsp-release/tree/imx/meta-bsp/recipes-bsp/imx-mkimage/imx-boot_0.2.bb?h=fido_3.14.38_6QP_ga&id=238a429e4eedd2f4b26876c2e2a6a9b3ec4e434c for our imx8mm Mar 18 10:43:42 thx Mar 18 10:44:09 I think I need to figure out how and why the imx-boot is required in the image Mar 18 10:44:29 I'm only interested of the u-boot-spl.bin u-boot.bin u-boot.dtb and bl31.bin I guess Mar 18 10:48:05 simonpe^^: imx-boot.bin includes atf and optee too for us Mar 18 11:29:41 how can I decide which tag I should use for my project? (beginner question) Mar 18 11:30:28 to clarify: yocto version 3.0 is called zeus, but then you have in the tags also somethin glike zeus-22.0.0 Mar 18 11:30:39 but you also have a git tag called yocto-3.0 Mar 18 11:30:40 ? Mar 18 11:31:13 yocto-3.0 = zeus right? Mar 18 11:32:15 mcburger: either latest master or latest dunfell Mar 18 11:33:30 LetoThe2nd so I shouldn't check out the latest branch release like explained in the quick start? Mar 18 11:34:40 LetoThe2nd so to be clear, I shouldn't check out a tag at all (use master) or use latest dunfell?? Mar 18 11:35:20 mcburger: well chances are that google referred you to an outdated quick start anyways. but dunfell is the LTS release, hence well maintained. latest master is already close to the next release, hence pretty reliable too at the moment. so yes, just using the latest state of either dunfell or master is the best way to start at the moment IMHO Mar 18 11:36:04 LetoThe2nd totally got it, thanks! Mar 18 11:36:29 kergoth: ok thanks for that. Mar 18 11:37:46 LetoThe2nd final question for today: is yocto-3.1.6 the same as dunfell-23.0.6? Mar 18 11:37:57 (code name) Mar 18 11:38:10 if not, what is the difference? Mar 18 11:38:43 ( you have 6 tags for yocto 3.1 and 6 tags for dunfell 23.0 which is why I am asking) Mar 18 11:39:21 mcburger: the manufacturer of your hardware might also have some requirements (ehrm... limitations) on what OE release you need to go for Mar 18 11:39:51 NXP for example is stuck on Zeus, which is end of life Mar 18 11:40:04 mcburger: completely identical (see for yourself in git, where the tags refer to the same commit hash) Mar 18 11:41:07 if a bbclass function is not python, what language/syntax is it? Mar 18 11:42:07 yates: bitbake. Mar 18 11:44:05 thanks sensei! Mar 18 11:44:13 and thanks simonpe Mar 18 11:45:03 yates: see section 3 in the bitbake manual: https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-metadata.html Mar 18 11:45:09 yates: thanks! Mar 18 11:45:38 thanks LetoThe2nd Mar 18 12:47:04 hi Mar 18 12:47:10 hi LetoThe2nd :) Mar 18 12:48:07 howdy Mar 18 12:51:42 I wrote this recipe https://controlc.com/5dce6f70 Mar 18 12:52:03 it is well compiled by bitbake but crash at installation .. idea ? Mar 18 12:53:50 https://docs.yoctoproject.org/dev-manual/common-tasks.html#packaging-externally-produced-binaries Mar 18 13:11:45 LetoThe2nd, is it an answer to my question ? Mar 18 13:12:58 jdrol: it is a "this is the relevant documentation section, i don't have time at the moment to go through and discuss it" Mar 18 13:13:53 I did't speak about external binary Mar 18 13:14:42 jdrol: and what is the difference between an "external binary" and "whatever file you just want to copy"? Mar 18 13:16:03 my file map is a text file Mar 18 13:23:55 yates: if not python, it's shell Mar 18 13:24:41 jdrol: "crash at installation"? we need more info if you want to be helped Mar 18 13:29:32 qschulz, https://controlc.com/4c5c0884 Mar 18 13:48:12 jdrol: clean your recipe workdir and build again Mar 18 13:49:06 hello guys ! Mar 18 13:49:38 doens anybody know why I can see the ouput coming from u-boot but not hte one after the kernel booting ? Mar 18 13:50:07 I can't see anything on serial port, but the system is up and running since I can access the board via ssh Mar 18 13:50:15 because your kernel setup is messed up? wrong device tree, etc... Mar 18 13:50:57 derRichard, I though it too but the peripherals seems to be working correctly Mar 18 13:51:05 and I can login via ssh Mar 18 13:52:30 check your kernel boot line. If the console isn't specified properly, you won't get anything. Could also be the init system not taking the handoff correctly as well. The device tree might not be setting the right preferred device for console, etc. There's a few ways it can go wrong. Mar 18 13:57:50 qschulz, ok many thanks ... I delete the build dir and recompile or is there a bibake clean to avoid to delete the conf bblayer files ? Mar 18 13:58:06 jdrol: bitbake -c clean my-recipe Mar 18 13:59:25 qshulz only the faulted recipe ? Mar 18 14:00:20 thekappe: as zeddii said, is the default console output correctly confgured? Mar 18 14:01:16 the device tree serialX order has changed Mar 18 14:01:31 for some reason Mar 18 14:01:54 at first I had serial0=&uart0 Mar 18 14:02:05 now I have serial2=&uart0 Mar 18 14:03:10 and I run the kernel with console=ttyPS2,115200n8 Mar 18 14:03:27 console=ttyPS0,115200n8 Mar 18 14:03:37 before the above changes Mar 18 14:04:10 so I've simply tried to use console=ttyPS2,115200n8 instead of console=ttyPS0,115200n8 to reflect the ghanges in DT Mar 18 14:04:26 the result ? kernel panic Mar 18 14:04:28 damn Mar 18 14:05:04 qschulz, https://controlc.com/659ac036 Mar 18 14:05:23 but a tleast I got some print Mar 18 14:05:33 and that line: Mar 18 14:05:49  tty_init_dev: ttyPS driver does not set tty->port. This will crash the kernel later. Fix the driver! Mar 18 14:10:49 jdrol: the error message is self-explanatory Mar 18 14:11:14 jdrol: please have a look at https://www.youtube.com/playlist?list=PLD4M5FoHz-TxMfBFrDKfIS_GLY25Qsfyj Mar 18 14:11:41 it'll help you get started much faster than trial and errors Mar 18 14:17:25 rburton: https://autobuilder.yoctoproject.org/typhoon/#/builders/113/builds/834 - sorry :/ Mar 18 14:53:47 RP: yeah that's a really weird build race, no idea what happens Mar 18 14:53:52 iirc there's a ticket already Mar 18 15:03:03 RP: morning, swatting failing disk space? Does that get reported to email or a bugzilla for halstead? Mar 18 15:21:51 sgw, pinging me is a great response for a disk space issue. It means a monitor isn't working right at least. Mar 18 15:23:39 halstead: it seems that opensuse152-ty-1 had a disk issue on sda4, but seems to be resolved now. Mar 18 15:24:32 sgw, That is one of the smaller disks in the cluster. Mar 18 15:24:59 Maybe ran out and then a clean-up occurred? Mar 18 15:25:39 sgw, Yep it looks like the janitor cleared it up before I was alerted. Hrm.. Mar 18 15:26:07 I'll find more to delete. Mar 18 15:26:10 halstead: Ok, your alerted now! (swatted!) Mar 18 15:26:16 Thanks sgw! Mar 18 15:31:42 I just realized the upgrade to liburi-perl with a different SRC_URI would be helped by a devtool bug assigned to me (to allow changing the SRC_URI). lol Mar 18 15:32:15 libri-perl has two authors, so the URL has been ping-ponging Mar 18 15:33:40 in yocto terminology, "inherit"ing (or "INHERIT"ing) a class, i.e., a .bbclass file, means to read and parse it as part of the build process. is this correct? Mar 18 15:35:22 i've read the manual on this but it never defines what exactly "inherit" means: https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-metadata.html#inherit-configuration-directive Mar 18 15:36:29 yates: in my mind, it inserts the content of the class in-place Mar 18 15:36:52 same for bbappends, inserts the content at the end of the recipe (in order of priority when multiple bbappends) Mar 18 15:37:24 exception made to := which are expanded from the bbclass directly Mar 18 15:37:36 (e.g. FILESEXTRAPATHS_prepend := trick in bbappends) Mar 18 15:37:43 yates: but... why the question? Mar 18 15:39:25 qschulz: i'm just trying to understand some of the base mechanisms of bitbake, and this is one of them. perhaps the term is a little bit confusing to me since i've used C++ and it has special meaning in that context. Mar 18 15:41:22 is it true that "INHERIT" can only be used in .conf files (not .bb files), but inherit can be used in .bb files? Mar 18 16:00:53 yates: yes Mar 18 16:01:46 yates: INHERIT is deferred until the end of parsing the conf files and is evaluated once, inherit is evaluated at the point it is in the bb file Mar 18 16:32:00 qschulz, I used ${sysconfig} and not ${sysconfdir} Mar 18 17:00:09 hmm, a 64GB cooker log is a bit excessive Mar 18 17:33:58 thanks qschulz and RP Mar 18 17:42:04 Hey, I have a problem. I want to use a specific layer because it has the packeges I need(at least the right version of the packages I need). I added the layer with bitbake command and while building the image many errors are showen with almost the same context that the preffered version is not avaliable but only the one I dont want. what can I do Mar 18 17:42:04 to force bitbake to use the layer/packeges I want? thank you Mar 18 17:43:43 RP: what does "evaluate" mean? does it mean "executed"? for example, if the conf file has some code at outer scope (i.e., not inside a function), would it get executed at "evaluation time"? Mar 18 17:43:46 what exactly do you mean by 'added the layer with bitbake command'? what command did you use? Mar 18 17:44:07 yates: there is no "code at outer scope" in our file format. Mar 18 17:44:43 yates: there are functions that are run at various times, and there's inline python in the value of a variable, which is evaluated at the time it's used unless you use := to force it to be immediate Mar 18 17:45:06 yates: evaluated mean the directives in the inherited file are included there and then at that point in the file/parsing Mar 18 17:45:20 yates: which is different to how INHERIT works in conf files Mar 18 17:45:24 ah, i missed the context, inherit Mar 18 17:45:58 kergoth: INHERIT vs inherit Mar 18 17:45:59 have to say i don't love that aspect of our format, the combination of imperative and declarative behavior. would be hard to fix, though. Mar 18 17:46:11 kergoth: right, it is what it is Mar 18 17:47:16 we could presumably make INHERIT be obeyed in a recipe, but it'd end up parsing those *after* the recipe, not before, unless we played games with the parsed statements Mar 18 17:47:31 so the ability to override class content would be impacted Mar 18 17:47:57 i guess we could parse it twice, once to get the value, then a second time *after* parsing the classes Mar 18 17:48:03 that'd have performance implications, though Mar 18 17:48:09 kergoth: the trouble is order does matter for inherit Mar 18 17:48:46 yeah. i think more often than not having the inherit be before the recipe would work, though, it's pretty rare to *have* to set a value before the recipe is parsed, more commonly things need to be done after Mar 18 17:49:03 kergoth: I think we have bigger problems :) Mar 18 17:49:06 given how our expansion works, only recipes that use := would need things set first Mar 18 17:49:09 true Mar 18 17:49:56 kergoth: I worry that we've been really creative about bolting on things like hash equivalence, sstate and so on and that its all getting a bit ugly Mar 18 17:50:01 i always wanted to be able to plug in a new file format, back when all this started, but the format isn't just the format. it's tightly bound to the other components and how things are done. you can't really change the file format without also changing how every other bitbake component interacts with the datastore Mar 18 17:50:36 Its definitely not straight forward :/ Mar 18 17:50:40 I'd actually really like to see a lot of the things we bolt on be done as separate python modules as *plugins* to bitbake, but which live in the layer, rather than shoehorning everything into the recipes and classes Mar 18 17:51:44 kergoth: do you have an example plugin? Mar 18 17:52:40 well bitbake doesn't have a plugin infrastructure at this point, but the concept of altering its behavior from a python class i think has some appeal Mar 18 17:52:59 kergoth: we kind of have precedent with the siggens Mar 18 17:53:50 They have a number of issues but they do give configurable behaviour from the metadata Mar 18 17:56:09 yeah. i like that idea, keep the metadata a bit more declarative, have more of the bits that change behavior of the build live in code Mar 18 17:58:40 http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=4d6254eb379ddedef696ef564f72bc14303a6eb5 - first attempt at removing stale sstate objects pre build Mar 18 17:58:50 JPEW: ^^^ - what we discussed in triage Mar 18 17:59:03 * RP isn't sure he likes it or not Mar 18 18:05:40 Thanks RP I will try appending to TEST_SUITES Mar 18 18:06:29 RP: I sent a patch I am carrying for a long time to let < > be allowed in error report, I know you raised some issues with this in past can you remind me if that patch is ok or not Mar 18 18:11:23 kergoth the command I used was : bitbake-layers add-layer "Path" Mar 18 19:15:47 sorry I disconnected. kergoth did you answer me? Mar 18 19:29:10 does a .bb file ever contain "code at the outer scope"? from browsing several .bb files, and from my memory/experience, i'd say "no" - they only contain function definitions (e.g., do_install()) and variable definitions; the actual work is done by the .bbclass files and possibly by bitbake itself. Mar 18 19:33:32 @yates: Do you have an example_1.0.bb which shows what you mean by "code at the outer scope"? Mar 18 19:34:18 cp -rf ${S}/demos/images/* ${D}/usr/aiop/bin Mar 18 19:34:29 (copied out of a do_install()) Mar 18 19:34:41 OK and where should this be? Mar 18 19:34:42 but i don't think that's "legal", is it? Mar 18 19:34:49 in a .bb file Mar 18 19:34:55 outside of a task/function Mar 18 19:34:58 yes Mar 18 19:35:04 So who should call it then? Mar 18 19:37:40 RobertBerger: well that's exactly what i'm trying to understand: where are functions / code "defined" versus where are they "called". in C (e.g.) your source code is compiled and then called (beginning with main()) at run time. Mar 18 19:38:08 Now people here will kill me, but think about bitbake like make ;) Mar 18 19:38:23 It's a task executor (shell and python) Mar 18 19:38:58 If you want to get really deep there is an example in the bitbake manual which shows you bitbake without OE/YP. Mar 18 19:39:46 RobertBerger: why would they kill you? bitbake *is* make on steroids Mar 18 19:40:24 RobertBerger: thanks - i need to do some more reading i think. specifically in the bitbake user manual. Mar 18 19:40:47 yes, i got that. i've used gnumake since the 90s.. Mar 18 19:41:41 @derRichard There are quite some differences in how BitBake and make work, but well... Mar 18 19:41:42 perhaps, if this isn't too stupid of a question, i could ask this: in yocto/bitbake, what gets called first? what is "main()"? Mar 18 19:41:55 hehe ;) Mar 18 19:42:32 You are confusing a few things, I believe. Mar 18 19:42:54 that is almost definitely true! Mar 18 19:43:02 i can't see what Mar 18 19:43:10 bitbake is the task executor, say make and the .bb .bbclass .bbappend and so on files are the meta-data - the makefiles Mar 18 19:43:11 RobertBerger: sure but from a brid's point of view both make and bitbake are buildsystems that build things based of rules Mar 18 19:43:26 *bird's Mar 18 19:43:50 @derRichard: Yep Mar 18 19:44:29 @yates, so we have one entry point to bitbake, which I guess you don't want to know and then we have meta data magic Mar 18 19:44:57 perhaps i could answer my own question: do_rootfs()/do_bootfs() are main, from the nice "High Level Overview" diagram here: https://www.aosabook.org/en/yocto.html Mar 18 19:44:59 You could inherit a cmake bbclass and then your recipe knows cmake. Mar 18 19:45:16 If you don't include anything, the "base class" searches for a Makefile Mar 18 19:45:48 do_rootfs is pretty much towards the end. Mar 18 19:46:01 You first need to download (fetch) then patch, build,.... Mar 18 19:46:11 each and every package Mar 18 19:46:41 The drawing starts from bottom to top Mar 18 19:46:50 there is do_fetch() and do_patch() (et al.) there. Mar 18 19:46:56 yes, i just am realizing that! Mar 18 19:47:01 Yep - this is done first Mar 18 19:47:22 what are they, Chinese? most people read L-R, T-B! Mar 18 19:47:34 @yates: http://docs.yoctoproject.org/ Mar 18 19:47:34 that's confusing.. Mar 18 19:48:20 RobertBerger: that's like saying: "internet" Mar 18 19:48:26 https://docs.yoctoproject.org/singleindex.html#what-i-wish-i-d-known-about-yocto-project Mar 18 19:48:30 and scroll down to the pic Mar 18 19:50:14 @LetoThe2nd: Oida! Mar 18 19:51:13 RobertBerger: OIDA!!! Mar 18 19:51:17 RobertBerger: yes, that is a nice diagram. i'd seen it before. Mar 18 19:51:19 @LetoThe2nd did you change your timezone to have jetlag without traveling? Mar 18 19:51:49 i didn't gaze on it long enough, apparently.. Mar 18 19:52:02 RobertBerger: ? Mar 18 19:52:09 @yates so now, I guess you would like to get the corresponding meta data pieces Mar 18 19:52:38 @LetoThe2nd: Isn't it late for you for the chat? Mar 18 19:53:26 RobertBerger: Nachtschicht. OIDA! Mar 18 19:53:50 @LetoThe2nd: Aso Mar 18 19:53:56 RobertBerger: you mean the specifics like .bb/.bbclass/.bbappend/blah files, how variables are accreted, shell versus python functions, etc.? yes, and i've been reading the bitbake manual for these. Mar 18 19:54:24 Like base bbclass do_compile Mar 18 19:54:42 in /meta/classes? Mar 18 19:55:34 hold your horses ;) Mar 18 19:55:50 Neee! Mar 18 19:58:08 @yates: search for base.bbclass Mar 18 19:58:19 got it Mar 18 19:59:15 now search in there for do_compile Mar 18 19:59:45 there you should see that it searches for Makefile, makefile,... Mar 18 19:59:45 ok, i see several instances Mar 18 20:00:05 base_do_compile Mar 18 20:00:15 yes Mar 18 20:00:57 does bitbake actually build a Makefile?!? Mar 18 20:01:02 then execute it? Mar 18 20:01:15 oe_runmake Mar 18 20:01:36 Nope Mar 18 20:01:46 It searches and executes it when it finds it Mar 18 20:02:07 oe_runmake Mar 18 20:02:09 yep Mar 18 20:02:26 ok this is the makefile from whatever you're building Mar 18 20:02:39 and you also see addtask compile after do_configure Mar 18 20:02:56 yes Mar 18 20:02:58 Which is highly confusing since it calls do_compile Mar 18 20:03:16 Anyhow, here you see the sequence compile after configure Mar 18 20:03:22 yes Mar 18 20:04:02 yes, i see the pattern Mar 18 20:04:22 OK Mar 18 20:04:35 thanks man! Mar 18 20:04:49 Now in your own classes/recipes you can overwrite those Mar 18 20:04:53 yates: when you bitbake a recipe explicitly, bitbake will default to running the task specified in BB_DEFAULT_TASK, which is do_build by default. that's it, that's the only thing that's built explicitly, and only if you don't specify another task. everything else comes in through dependencies one way or another, task or otherwise Mar 18 20:05:03 i.e. 'bitbake foo' and 'bitbake -c build foo' are the same thing Mar 18 20:05:22 the default set of tasks and their order is covered in the architecture of open source chapter on yocto Mar 18 20:07:40 yeah, the specific thing i'm chasing right now (perhaps without needing to) is how the binutils/compiler "fetch/unpack/configure/compile/install" gets done first. Mar 18 20:07:49 ..andi think i just saw it..! Mar 18 20:08:21 addtask build after do_populate_sysroot Mar 18 20:08:56 ? Mar 18 20:09:33 Dependencies? Mar 18 20:10:38 kergoth: good to know - thanks Mar 18 20:11:05 sorry if it seems like i ignore anyone - i am very tunnel-visioned.. Mar 18 20:13:14 yates: yep, that ensures that populate_sysroot of the specified recipe is run by default. there are other addtasks of interest in the packaging classes, etc. Mar 18 20:13:39 yates: beyond that you'd be interested to see flag definitions Mar 18 20:13:40 for example Mar 18 20:13:41 do_build[recrdeptask] += "do_deploy" Mar 18 20:13:58 this means that do_deploy of every recipe this recipe depends on will be run, both runtime dependencies and build time dependencies Mar 18 20:15:43 deptask == pull in this task for our build time dependencies (DEPENDS), rdeptask == pull in this task for our runtime dependencies (RDEPENDS_* for pkg in PACKAGES), recrdeptask is both recursively Mar 18 20:16:39 you guys are killing me! my head hurts! Mar 18 20:17:17 well, it has to have a way to pull in dependencies or the build would never work :) Mar 18 20:17:43 when users define variables it looks like recipes depend on one another and packages depend on one another, but from bitbake's perspective, it runs tasks, and tasks depend on tasks in other recipes Mar 18 20:17:51 the flags control the relationship between those two Mar 18 20:18:13 probably don't need to know that, but youe xpressed interest in how tasks depend on one another, so.. Mar 18 20:18:15 :) Mar 18 20:18:33 the addtask before and after covers most of waht you need to know within a single recipe Mar 18 20:27:54 @kernoth: and @yates is just at the beginning of all the fun ;) Mar 18 20:30:16 @yates: so you know the beginning now. The only thing which is sure, there is no end ;) Mar 18 21:11:38 khem: that patch imlies escaping is missing somewhere. I thought we fixed the escaping more generically ? Mar 18 21:23:54 thanks guys. where can i send the Heinekens? Mar 18 21:26:11 rburton, what is your take on this? https://github.com/besser82/libxcrypt/issues/123#issuecomment-802255830 Mar 18 21:26:37 rburton, I vaguely remember we did print config.log at some point, then didn't because it wasn't that useful after all? Mar 18 21:26:49 rburton, in this case though, upstream requests we do Mar 18 21:30:34 @yates: proper beer please ;) Mar 18 21:30:42 @yates next time we meet in person Mar 18 21:42:35 kanavin_: printing config.log just confuses people no end Mar 18 21:42:57 kanavin_: we'll just have to grab one from a failed build. Just remember that "build" becomes "build-renamed" Mar 18 21:43:12 kanavin_: my master-next last night had the same issue Mar 18 21:43:22 RP: yeah, I guess my patch to work around this should not be queued then Mar 18 21:43:58 RP: I also saw this when working on recipe updates, and there's a few more if you look at history of buildtools Mar 18 21:45:30 RP: here's the latest one with the failure, is there a chance it's not wiped away yet? https://autobuilder.yoctoproject.org/typhoon/#/builders/20/builds/3524 Mar 18 21:49:22 kanavin_: it is still here Mar 18 21:51:34 kanavin_: https://autobuilder.yocto.io/pub/logs/config.log Mar 18 21:52:38 RP: thanks, I got to it via ssh as well Mar 18 21:56:54 kanavin_: I've moved that bit of workdir to ~/saved in case you need more Mar 18 21:57:39 halstead: whilst I was on suse152, I moved a load of old builds to be deleted Mar 18 21:57:39 RP: I reported the issue and attached config log to the upstream ticket https://github.com/besser82/libxcrypt/issues/123 Mar 18 21:57:48 RP: let's see if they figure it out or it's somehow our fault Mar 18 21:58:32 RP, I removed several this morning as well. Where were the ones you deleted? Mar 18 21:58:32 halstead: they were build-renamed inside yocto-worker Mar 18 21:58:32 halstead: found about 12 of them Mar 18 21:59:18 Thanks RP. Mar 18 21:59:18 halstead: we should consider that script we talked about to do this during maintenance ? Mar 18 22:00:03 RP, Do you happen to know if the file referenced by https://www.yoctoproject.org/reproducible-build-results/ has changed? Mar 18 22:00:03 halstead: shouldn't have done Mar 18 22:00:03 halstead: this may be the issue JPEW reported on other branches though :/ Mar 18 22:00:48 RP, Thanks. I'll look for that from JPEW. Mar 18 22:02:18 RP, Yes. I do need to consider that script we talked about. Corruption on some of the longer lasting workers ext4 filesystems is an issue. Running mkfs during maintenance would be a very fast way to clear everything and solve space issues. Mar 18 22:03:19 halstead: we didn't get to the bottom of it, was something about the way the oe-selftests were logged in gatesgarth/dunfell Mar 18 22:03:22 RP: I'm sure it will come as zero surprise that there are perl deps issues with liburi-perl upgrade Mar 18 22:03:32 RP, I don't know if formatting away all build artifacts on a weekly basis is workable for the dev team though. Mar 18 22:03:32 halstead: at a guess it has happened in master Mar 18 22:03:34 time to dogfood Mar 18 22:04:03 I'm sure they aren't caught with AUH because perl-modules is installed. Mar 18 22:04:08 halstead: that wasn't the script I meant. I meant iterating the files in yocto-worker and moving build-renames to trash for the janitor Mar 18 22:04:24 halstead: we'd have to communicate any builds we needed saved in advance of maint Mar 18 22:04:55 moto-timo: hmm, not a surprise sadly Mar 18 22:05:24 RP: I thought you _might_ get a luagh out of that... hopefully not tears Mar 18 22:05:47 moto-timo: I just read the openssh license file so anything is better :) Mar 18 22:06:09 * moto-timo very happy to not be an attorney Mar 18 22:06:23 RP, Yes. What we talked about is much more doable. Maybe reformatting once a quarter would be better and easier to communicate around than every maintenance. Mar 18 22:07:09 halstead: right. I suspect the filesystems would be fairly light if we did this and they'd scan a lot faster anyway Mar 18 22:18:19 I've put some changes in master-next to test cleaning stale sstate objects in existing builds. If anyone is feeling adventurous with some existing build directories they're not too precious about... :) Mar 18 22:23:54 vmeson: current AB load will be doing heavy rebuilds if that helps **** ENDING LOGGING AT Fri Mar 19 00:01:55 2021 **** BEGIN LOGGING AT Sun Mar 21 04:22:16 2021 Mar 21 15:26:32 RP: trying to track down how to fix a do_rootfs failure after intercept_scripts was added to PSEUDO_IGNORE_PATHS (gatesgarth) and wonder if you have any idea how to best debug this Mar 21 15:26:49 basically I'm now getting "copyfile: failed to chown/chmod" warnings for delay_to_first_boot, update_desktop_database, update_udev_hwdb and a few postinsts are failing as a consequence, such as libglib-2.0-0.postinst, udev-hwdb.postinst and vim.postinst, causing do_rootfs to fail Mar 21 15:36:32 didn't yet try on current master, so not sure if we're still missing some backports for gatesgarth to work correctly after that change Mar 21 15:37:58 similar changes were also backported to dunfell, so expect the same issues there Mar 21 15:40:29 https://github.com/OE4T/tegra-demo-distro/issues/66#issuecomment-798826084 seems others are having similar issues on dunfell Mar 21 15:40:59 and funny that I'm only getting this issue on our ci builder, works fine when building locally Mar 21 17:00:15 how can I add pthread to the toolchain or into the SDK ? Mar 21 17:00:57 building a simple .c code I have undefined reference to `pthread_create' Mar 21 17:02:32 are you linking with -lpthread? Mar 21 17:12:54 smurray: I mean that if I call manually arm-poky-linux-gnueabi-gcc with -pthread it builds but the default settings of my toolchain don't contain it therefore I have to create a proper makefile Mar 21 17:13:22 smurray: I think this is the expected behavior, so it is not a problem Mar 21 17:21:36 mckoan: perhaps a question for khem Mar 21 17:31:17 smurray: actually it wasn't a real problem, only a wrong makefile. Sorry for the noise. Thank you Mar 21 21:12:35 mckoan|away: smurray use -pthread option to GCC (as compiler and linker both ) is the right way Mar 21 21:14:02 -lpthread works but there are cases where the order is important and some other libs should be pulled in or architecture has different needs so usually leaving that to compiler driver is wise thing to do Mar 21 21:15:04 zeddii: recent kernel updates in oe-core has turned the kconfig mismatch warnings into errors so now ppc64 kernel is failing because it find CONFIG_POWER4 to be conflicting Mar 21 21:15:21 zeddii: I think that option can be removed from the defconfig Mar 21 21:15:45 MACHINE=qemuppc64 bitbake virtual/kernel Mar 21 21:28:06 zeddii: http://sprunge.us/n72oKw Mar 21 21:48:02 Hi, when I try to create yocto image for nvidia nano, it says that meta-tegra is not compatible with Gatesgarth and that i need which doesn't exist yet. Message :ERROR: Layer tegra is not compatible with the core layer which only supports these series: gatesgarth (layer is compatible with hardknott) Mar 21 21:48:02 ideas? Mar 21 22:06:15 ok i solved my issue Mar 21 22:06:34 i downloaded a wrong version Mar 21 23:49:54 khem: while the fix is valid, I'm wondering what you are building ? master-next ? That shouldn't be throwing an error. so I want to get to the bottom of that. It is only a warning. Mar 22 00:46:49 zeddii: yes master-next **** ENDING LOGGING AT Mon Mar 22 02:59:56 2021