| bluelightning | tlwoerner: presumably that path is being encoded into a file that gets installed by PackageA, and PackageB's configure step picks it up | 00:03 |
|---|---|---|
| tlwoerner | bluelightning: let me check... | 00:04 |
| *** agust <agust!~agust@p54833695.dip0.t-ipconnect.de> has quit IRC | 00:06 | |
| tlwoerner | bluelightning: yes! found it | 00:08 |
| tlwoerner | PackageA-dev/usr/lib/PackageA-targets.cmake | 00:09 |
| tlwoerner | this doesn't *appear* to be a mistake in the recipe, but rather something that's part of cmake (or maybe how we're using cmake?) | 00:10 |
| *** behanw <behanw!uid110099@gateway/web/irccloud.com/x-grzifmaovbjixtlo> has quit IRC | 00:30 | |
| *** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has quit IRC | 00:56 | |
| *** DvorkinDmitry <DvorkinDmitry!~Dvorkin@59-120-32-26.HINET-IP.hinet.net> has joined #yocto | 01:26 | |
| *** nrossi <nrossi!uid193926@gateway/web/irccloud.com/x-ejuiamfaranoelhq> has joined #yocto | 04:20 | |
| *** kaspter <kaspter!~Instantbi@101.93.194.160> has quit IRC | 04:42 | |
| *** kaspter <kaspter!~Instantbi@124.77.81.26> has joined #yocto | 04:43 | |
| yocti | New news from stackoverflow: Bitbake Server does not start on Windows Subsystem for Linux <https://stackoverflow.com/questions/49370077/bitbake-server-does-not-start-on-windows-subsystem-for-linux> | 04:44 |
| *** kaspter <kaspter!~Instantbi@124.77.81.26> has quit IRC | 04:45 | |
| *** kaspter <kaspter!~Instantbi@124.77.81.26> has joined #yocto | 04:46 | |
| *** hyper_dave <hyper_dave!~quassel@196.188.72.247> has quit IRC | 05:28 | |
| *** kaspter <kaspter!~Instantbi@124.77.81.26> has quit IRC | 05:38 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.168> has joined #yocto | 05:39 | |
| *** jaeckel <jaeckel!~jaeckel@unaffiliated/jaeckel> has quit IRC | 05:53 | |
| DvorkinDmitry | 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 | 05:58 |
| DvorkinDmitry | why? | 05:58 |
| *** camus <camus!~Instantbi@101.93.194.160> has joined #yocto | 05:58 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.168> has quit IRC | 06:01 | |
| *** camus is now known as kaspter | 06:01 | |
| *** ThomasD13 <ThomasD13!~ThomasD13@DSL01.212.114.255.148.ip-pool.NEFkom.net> has joined #yocto | 06:10 | |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto | 06:36 | |
| *** pohly <pohly!~pohly@p54BD5B80.dip0.t-ipconnect.de> has joined #yocto | 06:58 | |
| *** agust <agust!~agust@p54833695.dip0.t-ipconnect.de> has joined #yocto | 07:05 | |
| *** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has joined #yocto | 07:10 | |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto | 07:38 | |
| *** mckoan|away is now known as mckoan | 08:14 | |
| *** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has joined #yocto | 08:18 | |
| *** yann|work <yann|work!~yann@91-170-159-152.subs.proxad.net> has quit IRC | 08:29 | |
| wertigon | Hmmm... | 08:34 |
| wertigon | Allright, so after a lot of cursing, sweat and tears, I finally narrowed down why my mingw sdk refuse to compile | 08:34 |
| wertigon | It is due to the layers meta-browser and it in turn inherits meta-clan | 08:35 |
| wertigon | *meta-clang | 08:35 |
| *** leon-anavi <leon-anavi!~Leon@78.130.245.67> has joined #yocto | 08:35 | |
| wertigon | 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 | 08:37 |
| wertigon | Can this be done? | 08:37 |
| wertigon | e.g. when I type bitbake my-image -c populate_sdk it should ignore those two layers completely | 08:41 |
| LetoThe2nd | nope, i don't think so | 08:41 |
| LetoThe2nd | this contradicts pretty much the whole layer model | 08:41 |
| LetoThe2nd | 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? | 08:42 |
| wertigon | 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 | 08:43 |
| RP | wertigon: You could try setting TOOLCHAIN = "gcc" in the problematic recipes? | 08:43 |
| LetoThe2nd | because if a layer break the build just by its pure inclusion, then it is buggy. | 08:43 |
| LetoThe2nd | but if you actively select something from the layer and it breaks, well, then fix the recipe | 08:44 |
| RP | 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 | 08:44 |
| wertigon | 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 | 08:44 |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto | 08:45 | |
| LetoThe2nd | wertigon: then the layer is probably wellbehaved and the recipes need fixing. | 08:45 |
| wertigon | RP: Ah, that might help; do I put that recipy in my own layer then? :) | 08:45 |
| LetoThe2nd | RP: can i try again and pester you for some multiconfig things? | 08:45 |
| wertigon | I'll try it after my coffee break starting now ^^ | 08:46 |
| RP | LetoThe2nd: it sounds like I missed something previous but yes, you can ask | 08:46 |
| LetoThe2nd | 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 | 08:46 |
| RP | 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 | 08:46 |
| LetoThe2nd | RP: like, struggling with dependency propagation when sstate is involved. | 08:47 |
| RP | LetoThe2nd: that sounds wrong :/ Is a nostamp involved on any of the images? | 08:48 |
| *** camus <camus!~Instantbi@101.93.194.160> has joined #yocto | 08:48 | |
| *** kaspter <kaspter!~Instantbi@101.93.194.160> has quit IRC | 08:48 | |
| *** camus is now known as kaspter | 08:48 | |
| LetoThe2nd | 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 | 08:49 |
| RP | LetoThe2nd: right, it is and you shouldn't have to do that | 08:50 |
| RP | LetoThe2nd: could be a bug :( | 08:51 |
| LetoThe2nd | 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 | 08:51 |
| RP | LetoThe2nd: its good to have it isolated to a specific case like that | 08:52 |
| RP | LetoThe2nd: probably a case of filing a bug and waiting/hoping someone has a chance to debug it | 08:52 |
| LetoThe2nd | RP: want me to file? | 08:52 |
| RP | LetoThe2nd: please | 08:52 |
| LetoThe2nd | RP: ok | 08:53 |
| RP | LetoThe2nd: an automated test reproducing the problem would probably help too | 08:53 |
| RP | sounds like it could be something quite simple to reproduce, maybe even two recipes rather than full images | 08:53 |
| RP | LetoThe2nd: basically the easier it is to reproduce, the faster someone will probably look at it | 08:54 |
| LetoThe2nd | 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? | 08:54 |
| LetoThe2nd | RP: we'll see if we can provide a test case. | 08:55 |
| *** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 08:55 | |
| RP | LetoThe2nd: normal is a multiconfig of '' | 08:56 |
| LetoThe2nd | RP: so ::, basically? | 08:57 |
| RP | LetoThe2nd: I think so | 08:57 |
| LetoThe2nd | RP: thanks! | 08:57 |
| LetoThe2nd | 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. | 09:01 |
| *** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-jatjqccgnezjprnv> has joined #yocto | 09:06 | |
| *** fitzsim <fitzsim!~user@69-165-165-189.dsl.teksavvy.com> has quit IRC | 09:06 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:9a0f> has joined #yocto | 09:10 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto | 09:11 | |
| *** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 09:18 | |
| RP | LetoThe2nd: ok, thanks | 09:20 |
| LetoThe2nd | me being stupid. whats the trick if a source tarball unpacks to a non-canonical path? | 09:21 |
| LetoThe2nd | i think there was soomething to set the extraction directory? or just do S=...? | 09:22 |
| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has quit IRC | 09:22 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 09:23 | |
| *** farnerup <farnerup!~farnerup@h-254-84-175.A137.corp.bahnhof.se> has joined #yocto | 09:30 | |
| *** yann|work <yann|work!~yann@85.118.38.73> has joined #yocto | 09:32 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:9a0f> has quit IRC | 09:54 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:9a0f> has joined #yocto | 09:55 | |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto | 09:57 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:9a0f> has joined #yocto | 09:57 | |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC | 09:59 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 10:12 | |
| mcfrisk | 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" | 10:19 |
| rburton | proper example? | 10:22 |
| LetoThe2nd | RP: concerning the python2 thing from yesterday, rebuilding the container did the trick. no idea what went wrong there. | 10:24 |
| mcfrisk | 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 ??= "" | 10:24 |
| mcfrisk | so that works. I wonder how many bugs I have because of this... | 10:25 |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:9a0f> has quit IRC | 10:25 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:c2b> has joined #yocto | 10:27 | |
| RP | mcfrisk: think "right to left" with variables. ??= sets the thing with that value (which includes the overide). Override expansion happens later | 10:28 |
| RP | FOO_x ??= "y" sets a default value of "y", FOO_x = "z" changes its value to z. Overrides only come later | 10:29 |
| mcfrisk | RP: thanks. Not sure if I should use ?= or ??= in the bbclass though. | 10:29 |
| RP | mcfrisk: it depends on the behaviour you want I guess | 10:35 |
| rburton | 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 '')? | 10:46 |
| rburton | 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 | 10:46 |
| rburton | RP: ^^ is that one of the known problems? | 10:46 |
| rburton | or something fun and exciting in my next branch | 10:46 |
| RP | rburton: not seen it before | 10:47 |
| rburton | dropped the gcc patch from my next | 10:50 |
| rburton | hm devtool selftest does a mdadm cleansstate | 10:52 |
| rburton | could that be breaking the other tests? | 10:52 |
| RP | rburton: is that one where it sets its own sstate directory? | 10:53 |
| RP | rburton: there are some tests which do run clean* but they should have their own sstate dir | 10:54 |
| rburton | ah yes, okay, devtoolbase sets sstate_dir | 10:55 |
| ThomasD13 | 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" | 10:57 |
| ThomasD13 | I don't know if that will affect me, or how to fix it ? | 10:58 |
| *** anujm <anujm!anujm@nat/intel/x-qctufmovciodyzuu> has joined #yocto | 10:59 | |
| *** florian_kc is now known as florian | 11:02 | |
| LetoThe2nd | is there a particular reason why runqemu always wants to get tun/tap up? what about a -nonet option? | 11:22 |
| *** ThomasD13 <ThomasD13!~ThomasD13@DSL01.212.114.255.148.ip-pool.NEFkom.net> has quit IRC | 11:22 | |
| *** kaspter <kaspter!~Instantbi@101.93.194.160> has quit IRC | 11:23 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:c2b> has quit IRC | 11:25 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:9a0f> has joined #yocto | 11:34 | |
| *** berton <berton!~berton@189.103.49.163> has joined #yocto | 11:43 | |
| *** berton <berton!~berton@189.103.49.163> has quit IRC | 11:47 | |
| wertigon | *le sigh* | 11:48 |
| *** berton <berton!~berton@189.103.49.163> has joined #yocto | 11:49 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:9a0f> has quit IRC | 11:58 | |
| *** jklare <jklare!~jklare@157.97.76.18> has quit IRC | 11:58 | |
| *** jklare <jklare!~jklare@157.97.76.18> has joined #yocto | 12:01 | |
| nrossi | 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) | 12:04 |
| RP | nrossi: I'm not 100% sure but I know the builds with that change in showed those reproducible test errors | 12:05 |
| wertigon | I might have been able to reproduce my troubles, building now to double check but: | 12:06 |
| RP | nrossi: I guess I could add just that change and run another test to 100% isolate it but it seemed fairly clear | 12:06 |
| wertigon | Basic problem - meta-browser and/or meta-clang breaks meta-toolchain | 12:06 |
| wertigon | Steps to reproduce: Download Poky, meta-browser, meta-clang, meta-mingw | 12:07 |
| wertigon | Sorry, breaks meta-toolchain when trying to build on meta-mingw on Poky | 12:07 |
| wertigon | Poky-thud even | 12:08 |
| nrossi | 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 :| | 12:12 |
| wertigon | Change all branches to thud, add layers to bblayers.conf, specify the SDKMACHINE | 12:17 |
| wertigon | Compile, everything explodes in a fire | 12:17 |
| RP | nrossi: you can see why I was holding off blaming the patch, I don't quite understand it. | 12:22 |
| RP | nrossi: I guess we should fire a build with just this change in | 12:23 |
| RP | (compared to master) | 12:23 |
| nrossi | 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? | 12:24 |
| *** leitao <leitao!~leitao@2620:10d:c092:380::1:5d6c> has joined #yocto | 12:25 | |
| RP | nrossi: I don't :/ | 12:28 |
| *** leitao <leitao!~leitao@2620:10d:c092:380::1:5d6c> has quit IRC | 12:30 | |
| RP | nrossi: I've fired a couple of test builds with just that in | 12:30 |
| RP | https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/521 https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/530 | 12:33 |
| nrossi | RP: thanks, i will keep an eye on it. Will see if i can figure out why my local master build fails | 12:34 |
| wertigon | Another strange inconsistency | 12:35 |
| wertigon | I get mingw gcc version 7.3 | 12:36 |
| wertigon | but linux gcc version 8.2 | 12:36 |
| wertigon | for sdk | 12:36 |
| LetoThe2nd | trying to use yarn in a recipe do_compile, it gets annoyed over Error: EACCES: permission denied, open '/usr/local/share/.yarnrc' | 12:42 |
| LetoThe2nd | anybody run into this already? | 12:42 |
| *** tgamblin <tgamblin!~tgamblin@128.224.252.2> has joined #yocto | 12:50 | |
| *** JaMa <JaMa!~martin@109.238.218.228> has joined #yocto | 12:52 | |
| *** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 12:56 | |
| *** anujm <anujm!anujm@nat/intel/x-qctufmovciodyzuu> has quit IRC | 12:58 | |
| wertigon | Why isn't meta-mingw gcc same as linux-native gcc? | 13:22 |
| *** yann|work is now known as yann | 13:24 | |
| mcfrisk | would CFLAGS_append_x86_64 work for appending some optimizations for x86_64 targets only? is the variable TUNE_ARCH or some other thing? | 13:27 |
| yann | 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 ? | 13:36 |
| wertigon | Ok, confirmed; meta-browser breaks meta-mingw on standard Yocto in the same way it breaks on meta-arago. | 13:56 |
| wertigon | (thud branch) | 13:56 |
| rburton | and this is why we have the yocto project compatible scripts | 13:57 |
| rburton | to detect layers that make changes without being asked | 13:57 |
| wertigon | rburton: Or might be mingw that breaks browser, but end result is the same :P | 13:57 |
| rburton | wertigon: how does it explode? | 13:58 |
| rburton | wertigon: meta-mingw does export RC, which might be upsetting the browser | 13:58 |
| wertigon | rburton: try the following layers: meta, meta-poky, meta-yocto-bsp, meta-openembedded/meta-oe, meta-clang, leta-browser, meta-mingw | 13:59 |
| rburton | or, you can pastebin the failure and i can look at it | 14:00 |
| wertigon | Put all layers to thud except for meta-browser | 14:00 |
| wertigon | Building the failure right now | 14:00 |
| wertigon | But I'll pastebin in about 5-10 min :) | 14:00 |
| wertigon | (meta-browser has no layers) | 14:00 |
| wertigon | And change SDKMACHINE | 14:01 |
| wertigon | And it'll explode in glorious flames | 14:01 |
| wertigon | If you do bitbake meta-toolchain or populate_sdk | 14:01 |
| *** rcrudo <rcrudo!~rcrudo@i5387F440.versanet.de> has quit IRC | 14:05 | |
| *** rcrudo <rcrudo!~rcrudo@i5387F440.versanet.de> has joined #yocto | 14:06 | |
| RP | nrossi: figured it out. coreutils-ptest adds libmodule-build-perl which has a ptest RDEPENDing on gcc | 14:12 |
| RP | nrossi: so the coreutils change made it appear in the test | 14:12 |
| RP | tgamblin: ^^^ | 14:12 |
| tgamblin | ah, interesting | 14:12 |
| tgamblin | 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 | 14:13 |
| RP | tgamblin: its not that much of an issue but just an interesting part of the tangled web the ptests are causing | 14:14 |
| tgamblin | RP: things to remember when I eventually add more | 14:18 |
| tgamblin | At some point I'd like to add one for libgcrypt | 14:18 |
| RP | tgamblin: I'm definitely keen to see more of them | 14:26 |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC | 14:31 | |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC | 14:38 | |
| wertigon | 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 | 14:40 |
| wertigon | doing a -k bitbake in order to catch most errors | 14:40 |
| *** jij <jij!jonashg@nat/axis/x-bkhfwgluthwgyeqi> has quit IRC | 14:44 | |
| wertigon | rburton: Here ya go! https://pastebin.com/dHWCNUHX | 14:53 |
| GeneralStupid | hi iam stucking at my custom Uboot config... | 14:55 |
| GeneralStupid | I want to have the boot config / environment in a different partition (and redundant but afair this is possible with altbootcmd) | 14:56 |
| GeneralStupid | But for me it looks likt its hard compiled into include/configs/boardname.h And NXP uses a lot of "custom" enviroment... | 14:56 |
| wertigon | We have a separate boot partition that contains Linux kernel image, a squashed rootfs and boot parameters | 15:09 |
| wertigon | I don't think you can have kernel config and image separate, could be wrong | 15:09 |
| wertigon | Would otherwise suggest an overlayfs | 15:09 |
| wertigon | We as in, my company, not yocto project as such. :P | 15:10 |
| wertigon | <-- Just another yocto "user" with noobish skills still | 15:10 |
| wertigon | 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 | 15:17 |
| wertigon | e.g. if your overlay only has /etc/network/interfaces only that file will be replaced in the unified root filesystem | 15:17 |
| *** lfa_ <lfa_!~lfa@217.19.35.51> has quit IRC | 15:20 | |
| *** kpo <kpo!~kpo@eet50.internetdsl.tpnet.pl> has quit IRC | 15:20 | |
| GeneralStupid | wertigon: not kernel config, iam taling about uboot config / environment stuff | 15:21 |
| *** jij <jij!jonashg@nat/axis/x-mgbkucqkcclnrpjh> has joined #yocto | 15:33 | |
| nrossi | 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 ;) | 15:35 |
| wertigon | rburton: Ok, I think I have a theory of why I am seeing strange things with mingw[thud]: | 15:40 |
| wertigon | mingw[thud] does not support clang | 15:40 |
| wertigon | this is since clang makes gcc compiler version 8.2 | 15:41 |
| wertigon | Which mingw[thud] does not support | 15:41 |
| wertigon | Am waiting for a build to finish so I can confirm, but I have a pretty strong suspicion I'm right here :P | 15:42 |
| *** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has quit IRC | 15:51 | |
| *** jklare <jklare!~jklare@157.97.76.18> has quit IRC | 15:55 | |
| *** jklare <jklare!~jklare@157.97.76.18> has joined #yocto | 15:59 | |
| wertigon | Yes, this is confirmed now - gcc is 8.2 if I include clang, 7.3 if I do not | 16:10 |
| wertigon | Great, have a good weekend y'all! | 16:10 |
| milloni | 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 | 16:15 |
| milloni | why would my recipe require libtool .la files? | 16:16 |
| milloni | shouldnt the same info already be in pkg-info? | 16:17 |
| milloni | i've upgraded to a newer yocto and now it removes .la files during install by default | 16:17 |
| milloni | i understand there's REMOVE_LIBTOOL_LA | 16:18 |
| milloni | but im trying to understand why it needs those files at all | 16:24 |
| *** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has quit IRC | 16:24 | |
| milloni | the recipe that fails to build looks just like a regular autotools project | 16:24 |
| milloni | it's using PKG_CHECK_MODULES(GLIB, glib-2.0 >= 2.16, dummy=yes, | 16:25 |
| milloni | i thought that would take everything it needs from the .pc file for glib | 16:26 |
| *** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-jatjqccgnezjprnv> has quit IRC | 16:37 | |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC | 16:42 | |
| *** tgamblin <tgamblin!~tgamblin@128.224.252.2> has quit IRC | 16:45 | |
| rcrudo | 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? | 16:50 |
| *** guerinoni <guerinoni!~guerinoni@host25-141-dynamic.248-95-r.retail.telecomitalia.it> has joined #yocto | 16:52 | |
| kergoth | 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 | 16:56 |
| *** alessioigor <alessioigor!8c69cfe3@out-207-227.elettra.trieste.it> has quit IRC | 16:59 | |
| *** farnerup <farnerup!~farnerup@h-254-84-175.A137.corp.bahnhof.se> has quit IRC | 17:10 | |
| *** hpsy <hpsy!~hpsy@217.66.60.5> has quit IRC | 17:10 | |
| *** yann <yann!~yann@85.118.38.73> has quit IRC | 17:23 | |
| rburton | 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. | 17:27 |
| milloni | in this particular case, it seems that glib (glib itself, unrelated to yocto) stopped producing .la files | 17:28 |
| rburton | yes, it moved to meson | 17:29 |
| RP | nrossi: sorry for the false alarm, its sometimes hard to track down what is coming from where | 17:29 |
| rburton | which doesn't use libtool | 17:29 |
| rburton | so no .la files | 17:29 |
| milloni | and good for them :) | 17:29 |
| milloni | but i've got a project here that insists on building from .la files | 17:29 |
| rburton | 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 | 17:29 |
| milloni | i.e im getting a ".la file not found" error | 17:29 |
| rburton | does it break from a clean build? | 17:29 |
| milloni | clean build of the offending recipe? yes | 17:30 |
| rburton | maybe its actually hitting the .la files directly? | 17:30 |
| milloni | how so? | 17:30 |
| rburton | specifying them directly in the makefiles | 17:30 |
| rburton | is this a public project or something private | 17:30 |
| milloni | hm | 17:30 |
| milloni | unfortunately proprietary code :/ | 17:31 |
| rburton | 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 | 17:31 |
| rburton | 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 | 17:32 |
| rburton | this is one of many reasons why we blast away all .la files by default | 17:32 |
| rburton | RP: ross/next went green if you want to grab it | 17:35 |
| RP | rburton: cool, thanks | 17:36 |
| milloni | the only thing returned by `git grep '\.la'` is | 17:37 |
| *** mckoan is now known as mckoan|away | 17:37 | |
| milloni | lib_LTLIBRARIES = libredacted.la | 17:37 |
| milloni | where "redacted" is the thing im trying to build | 17:37 |
| RP | rburton: did you find a problem with the gcc change or not? | 17:37 |
| rburton | RP: i removed it as you had a hunch | 17:38 |
| rburton | we can fire that at selftest on its own | 17:38 |
| RP | rburton: ok, we've proven that one wrong, just checking I hadn't missed anything | 17:38 |
| rburton | milloni: can you not just use the remove-la class and rebuild the world? | 17:38 |
| rburton | the problem is most likely (2), .la files are incredibly contagious | 17:38 |
| milloni | isn't remove-la on by default now? (zeus) | 17:38 |
| milloni | for autotools.bbclass | 17:39 |
| milloni | it started removing .la files since we upgraded | 17:39 |
| rburton | assuming you're using the default distro conf yes | 17:39 |
| milloni | that started breaking things | 17:39 |
| milloni | which we got around by using REMOVE_LIBTOOL_LA = 0 | 17:40 |
| milloni | but this proprietary recipe is insisting on using .la files | 17:40 |
| milloni | even though i cant find any references to them in the codebase | 17:40 |
| milloni | other than what i pased above | 17:41 |
| rburton | so if you don't set REMOVE_LIBTOOL_LA=0 then what error do you get? | 17:41 |
| milloni | it built after i removed lib_LTLIBRARIES = libredacted.la | 17:42 |
| milloni | we have REMOVE_LIBTOOL_LA = 0 for glib-2.0 | 17:42 |
| milloni | i've not tried without setting it but i assume it doesnt make a difference | 17:43 |
| rburton | honestly, just stop disabling it for glib and fix the real problem | 17:43 |
| *** Chrusel <Chrusel!c1669b04@193.102.155.4> has quit IRC | 17:43 | |
| milloni | since glib-2.0 doesnt produce .la files at all ever since they moved to meson | 17:43 |
| rburton | removing lib_LTLIBRARIES will mean it doesn't build libredacted.la | 17:43 |
| rburton | which means it won't build the library at all | 17:43 |
| milloni | hm | 17:43 |
| milloni | <rburton> honestly, just stop disabling it for glib and fix the real problem | 17:44 |
| milloni | that's what im trying to do now | 17:44 |
| rburton | before i go, my recommendation is to undo anything you changed re libtool and do a build with a clean tmp | 17:44 |
| milloni | okay, i'll try that, thanks | 17:44 |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 17:48 | |
| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 17:54 | |
| *** wertigon <wertigon!8addfa13@138.221.250.19> has quit IRC | 17:56 | |
| *** lucaceresoli <lucaceresoli!~lucaceres@45.11.168.109.cust.ip.kpnqwest.it> has quit IRC | 18:00 | |
| *** yann <yann!~yann@91-170-159-152.subs.proxad.net> has joined #yocto | 18:27 | |
| *** hpsy <hpsy!~hpsy@85.203.15.23> has joined #yocto | 18:29 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 18:38 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 18:48 | |
| *** Domin1k <Domin1k!c1669b04@193.102.155.4> has quit IRC | 18:54 | |
| *** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has joined #yocto | 19:32 | |
| *** roussinm <roussinm!~mroussin@ipagstaticip-d73c7528-4de5-0861-800b-03d8b15e3869.sdsl.bell.ca> has joined #yocto | 20:44 | |
| *** pohly <pohly!~pohly@p54BD5B80.dip0.t-ipconnect.de> has quit IRC | 20:51 | |
| *** mischief <mischief!~mischief@216.126.196.60> has quit IRC | 20:51 | |
| *** guerinoni <guerinoni!~guerinoni@host25-141-dynamic.248-95-r.retail.telecomitalia.it> has quit IRC | 21:02 | |
| *** nrossi <nrossi!uid193926@gateway/web/irccloud.com/x-ejuiamfaranoelhq> has quit IRC | 21:04 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 21:13 | |
| *** berton <berton!~berton@189.103.49.163> has quit IRC | 21:13 | |
| *** BobPungartnik <BobPungartnik!~BobPungar@179.177.244.225> has joined #yocto | 21:16 | |
| *** sagner <sagner!~ags@37.17.234.113> has quit IRC | 21:35 | |
| *** lexano <lexano!~lexano@CPEa021b7ac59c9-CMf0f249028110.cpe.net.cable.rogers.com> has quit IRC | 21:47 | |
| *** falstaff <falstaff!~quassel@37.17.234.113> has quit IRC | 22:01 | |
| *** falstaff <falstaff!~quassel@37.17.234.113> has joined #yocto | 22:03 | |
| *** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has quit IRC | 22:07 | |
| *** lexano <lexano!lexano@gateway/vpn/nordvpn/lexano> has joined #yocto | 22:09 | |
| *** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/kiwiirc.com/ip.208.88.110.46> has quit IRC | 22:09 | |
| *** falstaff <falstaff!~quassel@37.17.234.113> has quit IRC | 22:16 | |
| *** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has joined #yocto | 22:20 | |
| *** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has quit IRC | 22:25 | |
| *** roussinm <roussinm!~mroussin@ipagstaticip-d73c7528-4de5-0861-800b-03d8b15e3869.sdsl.bell.ca> has quit IRC | 22:38 | |
| *** lexano <lexano!lexano@gateway/vpn/nordvpn/lexano> has quit IRC | 22:50 | |
| *** anujm <anujm!~anujm@134.134.137.73> has joined #yocto | 22:54 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 23:15 | |
| *** agust <agust!~agust@p54833695.dip0.t-ipconnect.de> has quit IRC | 23:15 | |
| *** lexano <lexano!lexano@gateway/vpn/nordvpn/lexano> has joined #yocto | 23:25 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 23:30 | |
| *** champagneg <champagneg!~gchamp@ipagstaticip-d73c7528-4de5-0861-800b-03d8b15e3869.sdsl.bell.ca> has quit IRC | 23:44 | |
| *** anujm <anujm!~anujm@134.134.137.73> has quit IRC | 23:46 | |
| *** elvispre <elvispre!~elvispre@2001:8b0:e0:884d:99db:5cdc:4b13:fabc> has quit IRC | 23:46 | |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!