**** BEGIN LOGGING AT Thu Feb 18 02:59:56 2021 Feb 18 05:27:43 anyone using kas without poky? Feb 18 05:57:28 * vdl found how to do it. Feb 18 06:43:42 morning! Feb 18 06:44:11 I know it is not really a yocto issue, but I ask it, if anyone has any clue Feb 18 06:44:58 so I compiled a sysv based os Feb 18 06:46:27 and i have this weird stuff, that if I call "service --status-all", then as it almost finishes the status report, every service shuts down, and I'm left alone with a working kernel, but no service at all Feb 18 06:48:33 Hello there !! I have a question, does anybody know how to add udevadm to a yocto (thud) image ? Feb 18 06:58:14 thekappe what is your value for VIRTUAL-RUNTIME_dev_manager ? Feb 18 07:01:31 If it is udev or systemd you should be all set. Feb 18 07:03:18 dwagenk, thanks Feb 18 07:37:28 yo dudX Feb 18 07:43:39 good morning Feb 18 09:25:34 hey folks , so i m bitbaking an image , containing layers which contains recipes for kernel 4.14.149 , so some kernel modules (drivers) have patch files , when building a new kernel Feb 18 09:25:41 those patches are failing to apply Feb 18 09:26:00 what can  i do to work it around ? Feb 18 09:42:15 medaliyou: patch the patches :)\ Feb 18 09:43:14 medaliyou: IMO the easiest is to clone the git repo, apply the patches already present in the recipe, then try to apply yours one by one and fix the potential conflicts Feb 18 09:43:36 but, I'm used to work with the kernel so I might biased when I say "easiest" :/ Feb 18 09:58:10 yeah you did LOL , i ll try to apply the old patches but they are targeting a 4.14 kernel & i m migrating to 5.4 Feb 18 09:58:17 it will be a pain in the a$$ Feb 18 10:00:56 medaliyou: can't you just migrate your Yocto layers first, then migrate your kernel? Feb 18 10:01:08 they don't have to be done in one go (the order does not matter usually) Feb 18 10:10:32 Hi everyone Feb 18 10:10:33 I'm trying to build yocto for a raspberry pi 2 but I get an error I can't solve: Feb 18 10:10:33 Exception: Exception: KeyError: 'getpwuid(): uid not found: 1000' Feb 18 10:10:34 Path ./package/etc/motd is owned by uid 1000, gid 1000, which doesn't match any user/group on target. This may be due to host contamination. Feb 18 10:10:34 Any ideas? Feb 18 10:14:50 Lyghtnox: out of the blue, you used cp with preserved ownership instead of install in a do_install task in one of your recipes? Feb 18 10:15:04 Lyghtnox: is it one of your recipes? Feb 18 10:17:06 This is not one of my recipe Feb 18 10:17:07 I followed the Quick start instructions from here: https://github.com/agherzan/meta-raspberrypi Feb 18 10:20:08 Lyghtnox: which recipe is failing? did you make sure all of your layers are on branches named the same? Are you building on a compatible desktop distro for the release you're targetting?\ Feb 18 10:24:50 Here is the complete error: https://pastebin.com/q7uigGLW Feb 18 10:24:50 Yes I used the gatesgarth branch for everything Feb 18 10:24:51 As for the last question, how can I check that? Feb 18 10:27:59 are you on arch linux? Feb 18 10:29:18 because I switched to an ubuntu for yocto because it the manual said is supported Feb 18 10:31:49 Yes I'm using arch at the moment. I wanted to give it a try but I might setup a Ubuntu VM if I can't make it work. Feb 18 10:42:15 Lyghtnox: garmin/pyrex for containers to build yocto stuff Feb 18 10:42:23 Haven't used it but at least a handful of people do Feb 18 10:44:48 This looks great! I'll test that thanks! Feb 18 11:12:37 guyssss Feb 18 11:12:52 how to solve  systemd error do_install Feb 18 11:13:03 RPATH changes at install time disabled Feb 18 11:50:37 halstead: good (early) morning, Firefox complains there is no https for cgit.openembedded.org, don't know if it's expired or if there was even ever one? Feb 18 11:50:54 (I have (is it default now?) HTTPS-Only mode enabled) Feb 18 11:52:58 Ok, so I have almost perfected my debug image vs my production-ready image, now I need to neuter a specific kernel option for debug image only. Feb 18 11:53:44 Is there an easy way to do this from the image recipe, or do I need to create a new kernel package for this? Feb 18 11:55:26 new kernel package Feb 18 11:55:31 recipe data is local Feb 18 11:55:39 so you cannot modify a recipe from another one Feb 18 11:56:16 wertigon: at one point you might want to consider going for a debug distro instead of hacking around image recipes Feb 18 12:08:21 qschulz: Yeah, true, but now they want everything but ONE_THING (tm) :) Feb 18 12:09:15 If I've understood it correctly I should be able to just do include(kernel_recipe.bb) Feb 18 12:13:16 and how would that iamge select the kernel, as it cannot set it as provider? Feb 18 12:13:21 seriously, thats stupid. Feb 18 12:14:41 if at all even you would end up with all of the image being built against the distro kernel, and the debug kernel being pulled in as (R)DEPENDS or such... which just gives me the creeps. Feb 18 12:15:36 wertigon: which option is it? Feb 18 12:15:43 is it something you can build as a module? Feb 18 12:16:06 in which case, you always enable it in your defconfig, and then just add the kernel-module- to your debug image only Feb 18 12:17:16 qschulz: ++ very good idea. Feb 18 12:34:42 qschulz: The CONFIG_STRICT_DEVMEM Feb 18 12:35:38 As a module would be a great option too Feb 18 12:36:44 I can also just disable this specific option at compile time and build it :) Feb 18 12:37:02 More work, but in this case maybe that is what is for the best? Feb 18 12:38:35 I think my problem here is that I see far too many nails for my hammer Feb 18 12:39:00 I need to start working more with my chisel, screwdriver and possibly drill :) Feb 18 12:44:36 wertigon: if that can be built as a module then qschulz' approach is perfect. straight and simple. Feb 18 12:53:35 LetoThe2nd: Yep, already do that with a few other options, I'll double check, but if there is a handful of options I can just write a simple pre-compilation script that changes the appropriate option Feb 18 12:54:18 I think doing that and then git reset is easier :) Feb 18 12:54:34 As long as it is documented *somewhere* Feb 18 12:57:34 i really don't get what makes people avoid debug distros. most behave like they would spread some infection. Feb 18 13:02:31 wertigon: how would this pre-compilation script be selected then? it has to be from within the kernel recipe Feb 18 13:03:39 qschulz: i fear he's talking about a manual process. like "you want a debug image? here, its only those tiny 18 steps you need to do, totally not error prone, nothing has ever failed. and best, all without a debug distro!" Feb 18 13:05:28 btw, do we have to create a TOPDIR/TMPDIR for each combo of distro and machine ? Feb 18 13:07:00 kyanres: not sure to understand? distro and machines are already clearly separated in TMPDIR Feb 18 13:07:57 kyanres: for building, no. but you can't set multiples in local.conf, so you would either have to resort to passing via ENV or changing local.conf between builds. Feb 18 13:15:18 thanks Feb 18 13:15:26 qschulz, Well, I don't know where I got that information, but I tought I had to create a TMPDIR for each machine. Feb 18 13:15:55 actually, in https://docs.yoctoproject.org/dev-manual/common-tasks.html#setting-up-and-running-a-multiple-configuration-build Feb 18 13:15:56 Suggested practice dictates that you do not overlap the temporary directories used during the builds Feb 18 13:17:12 kyanres: a multiconf build is something completely different. Feb 18 13:18:30 kyanres: and it certainly doesn't hurt to use multiple TMPDIRs, but for building several combinations sequentially, it at least shouldn't be problematic to stick with one (for standard usecases/environments) Feb 18 13:19:26 oh? different from having several TOPDIR and calling oe-init-build-env ? how so ? Feb 18 13:20:01 nanana. Feb 18 13:20:28 no multiple environments. thats not what we were talking about. Feb 18 13:20:52 kyanres: for building, no. but you can't set multiples in local.conf, so you would either have to resort to passing via ENV or changing local.conf between builds. Feb 18 13:20:59 thats what i wrote. Feb 18 13:21:44 so you could do MACHINE=machine1 DISTRO=distro1 bitbake my-image. and once that is finished, you do MACHINE=machine2 DISTRO=distro1 bitbake my-image Feb 18 13:22:14 and so on, and so on. but sharing TMPDIR between several build environments, nope, don't do that. Feb 18 13:23:42 okay Feb 18 13:24:42 but in the end its mostly cosmetic anyways, or depending on your workflow. this won't save diskspace or time noticeably, thats all in sstate. Feb 18 13:25:07 by build environment, you mean TOPDIR ? version of bitbake ? Feb 18 13:25:58 build environment == the directory that you create by oe-init-build-env. Feb 18 13:26:34 i guess that equivalates to TOPDIR, but i've never noticed anyone using that expression. Feb 18 13:26:52 okay. yeah I wouldn't dare go that far Feb 18 13:28:33 systemd do compile Feb 18 13:28:33 erro Feb 18 13:28:34 RPATH changes at install time disabled Feb 18 13:28:34 Mmedaliyou 14:27:17and its a meson_do_install Feb 18 13:28:35 in the do_install() Feb 18 13:28:35 Welcome to freenode. To protect the Feb 18 13:29:11 LetoThe2nd, qschulz: Yep, manual for now - sometimes it's better to do stuff for hand :) Feb 18 13:29:22 But I agree it's the least ideal solution Feb 18 13:29:52 Idea is you call the script, build the image, run git reset Feb 18 13:30:55 wertigon: assume users are dumb and will either forget or do weird things. Feb 18 13:31:02 and you need to maintain this script Feb 18 13:31:05 * LetoThe2nd shrugs Feb 18 13:31:20 folks Feb 18 13:31:24 i think that way is outright stupid. but hey, its not mie to support it, so go go go. Feb 18 13:31:40 can i get some help please Feb 18 13:31:51 why systemd: do_compile() crasher Feb 18 13:31:53 crashes Feb 18 13:32:58 medaliyou: sorry, but we are not responsible for support upon request. if you've got a problem that somebody knows something about, then that person will answer. if not, then its bad luck, but still not our problem. Feb 18 13:33:41 you re right, helping is optional (y) (y) Feb 18 13:33:42 medaliyou: as systemd happily builds on hundreds of systems and thousand of combinations in poky each day, i'd guess hte problem is yours alone. strip the build down, isolate, reproduce. good luck. Feb 18 13:34:13 Hey all. Do you know of any nice way to build multiple gcc runtimes in the same build? Feb 18 13:34:58 ptsneves: 1) copy the recipes 2) change slightly the name of the second recipe so that it does not match the first 3) profit Feb 18 13:36:05 qschulz: 3) change the slight name changes to something funny but completely pointless, like wonderful_1.2.3.bb, fancy_2.3.4.bb and superduper_4.3.2bb Feb 18 13:36:07 I like the profit part Feb 18 13:36:11 qschulz  yeah that is what I do with userspace recipes but gcc-runtime sounds trickier. Is is safe to have the runtime of GCC9 built with GCC10, so that GCC9 can use it? Feb 18 13:36:17 4) profit and hanve fun Feb 18 13:37:01 sorry, step 4) is "run away and never look back" Feb 18 13:37:51 eeheh yeah the profit and never look back part have a tendency of catching me in the back :D Feb 18 13:38:32 mcfrisk: nope, seriously. if the asker does that we can all have profit in laughing on him/her. Feb 18 13:38:41 ptsneves: didn't run fast and far enough Feb 18 13:38:48 so i think thats an outright awesome way! Feb 18 13:44:03 @qschulz: Probably, yeah. Not a good solution but it's this or having to spend 4 hours cursing at the screen... Feb 18 13:44:19 Maybe a new distro is the way to go soon though Feb 18 13:44:35 wertigon: cp poky.conf conf/layer/opky-debug.conf Feb 18 13:44:51 ❯ cat systemd_%.bbappend Feb 18 13:44:51 do_install_append() { Feb 18 13:44:52     rm ${D}${sysconfdir}/systemd/system/getty.target.wants/getty@tty1.service Feb 18 13:44:52 } Feb 18 13:44:53 CAN YOU PLEASE EXPLAIN WHAT DOES THIS LINE DO ???? Feb 18 13:45:33 medaliyou: sure! its a neat trick we use to make sure the caps lock keys of poky users are tested. Feb 18 13:45:39 medaliyou an error? Feb 18 13:45:53 LetoThe2nd :D :D :D Feb 18 13:46:07 yeah when i commented th rm ... line Feb 18 13:46:13 medaliyou: ask the one who wrote the bbappend. Feb 18 13:46:15 bitbake systemd finally passed Feb 18 13:46:35 medaliyou: seems to disable automatic startup of tty1 service. Feb 18 13:46:35 medaliyou: there are no bbappend for systemd in official layers AFAICT Feb 18 13:46:54 c.f. https://layers.openembedded.org/layerindex/recipe/5979/ Feb 18 13:46:59 oh sorry i saw mv and not rm :D Feb 18 13:47:31 medaliyou: seriously: go pester those folks who provided you layers that give trouble. Feb 18 13:49:26 i'm just doing a 6 months internship for my end of studies project, i m working with a company that hired a freelancer to create their linux for imx board Feb 18 13:51:11 medaliyou: then tell your supervisor that the stuff is outdated, you're having troubles, whatever. but essentially you're demanding that people here help you fixing stuff for free, that the company is being cheap on. or is that some opensource,openhardware project we can all profit on? Feb 18 13:52:16 medaliyou: opinions may of course differ. but that is mine, and i am speaking just for myself here (that needs to be clear, my opinion is neither representative of this channel nor the YP) Feb 18 13:52:38 medaliyou: bitbake -e systemd, then inspect the output and figure out where this bbappend is and change it. there are endless possibilities to shoot oneself to foot with yocto and bitbake. we talk here of upstream yocto, if you add custom layers we can't really help except provide general guidance Feb 18 13:52:59 mcfrisk: s/foot/brains/g Feb 18 13:54:49 My task is to optimize boot time, and i didn't even get a build work to flash the image to the IMX  board yet. I  m just trying to learn & improve myself here, and i only ask you huys when i got stuck after long search time. And yeah that project seems so outdated and it is not open source . Feb 18 13:56:18 medaliyou: well then i kinda feel sorry for you, and i wish you good luck. but i probably won't be of much help because i'm not going to work for free for that company (which i would basically do then) Feb 18 13:57:18 medaliyou: you need to start by reproducing your compamny build, we can't help that here. general guidance, then run systemd-analyze and look what takes long and why. also look at bootloader and kernel. generic linux guides help: 2nd google hit is https://elinux.org/images/6/64/Chris-simmonds-boot-time-elce-2017_0.pdf Feb 18 13:59:43 good afternoon, Feb 18 14:01:11 you ve already offred me much help , thank you a lot guys Feb 18 14:01:31 am working with branch warrior (open-amd) and I was wondering wht is th esafest way to upgrade the version of mosquitto which is pulled as part of openembedded as our software requires 1.6.12 and openembedded/meta-networking/recipes-connectivity/mosquitto pulls 1.5.8 Feb 18 14:01:57 intera91: new recipe? Feb 18 14:02:12 copied recipe? Feb 18 14:02:28 resarted from scrtch as bsp is AMD v1000 Feb 18 14:02:28 intera91: http://cgit.openembedded.org/meta-openembedded/tree/meta-networking/recipes-connectivity/mosquitto/mosquitto_1.6.12.bb?h=gatesgarth Feb 18 14:02:50 intera91: https://layers.openembedded.org/layerindex/branch/master/recipes/ Feb 18 14:05:00 qschulz:  https://layers.openembedded.org/layerindex/recipe/85578/  mentions that gatesgarth pulls 1.6.12 but warrior pulls 1.5.8 Feb 18 14:05:11 intera91: then backport it? Feb 18 14:05:50 qschulz: indeed  my intention but what is the safest way to do that Feb 18 14:06:45 intera91: ???? just download the recipe and the patches it rquires? Feb 18 14:07:51 i'll giove that  a try but the recipe uses ${PV} as version, how is that value initialised? Feb 18 14:09:16 from the filename of the recipe Feb 18 14:09:38 How can I inject DL_DIR and SSTATE_DIR or MIRROR into oe-selftest ? Feb 18 14:10:05 there's really nothing more than getting the files from a new layer in most cases. No changes involved. If it does not compile, only then you dig deeper Feb 18 14:10:42 dl9pf: If you set then in your build dir in advance it should reuse them Feb 18 14:11:03 the dir where the toplevel project is ... ok Feb 18 14:11:42 looking at the SDE now Feb 18 14:13:56 dl9pf: want me to trim down your other patch and queue it? Feb 18 14:20:31 i can split it ... sec ... Feb 18 14:26:06 done Feb 18 14:27:10 dl9pf: thanks, can get that one in the queue :) Feb 18 15:01:45 Anyone thought about trying to detect unused variables, if limited by file? i.e. a recipe level linter, iterate over the lines of the file and its appends and identify which of those weren't present in the final result for those variables, and checksum the tasks to identify which vars were unused in those, to potentially detect possible typos? Feb 18 15:07:17 kergoth yes, but if the variable is exported you have no way of knowing if it is used by any script in the task for example, so you would need to limit it to bitbake vars correct? Feb 18 15:15:58 ptsneves: yeah, it'd have to have limitations to avoid a ridiculous number of warnings, but at least if you typo SRC_URI as SRC_URO or something it'd warn you :) Feb 18 15:17:52 yeah, in that direction i would say it would really help 40% of the cases of newbies being confused Feb 18 15:18:08 so maybe starting by a typo detector would be nice Feb 18 15:18:30 like a string distance of something not known to the parse output to a given variable. Feb 18 15:22:21 I think we could have a look at all variables in tasks' sigdata? Feb 18 15:23:38 There's a *lot* of variables that are unused from e.g. bitbake.conf Feb 18 15:25:07 You might want to limit it to only variables defined in the current bb file, but I think know that would require parsing with variable tracking information (maybe?), which we don't normally do Feb 18 15:30:07 well all the info we need should be available from bitbake -e Feb 18 15:30:13 as it says wehre the variables are set Feb 18 15:34:42 Hi, I have a question regarding contributing patches Feb 18 15:35:45 I have a patch for poky: meta/recipes-sato/webkit/wpebackend-fdo_1.4.1.bb, from what I understand I should post it to openembedded-core? Feb 18 15:36:41 yup, poky/meta is openembedded-core Feb 18 15:37:39 My patch is against dunfell, should I post it as a patch on-top of dunfell-next? Feb 18 15:38:45 zbodek. if it is version specific, you'd send it against dunfell (commenting that it is already fixed in master due to a newer version), or you must send it against master first and ask for a backport to dunfell. Feb 18 15:38:48 Anyone tried running toaster on other-than-ubuntu lately? I tried on Centos8 and got an error right off the bat. Feb 18 15:45:16 zeddii: thanks. I don't think it is fixed in the latest version. I'm only using dunfell and from what I see master only has package version bumped up. I will try to build master and see what's happening Feb 18 15:47:26 yah. that's the trick with LTS. There's an extra hoop to jump through on fixes, since the project has a master first policy. Otherwise, the branches would diverge and have completely different sets of issues. Feb 18 15:47:35 thanks for the extra effort! Feb 18 15:48:08 np Feb 18 15:50:17 is there any known problem between ccache and meta-arm-toolchain ? On the kernel I'm seeing scripts/Kconfig.include:40: linker 'ccache aarch64-shadow-linux-ld.bfd --sysroot=.../recipe-sysroot' not found (which I did not have before starting to switch from the vendor meta-rockchip to the yoctoproject.org meta-arm-based one) Feb 18 15:50:46 (and without too much surprise, disabling ccache does work) Feb 18 15:50:51 meta-arm-toolchain isn't used unless you select it Feb 18 15:53:57 ptsneves: Ya the variable tracking information isn't normally collected when parsing recipes (it's enabled when you run bitbake -e), possibly as a performance optimization? Feb 18 15:59:29 at least meta-rockchip requires the meta-arm layer, which in turn requires meta-arm-toolchain Feb 18 16:00:05 I admit I have another change that can't be ruled out so fast: I upgraded the poky layer to 3.2.2rc1 Feb 18 16:00:56 oh and that's not the end of the problems, as I'm now hitting ".../arch/arm64/boot/fitImage: No such file or directory" Feb 18 16:01:42 I'd' better split that upgrade in two :) Feb 18 16:05:35 yann: its a layer dependency as firmware needs the binary compilers, but adding meta-arm-toolchain doesn't change anything out of the box Feb 18 16:05:55 I'd definitely split your changes into two :) Feb 18 16:06:27 is it really useful to have a layer dependency for something that's not used out of the box ? Feb 18 16:06:56 it is used out of the box if you build trusted-firmware-a Feb 18 16:07:43 qschulz, We've only had a cert for git.openembedded.org. cgit.openembedded.org is an old cname record. Do you need to use that domain name? Feb 18 16:07:49 yeah, I was overly optimistic trying to avoid doing 2 full rebuilds - I'll take my time :) Feb 18 16:14:47 RP JPEW was anyone looking at the watchdog reprod failure? stupid irc client can't search and i'm sure I saw that come up Feb 18 16:17:47 halstead: not really no, my browsing history is full of them though :D can we redirect cgit.oe.org to git.oe.org? is there a reason for keeping cgit? Feb 18 16:17:55 rburton: I think I fixed that didn't I? Feb 18 16:18:12 ah yes so you did Feb 18 16:18:21 i was just doing a bit of triage on the pending swat list Feb 18 16:18:54 qschulz: I'm not sure. I'll make it a redirect though. Feb 18 16:19:29 hello, what is the best way to build two different kernels for same machine in the same build directory Feb 18 16:19:39 ? Feb 18 16:20:24 I need one with integrated initramfs for testing and one without for final raw NAND UBI image generation Feb 18 16:22:18 halstead, qschulz, if you search "git.openembedded.org" in https://layers.openembedded.org/layerindex/branch/master/layers/, all the "Repository" URLs say git, but their web repo and tree actually point to cgit Feb 18 16:24:04 kyanres: oh. I could change that before making the redirect. Feb 18 16:27:35 kyanres: thanks, was wondering where I got the links from :D Feb 18 16:28:03 eduardas: two different distros then Feb 18 16:30:47 qschulz: but two different distros means two build directories, no? Feb 18 16:38:22 eduardas: as I was taught recently ;), you can >> MACHINE=machine1 DISTRO=distro1 bitbake my-image. and once that is finished, you do MACHINE=machine2 DISTRO=distro1 bitbake my-image Feb 18 16:40:26 er. distro2 for the second command Feb 18 16:47:46 hello guys ! I've three network interfaces and I want to have therir names be unique Feb 18 16:47:58 so that eth0 always refer to eth@xxxxxx Feb 18 16:48:09 and eth1 refers to eth@yyyyy Feb 18 16:48:29 how can I do that in Yocto ? Feb 18 16:52:46 rburton: at least it's not the update to 3.2.2 which breaks the kernel build :) Feb 18 16:53:30 thekappe: write the udev/systemd/whatever rules, and put them in a package, and put the package in your image Feb 18 16:57:32 rburton: ah, thanks. Would you want to reply to this swat email? Feb 18 17:02:06 kyanres: thank you. I was not aware of that possibility. Feb 18 17:02:46 rburton, thanks, I'll look into that Feb 18 17:29:17 kyanres: I have taken a closer look at the Yocto documentation. Isn't multiconfig what I should really want for my usecase? Feb 18 17:59:13 eduardas: erm, maybe ? I'd say both ways allow to build with different distros, but take note that I'm new Feb 18 17:59:39 anyone else has infos about that ? Feb 18 18:01:06 Hi guys, I have a question. I'm new to yocto and I want to use an external toolchain to build my image. I'm using arm-linux from ARM so not sourcery, nor linaro. Is there a way to do it ? Feb 18 18:03:09 RP: just curious, has anyone expressed interest in a recipe for the split out xwayland yet? Feb 18 18:05:20 smurray: not seen it Feb 18 18:07:12 RP: they're pulling it out of xorg since it's the only part people plan to use going forward with wayland, rc is out now: https://lists.freedesktop.org/archives/xorg/2021-February/060615.html Feb 18 18:33:10 * zeddii is going back to mwm and old school exterm. Feb 18 18:33:16 s/ex/x/ Feb 18 18:36:32 smurray: patches welcome :) Feb 18 18:43:23 rburton: heh, indeed. I might take a crack at it after I get a couple more CVE fixes for dunfell squared away Feb 18 18:47:18 that does kind of encourage the effort to move away from xorg Feb 18 18:56:17 rburton: yeah. I'd not be surprised to see e.g. Fedora not ship xorg at all in 2022/2023 Feb 18 18:57:13 It's annoyingly hard to find a simple embedded focus wayland compositor... lipstick is *really* close, but it uses Qt :( Feb 18 19:16:27 It seems to me that if I just put my multiconfig directory into my template directory, these files do not get copied over when using the TEMPLATECONF variable with the oe-init-build-env script Feb 18 19:17:06 Can one even copy over multiconfig config files from template directory when using TEMPLATECONF? Feb 18 19:24:37 I'm still trying to fix the compilation of systemd with importd support. I've added support for glib and apparmor so now I have all Run-time dependencies found, but the compilation still fails Feb 18 19:25:21 meson-log.txt still shows a bench of "Program foo found: NO", should all of them be added to the image as a dependency as well? Feb 18 19:28:38 vdl: No, they need to be in `DEPENDS` Feb 18 19:29:12 vdl: Either directly or through `PACKAGECONFIG` Feb 18 19:29:48 eduardas: I don't know if that works.... it might be easier just to put the multiconfigs in a layer? Feb 18 19:30:52 JPEW: my multiconfig files are in a layer, in the same directory I store my templates for distro + machine combinations. Not sure what you mean Feb 18 19:31:54 JPEW: I have a meta-mylayer/conf/templates/setupA and meta-mylayer/conf/templates/setupB Feb 18 19:32:39 eduardas: If you put them in meta-mylayer/conf/multiconfig/mc.conf bitbake should be able to find them Feb 18 19:32:48 TEMPLATECONF="${PWD}/sources/meta-mylayer/conf/templates/setupA/" . ./sources/poky/oe-init-build-env build Feb 18 19:32:59 This is how I usually setup my build directory Feb 18 19:33:48 JPEW: will try it. I was putting them under /sources/meta-mylayer/conf/templates/setupA/multiconfig Feb 18 19:34:02 I need multiconfig only for one of my setups Feb 18 19:34:21 If I do it your way, this will become universal for all setups? Feb 18 19:34:32 eduardas: correct Feb 18 19:34:47 seems kinda inflexible Feb 18 19:35:05 eduardas: Depends on what you are going for I suppose :) Feb 18 19:35:57 JPEW: I see, things like kmod can be added both as PACKAGECONFIG or a DEPENDS package. What's the best approach to fix compilation issue like this? PACKAGECONFIG first? Feb 18 19:36:17 Also finding which package provides which function is tricky Feb 18 19:36:53 I'd really like there to be a way to specify the entirety of the build directory config directory contents in one place. That kind of would seem more obvious, at least for me. Feb 18 19:37:06 vdl: Ya, you actually only need the recipe (.bb file), not the package Feb 18 19:37:34 vdl: You would put it in PACKAGECONFIG if the dependency is tied to an optional PACKAGECONFIG, DEPENDS if it's needed all the time Feb 18 19:37:56 One can always do custom setup scripts, but I'd really like to avoid those. Feb 18 19:39:12 eduardas: I'm not a huge fan of TEMPLATECONF because it doesn't update after the first time. e.g. if person A updates the template, there is no way for person B to get the update (or even know they need one without looking at the history) unless they delete what they currently have Feb 18 19:40:07 JPEW: yeah, good point. My colleagues have already stumbled on that one as it is non-obvious. Feb 18 19:41:04 eduardas: We wrote this to try an solve the "product management" problem: https://github.com/garmin/whisk Feb 18 19:41:05 though because BBMULTICONFIG won't be defined for all local.conf.sample files, I guess what you suggested should be fine Feb 18 19:42:56 JPEW: really interesting. haven't heard about it, so really useful to know Feb 18 19:43:28 JPEW: does this have overlap from a functionality perspective like siemens kas ? Feb 18 19:43:47 JPEW: so I've fixed the "Run-time dependency X found: NO" error, I'm looking at the "Program X found: NO" errors, should I worry about the "Compiler for C supports arguments -WX: NO" errors? how to tackle this? Feb 18 19:44:15 (explicitly "-Wno-error=#warnings -Werror=#warnings" and "-Wno-string-plus-int -Wstring-plus-int") Feb 18 19:49:05 eduardas: Probably overlaps with kas Feb 18 19:54:14 vdl: Probably don't need to worry about the compiler argument checks Feb 18 20:04:59 eduardas: I'm not using it but kas supports specifying multiconfig, if that's needed. (otherwise 2 kas files are often just fine) Feb 18 20:06:32 vdl: thanks. good to know too Feb 18 20:06:32 I've build an os with nft, and I can not set the network tables up Feb 18 20:07:28 I posted this in #poky, now posting here. Feb 18 20:07:29 eduardas: since configuration format version 5 to be precise: https://kas.readthedocs.io/en/latest/format-changelog.html#version-5 Feb 18 20:07:40 it says that "prerouting" can not be processes, since "No such file or directory" Feb 18 20:07:48 what am I missing from the os? Feb 18 20:08:54 Apparmor build started to fail for us on dunfell branch. It was working fine yesterday, so some change broke that (and it's definitely not our change) Feb 18 20:09:02 here are the logs https://gist.github.com/om26er/8e0ab28f79f3807b9a28b6c203860bbf Feb 18 20:09:38 armpit is that something you are aware of ? (looking at meta-security, it seems you wrote the Apparmor recipe) Feb 18 20:21:13 is it ok, that nftables package does not contain the nftables service script for SysV Feb 18 20:33:43 JPEW: my systemd-importd compilation failure is down to this, not sure what to tackle next: http://ix.io/2PTx Feb 18 20:51:20 ok, I have reported https://bugzilla.yoctoproject.org/show_bug.cgi?id=14239 Feb 18 21:01:49 vdl: Which one is the fatal error? Feb 18 21:02:17 JPEW: I cannot tell, that meson-log.txt isn't very explicit Feb 18 21:03:58 JPEW: I meant the "fatal" line is this... Feb 18 21:04:00 "meson.build:1265:16: ERROR: Problem encountered: importd support was requested, but dependencies are not available"... Feb 18 21:06:17 vdl: Hmm, you may need to log at the meson.build file and figure out which dependencies are actually required Feb 18 21:06:35 vdl: Or maybe diff the log file with and without importd support Feb 18 21:23:23 I have some basic question Feb 18 21:23:29 where are the init files from? Feb 18 21:23:43 I can't find in any log file, where it is downloaded Feb 18 21:45:44 dl9pf: Did you make any progress? Feb 18 21:46:17 smurray: interesting. Its something we'd want a recipe for Feb 18 21:53:36 i got it coded, but selftest still runs locally Feb 18 21:53:47 waiting for result Feb 18 22:04:21 dl9pf: fair enough, sounds promising! :) Feb 18 22:55:19 zeddii: can you spot any race that would explain https://autobuilder.yoctoproject.org/typhoon/#/builders/23/builds/3321/steps/13/logs/stdio ? Feb 19 01:33:13 RP: sorry. was away for a bit. We haven't seen make-mode-scripts race in quite some time. That is very strange. do_configure depends on the do_shared_workdir, so I can't see how the .config hadn't landed by the time it ran. **** ENDING LOGGING AT Fri Feb 19 02:59:57 2021