**** BEGIN LOGGING AT Thu Feb 25 02:59:57 2021 Feb 25 03:35:05 just me or does json-c-native fail to build? Feb 25 04:45:11 is the smart package manager still supported? or is there something better (apt?) available nowadays? (I used smart some 2-3 years back) Feb 25 05:24:50 yates: dnf has been used for a while now Feb 25 05:25:59 yates: and I believe it's possible to build with apt, but I've not tried it Feb 25 05:43:06 smurray: thank you Feb 25 05:44:07 isn't there a site of all (or many) of the open-source layers available for yocto? Feb 25 05:44:52 https://layers.openembedded.org/layerindex/branch/master/layers/ Feb 25 05:44:53 ? Feb 25 05:48:52 i'm confused - what's the difference between the layers here: https://git.yoctoproject.org/ and the ones listed here: https://layers.openembedded.org/layerindex/branch/master/layers/ Feb 25 05:50:24 yates: layer index as the name says list all layers which are available, they can be housed anywhere, git.yoctoproject.org is one such location to house the source code for some of layers which are supported. by yocto project Feb 25 05:50:29 hope that helps Feb 25 05:53:56 k Feb 25 05:54:05 yes, thanks khem Feb 25 06:04:30 i was asking earlier about how cross-toolchains (i.e., binutils) are built and it seems that somehow yocto builds it from source but may require some customization for a specific or custom architecture. which layer is responsible for this? Feb 25 06:06:32 https://www.yoctoproject.org/docs/1.8/bsp-guide/bsp-guide.html ? Feb 25 06:17:39 is it this one? http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-devtools/binutils/binutils.inc?h=fido ? Feb 25 06:28:44 is the device tree typically provided as part of the bsp layer? Feb 25 07:32:00 good morning Feb 25 07:47:53 yates: that's the way I've seen it usually done. The BSP layer adds the needed devicetree files as kernel patches and declares wich one to use in the machine config Feb 25 09:14:38 yates: bsp layer = everything needed to reach userspace (init system excluded) and all needed firmwares/drivers. Bootloader, kernel, device tree, firmware, out-of-tree drivers,... Feb 25 09:15:26 which usually requires a machine config file as dwagenk said Feb 25 09:15:39 requires/warrants/ Feb 25 09:17:32 dl9pf: overnight build still shows the font issue :( Feb 25 09:24:01 RP with sstate? Feb 25 09:24:27 sstate might contain the old metadata Feb 25 09:24:38 or? Feb 25 09:25:50 or we did not disable the macro w/ our call. Feb 25 09:26:23 RP where is the diffoscope or files ? Feb 25 09:27:55 https://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20210224-a_qc3tpm/packages/diff-html/ from https://autobuilder.yoctoproject.org/typhoon/#/builders/115/builds/36/steps/12/logs/stdio for example Feb 25 09:28:31 dl9pf: version B should have been from scratch Feb 25 09:37:59 RP: help me understand what happenz in case A) do we get the finished rpm file out of sstate or the package/package-split and rerun rpmbuild ? Feb 25 09:38:45 to me A does not find the fontcache binary, thus shorter. and the fully build B) does find it and adds the extra data Feb 25 09:39:57 dl9pf: A could pull out of sstate for everything Feb 25 09:40:18 dl9pf or build from scratch, depends if it is in sstate Feb 25 09:40:53 lets assume it is Feb 25 09:41:33 now with our change B should not have the metadata, so back to that Feb 25 09:42:14 can we inject 'rpm --showrc' dump before we call rpmbuild ? Feb 25 09:43:15 B) clearly executes e.g. "/usr/bin/fc-query --format '%{=pkgkit}' /usr/share/fonts/100dpi/charB10.pcf.gz" Feb 25 09:43:30 which we don't want Feb 25 09:43:35 dl9pf: What you're saying is I need to debug it on that machine Feb 25 09:44:09 we need to find why the --define did not take effect Feb 25 09:44:29 dl9pf: right Feb 25 09:44:54 or we simply patch out in rpm's macros.in when building rpm-native Feb 25 09:45:50 I'll see if I can have a look shortly **** BEGIN LOGGING AT Thu Feb 25 09:56:55 2021 Feb 25 09:58:07 yo dudX Feb 25 09:58:33 o/ Feb 25 09:59:31 rpm --define '__font_provides %{nil}' --showrc | grep font works as expected ... hmm Feb 25 10:48:55 Hello everyone. I am trying to overwrite the do_install() task using a bbapend file. However, it seems that both do_install() tasks are executed. Feb 25 10:49:01 What am I missing? Feb 25 10:55:40 morning, am slowly running out of space (work/tmp taking 110GB) can I safely delete the build/tmp directory? also there is a cache directory which one is it and can i safely delete it? Feb 25 10:56:57 sorry mean build/tmp is taking 110GB Feb 25 11:00:25 intera91: sstate-cache and downloads directories should be kept, the rest can be removed Feb 25 11:00:39 intera91: have a look into rm_work class to be inherited globally too Feb 25 11:02:59 qschulz: I have not yet mastered the classes but I know I can safely delete build/tmp which is enough to give me back the space I need Feb 25 11:09:59 intera91: To not keep all artifacts built, you can use the "rm_work" bbclass. And to reduce the size of your sstate folder you can use the command "sstate-cache-management.sh --yes --cache-dir = $ SSTATE_DIR --stamps-dir = tmp / stamps" that will remove the duplicated sstate cache files of one package, only the newest one will be kept. Feb 25 11:11:15 tprrt: thank you  I will look  into that class and how to use it Feb 25 11:11:30 Hi All, Is there a option in wic to generate compressed image instead of .direct ? Feb 25 11:13:10 intera91: you are welcome Feb 25 11:36:22 tprrt: FWIW, I do a simple find -atime +30 -delete sstate-cache every now and then. Feb 25 11:38:17 yeah, same here Feb 25 11:38:26 weekly cron is all you need Feb 25 11:40:41 qschulz: thx Feb 25 11:46:37 prabhakarlad: can't you have an IMAGE_FSTYPES = "wic.gz" or something along those lines? is this what you're looking for? Feb 25 11:51:10 qschulz I have  a requirement to  have a rfs inside a rfs so I am using wic to do the copying and create a .direct image Feb 25 11:52:34 o.O Feb 25 11:53:30 yo dawg, we heard you like builds, so we put a build in your build.... Feb 25 11:53:52 https://theyoctojester.info/session_18/main.html Feb 25 11:56:34 RP: am i right in thinking that meta/recipes-devtools/gcc/gcc/0002-gcc-poison-system-directories.patch includes a change so that cross builds pass -Werror=point-system-directories by default? Feb 25 12:09:35 thanks for the responses re: bsp/device tree Feb 25 12:15:22 rburton: that is what it is supposed to do but looking at the patch I'm not sure it is enabled Feb 25 12:15:30 me neither Feb 25 12:15:43 just doing a build test now but i had to rebuild the compiler because I updated Feb 25 12:16:45 rburton: its possible there is some other config that makes it the default in the cross compiler Feb 25 12:17:11 rburton: gcc-cross-canadian.inc:EXTRA_OECONF += "--enable-poison-system-directories" Feb 25 12:17:15 gcc-cross.inc:EXTRA_OECONF += "--enable-poison-system-directories" Feb 25 12:17:25 I discovered an old patch i had that removed all the 'CROSS COMPILE Badness' detection from insane, which hasn't been output since 2010 Feb 25 12:17:57 rburton: I think I have seen that Feb 25 12:18:15 gonna write a test for this :) Feb 25 12:18:22 rburton: cool Feb 25 12:22:34 Can I somehow check to which directory DL_DIR and SSTATE_DIR were set to at last build? Feb 25 12:23:02 when I still have the TMPDIR around Feb 25 12:24:18 manuel__: bitbake -e some-recipe | grep -e "^DL_DIR="? Feb 25 12:27:19 Hmm. Let's see how to get kas doing that. Feb 25 12:27:55 manuel__: export those variables before calling kas and it will use the variables you set Feb 25 12:28:06 so you tell kas, instead of needing to find out from kas Feb 25 12:28:24 (but you can do what you want with kas) Feb 25 12:35:46 RP: its just a warning Feb 25 12:36:14 this could be fun Feb 25 12:38:46 is it possible to configure gcc so that a warning is on by default and fatal (without passing -Werror=... every time) Feb 25 12:54:36 rburton: we could probably make it fatal by now... Feb 25 12:54:51 rburton: although I remember that having interesting side effects with configure Feb 25 12:55:06 "does gcc support X" "no as it errored" Feb 25 13:29:36 is the current opkg maintainer here ? Feb 25 13:32:03 hch: at least people with commit rights are here. what is it about? Feb 25 13:40:25 RP: can you check if the contributing doc of opkg is up to date, especially concerning the ML? Feb 25 13:43:43 LetoThe2nd: https://groups.google.com/g/opkg-devel?pli=1 is the right place? Feb 25 13:44:12 hch: ^^^^^^ Feb 25 13:44:14 RP: well minimal built with -Werror in cflags and ldflags Feb 25 13:44:44 rburton: promising Feb 25 13:44:44 https://git.yoctoproject.org/cgit/cgit.cgi/opkg-utils/tree/CONTRIBUTING#n60 Feb 25 13:45:02 rburton: don't put -werror in production code Feb 25 13:45:19 hch: the link before that links to opkg-devel Feb 25 13:45:23 line before Feb 25 13:46:08 that documents states "For now, please submit all patches to both the Yocto Project mailing list (yocto@yoctoproject.org) and the opkg mailing list (opkg-devel@googlegroups.com)," Feb 25 13:47:43 hch: yes, i know. this i special. Feb 25 13:48:46 i got a 'Undelivered Mail Returned to Sender' from (expanded from ) Feb 25 13:48:53 just wanted to report Feb 25 13:49:08 ah the address is wrong Feb 25 13:49:12 yocto@lists.yoctoproject.org Feb 25 13:49:24 feel free to send a patch fixing the readme too :) Feb 25 13:49:47 if that's intended, fine :) Feb 25 13:49:49 oh. will do Feb 25 13:50:31 hch: sorry, yes, there should be a lists. in there. Didn't spot that! Feb 25 13:52:05 that note is only present in opkg-utils/CONTRIBUTING, not in opkg/CONTRIBUTING Feb 25 13:52:43 :) LetoThe2nd> TheYoctoJester guess it should be yocto@lists.yoctoproject.org, the MLs move a couple of months back. Feb 25 13:53:26 hch: see, staying in channel would've been easier :) Feb 25 13:53:46 agree Feb 25 13:55:38 Hello, I'm trying to compile the iotedge-cli from meta-iotedge. In the logs it looks like there there is something wrong with the variabels : error: failed to parse manifest at `/tmp/work/aarch64-ktn-linux/iotedge-cli/1.0.9.4-r0/iotedge-1.0.9.4/edgelet/iotedge/iotedge/Cargo.toml`  the file is located at /iotedge but there is no /iotedge/iotedge Feb 25 13:55:39 directory. My question is, where can I find out what function and file is actually running that command? I have looked in the Makefile for the recipe and the .bbfile but here is no do_compile function nor any cargo command. Not sure if this is the right forum but thought I would give it a go (: Feb 25 13:58:16 boom minimal test case Feb 25 13:58:18 $ aarch64-poky-linux-cpp -I/usr/include -Werror=poison-system-directories < /dev/null ; echo $? Feb 25 13:58:27 rburton: :) Feb 25 13:59:11 wbw: well you've checked all dependencies are in place (layers) and that releases/branches match? Feb 25 14:01:07 wbw: because this sounds a lot like some rust magic is missing. Feb 25 14:02:36 RP: is sending to that yocto list even relevant really? Feb 25 14:03:12 hch: good question. It doesn't hurt anything but cross posting isn't ideal Feb 25 14:03:44 i just realized the mailerdaemon notified me that i'm not subscribed to that list Feb 25 14:09:07 LetoThe2nd: I checked and you are correct, the meta-rust does not seem to have a dunfell branch. Is my only option then to downgrade everything to a matching branch? In this case Sumo Feb 25 14:11:04 wbw: if the branches don't match then you're in for trouble. sumo is basically deprecated and out of support, so choose wisely. Feb 25 14:11:46 for meta-rust, master might work with dunfell Feb 25 14:11:57 if it doesn't then harass the maintainer as the layer says it does Feb 25 14:12:27 rburton: yeah. Feb 25 14:12:59 if the documentation says "works with" then compatible vars should be set accordingly. if not then its essentailly a bug - either in the docs or in the layer.conf Feb 25 14:13:00 This error comes from master branch, I can try go back a few commits maybe something broke recently Feb 25 15:41:04 Hello! I'm currently trying to compile dunfell, and I need to add out of tree kernel modules. Kernel is compiling fine (I'm on a 5.10 megous version). When I try to compile my modules, the make-mod-scripts recipe fails during the configure. The error is related to not found : gmp.h: No such file or directory. gmp-native is correctly Feb 25 15:41:04 compiled. I don't understand why I'm getting this error. Someone already faced this kind of problem, or someone has an idea ? Feb 25 15:45:17 in my experience missing .h files usually means something is missing on the host, do you have libgmp3-dev installed? Feb 25 15:47:34 wbw: nah thats certainly not the case. Feb 25 15:48:13 @wbw indeed, libgmp3-dev was not installed ... I installed it, and now I have an error concerning mcp.h:D  I'll install the missing dependencies, and it should be OK Feb 25 15:48:29 ks156: i would guess that the modules makefile is broken/not cross compile aware. maybe try with a generic, simple OOT module. if that builds fine then that also indicates a problem with the module. Feb 25 15:49:01 ks156: i am sure that you're on the wrong track. now you're randomly installing host packages that leak into your build, making it buggy/unreproducible. Feb 25 15:51:23 we do out of tree module builds every night with the AB, thousands of them. Feb 25 15:52:05 RP: core-image-minimal testimage is failing with couple of tests failing https://paste.ubuntu.com/p/69Tn3PRnyT/ it was working ok a day ago so something changed yesterday Feb 25 15:52:07 zeddii: and let me guess, you don't manually install gmp headers :) Feb 25 15:52:14 nope :D Feb 25 15:52:33 lttng-modues is out of tree. and builds frequently. Feb 25 15:52:40 he seems zeddii is in trouble Feb 25 15:52:56 LetoThe2nd I'm using a minimal docker image for the build, so that's explain why I don't have these libs installed. I installed libgmp3 and libmpc, and make-mod-scripts works now. Anyway, if the problem is not related to my host installation, what could cause the issue ? Feb 25 15:53:36 FWIW: Feb 25 15:53:36 recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb:DEPENDS += "gmp-native" Feb 25 15:53:37 we should add mpc and gmp to DEPENDS for kernel Feb 25 15:53:46 it's already covered. Feb 25 15:53:49 ks156: so you want me to repeat it a third time literally? Feb 25 15:53:56 but not mpc ? Feb 25 15:54:20 ks156: i would guess that the modules makefile is broken/not cross compile aware. Feb 25 15:54:20 I've never run into it, and haven't installed any mpc dev files locally Feb 25 15:54:30 and I tend to build quite a few kernels Feb 25 15:54:37 perhhaps you need libmpc-native in deps too zeddii Feb 25 15:54:47 i don't have any issues :D Feb 25 15:54:53 nor do the ABs Feb 25 15:55:06 ah Works For me (TM) Feb 25 15:55:37 look mpc is always installed on machines but containers could be bare bone Feb 25 15:55:48 LetoThe2nd I was suspecting my modules to be faulty. So I tried with this simple module : https://wiki.koansoftware.com/index.php/Howto_build_a_kernel_module_out_of_the_kernel_tree Feb 25 15:56:27 JPEW: 'WARNING: SOURCE_DATE_EPOCH value from sstate '0' is deprecated/invalid. Reverting to SOURCE_DATE_EPOCH_FALLBACK '1302044400' <-- is that your fault Feb 25 15:56:43 if i can ignore it, should it be a warning? Feb 25 15:57:02 rburton: Actually not! dl9pf added that code ;) Feb 25 15:57:08 libmpc is needed by gcc so it should get in automatically on a system where you install gcc and we do need gcc on build machines so I wonder why it is not installed on the docker image Feb 25 15:57:20 rburton: Which task? Feb 25 15:57:28 doesn't say Feb 25 15:57:31 ks156: so if at all, then adding the dependencies as khem discussed is the way to go. randomly installing packages on the host is not. Feb 25 15:58:57 anyways, calls it a day. Feb 25 15:59:52 no escape character (for multiline) allowed in .wks files? Feb 25 16:00:22 rburton: for now we need to see it prominently, can revert to a note in a few days Feb 25 16:01:24 gn LetoThe2nd: Feb 25 16:02:46 dl9pf: ok Feb 25 16:03:29 rburton: what task/package did spit that out ? Feb 25 16:03:46 dl9pf: the message should say that: i was building a recipe from clean, so can't tell Feb 25 16:06:31 rburton: the messages here look like: Feb 25 16:28:59 I have kind of an existential question. Since a .wks file is hardly bound to a machine and a machine can only define one .wks file to use, wouldn't it be better to have machine variables in include files like WIC_PART_FSTYPE_boot = "vfat", WIC_PART_EXTRA_SPACE_boot = "100M", etc. Feb 25 16:30:33 (similar to UBOOT_EXTLINUX_FOO_label variables.) Feb 25 16:45:49 vmeson: https://autobuilder.yoctoproject.org/typhoon/#/builders/116/builds/40/steps/13/logs/stdio failure of rust-native on debian8 Feb 25 16:48:59 revert with malice! Feb 25 16:49:03 * paulg runs. Feb 25 16:49:30 paulg: not merged yet so even easier ;-) Feb 25 16:50:19 NAK WITH MALICE Feb 25 16:51:04 vmeson: ah, selftest isn't happy either. I'll write an email ;-) Feb 25 16:56:20 you know it's bad when I can't explain on irc :) Feb 25 17:19:05 yeah, I understand. Peopler aren't supposed to use cuss words on here. ;-P Feb 25 17:19:49 paulg: coming to kernel modules near you soon? ;-) Feb 25 17:20:07 * smurray shudders Feb 25 17:20:51 * moto-timo makes popcorn Feb 25 17:22:07 can pretty much guarantee there will be someone new every year or two who will run "git grep " and get on LKML in an attempt to save the unwashed heathen scum from poisoning the minds of the sheep. Feb 25 17:22:40 after some 25 years, you just don't even see it anymore. Feb 25 17:47:42 zeddii, JPEW: https://autobuilder.yocto.io/pub/repro-fail/2021-2-25-rp/perf/diff/ - perf diffoscope Feb 25 17:54:24 https://autobuilder.yocto.io/pub/repro-fail/2021-2-25-rp/ has the other remaining diffs for non-reproducing packages outside of go Feb 25 17:57:21 clearly i need to learn how to read that output :D Feb 25 17:58:31 Although I used your tip from earlier, and at least searched for 'bison' and it is more than just size differences in headers Feb 25 18:01:28 zeddii: key first observation is the size change in the rodata section Feb 25 18:01:56 DW_MACRO_define_strp·​-​·​lineno·​:​·​0·​macro·​:​·​DOCDIR·​BUILD_STR(/​home/​pokybuild/​yocto-​worker/​reproducible-​centos/​build/​build-​st-​2135135/​reproducibleA/​tmp/​work/​qemux86_64-​poky-​linux/​perf/​1.​0-​r9/​perf-​1.​0/​tools/​perf/​Documentation)​ Feb 25 18:02:03 changes to DW_MACRO_define_strp·​-​·​lineno·​:​·​0·​macro·​:​·​DOCDIR·​BUILD_STR(/​home/​pokybuild/​yocto-​worker/​reproducible-​centos/​build/​build-​st-​41742/​reproducibleB/​tmp/​work/​qemux86_64-​poky-​linux/​perf/​1.​0-​r9/​perf-​1.​0/​tools/​perf/​Documentation)​ Feb 25 18:02:41 zeddii: basically hardcoded paths making it into the binaries so start finding where those come from Feb 25 18:03:50 If anyone wants to help, the boochart2-doc and libid3tag packages don't look too bad to fix Feb 25 18:04:07 * zeddii nods Feb 25 18:10:32 RP: yah, some simple grepping shows that it does capture the srcrc Feb 25 18:10:40 srcdir, I should say Feb 25 18:11:28 https://pastebin.com/cj6DaxCG Feb 25 18:11:54 I need to learn how to run the reproducible builds here though, otherwise, I'm going to just be guessing. Feb 25 18:19:17 RP: I have sent a v2 which potentially should fix mingw issue, I think its because of a backport that came into 2.36 branch which has been fixed in master but will need some dependent backports first so I will let upstream binutils devs figure the required backport to fix it until then we use a SRCREV before that breakage Feb 25 18:21:20 this is the fix I am talking about https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=cca8873dd5a6015d5557ea44bc1ea9c252435a29 Feb 25 20:37:41 zeddii: I can give a crash course on how to test it if that helps Feb 25 20:37:55 khem: seems reasonable to me, JPEW is the mingw maintainer Feb 25 20:42:07 JPEW_: https://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20210225-khmytn4a/packages/diff-html/ is an example of the issue we talked about earlier with hashequiv invalidation :( Feb 25 20:42:46 dl9pf: still seeing rpm mismatches but its hashequiv issues now :( Feb 25 20:48:08 yeah, i see pre/post fix Feb 25 20:51:31 RP: So this is the same input hash causing 2 different outputs ? Feb 25 20:51:59 JPEW_: yes. before I fixed rpmdeps the fonts output could appear depending on whether the system had fc-cache Feb 25 20:52:25 since we now get the same output after the fix, it has the thing crosslinked Feb 25 20:54:44 Ok, so task hash OLD made both output hashes GOOD and BAD. Now task hash NEW also produced GOOD so hashequiv assumes that OLD is equally valid? Feb 25 20:55:14 JPEW_: yes Feb 25 20:55:32 JPEW_: and BAD is the one chosen in sstate Feb 25 20:56:42 The "easy" fix it to remove the OLD/GOOD pair in the database Feb 25 20:56:52 The hard part is detecting it Feb 25 20:58:58 JPEW: right, I don't know how to do it :( Feb 25 21:00:30 Hmm... Feb 25 21:06:25 JPEW: question is do I bump the hash version for the 4 font recipes or... ? :/ Feb 25 21:23:23 RP: It seems a little odd that OLD has both GOOD and BAD in the database in the first place... only one of them can be in sstate? Feb 25 21:27:46 JPEW: well, that sounds logical but doesn't seem to be the case :/ Feb 25 22:08:04 RP: Well... should we only allow one OUTHASH per TASKHASH? The OUTHASH needs to match whats in sstate... Feb 25 22:12:50 JPEW: could we enforce that? Feb 25 22:13:31 JPEW: I think the issue might have been that we have the same TASKHASH but different OUTHASH e.g. per arch Feb 25 22:16:31 Ah, that package is noarch? Feb 25 22:16:40 JPEW: yes Feb 25 22:36:43 I have a strange situation..   I have a libgbm.so  that is a softlink to libMali.so. This seems to upset yocto when another package rdepends on libgbm. Feb 25 22:37:29 If I just copy libMali.so to libgbm.so it seems to work.. but its 18MB! Feb 25 22:38:31 Even if I bypass the file-rdeps dnf gets upset...  So this just seems like a bad thing but I also feel like I am missing something because softlinks for so are normal. Feb 25 22:51:54 rabbit9911: libmali is a mess :( Feb 25 22:52:22 We gave up and switched to panfrost (mesa)... *so* much better Feb 25 22:59:15 I think I see the root of the problem...  I have a recipe that has multiple packages.  libegl libgbm. but they all softlink to the libMali.so.   Can you have a package that depends on another package in the same recipe? Feb 25 23:00:39 You should be able to RDEPENDS on other packages in the same recipe Feb 25 23:08:11 Hmm. Well all of this looks right now but I still get the same errors.. It seems yocto and dnf dont like the base libgbm.so to be a softlink to another library. Feb 25 23:08:42 Problem: conflicting requests Feb 25 23:08:42   - nothing provides libgbm.so()(64bit) needed by glmark2-20191226+0+72dabc5d72-r0.aarch64 Feb 25 23:09:08 libgbm.so is there as far as I can tell.. its just a link.  not (64bit)? Feb 26 02:48:34 rabbit9911: this means the libgbm.so that you have does not have SONAME encoded in ELF Feb 26 02:48:47 can you post output of readelf -d libgbm.so ? **** ENDING LOGGING AT Fri Feb 26 03:02:01 2021