**** BEGIN LOGGING AT Thu Apr 29 02:59:57 2021 Apr 29 03:29:05 JPEW: https://bugzilla.nasm.us/show_bug.cgi?id=3392635 seems that nasm now has --reproducible option do we still need the patch for adding debug-prefix-map ? Apr 29 03:29:56 see https://github.com/netwide-assembler/nasm/commit/bf79786e894ad16519e5374291205ebe71da07b8 Apr 29 03:33:42 hey sakoman Apr 29 03:34:18 hey khem! Apr 29 03:34:59 how is life in Hawaii !! Apr 29 03:38:45 I glad I made the move ;-) Apr 29 03:41:44 I think we are coming on six years now. Time flies! Apr 29 03:42:13 Heading off to make some dinner now . . . Apr 29 03:42:16 ttyl Apr 29 05:47:14 https://www.hackster.io/monica/building-your-own-yocto-for-maaxboard-7301ad Apr 29 07:19:25 yo dudX Apr 29 08:17:12 good morning, I have a recipe using meson find_program and that recipe fails because the program it is looking for is in /usr/local/bin I was wondering whethger I could ament HOSTTOOLS to include these programs and if so where can I do that Apr 29 08:19:06 intera_91: wrong appraoch. you rather should provide the tool through a -native recipe Apr 29 08:19:41 the find_program in meson is set to native:true Apr 29 08:19:52 thats not what i'm talking about. Apr 29 08:20:28 meson is supposed to look into the provided sysroot. and DEPENDing on -native recipes will put those things into the sysroot. Apr 29 08:22:05 isn't the sysroot is made of cross-compiled execs? Apr 29 08:22:12 it is. Apr 29 08:22:36 I need the native apps (the ones in /usr/local/bin on the host) Apr 29 08:22:51 again, thats the wrong appraoch. Apr 29 08:23:56 so the recipe I should write would only copy the x86 execs to sysroot? Apr 29 08:24:01 no. Apr 29 08:24:23 the -native recipe that you shall write must provide the tools you need in a reproducible way Apr 29 08:25:38 if you totally think you know what you are doing, are willing to pass on all sensible support and to sacrifice your eternal soul, then you can look up the HOSTTOOLS stuff in the ref-manual. but at least i personally will completely refuse any further assistance, then. Apr 29 08:27:52 LetoThe2nd: I really am trying to understand here, please be patient but if I have to write a recipe that creates the tools in sysroot, these will be compiled for the armv7 processor. the find_program says native:true so am I underrstanding this part correctly? Apr 29 08:28:54 intera_91: no, again, you didn't listen. you have to create a "-native" recipe. Apr 29 08:29:22 that exactly what those are meant for. they can run on the host during bitbake execution. Apr 29 08:29:39 so no, you're not understanding correctly. Apr 29 08:29:58 oh ok, so sorry, didn't click before Apr 29 08:30:29 i literally stated that in the very first response: tera_91: wrong appraoch. you rather should provide the tool through a -native recipe Apr 29 08:30:40 so, really, look up -native recipes. Apr 29 09:26:39 hello guys ! how can I "instruct" a recipe to have some other recipes tasks being completed before it does anything ? Apr 29 09:26:52 eg: recipe B depends on recipe A do_deploy() Apr 29 09:28:23 TaileS: it is possible for a recipe to produce GPLv2 and GPLv3 licensed packages (as an example, can very well be other licenses). When you have a package with an incompatible license but the recipe "has" other licenses that are compatible, the recipe can be built, some of its packages can be used but you get a warning for incompatibly licensed packages because they are actually **not** Apr 29 09:28:26 created/packaged, hence absent from deploy/{ipk,deb,rpm}/ directory Apr 29 09:28:48 this makes sure that you don't install a package of an incompatible license, since it's not available to you anymore Apr 29 09:28:55 having this turned into an error is a mistake IMO Apr 29 09:29:46 cccccckulcfntivunkftdveflfrbkeekdetkjbegvgbk Apr 29 09:34:09 dl9pf: yup. agreed. Apr 29 09:39:44 LetoThe2nd: wrote native recipe to basically install the tools I need but they do not appear in the recip-systool-native directory of the recipe that needs them Apr 29 09:41:18 intera_91: DEPENDS = "tool-i-need-native" in the recipe. or did you expect bitbake to build all tools unconditionally even if nobody actually needs them? Apr 29 09:42:14 LetoThe2nd: https://pastebin.com/qWbekegK Apr 29 09:42:40 am not building the tools just installing them Apr 29 09:45:07 already added that in the recipe that needs them Apr 29 09:52:48 LetoThe2nd: cat Apr 29 10:11:29 is there a way to preload docker images onto a yocto image partition? Apr 29 10:13:12 https://www.yoctoproject.org/pipermail/meta-virtualization/2019-July/004301.html Apr 29 10:24:42 hello guys Apr 29 10:25:16 I want to build a recipe that creates a tar.xz file with some files prsent in ${DEPLOYDIR} Apr 29 10:26:20 it must have the do_image_complete task in it Apr 29 10:26:58 so in the do_deploy task I create the tar.xz archive Apr 29 10:27:19 and in the do_image_complete I've added a ":" only Apr 29 10:27:38 bitbaking the recipe leads to Apr 29 10:27:54 ERROR: Function failed: BUILDSPEC Apr 29 10:28:58 thekappe: and I guess your recipe creating this tarball is a package recipe? Apr 29 10:32:05 I don't know Apr 29 10:32:26 I've just created a .bb and put in there do_deploy and do_image_complete Apr 29 10:32:35 with a DEPENDS Apr 29 10:34:38 hi, i am creating a new recipe from a git source repo using 'devtool add'. so far that works pretty well. now i am at a point where i'd like to run a 'git pull' on the sources that are placed inside my devtool workspace. is there an easy way to achieve this? Apr 29 10:50:04 thekappe: you should do all this logic within an image recipe Apr 29 10:50:43 yes Apr 29 10:50:56 it seems so Apr 29 10:51:25 probably I'll also need to create a vfat image with this files instead of a tar.xz Apr 29 10:51:53 Does a simple template exists in somewhere out in space ? Apr 29 10:53:39 thekappe: depending on the content of your tarball/fs, you might want to use IMAGE_CMD logic? Apr 29 10:54:07 otherwise, just hook a new task after do_image_complete (well, in the correct order, might be just before, don't remember exactly) Apr 29 10:55:46 creich: what's not working with git pull :) ? Apr 29 10:56:30 creich: though, you have to know that this won't probably modify the commit hash specified in the devtool'ed recipe file, so you'll need to change it once you do a devtool finish or similar (have never created a recipe with devtool :/) Apr 29 11:04:44 qschulz: devtool creates some temporary branch, so pulling won't do anything useful out of the box. thought about 'devtool sync' but that complained about missing patches.. Apr 29 11:05:09 i just removed the sources, kept the recipe and started over with a new 'devtool add' Apr 29 11:05:25 maybe that's just a missing functionality in devtool Apr 29 11:14:43 creich: it creates the branch on top of the one you asked it to base your recipe on, so a simple `git rebase ` probably would have been enough Apr 29 11:21:44 there is no support for vfat image generation ? Apr 29 11:21:58 it seems that's not listed in fstypes Apr 29 11:25:22 qschulz: hmm.. sounds plausible.. thx :D Apr 29 11:25:30 thekappe: how would you put permissions on vfat? Apr 29 11:31:06 i just need to put three file in the first partition of a emmc card that must be vfat Apr 29 11:31:15 ending up with a master degree in yocto Apr 29 11:31:53 thekappe: what about looking into wic? Apr 29 11:32:14 thekappe: you're talking about something that would come out of wic. not out of bitbake, e.g. no IMAGE in the yocto sense Apr 29 11:32:30 i know i know Apr 29 11:32:45 obviously not. ;-) Apr 29 11:32:54 point is I want to use RAUC for updataing the boot partition Apr 29 11:33:07 point is, i want a sandwich Apr 29 11:33:17 yea i know Apr 29 11:33:26 you are totallu right Apr 29 11:33:37 thekappe: You could use the "bootimg-partition" source plugin for wich. Apr 29 11:33:38 LetoThe2nd: have you had a chance to look at the recipe at https://pastebin.com/qWbekegK , the purpose is to populate another receipe Apr 29 11:33:58 and rauc wnats a vfat image file with the files required for booting in it Apr 29 11:34:47 LetoThe2nd wan't finished: the purpose is for a find_program in a meson.build in another recipe to find these programs Apr 29 11:35:39 intera_91: hum wat? Apr 29 11:36:06 thekappe: well then make one https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/scripts/lib/wic/canned-wks/sdimage-bootpart.wks#n5 Apr 29 11:36:32 thekappe: wic supports vfat, with somewhat arbitrary content. Apr 29 11:37:31 but this generate a .wic file Apr 29 11:38:10 with the partition table Apr 29 11:38:11 intera_91: i don't get what you expect from me. i have the simple impression that you haven't properly tried to understand what a -native recipe is and how it relates to another recipe depending on it. Apr 29 11:38:15 as far as I know Apr 29 11:39:58 I need a way to have something (eg recipe) that takes the deployed/installed files of recipeA recipeB recipeC and generates a vfat fs with those files in it Apr 29 11:40:06 (eg regipe ?) Apr 29 11:40:52 and I need this .vfat to be directly accessible for example from ${DEPLOYDIR} Apr 29 11:41:27 thekappe: could probably done via multiconfig, if you want to have it at that stage of the pipeline. Apr 29 11:48:07 LetoThe2nd: I must really apologise for not being clear, my question becomes why isn't the recipe I sent you the pastebin link to does not solve the find_program problem Apr 29 11:49:57 intera_91: probably because its totally whacked? randomly copying stuff into WORKDIR? Apr 29 11:50:49 intera_91: seriously. look at bc for example. it happily serves as -native as well as target variant. do you spot a difference in do_install? no. so, the -native variant needs a proper install stage that adheres paths and all too. Apr 29 11:51:41 intera_91: then anoter recipe can be DEPENDS = "bc-native". then, and only then, bc will be available under /usr/bin of the sysroot that the depending recipe can use. Apr 29 11:52:22 intera_91: in a nutshell: make sure you understand the mechanism first, instead of randomly cobbling up stuff. Apr 29 11:53:21 LetoThe2nd: thanks for the hint, I got a skeleton recipe from the net on which I based this work, guess that wasn't the right example to follow Apr 29 11:54:10 plus efl is probably just a super complicated target. Apr 29 12:08:19 intera_91: look at meta-efl recipe, that will be better start than what you shown in https://pastebin.com/qWbekegK Apr 29 12:09:40 @jama: the recipe shown in tyhe pastebin only attempt to give the actual efl recipe the tools it  needs to complete, not to install efl Apr 29 12:10:37 @jama: stems from a meson.builkd in meta-efl not completing with an error on find_program() -> not finding the program Apr 29 12:13:19 itseris: see BBCLASSEXTEND in https://git.openembedded.org/meta-openembedded/tree/meta-efl/recipes-efl/efl/efl.inc?id=b8368598aed3e07cfb638b537e409bd0b3692df9 that's how you can build efl-native from the same sources Apr 29 12:13:43 intera_91: ^ Apr 29 13:48:50 khem: We probably still need the --debug-prefix-map option in nasm.... It doesn't look like the --reproducible option covers paths Apr 29 13:51:54 khem: Ah, it looks like they moved to github, so I'll refresh the patches there Apr 29 14:22:17 hi. I am trying to enable perf with trace (related to this commit https://github.com/openembedded/openembedded-core/commit/c386abacae89a148e77ffa51630c7917e90406f9 ) Apr 29 14:23:01 I added meta-selinux to my bblayers, I created perf.bbappend to add audit to PACKAGECONFIG Apr 29 14:23:31 now I have an error that nothing provides audit-python3 Apr 29 14:23:59 all meta-layers that are mentioned in the layer dependencies in meta-selinux are added to bblayers.conf Apr 29 14:24:30 Has anyone been able to build it? Am I missing something? Apr 29 14:38:31 zbodek: triple check that all your layers are checked out in the correct release branch Apr 29 14:40:01 zbodek: the package is named audit-python Apr 29 14:40:38 and your error tells us that Yocto is looking for audit-python3 Apr 29 14:41:59 zbodek: pretty sure it's an issue introduced by this: https://github.com/openembedded/openembedded-core/commit/584af667e0000129bcb5c9e8108485f2f6590eaf Apr 29 14:42:26 probably a search and replace was done and since the PACKAGECONFIG option isn't selected by default.. Apr 29 14:42:34 it went unnoticed Apr 29 14:43:40 I don't know if Bruce is on this IRC channel, but anyway, I guess it's worth sending a patch once you have made sure it builds fine :) Apr 29 14:50:00 qschulz: thanks a million, changing audit-python3 to audit-python seems to solve the problem Apr 29 14:52:05 zbodek: please send a patch :) Apr 29 14:56:57 zeddii: ^^ (aka "Bruce") Apr 29 15:04:35 hah yes. rdepends are packages, not recipes. That would have just slipped through. It is obviously not used, so beware of runtime gremlins as well Apr 29 15:06:21 zeddii: I dont' think there ever was an audit-python3? Apr 29 15:08:55 that's not what I'm saying Apr 29 15:09:08 zbodek: I can take care of fixing it. easy for me to do. Apr 29 15:11:38 zeddii: I would greately appreciate it because I can't do it right away. Apr 29 15:12:24 no problem. I'll pull something together this afternoon. Apr 29 15:13:24 zeddii: thanks a lot! Apr 29 15:56:06 hey, dumb question.. how do I add "timeout" from coreutils to an image? Apr 29 15:56:44 Usually these things are done with PACKAGECONFIG, but that doesn't seem to be the case with coreutils. Apr 29 15:59:11 fullstop: IMAGE_INSTALL_append = " coreutils" :) Apr 29 15:59:39 LetoThe2nd: will that replace busybox stuff with coreutils, though? Apr 29 16:00:02 fullstop: should, IIUC Apr 29 16:00:05 hmm. Apr 29 16:00:18 I want to leave that alone and just add "timeout" Apr 29 16:01:21 fullstop: then you'll probably have to manually split up coreutils. Apr 29 16:01:34 Well that's a bummer. Thanks! Apr 29 16:01:59 have fun Apr 29 16:22:38 fullstop: once you've split it out of coreutils, make sure to add RDEPENDS_${PN} += "${PN}-timeout" so that you don't break existing recipes Apr 29 16:25:15 qschulz: thanks. I might end up adding timeout to busybox since that seems like it will break the least number of things. Apr 29 16:29:42 If a base recipe in layer A has SRC_URI="myfile", and there's a file with exactly that name in the files subdir of another layer whose bbappend has "FILESEXTRAPATHS_prepend := "${THISDIR}/files:"", which file does yocto take? Apr 29 16:33:28 manuel1985: look into ${WORKDIR}/temp/log.do_fetch Apr 29 16:34:39 there's no universal answer, but basically if the relative path to myfile is identical in both layers, the one from the bbappend will take precedence Apr 29 16:35:20 qschulz: I see, thank you! Apr 29 16:35:52 manuel1985: but there's a catch with OVERRIDES, so to put it simply: 1) exact same relative path, or 2) check ${WORKDIR}/temp/log.do_fetch this will tell you which paths are traversed and the first to be matched Apr 29 16:45:05 JPEW: I think I've spotted an interesting issue where multiconfig builds and hashequiv don't get on Apr 29 16:45:48 JPEW: basically if a task rehashes and is deferred due to overlap with another bit of a multiconfig build, it ends up running twice with different hashes and no sstate reuse Apr 29 17:52:19 Of course it isn't that "simple" :/ Apr 29 17:55:07 nothign ever it Apr 29 17:59:16 RP; eww Apr 29 18:18:34 I think I just don't understand the code and my fix does work "correctly" but there is a bigger setscene optimisation we need to think about Apr 29 18:19:51 bitbake or classes? Apr 29 18:20:06 fray: bitbake Apr 29 18:26:03 JPEW, fray: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=b70a10f928d3b04667b31ffce2140ec4a3290877 Apr 29 18:36:38 seems reasonable Apr 29 18:45:54 RP: Is it possible tid is already in sd_deferred and it might get added to torehash twice? Apr 29 18:52:23 JPEW: yeah that patch is still needed. Although that option you added is behaving like -fmacro-prefix-map Apr 29 18:52:46 not -fdebug-prefix-map Apr 29 18:53:14 change its doing is changing FILE directive in generated .o from .asm files Apr 29 18:58:22 khem: I don't follow. It's changing the FILE symbol in the elf file, which is implicitly added by nasm; IIRC this is the same as the gcc, and is affect by -debug-prefix-map, not -macro-prefix-map Apr 29 18:58:33 ndec: when I search for string "oe-pkgdata-util" on docs.yoctoproject.org I can not find it but its there https://docs.yoctoproject.org/singleindex.html#viewing-package-information-with-oe-pkgdata-util Apr 29 18:58:47 google search returns it from mega-manual correctly Apr 29 18:59:08 well google is definietly known for finding things better than anyone ;) Apr 29 18:59:28 JPEW: yes I mixed it with __FILE__ which is same as FILE in c/c++ Apr 29 18:59:58 ndec: but sadly it does not index docs.yoctoproject.org yet Apr 29 19:00:12 so all hits go to https://www.yoctoproject.org/docs/ Apr 29 19:00:25 that's correct.. and something we should fix.. Apr 29 19:00:33 and 2.2 is sorted above newer ones Apr 29 19:01:08 so ideally it should point to current docs before the older released ones Apr 29 19:04:33 is there a simple trick determing which *.bb got used (in the case where there are multiple layers with same recipe)? Apr 29 19:08:53 (kind of like 'bitbake -s' but showing which layer, or ideally, the full path to the *.bb file) Apr 29 20:00:39 JPEW: I think from the way it is constructed, no, it shouldn't be Apr 29 20:03:29 rfs613: bitbake-layers ? Apr 29 20:04:36 RP: that shows the layers & priority, what I wanted was to quickly find out which *.bb (from which layer) is actually used. Apr 29 20:05:09 I was able to extract this manually from 'bitbake -e foobar', looking at eg. SRC_URI to see which *.bb it came from. Apr 29 20:06:26 rfs613: even something like bitbake-layers show-recipes -f Apr 29 20:08:00 RP: oh neat! I had tried show-recipies, but didn't know about -f option Apr 29 20:09:48 thank you :) Apr 29 20:11:04 rfs613: neither did I until a few minutes ago but I figured it had to do it somehow Apr 29 20:11:22 those commands do have good hel Apr 29 20:11:25 help Apr 29 20:13:53 yup, as usual just a case of RFTM... :-) Apr 29 20:15:01 armpit2: did something change in meta-security recently? Apr 29 20:15:20 armpit2: it passes testing with master-next and failed when I merged to master :( Apr 29 20:31:32 RP: OK, seems good to me then Apr 29 20:49:23 rfs613: bitbake-layers show-overlayed will indicate which version of a recipe is used (it'll be the first one listed) Apr 29 20:52:34 smurray: i had actually tried that... but the package I was interested in did not appear in that output. In fact it looks like only a small subset of total recipies appear. Apr 29 20:53:00 rfs613: AFAIK it only shows recipes that have more than one version Apr 29 21:02:48 smurray: hehe, looks like i managed to have both poky and openembedded-core repos checked out along side each other. Only poky was added as layer, so bitbake only had one spot to find the recipe. However when I use find/grep both copies show up. Apr 29 21:03:08 rfs613: doh! Apr 29 21:03:37 this may explain a lot of my confusion ;-) Apr 29 21:11:45 Good Evening! Is anybody here active in the conference planning for Yocto Project Virtual Summit? Apr 29 21:11:53 Tried contacting the conference team via the conferences@lists.yoctoproject.org e-mail address/mailinglist like mentioned at https://pretalx.com/yocto-project-summit-2021/ but it is beeing rejected because I'm not subscribed to that list. Apr 29 21:11:56 Not ideal for an outwards facing contact address... Apr 29 21:15:10 dwagenk: you want ndec or tlwoerner Apr 29 21:15:48 RP: thanks Apr 29 21:16:01 dwagenk: you can send me an email at twoerner@gmail.com Apr 29 21:17:18 dwagenk: the conferences@ mailing list is more of an email list for the conference planners to talk amongst themselves while doing the planning :-) Apr 29 21:17:23 tlwoerner: done, thanks! Apr 29 21:37:52 Hello, all. I have a yocto build on a folder and I intended to move it to another drive. Copying it directly made the symlinks be dereferenced and soon I had no storage left. What way I could copy it, keeping the symlinks functional, and that doesn't involve tar and untar? Thanks! Apr 29 21:44:56 MysticMice: One approach would be to just move the sstate cache to the new drive and then rerun the build there. Apr 29 21:46:29 Sounds like a plan! But, forgive me my lack of knowledge, are there no symlinks on sstate cache? Apr 29 21:46:30 yeah don't bother moving anything but the layers and the sstate Apr 29 21:46:32 ignore tmp. Apr 29 21:46:41 sstate is just compressed archives Apr 29 21:47:51 Great! I've just started to rebuild, but, i think I will cancel it and try that. Thanks! Apr 29 22:50:15 JPEW: I don't suppose you can easily see why "bitbake XXX -l RunQueue -l RunQueue" doesn't show the same cooker output as bitbake XXX -DD ? Apr 29 22:52:08 its really starting to get to me as I don't want to parsing logs, just cooker Apr 29 23:10:04 RP: I didn't think it counted the arguments that way? Apr 29 23:10:54 JPEW: bb.msg line 166, dlevel = len(tuple(iterator)) Apr 29 23:11:21 JPEW: I can't make it print any logging though even though it makes it through to there Apr 29 23:15:41 * JPEW looks Apr 29 23:18:05 RP: If you uncomment the logging_tree lines in knotty, you can see that the RunQueue logging level is not being affected (for some reason) Apr 29 23:19:00 JPEW: hmm :/ Apr 29 23:21:41 Hmm, it propagates the users logging config into loggerDefaultDomains, but I'm not sure if it goes the other direction Apr 29 23:22:12 Or probably more accurately, the -l option should be handled differently Apr 29 23:24:03 JPEW: I could have sworn this used to work so I guess something changed :/ Apr 29 23:24:24 Ya, I'm a little suprised also Apr 29 23:26:23 RP: Ideally, the loggerDefaultDomain would be on the way out the door; AFAIK the only (gross simplification) reason it has stuck around is because it's the way that the logging configuration is shared between the UI and bitbake process Apr 29 23:27:36 JPEW: ideally, yes, its horrible Apr 29 23:28:04 JPEW: I guess I should be trying to use a logging config to do what I'm trying to do Apr 29 23:28:17 Ya, that would work Apr 29 23:28:23 Equally, runqueue is making my head hurt more than enough as it is Apr 29 23:32:47 RP: { "version": 1, "loggers": { "BitBake.RunQueue": { "level": "VERBOSE" } } } Apr 29 23:55:21 JPEW: I can't make that work either :( Apr 30 00:00:59 JPEW: oh, it could be my fault with other debugging :/ Apr 30 00:03:00 no, it isn't that... Apr 30 00:09:41 fray: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=1693c6e229c4e018ae68ffa5b7a640ef115b3aba might be interesting in your big builds Apr 30 00:10:33 ohh another Apr 30 00:12:15 interesting Apr 30 00:13:05 I've got that one and a previous queued to try.. Apr 30 00:22:59 khem: I can't work out which of the patches are causing which issues :( Apr 30 00:24:48 reproducibile builds still running 12 hours later :/ Apr 30 00:47:06 RP: ok point me to one Apr 30 00:47:59 we can serialize them a bit Apr 30 00:48:08 lets get all other patched in first Apr 30 00:48:23 then get the -ffile-prefix-map patch Apr 30 00:48:33 then get gcc11 Apr 30 01:31:24 RP: Right. Sorry, I had to step away for supper. I forgot to include the verbconsole handler: { "version": 1, "loggers": { "BitBake.RunQueue": { "level": "DEBUG3", "handlers": ["BitBake.verbconsole"] } } } Apr 30 02:04:46 RP: Added a patch to re-enable the "-l" option; it should make it do what you want now **** ENDING LOGGING AT Fri Apr 30 02:59:56 2021