**** BEGIN LOGGING AT Sun Mar 22 02:59:58 2020 Mar 22 07:58:00 RP: i am trying to build -cpppulate_sdk_ext qwith kernel using initiramfs from linux-yocto and and I see these warnings/errors http://sprunge.us/MvMPW8 Mar 22 07:58:02 any ideas Mar 22 09:05:26 khem: probably some date/time issue making it into the hashes? I'd get bitbake-diffsigs out Mar 22 09:14:59 RP: how is the release process going? anything where I could help? Mar 22 09:55:14 hello Mar 22 09:55:47 I am a newbie in yocto and bash script, I want to understand some line like this Mar 22 09:55:50 PN = "${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE', False),d)[0] or 'defaultpkgname'}" Mar 22 10:30:46 kanavin_home: M3 is looking good but we're seeing intermittent ptest failures after your change to error upon failure :( Mar 22 10:31:02 kanavin_home: I've filed bugs for them but this worried me a lot in the context of LTS Mar 22 10:31:28 kanavin_home: that is the main reason recent builds are fails Mar 22 10:33:53 Are sym links created by EXTERNALSRC_SYMLINKS actually needed for external source builds or can I set it to nothing? Mar 22 10:49:47 RP: but overall ptest is passing, right? Mar 22 10:50:10 kanavin_home: the builds failed Mar 22 10:51:00 kanavin_home: any ERROR: message will cause the build to be a fail. What we might want is a WARNING Mar 22 10:51:16 but we do have warning free builds now :/ Mar 22 10:51:38 RP: right, those are ptest-fast Mar 22 10:51:41 kanavin_home: it would be helpful to dive into the builds logged into bugzilla and find the ptest logs, see what happened Mar 22 10:51:53 RP: I added a ignore-fail only for slow ptests, thinking that fast ones are robust Mar 22 10:52:09 RP: if they're not, then the same has to be set for ptest-fast as well Mar 22 10:52:28 kanavin_home: ok, looks like they're not robust, sadly Mar 22 10:52:33 RP: should be quick to patch that Mar 22 10:52:52 kanavin_home: we should probably still try and get the logs into those bugs so we can look into the issues Mar 22 10:54:20 RP: of course, that'd be a much needed enhancement, Mar 22 10:54:51 intermittent ptest failures can be maddeningly difficult to reproduce locally Mar 22 10:55:47 kanavin_home: its why I'm keen to try and find/save the logs which should be there for this Mar 22 10:55:55 RP: I'll make a bug for that and assign for myself, but the quickest way out is to declare fast ptests not robust for now Mar 22 10:56:14 kanavin_home: to be clear, we should have the logs in this case, we just need to find and extract the useful but Mar 22 10:56:15 bit Mar 22 10:56:37 I think I've filed about three of these so far Mar 22 10:56:43 RP: right. The difficult bit is that what gets printed may or may note be helpful (depending on ptest), and sometimes you need at the log on disk too Mar 22 10:57:15 kanavin_home: right, it may or may not be useful but it'd be a step forward Mar 22 10:57:32 kanavin_home: the output from ptest runner is at least something Mar 22 10:58:40 RP: yes - if the overall ptest exits with a non-zero we do print the entire output, so maybe we should adjust ptest.py to do the same when just specific ptests fail Mar 22 10:59:01 (it's an enhancement I did, because some ptests were invisibly failing in that manner!) Mar 22 10:59:36 kanavin_home: We shouldn't need to print the output since it is logged into the json results Mar 22 11:00:04 I've wanted to improve the tooling to allow easier extraction of that but we're not there yet Mar 22 11:00:10 RP: right, but then if that is logged, it could be somehow preserved? I don't know much about that area Mar 22 11:00:26 I'll send a patch for ptest-fast not giving a hard failure though, if you're ok with it? Mar 22 11:02:48 kanavin_home: yes, I am, thanks Mar 22 11:03:24 kanavin_home: What I mean is that https://autobuilder.yoctoproject.org/typhoon/#/builders/93/builds/459 failed, if you look at the build properties you can be lead to https://autobuilder.yocto.io/pub/non-release/20200321-1/testresults/qemuarm64-ptest-fast/testresults.json Mar 22 11:03:42 kanavin_home: that json file has the log for the failure in. Mar 22 11:06:09 I've updated the bug Mar 22 11:13:53 RP: right yes, that does give a much better starting point! Mar 22 11:16:54 kanavin_home: there is an open bug to add a link on the autobuilder to point at the testresults directory Mar 22 11:17:17 kanavin_home: and we do have tools that can pull the logs from the json files, in this case I admit I did it manually Mar 22 11:18:35 RP: yeah, I am trying to extract the important bit, but both my browser and the local app choke on the full raw log part Mar 22 11:19:01 kanavin_home: resulttool has some option to extract it Mar 22 11:28:31 RP: yes, I've figured it out - don't go to ptestresult.rawlogs, but rather to ptestresult.sections Mar 22 11:35:49 RP: just been wondering, this has been stuck in master-next for weeks, despite being totally uncontroversial: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=master-next&id=9c085f65ab92ea6dbde94145b03ad340e277579d Mar 22 11:36:38 Hi Everyone, I'm building my Yocto image inside a docker container, and on some packages (ex. gcc) on the do_package step fails, i receive this ERROR: Exception: KeyError: 'getpwuid(): uid not found: 1001' (full log here https://pastebin.com/jF7Vf11T) thank for the help! Mar 22 11:38:17 I'm running bitbake as suggested as non-root, with a user with UID 1001 Mar 22 11:46:53 kanavin_home: FWIW the autobuilder is supposed to extract these in the http share but for some reason isn't Mar 22 11:47:13 kanavin_home: The patch needs various fixes, I have a number of emails I need to sort out in relation to that docs patch :( Mar 22 11:53:32 RP: right - I'm going for a bike ride now, as it's sunny and might be last chance to do so 'legally' for a while Mar 22 11:54:10 RP: I've been working from home, and my nice workstation in the office still not on the right network, so ability to do things that require 'real yocto builds' is limited a bit Mar 22 11:54:35 kanavin_home: no problem, stay safe! Mar 22 11:54:58 thanks, I'd say that solo road cycling should be very low risk, shouldn't it? Mar 22 11:55:26 kanavin_home: unless you fall off, that would be the biggest risk there Mar 22 11:55:57 yep, the bulk of the planned route is on dedicated cycle paths :) Mar 22 11:56:06 kanavin_home: That helps a lot! Mar 22 11:56:56 kanavin_home: I suspect I'd still use the mtb but I would be careful about route choice. I'm staying at home today though, too many people everywhere outside by the looks of it :( Mar 22 11:58:17 RP: I think I should be able to handle the lockdown okay, I'm an introvert who relaxes through books and music Mar 22 11:58:41 RP: Kari will be hit much harder probably, he thrives on human interaction and can never have enough of it Mar 22 11:59:08 kanavin_home: Its going to be very tough on social people :/ Mar 22 12:00:01 kanavin_home: I live alone so it could get interesting... Mar 22 14:31:29 A Yocto talk at foss-north foss-gbg online konferans #1 nu: https://www.youtube.com/watch?v=wKqdVTi4CuI Mar 22 14:42:12 New news from stackoverflow: I am new in yocto build and integration. Please suggest me idea why I am getting error "ERROR: oe_runmake failed"? Mar 22 14:52:37 RP: how do we do that inside esdk Mar 22 15:05:38 khem: diffsigs? grab the sig files as normal Mar 22 15:20:18 RP: I only see setscene files in stamps/ dir Mar 22 15:26:06 RP: should recipes using externalsrc or sourcecode inside workspace work in eSDK, I see they dont Mar 22 15:26:34 khem: I don't remember :( Mar 22 15:27:15 khem: eSDK was developed so far, then everyone was pulled off it. It works to a point but there were many things we never got to do with it that really needed to be done Mar 22 15:27:30 Most of the knowledge "paged to disk" amt :( Mar 22 15:27:51 * RP is staring at tinfoil data connector code and really needs input from Paul as I don't understand why the code is as it is Mar 22 17:12:41 New news from stackoverflow: Yocto build and integration, getting error "ERROR: oe_runmake failed" || Patch bitbake to use custom `wpa_supplicant.conf` Mar 23 01:44:11 New news from stackoverflow: No rule to make target, needed by '__build'. Stop **** ENDING LOGGING AT Mon Mar 23 02:59:58 2020