**** BEGIN LOGGING AT Thu Feb 04 03:02:58 2021 Feb 04 05:59:56 I'm running cmake to build shared libraries, but cmake gives me following error. Please suggest me. Feb 04 06:00:05 | checking whether make supports the include directive... yes (GNU style) Feb 04 06:00:07 | checking for gcc... /home/bl-docker/rity/bsp/tmp/work/aarch64-poky-linux/kvscpp/1.0-r0/recipe-sysroot-native/usr/bin/aarch64-poky-linux/aarch64-poky-linux-gcc Feb 04 06:00:07 | checking whether the C compiler works... no Feb 04 06:00:07 | configure: error: in `/home/bl-docker/rity/bsp/tmp/work/aarch64-poky-linux/kvscpp/1.0-r0/git/open-source/liblog4cplus/build/src/project_log4cplus': Feb 04 06:00:07 | configure: error: C compiler cannot create executables Feb 04 07:47:12 good morning Feb 04 07:47:23 Sad news from Linux Foundation Feb 04 07:47:29 LF said they've made the difficult decision to cancel plans for events to take place in August even if Virtual. Feb 04 07:48:04 Only ELCE in Dublin is still confirmed (very likely Virtual) Feb 04 07:49:43 khem: not sure I understand the glibc build result :/ Feb 04 07:52:00 link ? Feb 04 07:54:22 khem: https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/1821 Feb 04 07:54:39 khem: looks like core-image-sato-sdk fails to boot in many cases Feb 04 08:00:53 looks like kernel crashes Feb 04 08:03:12 khem: maybe, not sure Feb 04 08:09:34 I think its mainly qemux86/qemuarm/qemumips which is showing boot failures let me try to reproduce the qemux86 one first since that seems to be completely bad Feb 04 08:15:14 RP: I also see stdio: ERROR: No new tasks can be executed since the disk space monitor action is "STOPTASKS"! Feb 04 08:15:14 on https://autobuilder.yoctoproject.org/typhoon/#/builders/82/builds/1493 Feb 04 08:15:21 I wonder if its out of disk space ? Feb 04 08:20:03 yo dudX Feb 04 08:48:52 khem: the arm one was, I've fixed that Feb 04 08:49:00 khem: doesn't explain all the others Feb 04 09:00:23 morning :) Feb 04 09:08:13 i have a question/build error. currently i am running a docker container (L2) inside a debian kvm (L1) on a host (L0). The build is crashing on "rootfs/dev: umount failed: No such file or directory" "FileNotFoundError: [Errno 2] No such file or directory: '/proc/mounts'". How do i solve this? Feb 04 09:23:22 jack_guo: it seems strange something is trying to run umount? that isn't part of a normal build as far as I know. Do you have a bit more context for the error? Feb 04 09:23:35 jack_guo: i guess the first step would be to find out what actually crashes? because a generic bitbake certainly doesn't try an unmount something Feb 04 09:23:47 RP: meh, slow typing me. Feb 04 09:25:06 | umount: /home/gitlab-runner/isar-vied/build/tmp/work/debian-buster-amd64/isar-bootstrap-target/1.0-r0/rootfs/dev: umount failed: No such file or directory. Feb 04 09:25:07 | WARNING: exit code 32 from a shell command. Feb 04 09:25:08 | Feb 04 09:25:08 ERROR: Task (mc:qemuamd64-buster:/home/gitlab-runner/isar-vied/meta/recipes-core/isar-bootstrap/isar-bootstrap-target.bb:do_bootstrap) failed with exit code '1' Feb 04 09:25:08 NOTE: Tasks Summary: Attempted 35 tasks of which 0 didn't need to be rerun and 1 failed. Feb 04 09:25:09 ERROR: Execution of event handler 'build_completed' failed Feb 04 09:25:09 Traceback (most recent call last): Feb 04 09:25:10   File "/home/gitlab-runner/isar-vied/meta/classes/isar-events.bbclass", line 52, in build_completed(e=): Feb 04 09:25:10     > with open('/proc/mounts') as f: Feb 04 09:25:11              for line in f.readlines(): Feb 04 09:25:11 FileNotFoundError: [Errno 2] No such file or directory: '/proc/mounts' Feb 04 09:26:30 jack_guo: isar is a somewhat external thing to us, and you are trying to assemble a debian image, right? Feb 04 09:26:35 jack_guo: ah. You'd need to ask the isar people about their class, I have no idea what that does Feb 04 09:26:47 yes, i am trying to assemble a debian image Feb 04 09:27:13 ok, i'll try the isar people then Feb 04 09:27:22 jack_guo: well then you should certainly try and get in touch with the isar folks. Feb 04 09:29:03 jack_guo: if you can mount a valid /proc within the container it would probably help, or even a dummy file there Feb 04 09:29:11 jack_guo: I don't know what it uses it for though Feb 04 09:40:32 i think i found the issue. some sort of bug with debootstrap https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968927 Feb 04 10:05:08 Hi, I want to use devtool to add an NPM module using the Repository Method. The module is provided by a custom NPM repo with restricted access. I use a .npmrc with the necessary credentials to access the repo with the npm command line tool. However, using devtool add the npm tool doesn't seem to find/see the .npmrc file in my home directory or in the build directory. Does anyone know in which Feb 04 10:05:09 directory .npmrc must be located? Feb 04 10:10:26 polaris: Maybe this will be useful to you: https://wiki.yoctoproject.org/wiki/TipsAndTricks/NPM Feb 04 10:20:27 Hi, Feb 04 10:20:28 I'm running cmake to build shared libraries, but cmake gives me following error. Feb 04 10:20:28 | checking whether make supports the include directive... yes (GNU style) Feb 04 10:20:29 | checking for gcc... /home/bl-docker/rity/bsp/tmp/work/aarch64-poky-linux/kvscpp/1.0-r0/recipe-sysroot-native/usr/bin/aarch64-poky-linux/aarch64-poky-linux-gcc Feb 04 10:20:29 | checking whether the C compiler works... no Feb 04 10:20:29 | configure: error: in `/home/bl-docker/rity/bsp/tmp/work/aarch64-poky-linux/kvscpp/1.0-r0/git/open-source/liblog4cplus/build/src/project_log4cplus': Feb 04 10:20:30 | configure: error: C compiler cannot create executables Feb 04 10:25:12 vijay: check the compile scripts and logs to see that bitbake's toolchain file and it's variables are used correctly Feb 04 10:25:57 remember to use cmake.bbclass in the recipe, e.g. "inherit cmake" Feb 04 10:27:34 mcfrisk I'm using inherit cmake in my recipe. Feb 04 10:28:07 if we're talking about this https://github.com/awslabs/amazon-kinesis-video-streams-producer-sdk-cpp/blob/master/CMakeLists.txt the i expect massive work to be needed to make it work Feb 04 10:29:19 Yes, trying into integrate the same Feb 04 10:29:30 because this is actually like an inner build that is hidden away for its OS dependencies, which is mostly guaranteed to break in a crosscompilation environment. not even talking about licensing problems. Feb 04 10:30:06 LetoThe2nd How to avoid those? Feb 04 10:30:24 my advice would be to first package up the dependencies and then make that kvscpp thing use them, probably by patching. Feb 04 10:30:33 but this is certainly not trivial- Feb 04 10:31:54 hum they at least claim to be cross compile aware which is more than one usually can expect: https://github.com/awslabs/amazon-kinesis-video-streams-producer-sdk-cpp#cross-compilation Feb 04 10:33:41 I want to install gstreamer plugin kvssink Feb 04 10:34:52 LetoThe2nd Thanks for the advice. Feb 04 10:35:14 vijay: have fun. Feb 04 13:06:41 Hi, does anyone know how to make devtool/Bitbake add aware of a custom .npmrc? Or to ask differently, how can I provide a custom .npmrc to devtool/Bitbake? Is that possible at all? Feb 04 13:12:55 polaris-: anything is possible, its just software. but i guess you'll actually have to look at the npm fetcher code here Feb 04 13:13:00 yann: ^^^^^^ Feb 04 13:19:52 polaris-: AFAIK .npmrc in your source should just be used already ? except if explicitly disabled, and then as LetoThe2nd said, the code is the law Feb 04 13:21:13 yann: https://youtu.be/L397TWLwrUU Feb 04 13:21:22 oh and of course rburton!!!! Feb 04 13:23:07 LetoThe2nd: often it's rather https://youtu.be/AL8chWFuM-s :) Feb 04 13:23:47 yann: well, I have a .npmrc in my home folder. It contains credentials to access a private npm repo. I want to use devtool add to create a recipe for a module available in the private repo. I works with npm install in my shell. But devtool add seems to ignore the .npmrc in my home folder. Feb 04 13:23:57 yann: hi5 Feb 04 13:24:36 it's normal that it would ignore your home folder, there would be a reproducibility issue Feb 04 13:25:58 yann: yes .. that's a good point. I didn't find another way to provide the credentials for the repo though. Feb 04 13:26:18 polaris-: not perfect, but you can add something like "_authToken=${MY_NPM_REGISTRY_TOKEN}" in a .npmrc in your project, and set that var in your environment Feb 04 13:27:18 fwiw, using .netrc from users home is normal for all bitbake fetchers like git Feb 04 13:27:48 yann: that sounds interesting, what do you mean by project? Feb 04 13:27:50 we are rather using yarn than directly npm, and use a different mechanism now, but I'm not sure it would apply to npm Feb 04 13:28:33 and similarly svn fetcher uses ~/.subversion for authentication etc config Feb 04 13:29:26 polaris-: hm let me think twice, that probably won't work to have this in your source - just ignore what I said :) Feb 04 13:29:27 mcfrisk: good point Feb 04 13:34:54 I also tried to use fetch the project from the Git repo but that's also failing for me. My URI is "git://git@ssh.dev.azure.com:v3/foo/bar/baz;branch=master;protocol=ssh;tag=v0.0.4" and the error I get is "ssh: Could not resolve hostname ssh.dev.azure.com:v3: Name or service not known" Feb 04 13:35:06 I guess that's a parsing problem. Feb 04 13:46:43 mcfrisk: we do try and minimise such accesses though... Feb 04 14:28:49 TBH having ELC-NA and ELC-E 2 months apart and virtual didn't really make sense, so I'm not too suprised it was canceled Feb 04 14:30:55 * LetoThe2nd places his bet on ELCE going virtual and into the NA timezone too. Feb 04 14:39:05 LetoThe2nd: I would guess that also Feb 04 14:53:08 i'm using crops/poky and i keep on getting myself into situations (like, if i'm working on a new recipe that doesn't build right the first time, or if i change a recipe) where my build fails because the recipe couldn't clean out the old source files from the previous build due to a permissions error Feb 04 14:54:11 what am i doing wrong? the files seem to be owned by the (unprivileged, no sudo access) user that i'm doing the build as, i'm not sure why they can't be removed or how i'm creating files that i can't then subsequently remove without sudo Feb 04 14:55:22 i've dug around and saw that sometimes this is caused by copying files instead of using `install` in your `do_install` but this stuff is blowing up at `do_compile` Feb 04 15:05:13 jordemort: Are you doing everything in the container, or are you trying to mix commands inside and outside the container? Feb 04 15:05:36 everything inside the container Feb 04 15:06:03 the build and sstate are on volumes, they're not even accessible outside the container Feb 04 15:09:14 jordemort: Not sure then.... I don't use crops for desktop builds, sorry Feb 04 15:24:27 RP: looks like diskspace on autobuilder is low. See https://autobuilder.yoctoproject.org/typhoon/#builders/93/builds/806 Feb 04 15:24:51 jonmason: this is the problem we have with the arm worker, I did pause it and do some manual cleanup so we should be ok again Feb 04 15:25:11 tell awafaa to get you a bigger disk ;-) Feb 04 15:25:38 jonmason: I know there are some contstraints on the server, I don't recall what :/ Feb 04 15:26:01 jonmason: not helped that one of the arm servers is effectively dead :( Feb 04 15:27:58 There are some good Arm servers out now. It _should_ be possible to get one to you. I'll start an internal email to see if anyone is working on getting it replaced Feb 04 15:52:59 jonmason: I have a cunning idea of a project that you need to take on, it would help RP and the project ;) Feb 04 15:54:00 awafaa: i know, i know! sending a truckload of booze and spare motorcycle parts! Feb 04 15:54:44 LetoThe2nd: close, so close... alas no cigar Feb 04 15:54:53 awafaa: DANG. Feb 04 15:56:20 ok, now my brain pictures RP going on a ride like https://www.shutterstock.com/de/editorial/image-editorial/arnold-schwarzenegger-out-and-about-los-angeles-usa-04-apr-2020-10603300e Feb 04 15:58:57 awafaa: submerging hardware in coolant? Feb 04 15:59:50 jonmason: supervising the hardware install (as flightcrew) on the next starship flight / landing. Feb 04 16:07:01 zeddii: ++ Feb 04 16:07:48 it's an explosive opportunity! I say go for it!! Feb 04 16:18:08 Hmm, is there no dbg source package for gcc packages like libstdc++? Feb 04 16:29:39 hello guys ! I asked for a system to store yocto images and sdks. It seems that they are using a tool called artifactory, I've never heard about that and after a rapid look to the artifactory website I am more confused than before. Does anybody know how it works or have some docs to point me to ? Feb 04 16:37:31 kergoth: I'd have thought there should be Feb 04 16:39:10 LetoThe2nd: heh, I take mtb parts too! :) Feb 04 16:39:55 maybe there is and i'm just missing it, just built an sdk and was expecting them to be in there. but only have elfutils gdb glibc libgcc libnsl2 libtirpc libxcrypt prelink zlib in usr/src/debug, and gcc-runtime-dbg has almost nothing. artifact of the use of gcc-source, perhaps? Feb 04 16:39:57 hmm Feb 04 16:40:20 kergoth: it should be gcc-runtime-dbg I'd have thought Feb 04 16:40:58 that's what i thought, no sources in mine though. switching to nodistro/qemu to eliminate external variables from the mix Feb 04 16:41:03 thanks, i'll investigate further Feb 04 16:41:25 kergoth: FWIW I have an 18MB libstdc++ debug file in gcc-runtime-dbg Feb 04 16:41:52 mine has the debug files, but not the sources in usr/src/debug Feb 04 16:42:02 regardless of use of debug-with-src Feb 04 16:42:03 kergoth: oh, right sorry Feb 04 16:42:05 np Feb 04 16:42:19 kergoth: that is empty here too Feb 04 16:42:26 okay, thanks Feb 04 16:43:12 khem: I did a MACHINE=qemux86 bitbake core-image-sato-sdk -c testimage with glibc 2.32 and it works, then switching to glibc 2.33, it fails Feb 04 16:43:44 zeddii: there is a backtrace in the kernel om both :/ Feb 04 16:45:52 RP: you get vehicle parts of any kind, I get the booze. Deal! Feb 04 16:46:26 zeddii: I filed a bug for it as it was easier than pastebin ;-) Feb 04 16:46:27 https://bugzilla.yoctoproject.org/show_bug.cgi?id=14219 Feb 04 16:51:55 RP: ok. building the sato-sdk image right now. I think its some test which is failing perhaps ? since sato image booted ok for qemux86 here but will see how sato-sdk does Feb 04 16:56:28 khem: sato and sato-sdk have different tools in so it could be one of these is misbehaving on the new libc Feb 04 17:00:33 right lets see Feb 04 17:00:47 ltp takes so long to build :( Feb 04 17:01:13 Is it possible to do OVERRIDES_some-machine = "a" in order to be able to use IMAGE_INSTALL_append_a and ROOTFS_POSTPROCESS_COMMAND_append_a in an image recipe? Feb 04 17:02:14 And why "a"? Becuase other machines can result in setting the override flag "a", not just "some-machine". Feb 04 17:06:33 There is no concept of using PACKAGECONFIG on images? Feb 04 17:07:03 sveinse: there are IMAGE_FEATURES Feb 04 17:07:57 sveinse: what you're describing is MACHINEOVERRIDES. Add some-machine to MACHINEOVERRIDES in the appropriate machine and yes, that should work Feb 04 17:09:51 I'm trying to move away from machineoverrides, really. I have a image which generates different contents based on machine(overrides), but I now need it to be selected by other means than machine. Feb 04 17:10:35 sveinse: well, you can add your own generic overrides, just be careful about namespacing Feb 04 17:11:09 sveinse: MACHINEOVERRIDES literally just appends to OVERRIDES Feb 04 17:11:40 IMAGE_FEATURES is an great idea. That has turn-key solutions for package selections. But I would need something like this for ROOTFS_POSTPROCESS_COMMAND += "${@bb.utils.contains('IMAGE_FEATURES', 'a', 'something;', '', d)}" ? Feb 04 17:13:40 RP: the sato-sdk failure does it happen on both systemd/sysvinit ? Feb 04 17:18:04 khem: don't know Feb 04 17:28:19 khem: FWIW its not related to the stacktrace in dmesg as that happens with 2.32 and 2.33 in working and non-working cases Feb 04 17:29:33 I notice that my system unsets MACHINE, but sets MACHINE_ARCH. Is there a new policy or something in place that discourages the use of MACHINE in recipes? Feb 04 17:29:50 s/my system/bitbake/ Feb 04 17:30:19 RP: it seems ssh is not working on qemux86 perhaps that could be the reason ? Feb 04 17:30:35 I am building x86_64 image and see if thats the difference Feb 04 17:30:41 khem: that is why the tests are failing, yes Feb 04 17:31:06 sveinse: it unexports it, which is quite different from unsetting it Feb 04 17:31:13 RP: the daemon is running but ssh'ing does not work even from console, ssh localhost fails Feb 04 17:31:52 khem: interesting. I lost my debug env bisecting it to confirm it was definitely glibc uprev Feb 04 17:32:05 khem: still rebuilding after fighting other issues :/ Feb 04 17:32:08 RP: oh, my bitbake -e reads "unset MACHINE" on that entry... Feb 04 17:32:34 sveinse: which means "do not export this into the environment", its set in the datastore Feb 04 17:33:05 RP: a test would be to check if ssh is working with or without glibc 2.33 Feb 04 17:33:13 into qemux86 Feb 04 17:33:26 khem: its definitely working with 2.32 and not with 2.33, I confirmed that much Feb 04 17:33:53 right, I will check if its working with 2.33 + x86_64 Feb 04 17:33:57 RP: ok. That was subtle. I've always used bitbake -e as an insight into what the datastore have and use Feb 04 17:34:45 sveinse: traditionally, bitbake -e exposes a shell environment as the task would see. Its handy to debug the datastore but you do need to read what its saying Feb 04 17:34:49 but the "pre-expansion value" is printed just before the unset Feb 04 17:36:30 RP: Is that the reason why one cannot see the set history of ROOTFS_POSTPROCESS_COMMAND? Feb 04 17:37:04 sveinse: I don't know what that variable is doing to be able to comment :/ Feb 04 17:39:15 RP: Its a list of functions that OE/BB will call after the image has been compiled. For some reason, the ROOTFS_POSTPROCESS_COMMAND has been replaced by a function that contains all the configured functions to call. But the history of what recipe sets what in that var is gone. Feb 04 17:39:54 sveinse: I know what it does, I mean that I a) don't know what its showing in bitbake -e and b) I don't know how its being set Feb 04 17:41:27 If I were to venture a guess; bitbake is deleting the variable and replacing it with a function and with it wipes the change history. But I'm speculating. Feb 04 17:41:50 sveinse: I think history for functions may be suppressed Feb 04 17:42:40 khem: I think the difference is that sato uses dropbear whereas sato-sdk uses openssh Feb 04 17:42:43 jep, seems so Feb 04 17:43:36 RP: right Feb 04 17:44:20 sveinse: there may even be an open bug for that Feb 04 17:49:32 Hi Everyone, after creating a recipe using devtool add command and editing, recipe still in poky/build/workspace/ directory. I ran the "devtool finish recipe /layer/path" command but got this error: ERROR: Unable to find initial revision - please specify it with --initial-rev Feb 04 17:50:48 i don't understand how to go about fixing this, help will be much appreciated thanks. Feb 04 17:54:09 huh, this is odd, it seems to be trying to grab this path relative to the parent of the workdir's parent, but the file actually exists in the path relative to the build directory, not the workdir... also the file sin workdir-shared aren't captured at all, since the fdebug-prefix-map doesn't map it at all, you end up with debug source paths like '/work-shared/foo/' Feb 04 17:54:25 so actually seems to be two different problems preventing inclusion of sources in gcc-runtime Feb 04 17:54:27 * kergoth digs Feb 04 17:55:33 i expect we dont include shared files as they could easily be packaged by multiple recipes, which would result in file conflicts at installation time.. but we shouldn't just *not* package them, either... Feb 04 17:55:58 Shot from the hips here: No initial revision, could that be related to a new git repo that have no commits? Becuase you'd need a first commit to make a git repo valuable Feb 04 17:56:18 kergoth: its not any conscious decision I'm aware of FWIW Feb 04 17:56:24 * kergoth nods Feb 04 17:56:28 kergoth: more likely the code struggles with the shared workdir :( Feb 04 17:56:59 i'm not sure how to resolve it, the files referenced that are in shared might be unique to this recipe or might be common to multiple recipes using the shared workdir Feb 04 17:57:10 so packaging them is non-trivial Feb 04 17:58:47 sveinse: i suspected so, but the git repo already has existing commits. Feb 04 17:59:18 dorinda: i'm not an expert on devtool, and i could be wrong about this, but when i use "devtool add" to create a *new* recipe, i just move it to my desired layer manually Feb 04 18:00:02 dorinda: i think the "devtool finish" only works when you're modifying an existing recipe (aka "devtool modify") Feb 04 18:01:10 it's possible that if i understood better what it is trying to do that the --initial-rev could work, but i'm not sure what it's looking for Feb 04 18:02:30 tlwoerner: okay, let me try to move it manually then. i did'nt think of that Feb 04 18:04:03 Ah, I see, the debug source handling assumes that the paths can be found relative to dirname(dirname(workdir)) rather than using fdebug-prefix-map to map back to the original source paths, but if the files were generated, i.e. are in ${B} and need a custom fdebug-prefix-map, as is the case for gcc-runtime, they don't exist in the assumed paths Feb 04 18:04:10 that explains why include/ostream, etc aren't included Feb 04 18:04:48 kergoth: hmmm :( Feb 04 18:04:50 and actually the same is true for the shared workdir paths, we specify the fdebug-prefix-map for them, but the code assumes the resulting paths are relative to there too Feb 04 18:05:05 * kergoth trying to figure out why gcc-runtime-dbg is missing sources Feb 04 18:05:42 looks like ideally it'd map back to the original locations using the specified fdebug-prefix-map, but that would likely impact performance, so might have to opt-in to that when the debug prefix maps are customized Feb 04 18:05:54 hmm Feb 04 18:07:50 dorinda: does the devtool-base tag exist in the git repository? i expect initial-rev might be that, the commit where devtool set up the repo, so it knows which commits to turn into patches. if devtool isn't the one that set up the git repo, it probably coudln't figure that out Feb 04 18:07:57 admittedly not a devtool expert Feb 04 18:17:02 kergoth: hmm, okay i see but i've used this "devtool finish" command when modifying an existing recipe. I really don't know, but thanks. Feb 04 18:17:20 tlwoerner: Thanks, i just moved the recipe manually to the layer i wanted and it builds alright. Feb 04 18:17:37 Right, when you modify a recipe, devtool sets up the local git clone. If you used add to reference an existing clone rather than a remote repo, not sure if it does that? Feb 04 18:17:38 * kergoth shrugs Feb 04 18:17:47 Just a thought Feb 04 18:23:44 Thank you all for the help. :) Feb 04 18:41:30 moto-timo: I would to submit an ELC CFP about Kubernetes + Tekton + labgrid for Yocto CI... were you planning anything in that space? Feb 04 18:41:40 *would like Feb 04 18:45:22 with ELC canceled this year, we should do our own mini-summit thingy ;-) Feb 04 18:45:50 aka a glorified OEHH with speed talks Feb 04 19:01:28 RP: it seems openssh is the issue for ptest fails on x86, I can see that its working ok on x86_64 but not on x86 Feb 04 19:38:38 Can a FEATURE_PACKAGES_some pull in another FEATURE_PACKAGES_thing? I think not, right? Feb 04 20:25:04 Is it a bad thing to have an empty OVERRIDES .= ":${OTHERVAR}" if OTHERVAR is not defined? Feb 04 20:26:05 probably not ideal, but ensuring its always defined is pretty trivial usually.. Feb 04 20:27:50 kergoth: I think if we can get the files being added, we can worry about the packaging issue later. I think if the files are identical, the package manager might be ok with it Feb 04 20:28:35 hmm, good point. I'll work on it Feb 04 20:28:36 I can't make up my mind if its better to do ROOTFS_POSTPROCESS_COMMAND_append_myfeature via OVERRIDES, vs. manually typing out ${bb.utils.contains('VAR', 'myfeature', ...)} inside a large ROOTFS_POSTPROCESS_COMMAND Feb 04 20:30:27 The bad thing with large multi line blocks is that one cannot put comments in there. Feb 04 20:30:30 khem: agreed. any idea why? Feb 04 20:58:47 Is there any simple way to let bitbake produce an error if a variable is unset? Feb 04 20:59:49 sveinse: check it with anon python? Feb 04 20:59:53 sveinse: can definitely be done in anonymous python? Feb 04 21:00:05 Thanks Feb 04 21:00:06 JPEW: snap :) Feb 04 21:01:32 khem: it looks like its enabling seccomp then getting SIGSYS Feb 04 21:11:34 khem: I wonder if we need https://github.com/openssh/openssh-portable/commit/0f90440ca70abab947acbd77795e9f130967956c#diff-56aaf6f39b947c1321a2565a8944f7ea0168036855ddd1a3149dbaecb6c3421a Feb 04 21:11:58 I know it says arm but I think it applies to 32 bit IA too Feb 04 21:12:36 Hello everyone. I think I am seeing this wireguard issue. https://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg73480.html Feb 04 21:15:38 I know PREMIRRORS will be the answer.  As I got it weeks ago here.  But still I can't find how to use it. Feb 04 21:15:54 All examples I can find are using it to go from whatever to http. Feb 04 21:16:43 But what I would like to do is to redirect from e.g . http://github.com/something/x to http://mygit/something/x Feb 04 21:17:35 So, I'm not looking do download tarballs from another place.  But have access to local placed git repo's from the Internet to our Intranet. Feb 04 21:20:56 vermaete: first of all, git urls in src_uri are git://, not http://. second, premirrors is just a search/replace, the fact that the examplse happen to replace with http doesn't mean you have to do so, youc an replace anything you want in the url Feb 04 21:21:00 with whatever you want Feb 04 21:22:52 Has anyone noticed that brackted-paste mode being enabled in bash is causing problems with terminal output (specifically for testing)? Feb 04 21:23:29 You get weird escape codes in your output like: "echo 'JCQE''DBCNPQ'\r\n\x1b[?2004l\rJCQEDBCNPQ\r\n\x1b[?2004hroot@rock-pi-x:~# " Feb 04 21:23:51 Note the \x1b[?2004l and \x1b[?2004h Feb 04 21:24:00 @kergoth An example will probably help to explain.  https://github.com/Xilinx/meta-xilinx/blob/master/meta-xilinx-bsp/recipes-bsp/u-boot/u-boot-xlnx.inc#L9 Feb 04 21:24:37 JPEW: did we deliberately do that or was it an auto default? I have noticed some issues but not looked into it Feb 04 21:24:50 That git repo at github is fetched over http.  But at our company network, we can not access the Internet. Feb 04 21:24:51 RP: It was enabled by default in bash 5.1 Feb 04 21:25:08 JPEW: we could change it back... Feb 04 21:25:09 So, will PREMIRRORS be my answer? Feb 04 21:25:37 RP: Ya, I'm trying to figure out the best way to do that Feb 04 21:25:55 like i said, it's search/replace. https://github.com/openembedded/openembedded-core/blob/master/meta/classes/own-mirrors.bbclass .. i.e. PREMIRRORS = "git://github.com/Xilinx/.* git://localhost/my/git/mirrors/PATH \n " or something (untested). it's search/replace. replace github.com/Xilinx with your own host and subdir.. Feb 04 21:26:06 admittedly that example didn't show usage of PATH Feb 04 21:26:18 khem: above patch fixes it, confirmed Feb 04 21:27:01 ca va, I will give it a try.  Thanks for helping again. Feb 04 21:27:05 RP: there are new time64 syscalls Feb 04 21:27:06 Is it problematic if FEATURE_PACKAGES_something defines "something" which is also in OVERRIDES? I see that results in FEATURE_PACKAGES being defined from the override, but uncertain if it has any other obstructive behavior Feb 04 21:27:09 is it related ? Feb 04 21:27:53 ah I was at __NR_pselect6_time64 in strace :) Feb 04 21:28:09 so you beat me to it. I think it will fix arm/mips/x86 issues Feb 04 21:28:14 for AB Feb 04 21:28:37 RP: do you want me to create a patch or I guess you already might have one Feb 04 21:29:22 khem: I have one, will sort Feb 04 21:29:36 ok cool Feb 04 21:29:44 let test it locally here as well Feb 04 21:32:02 khem: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=06376c1af630889972be7d78da5228c557856901 Feb 04 21:34:05 RP: It's comforting that this got released in bash: # define BRACKETED_PASTE_DEFAULT 1 /* XXX - for now */ Feb 04 21:39:13 RP: thx, trying it locally here as well. Feb 04 21:42:45 JPEW: yes :/ Feb 04 21:43:12 khem: I've rebased your glibc upgrade onto steve's stable uprev Feb 04 21:43:18 (in -next) Feb 04 21:48:32 ok cool Feb 04 22:10:14 JPEW: bracked paste is enabled when non-interactive? is that when used over serial or something? I'd expect bash to be able to recognize when it's not on a tty.. Feb 04 22:40:45 kergoth: Ya, sorry. The commit message it wrong Feb 04 22:40:54 It's "interactive" over serial Feb 04 22:55:02 hmm, wonder if there's a way to disable it in that context somehow. would probably require session management or something funky. oh well Feb 04 22:55:08 JPEW: thanks for the clarification Feb 04 22:57:12 huh, this is weird. work-shared gcc sources in gcc-runtime context are '/work-shared/foo'. But none of the debug-prefix-map entries are configured to replace TMPDIR with the empty string, they should be replacing those with the gcc-runtime src debug paths. Weird? Feb 04 23:01:55 Hello - a relative yocto newb here. I trying to use devtool, specifilcally devtool add .... but I keep getting the following message: Feb 04 23:01:56 Error: workspace layer not setup Feb 04 23:01:56 Looking through the documentation at docs.yoctoproject.org indicate that using the command "devtool add" will create the workspace layer in the build directory if it does not exist. I've sourced in both the poky/oe-init and eSDK/environment scripts. Feb 04 23:01:57 Any ideas as to why I'm getting this error message? Feb 04 23:21:05 Hmm, wonder if we should be setting file-prefix-map as well as debug-prefix-map Feb 04 23:21:08 for __FILE__ Feb 04 23:27:49 kergoth: I think we do? Feb 04 23:28:53 kergoth: I'm thinking of macro-prefix-map :/ Feb 04 23:41:50 kergoth: one may influence the other I think? I'm just going off memory which might not be so good today... **** ENDING LOGGING AT Fri Feb 05 02:59:57 2021