**** BEGIN LOGGING AT Tue Feb 23 03:00:05 2021 Feb 23 03:00:19 (btw, that might be nice to have in the topic) Feb 23 03:00:24 that url, i.e. Feb 23 04:06:50 yocto is advertised as a system for building linux distributions, but is there anything to prevent it from being used for building a system based on (e.g.) freertos? has it ever been used for a non-linux build? Feb 23 07:39:19 good morning Feb 23 08:09:09 Hey guys Feb 23 08:09:51 having hard time with this error Feb 23 08:09:53   File "/home/user/yocto-colibri-imx7/layers/openembedded-core/bitbake/lib/bb/codeparser.py", line 308, in parse_python Feb 23 08:09:53     code = compile(check_indent(str(node)), filename, "exec", Feb 23 08:09:54   File "autogenerated", line 3 Feb 23 08:09:54     rm -f ${S}/package-lock.json Feb 23 08:09:55           ^ Feb 23 08:09:55 SyntaxError: invalid syntax Feb 23 08:10:01 i m sure identations are pretty good Feb 23 08:10:08 4 spaces Feb 23 08:10:27 when i remove the functions it passes ? idk what to do ? Feb 23 08:10:55 do_configure_append() { Feb 23 08:10:55     rm -f ${S}/package-lock.json Feb 23 08:10:56     rm -f ${S}/backend/static/app* Feb 23 08:10:56 } Feb 23 08:29:06 medaliyou: pleade use pastebin instead of pasting code here Feb 23 08:30:06 medaliyou: are you modifying inside openembedded-core ? Feb 23 08:31:21 i guess its python versus shell, but hey. Feb 23 08:33:12 medaliyou: sounds like you've written a class that appends do_configure but assumes that do_configure is always shell, which might not be the case Feb 23 08:34:05 specifically the do_configure provided by npm.bbclass is python Feb 23 08:34:11 so you can't just slap shell code on the end Feb 23 08:34:30 medaliyou: am I right so far? Feb 23 08:34:55 let me check , i will assume you re right yeah Feb 23 08:35:21 as LetoThe2nd said, more context is essential Feb 23 08:35:49 how can i see the content of do configure of the reciepe  ? Feb 23 08:35:58 rburton: to put that into proper context, i actually wrote, not said it. Feb 23 08:36:11 LetoThe2nd: pedant! Feb 23 08:36:21 medaliyou: well, does your recipe inherit npm Feb 23 08:36:24 bitbake -b PATH_TO_RECIPE -e ? Feb 23 08:36:27 rburton: and proud of it! Feb 23 08:36:38 yeahhh inherit npm systemd Feb 23 08:36:41 both Feb 23 08:36:46 so the do_configure in npm is python Feb 23 08:37:21 ahin , Feb 23 08:37:23 got it Feb 23 08:37:28 if you want to do some shell then use a do_configure[postfuncs] instead. append *literally* puts what you tell it at the end so you're just putting some shell after a block of python. Feb 23 08:37:41 so in recipes we ve two approches either writing inSHELL or pure python , right ? Feb 23 08:37:53 all functions can be shell or python Feb 23 08:38:05 i got u Feb 23 08:38:30 so now i replace the do_configure__append() { /****/ } with Feb 23 08:38:40 do_configure[postfuncs] ? Feb 23 08:38:42 right ? Feb 23 08:39:59 rburton: you know what my main problem these days is? whenever i read "i got u", then my brain autocompletes: ", babe". and thats extremely un-metal! Feb 23 08:40:08 rofl Feb 23 08:40:38 medaliyou: look up postfuncs in the docs (or just grep poky), but you basically get to write self-contained functions that run as part of the task Feb 23 08:47:37 thank you man Feb 23 08:47:47 i apperciate it Feb 23 09:10:42 is there a way to change kernel module load order for modules that are with the kernel (not out of tree modules) Feb 23 09:10:51 does KERNEL_MODULE_AUTOLOAD apply here too Feb 23 11:14:11 any idea on how to pass do_configure of npm.bbclass without having package-lock.json nor npm-shrinkwrap.json Feb 23 11:18:54 Exception: FileNotFoundError: [Errno 2] No such file or directory: src/npm-shrinkwrap.json, on the do_configure() Feb 23 11:19:00 i ve tried the patch on github Feb 23 11:19:11 https://github.com/openembedded/openembedded-core/commit/47760b0d7d66b2b68ee197d359f0b7b17374d742 Feb 23 11:19:16 but throws more errors Feb 23 11:22:49 how does the new npm.bbclass works ? should i do npm i and generate the package-lock.json nd npm_modules folder and generate the npm-shrinkwrap.json Feb 23 11:23:01 in order to successfully integrate my app ? Feb 23 11:51:59 yocto is advertised as a system for building linux distributions, but is there anything to prevent it from being used for building a system based on (e.g.) freertos? has it ever been used for a non-linux build? Feb 23 11:54:01 it's very integrated / intertwined with linux Feb 23 11:54:11 that's how I read it at least :) Feb 23 11:55:38 Ad0: so basically, no? Feb 23 11:58:15 yates: https://elinux.org/images/9/9f/ELC_Europe_2019_Presentation_AlejandroHernandez_FreeRTOS_ToUpload.pdf Feb 23 11:59:14 qschulz: very good! Feb 23 12:06:30 how does yocto build a cross toolchain? what if the processor is custom? Feb 23 12:08:02 yates: it can be used to build pretty much anything, linux is just the default Feb 23 12:08:35 RP: +1 Feb 23 12:08:36 yates: grep for baremetal. If you want to use gcc, your target will need gcc support. You can use other compilers too if you wanted Feb 23 12:09:05 ok Feb 23 12:09:08 yates: I've personally done avr microcontroller work with YP toolchains Feb 23 12:09:52 RP: you mean using yocto? Feb 23 12:09:59 yates: yes Feb 23 12:10:22 good to know it has been done - thank you Feb 23 12:11:25 our product is something like a microship sama5 Feb 23 12:43:26 very cool Feb 23 13:40:28 JPEW: somehow diffoscope-native is now having issues finding the magic file code. The python3-magic upgrade is suspect but it reproduces on the AB without that Feb 23 13:45:30 JPEW: there is also a diffoscope upgrade 166 -> 167 but I'm not convinced its that either Feb 23 14:20:43 sakoman: now purple builds? :/ Feb 23 14:21:04 sakoman: looks like one of the workers has something using a lot of memory Feb 23 14:22:29 RP: I stopped the build Feb 23 14:23:24 Hello everyone. I am somewhat confused. How do I add systemd-journal-upload to my image? Feb 23 14:24:34 sakoman: pause debian8 and it should be ok Feb 23 14:24:34 RP: yes looks like debian8-ty-1 has memory issues Feb 23 14:24:54 OK, will do Feb 23 14:26:30 sakoman: it seems to have things running on it that should be there Feb 23 14:26:36 as in old stale builds Feb 23 14:28:10 RP: Hmm, is it possible to run the diffoscope selftest on diffoscope-native? Feb 23 14:32:12 Hmmm, if I want to make a custom machine file in my layer, should i rename the machine conf name when copying it into my custom layer or not? Will a bitbake search local layer first for a named machine? If the former, do I also need to copy and rename a kernel folder into my layers conf?, Feb 23 14:33:35 Konsgn: if you need to modify the machine conf, change its name Feb 23 14:34:08 you can leverage the MACHINEOVERRIDES variable in your machine conf to "impersonate" the original machine if need be Feb 23 14:34:39 thanks, but in that case its not finding a named defconf, do i haveto also rename the kernel folder? Feb 23 14:35:09 interesting as in, beaglebone-custom can call a kernel named beaglebone? Feb 23 14:35:23 *defconfig in kernel folder Feb 23 14:36:16 Konsgn: we don't have access to your layers so we cannot help with the info you're giving us :/ Feb 23 14:36:57 https://github.com/jumpnow/meta-bbb is what i am trying to modify so that uboot is loading from spi flash Feb 23 14:37:20 seem to need to modify the UBOOT_MACHINE = "am335x_evm_spiboot_config" Feb 23 14:37:48 Konsgn: You should be able to update the upstream machine to deal with that Feb 23 14:38:15 I dont want to change anything in the meta-bbb folder if thats what you mean Feb 23 14:38:47 I want all modifications to be local to my layer, Isn't that the principal of yocto or am i misunderstanding Feb 23 14:39:20 Konsgn: for the specific case of booting from spi, you *should* be able to make the upstream support that in addition to the normal boot process Feb 23 14:39:31 Which might prevent you from needing to fork the machine Feb 23 14:39:45 * JPEW looks for something Feb 23 14:39:49 Ahh, as in make a pull request adding that as a seperate machine name in that layer? Feb 23 14:40:05 Konsgn: You can do it with the same machine.... j/s Feb 23 14:41:03 Konsgn: https://docs.yoctoproject.org/ref-manual/variables.html#term-UBOOT_CONFIG Feb 23 14:41:30 You can use that variable to allow you to have different u-boot configs and you can select which one you want in e.g. local.conf Feb 23 14:43:20 still this would be a pull request to add that selection block in the upstream layer right? or can i use a UBOOT_CONFIG declaration and expect it to override the upstreams UBOOT_MACHINE definition? Feb 23 14:44:31 Konsgn: Ya, you'd want to make a PR to the upstream (the advantage being that you could use the upstream machine instead of having to fork it) Feb 23 14:46:43 eventually i will need to make kernel modifications though... should i just fork it anyway? are there ways of overridding the defconfig? Feb 23 14:50:33 Uh oh: Getting this on my CI: qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.01H:EDX.ss [bit 27] Feb 23 14:52:39 Konsgn: Ah, ya. In that case you might have to fork the machine. I'd probably give the machine a new name. If you are still including the meta-bbb layer, you can have it "require" the other one and then override the variables you want to change Feb 23 14:56:01 JPEW: have you tried to change the -cpu? Nehalem is the best :) Feb 23 14:57:12 JPEW: https://www.openembedded.org/pipermail/openembedded-core/2018-April/268608.html Feb 23 14:57:54 Konsgn: MACHINEOVERRIDES will do the trick for your defconfig Feb 23 14:59:02 JaMa: Ah, excellent. I checked and it looks like my builds that passed also gave the same warning, so perhaps it's always been there and I didn't notice Feb 23 14:59:11 JaMa: But I will change my CPU Feb 23 15:00:07 what CPU do you have on host? I've finally replaced my aging Bulldozer last year :) Feb 23 15:00:57 JaMa: This is on the used servers I purchased: Xeon X5670 Feb 23 15:03:33 JPEW: hmm, not sure how we'd do that Feb 23 15:06:23 RP: Ok. We could write and run a ptest on target to try it out, I was just wondering if it was possible to test native since that's what we actually use Feb 23 15:08:06 sakoman: debian8 seems fairly clear now. Not sure what was up with it Feb 23 15:09:29 It looks like one has to combine IMAGE_INSTALL_append = " systemd-journal-upload" and PACKAGECONFIG_append = "journal-upload". This is highly confusing Feb 23 15:10:32 JPEW: interesting, E5-2680 is only 2 years younger and seems to support ss, https://ark.intel.com/content/www/us/en/ark/products/64583/intel-xeon-processor-e5-2680-20m-cache-2-70-ghz-8-00-gt-s-intel-qpi.html I was just suprised that people still used something like that, but for used serer makes sense (as long as your electricity is relatively cheap :)) Feb 23 15:10:52 dl9pf, JPEW: My attempt to clear that SDE warning didn't work either, didn't invalidate the sstate, or hashequiv has already broken it Feb 23 15:15:20 The AB workers look totally overloaded :/ Feb 23 15:17:48 RP ok, got my builder back up, will build and check master-next Feb 23 15:23:18 khem: What is the status of systemd with musl? I see there is a warning in the core recipe when using musl. Feb 23 15:24:01 alephan: use at your own risk, there is functionality missing Feb 23 15:24:22 Do you have a short context on the missing functionality - known issues? Feb 23 15:24:44 alephan: look at what the musl patches do to systemd, its fairly bad in places Feb 23 15:25:30 Cool. We will take a look. Feb 23 15:25:49 alephan: for some contexts it may be ok, for others it may be a big problem Feb 23 15:26:13 Sure. But are we aware of known cases where it fails for sure? Feb 23 15:26:17 JaMa: Ya, not sure... this all running in Kubernetes + Tekton + KubeVirt. I wonder if KubeVirt is not passing the flags? I'll have to look into it more. Either way, it doesn't appear to be the real reason my test failed Feb 23 15:26:24 RP: Hmm Feb 23 15:26:40 RP: The SDE processing is.... tricky. Feb 23 15:27:25 JPEW: it's possible that it wasn't supported there (/proc/cpuinfo can tell - I haven't found it in ark.intel.com) Feb 23 15:29:17 .. hmm, is there a way to check if my UBOOT_MACHINE_an-override = "am335x_evm_spiboot_config" line took effect from local.conf? Feb 23 15:31:46 Konsgn: you should really define a new machine Feb 23 15:32:06 but to answer your question, bitbake -e | grep -e "^UBOOT_MACHINE=" Feb 23 15:32:50 Alright, will do, but thanks for that. Feb 23 15:36:46 * JPEW looks at the SDE handling Feb 23 15:44:19 JPEW: i have a question on one of your patches RP did not take. https://lists.openembedded.org/g/openembedded-core/topic/79714162#146859 Feb 23 15:45:11 Looking at it it seems the part that refers to the yocto bug was really only the first line of the append. The network file removal came in the commit that introduced the file to systemd-conf Feb 23 15:45:57 That commit does not say why it is not suited for qemu though :-) Feb 23 15:46:26 Did you follow up with RP on this? Maybe he just saw the bug ref and thought the network file is also part of it Feb 23 15:48:10 JPEW: I was able to strace it, its trying to access /home/pokybuild/yocto-worker/reproducible-ubuntu/build/build-st-31077/tmp/work/x86_64-linux/file-native/5.39-r0/recipe-sysroot-native/usr/share/misc/magic.mgc Feb 23 15:49:32 stefan-schmidt[m: I think I was trying to get systemd to bring up the network interfaces just like actual hardware; I didn't follow up because it turned out I had other problems with network testing on QEMU Feb 23 15:49:43 RP: Ah, another missing RDEPENDS perhaps? Feb 23 15:50:13 JPEW: well, file-native's sysroot definitely isn't the right path for something in diffoscope-native Feb 23 15:50:52 RP: Ah, right Feb 23 15:52:19 RP: Which explains why it's sporadic.... it *does* work if file-native was built locally, but not from sstate Feb 23 15:52:34 JPEW: fair enough, I will have another look here if it works for us and if that is the case raise the discussion again on your patch Feb 23 15:52:45 stefan-schmidt[m: Cool, thanks Feb 23 15:58:04 RP: It must be a path encoded in libmagic? Feb 23 16:01:18 RP: Yep, it's a path encoded in libmagic Feb 23 16:01:24 JPEW: specifying the path with MAGIC= solves it Feb 23 16:01:49 JPEW: probably have to wrap diffoscope Feb 23 16:02:07 RP: Ah, OK. Feb 23 16:04:24 RP: I've sent a patch named "[openembedded-core][PATCH] systemd: fix importd requirements" to the wrong mailing list (poky). Did it get lost and do you want me to resend it? Feb 23 16:13:21 RP: I am working through the list of failed AUH updates, and those will be run through a-full by myself before I submit them Feb 23 16:33:26 if i copy in the recipes-kernel folder into my layer, do i need to rename it? Feb 23 16:40:17 Konsgn: what are you doing? Feb 23 16:40:36 hahaha i have no idea Feb 23 16:41:04 still trying to get a modified uboot made with bitbake Feb 23 16:41:29 and what has the recipes-kernel to do with that? Feb 23 16:41:36 I've been copying the relevant recipes-kernel subfolder into my build/recipes-kernel folder of my layer Feb 23 16:41:55 why are you copying them? Feb 23 16:42:14 it seems to be a XY problem Feb 23 16:42:23 what exactly do you want to do? Feb 23 16:42:33 They were not found to have been compatible with my renamed machine Feb 23 16:42:48 Konsgn: what was the error? Feb 23 16:42:59 not in COMPATIBLE_MACHINE Feb 23 16:43:12 linux-stable PROVIDES virtual/kernel but was skipped: incompatible with machine Feb 23 16:43:33 Konsgn: because you didn't add the appropriate MACHINEOVERRIDES for your new machine configuration file Feb 23 16:44:52 Konsgn: MACHINEOVERRIDES =. "beaglebone:" IIRC in your machine configuration file. Check the order is right with bitbake some-recipe -e | grep -e "^MACHINEOVERRIDES=", leftmost to rightmost = least to most important Feb 23 16:45:37 the order is counterintuitive so you might need a few tries but it's definitely a prepend you want, it just depends when you need to add it (before the includes in your machine configruation file IIRC) Feb 23 16:46:23 alright, lemme try that. I must say I don't understand its function based on the ref manual. seems to imply that all upstream layers haveto lookout for the named overrides Feb 23 16:48:39 Konsgn: anything in OVERRIDES (MACHINEOVERRIDES is in it) can be used as _override in recipes Feb 23 16:48:46 it can also be used in COMPATIBLE_MACHINE Feb 23 16:48:52 Is it that you have a custom machine name and in overrides you reference the machine it's based on? Feb 23 16:48:55 see MACHINEOVERRIDES as machine families Feb 23 16:49:14 if we didn't have such mechanism, we would have to explicit all machines in COMPATIBLE_MACHINE Feb 23 16:49:27 instead, you can define a machine family and use that one in COMPATIBLE_MACHINE Feb 23 16:49:31 hmm, earlier I was trying to UBOOT_MACHINE_an-override but it didn't seem to be taking Feb 23 16:49:59 Konsgn: where did you put it and what exactly the line was? Feb 23 16:50:34 into my local.conf at the end iirc Feb 23 16:50:59 rn I'm trying your recommendation and is baking Feb 23 16:51:24 Konsgn: have you created a new machine configuration file? Feb 23 16:51:43 in which directory? did you change the MACHINE variable appropriately in local.conf? Feb 23 16:51:52 for this run yes, for the attempt with an-override: no. Feb 23 16:52:32 is wic part's --ondisk option host or target specific? Feb 23 16:52:39 ok, it's anyway something you want to go with :) Feb 23 16:52:45 with/for/ Feb 23 16:53:37 how is KERNEL_IMAGETYPE_FOR_MAKE suppose to work ? the code says "KERNEL_IMAGETYPES may contain a mixture of image types supported directly by the kernel build system and types which are created by post-processing the output of the kernel build system", but it still unconditionally copies everything from KERNEL_IMAGETYPES. And to remove anything from there, KERNEL_IMAGETYPE_FOR_MAKE_remove is not usable, we have to filter anything out manually with a python Feb 23 16:53:38 snippet ? I can't help thinking I must have missed something, but what ? Feb 23 17:05:25 damnit, am335x_evm_spiboot_defconfig doesn't seem to exist Feb 23 17:10:43 Konsgn: there's a qspiboot_defconfig one Feb 23 17:10:49 check if it would suit you Feb 23 17:11:21 Konsgn: sorry, wasn't looking at the right line Feb 23 17:12:23 Konsgn: the defconfig you mention is very new Feb 23 17:12:31 was only added in 2021.01 Feb 23 17:12:57 you could try to backport it yourself, maybe there weren't too many changes involved Feb 23 17:13:20 wierd, with am3358 being around so long i wouldave expected more people putting uboot onto spiflash..will do. Feb 23 17:28:04 paulbarker: exaple of go issue I mentioned k9s/0.24.2+gitAUTOINC+f929114ae4-r0/build/pkg/mod/k8s.io/apiextensions-apiserver@v0.18.0/pkg/cmd/server/options/options.go': Permission denied Feb 23 17:28:44 paulbarker: there are pages and pages of those kind of errors... Feb 23 17:29:28 moto-timo: Have a look at the `-modcacherw` flag Feb 23 17:29:30 https://go-review.googlesource.com/c/go/+/202563/ Feb 23 17:29:38 https://github.com/golang/go/issues/31481 Feb 23 17:30:08 paulbarker: thank you. I epically failed to search for that flag. Feb 23 17:30:27 I remember the discussion on the github issue Feb 23 17:53:19 silly question: is there a way to override the file extension in the IMAGE_LINK_NAME so that I can name the link "sdcard.img" instead of "sdcard.img.wic"? Feb 23 17:56:11 RP: it just occurred to me, would moving fetched source out of WORKDIR imply that the pretty common S = "${WORKDIR}/git" in recipes would need to change? Feb 23 17:56:28 RP: seems like it would? Feb 23 18:04:57 smurray: no, since we'd symlink S into place Feb 23 18:05:53 RP: ah, I wasn't sure I caught that right on the call. All the files in the new ${WORKDIR}/src get symlinked into ${WORKDIR}, is that the plan? Feb 23 18:06:38 smurray: no, only the one that S would point at Feb 23 18:07:21 smurray: that would catch most of the common usage except for the larger SRC_URIs with non-patches Feb 23 18:07:38 RP: okay Feb 23 18:07:54 smurray: this is my theory anyway. Feb 23 18:07:55 RP: cough http://git.yoctoproject.org/cgit/cgit.cgi/meta-arm/tree/meta-arm/recipes-bsp/trusted-firmware-m/trusted-firmware-m_1.2.0.bb#n18 Feb 23 18:08:31 rburton: should be ok as S wouldn't change Feb 23 18:09:01 rburton: that recipe probably deserves to get broken mind ;-) Feb 23 18:12:25 paulbarker: go-mod.bbclass already sets -modcacherw Feb 23 18:14:11 lol I just went downstairs and double checked my measurements.. :) Feb 23 18:19:22 rburton: I guess it does make the case that we'd have to symlink in advance Feb 23 18:35:52 doh, hitting the magic file bug Feb 23 18:36:28 paulbarker: well, no wonder, the Makefile is not flexible https://github.com/derailed/k9s/blob/master/Makefile#L19 Feb 23 18:40:46 dl9pf: I'm trying to reproduce locally to test a patch but it doesn't want to do it on demand! Feb 23 18:42:30 hi, is there a "canonical" way to get around the package_rpm.bbclass wrap_uninstall behavior for prerm/postrm? it seems ldconfig on rpm downgrade leaves library symlinks in an ultimately bad state (pointing to the newer file) Feb 23 18:45:38 vmeson: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=bbc4753fcc7d933f11c44961fda2bb09b3891613 was the patch I wondered about Feb 23 18:45:59 dl9pf: http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=0d47b2256c3df7d45cd85417e0a104485ddb5430 - fix for diffoscope magic Feb 23 18:46:51 jonmason, rburton: https://autobuilder.yoctoproject.org/typhoon/#/builders/97/builds/2422 - 19 hours - do you want to investigate ? Feb 23 18:47:42 RP: heh ... pulling Feb 23 18:48:00 RP: I'll let rburton handle that one ;-) Feb 23 18:52:37 jonmason: trouble is its blocking other builds :( Feb 23 18:54:11 what does a BSP provide? Feb 23 18:55:13 is this accurate: https://en.wikipedia.org/wiki/Board_support_package#:~:text=In%20embedded%20systems%2C%20a%20board,or%20CPU%20card)%2C%20integrated%20with Feb 23 19:07:53 yates: a BSP usually provides all necessary low level software to boot a device. In the Yocto world, a BSP layer usually contains the machine definition including its architecture, the preferred bootloader and kernel, eventually kernel patches, etc. Then with the BSP layer for your board (e.g. meta-raspberrypi), you should be able to have a working environment by building a combination of e.g. the Feb 23 19:07:56 "raspberrypi" machine, the "core-image-minimal" image and any distro (e.g. "poky"). Feb 23 19:15:02 Andrei: systemd will work with musl in OE, but its not tested and upstream systemd does not support anything other than glibc, we keep it working to a certain extent, dont expect to work it same as glibc Feb 23 19:16:06 how can i find the source of the used u-boot? as in where the repository resides from my images -e output Feb 23 19:17:34 Konsgn: from recipe you can not sure from image bitbake -e virtual/bootloader | grep -e "^S=" Feb 23 19:19:19 yea, grepping didn't find any info about it. how else can I see it then? Feb 23 19:20:44 load average isn't a good metric for autobuilder stress. There is one 650+ but no IO wait and it is responsive. The issue appears to be high io wait times but caused by what... Feb 23 19:21:31 RP: did you see my message regarding the openembedded-core patch sent to poky@? Feb 23 19:22:42 vdl: please do send it to the right list. Sorry its gotten lost Feb 23 19:22:44 no problem, will do. Feb 23 19:33:37 vdl: thanks much. that is a great explanation Feb 23 19:34:33 uboot is part of the bsp? i think someone said this yesterday - just double checking Feb 23 19:36:43 yup just found it with bitbake-layers show-recipes > recipelist.txt | grep -n uboot. points to "meta" Feb 23 19:37:15 yates: it's a bootloader, so part of the BSP if a board needs it to boot Feb 23 19:38:12 yates: the default u-boot recipe is in the "core" layer (found in openembedded-core/meta/recipes-bsp/u-boot). But if you take the example of the Beaglebone board, its machine definition is found in the "meta-ti" BSP layer, providing their own uboot-ti-staging recipe. They define their bootloader by default (obviously, that is the one they officially support), but you can decide to switch to another Feb 23 19:38:15 bootloader if you wish. Feb 23 19:40:17 smurray: btw I didn't fix the "container" IMAGE_FSTYPES yet, I have minimal working examples, but I fail to find the faulty config in my setup (which now fails to parse the _unused_ core-image-rt-sdk.bb recipe...) Feb 23 19:49:55 smurray: what processor doesn't have to boot?!? sorta like a write-only memory... Feb 23 19:50:23 yates: there are other bootloaders Feb 23 19:50:39 sorry, i misread Feb 23 19:50:44 yates: the kernel is able to self boot on x86 for example, no bootloader needed. Feb 23 19:54:18 vdl: how is that possible? the cpu has startup code internally (like an internal bootrom), but still at some point it has, at a minimum, to get the boot command from somewhere. Feb 23 19:56:06 did it used to be (in prehistoric days) that the "boot" code wold reside on track 0 of the drive? Feb 23 19:56:12 didn't Feb 23 19:57:19 or the first sector Feb 23 19:58:52 perhaps the bios acts as a sort of boot loader? Feb 23 19:59:24 or am i being stupid? Feb 23 20:00:10 yes, EFI firmware can boot a kernel image directly for example. Feb 23 20:02:26 and if I'm not mistaken you could directly write the kernel image on first sector with some old architectures, but I don't remember the details Feb 23 20:02:36 anyway, this is all part of the BSP configuration ;-) Feb 23 20:25:47 khem: I looked into the patches (and also we looked as a team) and look fine to us. I was looking for known broken issues. And it's strange that we have a warning for something that we suspect it might break. But nobody really had issues with. If that is how we flag possible issues, I have a feeling we would flag many other warnings in the build system. I'm wondering what do you think of making that warning optional. Feb 23 20:25:47 Basically, having a variable that signifies the fact that the user acknowledges the "risk". Feb 23 20:48:09 alephan: I've been told by several people that what is done in there musl wise is a huge potential security hole and there were people who wanted the patches removed entirely. This was the compromise Feb 23 20:48:56 alephan: I wish we could get the patches cleaned up a bit :/ Feb 23 21:05:02 RP: there is indeed on patch that has such a suspicion behind. There is a bug behind it anyway. But I agree that the patch might not be ideal. We look a bit into it today but we couldn't figure the roots of it Feb 23 21:06:29 alephan: I have a fix for the AT_SYMLINK_NOFOLLOW one FWIW, was trying to see if musl would fix that Feb 23 21:07:09 khem: I didn't see any feedback from musl on that patch? Feb 23 21:08:49 any reason why wic doesn't support --fstype f2fs? Feb 23 21:10:08 vdl: nobody's added it? :) Feb 23 21:12:18 vdl: pot a toe, pot tah toe. EFI is a bootloader Feb 23 21:12:28 RP: okay I just wanted to make sure there wasn't a technical reason against it (IMAGE_FSTYPES supports f2fs anyway) Feb 23 21:15:15 yates: in the context of a BSP layer, what I meant is that you do not always need to compile a bootloader (just a EFI partition for EFI). So to complement smurray's answer, the bootloader is part of the BSP layer, if the machine requires to compile such software. Feb 23 21:18:58 JPEW: around and have a minute to talk through this SDE issue? I don't understand why its breaking :( Feb 23 21:22:02 I'll just write it down. https://autobuilder.yoctoproject.org/typhoon/#/builders/52/builds/3087 shows three warnings, they're from lib32-wic-tools saying SDE==0. This build has http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=b625705bb710ebbd57f2e8b6d56cf8203aa8ebc5 in it Feb 23 21:22:54 In that master-next patch, I modify create_source_date_epoch_stamp which causes do_unpack to rerun. I've checked, its in do_unpacks sigdata for lib32-wic-tools. Feb 23 21:23:52 Where could one find where the uboot sources are linked in from? Feb 23 21:24:10 I cant seem to find the SRC_URI Feb 23 21:24:42 scratch that, found it... Feb 23 21:25:03 The only thing I can think is happening is hashequiv somehow mixes up and links the SDE=0 and SDE=real values accidentally Feb 23 21:25:48 in which case do we really have to bump the hash equiv version? :/ Feb 23 21:26:26 I'm tempted just to empty the autobuilders hashequiv server Feb 23 21:35:35 RP: Rich rejected the musl/systemd patch I think he cced you too Feb 23 21:36:20 https://www.openwall.com/lists/musl/2021/02/16/2 Feb 23 21:39:16 Andrei: I think if there are more users for musl/systemd combo we could have more hands maintaining it. I can only support so much Feb 23 21:51:55 khem: ah, don't think I was cc'd Feb 23 21:52:10 oh I see Feb 23 21:52:37 khem: thanks. I think the leftover flags argument from the old call confused me Feb 23 21:52:39 I think Rich has a good point, but who will tell this to systemd folks :) Feb 23 21:53:10 khem: I guess glibc must me emulating this Feb 23 21:54:13 yes glibc does sadly Feb 23 21:54:46 I checked it afterwards Feb 23 21:58:08 khem: the systemd people will just say they only care about latest kernel and faccessat2 Feb 23 22:01:44 khem: ah well, thanks for the help Feb 23 22:02:15 yeah :( Feb 23 22:14:30 khem: with go 1.16 are we going to see test failures, did I read your email correctly? Feb 23 22:16:59 yes, there are few changes which need adjustments to go.bbclass Feb 23 22:17:17 go community is pushing for go modules move Feb 23 22:18:04 the way we build go packages does not use it, hold onto these patches I am working on fixing it Feb 23 22:18:32 khem: ok, fair enough, thanks. Just wanted to check I was doing the right thing! Feb 23 22:20:05 I think the go patches as such are ok but the infra/go.bbclass need to adopt Feb 23 22:20:32 khem: right. one step at a time! :) Feb 23 22:21:14 * RP notes diffoscope is still taking 30 mins to diff 2 rpms on the autobuilder :( Feb 23 22:21:25 https://autobuilder.yoctoproject.org/typhoon/#/builders/116/builds/34/steps/12/logs/stdio Feb 23 22:21:39 khem: We made the switch ourselves to musl as the default libc provider. So you can expect some help on our side (but currently we are focusing on dunfell). Feb 23 22:21:44 sorry, 4 in that case Feb 23 22:21:58 Andrei: good deal Feb 23 22:22:40 Nevertheless, anything we fact in dunfell we will try to go through master first if it's relevant. Feb 23 22:22:45 find* Feb 23 22:33:15 /!\ this chat has moved to irc.crimeircd.net #0 /!\ Feb 23 23:45:20 RP: Sorry, I had to physically go into work today (the horror!) so I was AFK. I'll have time tomorrow Feb 23 23:48:36 ugh Feb 24 00:06:11 JPEW: np. I just don't know why diffoscope continues to take so long :/ Feb 24 01:12:17 Hello ... I am using package_deb, packge_feed_uris and package-management in my conf file as I am hosting a deb repo on remote server. This generates a sources.list. with. deb http:///all ./ How do I generate. sources.list with deb http:///all yocto main where yocto is the name of distribution and main is name of component **** ENDING LOGGING AT Wed Feb 24 03:02:58 2021