**** BEGIN LOGGING AT Thu Oct 01 02:59:57 2020 Oct 01 03:44:51 roussinm:https://github.com/golangbot/webassembly/tree/tutorial1/ Oct 01 03:45:48 RP: today's master next is consistently failing with this https://errors.yoctoproject.org/Errors/Build/110610/ for qemumips Oct 01 03:48:55 mccc: I also use github actions see https://github.com/YoeDistro/yoe-distro/actions Oct 01 04:12:37 RP: the latest master next fails with a different error https://hastebin.com/seqamanejo.cs Oct 01 04:15:54 * khem reverts all pseudo fixed in yoe/mut Oct 01 07:33:29 Thanks for the link khem. Oct 01 08:59:36 Hi everyone, I'm trying to extend the UBoot bootloader recipes with local patches: I have patchdir=${Foo} and ${Foo}="${WORKDIR}" and I get an recursion error. Oct 01 09:00:28 guest1023: why do you need to set patchdir? Oct 01 09:00:41 just omit it, it should apply to the sources directly Oct 01 09:00:48 provided you formatted your patches correctly Oct 01 09:01:56 The Uboot recipe changes the local directory, that's why I need to change it Oct 01 09:02:03 back Oct 01 09:02:05 guest1023: and to make your example work, it's probably patchdir=${FOO} FOO="${WORKDIR}" Oct 01 09:02:30 guest1023: changes the local directory? Oct 01 09:02:47 It modifes ${S} Oct 01 09:02:47 it's pretty unusual to patch stuff in WORKDIR Oct 01 09:02:58 guest1023: that's fine? what does it set it too? Oct 01 09:03:23 to ${WORKDIR} Oct 01 09:04:07 guest1023: wtf, what's in the SRC_URI? Oct 01 09:04:32 ${UBOOT_REPO} Oct 01 09:04:47 which is calculated from other values Oct 01 09:06:09 guest1023: does UBOOT_REPO start with file:// and is actually a tarball who has the sources directly in it and not in a directory? Oct 01 09:06:32 Yes Oct 01 09:06:44 guest1023: sigh Oct 01 09:07:07 anyway, the patches should apply to S IIRC? so if S is workdir you're fine? what's your issue? Oct 01 09:07:32 The recursion error: Oct 01 09:07:32 https://0bin.net/paste/HI82vIJK#sQwVHaS9-RJdyQthuK0K07A4IfwyxfPaV/NWdyn2bsM Oct 01 09:07:46 guest1023: no, why do you need patchdir in the first place? Oct 01 09:07:53 The directory structure differs Oct 01 09:09:23 It would be fine if S is workdir and I have the same directory but this is not the case Oct 01 09:10:36 guest1023: patchdir is set to S by default Oct 01 09:10:39 guest1023: patchdir should be relative Oct 01 09:10:40 you said S is WORKDIR Oct 01 09:11:07 so I'm not sure what you're trying to achieve Oct 01 09:11:25 paulbarker: mmm indeed, missed that but it still does not make sense to me :) Oct 01 09:12:50 paulbarker: mmm wait... it seems it can be absolute? http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/patch.bbclass#n132 Oct 01 09:15:04 Why does ${SRCPV} trigger a recursion error in patchdir? That was my question Oct 01 09:15:13 qschulz: guest1023: See https://git.openembedded.org/openembedded-core/tree/meta/recipes-devtools/go/go-dep_0.5.4.bb for an example of how patchdir is typically used Oct 01 09:15:50 guest1023: Do you set PV in your recipe? Oct 01 09:16:20 It sounds like it can't determine the path for WORKDIR as there's an infinite loop when trying to expand variables Oct 01 09:17:46 I still don't understand what is guest1023 trying to achieve as patchdir is using S by default. That S is WORKDIR in their case and they want to set patchdir to WORKDIR Oct 01 09:18:20 so fixing this recursion error is actually not going to bring anything to what they're trying to achieve? Oct 01 09:18:56 PV_append = "+git${SRCPV}" Oct 01 09:20:00 You can only apply a patch if you have the same directory structure, but I have multiple patches which are created from a different structure Oct 01 09:21:21 Say you have /a/c/test in one project and /a/c_b/test in another Oct 01 09:21:21 guest1023: format your patch correctly then? Otherwise, use relative path as paulbarker suggested. If it is in WORKDIR you want to apply the patch, don't specify patchdir. If it's a subdir of WORKDIR, just specify the path relative to WORKDIR without mentioning WORKDIR Oct 01 09:21:52 guest1023: I'm not sure if this is a bug but I guess SRCPV is not valid for use in SRC_URI Oct 01 09:22:25 paulbarker thanks paul Oct 01 09:23:09 guest1023: If you look at https://git.openembedded.org/openembedded-core/tree/meta/classes/base.bbclass#n647, it's modified during parsing Oct 01 09:24:04 It's intended to set the WORKDIR path before the actual git revision is known but then at a later stage when the git revision is known it can change Oct 01 09:24:19 If I remember correctly, it's been a few months since I looked at it in detail Oct 01 09:25:57 that's interesting, it explains the behavior of bitbake Oct 01 09:29:06 guest1023: Is there any reason you can't use relative paths in patchdir? Oct 01 09:29:43 You can step up the hierarchy using "..", that's known to work: https://git.openembedded.org/openembedded-core/tree/meta/recipes-devtools/tcltk/tcl_8.6.10.bb#n25 Oct 01 09:30:15 Oh, that's great, thank you paulbarker Oct 01 09:31:21 That should solve the issue Oct 01 09:41:17 dl9pf: I have this integreity check running, the problem now is that it races really badly :( Oct 01 10:29:02 Hi armpit. Do you know if there are plans to add sysvinit support for kea in oe-core? Or if there is a reference implementation in 3rd party layers? A quick google search didn't bring me anything. Oct 01 10:32:02 dsueiro: good question. can you file a bug, a dhcp server without init scripts is quite sad and arguably a release blocker Oct 01 10:32:49 rburton: Sure. I'll file a bug if there is a confirmation that init scripts were not planned. Oct 01 10:40:00 definintely a release blocker, thanks for raising dsueiro! Oct 01 10:42:15 RP: you are welcome. Oct 01 10:42:34 that armpit is such a liability Oct 01 10:53:31 Hey guys have you ever tried to use an sdk produced by yocto to set -fuse-ld=gold? Oct 01 11:12:45 It seems this commit cc21092c6d8563d5ec0ce3ba06a3735daa40fc1e kills gold usage :( Oct 01 11:20:16 I think there was some discussion about this on ML, but https://git.openembedded.org/openembedded-core/commit/cc21092c6d8563d5ec0ce3ba06a3735daa40fc1e doesn't look correct "oeqa/selftest/devtool: Add sync call to test teardown" Oct 01 11:24:55 hhehe does not look related at all. I am going to make some test but i think according to https://stackoverflow.com/questions/54558140/how-to-force-gcc-to-use-ld-gold-if-real-ld-executable-exists-in-compiler-search when there is a file called real-ld gcc ignores -fuse-ld= Oct 01 11:49:58 RP: applied locally and running some tests Oct 01 13:13:58 I have a bb variable that does appear in BB_HASHBASE_WHITELIST, but still gets included in do_fetch's sigdata - what could be wrong ? Oct 01 13:14:44 (that's an API token necessary for fetching from a private npm repo) Oct 01 13:15:42 (and I have used BB_HASHBASE_WHITELIST_append in the recipe making use of it) Oct 01 13:19:05 yann: Try `BB_HASHBASE_WHITELIST +=`. The deferred _append may be too late for signature calculations? Oct 01 13:20:05 yann: That seems strange, but it looks like everywhere else it's always using += Oct 01 13:24:07 JPEW: no luck, still there Oct 01 13:25:17 bitbake-dumpsigs also lists that var alongside SRC_URI with "List of dependencies for variable ... is set()" Oct 01 13:29:37 yann: Weird Oct 01 13:38:23 Would look like a bitbake bug/limitation ? Oct 01 13:38:50 could it be the modification of BB_HASHBASE_WHITELIST from within the recipe ? Oct 01 13:39:06 i'd like to run the glibc testsuite on my target. if i understand it correctly setting TOOLCHAIN_TEST_TARGET to ssh should to it. but how (or who?) get the tests installed on my board? Oct 01 13:40:02 yann: Possibly? I've modified BB_HASHBASE_WHITELIST in classes before, but maybe they were always classes that use INHERIT += Oct 01 13:40:12 yann: i.e. icecc.bbclass Oct 01 13:41:57 yann: you can't modify that variable in a recipe Oct 01 13:42:39 yann: try SRC_URI[vardepsexclude] += "VARNAME" (not sure if its vardepexclude or vardepsexclude) Oct 01 13:43:27 derRichard: I think the glibc test suite may expect some kind of nfs availability but I'm guessing from memory Oct 01 13:44:09 RP: ok thx - would seem useful to have a warning when touching BB_HASHBASE_WHITELIST in a recipe, then ? Oct 01 13:44:18 RP: hmmm. ok. is this documented somewhere? Oct 01 13:45:12 RP: hm, it's not included in SRC_URI, it's passed to do_fetch with "export THISVAR" Oct 01 13:45:29 derRichard: well, we do run the tests under qemu on the autobuilder. Oct 01 13:45:44 well, passed to npm via yarn via do_fetch, to be picky Oct 01 13:45:47 yann: oh, global exports are a huge pain Oct 01 13:46:29 RP: what also confuses me. there is no recipe to get the tests as package and installed in the image, right? Oct 01 13:46:38 derRichard: they're not ptests Oct 01 13:46:50 i mean the tests within glibc itself Oct 01 13:47:10 such as tst-malloc-fork-deadlock.c Oct 01 13:48:21 derRichard: I do know what glibc tests are Oct 01 13:49:04 RP: okay. i thought the talk about different things :) Oct 01 13:49:08 *we talk Oct 01 13:49:13 derRichard: They're run on the autobuilder with "oe-selftest -t toolchain-user" or "oe-selftest -t toolchain-system" Oct 01 13:49:43 derRichard: The toolchain tests are the testsuites in gcc, binutils, db and glibc. We have the option to run them in qemu user mode or qemu system emulation mode Oct 01 13:50:01 yeah. so there is no easy way to get them installed on my target. Oct 01 13:50:07 derRichard: I don't know how you'd run them for a real hardware target but I'd imagine it can be done with the right setup Oct 01 13:50:34 derRichard: They have their own special setup due to the way the test suites expect to work which involves nfs networking from what I remember Oct 01 13:50:34 it can, theoretically Oct 01 13:50:47 rburton: no, not really Oct 01 13:50:49 EXTRA_OEMAKE appends the oe_runmake command. Any way to assign a variable that is prepended to oe_runmake? Oct 01 13:50:50 i have lots of patches against malloc and want to run all malloc related glibc tests on the target Oct 01 13:51:12 derRichard: they simply don't work like the other tests Oct 01 13:51:37 lxc: why :) ? Oct 01 13:51:55 RP: well, i hoped you have a recipe to shipp all they need :-) Oct 01 13:52:12 RP: at least it seems to work when set at layer level Oct 01 13:52:46 derRichard: right, I'm trying to say its not that simple. They expect to build X on the host, transfer to the target, run, change it, run it, etc, all on the fly Oct 01 13:54:20 RP: maybe i can decipher the nfs setup from the autobuilder. shouldn't be that hard :) Oct 01 13:54:53 derRichard: its all in the oeqa stuff Oct 01 13:55:05 yep :) Oct 01 13:55:46 derRichard: It lets you set a TOOLCHAIN_TEST_HOST, HOST_USER, HOST_PORT and so on so there is hope Oct 01 13:56:12 derRichard: and it does indeed use an nfs mount Oct 01 13:56:35 see meta/lib/oeqa/selftest/cases/glibc.py Oct 01 13:56:57 derRichard: and if you get it working, could you please add some documentation since I've helped you this far? :) Oct 01 13:56:59 RP: yes. i set these variables and saw many ssh logins on the target. but bitbake glibc-testsuite -c check run for a few minutes and did not fail (wut?) Oct 01 13:58:10 derRichard: we're beyond my knowledge, I just know it works on the autobuilder. I didn't write it Oct 01 13:58:56 no need to worry :) Oct 01 14:00:07 qschulz well if you append them you override the variable Oct 01 14:00:51 qschulz make CFLAGS=-g may not be the same as CFLAGS=-g make Oct 01 14:03:01 if you want the former, just export the variable Oct 01 14:03:06 erm, latter Oct 01 14:03:16 EXTRA_OECMAKE is explicitly the former Oct 01 14:04:00 man I can't type today Oct 01 14:04:05 * EXTRA_OEMAKE * Oct 01 14:05:33 rburton yes export works, but even better to prepend the make command. thus my ask if there is such a variable Oct 01 14:05:51 semantically they are identical though Oct 01 14:06:07 'prepending the make command' is exporting a variable for make Oct 01 14:09:42 rburton the export is stronger than the prepend, export is for all in that shell Oct 01 14:17:34 "FOO=bar oe_runmake" will do what you want Oct 01 14:22:09 RP, JPEW : damned, I did not realize at firstn but adding this BB_HASHBASE_WHITELIST += "..." to layer.conf suddenly causes all recipes to get flagged "metadata is not deterministic" - any idea ? Oct 01 14:22:47 yann: are you wiping out the default value? Oct 01 14:22:58 lxc: just override the function to add a variable in front of oe_runmake Oct 01 14:24:03 qschulz not sure what you mean. CFLAGS= oe_runmake? Oct 01 14:24:31 lxc: ${EXTRA_OEMAKE_BEFORE} oe_runmake Oct 01 14:24:42 and set EXTRA_OEMAKE_BEFORE to whatever you want Oct 01 14:25:31 RP: ah it could be that "BB_HASHBASE_WHITELIST +=" does that, BB_HASHBASE_WHITELIST_append +=" seems more selective... but that does look confusing Oct 01 14:25:32 basically what rburton said with an additional variable just to make it obvious outside of tasks Oct 01 14:25:50 qschulz yes that would do it, but wouldn't it be prettier if bitbake make engine could do that instead, like it does with EXTRA_OEMAKE? Oct 01 14:26:05 lxc: there's no need for that is my understanding Oct 01 14:26:19 you can export variable and use "-e" flag or pass variables with OE_CMAKE Oct 01 14:26:24 EXTRA_OEMAKE sorry Oct 01 14:26:50 feel free to send a patch to add your third option if there's really a usecase for it? Oct 01 14:30:34 Is there a password on the bug triage call? Oct 01 14:30:49 huh Oct 01 14:30:54 apparently so Oct 01 14:30:59 https://zoom.us/j/454367603?pwd=ZGxoa2ZXL3FkM3Y0bFd5aVpHVVZ6dz09 Oct 01 14:31:45 sgw: Thanks Oct 01 15:04:19 RP: https://paste.debian.net/1165464/ Oct 01 15:12:22 JPEW: https://www.seeedstudio.com/Rock-Pi-X-Model-B-4GB-p-4277.html Oct 01 15:18:02 RP: pseudo/ folder empty after invocation Oct 01 15:24:47 tlwoerner: Awesome Oct 01 15:25:40 Is there a standard target in yocto for a full disk image inc partition table I can use directly with virtio? Oct 01 15:26:36 (Im using qemuarm) Oct 01 15:27:37 pev: This does that I think: https://git.yoctoproject.org/cgit/cgit.cgi/meta-arm/tree/meta-arm/conf/machine/qemuarm64-secureboot.conf Oct 01 15:28:52 tlwoerner: you added libmodule-build-perl to coreutils-ptest RDEPENDS. However, if I remove it the pass/fail/skip rate doesn't change. Do you remember what tests needed it? Oct 01 15:29:36 pev: It also enables secure boot, but you can fix it up to boot directly to u-boot instead Oct 01 15:31:31 JPEW: Ah, that looks like a great shove in the right direction, thanks! Yeah, I'm trying to set up QEmu to behave 'normally' doing a u-boot -> kernel boot from disk/flash.... Oct 01 15:31:52 but shouldn't be at least the pseudo.pid be in the dir even if the db is not flushed ? Oct 01 15:32:04 pev: Ya. The key point is to use wic to build a complete disk image Oct 01 15:32:45 pev: Then, tell qemu to boot u-boot instead of the kernel with the QB_DEFAULT_BIOS option Oct 01 15:34:18 JPEW: Ah, I've actually incorporated u-boot into pflash0 so it boots by default and fixed pflash1 so I can save the environment... Just want to be pretty close to a real-world hardware target Oct 01 15:34:42 Im a bit old fashioned, I hadn't used wic before so a bit of learning curve! Oct 01 15:34:44 rburton: if memory serves i had an image where i had added packagegroup-core-lsb-perl which stopped building, that's what i did to get it building again Oct 01 15:35:00 hm Oct 01 15:35:04 rburton: but i think packagegroup-core-lsb-perl is gone now Oct 01 15:35:14 pev: wic is really nice. It's not terrible hard to use. Oct 01 15:35:30 tlwoerner: well i'm ripping it out again because building a target gcc when i build coreutils is making me sad (and killing the planet ;) Oct 01 15:35:33 JPEW: boom, looks like that put me on the right path and it detects and boots! Oct 01 15:36:31 JPEW: Yeah, i suspect I need to get my head round it - you know what it's like though, always pressure to make progress on projects rather than having the time to get up to speed on new toolls! Oct 01 15:36:35 rburton: oh noes!! don't kill the planet! Oct 01 15:37:44 tlwoerner: I've been wanting an x86 rpi form factor board! Oct 01 15:38:33 JPEW: yes i know, you mentioned it before and back then the only one was the UP board which had been discontinued, so when i saw this i passed it on Oct 01 15:38:45 JPEW: and the name has an "X" in it, so you know it's really kewl!! Oct 01 15:39:20 tlwoerner: Right :) Hopefully it can boot from the SD card so I can do my automated testing with it Oct 01 15:41:45 fray: was it you that did the gitsm work recently? Oct 01 15:50:47 tlwoerner: Hmm, radxa has been busy: https://github.com/radxa/meta-radxa Oct 01 15:54:33 JPEW: i ordered the rockpi-3-rk3328 yesterday and was just looking at that :-) Oct 01 15:55:14 JPEW: it looks like there's upstream support in U-Boot, but there doesn't appear to be a dts file in linux-stable (yet) Oct 01 16:01:15 Ya. wic files would be nice too Oct 01 16:14:57 need to pass bitbake datastore variable "d" to a py function but caller function doesn't have one, how it can be access "d" in python function... got an implementation using setup_tinfoil() IDK if it's the right approach Oct 01 16:16:35 function I need to call -> def exec_fakeroot(d, cmd, **kwargs): Oct 01 16:20:32 xtron: d is available in python tasks in recipes (if that was your question?) Oct 01 16:22:49 qschulz, I need to call it from a custom wic plugin *.py Oct 01 17:29:52 whoa, cherry-trail? blast from the past @JPEW Oct 01 17:30:19 moto-timo: I wouldn't know. My x86 knowledge is weak Oct 01 17:30:39 JPEW: that processor came out before I joined Intel Oct 01 17:31:08 moto-timo: Oh, do I need to bust out my punch-card deck then? ;) Oct 01 17:31:24 JPEW: lol Oct 01 17:31:36 JPEW: it should be _really_ stable Oct 01 17:32:43 moto-timo: Hopefully that means all the upstream projects just work... I'm tired of vendor graphics drivers Oct 01 17:33:21 oh... the newer board is rockchip I was refering to the seeedstudio link from tlwoerner Oct 01 17:34:48 moto-timo: Ya, the Rock Pi X B4E32? I believe that is a new board Oct 01 17:35:48 moto-timo: we missed you yesterday! :'( Oct 01 17:35:52 so many chips so little time Oct 01 17:36:09 oh darn! I forgot to put it on my calendar. Oct 01 17:36:11 damn Oct 01 17:36:26 sigh Oct 01 17:36:29 i looked for you on IRC, but you weren't logged in :-( Oct 01 17:36:38 oh well Oct 01 17:37:07 * tlwoerner didn't take notes, but there sure was a lot of "…oh wait, this isn't recorded, is it??" Oct 01 17:37:17 hahahahahahahaha Oct 01 17:37:38 I'm positive many things I have said should never have been recorded. Oct 01 17:38:04 lol Oct 01 17:39:18 I think I was staring at either the toaster-container or runqemu oe-selftests and just unaware of the world Oct 01 17:41:00 i was repairing fences at the time, and it started to rain, i came in and said "oh yea! OEHH" Oct 01 17:41:12 moto-timo: blast from the past would be emenlow or fri2 :) Oct 01 17:41:48 * RP apologises in advance for the flashbacks Oct 01 17:42:32 RP: you wouldn't believe the boards I found in the "Yocto" rack in the lab. Oct 01 17:42:49 moto-timo: oh, I would :) Oct 01 17:43:20 * RP did manage to kill the emenlow Oct 01 17:45:26 the videos from ELC2020 are now up: https://www.youtube.com/playlist?list=PLbzoR-pLrL6oyIqGsEZdb1E4pWzWn9qOZ Oct 01 17:51:58 rewitt: can you add pip3 to the crops image? Oct 01 17:56:15 rewitt: (use-case: i want to use kas inside my crops image to do CI) Oct 01 17:56:38 rewitt: prior art: meta-security downloads pip itself https://gitlab.com/akuster/meta-security/-/blob/master-next/.gitlab-ci.yml Oct 01 18:00:19 rburton: kas uses crops ? Oct 01 18:00:33 kas doesn't care Oct 01 18:00:36 some one said rain ? send some here please Oct 01 18:00:50 writing CI, want to use crops + kas Oct 01 18:01:01 but having to install pip3 by hand is boring Oct 01 18:01:16 rburton: yeah I have been happy with docker building OE Oct 01 18:16:25 rburton: I'll look into it. Can you ask on github so I don't forget? Oct 01 18:16:36 rburton: Or you can just email me Oct 01 18:24:07 rewitt: RP: toaster-container failure with cooker log https://travis-ci.org/github/moto-timo/toaster-container/jobs/732022993 Oct 01 18:31:26 rewitt: https://github.com/crops/poky-container/issues/54 thanks Oct 01 18:33:47 rburton: paul barker installs kas on crops go look at the YP DevDay slides and his repo Oct 01 19:00:33 our crops are on fire Oct 01 19:06:02 moto-timo: I don't see the cooker log, is it in there? Oct 01 19:06:39 moto-timo: Ignore me, if only there was a search function in the browser... Oct 01 19:42:14 khem: i thought that was part of California's charm? it's always sunny in California? ;-) Oct 01 20:03:31 moto-timo: that is very useful I think it can be fixed from that Oct 01 20:06:24 rewitt: RP: I was going to pastebin the only part you care about but I got distracted Oct 01 20:06:39 in other news I don't have 2ft high front lawn Oct 01 20:07:31 moto-timo: for 2020 I worry that is the result of land slip! :) Oct 01 20:07:56 RP: I would believe absolutely anything you told me happened in #2020 at this rate Oct 01 20:07:59 moto-timo: yeah, armin does too. just sad that it has to be via installing pip from a wget first Oct 01 20:08:40 rburton: yeah. I also have an internal derivative container that installs repo and git-lfs Oct 01 20:09:12 you should ask randy for those in crops too :) Oct 01 20:09:15 I continue to agree we should keep the containers slim and rewitt is an even louder voice :) Oct 01 20:09:27 rburton: there are PRs for both Oct 01 20:10:02 it's a matter of everybody wants a different tool and at some point ... it's bloated. Oct 01 20:10:34 sure, there's definitely a balance to be made Oct 01 20:10:38 rburton: I currently use the kasproject kas container from docker hub, but... that was just lazy Oct 01 20:11:00 * moto-timo completely waffling about features vs sparseness Oct 01 20:11:01 ah forgot that existed Oct 01 20:11:28 like every other thought in my 50-50 left-right brain Oct 01 20:14:15 moto-timo: rburton: I'm trying to limit the items in the container to the set of items required to build items in oe-core. It's probably less than that right now. But considering the "best practice" is to build the container yourself for reproducibility, security, etc, I think leaning to a smaller set makes sense. Especially considering the things are massive already. Oct 01 20:14:33 hmmm. what if I want to test for either of two things with @skipIfNotDataVar Oct 01 20:15:22 rewitt: my approach is going to be document how to create reasonable derivative containers Oct 01 20:16:10 rewitt: we are actively doing that now (along with some pluggable python scripts to install Intel's BSP offerings...) Oct 01 20:16:28 but you knew that already (just thought I'd voice it publicly) Oct 01 20:16:56 Yeah, I think it makes sense to document crops/yocto and the base image https://github.com/crops/poky-container/issues/53 Oct 01 20:17:04 now if only the open sourcing internal process was not so wonky Oct 01 20:17:09 yes Oct 01 20:17:11 moto-timo: fix pushed to bitbake master for that traceback Oct 01 20:17:19 RP: thank you! Oct 01 20:17:40 * rewitt leaves to go to WA will check back this evening Oct 01 20:17:51 moto-timo: let me know if there are any others Oct 01 20:18:38 RP: running the travis job again now Oct 01 20:18:52 RP: I kind of see this as low hanging fruit I would like to be DONE with :) Oct 01 20:55:22 when I try to define tinfoil_init() routin inside the wic plugin, bitbake trys to re-connect to the server recursively, what other way I've to access datastore "d" in wic script Oct 01 20:56:37 xtron: Rename the file wic.in so that it does variable expansion? Oct 01 20:56:59 xtron: wks.in sorry Oct 01 20:57:49 JPEW, may be I explain it wrong,but wic plugin is written in python Oct 01 20:57:58 xtron: Ah, sorry Oct 01 21:23:03 dl9pf: I tried master-next on the autobuilder and it seems some workers are suffering inode mismatching in /tmp/ Oct 01 21:23:19 this is problematic in a large number of ways :( Oct 01 21:38:40 RP: I am working on something with the qemu monitor and sending command via netcat. I have the concept at least, next is to work on maybe extending the utils/dumper code. Oct 01 21:49:43 sgw: sounds like good progress, thanks! Oct 01 21:53:34 RP: since it's host command, I might even beable to use the HostDumper with a different command list. Trick will get setting and getting the port# since I assume we can't use a fixed port as there may be multiple qemu processes running Oct 01 21:53:52 Is there already something that can get us a random unused port? Oct 01 21:54:13 sgw: right, I think qemu may be able to do that itself? Oct 01 21:54:53 I will check, I think your right, then it's parsing out the port number. Still digging around. Oct 01 21:56:13 sgw: we do this for the serial ports somehow I think Oct 01 22:30:15 looks like the pseudo patches don't work on debian10 and ubuntu2004 Oct 01 22:30:43 something is doing roughly mkstemp(), fd = fopen, fd2 = dup2(fd), unlink(fd), fchown(fd2) which leads to db "corruption" and aborts Oct 01 22:33:15 dl9pf: not sure which host OS you're using? (see above) Oct 01 22:33:37 and when I say "something", its opkg-build, probably through the shell in do_package_write_ipk Oct 01 22:39:40 armpit: given confirmation that the perl CVE fix did indeed introduce the regression, what would you like to see happen? We can easily revert that commit and do an rc2 Oct 01 22:42:34 RP: on the current builder ? openSUSE 15.02 Oct 01 22:42:37 RP: on the current builder ? openSUSE 15.2 Oct 01 22:43:18 I'm testing with package set to rpm fwiw Oct 01 22:45:23 armpit: Lee Chee Yang stated in the patch text that he made modifications to the test cases in the .patch file, so I suspect that those changes weren't correct Oct 01 22:47:00 so we can either revert and ask him to resubmit post 3.1.3, or just make a note that this particular test case is broken until we get a fix patch. Do you have a preference? Oct 01 22:58:56 sakoman, that is good data. I suspect that will help in the TSC decision making process for their approval. Please respond to the YP TSC Oct 01 23:00:40 armpit: OK will do. I did reply to your original objection email with confirmation that the patch did indeed cause the regression. I'll send another reply calling out Lee Chee Yang's commit comment on the test cases Oct 02 00:58:09 RP: please stage https://patchwork.openembedded.org/patch/176899/ for master as well. latest systemd upgraded regressed this **** ENDING LOGGING AT Fri Oct 02 02:59:57 2020