**** BEGIN LOGGING AT Fri Nov 29 02:59:58 2019 Nov 29 04:44:11 New news from stackoverflow: Bitbake Server does not start on Windows Subsystem for Linux Nov 29 05:58:24 b'/disk2/build.23/tmp/work/x86_64-nativesdk-tpssdk-linux/nativesdk-cmake/3.14.1-r0/package/opt/tps/2.7-20191129/sysroots/x86_64-tpssdk-linux/usr/bin/cpack: RPATH=/disk2/build.23/tmp/work/x86_64-nativesdk-tpssdk-linux/nativesdk-cmake/3.14.1-r0/recipe-sysroot-native/usr/lib\n'b"new rpath '$ORIGIN/../../../../../../../disk2/build.23/tmp/work/x86_64-nativesdk-tpssdk-linux/nativesdk-cmake/3.14.1-r0/rec Nov 29 05:58:34 why? Nov 29 08:34:11 Hmmm... Nov 29 08:34:54 Allright, so after a lot of cursing, sweat and tears, I finally narrowed down why my mingw sdk refuse to compile Nov 29 08:35:19 It is due to the layers meta-browser and it in turn inherits meta-clan Nov 29 08:35:24 *meta-clang Nov 29 08:37:08 Now, I do not need these layers at all for the SDK; so I wish to have them excluded from the SDK build chain and only the SDK build chain Nov 29 08:37:11 Can this be done? Nov 29 08:41:02 e.g. when I type bitbake my-image -c populate_sdk it should ignore those two layers completely Nov 29 08:41:16 nope, i don't think so Nov 29 08:41:36 this contradicts pretty much the whole layer model Nov 29 08:42:59 i mean, do the layers break the build by their pure inclusion in bblayers.conf? without any recipes being pulled in, no configuration being selected and all? Nov 29 08:43:01 Well, the meta-browser layer is supposed to be only an extra application, we don't need any libraries from it, and same with meta-clang Nov 29 08:43:10 wertigon: You could try setting TOOLCHAIN = "gcc" in the problematic recipes? Nov 29 08:43:44 because if a layer break the build just by its pure inclusion, then it is buggy. Nov 29 08:44:09 but if you actively select something from the layer and it breaks, well, then fix the recipe Nov 29 08:44:18 wertigon: https://github.com/kraj/meta-clang/blob/master/conf/nonclangable.conf shows the kind of thing I mean, its necessary for some bits of the system Nov 29 08:44:33 LetoThe2nd: Yes, from what I can understand; if I remove meta-browser dependencies from meta-arago-extras, but include it in bblayers.conf, it still builds Nov 29 08:45:21 wertigon: then the layer is probably wellbehaved and the recipes need fixing. Nov 29 08:45:28 RP: Ah, that might help; do I put that recipy in my own layer then? :) Nov 29 08:45:47 RP: can i try again and pester you for some multiconfig things? Nov 29 08:46:10 I'll try it after my coffee break starting now ^^ Nov 29 08:46:23 LetoThe2nd: it sounds like I missed something previous but yes, you can ask Nov 29 08:46:54 basically this:1) build an image that depends on another mc-image. 2) change something in a recipe that affects the mc-image, to something that is already in sstate cache 3) bitbake image. effect is: the mc-image gets rebuilt, but not image. then rerun bibtake image: mc-image doesn't get rebuit, image does Nov 29 08:46:59 wertigon: you can set it in certain recipes directly to force a particular toolchain or set it with the pn-XXX override in local.conf Nov 29 08:47:19 RP: like, struggling with dependency propagation when sstate is involved. Nov 29 08:48:06 LetoThe2nd: that sounds wrong :/ Is a nostamp involved on any of the images? Nov 29 08:49:31 RP: no. setting a nostamp on the fetch of the recipe that pulls in the image from the mc dependency solves them problem practically, but it feels like a sledge hammer Nov 29 08:50:14 LetoThe2nd: right, it is and you shouldn't have to do that Nov 29 08:51:13 LetoThe2nd: could be a bug :( Nov 29 08:51:40 RP: FWIW it only shows the behaviour if a recipe is modified so diffsigs triggers, but the new state of the recipe is something that already was built earlier and therefore can be pulled from sstate Nov 29 08:52:13 LetoThe2nd: its good to have it isolated to a specific case like that Nov 29 08:52:40 LetoThe2nd: probably a case of filing a bug and waiting/hoping someone has a chance to debug it Nov 29 08:52:50 RP: want me to file? Nov 29 08:52:56 LetoThe2nd: please Nov 29 08:53:10 RP: ok Nov 29 08:53:19 LetoThe2nd: an automated test reproducing the problem would probably help too Nov 29 08:53:55 sounds like it could be something quite simple to reproduce, maybe even two recipes rather than full images Nov 29 08:54:23 LetoThe2nd: basically the easier it is to reproduce, the faster someone will probably look at it Nov 29 08:54:47 RP: one additional minor question. referring to something from a speicifc multiconfig is clear, with the :multiconfig: syntax. but how to refer to something from the standard config, e.g. local.conf? Nov 29 08:55:52 RP: we'll see if we can provide a test case. Nov 29 08:56:26 LetoThe2nd: normal is a multiconfig of '' Nov 29 08:57:33 RP: so ::, basically? Nov 29 08:57:42 LetoThe2nd: I think so Nov 29 08:57:57 RP: thanks! Nov 29 09:01:47 RP: ok, $coworker who actually works on this (i'm just the guys supposed to be good with people here) agrees to provide a bugreport some time soon. Nov 29 09:20:04 LetoThe2nd: ok, thanks Nov 29 09:21:17 me being stupid. whats the trick if a source tarball unpacks to a non-canonical path? Nov 29 09:22:29 i think there was soomething to set the extraction directory? or just do S=...? Nov 29 10:19:48 hmm, a nativesdk recipe must set variables with FOO_class-nativesdk to override defaults from a bbclass. Plain FOO = "bar" will not work even if the bbclass sets defaults with FOO ??= "zoo" Nov 29 10:22:51 proper example? Nov 29 10:24:04 RP: concerning the python2 thing from yesterday, rebuilding the container did the trick. no idea what went wrong there. Nov 29 10:24:34 the bbclass also sets defaults for FOO_class-nativesdk ??= "". Seems like that overrides the FOO = "bar" from recipe, but FOO_class-nativesdk = "bar" again overrides the FOO_class-nativesdk ??= "" Nov 29 10:25:04 so that works. I wonder how many bugs I have because of this... Nov 29 10:28:21 mcfrisk: think "right to left" with variables. ??= sets the thing with that value (which includes the overide). Override expansion happens later Nov 29 10:29:23 FOO_x ??= "y" sets a default value of "y", FOO_x = "z" changes its value to z. Overrides only come later Nov 29 10:29:59 RP: thanks. Not sure if I should use ?= or ??= in the bbclass though. Nov 29 10:35:45 mcfrisk: it depends on the behaviour you want I guess Nov 29 10:46:43 WARNING: core-image-minimal-1.0-r0 do_rootfs: Manifest /home/pokybuild/yocto-worker/oe-selftest/build/build-st-14235/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-mdadm.package_write_rpm not found in qemux86_64 core2-64 x86_64 allarch x86_64_x86_64-nativesdk (variant '')? Nov 29 10:46:44 ERROR: core-image-minimal-1.0-r0 do_rootfs: No manifest generated from: mdadm in /home/pokybuild/yocto-worker/oe-selftest/build/meta/recipes-extended/mdadm/mdadm_4.1.bb Nov 29 10:46:51 RP: ^^ is that one of the known problems? Nov 29 10:46:59 or something fun and exciting in my next branch Nov 29 10:47:51 rburton: not seen it before Nov 29 10:50:13 dropped the gcc patch from my next Nov 29 10:52:08 hm devtool selftest does a mdadm cleansstate Nov 29 10:52:29 could that be breaking the other tests? Nov 29 10:53:52 rburton: is that one where it sets its own sstate directory? Nov 29 10:54:20 rburton: there are some tests which do run clean* but they should have their own sstate dir Nov 29 10:55:19 ah yes, okay, devtoolbase sets sstate_dir Nov 29 10:57:41 I've created a eSDK for my raspberrypi 4. Now I changed the kernel source and wanted to rebuild the image with "devtool build-image core-image-base". However, bitbake reports "skipping recipe linux-raspberrypi-rt as it doesn't produce a package with the same name" Nov 29 10:58:24 I don't know if that will affect me, or how to fix it ? Nov 29 11:22:24 is there a particular reason why runqemu always wants to get tun/tap up? what about a -nonet option? Nov 29 11:48:10 *le sigh* Nov 29 12:04:09 RP: are you sure that my gcc change was causing those reproducible errors? I was able to reproduce the errors, however both with and without the change. I did have to add tools-sdk to image features to get g++/etc. building though (which does not look like the default? on the AB) Nov 29 12:05:42 nrossi: I'm not 100% sure but I know the builds with that change in showed those reproducible test errors Nov 29 12:06:10 I might have been able to reproduce my troubles, building now to double check but: Nov 29 12:06:19 nrossi: I guess I could add just that change and run another test to 100% isolate it but it seemed fairly clear Nov 29 12:06:46 Basic problem - meta-browser and/or meta-clang breaks meta-toolchain Nov 29 12:07:18 Steps to reproduce: Download Poky, meta-browser, meta-clang, meta-mingw Nov 29 12:07:41 Sorry, breaks meta-toolchain when trying to build on meta-mingw on Poky Nov 29 12:08:01 Poky-thud even Nov 29 12:12:23 RP: it does seem obvious why it might fail reproducible tests. The equivalent configargs.h might also be needed for non-cross (since "--with-build-sysroot" is embedded in the binaries), however it should be failing now regardless of my gcc change :| Nov 29 12:17:26 Change all branches to thud, add layers to bblayers.conf, specify the SDKMACHINE Nov 29 12:17:37 Compile, everything explodes in a fire Nov 29 12:22:53 nrossi: you can see why I was holding off blaming the patch, I don't quite understand it. Nov 29 12:23:05 nrossi: I guess we should fire a build with just this change in Nov 29 12:23:11 (compared to master) Nov 29 12:24:43 RP: probably a good idea, out of query do you know where/how tools-sdk or gcc/g++/etc. is added to core-image-minimal in yocto-autobuilder-helper? Nov 29 12:28:07 nrossi: I don't :/ Nov 29 12:30:46 nrossi: I've fired a couple of test builds with just that in Nov 29 12:33:14 https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/521 https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/530 Nov 29 12:34:49 RP: thanks, i will keep an eye on it. Will see if i can figure out why my local master build fails Nov 29 12:35:46 Another strange inconsistency Nov 29 12:36:02 I get mingw gcc version 7.3 Nov 29 12:36:11 but linux gcc version 8.2 Nov 29 12:36:19 for sdk Nov 29 12:42:43 trying to use yarn in a recipe do_compile, it gets annoyed over Error: EACCES: permission denied, open '/usr/local/share/.yarnrc' Nov 29 12:42:51 anybody run into this already? Nov 29 13:22:52 Why isn't meta-mingw gcc same as linux-native gcc? Nov 29 13:27:21 would CFLAGS_append_x86_64 work for appending some optimizations for x86_64 targets only? is the variable TUNE_ARCH or some other thing? Nov 29 13:36:19 how is it possible that a wic image tries to include my squashfs rootfs without building it first (in sumo) ? The squashfs does get built as soon as I remove "wic" from IMAGE_FSTYPES, so it looks like some task dependency is missing ? Nov 29 13:56:18 Ok, confirmed; meta-browser breaks meta-mingw on standard Yocto in the same way it breaks on meta-arago. Nov 29 13:56:21 (thud branch) Nov 29 13:57:00 and this is why we have the yocto project compatible scripts Nov 29 13:57:10 to detect layers that make changes without being asked Nov 29 13:57:49 rburton: Or might be mingw that breaks browser, but end result is the same :P Nov 29 13:58:14 wertigon: how does it explode? Nov 29 13:58:27 wertigon: meta-mingw does export RC, which might be upsetting the browser Nov 29 13:59:50 rburton: try the following layers: meta, meta-poky, meta-yocto-bsp, meta-openembedded/meta-oe, meta-clang, leta-browser, meta-mingw Nov 29 14:00:07 or, you can pastebin the failure and i can look at it Nov 29 14:00:12 Put all layers to thud except for meta-browser Nov 29 14:00:20 Building the failure right now Nov 29 14:00:35 But I'll pastebin in about 5-10 min :) Nov 29 14:00:55 (meta-browser has no layers) Nov 29 14:01:02 And change SDKMACHINE Nov 29 14:01:18 And it'll explode in glorious flames Nov 29 14:01:52 If you do bitbake meta-toolchain or populate_sdk Nov 29 14:12:03 nrossi: figured it out. coreutils-ptest adds libmodule-build-perl which has a ptest RDEPENDing on gcc Nov 29 14:12:21 nrossi: so the coreutils change made it appear in the test Nov 29 14:12:25 tgamblin: ^^^ Nov 29 14:12:58 ah, interesting Nov 29 14:13:18 I'll check to see how that affects the ptest. I think it adds a failure without it but I'll have to confirm again Nov 29 14:14:28 tgamblin: its not that much of an issue but just an interesting part of the tangled web the ptests are causing Nov 29 14:18:40 RP: things to remember when I eventually add more Nov 29 14:18:51 At some point I'd like to add one for libgcrypt Nov 29 14:26:33 tgamblin: I'm definitely keen to see more of them Nov 29 14:40:14 rburton: Sorry for it taking so long, clang-native takes a lot of time to compile, at 87% clang-native and 2109 tasks of 2287 Nov 29 14:40:38 doing a -k bitbake in order to catch most errors Nov 29 14:53:31 rburton: Here ya go! https://pastebin.com/dHWCNUHX Nov 29 14:55:00 hi iam stucking at my custom Uboot config... Nov 29 14:56:03 I want to have the boot config / environment in a different partition (and redundant but afair this is possible with altbootcmd) Nov 29 14:56:39 But for me it looks likt its hard compiled into include/configs/boardname.h And NXP uses a lot of "custom" enviroment... Nov 29 15:09:00 We have a separate boot partition that contains Linux kernel image, a squashed rootfs and boot parameters Nov 29 15:09:30 I don't think you can have kernel config and image separate, could be wrong Nov 29 15:09:43 Would otherwise suggest an overlayfs Nov 29 15:10:04 We as in, my company, not yocto project as such. :P Nov 29 15:10:22 <-- Just another yocto "user" with noobish skills still Nov 29 15:17:13 Anyhow; boot configs cannot be put in a separate partition, but you can overlay and merge a separate filesystem that replaces all files in the first file system with ones defined in the second one Nov 29 15:17:48 e.g. if your overlay only has /etc/network/interfaces only that file will be replaced in the unified root filesystem Nov 29 15:21:49 wertigon: not kernel config, iam taling about uboot config / environment stuff Nov 29 15:35:41 RP: interesting, good to know that the build passed with just the gcc patch though. I will separately look into the configargs.h for target gcc since noticing it contains build-sysroot paths, will help to make target gcc one step closer to reproducible ;) Nov 29 15:40:37 rburton: Ok, I think I have a theory of why I am seeing strange things with mingw[thud]: Nov 29 15:40:58 mingw[thud] does not support clang Nov 29 15:41:24 this is since clang makes gcc compiler version 8.2 Nov 29 15:41:38 Which mingw[thud] does not support Nov 29 15:42:40 Am waiting for a build to finish so I can confirm, but I have a pretty strong suspicion I'm right here :P Nov 29 16:10:44 Yes, this is confirmed now - gcc is 8.2 if I include clang, 7.3 if I do not Nov 29 16:10:56 Great, have a good weekend y'all! Nov 29 16:15:58 hi folks, not really strictly a yocto question but since there's a lot of people who have a lot of knowledge about this kind of stuff Nov 29 16:16:49 why would my recipe require libtool .la files? Nov 29 16:17:05 shouldnt the same info already be in pkg-info? Nov 29 16:17:57 i've upgraded to a newer yocto and now it removes .la files during install by default Nov 29 16:18:16 i understand there's REMOVE_LIBTOOL_LA Nov 29 16:24:05 but im trying to understand why it needs those files at all Nov 29 16:24:25 the recipe that fails to build looks just like a regular autotools project Nov 29 16:25:22 it's using PKG_CHECK_MODULES(GLIB, glib-2.0 >= 2.16, dummy=yes, Nov 29 16:26:05 i thought that would take everything it needs from the .pc file for glib Nov 29 16:50:51 I am creating a recipe for this sw: https://github.com/NordicSemiconductor/pc-nrfutil. The license is some sort of modified BSD. what value should I use for LICENSE var? Nov 29 16:56:49 this is neither the usual 3-clause nor the usual 4-clause bsd, but something customized, i such a case we generally advise setting it to the name of the project Nov 29 17:27:36 milloni: yes, but if you're rebuilding and it found a .la file before and you're not using a clean build dir and and and. just use the remove-la class and do a clean build. .la files are EVIL. Nov 29 17:28:54 in this particular case, it seems that glib (glib itself, unrelated to yocto) stopped producing .la files Nov 29 17:29:02 yes, it moved to meson Nov 29 17:29:03 nrossi: sorry for the false alarm, its sometimes hard to track down what is coming from where Nov 29 17:29:04 which doesn't use libtool Nov 29 17:29:09 so no .la files Nov 29 17:29:11 and good for them :) Nov 29 17:29:30 but i've got a project here that insists on building from .la files Nov 29 17:29:41 but if something indirectly depends on glib and uses libtool and you were not blasting them from space, it will try to find the files Nov 29 17:29:41 i.e im getting a ".la file not found" error Nov 29 17:29:46 does it break from a clean build? Nov 29 17:30:02 clean build of the offending recipe? yes Nov 29 17:30:13 maybe its actually hitting the .la files directly? Nov 29 17:30:20 how so? Nov 29 17:30:27 specifying them directly in the makefiles Nov 29 17:30:46 is this a public project or something private Nov 29 17:30:53 hm Nov 29 17:31:01 unfortunately proprietary code :/ Nov 29 17:31:43 so 1) check the makefiles are using pkgconfig properly, ie the variables from that PKG_CHECK_MODULES call and not glib-2.0.la anyhere Nov 29 17:32:09 2) check that you don't have any implicit dependencies on modules that depend on glib, so wouldn't have rebuilt, but now embed references to the glib.la files Nov 29 17:32:54 this is one of many reasons why we blast away all .la files by default Nov 29 17:35:46 RP: ross/next went green if you want to grab it Nov 29 17:36:33 rburton: cool, thanks Nov 29 17:37:14 the only thing returned by `git grep '\.la'` is Nov 29 17:37:26 lib_LTLIBRARIES = libredacted.la Nov 29 17:37:34 where "redacted" is the thing im trying to build Nov 29 17:37:49 rburton: did you find a problem with the gcc change or not? Nov 29 17:38:04 RP: i removed it as you had a hunch Nov 29 17:38:11 we can fire that at selftest on its own Nov 29 17:38:23 rburton: ok, we've proven that one wrong, just checking I hadn't missed anything Nov 29 17:38:37 milloni: can you not just use the remove-la class and rebuild the world? Nov 29 17:38:57 the problem is most likely (2), .la files are incredibly contagious Nov 29 17:38:58 isn't remove-la on by default now? (zeus) Nov 29 17:39:19 for autotools.bbclass Nov 29 17:39:32 it started removing .la files since we upgraded Nov 29 17:39:40 assuming you're using the default distro conf yes Nov 29 17:39:52 that started breaking things Nov 29 17:40:08 which we got around by using REMOVE_LIBTOOL_LA = 0 Nov 29 17:40:42 but this proprietary recipe is insisting on using .la files Nov 29 17:40:54 even though i cant find any references to them in the codebase Nov 29 17:41:31 other than what i pased above Nov 29 17:41:41 so if you don't set REMOVE_LIBTOOL_LA=0 then what error do you get? Nov 29 17:42:31 it built after i removed lib_LTLIBRARIES = libredacted.la Nov 29 17:42:48 we have REMOVE_LIBTOOL_LA = 0 for glib-2.0 Nov 29 17:43:02 i've not tried without setting it but i assume it doesnt make a difference Nov 29 17:43:03 honestly, just stop disabling it for glib and fix the real problem Nov 29 17:43:17 since glib-2.0 doesnt produce .la files at all ever since they moved to meson Nov 29 17:43:23 removing lib_LTLIBRARIES will mean it doesn't build libredacted.la Nov 29 17:43:41 which means it won't build the library at all Nov 29 17:43:57 hm Nov 29 17:44:25 honestly, just stop disabling it for glib and fix the real problem Nov 29 17:44:31 that's what im trying to do now Nov 29 17:44:43 before i go, my recommendation is to undo anything you changed re libtool and do a build with a clean tmp Nov 29 17:44:59 okay, i'll try that, thanks **** ENDING LOGGING AT Sat Nov 30 02:59:57 2019