**** BEGIN LOGGING AT Tue Dec 15 02:59:57 2020 Dec 15 07:25:51 Hi! is it possible to generate ESDK for offline usage, so that it packages all the dl_dir? if it is, which parameters should be used. Just add BB_NO_NETWORK = "1" to the /conf/sdk-extra.conf ? Dec 15 08:18:08 good morning Dec 15 08:29:00 yo dudX Dec 15 09:09:37 seems like the -o argument is missing from ps in busybox, and I can't really see an option for it in the defconfig Dec 15 09:11:12 oh my bad Dec 15 09:32:57 dosfstools was skipped: it has an incompatible license: GPLv3 Dec 15 09:33:03 oops. how do I get around this one :) Dec 15 09:33:19 /poky/meta/recipes-core/packagegroups/packagegroup-base.bb RDEPENDS on or otherwise requires it Dec 15 09:36:54 hm doesn't work to put it in BAD_RECOMMENDATIONS Dec 15 09:38:50 I want the kernel modules but not the utility Dec 15 09:40:46 oh they go for entire package names Dec 15 10:26:56 hello, I am using zeus with "default" base-files and systemd packages. I have added some additional files and configuration + volatile bind for some systemd folders Dec 15 10:27:22 i am using ro file system (whole root is squashfs) Dec 15 10:28:41 i have a problem with /var/volatile/log and /var/volatile/tmp folder not created by systemd-tmpfiles Dec 15 10:31:57 which makes links /var/log and /var/tmp broken Dec 15 10:47:03 from the logs i see that 00-create-volatile.conf is being processed, but i get an error when var/volatile/log file is being created Dec 15 10:51:20 Nov 16 20:42:40 ct-made systemd-tmpfiles[200]: Failed to determine whether '/var/volatile/log' is below autofs, ignoring: No such file or directoryNov 16 20:42:40 ct-made systemd-tmpfiles[200]: Running remove action for entry d /var/volatile/logNov 16 20:42:40 ct-made systemd-tmpfiles[200]: Failed to determine whether '/var/volatile/tmp' is below Dec 15 10:51:21 autofs, ignoring: No such file or directoryNov 16 20:42:40 ct-made systemd-tmpfiles[200]: Running remove action for entry d /var/volatile/tmp Dec 15 11:09:43 could some one point me what could be a problem? Dec 15 11:57:07 Hello, I'm very new to using yocto. There's one basic thing I'm trying to do and for which I struggle. I have installed the BSP for my board and I have been able to run a build of the default image for it. Now I need to add a few options to the linux kernel. I have added a KERNEL_DEFCONFIG in my local.conf that points to a file that is the original kernel configuration, together with a few modifications (I changed a few things to =y). My Dec 15 11:57:07 problem is that whenever I re-run bitbake to re-build my image, the kernel doesn't have those new options enabled. What could I be missing here ? Dec 15 12:30:10 Fanfwe: you can't change kernel config in local.conf you need to bbappend your modification Dec 15 13:02:14 Good morning. I asked about a python3 issue when building dunfell a couple of days ago and got no answer so trying again as my investigation failed. Summary on Stack Overflow: https://stackoverflow.com/q/65178174/414817 Dec 15 13:22:33 mansi: is not clear what are you trying to do inside tmp/work, scary Dec 15 13:46:30 mckoan: I'm trying to debug the issue to figure out what line causes the illegal instruction. So basically using devshell to set up the environment and then manually running the first lines of setup.py one by one to see where it fails. Yes it's scary but I had no other idea as log files didn't provide much to go on. Dec 15 13:50:13 mckoan: added the original output of log.do_compile to question to better clarify this. Dec 15 14:09:12 zeddii: Looks like I was wrong yesterday, 5.10.1 changes were reverts of md raid changes not btrfs specific: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=linux-5.10.y Dec 15 14:32:43 hi, i am getting weird error while booting from ro rootfs while creating needed files in /var/volatile/log Dec 15 14:32:46 Nov 16 20:42:40 ct-made systemd-tmpfiles[200]: Failed to determine whether '/var/volatile/log' is below autofs, ignoring: No such file or directoryNov 16 20:42:40 ct-made systemd-tmpfiles[200]: Running remove action for entry d /var/volatile/logNov 16 20:42:40 ct-made systemd-tmpfiles[200]: Failed to determine whether '/var/volatile/tmp' is below Dec 15 14:32:47 autofs, ignoring: No such file or directoryNov 16 20:42:40 ct-made systemd-tmpfiles[200]: Running remove action for entry d /var/volatile/tmp Dec 15 14:32:57 have you ever seen this problem? Dec 15 14:33:20 This is clean zeus systemd startup with clean base-files package Dec 15 14:33:44 same happens to /var/volatile/tmp Dec 15 14:35:38 and since /var/log is linked to /var/volatile/log, services have problem with startup Dec 15 14:36:01 this also make syslog to be printed in console since var/log/messages cannot be created Dec 15 14:37:29 i have been able to fix it by adding service which runs before systemd-tmpfiles service and just do mkdir -p /var/log/volatile but i would like to avoid using it and use clean solution Dec 15 14:59:31 RP: and now shockingly, my musl build worked with the new libc-headers overnight. I'm seeing one stap issue, but otherwise, I need to do performance/rt testing, ping about getting the h/w references updated and 5.10 is in good shape. Dec 15 15:02:58 zeddii: great news :) Dec 15 15:03:06 * RP wonders what surprise is lurking Dec 15 15:03:29 that's what I figure. I'll start some AB runs shortly, probably to find out I'm building 5.4 locally :P Dec 15 15:03:57 zeddii: its sad we have such distrust of software isn't it :) Dec 15 15:04:27 absolutely. I only ever think that something is working "for now" :D Dec 15 15:57:59 * paulg sheds a tear for the mcp8315-rdb Dec 15 15:59:14 think they (fsl 83xx reference boards) came out around 2005-ish? Dec 15 15:59:46 not sure what one would use for an updated hw ref on ppc today.... Dec 15 16:00:29 yah. we tried a few times, but found nothing reasonable (availability or price). long live new architectures :D Dec 15 16:15:30 paulg: I thought the loss of the mpc was ancient history now! :) Dec 15 16:16:35 vmeson: the tsc is pondering if the valgrind ptest is worth the effort? ;-) Maybe we should disable bits of it? Dec 15 16:16:48 cough delete cough Dec 15 16:17:06 rburton: slayer of code :) Dec 15 16:18:27 I was late to YPTM, was it really short or cancelled? Dec 15 16:18:48 short Dec 15 16:18:53 rburton: okay, thanks Dec 15 16:19:57 reminds me. Need to nuke the sbc85xx/86xx from the kernel once the merge window is done. Dec 15 16:20:36 haven't had the hardware to test those for ~5y or so, I'd guess. Dec 15 16:30:04 and I spent the enire prelude part of the meeting jiggling with my headset/audio only to notice I had turned the volume down (not muted, just near zero) Dec 15 16:30:20 so I heard "and that's about it" from RP Dec 15 16:31:01 moto-timo: its in the status report, you didn't miss much Dec 15 16:31:46 RP: thanks :) Dec 15 18:07:52 Hi, I'm building a go software using go modules on dunfell. When it tries to rebuild, I can't delete the vendor folder unless I use sudo. Did someone had this issue? Dec 15 18:50:24 dakhoya: I have seen the same problem but have not tracked it down... for me it was only one of the vendored libs... protobuf I think Dec 15 18:51:39 @moto-ti Dec 15 18:51:51 @moto-ti Yes its that issue that I have Dec 15 18:52:36 specifically it was this recipe: https://github.com/moto-timo/meta-virtualization/blob/timo/k3s-wip/recipes-containers/k9s/k9s_git.bb Dec 15 18:53:13 I suspect there is something wrong with upstream file permissions, but I am not a go expert Dec 15 18:53:58 I can build k9s the first time (and it is functional), but any rebuild throws an error like you are seeing Dec 15 18:54:21 I think go clean -modcache should be used when cleaning a recipe that use module Dec 15 18:54:38 if that works, you should submit a patch :) Dec 15 18:55:02 go handle the permission for those files. I just wanted to know if it was already integrated with the current go class Dec 15 18:55:11 *in yocto Dec 15 18:55:36 it should probably be in the gomod bbclass http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/go-mod.bbclass Dec 15 18:55:55 we are probably fighting pseudo for file permissions... but that is just a hunch Dec 15 18:56:13 GOBUILDFLAGS_append = " -modcacherw" Dec 15 18:56:22 ill try with this Dec 15 18:56:40 let me know, you are solving a problem that annoys me :) Dec 15 18:57:20 (and is preventing me from contributing the k9s recipe that OutBackDingo and others would like to have in meta-virt) Dec 15 18:57:23 same I got few apps in go now and its a mess when updating the packages Dec 15 19:40:14 RP: need a bit of help. Half the AUH upgrades failed with: Dec 15 19:40:14 ERROR: When reparsing /home/pokybuild/yocto-worker/auh/build/build/poky/meta/recipes-core/os-release/os-release.bb:do_compile, the basehash value changed from c4de0c32ccdaaf98033b2650c9c04c2cef325cab67ada6a6d4ba091ecbd6674b to 68987924e164c89da36a7e50fafc5ce233b6b24e03bc14fbc164270bb0aa1fb2. The metadata is not deterministic and this needs to be fixed. Dec 15 19:40:14 ERROR: The following commands may help: Dec 15 19:40:14 ERROR: $ bitbake os-release -cdo_compile -Snone Dec 15 19:40:14 ERROR: Then: Dec 15 19:40:14 ERROR: $ bitbake os-release -cdo_compile -Sprintdiff Dec 15 19:45:26 * zeddii finally chimes in on all the "split every package into a zillion binaries patches" Dec 15 19:48:44 moto-timo: I think I finally have a better thread to tug on for the k3s thing Dec 15 19:49:17 RP: somehow putting the revision into DISTRO_VERSION still isn't working quite right, but I am failing to see how, and why it only happened during AUH run Dec 15 19:55:01 I feel like the "beaglebone" machine from meta-ti is incomplete, but "beaglebone-yocto" from meta-yocto-bsp isn't supposed to be used for production because it's just a reference platform. What's the best practice here? Should I tweak beaglebone-yocto in my custom layer? Should I create a machine conf from scratch requiring beaglebone.conf (from meta-ti) and copy most conf from Dec 15 19:55:03 beaglebone-yocto.conf? Dec 15 20:03:51 kanavin_home: i was just about to ping you about that Dec 15 20:04:14 v0n: fix whats missing from the beaglebone in meta-ti Dec 15 20:04:47 v0n: when I did a beaglebone black based system a few years back (which had a custom board it mated to) I ended up taking some content of the meta-ti machine and making a custom one (in particular, I needed custom kernel & u-boot versions for my hardware/application) Dec 15 20:05:46 codyps: this is exactly what I'm doing, creating a distro for a beagleboneblack + custom daughter board Dec 15 20:07:02 I am surprised that the beaglebone.conf from meta-ti doesn't include UBOOT_LOADADDRESS and such, since it is machine specific, it feels weird to copy/paste it from beaglebone-yocto and not requiring that from somewhere Dec 15 20:11:23 v0n, rburton: https://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/conf/machine/include/ti33x.inc#n45 Dec 15 20:13:20 denix: ho, correct. Why is beaglebone-yocto.conf defining UBOOT_* and KERNEL_* again? Dec 15 20:15:01 v0n: beaglebone-yocto.conf in meta-yocto-bsp doesn't use any meta-ti defines Dec 15 20:17:13 denix: ho correct. But it could've added meta-ti to bblayers and used 'require conf/machine/beaglebone.conf', right? I guess it's just a design choice to limit dependencies? Dec 15 20:18:12 v0n: meta-yocto-bsp is a reference BSP (i.e. just an example) and is not supposed to depend on any other BSPs Dec 15 20:18:28 this is what I meant Dec 15 20:19:08 it would've been clearer to split the "beaglebone" specific conf in an include file but well, it's a refernce Dec 15 20:23:35 codyps: how did you organized the DTS for your daughterboard? a file to include or a complete new dts? Dec 15 20:25:31 v0n: include files are useful only when used from more than one place. meta-ti defines ti33x.inc file with common entries for the entire SoC family, as there are multiple platforms in that family besides beaglebone. on the other hand, meta-yocto-bsp has no other platforms to share anything with beaglebone-yocto, hence no .inc file needed Dec 15 20:28:10 denix: I understand. My point was that as a reference platform, it would've been clearer for the new user to distinguish what is really hardware related in the configuration from what is more a reference choice (like the PREFERRED_PROVIDER_virtual/xserver or QB_* for qemu support) Dec 15 20:28:47 denix: but I agree with you for our own projects Dec 15 20:32:03 v0n: PREFERRED_PROVIDER and PREFERRED_VERSION are normally considered part of a Distro config, not a BSP config. a BSP may weakly assign those as a recommendation, but it is expected that a Distro or a user have the final decision in those Dec 15 20:32:28 v0n: but UBOOT_ and KERNEL_ settings are usually BSP and platform specific Dec 15 20:34:04 I know Dec 15 20:35:40 ho I didn't see your comment on PREFERRED_*, got it. Indeed they are defined as ?= Dec 15 20:41:39 v0n: even if they are not ?= they can be easily overwritten by a Distro, as ${MACHINE}.conf is parsed before ${DISTRO}.conf - https://git.openembedded.org/openembedded-core/tree/meta/conf/bitbake.conf#n756 Dec 15 21:12:40 zeddii: did comparing the binaries help at all? Dec 15 21:15:36 v0n: the entire point of the beaglebone-yocto machine is to actually work on the beaglebone but be standalone and do just enough to be useful. nobody is expected to actually use it. Dec 15 21:17:15 as I said a couple days ago, you should be using vendor layers to build products Dec 15 21:17:37 but the core layers should not be trying to keep up with vendor churn... Dec 15 21:59:31 v0n: iirc, I created a new dts within my linux kernel for my board (which was bbb + extra hw). It included some existing dts for the beaglebone black (or maybe just the am335x, don't recall). Dec 15 21:59:52 that is "#include"ed, to be clear. Dec 15 22:00:49 so essentially, ended up with a dts that corresponded to the MACHINE, which fully defined the combination of the bbb and extra hw. Dec 15 22:07:16 moto-timo About the golang issue, if you are not on master branch of poky you won't get the correct GOBUILDFLAGS. For myself, my makefiles are not correcly build to handle GOBUILDFLAGS from yocto. But what you showed me seems to me to solution. Search for -modcacherw here: https://golang.org/doc/go1.14 Dec 15 22:36:40 i'm trying to build kmscube but it's being skipped because my machine isn't in COMPATIBLE_HOST, except i don't see anything anywhere in the kmscube recipe that even suggests a COMPATIBLE_HOST Dec 15 22:36:49 how is it sneaking in? Dec 15 22:40:02 kanavin_home: just seen this, I'll try and remember to have a look tomorrow Dec 15 22:40:25 kanavin_home: I suspect its something to do with AUH adding/removing commits and maybe the cache invalidation isn't working for that Dec 15 22:40:55 kanavin_home: my change made it depend on the absolute value but it probably doesn't trigger a reparse if the metadata has changed Dec 15 22:41:36 kanavin_home: I suspect you could reproduce if you make a change to say a README, commit it and than build os-release again, something along those lines Dec 15 22:41:53 (i.e. change the revision but not the metadata) Dec 15 22:45:56 RP: thanks. It's late here, so I'd look into it tomorrow if you can't. Dec 15 22:46:00 23:45 Dec 15 22:47:10 kanavin_home: no problem, its definitely late there. I'll be sleeping shortly too Dec 15 22:49:59 the fun part is: i can't debug COMPATIBLE_HOST with "bitbake -e" because, well, ya know, it's not in COMPATIBLE_HOST Dec 15 22:50:08 :-) Dec 15 23:04:03 d'oh! BSP layer… Dec 15 23:06:05 * McBain MENDOZA!!! Dec 15 23:06:26 tlwoerner: didn't we improve it so you can use bitbake -e on skipped recipes? Dec 15 23:06:38 * RP remembers something about that but not exactly what Dec 15 23:06:42 haha, lol Dec 15 23:07:06 RP: that sounds familiar, i seem to recall more thought was added to helping situations like this Dec 15 23:08:16 zeddii: https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/1679/steps/13/logs/errors :/ Dec 15 23:08:22 zeddii: missing push/ Dec 15 23:08:24 ? Dec 15 23:08:36 but if a recipe is skipped due to COMPATIBLE_HOST issues and i do a "bitbake -e" i get: Dec 15 23:08:39 kmscube was skipped: incompatible with host arm-oe-linux-gnueabi (not in COMPATIBLE_HOST) Dec 15 23:08:51 (i.e. "bitbake kmscube -e") Dec 15 23:09:14 anyway, the restriction was from the BSP layer bbappend, so mystery solved Dec 15 23:13:45 zeddii: dropped that bit for now until you can push the missing bits ;-) Dec 16 01:02:03 codyps: so essentially if I want to let my customers build their own application for the target without sharing sensitive stuffs (e.g. the daughterboard or in-house apps) I can share the distro layer to them and ask them to build for the "beaglebone(-yocto)" machine, while I would be using a custom machine on my side. Dec 16 02:38:36 RP: somehow I ended up with a temp commit and the push bounced on non-ff, and I didn't notice. Dec 16 02:38:47 I'll resend. Dec 16 02:50:17 RP: rebased and dropped my debug commit, the patch will be fine now. **** ENDING LOGGING AT Wed Dec 16 02:59:56 2020