| *** la_croix <la_croix!~la_croix@cpc97624-walt24-2-0-cust98.13-2.cable.virginm.net> has quit IRC | 00:03 | |
| *** davisr <davisr!~davisr@cpe-184-58-235-7.wi.res.rr.com> has joined #yocto | 00:11 | |
| *** la_croix <la_croix!~la_croix@cpc97624-walt24-2-0-cust98.13-2.cable.virginm.net> has joined #yocto | 00:11 | |
| *** ericch <ericch!~ericch@50-205-235-218-static.hfc.comcastbusiness.net> has quit IRC | 00:12 | |
| *** vineela <vineela!~vtummala@134.134.139.74> has quit IRC | 00:13 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.177> has quit IRC | 00:58 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.174> has joined #yocto | 00:58 | |
| *** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 01:03 | |
| *** dreyna_ <dreyna_!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has joined #yocto | 01:13 | |
| *** georgem <georgem!~georgem@216.21.169.52> has quit IRC | 01:13 | |
| *** georgem <georgem!~georgem@216.21.169.52> has joined #yocto | 01:13 | |
| *** dreyna <dreyna!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has quit IRC | 01:16 | |
| *** learning1 <learning1!~pi@121.121.99.187> has quit IRC | 01:18 | |
| *** learning1 <learning1!~pi@121.121.99.187> has joined #yocto | 01:27 | |
| *** nslu2-log <nslu2-log!~nslu2-log@milla.nas-admin.org> has quit IRC | 01:30 | |
| *** nslu2-log <nslu2-log!~nslu2-log@milla.nas-admin.org> has joined #yocto | 01:31 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.174> has quit IRC | 01:31 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.168> has joined #yocto | 01:32 | |
| *** camus <camus!~Instantbi@222.67.188.168> has joined #yocto | 01:35 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.168> has quit IRC | 01:36 | |
| *** camus is now known as kaspter | 01:36 | |
| *** sirus71 <sirus71!ac3a8b5a@172.58.139.90> has joined #yocto | 02:18 | |
| sirus71 | if I'm building from x86_64 to rapsberry pi 4, and i'm bitbaking meta-toolchain-qt5 how do I get meta-qt5 to use the qmake.conf file found in https://code.qt.io/cgit/qt/qtbase.git/tree/mkspecs/devices/linux-rasp-pi4-v3d-g++/qmake.conf | 02:19 |
|---|---|---|
| *** kaspter <kaspter!~Instantbi@222.67.188.168> has quit IRC | 02:24 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.168> has joined #yocto | 02:25 | |
| sirus71 | or if there is a particular forum to post this on | 02:31 |
| *** sirus71 <sirus71!ac3a8b5a@172.58.139.90> has quit IRC | 03:00 | |
| *** King_InuYasha <King_InuYasha!~King_InuY@fedora/ngompa> has joined #yocto | 03:15 | |
| *** camus <camus!~Instantbi@222.67.188.168> has joined #yocto | 03:31 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.168> has quit IRC | 03:33 | |
| *** camus is now known as kaspter | 03:33 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.168> has quit IRC | 04:14 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.168> has joined #yocto | 04:14 | |
| *** radeks <radeks!~radeks@185-15-80-246.ksi-system.net> has joined #yocto | 04:21 | |
| *** camus <camus!~Instantbi@222.67.188.168> has joined #yocto | 04:35 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.168> has quit IRC | 04:36 | |
| *** camus is now known as kaspter | 04:36 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.168> has quit IRC | 05:04 | |
| *** kaspter <kaspter!~Instantbi@222.67.152.154> has joined #yocto | 05:04 | |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto | 05:18 | |
| *** kroon <kroon!~kroon@213.185.29.22> has joined #yocto | 05:26 | |
| LetoThe2nd | sven^: thank, will look into it | 05:49 |
| *** agust <agust!~agust@p54833695.dip0.t-ipconnect.de> has joined #yocto | 05:49 | |
| *** camus <camus!~Instantbi@222.67.188.176> has joined #yocto | 05:59 | |
| *** kaspter <kaspter!~Instantbi@222.67.152.154> has quit IRC | 06:00 | |
| *** camus is now known as kaspter | 06:00 | |
| *** radeks <radeks!~radeks@185-15-80-246.ksi-system.net> has quit IRC | 06:07 | |
| *** goliath <goliath!~goliath@nat001-WLTU1.uibk.ac.at> has joined #yocto | 06:07 | |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto | 06:20 | |
| *** Micro23 <Micro23!~Micro23@c94F2653E.static.as2116.net> has joined #yocto | 06:25 | |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto | 06:32 | |
| *** frsc <frsc!~frsc@mue-88-130-67-045.dsl.tropolys.de> has joined #yocto | 06:35 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.176> has quit IRC | 06:37 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.176> has joined #yocto | 06:37 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 06:40 | |
| yocti | New news from stackoverflow: Auditd in Yocto <https://stackoverflow.com/questions/50840889/auditd-in-yocto> | 06:49 |
| *** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-rhixtitnedhikaok> has joined #yocto | 06:57 | |
| *** camus <camus!~Instantbi@222.67.188.168> has joined #yocto | 06:59 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.176> has quit IRC | 07:00 | |
| *** camus is now known as kaspter | 07:00 | |
| *** yacar_ <yacar_!~yacar@static-css-ccs-204145.business.bouyguestelecom.com> has joined #yocto | 07:06 | |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC | 07:12 | |
| yocti | New news from stackoverflow: U-boot environment is not the same as Linux "fw_printenv" <https://stackoverflow.com/questions/58535992/u-boot-environment-is-not-the-same-as-linux-fw-printenv> | 07:19 |
| *** tprrt <tprrt!~tprrt@217.114.204.178> has joined #yocto | 07:19 | |
| *** mckoan|away is now known as mckoan | 07:20 | |
| *** yann <yann!~yann@91-170-159-152.subs.proxad.net> has quit IRC | 07:20 | |
| *** goliath <goliath!~goliath@nat001-WLTU1.uibk.ac.at> has quit IRC | 07:22 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 07:32 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.168> has quit IRC | 07:34 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.168> has joined #yocto | 07:35 | |
| *** yacar_ <yacar_!~yacar@static-css-ccs-204145.business.bouyguestelecom.com> has quit IRC | 07:42 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.168> has quit IRC | 07:56 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.177> has joined #yocto | 07:57 | |
| *** kaspter <kaspter!~Instantbi@222.67.152.154> has joined #yocto | 07:58 | |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto | 08:05 | |
| *** kaspter <kaspter!~Instantbi@222.67.152.154> has quit IRC | 08:05 | |
| *** kaspter <kaspter!~Instantbi@222.67.152.154> has joined #yocto | 08:06 | |
| *** farnerup <farnerup!~farnerup@h-254-84-175.A137.corp.bahnhof.se> has joined #yocto | 08:10 | |
| *** khem <khem!~khem@unaffiliated/khem> has quit IRC | 08:10 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 08:12 | |
| *** khem <khem!~khem@unaffiliated/khem> has joined #yocto | 08:12 | |
| *** palate <palate!~palate@unaffiliated/palate> has joined #yocto | 08:22 | |
| *** goliath <goliath!~goliath@82.150.214.1> has joined #yocto | 08:28 | |
| *** kaspter <kaspter!~Instantbi@222.67.152.154> has quit IRC | 08:34 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.174> has joined #yocto | 08:34 | |
| *** yann <yann!~yann@85.118.38.73> has joined #yocto | 08:36 | |
| *** falk0n <falk0n!~falk0n@a109-49-142-1.cpe.netcabo.pt> has quit IRC | 08:45 | |
| yocti | New news from stackoverflow: Holding splash screen until X Server is ready using dbus <https://stackoverflow.com/questions/58537470/holding-splash-screen-until-x-server-is-ready-using-dbus> | 08:50 |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto | 08:52 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.174> has quit IRC | 08:55 | |
| *** kaspter <kaspter!~Instantbi@101.93.194.160> has joined #yocto | 08:55 | |
| *** dreyna_ <dreyna_!~dreyna@c-24-5-28-247.hsd1.ca.comcast.net> has quit IRC | 08:58 | |
| *** kaspter <kaspter!~Instantbi@101.93.194.160> has quit IRC | 09:12 | |
| *** kaspter <kaspter!~Instantbi@101.93.194.160> has joined #yocto | 09:12 | |
| *** JaMa <JaMa!~martin@ip-217-030-068-212.aim-net.cz> has joined #yocto | 09:14 | |
| *** frsc <frsc!~frsc@mue-88-130-67-045.dsl.tropolys.de> has quit IRC | 09:33 | |
| *** frsc <frsc!~frsc@i4DF677E4.static.tripleplugandplay.com> has joined #yocto | 09:33 | |
| *** VoidNick <VoidNick!~dw@dslb-092-074-038-004.092.074.pools.vodafone-ip.de> has joined #yocto | 09:47 | |
| qschulz | hi all, I'm extremely puzzled by https://git.yoctoproject.org/cgit.cgi/poky/commit/?id=c2f72f6cb7646757bf0dc7e16b4e0715025b7df2 | 09:49 |
| qschulz | Let me explain. We have two identical machines, machineA includes machineB and MACHINEOVERRIDES =. "machineb:". The reason for that is not part of the discussion, but they ARE identical except the name and the overrides. | 09:51 |
| qschulz | when we build machineA and then machineB, linux-libc-headers gets recompiled | 09:51 |
| qschulz | because it inherits kernel-arch which is adding STAGING_KERNEL_DIR to KERNEL_CC which is machine-specific (it has the name of the machine in it) | 09:52 |
| qschulz | I have very limited knowledge of gcc and flags/parameters so I might misunderstand the addition of -fdebug-prefix-map=${STAGING_KERNEL_DIR}=${KERNEL_SRC_PATH} for all recipes inheriting kernel-arch | 09:53 |
| qschulz | for me, with my very limited understanding of this, this has its place in module.bbclass, not kernel-arch.bbclass | 09:53 |
| qschulz | the big issue is that having linux-libc-headers recompiled is that, glibc is also recompiled and then the whole world is recompiled. Then everything is basically machine-specific and it results in extremely long builds | 09:54 |
| *** radsquirrel <radsquirrel!~bradleyb@mail.fuzziesquirrel.com> has quit IRC | 09:58 | |
| *** radsquirrel <radsquirrel!~bradleyb@mail.fuzziesquirrel.com> has joined #yocto | 09:59 | |
| qschulz | Does anyone know if the original commiter "He Zhe" from WindRiver is on IRC? | 09:59 |
| qschulz | I see rburton isn't here anymore so can't bother him with this :) | 10:00 |
| RP | qschulz: this does sound very much like a bug | 10:02 |
| RP | qschulz: what puzzles me is that we have tests for this kind of contamination | 10:05 |
| RP | qschulz: just because it has the name of the machine in, that doesn't mean it would necessarily rebuild as some paths do get filtered out | 10:06 |
| qschulz | I do not exclude that we've done something wrong in our custom layers though | 10:06 |
| RP | qschulz: have you tried diffsigs? | 10:06 |
| RP | (if you don't know what I mean that is fine, I can explain) | 10:07 |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 10:08 | |
| qschulz | RP: afk for 30min, I'll pick up then with whatever you wrote | 10:08 |
| RP | qschulz: basically find the tmp/stamps for linux-libc-headers and run bitbake-diffsigs on the two different sigdata files you see there (earliest task that has different sigs) | 10:08 |
| *** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 10:08 | |
| kanavin | RP, regarding adding polkit to oe-core (for sysprof and systemd), polkit hard-depends on mozjs, the mozilla javascript engine :( | 10:23 |
| kanavin | RP, so I am leaning towards actually shifting sysprof to meta-oe | 10:23 |
| RP | kanavin: hmm, I think we used to have that in core, probably due to this | 10:27 |
| *** ykrons <ykrons!~guillaume@62.192.23.101> has quit IRC | 10:27 | |
| RP | kanavin: I do worry we should really have polkit there for systemd :/ | 10:27 |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 10:28 | |
| LetoThe2nd | kanavin: RP: if polkit and mozjs get sucked into the systemd defaults, i can already hear screaming and cursing | 10:29 |
| kanavin | RP, I'm not able to find any mentions of mozjs in oe-core | 10:29 |
| kanavin | (in oe-core git log) | 10:32 |
| kanavin | let's wait and see what rburton says | 10:32 |
| RP | kanavin: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=7056054f61b354adcafb8957fe166fda88ca58c0 is what I was thinking of | 10:36 |
| RP | LetoThe2nd: it would be optional | 10:37 |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 10:37 | |
| LetoThe2nd | RP: whoa i just had a heartattack. i misread "it would be optimal2 | 10:38 |
| kanavin | RP, right. The current mozjs recipes pulls in a few python bits as well: http://git.openembedded.org/meta-openembedded/tree/meta-oe/recipes-extended/mozjs/mozjs_60.5.2.bb | 10:38 |
| kanavin | python 2.x bits | 10:38 |
| RP | kanavin: we really don't want py2... | 10:47 |
| T_UNIX | hi | 10:50 |
| kanavin | RP: right, so bringing mozjs into core is not a trivial task | 10:51 |
| T_UNIX | are `python __anonymous` in `.bb` or `.bbappend` simply anonymously injected, or are they addressable/overwritable in a `.bbappend`? | 10:51 |
| *** Klanticus <Klanticus!~quassel@189.76.135.211> has joined #yocto | 10:55 | |
| *** VoidNick <VoidNick!~dw@dslb-092-074-038-004.092.074.pools.vodafone-ip.de> has quit IRC | 10:55 | |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto | 11:01 | |
| RP | kanavin: no, doesn't look like it. Nothing ever seems simple :/ | 11:02 |
| RP | T_UNIX: the former unfortunately | 11:02 |
| *** radeks <radeks!~radeks@185-15-80-246.ksi-system.net> has joined #yocto | 11:07 | |
| qschulz | RP: I knew about bitbake-dumpsigs diffsigs but I thought you had something very specific in mind | 11:12 |
| qschulz | RP: anyway. I tried without using our images but just MACHINE=machine abitbake linux-libc-headers followed by same but for machineb. It's not rebuilt (directly taken from sstate-cache, I've no do_install.siggdata so I'm certain it's from sstate-cache | 11:13 |
| qschulz | so I'd say we're fucking up something | 11:13 |
| qschulz | (by we, I mean where I work, not YP :) ) | 11:14 |
| qschulz | do you have any pointers on how to debug this? | 11:14 |
| qschulz | does the bitbake-dumpsigs suggestion still stands? Will it help with poisoning from other recipes? (I guess?) Our image is just taking an awful amount of time to build (qtbase :) ) | 11:15 |
| qschulz | so the debugging might take some time :) | 11:15 |
| RP | qschulz: diffsigs is exactly how to debug | 11:15 |
| RP | qschulz: it should tell you what is changing | 11:15 |
| qschulz | RP: alright, now the waiting game :) Thx for the help, will let you know if I find something interesting or need help | 11:17 |
| qschulz | sorry for the scare, looks like we messed up and nothing to do with YP :) | 11:17 |
| qschulz | RP: I'm interested in what you meant by " 12:06 RP| qschulz: just because it has the name of the machine in, that doesn't mean it would necessarily rebuild as some paths do get filtered out" | 11:19 |
| qschulz | what is this filtering mechanism and where is it used, what for, etc. :) | 11:19 |
| *** khem <khem!~khem@unaffiliated/khem> has quit IRC | 11:20 | |
| RP | qschulz: note you don't need to wait for the build. Just "bitbake linux-libc-headers" for each machine | 11:20 |
| RP | qschulz: you could even just do "bitbake linux-libc-headers -S none" and skip building entirely (will generate the sig files) | 11:21 |
| *** learning1 <learning1!~pi@121.121.99.187> has quit IRC | 11:21 | |
| RP | qschulz: if you build in two different locations, you'd want the sstate object to be identical. Paths therefore get filtered out of the sigs | 11:22 |
| RP | some paths anyway | 11:22 |
| qschulz | RP: this does not reproduce the full build (bitbake linux-libc-headers) | 11:22 |
| qschulz | sorry, this does not reproduce the bug | 11:22 |
| RP | qschulz: but it rebuilds linux-libc-headers? | 11:23 |
| qschulz | It does not seem so, it's taken from the sstate-cache directly and I don't see anything new in stamps | 11:23 |
| *** khem <khem!~khem@unaffiliated/khem> has joined #yocto | 11:24 | |
| *** radeks_ <radeks_!~radeks@185-15-80-246.ksi-system.net> has joined #yocto | 11:24 | |
| *** tprrt <tprrt!~tprrt@217.114.204.178> has quit IRC | 11:24 | |
| RP | qschulz: so what you told me earlier about rebuilding it isn't quite right :/ | 11:24 |
| RP | qschulz: you need to find out what does actually rebuild, then use diffsigs there | 11:25 |
| *** radeks <radeks!~radeks@185-15-80-246.ksi-system.net> has quit IRC | 11:26 | |
| *** goliath <goliath!~goliath@82.150.214.1> has quit IRC | 11:28 | |
| qschulz | RP: sorry, I'm getting all confused. Starting from zero: | 11:29 |
| qschulz | cleansstate of all linux-libc-headers for all machines. MACHINE=machinea bitbake my-image; MACHINE=machineb bitbake my-image; bitbake-ddiffsigs stamps/linux-libc-headers/*/*do_install* | 11:30 |
| qschulz | Hash for dependent task linux-libc-headers/linux-libc-headers_4.18.bb.do_compile changed from 5ad454ec2f7f2cd3059917a80291509f to c554e27feec0caba02f1f8e9d205480b | 11:30 |
| qschulz | but wtf because in linux-libc-headers.inc => do_compile[noexec] = "1" | 11:33 |
| *** learning1 <learning1!~pi@121.121.99.187> has joined #yocto | 11:33 | |
| qschulz | damn... do_compile has set_icecc_env in it | 11:34 |
| qschulz | even if it's not executed I guess the task hash still matters atm | 11:34 |
| qschulz | RP: https://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/icecc.bbclass#n379 this line I think is the only change | 11:36 |
| *** tgamblin <tgamblin!~tgamblin@128.224.252.2> has joined #yocto | 11:36 | |
| *** goliath <goliath!~goliath@82.150.214.1> has joined #yocto | 11:37 | |
| *** yacar_ <yacar_!~yacar@149.91.82.219> has joined #yocto | 11:38 | |
| T_UNIX | RP: thanks! | 11:42 |
| *** tprrt <tprrt!~tprrt@217.114.204.178> has joined #yocto | 11:46 | |
| *** berton <berton!~berton@181.220.83.67> has joined #yocto | 11:46 | |
| *** ecdhe <ecdhe!~quassel@unaffiliated/ecdhe> has joined #yocto | 11:50 | |
| *** berton <berton!~berton@181.220.83.67> has quit IRC | 11:51 | |
| *** berton <berton!~berton@181.220.83.67> has joined #yocto | 11:53 | |
| *** radeks_ <radeks_!~radeks@185-15-80-246.ksi-system.net> has quit IRC | 12:13 | |
| milloni | is there an irc channel for automotive grade linux? | 12:19 |
| mdp | milloni: #automotive | 12:20 |
| milloni | thanks! - is that for automotive in general, not agl specifically? | 12:21 |
| qschulz | RP: https://git.yoctoproject.org/cgit.cgi/poky/commit/?id=8856289fb615698b9c5bf68431cceee1ef80a1bf guess that's the one | 12:21 |
| mdp | milloni: topic is automotive foss, but it's 99% agl talk | 12:21 |
| milloni | ok | 12:23 |
| *** litb <litb!~jschaub@pd907fca9.dip0.t-ipconnect.de> has joined #yocto | 12:24 | |
| litb | JaMa, sorry, my issue report on github was incorrect! I wasn't aware that qt configure uses cross canadian schemes for qmake. so it will use qmake built by qtbase-native | 12:24 |
| litb | i will close my issue report in the evening | 12:24 |
| LetoThe2nd | RP: btw, have you seen http://sprunge.us/sT5062 ? | 12:29 |
| LetoThe2nd | RP: reporter didn't want to create a loging for bugzilla nor register to the ML. | 12:29 |
| JaMa | litb: cool | 12:32 |
| JaMa | qschulz: you mean you're missing this change in our build, right? | 12:34 |
| qschulz | JaMa: I mean that's the one commit which is missing in thud I think. I'm testing right now :) | 12:35 |
| qschulz | Good thing is, if it's really this commit, it's a change in a bbclass, so I can just override this bbclass until we migrate to warrior 2.7.2 | 12:36 |
| JaMa | qschulz: yes, it's missing in thud, I never sent the backport request for that, but I have it in my "fork" http://git.openembedded.org/openembedded-core-contrib/commit/?h=jansa/thud&id=13f29239a9b71ee2a714c990d2b86d162bbe6690 | 12:36 |
| *** camus <camus!~Instantbi@222.67.188.174> has joined #yocto | 12:37 | |
| *** kaspter <kaspter!~Instantbi@101.93.194.160> has quit IRC | 12:38 | |
| *** camus is now known as kaspter | 12:38 | |
| qschulz | JaMa: I'm surprised it made it to warrior as a backport but not thud, that's all | 12:39 |
| tlwoerner | has anyone else's build of libcap-ng-native fail today as a result of the upgrade from 0.7.9 to 0.7.10? it looks like a host issue, so i'm hesitant to report it on the mailing list | 12:39 |
| qschulz | (considering thud was still maintained at that time) | 12:39 |
| tlwoerner | -> /usr/lib64/gcc/x86_64-suse-linux/8/../../../../x86_64-suse-linux/bin/ld: /z/jenkins-workspace/nightly/cubietruck/build/tmp-glibc/work/x86_64-linux/libcap-ng-native/0.7.10-r0/build/src/.libs/libcap-ng.so: undefined reference to `pthread_atfork' | 12:40 |
| JaMa | qschulz: backport request sent now | 12:40 |
| JaMa | qschulz: I've fixed it locally while waiting for the backport to warrior to be merged and then I just forgot to send it for thud as well, because sstate-diff-machines was no longer complainig (because of the local fix for that) | 12:41 |
| *** georgem_ <georgem_!~georgem@216.21.169.52> has joined #yocto | 12:42 | |
| qschulz | JaMa: Cool, thx. | 12:43 |
| qschulz | no worries :) | 12:43 |
| qschulz | Happy that's it's fixable (and fixed already upstreamed :) ) | 12:43 |
| JaMa | it's useful to run sstate-diff-machines.sh script as part of your CI to catch these issues early | 12:43 |
| JaMa | with many layers it's a bit problematic, because many layers still have even parsing issues with this and then the script cannot work | 12:44 |
| JaMa | e.g. http://jenkins.nas-admin.org/job/oe_world_workspace-compare-signatures/808/console isn't really useful now | 12:44 |
| JaMa | https://github.com/advancedtelematic/meta-updater/issues/603 | 12:45 |
| tgamblin | tlwoerner: just tried, got same issue | 12:45 |
| *** georgem <georgem!~georgem@216.21.169.52> has quit IRC | 12:45 | |
| JaMa | meta-virtualization adds even more issues I haven't reported yet | 12:45 |
| JaMa | ERROR: Nothing RPROVIDES 'apache2' (but /home/jenkins/anaconda/build-webos-thud/build/meta-virtualization/recipes-extended/nagios/nagios-core_4.4.2.bb RDEPENDS on or otherwise requires it) | 12:47 |
| JaMa | ERROR: Nothing PROVIDES 'syslinux' (but /home/jenkins/anaconda/build-webos-thud/build/meta-virtualization/recipes-extended/ipxe/ipxe_git.bb DEPENDS on or otherwise requires it) | 12:47 |
| JaMa | syslinux was skipped: incompatible with host arm-webos-linux-gnueabi (not in COMPATIBLE_HOST) | 12:47 |
| JaMa | etc | 12:47 |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 12:54 | |
| *** VoidNick <VoidNick!~dw@141.60.172.189> has joined #yocto | 12:59 | |
| RP | qschulz: I had to step away but looks like you found the source of the problem | 12:59 |
| RP | LetoThe2nd: strangely enough no, I have not seen that | 13:00 |
| LetoThe2nd | RP: any objects? can you take it, or want me to formally report/mail it? | 13:01 |
| RP | LetoThe2nd: question is about attribution I guess | 13:01 |
| qschulz | RP: np, I don't expect anyone to answer under a given time (or even at all). | 13:02 |
| *** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 13:02 | |
| tlwoerner | tgamblin: okay, thanks for checking! i'll report it in the mailing list | 13:03 |
| LetoThe2nd | RP: well its a rather trivial one, so i guess its fine if somebody just pushes it as "hum i noticed" | 13:03 |
| RP | LetoThe2nd: mailed it out with a guess at what its for | 13:03 |
| VoidNick | Hello, I have some problems with yocto warrior release. It fails with the default qemu image. Is it the right place here to get some help? | 13:05 |
| LetoThe2nd | RP: thanks. | 13:06 |
| LetoThe2nd | VoidNick: try pouring your question into a form that can be answered, then yes :) | 13:06 |
| VoidNick | Ok, i'll try: | 13:06 |
| VoidNick | Following https://www.yoctoproject.org/docs/2.0/yocto-project-qs/yocto-project-qs.html and switching to the warrior branch. The command "bitbake core-image-sato" fails with: pthread_atfork.c:51: undefined reference to `__dso_handle' | 13:09 |
| VoidNick | Host is Ubuntu 18.04 | 13:09 |
| LetoThe2nd | VoidNick: w.0 is massively outdated | 13:09 |
| LetoThe2nd | 2.0, i mean | 13:10 |
| VoidNick | ok, so I have to do something different? | 13:11 |
| LetoThe2nd | and i actually just gave 2.7.1 a.k.a. warrior a full sato build on ubuntu 18.04 this morning, so i'm relatively sure that its related to your specific box | 13:12 |
| LetoThe2nd | VoidNick: can you retry following this? https://www.yoctoproject.org/docs/current/brief-yoctoprojectqs/brief-yoctoprojectqs.html | 13:12 |
| zeddii | RP: just cc’d you on my qemumips64 boot issues with v5.4-rcX | 13:13 |
| zeddii | that’s the earliest I’ve ever gotten around to finding an issue .. normally we find them when there’s no time left :D | 13:13 |
| JPEW | RP: No luck reproducing the Fedora perl non-reproducible error. Has anyone seen it on the AB since? | 13:14 |
| VoidNick | LetoThe2nd: ok, I try | 13:15 |
| LetoThe2nd | VoidNick: also, see my answer at https://stackoverflow.com/questions/58528703/setting-up-yocto-on-my-ubuntu-ubuntu-18-04-3-lts-bionic-with-error-importerro for possible error mitigations, if this comes from seomthing in your specific dev host setup | 13:20 |
| yocti | New news from stackoverflow: How to add changed dts-file in kernel in Yocto? <https://stackoverflow.com/questions/58542016/how-to-add-changed-dts-file-in-kernel-in-yocto> | 13:20 |
| yann | building mesa on zeus, I get a meson failure saying: meson.build:140:0: ERROR: Unknown variable "_drivers" | 13:28 |
| RP | JPEW: happens most builds :/ | 13:28 |
| RP | JPEW: https://autobuilder.yoctoproject.org/typhoon/#/builders/86 | 13:29 |
| *** wertigon <wertigon!50fe9a69@1071ob.scansafe.net> has joined #yocto | 13:29 | |
| yann | never looked at meson before, but that "_drivers" name seems to occur only at that line - surely I can't be the only one to see that issue ? | 13:29 |
| JPEW | RP: Ok, that's actually good. It means the error is (probably) in sstate and if I can get my local build to pull from AB sstate (its not now for some reason), it should be easier to reproduce | 13:29 |
| JPEW | I'll keep trying | 13:30 |
| wertigon | Hi, got a big problem trying to build the SDK to our distribution. I run bitbake -c output_sdk test-image and is greeted with two file not found errors on two packages. | 13:30 |
| RP | JPEW: we could get you ssh onto that worker if that would help? | 13:31 |
| RP | zeddii: hmm, forwarded that to someone who might have contacts | 13:31 |
| JPEW | Ya, If I can pull the offending packages, I can run diffoscope on them | 13:32 |
| RP | JPEW: halstead can probably get you access | 13:32 |
| wertigon | I get that recipes-devtools/clang/libcxx_git.bb fails with build/tmp-glibc/work/.../nativesdk-libcxx/.../x86_64-test-linux-llvm-ar: No such file or directory | 13:33 |
| wertigon | Any ideas how to solve it? Been looking around the web but no luck as of yet | 13:33 |
| JPEW | Now that reproducible builds aren't generating 1000s of offending packages, we might try running diffoscope as part of the build logs so we have all the info... maybe there's some way to reduce the CPU/space requirements. | 13:34 |
| RP | JPEW: the host dependency issues with this worry/scare me | 13:37 |
| RP | JPEW: if you can hack the build to stash the different packages into /tmp/somewhere, I can run that on the AB btw | 13:37 |
| JPEW | RP: It might not be that FWIW. Perl does almost nothing correctly to be reproducible :) | 13:38 |
| wertigon | Also same thing happens with recipes-devtools/clang/compiler-rt_git.bb | 13:38 |
| LetoThe2nd | wertigon: as clang is not in poky nor meta-openembedded, things might be a bit difficult. | 13:38 |
| *** georgem_ is now known as georgem | 13:38 | |
| JPEW | I would not be suprised if there is a "bad" perl build in sstate that only the fedora builder pulls | 13:38 |
| LetoThe2nd | wertigon: maybe khem can chime in, but i guess your best chance is the mailing list. | 13:38 |
| kroon | wertigon, maybe something todo with https://git.openembedded.org/openembedded-core/commit/?id=b0efd8d4d0dbc30e6505b42f5603f18fa764d732 ? | 13:39 |
| *** farnerup <farnerup!~farnerup@h-254-84-175.A137.corp.bahnhof.se> has quit IRC | 13:39 | |
| wertigon | Yeah, I've inherited a Poky distribution at work and my usual goto reference is on vacation :/ | 13:39 |
| LetoThe2nd | wertigon: well then, sounds like you're about to have fun. | 13:40 |
| *** farnerup <farnerup!~farnerup@h-254-84-175.A137.corp.bahnhof.se> has joined #yocto | 13:45 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.174> has quit IRC | 13:45 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.174> has joined #yocto | 13:46 | |
| wertigon | Bummer, I'll test that patch kroon sent and we'll see from there | 13:47 |
| wertigon | I did see SDK was defined as ${SDK}-${OS} in one place | 13:47 |
| kroon | wertigon, you can just check your SDK_VENDOR | 13:47 |
| kroon | wertigon, bitbake -e test-image | grep ^SDK_VENDOR= | 13:48 |
| yann | ok that's only happening when mesa is built without dri, and there are other issues lurking behind that, I'll look and submit a patch | 13:49 |
| *** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto | 13:51 | |
| wertigon | SDK image is "-test" | 13:53 |
| wertigon | Or sorry, SDK_VENDOR I mean | 13:53 |
| wertigon | And the name of my image is test-dev-image | 13:54 |
| *** Hellgineer <Hellgineer!4a38d61b@modemcable027.214-56-74.mc.videotron.ca> has joined #yocto | 13:56 | |
| Hellgineer | Hi Yocto community! | 13:57 |
| florian | hi Hellgineer | 13:58 |
| * LetoThe2nd can't greet, is scared. | 13:59 | |
| * jofr hides behind LetoThe2nd | 13:59 | |
| * LetoThe2nd quickly turns round and pushes jofr forwards. | 13:59 | |
| * jofr whisper "Who is that cheerful person and what does he want with us??" | 13:59 | |
| * jofr collapses into a fetal-position. | 14:00 | |
| * Hellgineer wonders if the greeting was a good way to start this conversation | 14:00 | |
| LetoThe2nd | Hellgineer: that can be answered with a clear "no" | 14:00 |
| qschulz | Hellgineer: just put a beer on the table and wait for LetoThe2nd to come out of his hideout | 14:01 |
| florian | :-) | 14:01 |
| jofr | Software people can't do "conversation". We're embedded software people. We're WORSE! :p | 14:01 |
| LetoThe2nd | mh... did i hear "beer"? | 14:02 |
| * Hellgineer puts a local IPA on the table and steps back | 14:02 | |
| jofr | Nooooo! It's a traaaaap! | 14:02 |
| Hellgineer | Damn it! | 14:02 |
| * LetoThe2nd looks at bottle,reads, puts bottle back and shrugs "nah i dn't drink IPAs." | 14:02 | |
| jofr | I don't think LetoThe2nd even cares if it's a trap or not.. ;) | 14:03 |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC | 14:03 | |
| jofr | Ohh, fine. | 14:03 |
| Hellgineer | I heard embedded software people might have knack for structuring Yocto layers (the good way (tm)) | 14:03 |
| LetoThe2nd | that sounds very much like a trick question! | 14:05 |
| Hellgineer | The legend says that three different layer types exists: 1. BSP 2. Distros 3. Software. It is also, from the great Yocto manual, not a good idea to keep Distro layer with recipes, hence many meta-* layers having a *-bsp and a distro one. What is the reasoning behind that? | 14:07 |
| *** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC | 14:07 | |
| Hellgineer | Would it be a sin to have a machine + distro + images in the same meta-* ? | 14:07 |
| *** kaspter <kaspter!~Instantbi@222.67.188.174> has quit IRC | 14:07 | |
| *** kaspter <kaspter!~Instantbi@222.67.188.168> has joined #yocto | 14:08 | |
| wertigon | Not a sin, no... But it makes more sense to divide it in the way listed | 14:08 |
| wertigon | Reason being, you might want to run the distro on more than a single machine (like a rev. 2.0 uses a TI chip instead of a GloFo chip or something) | 14:09 |
| LetoThe2nd | Hellgineer: it depends (TM) | 14:10 |
| * Hellgineer lol | 14:10 | |
| wertigon | And you might want to have different roles (cluster of 3 RPi that acts as a webserver, FTP and git servers, for instance) | 14:11 |
| wertigon | With the same hardwar | 14:11 |
| wertigon | Finally you might want to have different profiles for the distro without touching the rest | 14:11 |
| LetoThe2nd | Hellgineer: nah, seriously. it pretty much depends if your hardware is fully-customized for a very specific application. if there's little change it could ever be repurposed, then the separation can be left out. whereas if you're on something more generic, or even a platfomr that you can "just buy", then a seperate bsp layer is almost due | 14:12 |
| wertigon | e.g. debug / release | 14:12 |
| LetoThe2nd | Hellgineer: app / distro layers are a bit more complicated. splitting them up is a kind of "known good practise", yet not always needed. it really comes down to your project, development workflow and also lifecycle management | 14:13 |
| wertigon | That's why you want to separate hw/sw/distro, but yeah. | 14:13 |
| LetoThe2nd | so, i'd conclude: "if unsure, seperate the three." | 14:15 |
| Hellgineer | Wow thanks for that, I think I moved a step forward. So with a 'multi-machine' distro with many profiles (ex. STD, SDK, Light, etc...), the best would be to have two diff. meta layers, then separate SW layers accordingly | 14:16 |
| LetoThe2nd | Hellgineer: absolutely. | 14:16 |
| *** tsjsieb <tsjsieb!~quassel@2a06:5b80:1::2be3:ec4> has quit IRC | 14:19 | |
| Hellgineer | Let's say that the distro would not to include another readily available meta-layer, what is the suggested GIT/CI strategy to make sure that everything is in the Source Directory before launching a build? | 14:19 |
| Hellgineer | Would you checkout everything manually before build, or maybe create a new 'internal' repository with the poky repo + the metas. ? | 14:20 |
| LetoThe2nd | Hellgineer: can you rephrase? i guess you either mangles the sentence or typoed somewhere so i don't really get the question | 14:20 |
| LetoThe2nd | ah. | 14:20 |
| LetoThe2nd | check out everything before build. there's tools and magic for it, basically kas and repo. you can also make a combined distro layer, i think ross has an example somewhere, using git submodules. | 14:21 |
| Crofton|work | git submodules for the win :) | 14:22 |
| *** ericch <ericch!~ericch@50-205-235-218-static.hfc.comcastbusiness.net> has joined #yocto | 14:22 | |
| Crofton|work | https://github.com/balister/sdr-build | 14:23 |
| LetoThe2nd | :-) | 14:23 |
| Hellgineer | That's nice! | 14:24 |
| Hellgineer | You guys are really helpful, thank you very much! | 14:24 |
| * Hellgineer lefts a big tips on the table, besides the untouched IPA | 14:25 | |
| mckoan | those are git submodule | 14:26 |
| litb | Need to add ${bindir} to SYSROOT_DIRS for cmake projects, because cmake expects dll files which are installed to bin/ to be present | 14:26 |
| *** tsjsieb <tsjsieb!~quassel@2a06:5b80:1::2be3:ec4> has joined #yocto | 14:26 | |
| litb | I think I should not add it to SYSROOT_DIRS though, to prevent binaries to be put into recipe-sysroot-s. instead, I'm going to _append to do_populate_sysroot | 14:26 |
| alessioigor | I use git-submodules of git-submodules! | 14:27 |
| halstead | JPEW, Let me know if I can help with access. | 14:31 |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC | 14:32 | |
| *** wertigon <wertigon!50fe9a69@1071ob.scansafe.net> has quit IRC | 14:35 | |
| *** goliath <goliath!~goliath@82.150.214.1> has quit IRC | 14:40 | |
| *** kroon <kroon!~kroon@213.185.29.22> has quit IRC | 14:48 | |
| *** tprrt <tprrt!~tprrt@217.114.204.178> has quit IRC | 14:48 | |
| VoidNick | have got still the same error: undefined reference to __dso_handle | 14:51 |
| LetoThe2nd | VoidNick: so in that case, what is special about your host? :) | 14:52 |
| *** Micro23 <Micro23!~Micro23@c94F2653E.static.as2116.net> has quit IRC | 14:54 | |
| *** VoidNick <VoidNick!~dw@141.60.172.189> has quit IRC | 14:55 | |
| *** VoidNick <VoidNick!~dw@141.60.172.189> has joined #yocto | 14:57 | |
| *** frsc <frsc!~frsc@i4DF677E4.static.tripleplugandplay.com> has quit IRC | 15:04 | |
| VoidNick | ok it seems that the host pc still lacks some packages. | 15:05 |
| inf | maybe someone stumbled upon this - i'm trying to implement swupdate & u-boot on raspberrypi 3 on warrior... i've managed to figure everyting out based on official examples and meta-swupdate, but u-boot seems to randomly fail to load / save environment from fat (with either "invalid crc" error, or just straight up failing with WARNING at drivers/mmc/bcm2835_sdhost.c:408/bcm2835_send_command()!) | 15:07 |
| *** kaspter <kaspter!~Instantbi@222.67.188.168> has quit IRC | 15:07 | |
| *** camus <camus!~Instantbi@222.67.188.177> has joined #yocto | 15:07 | |
| *** camus is now known as kaspter | 15:09 | |
| *** VoidNick <VoidNick!~dw@141.60.172.189> has quit IRC | 15:10 | |
| *** frsc <frsc!~frsc@i4DF677E4.static.tripleplugandplay.com> has joined #yocto | 15:10 | |
| inf | running in 32-bit mode with this patch https://github.com/balena-os/balena-raspberrypi/blob/master/layers/meta-balena-raspberrypi/recipes-bsp/u-boot/u-boot/0002-raspberrypi-Disable-simple-framebuffer-support.patch but doesn't seem like might cause this? | 15:10 |
| *** yann <yann!~yann@85.118.38.73> has quit IRC | 15:14 | |
| *** tsjsieb <tsjsieb!~quassel@2a06:5b80:1::2be3:ec4> has quit IRC | 15:17 | |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC | 15:19 | |
| *** tsjsieb <tsjsieb!~quassel@2a06:5b80:1::2be3:ec4> has joined #yocto | 15:19 | |
| *** yacar_ <yacar_!~yacar@149.91.82.219> has quit IRC | 15:27 | |
| *** VoidNick <VoidNick!~dw@dslb-092-074-038-004.092.074.pools.vodafone-ip.de> has joined #yocto | 15:30 | |
| *** farnerup <farnerup!~farnerup@h-254-84-175.A137.corp.bahnhof.se> has quit IRC | 15:33 | |
| JPEW | halstead: Is it possible I could get ssh access to the fedora30 worker to pull some files off? | 15:35 |
| *** tsjsieb <tsjsieb!~quassel@2a06:5b80:1::2be3:ec4> has quit IRC | 15:35 | |
| JPEW | halstead: Or anyway of pulling files would work. Doesn't need to be ssh | 15:36 |
| halstead | JPEW, Yes. Let me see if I already have your ssh public key. | 15:36 |
| JPEW | Should be in meta-mingw | 15:36 |
| JPEW | and poky-contrib | 15:36 |
| *** Hellgineer <Hellgineer!4a38d61b@modemcable027.214-56-74.mc.videotron.ca> has left #yocto | 15:39 | |
| litb | hmm, I suspect when I use multiconfig and both of the config need the same -native recipes, the -native recipes will be built twice :( | 15:39 |
| * armpit hmm Alex's changes look promising for warrior's issue | 15:39 | |
| litb | because sstate cache is not used during the multiconfig build | 15:39 |
| JPEW | litb: sstate should be shared between two multiconfig builds in the same invocation as of 3.0 | 15:42 |
| litb | oh nice | 15:42 |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC | 15:43 | |
| *** frsc <frsc!~frsc@i4DF677E4.static.tripleplugandplay.com> has quit IRC | 15:44 | |
| JPEW | litb: It's worked in back to back invocations for a while (bitbake mc:A:bar && bitbake mc:B:bar), but now it should also share when you do: bitbake mc:A:bar mc:B:bar | 15:46 |
| litb | nice, because when we build our linux firmware + windows/mingw customer programs , both of these will share many -native recipes. | 15:48 |
| JPEW | litb: Yep | 15:48 |
| litb | although I guess back to back execution would not be very slower | 15:49 |
| litb | after all, there's enough recipes in both such that they saturate the CPU when executed along | 15:49 |
| JPEW | litb: Ya. I suspect the more useful case there is when you have inter-recipe multiconfig dependencies (i.e. mcdepends) | 15:50 |
| litb | I see | 15:50 |
| halstead | JPEW, I've sent an e-mail with connection information. | 15:57 |
| *** DChacon <DChacon!c037362a@192.55.54.42> has joined #yocto | 16:08 | |
| JPEW | halstead: Thanks | 16:15 |
| *** DChacon <DChacon!c037362a@192.55.54.42> has quit IRC | 16:17 | |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto | 16:18 | |
| lpapp | hi | 16:18 |
| lpapp | why do I get two versions in the kernel's ipk filename? build/tmp/deploy/ipk/polatisnic/kernel-3.2.1-r21_3.2.1-r22_polatisnic.ipk | 16:18 |
| lpapp | shouldn't it be just build/tmp/deploy/ipk/polatisnic/kernel-3.2.1-r22_polatisnic.ipk | 16:25 |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 16:26 | |
| mckoan | lpapp: perhaps a mismatch in the recipe's variables? | 16:30 |
| lpapp | which variables? | 16:30 |
| lpapp | mckoan: this is what I have, =============================== | 16:32 |
| lpapp | https://justpaste.it/57uu2 | 16:32 |
| lpapp | the kernel recipe | 16:32 |
| lpapp | anything suspiciously wrong with it? Based on your reply, I assume that is not what you get in your builds, the pattern itself? | 16:32 |
| mckoan | lpapp: what's the recipe filename? | 16:34 |
| lpapp | you can see at the top from cat | 16:35 |
| lpapp | same as with the linux-yocto patterns | 16:35 |
| lpapp | oops, cat did not make it into the paste, my fault | 16:35 |
| *** VoidNick <VoidNick!~dw@dslb-092-074-038-004.092.074.pools.vodafone-ip.de> has quit IRC | 16:36 | |
| lpapp | mckoan: linux-polatis_3.2.1.bb | 16:36 |
| *** vineela <vineela!~vtummala@134.134.139.76> has joined #yocto | 16:37 | |
| lpapp | the other thing is that, this does not seem to make it into the uname: LINUX_VERSION_EXTENSION ?= "-polatis-${PR}" | 16:37 |
| lpapp | I would ideally like to resolve both | 16:37 |
| *** tsjsieb <tsjsieb!~quassel@2a06:5b80:1::2be3:ec4> has joined #yocto | 16:38 | |
| mckoan | lpapp: it is normal: kernel-image-4.4.26-yocto-standard_4.4.26+git0+3030330b06_ca6a08bd7f-r0_beaglebone.ipk | 16:38 |
| lpapp | normal as in yocto uses it, but I do not have multiple versions on desktop and to be fair, I like it that way. Why does it have to repeat the version when using Yocto? | 16:39 |
| mckoan | lpapp: no clue, sorry | 16:40 |
| lpapp | hmm, I see, thanks, what about the uname issue? | 16:40 |
| lpapp | doc says: LINUX_VERSION_EXTENSION: The Linux kernel CONFIG_LOCALVERSION that is compiled into the resulting kernel and visible through the uname command. | 16:40 |
| lpapp | maybe, daisy did not support it | 16:40 |
| lpapp | oh, it did | 16:41 |
| lpapp | so, yeah, no clue really | 16:41 |
| lpapp | Linux polatisnic 3.2.1-r21 #1 PREEMPT Thu Nov 22 16:32:08 GMT 2018 armv5tejl GNU/Linux | 16:41 |
| *** mckoan is now known as mckoan|away | 16:43 | |
| *** tsjsieb <tsjsieb!~quassel@2a06:5b80:1::2be3:ec4> has quit IRC | 16:46 | |
| lpapp | my colleague added some code to remove old kernel when we are upgrading the kernel... | 16:48 |
| lpapp | I think it makes no sense, opinions? | 16:48 |
| *** tsjsieb <tsjsieb!~quassel@2a06:5b80:1::2be3:ec4> has joined #yocto | 16:48 | |
| lpapp | In my opinion, it should be opkg's responsibility... failing that, we should add a post-install script to our kernel package to clean up old kernels in case we are paranoid? | 16:48 |
| RP | lpapp: FWIW the version is in the name so that its possible to install two kernels in parallel | 17:06 |
| RP | lpapp: some users need to do that in for example an upgrade scenario to have a fallback | 17:06 |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 17:07 | |
| litb | JPEW, ah cool, yocto 3.0 was released yesterday! | 17:08 |
| RP | litb: sharing sstate between multiconfigs dyanmically mid build was one of the features :) | 17:10 |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto | 17:23 | |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto | 17:25 | |
| JPEW | RP: AB doens't seem to have preserved the non-reproducible perl packages for me to diff, so I'm back to trying locally | 17:32 |
| JPEW | Unless I'm looking in the wrong location | 17:32 |
| *** wbn <wbn!~badegg@2607:5300:60:2ca::1> has joined #yocto | 17:33 | |
| litb | JPEW, but this in the 3.0 mega manual is now incorrect? | 17:33 |
| litb | "Support for multiple configuration builds in the Yocto Project 3.0 (Zeus) Release does not include Shared State (sstate) optimizations. Consequently, if a build uses the same object twice in, for example, two different TMPDIR directories, the build either loads from an existing sstate cache for that build at the start or builds the object fresh. " | 17:34 |
| JPEW | Yes, that is wrong | 17:34 |
| RP | JPEW: no, its selftest so it won't have it :( | 17:35 |
| RP | JPEW: could we try what I suggested - give me a patch to copy them to /tmp ? | 17:35 |
| JPEW | RP: Ok, I'll do that. | 17:35 |
| RP | JPEW: If you want it faster, hack it to disable other selftests :) | 17:35 |
| RP | JPEW: in fact put that in a poky branch on contrib and I can just run that :) | 17:36 |
| JPEW | RP: Ok | 17:36 |
| *** Klanticus <Klanticus!~quassel@189.76.135.211> has quit IRC | 17:52 | |
| *** Klanticus <Klanticus!~quassel@189.76.135.211> has joined #yocto | 17:52 | |
| *** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-rhixtitnedhikaok> has quit IRC | 18:07 | |
| *** litb <litb!~jschaub@pd907fca9.dip0.t-ipconnect.de> has quit IRC | 18:13 | |
| JPEW | RP: http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=jpew/ab-reproducible-test | 18:17 |
| *** zwelch <zwelch!~zwelch@fluffy.superlucidity.net> has joined #yocto | 18:18 | |
| *** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 18:27 | |
| *** yann <yann!~yann@91-170-159-152.subs.proxad.net> has joined #yocto | 18:37 | |
| mischief | does anyone know why python3 native packages don't compile with icecc even when it is enabled? | 18:38 |
| kergoth | do we have a tool/script to clear out old taint on tasks? | 18:49 |
| kergoth | without wiping tmp, that is | 18:49 |
| kergoth | hmm, anyone run into a libcap-ng-native build failure on certain hosts when building the utils due to a failure to find pthread_atfork? it seems like it requires -lpthread in LDADD the way it does in the tests, but i'm wondering why it fails to add it automatically via the .la unless something wentw rong with libtool, since the in-builddir .la should still exist | 18:52 |
| JPEW | mischief: No. Perhaps it's not invoking the compiler specified in $CC, or it's passing some argument that icecc doesn't like | 18:52 |
| JPEW | mischief: Or, you have it blacklisted :) | 18:53 |
| mischief | JPEW: yeah, maybe the former, but it does seem to somehow invoke the right cross-toolchain. i am no pythonista though, can't really figure out the guts of distutils :-( | 18:58 |
| JPEW | mischief: I'm not too familiar with it either. Does it print the compile commands? | 18:58 |
| *** litb <litb!~litb___@p5B02F489.dip0.t-ipconnect.de> has joined #yocto | 18:58 | |
| * kergoth tries using meta-external-toolchain with an oe-built sdk | 18:58 | |
| mischief | seems so | 19:00 |
| litb | would it make sense to add a 'mingw' disto-feature, so that packages can use this to configure their default PACKAGECONFIGs ? | 19:01 |
| mischief | another silly question, is there a way to enumerate all kernel module packages including external modules so i can put them in a image? | 19:01 |
| litb | otherwise, the only remaining thing for packages to arrange for valid config lines is the TARGET_OS override, which isn't as nice to use in PACKAGECONFIG | 19:02 |
| mischief | 'kernel-modules' package depends on all in-tree modules but i need out of tree ones as well | 19:02 |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 19:13 | |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC | 19:15 | |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto | 19:15 | |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC | 19:16 | |
| JPEW | mischief: grep for inherit module ? | 19:19 |
| JPEW | mischief: I don't know if there is a better way | 19:19 |
| mischief | JPEW: i would preferrably do it programmatically, since different $MACHINE needs different modules for us. | 19:21 |
| mischief | i don't really want to use $MACHINE_ESSENTIAL... since that might contain non-module packages | 19:22 |
| JPEW | mischief: If you had the list of all modules, what would you filter it on to figure out which ones when to which machines? | 19:24 |
| mischief | the content of build/tmp/deploy/deb/$MACHINE/kernel-module*.deb is basically what i want, but i suppose that isn't known until the recipes produce the packages | 19:26 |
| *** tgamblin <tgamblin!~tgamblin@128.224.252.2> has quit IRC | 19:32 | |
| *** ericch <ericch!~ericch@50-205-235-218-static.hfc.comcastbusiness.net> has quit IRC | 19:36 | |
| *** ericch <ericch!~ericch@50-205-235-218-static.hfc.comcastbusiness.net> has joined #yocto | 19:37 | |
| RP | kergoth: an rm tmp/stamps/*/*.taint (or similar) would probably work | 19:50 |
| RP | probably */*/*.taint | 19:50 |
| *** gnac <gnac!~gnac@or-71-0-52-80.sta.embarqhsd.net> has quit IRC | 19:51 | |
| *** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC | 21:03 | |
| *** zwelch <zwelch!~zwelch@fluffy.superlucidity.net> has quit IRC | 21:06 | |
| RP | JPEW: went and succeeded: https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/458 :( | 21:13 |
| *** BobPungartnik <BobPungartnik!~BobPungar@187.113.154.201> has joined #yocto | 21:13 | |
| litb | "BitBake finds and applies multiple patches for a single recipe in the order in which it locates the patches" hi! what does this mean? | 21:15 |
| litb | does this mean that it's the order in which they appear in SRC_URI? | 21:16 |
| bluelightning | litb: yes | 21:17 |
| *** BobPungartnik <BobPungartnik!~BobPungar@187.113.154.201> has quit IRC | 21:17 | |
| *** berton <berton!~berton@181.220.83.67> has quit IRC | 21:21 | |
| JPEW | RP: Ya, I was looking through and most of the failures were from test_devtool_deploy_target, not the perl reproducible test (although there were a few). | 21:34 |
| RP | JPEW: I think its a race depending on what makes it into sstate on the original build when perl is rebuilt :/ | 21:35 |
| JPEW | RP: Rebuilds are problematic. You might be able to keep the two patches in master-next to catch it next time; it doesn't really have any overhead when there's no failure | 21:35 |
| RP | JPEW: agreed, I'll try and do that | 21:37 |
| *** litb <litb!~litb___@p5B02F489.dip0.t-ipconnect.de> has quit IRC | 21:37 | |
| * kergoth starts working on oe selftests for meta-external-toolchain, emit an oe/yocto sdk, then for each included external recipe, build the internal and external versions and compare their contents, etc | 21:50 | |
| *** armpit <armpit!~armpit@2601:202:4180:a5c0:d998:942e:6613:6ef4> has quit IRC | 21:58 | |
| *** JaMa <JaMa!~martin@ip-217-030-068-212.aim-net.cz> has quit IRC | 22:08 | |
| *** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has joined #yocto | 22:25 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 22:37 | |
| *** m1ster_r0b0t <m1ster_r0b0t!~m1ster_r0@80-110-44-28.static.upcbusiness.at> has joined #yocto | 22:42 | |
| *** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC | 22:50 | |
| RP | JPEW: A new plan - can you rebase those patches onto a failed master-next build? That might retrigger easier? | 22:58 |
| RP | JPEW: I'm about to sleep but someone else may be able to trigger a build. If not, I can sort such a branch tomorrow and trigger worse case | 22:58 |
| * RP needs to sleep | 22:59 | |
| RP | JPEW: I'm thinking if it failed once the broken sstate should be there | 22:59 |
| *** robbawebba <robbawebba!~rob@12.206.203.186> has quit IRC | 23:02 | |
| *** m1ster_r0b0t <m1ster_r0b0t!~m1ster_r0@80-110-44-28.static.upcbusiness.at> has quit IRC | 23:08 | |
| *** ericch <ericch!~ericch@50-205-235-218-static.hfc.comcastbusiness.net> has quit IRC | 23:21 | |
| *** Klanticus <Klanticus!~quassel@189.76.135.211> has quit IRC | 23:27 | |
| *** agust <agust!~agust@p54833695.dip0.t-ipconnect.de> has quit IRC | 23:27 | |
| *** Klanticus <Klanticus!~quassel@189.76.135.211> has joined #yocto | 23:28 | |
| *** vineela <vineela!~vtummala@134.134.139.76> has quit IRC | 23:46 | |
Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!