| *** kaspter <kaspter!~Instantbi@222.67.188.168> has quit IRC | 00:26 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 00:27 | |
| *** kaspter <kaspter!~Instantbi@222.67.152.154> has joined #yocto | 00:27 | |
| *** kaspter <kaspter!~Instantbi@222.67.152.154> has quit IRC | 01:16 | |
| *** kaspter <kaspter!~Instantbi@124.77.81.26> has joined #yocto | 01:16 | |
| *** DvorkinDmitry <DvorkinDmitry!~Dvorkin@59-120-32-26.HINET-IP.hinet.net> has quit IRC | 01:17 | |
| *** DvorkinDmitry <DvorkinDmitry!~Dvorkin@59-120-32-26.HINET-IP.hinet.net> has joined #yocto | 01:37 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 01:38 | |
| *** kaspter <kaspter!~Instantbi@124.77.81.26> has quit IRC | 01:42 | |
| *** kaspter <kaspter!~Instantbi@124.77.81.26> has joined #yocto | 01:43 | |
| *** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has joined #yocto | 01:48 | |
| *** camus <camus!~Instantbi@124.77.81.26> has joined #yocto | 01:58 | |
| *** kaspter <kaspter!~Instantbi@124.77.81.26> has quit IRC | 01:59 | |
| *** camus is now known as kaspter | 01:59 | |
| tgamblin | evening | 02:02 |
|---|---|---|
| *** kaspter <kaspter!~Instantbi@124.77.81.26> has quit IRC | 02:28 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.174> has joined #yocto | 02:31 | |
| *** camus <camus!~Instantbi@124.77.81.26> has joined #yocto | 03:16 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.174> has quit IRC | 03:17 | |
| *** camus is now known as kaspter | 03:17 | |
| *** nrossi <nrossi!uid193926@gateway/web/irccloud.com/x-rwzaktyrkigjkrbb> has joined #yocto | 03:42 | |
| *** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has quit IRC | 03:47 | |
| *** armpit <armpit!~armpit@12.206.169.141> has joined #yocto | 04:43 | |
| *** kaspter <kaspter!~Instantbi@124.77.81.26> has quit IRC | 04:46 | |
| *** kaspter <kaspter!~Instantbi@124.77.81.26> has joined #yocto | 04:46 | |
| *** kaspter <kaspter!~Instantbi@124.77.81.26> has quit IRC | 05:28 | |
| *** kaspter <kaspter!~Instantbi@101.93.194.160> has joined #yocto | 05:28 | |
| *** khem <khem!~khem@unaffiliated/khem> has quit IRC | 05:40 | |
| *** khem <khem!~khem@unaffiliated/khem> has joined #yocto | 05:41 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.245.67> has joined #yocto | 05:46 | |
| *** xtron <xtron!~xtron@110.93.212.98> has joined #yocto | 06:16 | |
| *** ThomasD13 <ThomasD13!~ThomasD13@DSL01.212.114.255.148.ip-pool.NEFkom.net> has joined #yocto | 06:23 | |
| *** pohly <pohly!~pohly@p54BD5B80.dip0.t-ipconnect.de> has joined #yocto | 06:24 | |
| *** armpit <armpit!~armpit@12.206.169.141> has quit IRC | 06:28 | |
| xtron | included selinux in distro_features then removed it, now getting dbus, iproute do_package_qa error "iproute2-ss requires libselinux.so.1 ..." seeing that kinda build chain issues in package-management and systemd/syvinit, using yocto zeus, anyone else? | 06:30 |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto | 06:45 | |
| *** agust <agust!~agust@p54833695.dip0.t-ipconnect.de> has joined #yocto | 06:51 | |
| *** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has joined #yocto | 07:04 | |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto | 07:08 | |
| *** fatalhalt <fatalhalt!~fatalhalt@2601:244:4d01:52df:225:90ff:feda:2428> has quit IRC | 07:11 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 07:12 | |
| *** frsc <frsc!~frsc@2003:a:e7a:6200:a427:c148:e286:fbe7> has joined #yocto | 07:29 | |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto | 07:41 | |
| *** wertigon <wertigon!8addfa13@138.221.250.19> has joined #yocto | 07:42 | |
| wertigon | Ugggh... Stuck between a rock and a hard place now -_-;; So meta-mingw[thud] works if I temporarily remove meta-clang and meta-browser from my build. Two problems arise however; | 07:43 |
| wertigon | 1. meta-clang bumps gcc crosscompiler version to 8.2 | 07:44 |
| wertigon | (from 7.3) | 07:45 |
| wertigon | 2. Requires some fugly hacks that I have mostly scripted up right now | 07:45 |
| wertigon | If I can get meta-mingw to also bump up compiler version to 8.2 I should be home | 07:46 |
| wertigon | Ugly solution that needs to be prettied up, but home | 07:47 |
| wertigon | Hmm, correction, seems to perhaps be meta-browser that is the culprit here | 07:49 |
| *** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 07:57 | |
| *** alessioigor <alessioigor!8c69cfe3@out-207-227.elettra.trieste.it> has joined #yocto | 07:58 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 08:01 | |
| *** yann <yann!~yann@91-170-159-152.subs.proxad.net> has quit IRC | 08:23 | |
| *** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has joined #yocto | 08:24 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto | 08:31 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 08:33 | |
| *** mckoan|away is now known as mckoan | 08:55 | |
| *** yann <yann!~yann@85.118.38.73> has joined #yocto | 09:24 | |
| *** goliath <goliath!~goliath@82.150.214.1> has joined #yocto | 09:26 | |
| *** farnerup <farnerup!~farnerup@h-254-84-175.A137.corp.bahnhof.se> has joined #yocto | 09:26 | |
| wertigon | Is there a way to force meta-mingw to use and build the same compiler poky use? | 09:28 |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 09:34 | |
| rburton | wertigon: by default it does use the same one, so i presume the problem is that meta-clang is overriding the cross compiler but not the sdk compiler | 09:43 |
| yocti | New news from stackoverflow: Yocto, Meta-selinux does not work on raspberry pi 3 <https://stackoverflow.com/questions/59136024/yocto-meta-selinux-does-not-work-on-raspberry-pi-3> | 09:55 |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:9c57> has joined #yocto | 09:58 | |
| GeneralStupid | How does UBBOOT_CONFIG work? i created my own uboot config but iam not able to compile it in yocto (but it works in plain uboot). I always get Can't find default configuration "arch/../configs/......defconfig"! | 09:58 |
| qschulz | GeneralStupid: where is your defconfig in plain u-boot? what's its name? what's the exact error? | 10:04 |
| *** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has joined #yocto | 10:16 | |
| *** nayfe <nayfe!uid259604@gateway/web/irccloud.com/x-phogcypsfraxiufb> has joined #yocto | 10:23 | |
| yocti | New news from stackoverflow: How I run qemu in yocto with movbe CPU feature? <https://stackoverflow.com/questions/59136416/how-i-run-qemu-in-yocto-with-movbe-cpu-feature> | 10:25 |
| *** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has quit IRC | 10:28 | |
| *** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has joined #yocto | 10:28 | |
| *** hpsy <hpsy!~hpsy@217.66.60.5> has joined #yocto | 10:30 | |
| *** lucaceresoli <lucaceresoli!~lucaceres@45.11.168.109.cust.ip.kpnqwest.it> has joined #yocto | 10:34 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:9c57> has quit IRC | 10:46 | |
| *** JaMa <JaMa!~martin@109.238.218.228> has joined #yocto | 10:46 | |
| wertigon | rburton: if I remove meta-clang I get version 7.3 (which is my native version) | 10:53 |
| wertigon | if I add meta-browser and meta-clang I get 8.2 | 10:53 |
| wertigon | In poky[thud]/meta/recipes-devtools/gcc/ I find gcc_7.3 and gcc_8.2 | 10:58 |
| rburton | so blame meta-clang and its toolchain switching | 10:58 |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 10:59 | |
| *** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 11:00 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 11:08 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:9c57> has joined #yocto | 11:17 | |
| rburton | RP: hm one of the master selftest runs hung in drm/virtio stuff | 11:17 |
| rburton | paging kanavin_ https://autobuilder.yoctoproject.org/typhoon/#/builders/56/builds/837/steps/8/logs/step2d | 11:17 |
| kanavin_ | rburton, looking | 11:18 |
| rburton | a few fails in there | 11:18 |
| RP | rburton: just what we need, more intermittent failures. We should perhaps rerun it on that worker assuming kanavin_ doesn't need logs | 11:22 |
| wertigon | rburton: Ah, I finally see what happens here... meta-browser is the only package that bumps up the version to 8.2, so by removing it the version drops to 7.3 | 11:23 |
| kanavin_ | rburton, RP that failure is probably specific to opensuse 15.0 | 11:23 |
| wertigon | So, the default gcc is 7.3 and we do not change it | 11:23 |
| kanavin_ | so I could add one more distro exception to the test | 11:23 |
| wertigon | Off to check which option I need to change to force version 8.2 in my image :) | 11:24 |
| rburton | i'll refire it to see if it happens on demand | 11:39 |
| kanavin_ | rburton, new python ptests need headers in /usr/include, but adding -dev to RDEPENDS of -ptests makes package_qa complain | 11:40 |
| rburton | fired on suse 150 and 151 | 11:40 |
| kanavin_ | hints? | 11:40 |
| RP | rburton: thanks | 11:40 |
| RP | kanavin_: can't we disable that hint for that package? | 11:41 |
| rburton | kanavin_: insane-skip for ptest package | 11:41 |
| kanavin_ | ah! I didn't realize insane_skip can be package specific? | 11:41 |
| kanavin_ | I thought it's for entire recipe :-/ | 11:41 |
| *** berton <berton!~berton@189.103.49.163> has joined #yocto | 11:44 | |
| *** berton <berton!~berton@189.103.49.163> has quit IRC | 11:45 | |
| *** berton <berton!~berton@189.103.49.163> has joined #yocto | 11:47 | |
| *** jklare <jklare!~jklare@157.97.76.18> has quit IRC | 11:59 | |
| *** jklare <jklare!~jklare@157.97.76.18> has joined #yocto | 12:00 | |
| wertigon | Ugh, why isn't this cooperating... | 12:04 |
| wertigon | So I try setting PREFERRED_VERSION_gcc-cross-${TARGET_ARCH} to 8.2 | 12:04 |
| wertigon | And then I get | 12:05 |
| wertigon | ERROR: gcc-runtime-7.3.0-r0 do_configure: Function failed: do_configure | 12:05 |
| *** Crofton|work <Crofton|work!~Crofton@2601:5c0:c100:b84:c22d:c40:ab44:9e37> has quit IRC | 12:05 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:9c57> has quit IRC | 12:05 | |
| *** learningc <learningc!~pi@121.122.98.56> has joined #yocto | 12:07 | |
| rburton | wertigon: i guess you need to set everything to the same version | 12:18 |
| rburton | there's a variable for that, GCCVERSION | 12:18 |
| wertigon | GCCVERSION does nothing if I set it in the command line | 12:18 |
| wertigon | But I'll try local.conf | 12:19 |
| rburton | yeah its not an envrionment var | 12:19 |
| rburton | very few environment variables pass into the bitbake context | 12:19 |
| wertigon | Does SDKMACHINE pass into it? | 12:19 |
| wertigon | I know MACHINE works atleast | 12:20 |
| wertigon | See, I know the solution is easy it | 12:20 |
| wertigon | it's just a matter of finding where to define it :P | 12:21 |
| rburton | did you isolate the problem to just meta-clang | 12:25 |
| wertigon | Hmm, to meta-browser, yes. | 12:25 |
| rburton | what does meta-browser have to do with compiler version used | 12:25 |
| wertigon | meta-clang included - sdkgcc = 7.3 | 12:25 |
| wertigon | meta-browser (and meta-clang) - sdkgcc = 8.2 | 12:26 |
| rburton | well, drop meta-browser and verify its just meta-clang | 12:26 |
| wertigon | I did | 12:26 |
| wertigon | It's meta-browser that changes stuff, not meta clang | 12:26 |
| wertigon | Or it might be meta-browser+meta-clang | 12:28 |
| rburton | well browser depends on clang | 12:28 |
| rburton | but clang is the one that pokes at the toolchain selection | 12:28 |
| rburton | thus my suggestion that its not meta-browser at all | 12:29 |
| rburton | what branches are you using? | 12:29 |
| *** tgamblin <tgamblin!~tgamblin@128.224.252.2> has joined #yocto | 12:29 | |
| wertigon | thud branches | 12:29 |
| wertigon | Since ti is not compatible with anything more recent... yet | 12:29 |
| wertigon | We've just taken the decision to try and move away from arago though | 12:30 |
| wertigon | so we'll just have meta-processor-sdk and meta-ti in the future | 12:30 |
| kanavin_ | rburton, 15.0 failed in the same way. Waiting for the verdict from 15.1 | 12:30 |
| wertigon | Aha, here is something! :) | 12:30 |
| wertigon | In conf/distro/include/toolchain.gcc I have SDKGCC version set to 7.3% | 12:31 |
| wertigon | Through ?= ofc | 12:31 |
| wertigon | rburton: The biggest problem I have right now is that mingw and clang isn't compatible in thud | 12:32 |
| wertigon | However, I also do not need clang in my SDK files | 12:33 |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:9c57> has joined #yocto | 12:40 | |
| wertigon | rburton: Out of interest, are clang and mingw compatible in zeus? | 12:41 |
| rburton | never tried | 12:42 |
| rburton | on my todo list for a long time has been to merge the toolchain selection thing into core itself | 12:42 |
| rburton | as meta-iss has a clone of the clang's toolchain switching class too | 12:42 |
| wertigon | Ok, I'll try the default Yocto layers a little bit later then :) | 12:43 |
| wertigon | rburton: I have isolated the mingw/clang issues in thud btw in stock poky | 12:44 |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:9c57> has quit IRC | 12:45 | |
| rburton | if you've an easy reproducer involving those layers and nothing else please do replicate with master and file a bug | 12:47 |
| wertigon | just add meta-mingw, meta-clang and meta-openembedded to your bblayers.conf, change branches to thud and try to build the SDK with SDKMACHINE=x86_64-mingw32 bitbake <image> | 12:47 |
| wertigon | sorry, bitbake meta-toolchain | 12:47 |
| wertigon | And things should explode rather spectacularly :) | 12:47 |
| wertigon | rburton: Where to file the bug? | 12:48 |
| rburton | wertigon: i'd say bugzilla.yoctoproject.org to start, if its all khem's fault we can let him keep it there or move somewhere else | 12:50 |
| wertigon | Thanks ^^ b | 12:51 |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:9c57> has joined #yocto | 12:52 | |
| ThomasD13 | Hey, I would like to work on the actual kernel code of my linux image. This kernel contains already a set of patches and config fragments. Does Yocto provide a build step which applies all patches on the kernel source code and provide the final .config? | 12:56 |
| ThomasD13 | I would like to have a folder which I can just run "make ..." to build the kernel and modules with the correct (patched) sourcecode and .config | 12:57 |
| rburton | ok who broke my branch | 12:58 |
| rburton | kanavin_! | 12:59 |
| rburton | | ./boost/python/detail/wrap_python.hpp:57:11: fatal error: pyconfig.h: No such file or directory | 13:00 |
| rburton | | 57 | # include <pyconfig.h> | 13:00 |
| rburton | | | ^~~~~~~~~~~~ | 13:00 |
| ThomasD13 | According to the OpenEmbedded Build Sytem Workflow, "Patch Application" and "Config/Compile/Autoconf" sounds good. But how to "intercept and extract" the source files from yocto build process | 13:00 |
| rburton | checking whether to use python... /home/pokybuild/yocto-worker/edgerouter/build/build/tmp/work/i686-nativesdk-pokysdk-linux/gdb-cross-canadian-mips64/8.3.1-r0/python | 13:00 |
| rburton | checking for python3.8... no | 13:00 |
| rburton | configure: error: no usable python found at /home/pokybuild/yocto-worker/edgerouter/build/build/tmp/work/i686-nativesdk-pokysdk-linux/gdb-cross-canadian-mips64/8.3.1-r0/python | 13:00 |
| rburton | i wonder if thats the abi thing | 13:01 |
| *** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has quit IRC | 13:03 | |
| ThomasD13 | wertigon, why do you move away from aragon? | 13:08 |
| cengiz_io | hello. will adding `dbg-pkgs` to EXTRA_IMAGE_FEATURES provide a glibc with debug symbols to my distro? | 13:31 |
| cengiz_io | I need to cpuprofile an app and since there are no symbols in my glibc, gperftools blames strange functions like gnu_get_libc_version | 13:32 |
| LetoThe2nd | cengiz_io: should, yes. | 13:34 |
| LetoThe2nd | cengiz_io: but be aware that the size change can be dramatic | 13:34 |
| cengiz_io | LetoThe2nd thanks. also the complete rebuild will be automatic right? (probably take x4 times long..) | 13:37 |
| LetoThe2nd | cengiz_io: yes, and no. : | 13:38 |
| *** xtron <xtron!~xtron@110.93.212.98> has quit IRC | 13:41 | |
| rburton | kanavin_: fwiw, python3.bb has PYTHON_BINABI variable that isn't used | 13:44 |
| *** Hauke <Hauke!~Hauke@hauke-m.de> has quit IRC | 13:48 | |
| *** King_InuYasha <King_InuYasha!~King_InuY@fedora/ngompa> has quit IRC | 14:02 | |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC | 14:04 | |
| rburton | RP: nativesdk recipe looking for linux/capability.h is failing. native works as it looks on build host. why wouldn't nativesdk do the same? | 14:14 |
| rburton | or why wouldn't it be pulling nativesdk-libc-headers into the build ? | 14:16 |
| kergoth | i doubt it would be possible to build the crosssdk toolchain at all without linux-libc-headers, no? hmm | 14:18 |
| rburton | oh idiot boy, i'm sitting in mingw | 14:18 |
| rburton | shocking lack of linux headers in a mingw sdk ;) | 14:18 |
| LetoThe2nd | rburton: not it a pub? | 14:19 |
| * LetoThe2nd confirms the "idiot boy", then. | 14:19 | |
| rburton | maybe overloading a single build dir isnot sensible | 14:19 |
| kanavin_ | rburton, I fixed the "m" thing, will drop the PYTHON_BINABI as well and confirm that boost is still ok | 14:22 |
| rburton | kanavin_: i wonder if its worth adding a selftest to verify that python3native is doing the right thing so we get a proper error like 'cannot find library, check PYTHON_ABI etc" instead of some recipes failing | 14:23 |
| rburton | khem: RRECOMMENDS_${PN} += "${@'libcxx-dev libcxx-staticdev compiler-rt-dev compiler-rt-staticdev' if '${CLANGSDK}' else ''}" doesn't do what you think | 14:24 |
| rburton | bool("0") -> True | 14:24 |
| rburton | wertigon: probably fixed your problem | 14:28 |
| rburton | solution is in fact in the readme | 14:29 |
| RP | rburton: I was scratching my head like kergoth until you mentioned mingw :) | 14:34 |
| rburton | wertigon: first fix is on the house. CLANGSDK="" in your local.conf. | 14:35 |
| cengiz_io | LetoThe2nd adding dbg-pkg to extra features seems to build so quick that I'm not sure it did the right thing | 14:35 |
| cengiz_io | will check libc.so now | 14:35 |
| cengiz_io | perhaps I need to add DEBUG_BUILD = "1" as well? | 14:37 |
| wertigon | rburton: Thanks, I have also submitted a bug report in the clang github | 14:39 |
| wertigon | Will try it now :) | 14:39 |
| wertigon | rburton: I have managed to figure out exactly where we set the compiler options and everything now, as well | 14:41 |
| wertigon | So, I might actually have this one bagged now :) | 14:42 |
| wertigon | Thank you so much for the help! | 14:43 |
| wertigon | Hmm, CLANGSDK="" did nothing for me :( | 14:46 |
| wertigon | But no worries, I can run without CLANG until done | 14:46 |
| *** ecdhe <ecdhe!~quassel@unaffiliated/ecdhe> has joined #yocto | 14:49 | |
| *** AndersD <AndersD!~AndersD@h83-209-191-235.cust.a3fiber.se> has joined #yocto | 14:51 | |
| *** diego_r <diego_r!~diego@217-133-17-98.static.clienti.tiscali.it> has quit IRC | 14:53 | |
| rburton | kanavin_: https://autobuilder.yoctoproject.org/typhoon/#/builders/20/builds/1547/steps/8/logs/step1b <-- libdnf failing (ross/next) | 14:54 |
| rburton | (centos 7, have fun) | 14:55 |
| * rburton runs to get the kids | 14:55 | |
| wertigon | Going home too, thanks for the help! | 14:58 |
| kanavin_ | rburton, that does look old gcc failure :( | 15:00 |
| kanavin_ | are we planning to retire centos 7 in favor of centos 8? | 15:00 |
| RP | kanavin_: eventually, yes. We're not there yet | 15:01 |
| kanavin_ | RP: then libdnf/dnf updates have to be deferred | 15:02 |
| RP | kanavin_: is this a C++ issue? (I've not looked at the failure) | 15:02 |
| kanavin_ | RP: /home/pokybuild/yocto-worker/buildtools/build/build/tmp/hosttools/g++ -DLIBDNF_UNSTABLE_API -D_FILE_OFFSET_BITS=64 -Dlibdnf_EXPORTS -I/home/pokybuild/yocto-worker/buildtools/build/build/tmp/work/x86_64-linux/libdnf-native/0.38.1-r0/recipe-sysroot-native/usr/lib/pkgconfig/../../../usr/include/gio-unix-2.0 -I/home/pokybuild/yocto-worker/buildtools/build/build/tmp/work/x86_64-linux/libdnf-native/0.38.1-r0/recipe-sysroot-native/usr/lib/pkgconfig/../../. | 15:03 |
| kanavin_ | ./usr/include -I/home/pokybuild/yocto-worker/buildtools/build/build/tmp/work/x86_64-linux/libdnf-native/0.38.1-r0/recipe-sysroot-native/usr/lib/pkgconfig/../../../usr/include/libmount -I/home/pokybuild/yocto-worker/buildtools/build/build/tmp/work/x86_64-linux/libdnf-native/0.38.1-r0/recipe-sysroot-native/usr/lib/pkgconfig/../../../usr/include/blkid -I/home/pokybuild/yocto-worker/buildtools/build/build/tmp/work/x86_64-linux/libdnf-native/0.38.1-r0/recipe- | 15:03 |
| kanavin_ | sysroot-native/usr/lib/pkgconfig/../../../usr/include/glib-2.0 -I/home/pokybuild/yocto-worker/buildtools/build/build/tmp/work/x86_64-linux/libdnf-native/0.38.1-r0/recipe-sysroot-native/usr/lib/pkgconfig/../../../usr/lib/glib-2.0/include -I/home/pokybuild/yocto-worker/buildtools/build/build/tmp/work/x86_64-linux/libdnf-native/0.38.1-r0/recipe-sysroot-native/usr/lib/pkgconfig/../../../usr/include/json-c -I/home/pokybuild/yocto-worker/buildtools/build/build | 15:03 |
| kanavin_ | /tmp/work/x86_64-linux/libdnf-native/0.38.1-r0/recipe-sysroot-native/usr/lib/pkgconfig/../../../usr/include/libxml2 -I/home/pokybuild/yocto-worker/buildtools/build/build/tmp/work/x86_64-linux/libdnf-native/0.38.1-r0/git -I/home/pokybuild/yocto-worker/buildtools/build/build/tmp/work/x86_64-linux/libdnf-native/0.38.1-r0/git/libdnf/utils -I/home/pokybuild/yocto-worker/buildtools/build/build/tmp/work/x86_64-linux/libdnf-native/0.38.1-r0/git/libdnf/transactio | 15:03 |
| kanavin_ | n -isystem/home/pokybuild/yocto-worker/buildtools/build/build/tmp/work/x86_64-linux/libdnf-native/0.38.1-r0/recipe-sysroot-native/usr/include -O2 -pipe -std=c++11 -Wmissing-declarations -fPIC -DPACKAGE_VERSION=\"0.38.1\" -DGETTEXT_DOMAIN=\"libdnf\" -DG_LOG_DOMAIN=\"libdnf\" -DTESTDATADIR=\"/home/pokybuild/yocto-worker/buildtools/build/build/tmp/work/x86_64-linux/libdnf-native/0.38.1-r0/git/data/tests\" -Wcast-align -Wno-uninitialized -Wredundant-decls | 15:03 |
| kanavin_ | -Wwrite-strings -Wformat-nonliteral -Wmissing-format-attribute -Wsign-compare -Wtype-limits -Wuninitialized -Wall -Wl,--as-needed -MD -MT libdnf/CMakeFiles/libdnf.dir/dnf-context.cpp.o -MF libdnf/CMakeFiles/libdnf.dir/dnf-context.cpp.o.d -o libdnf/CMakeFiles/libdnf.dir/dnf-context.cpp.o -c /home/pokybuild/yocto-worker/buildtools/build/build/tmp/work/x86_64-linux/libdnf-native/0.38.1-r0/git/libdnf/dnf-context.cpp | 15:03 |
| kanavin_ | static std::atomic_flag cfgMainLoaded = ATOMIC_FLAG_INIT; | 15:03 |
| kanavin_ | ^ | 15:03 |
| kanavin_ | oops sorry! | 15:03 |
| kanavin_ | let's try again | 15:03 |
| kanavin_ | static std::atomic_flag cfgMainLoaded = ATOMIC_FLAG_INIT; | 15:04 |
| kanavin_ | ^ | 15:04 |
| kanavin_ | error: ‘atomic_flag’ in namespace ‘std’ does not name a type | 15:04 |
| kanavin_ | seems like a C++ issue indeed, I don't get this on ubuntu 18.04 | 15:04 |
| *** hpsy <hpsy!~hpsy@217.66.60.5> has quit IRC | 15:06 | |
| *** AndersD <AndersD!~AndersD@h83-209-191-235.cust.a3fiber.se> has quit IRC | 15:07 | |
| RP | kanavin_: That I think is C++11 which I guess centos7 isn't | 15:07 |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:9c57> has quit IRC | 15:08 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:9c57> has joined #yocto | 15:09 | |
| kanavin_ | RP, right, so I'll take out the libdnf upgrade from the set, and move them to a 'later' branch of mine | 15:09 |
| tgamblin | RP: Think I've figured out at least part of that selftest skip count bug | 15:11 |
| RP | kanavin_: would be good to know where debian8 stands too | 15:12 |
| tgamblin | attempting to import cairo in setUpClass and raising the exception if it can't be imported is causing it to count a single skip for the entire class | 15:12 |
| RP | tgamblin: ah, sounds good :) | 15:12 |
| RP | tgamblin: right, that isn't really correct though | 15:13 |
| tgamblin | Right. Just moving the try/except into each of the test functions makes it count correctly | 15:13 |
| tgamblin | It's a little ugly, though | 15:14 |
| RP | tgamblin: can we fix the class handling? | 15:14 |
| RP | kanavin_: debian8 is gcc 4.9.2 FWIW (centos7 is 4.8.5) | 15:14 |
| tgamblin | Possibly. I found another project that saw a similar issue and fixed it, I'm looking at their patch to see what was done | 15:14 |
| RP | tgamblin: I agree we could just move it but that opens up the problem to happen again in future | 15:15 |
| kanavin_ | RP, right, I can't easily test that though | 15:16 |
| RP | kanavin_: we could run ross/next specifically on that worker? | 15:17 |
| tgamblin | RP: Alright. I'll keep looking into the related UNKNOWN results issue and see if there's a way to do the skip fix more cleanly | 15:17 |
| *** ericch <ericch!~ericch@50-205-235-218-static.hfc.comcastbusiness.net> has joined #yocto | 15:17 | |
| kanavin_ | RP: yes please | 15:17 |
| RP | kanavin_: trying, although I worry it will pull libdnf-native from sstate | 15:18 |
| RP | kanavin_: may need to add a PR bump to the brach I guess | 15:18 |
| RP | tgamblin: I suspect if you move the skip to the test, the UNKNOWN issue is fixed too. I would like to fix the underlying problem if possible though | 15:18 |
| *** elGamal <elGamal!~elg@178-175-148-4.static.as43289.net> has quit IRC | 15:19 | |
| *** elGamal <elGamal!~elg@178-175-148-4.static.as43289.net> has joined #yocto | 15:19 | |
| RP | kanavin_: we're in luck, its building it | 15:20 |
| RP | kanavin_: blew up :( | 15:21 |
| kanavin_ | RP: right. I believe Debian 8 is supported until mid-2020 | 15:22 |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto | 15:22 | |
| RP | kanavin_: right :/. Just ensuring we know what gates libdnf I guess | 15:23 |
| *** goliath <goliath!~goliath@82.150.214.1> has quit IRC | 15:24 | |
| kanavin_ | RP: yep, sometimes I wish we would not rely on the host gcc :-/ | 15:25 |
| RP | kanavin_: hard not to. We could go "selfhosted" if we mandated people use our own buildtools tarball... | 15:26 |
| RP | we'd need a gcc-nativesdk recipe too | 15:27 |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC | 15:27 | |
| *** champagneg <champagneg!~gchamp@ipagstaticip-d73c7528-4de5-0861-800b-03d8b15e3869.sdsl.bell.ca> has joined #yocto | 15:27 | |
| kanavin_ | RP: but would it be crazy to build gcc-native in addition to gcc-cross? | 15:27 |
| kanavin_ | e.g. use the host gcc only for build gcc itself | 15:27 |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC | 15:28 | |
| *** jwessel <jwessel!~jwessel@128.224.252.2> has joined #yocto | 15:30 | |
| *** ThomasD13 <ThomasD13!~ThomasD13@DSL01.212.114.255.148.ip-pool.NEFkom.net> has quit IRC | 15:30 | |
| RP | kanavin_: not crazy, just adds significantly to the build time | 15:32 |
| kergoth | i'd rather just build in docker than use gcc-native, personally.. could even use a yocto-built docker image to self-host if we really wanted to.. | 15:34 |
| * kergoth shrugs | 15:34 | |
| kanavin_ | kergoth, this still doesn't solve the problem of having to hold back version updates because those updates don't work with 5 year old compilers | 15:36 |
| kergoth | i don't see the issue with updating the host, particularly if that host is a controlled container, unless you're under tight constraints due to needing to deal with compliance requirements | 15:38 |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto | 15:41 | |
| kanavin_ | kergoth, what I mean is that we now have to hold back version upgrades in oe-core master because of a continuing need to support older distributions. | 15:41 |
| RP | kergoth: having OE/Yocto "run anywhere" on distros is one of our valuable features, for better or worse | 15:41 |
| *** stephano <stephano!~stephano@c-73-164-244-205.hsd1.or.comcast.net> has joined #yocto | 15:41 | |
| RP | yes, you can use containers or other solutions but it would make the project less attractive to people :/ | 15:42 |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC | 15:43 | |
| RP | its a balancing act and a tough one at times :( | 15:43 |
| *** armpit <armpit!~armpit@12.206.169.141> has joined #yocto | 15:45 | |
| *** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/kiwiirc.com/ip.208.88.110.46> has joined #yocto | 15:45 | |
| mcfrisk | containers have been and are mandatory to assure reproducible builds. I can't imagine working without one, or rolling out the build setup for developers with full freedom to use random distros and versions of SW. | 15:49 |
| mcfrisk | it was especially important when host contamination was a bigger problem, e.g. before recipe specific sysroots | 15:50 |
| kergoth | fair enough. i do think if container use is sufficiently transparent it's almost a non-issue other than the additional requirement for podman or docker on the host. use of pyrex or equivalent means i almost never have to care that it's in a container, except i don't have to clutter up my host with unnecessary installed oe-core dependencies | 15:51 |
| * kergoth shrugs | 15:51 | |
| Ad0 | what's the diff between warrior and warrior-next? | 15:51 |
| kergoth | the latter is where changes sit while being tested before merged to the former, generally.. | 15:51 |
| Ad0 | thanks ! | 15:51 |
| JPEW | kergoth: Speaking of Pyrex, I have some changes I'm trying out... Since you're the only known user outside of my company, would you like to give some input? | 15:52 |
| Ad0 | and is bitbake totally independent of, say, warrior? should I always be on latest or something :) | 15:52 |
| kergoth | JPEW: ha, sure :) | 15:53 |
| Ad0 | on openembedded-core | 15:53 |
| kergoth | Ad0: bitbake does need to match up with the layers, at least a certain release branch/tag is needed for a given yocto release, but the branch naming is different unfortunately. this was discussed recently by the TSC and will be improved | 15:53 |
| Ad0 | ok! I just saw something related to "warrior" in tags for bitbake so I wound back to warrior-21.0.2 (3e61d700a05d2e0f68de3b37ab6d4005a5d07620) | 15:54 |
| *** hpsy <hpsy!~hpsy@85.203.15.105> has joined #yocto | 15:55 | |
| *** berton <berton!~berton@189.103.49.163> has quit IRC | 15:58 | |
| *** berton <berton!~berton@189.103.49.163> has joined #yocto | 15:59 | |
| *** berton <berton!~berton@189.103.49.163> has quit IRC | 16:01 | |
| moto-timo | ANNOUNEMENT: meta-python2 is live http://lists.openembedded.org/pipermail/openembedded-devel/2019-December/203370.html | 16:01 |
| LetoThe2nd | moto-timo: is this like a "celebrate!" announcement, or a "quick, ran and find cover!" one? :-) | 16:02 |
| fray | it's a celebration that we all have to find cover | 16:02 |
| tgamblin | exciting news! | 16:03 |
| *** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has joined #yocto | 16:03 | |
| LetoThe2nd | fray: ah. thanks for explaining. | 16:04 |
| rburton | moto-timo: i admire your dedication to history preserving, i'd have totally just copied/pasted :) | 16:04 |
| rburton | moto-timo: https://git.openembedded.org/meta-python2/tree/ <-- i see pipfiles | 16:05 |
| rburton | moto-timo: also believe it should dynamic-layers the meta-oe-needing bits out | 16:06 |
| kergoth | moto-timo: congrats! nicely done | 16:06 |
| kergoth | agreed, dynamic-layers would be good | 16:07 |
| LetoThe2nd | moto-timo: besides me being annoying, thanks for all the effort :) | 16:08 |
| kergoth | i'm guessing the pipfiles were to ease use of kas to manually run the same tests as are configured in the gitlab ci configuration, but i doubt either will be used while it's on git.oe.org :) | 16:09 |
| kergoth | still, up to him how he wants to maintain the thing, workflow wise | 16:09 |
| kanavin_ | moto-timo, \0/ | 16:10 |
| *** frsc <frsc!~frsc@2003:a:e7a:6200:a427:c148:e286:fbe7> has quit IRC | 16:11 | |
| *** comptroller <comptroller!~comptroll@47-213-230-143.paolcmtc01.res.dyn.suddenlink.net> has joined #yocto | 16:11 | |
| *** alessioigor <alessioigor!8c69cfe3@out-207-227.elettra.trieste.it> has quit IRC | 16:11 | |
| *** alessioigor <alessioigor!8c69cfe3@out-207-227.elettra.trieste.it> has joined #yocto | 16:12 | |
| RP | moto-timo: nice! :) | 16:17 |
| *** berton <berton!~berton@189.103.49.163> has joined #yocto | 16:17 | |
| *** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has quit IRC | 16:21 | |
| kergoth | JPEW: where should i look for the changes, have a branch? | 16:21 |
| JPEW | kergoth: I'm finishing them up now, but they'll be in the "next" branch | 16:22 |
| kergoth | cool | 16:22 |
| *** berton <berton!~berton@189.103.49.163> has quit IRC | 16:26 | |
| *** berton <berton!~berton@189.103.49.163> has joined #yocto | 16:27 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:9c57> has quit IRC | 16:29 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:9c57> has joined #yocto | 16:31 | |
| RP | https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/520 is an autobuilder failure where "oe-selftest -r signing.LockedSignatures.test_locked_signatures" fails | 16:34 |
| RP | Can anyone look at that test and tell me how this mode of failure is possible :/ | 16:34 |
| stephano | moto-timo: shiney :) | 16:34 |
| RP | It adds a bbappens, reruns the build and the sig still matches | 16:34 |
| RP | stephano: nice to see you're still around :) | 16:34 |
| rburton | hey stephano! | 16:40 |
| stephano | RP: nice to be seen! | 16:40 |
| rburton | accidentally join did you? | 16:40 |
| stephano | rburton: howdy partner! | 16:40 |
| stephano | I have to live up to all that "ping me on IRC" hype I preach at events. :-D | 16:41 |
| rburton | lol | 16:41 |
| fullstop | With systemd init how does one configure the network? A lot of targets require network and the system hangs until I plug an ethernet cable in and obtain a dhcp lease. I'd like to set it to a fixed address. | 16:43 |
| rburton | fullstop: either use the traditional ifupdown configuration files (same as debian), or systemd-networkd | 16:43 |
| fullstop | rburton: thanks! | 16:45 |
| fullstop | so systemd will use ifupdown if they are there? | 16:45 |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:9c57> has quit IRC | 16:46 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:9c57> has joined #yocto | 16:47 | |
| JPEW | RP: Huh, weird. It did reparse | 16:47 |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:9c57> has quit IRC | 16:48 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 16:51 | |
| *** diego_r <diego_r!~diego@81.29.205.101> has joined #yocto | 16:52 | |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:9c57> has joined #yocto | 16:53 | |
| RP | JPEW: yes. I don't understand :( | 16:59 |
| RP | JPEW: hashequiv was active | 16:59 |
| *** farnerup <farnerup!~farnerup@h-254-84-175.A137.corp.bahnhof.se> has quit IRC | 16:59 | |
| *** guerinoni <guerinoni!~guerinoni@host199-102-dynamic.50-82-r.retail.telecomitalia.it> has joined #yocto | 17:03 | |
| JPEW | Hmm, ya hashequiv could cause that if the target hash was in the database | 17:06 |
| *** hpsy <hpsy!~hpsy@85.203.15.105> has quit IRC | 17:06 | |
| rburton | fullstop: more systemd wont touch networking unless you configure networkd | 17:06 |
| JPEW | RP: It would have to be that the new hash was in the database and marked to report the unihash that was the taskhash of the original? | 17:07 |
| *** hpsy <hpsy!~hpsy@217.66.60.5> has joined #yocto | 17:07 | |
| *** jmiehe <jmiehe!~Thunderbi@p578c106e.dip0.t-ipconnect.de> has quit IRC | 17:10 | |
| RP | JPEW: right, and that shouldn't be able to happen? :/ | 17:12 |
| RP | JPEW: its one reason I put the uuid in the variable it sets | 17:12 |
| JPEW | Ah, right | 17:13 |
| RP | JPEW: I don't understand it at all :( | 17:13 |
| RP | JPEW: I also think I have the hashequiv change I made backwards :/ | 17:13 |
| RP | JPEW: trying to understand https://autobuilder.yoctoproject.org/typhoon/#/builders/97/builds/633 from that build too | 17:14 |
| RP | JPEW: I think it renames the stamp and the hash without the hash being in the sstate cache :/ | 17:14 |
| *** yann <yann!~yann@85.118.38.73> has quit IRC | 17:14 | |
| JPEW | I was going to ask about that... I think I get what you are trying to do and why, but don't think I quite follow the mechaism | 17:14 |
| RP | 6d55a78873fecf73b3a36b3b9326fae1a0ca3bd1c21f65ef9dfbfb2922ecae16 is, 6b59aec65be0166ea7bde7d7bc2004f822b13e842cb42142811487f867aac573 is not | 17:14 |
| JPEW | Ah, ya if the stamp file was renamed that would make it think it didn't need to build | 17:15 |
| RP | JPEW: I thought that was correct since we'd told hashequiv to make a mapping. I now think that is wrong and we're creating the wrong mapping if that works :/ | 17:15 |
| *** vineela <vineela!~vtummala@134.134.139.76> has joined #yocto | 17:15 | |
| JPEW | OK, that would make sense. | 17:16 |
| JPEW | RP: So I *think* what you are trying to do is make a given taskhash report a specific unihash? | 17:18 |
| JPEW | e.g. when meta-toolchain gets a new taskhash because it's deps have changed, but we've already restored it from sstate, so that new taskhash should be mapped to the old unihash that the server previously reported | 17:19 |
| RP | JPEW: yes | 17:22 |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:9c57> has quit IRC | 17:23 | |
| JPEW | Ok, then I *think* that in that case, the outhash is irrelevent. You should be able to add the new hash to the database with an "invalid" outhash (e.g. empty string) and eveything will sort out | 17:24 |
| JPEW | We don't need the old outhash in the new entry because the old entry already has that outhash -> unihash mapping | 17:25 |
| JPEW | So when the server looks up that outhash, it will get the same unihash (from the old entry) and the new one doesn't need it | 17:26 |
| RP | JPEW: right, I wasn't sure so I was trying to get the outhash | 17:27 |
| RP | JPEW: can you check if my logic is reversed in my patch? | 17:27 |
| JPEW | Sure | 17:28 |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:9c57> has joined #yocto | 17:30 | |
| RP | JPEW: I think I'd better rewrite this with less confusing variable names | 17:31 |
| JPEW | Ya, I went through and tried to renamed them to unihash_old and unihash_new | 17:32 |
| JPEW | But... I think the other problem is that you're capturing the old unihash and passing that as the new taskhash. You really want the old taskhash | 17:33 |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:9c57> has quit IRC | 17:34 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.245.67> has quit IRC | 17:34 | |
| JPEW | And, it does look backwards to me. You're passing the old unihash as the taskhash and the new unihash as the new one... instead pass the new taskhash as the taskhash and the old unihash as the unihash | 17:35 |
| RP | JPEW: I'm just confusing myself :( | 17:38 |
| RP | JPEW: One thing does worry me - what if an mapping for the hash already exists on the hashserver? | 17:38 |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:9c57> has joined #yocto | 17:38 | |
| JPEW | We always take the oldest hash, so the new one will be recorded but ignored | 17:39 |
| RP | JPEW: I think the client needs to error out though as the build wouldn't be reproducible | 17:39 |
| *** leitao <leitao!~leitao@2620:10d:c092:200::1:9c57> has quit IRC | 17:40 | |
| RP | I'm hoping this doesn't happen for anything we already have sstate artefacts for | 17:40 |
| JPEW | RP: Are you worried the existing DB on the AB is bad, or there is some other case that would trigger the logic? | 17:41 |
| JPEW | RP: I think I have a handle on this. If you want, I'll work up a patch for testing | 17:42 |
| RP | JPEW: actually, having stared at this, I think the code is right, the bitbake interpretation is wrong | 17:42 |
| RP | JPEW: I think that is wrong is that bitbake runqueue doesn't reset the task unihash to match the mapping it just created | 17:43 |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC | 17:43 | |
| RP | and since it queried once, it would now cache the 'bad' value | 17:43 |
| RP | JPEW: there should be a "oh, my task unihash was reset again" event here | 17:44 |
| RP | JPEW: that stamp renaming is half the issue but explains why sstate broke | 17:45 |
| JPEW | reset to the value it had before the rehash? | 17:46 |
| moto-timo | rburton: I haven't used dynamic-layers that much, but I like the idea... could that bring in cyrus-sasl from meta-networking as well (for python-ldap)? | 17:47 |
| RP | JPEW: yes | 17:49 |
| RP | JPEW: giving it a go with the tweak in -next | 17:57 |
| RP | JPEW: I have more renaming locally but didn't want to risk breaking things | 17:57 |
| JPEW | OK: Here's my (untested) take: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=jpew/reproducible&id=93cf630038947656ea5b4ecc161177609ca247a5 | 17:58 |
| JPEW | Hmm, "old" and "new" in this case is confusing :) | 18:00 |
| RP | JPEW: yes, one reason I haven't gone further with those names | 18:01 |
| RP | since we want the old value | 18:01 |
| RP | JPEW: I'll have a look later, thanks | 18:02 |
| * RP -> food | 18:03 | |
| kergoth | moto-timo: dynamic-layers is just a way to pull in bbappends only when the layer that has the main recipe exists, or recipes whose dependencies are only in that layer, potentially.. | 18:04 |
| *** mckoan is now known as mckoan|away | 18:06 | |
| *** armpit <armpit!~armpit@12.206.169.141> has quit IRC | 18:08 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto | 18:15 | |
| *** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 18:25 | |
| *** guerinoni <guerinoni!~guerinoni@host199-102-dynamic.50-82-r.retail.telecomitalia.it> has quit IRC | 18:28 | |
| *** ericch <ericch!~ericch@50-205-235-218-static.hfc.comcastbusiness.net> has quit IRC | 18:32 | |
| *** dfrey <dfrey!~dfrey@172.103.152.101> has joined #yocto | 18:32 | |
| *** ericch <ericch!~ericch@50-205-235-218-static.hfc.comcastbusiness.net> has joined #yocto | 18:33 | |
| dfrey | I have defined a bluez5_5.52 recipe in one layer (BBFILE_PRIORITY=40) and there is a bluez5_5.50 recipe in another layer (BBFILE_PRIORITY=8). It seems that while building bluez5_5.52, files from the bluez5_5.50 recipe's folder are being found. In the log.do_unpack file, I see this: "DEBUG: Searching for init in paths: <a bunch of paths>" and then: "NOTE: Unpacking <path to bluez5_5.50 | 18:41 |
| dfrey | files>/init". | 18:41 |
| kergoth | that's odd, that shouldn't be possible. | 18:42 |
| dfrey | Should it even be searching in the recipe directory of the 5.50 version? | 18:43 |
| kergoth | JPEW: ah, interesting, instead of re-sourcing the init you're capturing the vars it sets, that's cleaner. i like that we can specify the full buildcommand now. requiring PYREXCONFFILE will mean slightly different integration, but probably won't be problematic, and the user won't have to worry about the config in an old build dir being out of date with their preferences, presumably. | 19:10 |
| kergoth | (reading your personal next branch, cause i got bored) | 19:10 |
| JPEW | lol, ya. | 19:10 |
| JPEW | Yes, I think it will be better, specifically because the oe-init-build-env now happens in the container | 19:11 |
| JPEW | Meaning, when I init 2.2 on my Fedora 31 machine, it won't complain about 'python' being python3 anymore :) | 19:12 |
| *** roussinm <roussinm!~mroussin@ipagstaticip-d73c7528-4de5-0861-800b-03d8b15e3869.sdsl.bell.ca> has joined #yocto | 19:14 | |
| khem | kergoth: https://github.com/YoeDistro/yoe-distro/blob/master/envsetup.sh#L441-L485 | 19:15 |
| khem | thats how I wrap docker behind bitbake cmd | 19:15 |
| JPEW | khem: Ya, we started with something very similar | 19:18 |
| khem | devtool is painful with this env perhaps fixable but havent cared enough so far | 19:19 |
| kergoth | yeah, i used something along those lines myself before too | 19:19 |
| khem | I will be happy to take in any improvements into yoe if you have suggestions | 19:20 |
| JPEW | khem: I've been meaning to see what it would take to run yoe in pyrex; I don't think it would hard except new images would be needed b/c you don't build any hosttools | 19:21 |
| JPEW | err, try to avoid building -native recipes | 19:21 |
| kergoth | pyrex is basically a nicer version of what wrapper you have there, but configurable with a config file instead of hardcoding the paths to map | 19:21 |
| kergoth | s/what/that/ | 19:22 |
| kergoth | https://github.com/kergoth/meta-mentor/compare/setup-script-fixes...kergoth:pyrex integrates it into the mentor setup scripts, pretty painless | 19:24 |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 19:27 | |
| *** rcw <rcw!~rcw@128.224.252.2> has joined #yocto | 19:31 | |
| khem | seems good can I use a different docker image ? | 19:31 |
| khem | or does pyrex expects things from image | 19:31 |
| JPEW | khem: Yes | 19:31 |
| JPEW | There is a minimal set of support the image requires | 19:32 |
| JPEW | If you want to make your own, start from one of our "base" images | 19:32 |
| JPEW | or an "oe" image might be better for yoe if all you want is to add more pacakges so that you don't have to build -native recipes | 19:33 |
| khem | i am yet to see what it solves for me | 19:34 |
| *** elvispre <elvispre!~elvispre@2001:8b0:e0:884d:99db:5cdc:4b13:fabc> has quit IRC | 19:36 | |
| kergoth | i like that 1) more configurable, less hardcoded, 2) uses shims not shell functions, so less reliant on shell particulars, and wraps recipetool/devtool/etc by default too | 19:40 |
| JPEW | khem: Perhaps you haven't run into this, but we had a lot of quirks we had to account for when running in a container | 19:41 |
| *** yann <yann!~yann@91-170-159-152.subs.proxad.net> has joined #yocto | 19:42 | |
| *** mischief <mischief!~mischief@wopr.sciops.net> has joined #yocto | 19:44 | |
| *** pohly <pohly!~pohly@p54BD5B80.dip0.t-ipconnect.de> has quit IRC | 19:47 | |
| *** tgamblin_ <tgamblin_!~tgamblin@128.224.252.2> has joined #yocto | 19:53 | |
| *** nrossi_ <nrossi_!uid193926@gateway/web/irccloud.com/x-olqdmglqjdmokaap> has joined #yocto | 19:54 | |
| *** nayfe_ <nayfe_!uid259604@gateway/web/irccloud.com/x-dewqumehmljfnhaw> has joined #yocto | 19:55 | |
| Ad0 | I am looking at rburton's https://github.com/rossburton/customdistro which seems like a great starting point. however I get "ERROR: Nothing PROVIDES 'customimage' when running bitback customimage. there's a file called https://github.com/rossburton/customdistro/blob/master/meta-custom/recipes-example/images/customimage.bb but I am not sure how this works with bitbake. is it suppose to make the file name into a a build name? | 19:56 |
| Ad0 | bitbake* | 19:56 |
| *** u1106_ <u1106_!~quassel@163.172.172.46> has joined #yocto | 19:56 | |
| *** elGamal <elGamal!~elg@178-175-148-4.static.as43289.net> has quit IRC | 19:57 | |
| kergoth | did you add the layer to BBLAYERS? | 19:58 |
| Ad0 | hm I thought it was supposed to magically do that for me with the export TEMPLATECONF=../meta-custom/conf | 19:59 |
| Ad0 | my mission is to make a "source control / git friendly" distro with clean structure instead of messing around with toaster | 20:00 |
| Ad0 | it might be a shell issue if the paths are not set | 20:00 |
| *** JPEW_ <JPEW_!~JPEW@2600:1f16:181:f300:d350:982:b6f5:216c> has joined #yocto | 20:00 | |
| *** elGamal <elGamal!~elg@104.244.209.100> has joined #yocto | 20:01 | |
| *** diego_r <diego_r!~diego@81.29.205.101> has quit IRC | 20:02 | |
| *** tgamblin <tgamblin!~tgamblin@128.224.252.2> has quit IRC | 20:02 | |
| *** nayfe <nayfe!uid259604@gateway/web/irccloud.com/x-phogcypsfraxiufb> has quit IRC | 20:02 | |
| *** nrossi <nrossi!uid193926@gateway/web/irccloud.com/x-rwzaktyrkigjkrbb> has quit IRC | 20:02 | |
| *** lexano <lexano!lexano@gateway/vpn/nordvpn/lexano> has quit IRC | 20:02 | |
| *** jij <jij!jonashg@nat/axis/x-mgbkucqkcclnrpjh> has quit IRC | 20:02 | |
| *** meow` <meow`!~sbourdeli@147.ip-167-114-97.net> has quit IRC | 20:02 | |
| *** halfhalo <halfhalo!halfhalo@nasadmin/webteam/halfhalo> has quit IRC | 20:02 | |
| *** mdp <mdp!sid49840@gateway/web/irccloud.com/x-lewgwbbquvzunqub> has quit IRC | 20:02 | |
| *** JPEW <JPEW!~JPEW@2600:1f16:181:f300:d350:982:b6f5:216c> has quit IRC | 20:02 | |
| *** Azoff <Azoff!foobar@unaffiliated/azoff> has quit IRC | 20:02 | |
| *** u1106 <u1106!~quassel@163.172.172.46> has quit IRC | 20:02 | |
| *** zbooth <zbooth!~zbooth@2600:1f16:181:f300:d350:982:b6f5:216c> has quit IRC | 20:02 | |
| *** revsbech <revsbech!~revsbech@static.82.67.76.144.clients.your-server.de> has quit IRC | 20:02 | |
| *** nayfe_ is now known as nayfe | 20:02 | |
| *** nrossi_ is now known as nrossi | 20:02 | |
| *** diego_r <diego_r!~diego@81.29.205.101> has joined #yocto | 20:02 | |
| *** meow` <meow`!~sbourdeli@147.ip-167-114-97.net> has joined #yocto | 20:03 | |
| *** mdp <mdp!sid49840@gateway/web/irccloud.com/x-nkepsnpbscijdfaw> has joined #yocto | 20:05 | |
| *** zbooth <zbooth!~zbooth@ec2-18-219-251-161.us-east-2.compute.amazonaws.com> has joined #yocto | 20:06 | |
| *** halfhalo <halfhalo!halfhalo@nasadmin/webteam/halfhalo> has joined #yocto | 20:06 | |
| *** lexano <lexano!lexano@gateway/vpn/nordvpn/lexano> has joined #yocto | 20:07 | |
| dfrey | Regarding my message about my bluez recipe problems above... Does it make sense that my $FILESPATH contains directories from two different layers when I run "bitbake -c unpack bluez5"? | 20:13 |
| JPEW_ | dfrey: depends: If they are added via bbappend then I think it would. If it's two .bb files, that wouldn't be what I would expect | 20:14 |
| kergoth | only if one of the layers is using a bbappend to add to FILESEXTRAPATHS | 20:14 |
| Ad0 | kergoth, I made an idiot mistake, it works now. was environment / shell issue | 20:14 |
| dfrey | There are bbappend files in play. I'll look at that | 20:15 |
| Ad0 | and I had to delete the build directory | 20:15 |
| *** JPEW_ is now known as JPEW | 20:15 | |
| *** jij <jij!jonashg@nat/axis/x-xlzlevzpfxtviawf> has joined #yocto | 20:15 | |
| kergoth | ah, good to hear you got it sorted | 20:15 |
| Ad0 | thanks for your help kergoth , I am trying to "port" the toaster configs over to this structure | 20:16 |
| Ad0 | I executed it directly instead of source / . | 20:17 |
| *** Hauke <Hauke!~Hauke@hauke-m.de> has joined #yocto | 20:17 | |
| dfrey | JPEW, kergoth: I think I'm headed in the right direction now. Thanks for the hints | 20:17 |
| frosteyes | Hi folks. Is it possible to use INCOMPATIBLE_LICENSE on image level? | 20:24 |
| frosteyes | e.g. I have a base.inc file for all my images, where I want to prevent GPLv3 elements. | 20:25 |
| frosteyes | I though also have "-debug" versions of the images, only used locally, so GPLv3 is okay. | 20:26 |
| *** tgamblin_ <tgamblin_!~tgamblin@128.224.252.2> has quit IRC | 20:26 | |
| LetoThe2nd | frosteyes: no, you' probably have to switch it in/out through DISTROs | 20:26 |
| LetoThe2nd | frosteyes: as per the documentation, INCOMPATIBLE_LICENSE works on the build- not the image creation stage: https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-INCOMPATIBLE_LICENSE | 20:28 |
| LetoThe2nd | hence it has to be set through a .conf file | 20:28 |
| frosteyes | LetoThe2nd: thanks. | 20:28 |
| frosteyes | I think it would have been a likely candidate for the image creation.. | 20:29 |
| *** JaMa <JaMa!~martin@109.238.218.228> has quit IRC | 20:30 | |
| LetoThe2nd | frosteyes: only if your POV is limited to the GPLv3 topic | 20:30 |
| roussinm | Hello y'all! We were wondering why $IMAGE_NAME from bitbake.conf is a hard assignment and not a default assignment? To modify the $IMAGE_NAME the only way is to patch the file, because bitbake.conf is somehow applied after our configurations. | 20:31 |
| LetoThe2nd | because "i do not want to go anything by this license into the image" is just something different than "this license is incompatible with my usecase". and the variable, as per documentation, is expressing the latter. | 20:31 |
| LetoThe2nd | roussinm: why do you want to modify IMAGE_NAME at all? | 20:32 |
| frosteyes | LetoThe2nd: understand the difference. Do you then reommned something for the first.. | 20:32 |
| roussinm | LetoThe2nd: because the machine name inside is redundant because it's already in a directory which has the machine name. | 20:33 |
| frosteyes | Alternativ if some have created a python solution as a pre task for the image. | 20:33 |
| frosteyes | Or would I be looking into creating it my self.. | 20:33 |
| LetoThe2nd | roussinm: thats a side effect, but what is it that you *actually* want to archieve? | 20:33 |
| LetoThe2nd | frosteyes: switch DISTROs. | 20:33 |
| LetoThe2nd | frosteyes: your debug distro can happily just he the normal one with gplv3 switched on. | 20:34 |
| roussinm | LetoThe2nd: What I would like to achieve is to remove the machine name from the image name, because for us it's redundant | 20:34 |
| frosteyes | LetoThe2nd: needing to switch distro for debug image, just create more overhead.. E.g. need to either provide it from cmd or need to edit local.conf, where 2 images, would just be switch image target. | 20:36 |
| frosteyes | But it is properly easier to do it the yocto way, by having several distros, even though, I think it is a chumbersome way of doing it. | 20:37 |
| LetoThe2nd | roussinm: we do rather do this through just adding a symlink in the end that bears our desired name. | 20:37 |
| LetoThe2nd | frosteyes: a) its the way it is b) it is for a reason: local data versus glabal data c) feel free to send patches for review. | 20:38 |
| rburton | Ad0: did you use . custom-init-env? | 20:42 |
| roussinm | LetoThe2nd: Are you referring to IMAGE_LINK_NAME, because this is too an hard assignment | 20:42 |
| rburton | Ad0: ah ok you sorted it | 20:42 |
| LetoThe2nd | roussinm: i'm not referring to anything specific at the moment, i don't have the code handy. i'm just pointing out that if all you need is a different, more convenient name for the end result, this might be a way less invasive way of archieving it. | 20:43 |
| Ad0 | thanks rburton :) yeah I did in the end :) | 20:45 |
| Ad0 | seems to build fine so far! | 20:47 |
| roussinm | LetoThe2nd: We did something like that in the past, but we though it was not a clean way to do it. If I want to change IMAGE_LINK_NAME or IMAGE_NAME, I think we could make it possible through bitbake.conf default assignment. Which is IMO simplier/friendly then having an 'addtask' something to create your image name. | 20:50 |
| roussinm | s/something/somewhere/ | 20:52 |
| LetoThe2nd | kergoth: can you maybe comment on the image name? ^^^^^^^^^^^^ | 20:52 |
| Ad0 | what happens if not all meta layers are warrior that I need? can I just get the thud one? | 20:52 |
| LetoThe2nd | Ad0: try and find out. thats the only option you have | 20:53 |
| Ad0 | ok so it's technically possible | 20:53 |
| LetoThe2nd | Ad0: yes. | 20:53 |
| Ad0 | thanks | 20:54 |
| *** Azoff <Azoff!foobar@unaffiliated/azoff> has joined #yocto | 21:02 | |
| *** berton <berton!~berton@189.103.49.163> has quit IRC | 21:15 | |
| *** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto | 21:20 | |
| *** vmeson <vmeson!~rmacleod@24-52-239-53.cable.teksavvy.com> has quit IRC | 21:24 | |
| *** nrossi <nrossi!uid193926@gateway/web/irccloud.com/x-olqdmglqjdmokaap> has quit IRC | 21:26 | |
| *** cconlon <cconlon!~cconlon@72.175.11.38> has joined #yocto | 21:30 | |
| *** rcw <rcw!~rcw@128.224.252.2> has quit IRC | 21:30 | |
| RP | JPEW: messed up the patch, retesting... | 21:33 |
| JPEW | ok | 21:33 |
| *** armpit <armpit!~armpit@2601:202:4180:a5c0:51a5:502e:8fc:9836> has joined #yocto | 21:36 | |
| *** BobPungartnik <BobPungartnik!~BobPungar@177.41.206.57> has joined #yocto | 21:47 | |
| *** BobPungartnik <BobPungartnik!~BobPungar@177.41.206.57> has quit IRC | 21:48 | |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC | 22:00 | |
| *** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC | 22:17 | |
| rburton | RP: should we announce that py2 will be removed from oe-core on e.g next monday? | 22:19 |
| RP | rburton: yes, good idea | 22:20 |
| RP | rburton: remind me to put in weekly status tomorrow. Do you want to send something out or should I? | 22:21 |
| rburton | i can knock something up now | 22:21 |
| *** nayfe <nayfe!uid259604@gateway/web/irccloud.com/x-dewqumehmljfnhaw> has quit IRC | 22:23 | |
| rburton | RP: fired a new next, hopefully this time its actually green ;) | 22:28 |
| rburton | mail sent | 22:28 |
| rburton | short and sweet | 22:28 |
| RP | rburton: thanks :) | 22:35 |
| *** Sandrita <Sandrita!d0586e2e@gateway/web/cgi-irc/kiwiirc.com/ip.208.88.110.46> has quit IRC | 22:40 | |
| * RP ponders splitting sstate into a further set of subdirs | 22:43 | |
| RP | would take the autobuilder from 145,000 files in a directory to 570 which might not upset nfs so much | 22:44 |
| RP | its not currently scaling :/ | 22:44 |
| armpit | rburton, thanks for the email | 22:44 |
| armpit | sorry, added a stable branch notice to yours | 22:51 |
| armpit | RP, I say go for it.. | 22:52 |
| *** cconlon <cconlon!~cconlon@72.175.11.38> has quit IRC | 22:53 | |
| Marex | RP: hey uh, is it possible to build an image which has both preempt-rt patched and non-preempt-rt-patched kernel images in it , from a single bitbake run ? | 22:57 |
| Marex | RP: I guess that's not what the multiconfig or whatever that multi- thingie name was is for | 22:58 |
| *** jofr <jofr!~jofr@193.182.166.3> has quit IRC | 23:04 | |
| *** jofr <jofr!~jofr@193.182.166.3> has joined #yocto | 23:05 | |
| *** wooosaiiii <wooosaiiii!~prix@89-212-21-243.static.t-2.net> has quit IRC | 23:07 | |
| *** wooosaiiii <wooosaiiii!~prix@89-212-21-243.static.t-2.net> has joined #yocto | 23:10 | |
| RP | Marex: multiconfig would let you do that | 23:11 |
| RP | Marex: it is possible to build two kernels in the same build too, if they namespace themselves the right way | 23:11 |
| *** diego_r <diego_r!~diego@81.29.205.101> has quit IRC | 23:17 | |
| *** vineela <vineela!~vtummala@134.134.139.76> has quit IRC | 23:25 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC | 23:31 | |
| Marex | RP: is that the right tool for the job though ? | 23:45 |
| *** agust <agust!~agust@p54833695.dip0.t-ipconnect.de> has quit IRC | 23:47 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 23:56 | |
| RP | Marex: it depends. You told me what you wanted to achieve and I said there are two ways you can do it. Whether they're "right" depends on information I don't have | 23:56 |
| Marex | RP: I want to ship both preempt-rt and non-preempt-rt patched kernel (and possibly xenomai-patched kernel) in the same image for one device | 23:58 |
| Marex | RP: I would very much like to stick with linux-yocto if possible | 23:58 |
| RP | Marex: in which case you need three kernel recipes (can just be copies of linux-yocto which change PN and inherit everything else) | 23:59 |
| RP | Marex: two of the kernel recipes need to set a different kernel module namespace | 23:59 |
| Marex | RP: that's all ? I recall it used to be awfully complicated when I last tried | 23:59 |
| RP | (package namespace) | 23:59 |
Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!