**** BEGIN LOGGING AT Tue May 26 02:59:57 2020 May 26 07:06:19 I'm looking at https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#inter-task-dependencies.. Could someone help me with understanding what "runtime namespace" is here ? Is it packages ? May 26 07:16:10 kroon: yes, RDEPENDS instead of DEPENDS for example May 26 07:18:25 RP, hmm but RDEPENDS contains package names, right ? I didn't think packages had tasks associated with them, only recipes has tasks ? May 26 07:21:59 kroon: an RDEPENDS can be resolved back to a recipe though May 26 07:23:22 RP, aha.. ok, thanks for clarifying May 26 08:42:55 Hi, what is the difference if i put IMAGE_INSTALL_append = " libstdc++" in local.conf or in the image file? May 26 08:43:08 I noticed that it works in local.conf , but it dosnt in image May 26 08:43:41 Guest5215: in the image recipe file, it depends a bit. May 26 08:44:05 Guest5215: but its wrong anyways, as this belongs into the DEPENDS of the application recipe that actually needs it. May 26 08:58:31 Letothe2nd Ahh, i see... And what about DISTRO_FEATURES_append = " systemd" . Where should i put this? May 26 08:58:48 Guest5215: into your distro file. May 26 08:58:49 I think about putting it into the machine config? May 26 08:58:53 Oh ok May 26 08:59:35 Until now i dont have my own distro config :-D Still using the BSP distro file May 26 09:01:13 a good moment to create one then, i'd say. May 26 09:01:43 Letothe2nd i just recompile because i switched to systemd ... It'll take some time. But i put "distro layer" on my list May 26 09:03:48 Letothe2nd: where is your shameless plug? Guest5215 told you all the magic words :D May 26 09:04:21 qschulz: i'm just waiting for you! May 26 09:06:55 Letothe2nd: no, that's a shameful thing to do, not a shameless plug anymore May 26 09:08:35 see, now you scared him away! May 26 09:12:32 :( May 26 09:25:17 RP, I'm struggling with the last section of https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#recursive-dependencies May 26 09:30:35 I interpret that as "do_a and do_b of the current recipe, and all its build/runtime recipe dependencies, must run before this recipe's do_a can run" May 26 09:31:16 Which looks like a circular dependency do_a -> do_a May 26 09:38:14 hello May 26 09:38:26 i have a strange behaviour when generating my rootfs image May 26 09:38:44 all files are owned by uid 1000 instead of root May 26 09:39:10 did you notice something similar already ? May 26 09:39:52 amaury_d: building inside some form of container magic? which image type, and how did you check? May 26 09:40:34 i build inside a lxc container May 26 09:40:58 i check by uncompress the rootfs tar gz with option -p to preserve ownership May 26 09:41:36 does this actually propagate to the target? May 26 09:41:50 i'm stil unconvinced that this is not a false positivie. May 26 09:42:24 i cannot boot on the target anymore May 26 09:42:32 ok. anymore, since? May 26 09:42:48 i have errors "failed to mount ... effective uid is 1000" May 26 09:43:13 yet this means that it already worked up to some point in time. May 26 09:43:28 yes it worked perfectly back then May 26 09:43:39 since i tried to add a patch to a kernel module May 26 09:44:03 i removed the patch but this did not fix the issue May 26 09:44:36 maybe the patch i made was not at all related to this problem May 26 09:45:04 i don't think so. May 26 09:46:35 rather some change in the build environemtn. May 26 09:46:38 Hello. Im having difficulties building yocto. There is always the error of chown 'changing ownershiop of ... Operation not permitted' I didnt change anything in the yocto itselve. Just normal IMX6 TQ Layer + Yocto warrior. "shadow_4.6.bb:do_install" failed May 26 09:47:04 ok now i'm pretty sure there is a catch May 26 09:47:24 i mount manually the old ext4 image and the files are owned by root May 26 09:47:36 with the new image it is for user 1000 May 26 09:47:40 amaury_d: have you tried wipind the build and starting over? May 26 09:47:56 that will be probably the only solution i guess May 26 09:48:07 amaury_d: and you really did not change the lxc environment, or the way it accesses the build storage? May 26 09:49:05 to be honest the problem is here for some time now (~1 month ago) May 26 09:49:25 but i do not recall of anything i changed on the lxc side May 26 09:49:45 amaury_d: and you have no idea anymore what exactly happened back then - which is no surprise, i also wouldn't have. May 26 09:51:38 i was on remote back then with no access to my device May 26 09:51:53 so I though the patch was a source of kernel panic May 26 09:52:11 i came back today at the office and saw the strange uid things May 26 09:53:09 I've got a new layer ready for initial release and I'd like to post to the yocto-announce list. I see that it's moderators only so how do I get something posted? May 26 09:53:24 amaury_d: no idea at the moment, i'd wipe the build and see what happens. May 26 09:57:00 Letothe2nd: yes i will try that thank you anyway for your time May 26 09:57:37 amaury_d: no problem, have fun1 May 26 11:32:56 ok , iam on systemd now. But i still get the same DBUS error: "The name de.pengutronix.rauc was not provided by any .service files" But in busctl i can see that name May 26 11:33:37 Guest525: then my guess is that your application is using the wrong of system versus user bus. May 26 11:38:20 Guest525: if you can see and invoke methods on the service via busctl, then the problem is pretty clearly in the way the application tries to access it. May 26 11:39:29 Letothe2nd: FYI i manage to fix the uid issue by wiping the tmp folder for the build May 26 11:40:22 amaury_d: ok, thanks for the heads up May 26 12:19:06 if someone asks for chromium based browser to a yocto based project, my answer currently is switch to Debian, or at least setup a Debian based container or chroot for the browser. Any other opinions? May 26 12:53:29 mcfrisk: use meta-browser and the chromium recipe? May 26 12:54:21 mcfrisk: https://layers.openembedded.org/layerindex/branch/master/layer/meta-browser/ May 26 12:56:51 rburton: yea, but how about long term maintenance? the chromium there is quite out of date already. of course if I would want to do all maintenance on my own, then yes, meta-browser could be a good start. May 26 12:57:12 mcfrisk: ask otavio or whoever else is listed as a maintainer i guess May 26 12:57:34 a dumb recipe to fetch the official chrome binaries should be simple enough though? May 26 12:58:17 heh, that would work too :) May 26 12:58:45 also it seems layer index was not uptodate with what is actually in the meta-browser git repo May 26 13:02:09 mcfrisk: the usual complaint is the build time/resources required, it's a big step up from almost anything else May 26 13:03:47 smurray: yes, that is true. build times will explode. May 26 13:05:23 mcfrisk: they're not kidding about the memory needed to link it May 26 13:06:07 mcfrisk: AGL has a profile that builds it; iirc, a couple of people mentioned at one point about not having enough memory May 26 13:06:48 yes, we already limit parallel options for bitbake due to memory and make sure at least 2 gigs per core are there. May 26 13:07:55 mcfrisk: a current annoyance is the build system for it still needs python2 May 26 13:09:23 mcfrisk: Depending on what they need, WebKit might work also. meta-webkit is pretty well maintainted May 26 13:09:30 oh, meta-python2 too then, in addition to meta-clang and everything else May 26 13:10:12 mcfrisk: yeah, at least for now May 26 13:10:20 JPEW: video with drm, off line app support so WebKit doesn't fit anymore May 26 13:10:45 * mcfrisk misses the days when browsers did HTML rendering.. May 26 13:13:12 mcfrisk: Ah too bad. We've been using webkit and been reasonably happy with it (at least, compare to the build times and hardware resource chrome requires!) May 26 13:49:47 Letothe2nd. Thanks. It was right i needed to switch to system instead of session on my dbus stuff. May 26 13:50:04 Guest525: :) May 26 13:50:24 Guest525: invoice goes to? :P May 26 13:51:31 Are you doing it for beer? :) May 26 13:54:30 Guest525: find out here: https://www.youtube.com/playlist?list=PLD4M5FoHz-TxMfBFrDKfIS_GLY25Qsfyj May 26 13:55:42 One hour ?! May 26 14:00:01 ? May 26 14:01:08 Is there an easy way to findout the BPN, or is it simply the *.bb name without the version number? May 26 14:02:11 jonmason: i think it should be unless redefined by the recipe. May 26 14:04:54 jonmason: ${BPN} is the BPN. typically recipe name. what are you trying to do? May 26 14:05:05 typically *but not always* May 26 14:05:06 rburton: something stupid, obviously May 26 14:05:07 jonmason: bitbake.conf is your friend :) http://git.yoctoproject.org/cgit.cgi/poky/plain/meta/conf/bitbake.conf May 26 14:05:52 this is where I usually find most of the default values May 26 14:06:30 qschulz: thanks, I was looking at the docs and it was not obvious to me. Looking at the code should've been my next step May 26 14:06:43 jonmason: BPN is PN but with common prefix/suffix removed May 26 14:07:26 rburton: I'm trying to merge 2 recipes with a common inc file and am about to use the BPN and sed to derive some common parts May 26 14:07:38 seems sensible May 26 14:07:45 the toolchain recipes? May 26 14:07:54 rburton: its binary toolchains... May 26 14:07:59 sakoman: BTW out of pure interest - are you taking care of the LTS? May 26 14:08:20 jonmason: you have to take it to the next step! make arm support ternary toolchains! May 26 14:08:22 Letothe2nd: yes he is May 26 14:08:35 rburton: ah May 26 14:08:54 Letothe2nd: yes, I am May 26 14:09:25 sakoman: :) May 26 14:09:38 sakoman: awesome to see! May 26 14:09:43 Letothe2nd: this is going down a rabbit hole with all the Arm binary toolchains. I just learned that there is a binary clang Arm toolchain May 26 14:10:37 jonmason: so... quadrinary toolchains, or what? May 26 14:11:40 Letothe2nd: I think if I actually look at this abyss, the abyss will look back at me...and steal my soul May 26 14:13:09 souls are overrated. go for it. May 26 14:13:13 zeddii: ++ May 26 14:13:38 well, plus once your soul is gone, politics is a good 2nd career choice. May 26 14:13:51 join the dark side and get one beer free. #yoctomarketing May 26 14:13:59 nice!! May 26 14:16:35 Letothe2nd the video is too long for me, i just assume that you drink beer :) May 26 14:17:49 slowly i come to the conclusion that this is gonna be a complicated customer. May 26 14:19:00 .*guest.* is definitely a hint May 26 14:19:34 zeddii: well he was already around yesterday May 26 14:19:42 er, .*[Gg]uest[0-9]* May 26 14:19:52 ahah. I was IRC free most of the day, I didn't see the fun :D May 26 14:20:26 zeddii: not much fun, just some extended cluelessness about dbus/systemd and how things interact. May 26 14:21:17 ah yes. so not related to the build portion of bitbake/oe/yocto. May 26 14:22:42 not at all. May 26 14:59:33 YPTM: Jan-Simon is on May 26 15:01:00 YPTM: Scott Murray is on May 26 15:28:46 In a .bbclass file, is it possible to get the name of the file containing the associated inherit directive ? May 26 15:29:59 I'm not sure if FILE is the bbclass filename or the recipe filename if you force its immediate expansion in the bbclass. worth a check May 26 15:36:47 kergoth, it would appear that FILE expands to the .bb file, never to the .bbclass or .inc file, which is kind of what I wanted May 26 15:37:20 ah, that's unfortunate. ideally I think FILE would always be the current, and perhaps another variable would hold the stack of included files thus far May 26 15:37:32 i think we expected referencing the recipe to be the common case at the time May 26 15:39:06 ok. a BBFILE_LIST or FILE_LIST, would have been nice May 26 15:39:25 * kergoth nods.. maybe an enhancement request in bugzilla? doesn't solve the immediate problem, but.. May 26 15:39:37 yeah I can file one May 26 15:40:52 iirc there's a bitbake internal variable if you want to be daring and poke around at them. May 26 15:40:57 __inherit_cache May 26 15:41:34 includes in general don't have such a variable unless variable tracking is enabled, iirc May 26 15:41:51 ah, there's __depends May 26 15:41:56 but yeah, you'd be on your own with those May 26 15:44:42 Does anybody know where I can find information on a bitbake "ERROR: Can't get compiler version from gcc --version output" ? May 26 15:46:04 Ryan89: not without context. May 26 15:47:27 kergoth, but a BBFILE_LIST wouldn't give me the filename of the one who included me, now that I think about it.. May 26 15:47:30 I am building poky for a Raspberry Pi 4, I believe the version is 3.0.2. I had a working build on Fedora 31 and just upgraded to Fedora 32 and now have this error when I try to run a build. May 26 15:48:18 Ryan89: is F32 already GCC10-based? May 26 15:48:33 Yes May 26 15:48:52 gcc (GCC) 10.1.1 20200507 (Red Hat 10.1.1-1) May 26 15:49:02 Ryan89: then thats probably it. check if theres a fixed 3.0 state in git May 26 15:50:36 I'm relatively new to Yocto, could you elaborate? Do you mean in the poky repository? May 26 15:51:27 Ryan89: yes. 3.0 is zeus IIRC, so the hopefully easiest fix is to forward to the current head of that branch. May 26 15:52:03 Gotcha, appreciate the info. May 26 15:52:24 *lesigh* May 26 15:54:36 Letothe2nd: I've stopped answering those. If it's not listed in https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#detailed-supported-distros I just say it's unsupported /me shrugs May 26 17:25:01 Hi. When trying to build an application in a docker container that has installed in it a yocto sdk, I am having problems I havent been able to solve. I am using cmake and it is able to find_packages without problems but when I try to pkg_search_module it simply does not find the .pc file- which does exist. I am assuming it must be looking for the .pc files in a different directory than May 26 17:25:07 /opt/poky/..../blah/../usr/lib/pkgconfig May 26 17:25:16 Does anybody of you have a hint for me? May 26 17:28:49 any reason why there is no LAYERDEPENDS in meta-raspberrypi ? May 26 17:39:19 Letothe2nd: none of the gcc 10 host support changes have been backported to zeus, suspect they won't be May 26 17:47:32 right, no plans to add f32 support to zeus May 26 17:52:30 \join cmake May 26 17:52:36 \join #cmake May 26 18:37:14 RP: I have a huge recipe update patchset that I pulled from AUH and added some other items manually http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=akanavin/package-version-updates May 26 18:37:53 RP: can you run that through the AB please? then I can fix up the issues, and polish the patches, and send them in manageable chunks May 26 18:58:55 kanavin_home: its running... May 26 19:29:48 RP: thanks May 26 20:15:36 armpit: how do you extract the logs from test result json files for ltp? May 26 20:47:27 kanavin_home: nice cosy orange/red glow :) May 26 20:47:43 * RP is just happy its not a build he has to fix for a change May 26 22:38:17 so I found this gem in a vendor bsp , https://github.com/Xilinx/meta-xilinx/blob/rel-v2020.1/meta-xilinx-bsp/recipes-graphics/libgles/libmali-xlnx.bb#L156 May 26 22:38:31 that horribleness fails with read-only-rootfs May 26 22:39:11 I think if I remove the useless headless option of libmali, that _append isn't required at all, but how to make that not break ... May 26 22:40:09 damnit, getting hdmi display problems on my imx8qxp-mek. wonder if it's getting wrong timings or if something is wrong with the devicetree or what.. May 26 22:40:14 I am thinking of dropping update-alternatives from inherit list if only one option is selected, but maybe that's not the right way to do it May 26 22:40:54 kergoth: how is mainline support on the qxp ? did you try etnaviv on that GPU ther e? May 26 22:43:07 currently using a variant of the fsl sdk, haven't tried etnaviv yet, it's on my list May 26 22:43:27 RP, I scp the logs over to the host then the parser does its thing May 26 22:43:38 i'm so rusty in dealing with actual hardware, usually neck deep in build and bitbake stuff. good to be messing with a board again to freshen up :) May 26 22:43:50 even if it is occasionally irritating to have to ask for assistance May 26 22:44:36 kergoth: the nxp bsp quality is imo ... could be better May 26 22:44:45 I'd agree with that May 26 22:45:03 the amount of stuff they shoved into meta-imx/meta-bsp's layer.conf is horrifying May 26 22:51:34 kergoth: look into the kernel repo, thousands and thousands of patches :) May 26 22:51:43 kergoth: not much of it upstream May 26 23:03:21 kergoth: ouch, you have to deal with meta-imx May 26 23:04:29 kergoth: my condolences May 26 23:13:50 smurray: I switch to mainline wherever possible, because it's really impossible to deal with that one May 26 23:14:01 smurray: on mx8m* it's mostly possible already May 26 23:14:07 on mx8q/x ... sigh May 26 23:14:11 indeed May 26 23:14:15 btw any ideas about that updatealternatives hack ? May 26 23:14:22 nope May 26 23:32:07 Marex: do you have access to alter the recipe directly or are you going via bbappend? May 27 01:37:31 kergoth: well, in this particular case, I don't care either way May 27 01:38:08 kergoth: but I gave up on this, I didn't gain expected improvement after hacking it up for a test and in the next cycle I'm moving to Lima anyway, so meh May 27 01:38:16 kergoth: no point in wasting time on these awful blobs **** ENDING LOGGING AT Wed May 27 03:04:13 2020