**** BEGIN LOGGING AT Wed Jun 03 02:59:57 2020 Jun 03 06:09:44 RP, in a .bbclass file, is there a way to calculate the filename of the file that contained the "inherit foo" directive ? Jun 03 06:18:44 kroon: not without the internal depends variables Jun 03 06:20:57 kroon: I don't remember if we ever did export anything official or not Jun 03 06:21:12 RP, ok Jun 03 06:42:46 kroon: BBINCLUDED looks like an official variable Jun 03 06:44:10 RP, thanks, i'll check it out Jun 03 07:23:51 EP: even when you apply both patches? Perl should be gone then? Jun 03 07:33:42 sno: this isn't related to your patches, not gotten to those yet but am planning to queue them when I sort the current patch queue Jun 03 07:40:26 RP: which patch is it related to? I check it hopefully today then Jun 03 07:42:44 sno: its current master so maybe something which came with the 5.30.2 update? Jun 03 07:43:44 I run the current master and do not see such a race condition ... Jun 03 07:44:20 is the complete log file available? Jun 03 07:45:16 I am using qemu for testing. Is it possible to deploy a new version of an application without restarting qemu? I know i can use `devtool` but this seems not to be the propper way when working without sdk Jun 03 07:52:23 RP: in the web ui I do not see any build related issue, it bails out much earlier Jun 03 07:56:30 sno: you mean the failure in perl do_install ? Jun 03 08:00:40 RP: found it - didn't realize that 2d failed ... digging after lunch (around that) Jun 03 08:02:50 sno: thanks Jun 03 08:14:04 aw, looks like my 2.7 patch for better Ubuntu 20.04 support just missed 2.7.4 ... https://patchwork.openembedded.org/series/23841/ Jun 03 08:30:18 Can I get the version of another recipe? I'd like to know the major version of php in my recipe. Jun 03 08:30:29 sstiller: no. Jun 03 08:31:15 ernstp: unfortunately yes :/ Jun 03 08:31:37 sstiller: https://twitter.com/TheYoctoJester/status/1217166071519744000 Jun 03 08:32:04 RP: small extra release? :-) or you could push it out on the branch at least perhaps... Jun 03 08:33:35 qschulz: hi5 Jun 03 08:34:01 ernstp: have you followed the ubuntu 20.04 support in warrior? A few developers at my company are migrating to it and we're still using thud (the one before warrior) and obviously we run into issues (the qemu one for example :) ). Do patches have a mention that they are fixing ubuntu 20.04 support? Jun 03 08:34:10 ernstp: there is a surprising amount of work in testing and releasing the releases :( Jun 03 08:42:03 Letothe2nd, qschulz: OK. Once I have seen the usage of the kernel version + rev in a kernel-module recipe (>10 years ago, oe-classic). So I thought, there could still be a way. Jun 03 08:44:39 sstiller: maybe the kernel is still special, don't know. but the rule is: a recipe has no idea what another recipe does. Jun 03 08:47:52 RP: it's the same perl race we see every once in a blue moon. perl-cross upstream and I tried to get to the bottom of it but couldn't https://github.com/arsv/perl-cross/issues/75 Jun 03 08:49:33 kanavin_home: I wonder what is going on :/ Jun 03 09:36:36 What is the propper way to edit this source code (https://bitbin.it/ttYV9AL5/) without creating bbappend or patch files? First approach was `devtool modify -n exampleRecipe path/to/repo/files`. Jun 03 09:37:35 chris_ber: the proper way is to extract the sources into a freestanding recipe, instead of bundling it into the metadata. Jun 03 09:37:48 freestanding repository, pardon. Jun 03 09:38:54 @Letothe2nd so that that SRC_URI points directly to a git repo? Jun 03 09:39:02 chris_ber: yup. Jun 03 09:39:20 chris_ber: in that case, devtool modify will also work as expected, then. Jun 03 09:40:13 i don't have to use the ' -n' -Option? Jun 03 09:41:14 chris_ber: that depends on if you already have a checkout of the repository than you want to use, (then you need -n) or if you want devtool to create one for you (no -n) Jun 03 09:42:09 ok, i will check this out Jun 03 09:44:08 chris_ber: and while you're at it, get rid of that makefile :P Jun 03 09:47:40 Letothe2nd: You suggest cmake? Jun 03 09:48:43 chris_ber: i personally suggest cmake, but autotools or meson do the job too. everthing is better than handcarving makefiles. Jun 03 09:48:58 ok Jun 03 10:13:53 meson meson meson Jun 03 10:14:01 metal metal metal metal Jun 03 10:14:03 * rburton does badger dance Jun 03 10:14:03 erm wait Jun 03 10:14:12 * Letothe2nd does pogo dance Jun 03 10:16:51 rburton: but i think we can agree on that everything > handwritten Makefiles, right? Jun 03 10:17:05 absolutely Jun 03 10:19:27 \m/ Jun 03 10:20:59 does yocto explicitly set file size limit to 0 for core dumps somewhere? I.e. with ulimit/prlimit/LimitCORE or something Jun 03 11:34:56 Dear all, I have a question regarding security of my yocto image which I phrased here https://stackoverflow.com/questions/62171696/is-it-secure-to-install-everything-as-root-when-rootfs-is-read-only Jun 03 11:35:16 As usual, I would like to open this issue here as well as usually this is more productive to have a chat about Jun 03 11:36:48 emrius: s/install/run/g Jun 03 11:36:53 emrius: thats the real point. Jun 03 11:38:45 Letothe2nd fixed the question ;) Thanks Jun 03 11:39:22 But is it okay to have only user root given ro-rootfs and either no ssh login or certificate login? Jun 03 11:39:37 emrius: nope, it is not. Jun 03 11:40:06 May I quote this concise reply in SO? :) Jun 03 11:40:19 emrius: reasoning: unless you have really elaborate security measures in place, the rootfs is relatively easy to do a mount -o rw,remount / Jun 03 11:40:41 emrius: no, i explicitly do not allow to be quoted on SO. Jun 03 11:40:46 Ah! Thanks! Thats what I was hoping for Jun 03 11:41:29 emrius: plus, stuff that only lives in /tmp is just as bad as well. hence, resort to a "ordinary" user whenever possible Jun 03 11:41:32 Ok, that makes sense. Would you like to post an answer or should I write that there? Jun 03 11:41:53 emrius: i am really not kidding. i will not answer there and i do not allow do be cited there. Jun 03 11:41:59 Letothe2nd thanks a lot. That was a tremendous help Jun 03 11:43:03 Letothe2nd ok no worries. However, for others stumbling across the same issue a reply should be given. Not quoting. Jun 03 11:43:20 emrius: however you deem it best. Jun 03 12:49:31 qschulz: I think it's just the two patches uninative glibc, and qemu. with that warrior works fine here Jun 03 13:06:40 Letothe2nd: do you have a propper cmake exmaple where the SRC_URI uses a git repo? And the git repo should provide the CMakeLists.txt right? Jun 03 13:09:51 chris_ber: write proper CMakeLists.tzt, put it into git repo, in recipe add inherit cmake. Done Jun 03 13:10:36 chris_ber: https://github.com/LetoThe2nd/simplehello Jun 03 13:10:54 chris_ber: devtool add that should give you an instantly usable recipe as a blueprint Jun 03 13:11:05 ok, thx Jun 03 13:56:13 Letothe2nd: can you help me again? I am still stuck to integrate cmake: https://bitbin.it/x5GghQCf/ Jun 03 13:57:49 bitbake seems to ignore the CMakeLists.txt file in the git-repo itself Jun 03 13:58:45 chris_ber: how did you end up with that result? Jun 03 13:59:06 i postet the error in teh example Jun 03 13:59:15 chris_ber: i mean, i am really pretty sure that a simple devtool add onto the repo i gave you builds cleanly. Jun 03 14:00:12 i never tried to but now i have to. i mean the recipe looks the same like yours Jun 03 14:01:05 chris_ber: seriously, its pretty annoying if i first take the time to look up the url and tell you how to start, then you come back and say "i didn't do what you said but it still doesn't work, help!" Jun 03 14:01:35 thats true, sorry Jun 03 14:02:21 chris_ber: S = "${WORKDIR}/git" Jun 03 14:02:44 chris_ber: srcrev to a branch name is a no-go as well IIRC Jun 03 14:03:21 chris_ber: the point why i explicitly named devtool is that it adds a kind of "magic" bbappend under the hood that a) makes your recipe look normal while b) it does the tricks that qschulz just mentioned. Jun 03 14:03:30 chris_ber: thus, things "just work". Jun 03 14:03:51 if you want always the latest commit in the master branch, have a look at AUTOREV, but again, not recommended as it breaks one important feature of build systems: reproducibility Jun 03 14:08:14 it is really easy to make it wrong in yocto and and to do it the correct yocto way. I tried to push my Makefile-project into a cmake-project. I will try the yocto commands but sometime it "seems" to be easy to just edit some file. Now i am trying to add your hello example Jun 03 14:10:51 chris_ber: it is complicated sometimes, yes. i actually have the article explaining what that is almost completely ready and laid out on my mind, but no time to write it down yet. Jun 03 14:54:06 Letothe2nd: it worked well with devtool add ... with your example and with my project. Thx Jun 03 14:55:04 chris_ber: see :) Jun 03 14:55:42 I've written several python modules and incorporated them into my yocto build. I'd like to include running pytest as part of the build process. I tried something like do_run_testsuite(){ python3 -m pytest -v ${WORKDIR}/git/tests}addtask do_run_testsuite before do_install after do_configure Jun 03 14:56:06 Sorry on the formatting: do_run_testsuite(){ python3 -m pytest -v ${WORKDIR}/git/tests}addtask do_run_testsuite before do_install after do_configure Jun 03 14:57:01 Anyway, Yocto can't find the pytest module and fails. I've also tried calling /usr/bin/python3, but that fails to import the standard python modules when called. What is the best way to execute pytest as part of the build process? Jun 03 14:57:45 d_thomas: (just guessing) make a recipe that provides it as -native Jun 03 14:58:13 that makes pytest as -native? would that recipe then be part of the image? Jun 03 14:58:59 d_thomas: it would only be if you add it. Jun 03 15:00:02 just generically speakign: you want to run something at build time, on the host. that means you have to provide it as a -native (or native enabled) recipe, so bitbake can set it up Jun 03 15:00:41 interesting, I haven't done that before Jun 03 15:02:38 d_thomas: there is always a first time! :) Jun 03 15:03:32 Yeah, I'm googling now to do this right now. Looks like there is some stuff in meta-sca for native pytest. I've just never seen something get included without being in the image recipe Jun 03 15:03:55 d_thomas: i bet you have. Jun 03 15:05:38 d_thomas: you probably didn't notice, but basically all the toolchain stuff used for cross compilation are prime examples for native recipes :) Jun 03 15:08:09 I see a case where DEPENDS brings in a native package Jun 03 15:09:01 d_thomas: yes. that means "i need this thing being available at bild time on the host to do $SOMETHING in order to build" Jun 03 15:11:25 makes perfect sense. I'm going to give this a try. I'll let you know if it works, but thank you very much for your help! Jun 03 15:11:32 have fun! Jun 03 15:12:39 Honestly, it has been. 6+ months into using Yocto for an embedded device and my teammate and I have gotten so much done. It's made life a lot easier. Jun 03 15:14:42 d_thomas: once you get the hang of, its awesome. if you don't, its like hell. Jun 03 15:17:01 LOL, that's very true. Jun 03 15:38:57 Looks like I'll be hunting down native python modules. Python3-native is present in openembedded-core 2.6, but is gone after 2.7. Jun 03 15:40:48 d_thomas: i guess theres some pythonesque bit missing that i just don't know as i don't do python. Jun 03 15:41:28 You have me on the right track though. The case of the missing pytest is solved. Jun 03 15:41:48 \m/ Jun 03 15:41:55 throw money! throw money! Jun 03 16:18:32 d_thomas: python3-native exists but it just merged into the main recipe Jun 03 16:19:26 Thanks, I just figured that out. I'm currently pulling in meta-sca to get access to other native recipes. We'll see how that goes Jun 03 16:20:05 pytest was easy, but then I've had to pull in native recipes for six, py, pluggy, and the list might still be going. Makes me think I'm missing a recipe that includes all of them. Jun 03 16:20:25 meta-python is your friend Jun 03 16:26:00 Unfortunately not all of the recipes in meta-python support running natively it seems Jun 03 16:26:23 easily solved Jun 03 16:26:28 BBCLASSEXTEND = "native" Jun 03 16:29:09 Right, that would work. At the moment, I'm trying to add meta-sca to my bblayers to get those native versions. Unfortunately it's building about 3/4th of my image so I'm waiting Jun 03 16:38:27 RP: there is not much to see from the log - the update is out for quite a while (meanwhile 5.30.3 is out) - did it occur before? Jun 03 16:38:40 RP: is it know how to reproduce? Jun 03 16:42:59 Is there anyway to set the logger level when running oeqa tests? Jun 03 16:44:45 I'm trying to trace my way through `OESelftestTestCase.write_config()`, I can see calls to self.logger.debug() but those won't print unless I can set the logger verbosity level Jun 03 16:45:15 `oe-selftest` has no verbosity argument :( Jun 03 16:46:26 `oe-selftest -r archiver` is failing on master for me and I can't add more archiver tests until I can figure out why the existing tests don't like me Jun 03 17:19:45 Is there any documentation on how `oe-selftest` works? The code is pretty hairy and I can't trace my way through what's happening Jun 03 17:21:49 The fragments added by `self.write_config()` aren't affecting the bitbake env Jun 03 17:22:25 So the testcase adds `INHERIT += "archiver"` but the value of `INHERIT` doesn't get changed Jun 03 17:22:48 Second day I'm off yak shaving in the internals Jun 03 17:23:26 it uses a fresh build dir so maybe you're just looking in the wrong place? Jun 03 17:23:45 rburton: I'm running `bitbake -e` in the test and dumping the output Jun 03 17:23:52 ah Jun 03 17:24:20 I've already added 2 new arguments to `oe-selftest` today which I'll submit as patches Jun 03 17:25:08 But I'm totally lost now debugging these failures Jun 03 17:30:19 Ok. I run `oe-selftest` in my build directory `/w/build`. It creates a fresh build dir `/w/build-st`. However, `write_config()` writes to `/w/build/conf/selftest.inc` which looks like it's the wrong directory Jun 03 17:30:41 But that's not something I've changed. If that was a problem, oe-selftest would never have worked Jun 03 17:34:03 I've spent 1h fixing the archiver handling of gitsm in a way we can safely backport to dunfell as well as apply to master. Then over 2h trying to add a couple of tests and figure out why oe-selftest won't work Jun 03 17:34:19 I give up for now Jun 03 17:40:09 Well this is a fun one. Build decided to start throwing me a laundry list of "nothing provides errors" for a recipe. Except I've tried setting INSANE_SKIP with file-rdeps and it's still bugging out. Also unsure why I'm getting them in the first place. It's yelling at me for `/bin/env`, `ld-linux-x86-64.so.2()(64bit)`, Jun 03 17:40:10 `ld-linux-x86-64.so.2(GLIBC_2.3)(64bit)`, and `libc.so.6(GLIBC_2.14)(64bit)`. Jun 03 17:51:04 Worked yesterday too...-_- Jun 03 18:03:41 sno: we don't know how to reproduce :( Jun 03 18:05:09 paulbarker: I understand your frustration, I think it may be a poky vs bitbake+oe-core thing :( Jun 03 18:05:32 paulbarker: there is an open bug about they being problematic but how many people actually work on open bugs? :( Jun 03 18:10:13 RP: Ah, ok, I'm using oe-core+bitbake Jun 03 18:10:34 I made the tests work by hardcoding the path `write_config()` uses Jun 03 18:10:51 But obviously I can't submit that haha Jun 03 18:16:57 RP: Do you know if there's a bugzilla entry for that bug? Jun 03 18:21:19 paulbarker: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13815 Jun 03 18:21:36 paulbarker: we have some idea about the cause now so the title needs updating Jun 03 18:22:00 paulbarker: I'd bet on it being the same problem you saw though Jun 03 18:22:23 paulbarker: I'd also guess its the seperate builddir change I made in the last 12 months that broke it Jun 03 18:22:34 and now I can feel guilty about trying to find time to fix it :/ Jun 03 18:22:56 RP: Ok that helps narrow things down Jun 03 18:24:16 paulbarker: oe-selftest -j and without -j used to work differently which caused bugs. I made them work the same which means we now have different bugs. The separate builddir is necessary for the future though Jun 03 18:24:21 I guess `write_config()` really should write to the `selftest.inc` file in the new build directory Jun 03 18:24:34 Not in the original build directory Jun 03 18:25:30 paulbarker: yes Jun 03 18:25:47 paulbarker: I can probably find the code for you quite quickly Jun 03 18:25:54 RP: I've got it Jun 03 18:26:08 Currently hardcoded the path and the tests work Jun 03 18:26:42 I just need to pass the `newbuilddir` path to that function and I'll have something I can submit as a patch Jun 03 18:26:45 paulbarker: http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/lib/oeqa/selftest/context.py#n62 that remapping will be breaking Jun 03 18:27:18 RP: Ah, that wasn't where I was looking but that does make sense Jun 03 18:27:50 paulbarker: I'd much prefer we had a way to change a variable to make this change and I was aiming to ultimately refactor this to a variable Jun 03 18:28:04 but for now its search and replace :( Jun 03 18:28:21 RP: I see Jun 03 18:28:26 one step at a time as there were other bigger problems and you have to work through them in turn Jun 03 18:28:39 I may have a head start as I've already done a little related work Jun 03 18:30:06 I've added a `-B` option to oe-selftest to allow you to override the newbuilddir path since just adding `-st` onto the name of the existing build directory is bad when your build directory is a symlink Jun 03 18:32:15 * RP tries to remember what he was doing a couple of hours ago. Fixing buildhistory-diff since I can't merge master-next and the current output is unusable, I think :/ Jun 03 18:34:20 * RP remembers about food, that should probably come first :) Jun 03 18:45:48 RP: maybe it wents away when updating to 5.30.3 :) Jun 03 18:46:10 sno: happy to take an upgrade and see :) Jun 03 18:46:36 RP: I note it on a sticky and put it on the desk to dig later when I have a little more time Jun 03 18:47:05 maybe I run cleansstate / install in an endless loop until it crashs Jun 03 18:47:35 sno: no need to cleansstate, just run a clean and a "bitbake perl -c install" Jun 03 18:47:38 much faster Jun 03 18:47:59 okay, I'll give it a shot Jun 03 18:48:30 coming weekend is pen'n'paper rpg - so will be next week ^^ Jun 03 19:00:02 RP: story of my life I get a single phone call and it takes me half an hour remember what I was doing Jun 03 19:02:07 d_thomas: Im with rburton on this one, you should probably reuse as much as possible from meta-python, if you need a native version either add a bbappend with BBCLASSEXTEND on your layer or submit the change to meta-python if it makes sense Jun 03 19:02:45 alejandrohs: Does that mean avoiding the meta-sca layer? Jun 03 19:03:35 I pulled python3-pytest-native from there as it seems better equipped for running pytest Jun 03 19:03:43 d_thomas: not avoiding it but I would assume the meta-sca layer should depend on meta-python and reuse as much from it, trying to to duplicate work Jun 03 19:04:53 this is supposed to work in a modular fashion, oe-core->meta-oe->meta-python->meta-sca->your-layer Jun 03 19:05:32 if theres something in meta-sca thats supposed to be in meta-python I would say submit that change Jun 03 19:05:43 I understand Jun 03 19:06:02 Yes, I think meta-python could learn from some of meta-sca's use of native in places Jun 03 19:06:34 d_thomas: my point its try to avoid to duplicate recipes Jun 03 19:08:10 so I haven't duplicated any recipes, just. Sounds like you are asking for the changes in meta-sca to be identified and moved into meta-python? Jun 03 19:08:28 d_thomas: if it makes sense yest Jun 03 19:08:44 d_thomas: the recipes dont seem very different at first glance though Jun 03 19:09:09 d_thomas: why do you say its better equipped? Jun 03 19:10:16 alejandrohs: I was running into trouble with running pytest natively before I added meta-sca to my layers. When I look at the meta-sca recipe, it depends on a lot of native recipes. meta-python does not have those same recipes in Depends. Jun 03 19:10:45 I have things working now. It's possible I could pull meta-sca and get it working without it and minimal bbappends. I could try that now that I understand how to make it work. Jun 03 19:10:56 d_thomas: Then if it makes sense, those dependencies should be added on meta-python Jun 03 19:11:04 right Jun 03 19:11:45 alejandrohs: I'll give that a try (will take some time). At least I have the path to success now Jun 03 19:12:26 d_thomas: you also have to account for the fact that the further you get away from oe-core the least tested something will be, so you might end up maintaining code in the future Jun 03 19:13:17 d_thomas: IMO meta-sca should base more of its stuff on existing recipes from meta-python, having a separate native recipes vs BBCLASSEXTEND does not necessarily make it better Jun 03 19:14:32 alejandrohs: I agree with you there. Jun 03 19:37:43 test Jun 03 19:40:16 is the yocto irc logs not available since few days now? Jun 03 19:41:06 kiwi_29: Ya, it has been broken for a while I keep forgetting to mention it.... I don't know who maintains that Jun 03 19:41:30 halstead: ^^ Is that you? Jun 03 19:41:49 khem ? Jun 03 19:42:02 @khem Jun 03 19:43:00 I have created a custom distro which inherits from core-image-minimal and it has a recipe custdistro-prod.bb Jun 03 19:43:25 I have reused poky for creating my custom distro Jun 03 19:47:12 poky's build/conf/local.con has debug-tweaks enabled by default. I wanted to disable root user login from shell for production distro therefore I added EXTRA_IMAGE_FEATURES_remove = "debug-tweaks" inside customdistro-prod.bb Jun 03 19:47:22 and it has worked Jun 03 19:49:06 However, I also want a development version of distro which allows root user login from shell. The dev version of distro is customdistro-dev.bb . the code for customdistro-dev.bb is below Jun 03 19:49:23 require recipes-core/images/customdistro-prod.bb Jun 03 19:49:23 EXTRA_IMAGE_FEATURES += "debug-tweaks" Jun 03 19:49:39 However it does not seem to be enabling root login for dev distro . Jun 03 19:50:38 I am using "require recipes-core/images/customdistro-prod.bb" as first line in customdistro-dev.bb because I want to get all the implementation done for customdistro-prod.bb Jun 03 19:51:08 any idea where is the problem... or if my approach of creating prod and dev version of distro is not correct? Jun 03 20:03:23 kiwi_29: _remove should be your last resort Jun 03 20:03:30 kiwi_29: its relaly hard to get something back Jun 03 20:04:25 I see...then what should I use in prod distro to remove "debug-tweaks" Jun 03 20:05:20 kiwi_29: local is meant for local changes Jun 03 20:05:50 you can simply comment out the EXTRA_IMAGE_FEATURES line Jun 03 20:06:22 kiwi_29: the dev distro should probalby have its own conf and thats where you would add that Jun 03 20:08:45 the build/conf/local.conf is only one file for the whole source..correct? Jun 03 20:08:56 which file should I put the dev distro config in? Jun 03 20:09:56 my director structure is meta-customdistro/recipes-core/images/customdistro-dev.bb and meta-customdistro/recipes-core/images/customdistro-prod.bb Jun 03 20:10:18 also meta-customdistro/conf/layer.conf Jun 03 20:10:39 can there be more than one build/conf/local.conf ? Jun 03 20:14:42 kiwi_29: No, but there are other files you can use. We've co-opted the site.conf file to stuff in all our "product" configuration Jun 03 20:15:17 kiwi_29: Then we have a line like: "require conf/include/mode/${BUILD_MODE}.conf" Jun 03 20:16:05 conf/include/mode/release.conf is empty Jun 03 20:16:29 conf/include/mode/development.conf has EXTRA_IMAGE_FEATURES += "debug-tweaks" Jun 03 20:16:46 I see...so then it means, I should disable debug-tweaks from build/conf/local.conf and create a seperate conf file only for dev distro where I actually add Jun 03 20:17:11 JPEW .. I see...that sounds good Jun 03 20:17:14 kiwi_29: We don't have a seperate "dev" distro in this setup Jun 03 20:17:41 development.conf just has all the settings in it (like you would put in local.conf) to make it a "development" build Jun 03 20:18:09 Our users can then just add 'BUILD_MODE = "development"' to get all the settings in one shot Jun 03 20:18:31 ^^ They add that to their local.conf Jun 03 20:18:32 so you basically are building with debug-tweaks (because you "require conf/include/mode/development.conf" ) Jun 03 20:18:44 I see Jun 03 20:18:51 Ya, I mean thats an example. we do a bunch of other stuff also Jun 03 20:19:31 Hence the conf file. If it was just the one setting, I'd probably just let people add it to their local.conf on their own :) Jun 03 20:20:01 where is your logic for parsing BUILD_MODE and there selecting appropriate conf file? Jun 03 20:20:05 it is in distro recipe? Jun 03 20:20:29 No, it's in site.conf.... it's just two lines: Jun 03 20:20:38 BUILD_MODE ?= "release" Jun 03 20:20:57 require conf/include/mode/${BUILD_MODE}.conf Jun 03 20:21:50 thank you JPEW .. this sounds good approach Jun 03 20:22:09 "good" might be an overstatement, but it works for us :) Jun 03 20:36:32 halstead: is yocto-announce still live? I got a bounceback Jun 03 20:37:43 awafaa, Yes. It rejects mail by default except for a small whitelist since we advertise that list as very low traffic sending only 1 or 2 e-mails a month. Jun 03 20:37:53 awafaa, I'll whitelist your address. Jun 03 20:38:03 JPEW, That is something I can look at. Jun 03 20:38:04 makes sense Jun 03 20:38:25 halstead: thanks Jun 03 20:39:26 awafaa, Doesn't look like you are even a list member. Are you using your arm e-mail? Jun 03 20:39:47 halstead: yes sir Jun 03 20:41:16 awafaa, I've subscribed your e-mail, made you a mod, and whitelisted you. Should be set to send. Jun 03 20:55:17 JaMa: would you be able to look over the email I sent to OE-Arch and see if you're ok with it please? Jun 03 21:02:23 kiwi_29, JPEW The channel is being logged again. I have logs for the missing days but in a different format that will take a little munging to publish with the rest. Let me know if you need those days. Jun 03 21:03:32 The bot hit an exception in the socket handling code that knocked it out of the channels but didn't kill the process allowing it to auto-recover. Jun 03 21:04:26 halstead I m good and do not need any logs ..thank you for your work Jun 03 21:25:30 halstead: you are a scholar and a gentleman Jun 03 21:26:21 Thank you. It's nice to help out in a few easy ways instead of hard stuff all the time. :) Jun 03 21:47:59 halstead: we do seem to manage our share of hard things although I think the backlog isn't anywhere as bad as it used to be at least? :) Jun 03 21:48:52 It's better but still a bit overwhelming. Jun 03 21:52:44 halstead: we should probably talk then :/ Jun 03 21:55:25 RP, Okay. Do you have time on Monday perhaps? It's a little extra pressure now while I'm trying to keep up and documenting more. I can see the relief down the tunnel though. Jun 03 21:57:34 halstead: Sometime on Tuesday would probably work better? Yes, I can imagine it feeling worse before it gets better. Jun 03 21:57:59 RP, Tuesday would be good for me. Jun 03 22:08:44 Hi, new to yocto so excuse the basic question: Jun 03 22:09:12 Just tried `bitbake core-image-base --continue` Jun 03 22:09:53 It fails with `error: gpg failed to sign the data` Jun 03 22:11:36 It looks possible that bitbake makes commits as part of this process but in a custom shell environment. Jun 03 22:12:22 Is that correct? If so, could someone point me to where/how this is setup/manged Jun 03 22:18:40 markv: we don't have enough information to answer the question. pastebin more of the error so we can understand the context. We don't sign things by default so its as if you've enabled some setting to cause that Jun 03 22:23:52 Hey guys, tried to solve this issue for another day but didn't get any progress. Basically, I have a recipe that simply unpacks a tar archive into a specific area of the rootfs. On the do_rootfs for the application, I get 4 "nothing prived" errors. They're for `/bin/env/`, `ld-linux-c86-64.so.2()(64bit)`,`ld-linux-c86-64.so.2(GLIBC_2.3)(64bit)`, Jun 03 22:23:52 and `libc.so.6(GLIBC_2.14)(64bit)`. Any ideas? Jun 03 22:26:02 bsmerbeck: these are prebuilt packages ? Jun 03 22:28:36 RP: Correct, we setup default signing, but in a way that tries to ensure commits are made only us. Trying to guard against these sorts of things. Long way of saying the other error message is concerns the internal environment. Jun 03 22:31:26 RP, what author does bitbake commit as? Jun 03 22:33:37 RP: will do Jun 03 22:39:36 khem: sorry, VPN just kicked. The recipe doesn't require any installation as it's a node/react app Jun 03 22:40:51 khem: CI handles gathering all the packages and "cross compiling" (as far as node is considered). The recipe just unpacks the archive to the right directory :\ Jun 03 23:11:47 bsmerbeck: yeah thats ok but it seems the app is not compiled with yocto tools is that right ? Jun 03 23:11:54 Correct Jun 03 23:12:36 yeah the problem is it has encoded the rutime requirrements against the tools/os where you compiled it Jun 03 23:14:03 khem: any idea how I might workaround or resolve this? Jun 03 23:14:18 how do you compile your app ? Jun 03 23:14:28 is it compiled on centos or something ? Jun 03 23:15:22 Yeah, the host for bamboo (the CI) runs the `npm install` with a target architecture argument for the target machine (jetson nano). The same host also has bitbake which is where I run the build Jun 03 23:16:11 hmmm jetson nano is arm architecture isnt it Jun 03 23:16:38 errors you posted are for x86_64 ld.so and libc.so Jun 03 23:16:52 so it seems your build is not truly cross compiled Jun 03 23:17:30 your CI host is a intel/x86_64 box but your target is arm Jun 03 23:17:59 Ah, that makes sense. So I'll need to get that cross compile working to resolve it Jun 03 23:18:02 do building the npm app this way wont work unless you have a cross build environment for node app to compile for arm Jun 03 23:19:10 I think it could be possible, otherwise I could maybe just use another jetson nano in pipeline to handle the compilation. Hey thanks though! Two days of headache and finally moving forward Jun 03 23:20:20 good deal Jun 03 23:21:25 yocto also offers a way to cross compile node modules but it can be rabbit hole Jun 03 23:31:58 sakoman: have you looked at the backport series I sent around aarch64 Jun 03 23:48:39 halstead: seeing a cert issue on builders Jun 03 23:48:43 Cloning into 'googletest-src'... Jun 03 23:48:45 fatal: unable to access 'https://github.com/google/googletest.git/': error setting certificate verify locations: Jun 03 23:48:47 CAfile: /opt/poky/3.1/sysroots/x86_64-pokysdk-linux/etc/ssl/certs/ca-certificates.crt Jun 03 23:48:49 CApath: none Jun 03 23:49:02 see https://autobuilder.yoctoproject.org/typhoon/#/builders/88/builds/374/steps/8/logs/step1b Jun 03 23:49:35 khem, Thanks for the report. I'll install a different version of buildtools. Jun 03 23:49:37 seen it before as well on centos7 node, it does not happen always Jun 03 23:50:56 halstead: also seeing anogther cert issue here https://autobuilder.yoctoproject.org/typhoon/#/builders/88/builds/373/steps/8/logs/errors Jun 03 23:51:23 this is a debian8 host Jun 03 23:51:47 khem, That one has been difficult to track down. It seems buildtools related as well but I can't reproduce it on the worker. Jun 03 23:52:12 ok Jun 03 23:52:31 I have seen this few times with meta-oe job Jun 03 23:55:12 halstead: I also am trying to see another issue with toybox Jun 03 23:55:16 ERROR: toybox-inittab-0.8.2-r0 do_configure: Execution of '/home/pokybuild/yocto-worker/meta-oe/build/build/tmp/work/qemux86_64-poky-linux/toybox-inittab/0.8.2-r0/temp/run.do_configure.1229174' failed with exit code 2: Jun 03 23:55:17 /home/pokybuild/yocto-worker/meta-oe/build/build/tmp/work/qemux86_64-poky-linux/toybox-inittab/0.8.2-r0/temp/run.do_configure.1229174: 105: Bad substitution Jun 03 23:55:19 WARNING: exit code 2 from a shell command. Jun 03 23:55:29 this happened on ubuntu 2004 box Jun 03 23:55:43 I think its dash-vs-bash issue perhaps Jun 03 23:55:56 but I need to see this do_configure file Jun 03 23:56:09 is it possible for you to extract it for me Jun 03 23:56:50 khem, Sure. Or get you access to the worker. All the Ubuntu machines have /bin/sh -> dash though. Jun 03 23:57:09 yeah that will be ok Jun 03 23:57:59 yeah I only see this issue on debian/ubuntu nodes not on centos/fedora Jun 03 23:58:11 so I am thinking its perhaps some bashism somewhere Jun 03 23:58:58 khem, Adding your key now. Jun 03 23:59:56 khem, Was the toybox error on ubuntu2004-ty-2.yocto.io ? Jun 04 00:01:06 halstead: latest was on debian8-ty-1 Jun 04 00:18:49 khem, The load on debian8 is so high this will take a bit. **** ENDING LOGGING AT Thu Jun 04 03:06:17 2020