| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC | 00:02 | |
| *** ericch <ericch!~ericch@50-205-235-218-static.hfc.comcastbusiness.net> has quit IRC | 00:12 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC | 00:29 | |
| *** bluca <bluca!~bluca@88.98.246.218> has quit IRC | 00:54 | |
| yocti | New news from stackoverflow: Is it possible to run the rootfs containing kernel and DTB files for a specific board using qemu <https://stackoverflow.com/questions/59271650/is-it-possible-to-run-the-rootfs-containing-kernel-and-dtb-files-for-a-specific> | 01:58 |
|---|---|---|
| *** jklare <jklare!~jklare@157.97.76.18> has quit IRC | 02:58 | |
| *** gnac <gnac!~gnac@or-71-0-52-80.sta.embarqhsd.net> has quit IRC | 02:59 | |
| *** jklare <jklare!~jklare@157.97.76.18> has joined #yocto | 02:59 | |
| *** khem <khem!~khem@unaffiliated/khem> has quit IRC | 03:10 | |
| *** khem <khem!~khem@unaffiliated/khem> has joined #yocto | 03:22 | |
| *** saraf <saraf!~a_saraf@2405:204:911e:e7a7:d1ed:3b0b:a84f:8305> has joined #yocto | 05:19 | |
| *** saraf <saraf!~a_saraf@2405:204:911e:e7a7:d1ed:3b0b:a84f:8305> has quit IRC | 05:33 | |
| *** iceaway <iceaway!~pelle@37.233.78.69> has joined #yocto | 05:48 | |
| *** jklare <jklare!~jklare@157.97.76.18> has quit IRC | 05:59 | |
| *** jklare <jklare!~jklare@157.97.76.18> has joined #yocto | 06:02 | |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has joined #yocto | 06:22 | |
| *** clopez <clopez!~tau@neutrino.es> has quit IRC | 06:34 | |
| *** edgar444 <edgar444!uid214381@gateway/web/irccloud.com/x-dfvpmcijkrbhqtds> has quit IRC | 06:35 | |
| *** opennandra <opennandra!~marek@bband-dyn215.178-40-242.t-com.sk> has joined #yocto | 06:57 | |
| *** jklare <jklare!~jklare@157.97.76.18> has quit IRC | 06:58 | |
| *** jklare <jklare!~jklare@157.97.76.18> has joined #yocto | 07:00 | |
| *** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has joined #yocto | 07:01 | |
| *** pohly <pohly!~pohly@p54BD54FC.dip0.t-ipconnect.de> has joined #yocto | 07:10 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.245.67> has joined #yocto | 07:11 | |
| *** agust <agust!~agust@pD95F104D.dip0.t-ipconnect.de> has joined #yocto | 07:12 | |
| tlwoerner | when i send an email to the list i see: "Trevor Woerner via Lists.Yoctoproject.Org" as the sender (instead of just, say, "Trevor Woerner". is that how everyone sees their own messages? or is my email not configured correctly? | 07:26 |
| tlwoerner | halstead: ^^ | 07:26 |
| halstead | tlwoerner: everyone will see their own messages with the from line rewritten. | 07:27 |
| tlwoerner | halstead: ok, thanks :-) | 07:28 |
| halstead | Depending on the DMARC setting for the domain you'll see more addresses rewritten. | 07:28 |
| *** ka6sox is now known as zz_ka6sox | 07:29 | |
| LetoThe2nd | tlwoerner: gm! | 07:33 |
| LetoThe2nd | tlwoerner: are you still around for a second? | 07:34 |
| *** frsc <frsc!~frsc@mue-88-130-71-136.dsl.tropolys.de> has joined #yocto | 07:39 | |
| *** locutus_ <locutus_!~LocutusOf@ubuntu/member/locutusofborg> has joined #yocto | 07:55 | |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto | 07:57 | |
| *** jklare <jklare!~jklare@157.97.76.18> has quit IRC | 07:58 | |
| yocti | New news from stackoverflow: Do_compile error for libpam package: Angstrom build <https://stackoverflow.com/questions/59280918/do-compile-error-for-libpam-package-angstrom-build> | 07:59 |
| *** farnerup <farnerup!~farnerup@h-254-84-175.A137.corp.bahnhof.se> has joined #yocto | 08:00 | |
| *** hpsy <hpsy!~hpsy@217.66.60.5> has joined #yocto | 08:01 | |
| *** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 08:01 | |
| *** jklare <jklare!~jklare@157.97.76.18> has joined #yocto | 08:02 | |
| *** zz_ka6sox is now known as ka6sox | 08:05 | |
| *** mckoan|away is now known as mckoan | 08:05 | |
| mckoan | good morning | 08:05 |
| *** LocutusOfBorg <LocutusOfBorg!~LocutusOf@ubuntu/member/locutusofborg> has joined #yocto | 08:06 | |
| *** locutus_ <locutus_!~LocutusOf@ubuntu/member/locutusofborg> has quit IRC | 08:06 | |
| *** LocutusOfBorg <LocutusOfBorg!~LocutusOf@ubuntu/member/locutusofborg> has quit IRC | 08:17 | |
| *** LocutusOfBorg <LocutusOfBorg!~LocutusOf@ubuntu/member/locutusofborg> has joined #yocto | 08:19 | |
| *** yann <yann!~yann@91-170-159-152.subs.proxad.net> has quit IRC | 08:22 | |
| *** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has quit IRC | 08:24 | |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto | 08:37 | |
| *** LocutusOfBorg <LocutusOfBorg!~LocutusOf@ubuntu/member/locutusofborg> has quit IRC | 08:46 | |
| *** jklare <jklare!~jklare@157.97.76.18> has quit IRC | 08:58 | |
| *** LocutusOfBorg <LocutusOfBorg!~LocutusOf@ubuntu/member/locutusofborg> has joined #yocto | 09:00 | |
| *** jklare <jklare!~jklare@157.97.76.18> has joined #yocto | 09:01 | |
| *** LocutusOfBorg <LocutusOfBorg!~LocutusOf@ubuntu/member/locutusofborg> has quit IRC | 09:06 | |
| *** LocutusOfBorg <LocutusOfBorg!~LocutusOf@ubuntu/member/locutusofborg> has joined #yocto | 09:06 | |
| *** locutus_ <locutus_!~LocutusOf@ubuntu/member/locutusofborg> has joined #yocto | 09:10 | |
| *** locutus_ <locutus_!~LocutusOf@ubuntu/member/locutusofborg> has quit IRC | 09:11 | |
| *** LocutusOfBorg <LocutusOfBorg!~LocutusOf@ubuntu/member/locutusofborg> has quit IRC | 09:11 | |
| *** goliath <goliath!~goliath@nat002-WLTU1.uibk.ac.at> has joined #yocto | 09:13 | |
| *** yann <yann!~yann@85.118.38.73> has joined #yocto | 09:22 | |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto | 09:24 | |
| *** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 09:30 | |
| *** florian_kc is now known as florian | 09:32 | |
| *** farnerup <farnerup!~farnerup@h-254-84-175.A137.corp.bahnhof.se> has quit IRC | 09:36 | |
| *** ka6sox is now known as zz_ka6sox | 09:37 | |
| *** grumble <grumble!~grumble@freenode/staff/grumble> has quit IRC | 09:38 | |
| *** grumble <grumble!~grumble@freenode/staff/grumble> has joined #yocto | 09:40 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 09:40 | |
| *** zz_ka6sox is now known as ka6sox | 09:41 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 09:43 | |
| *** jklare <jklare!~jklare@157.97.76.18> has quit IRC | 10:00 | |
| *** jklare <jklare!~jklare@157.97.76.18> has joined #yocto | 10:03 | |
| RP | ok, lets try 3.1 M1 rc5 :/ | 10:11 |
| *** clopez <clopez!~tau@neutrino.es> has joined #yocto | 10:15 | |
| *** bluca <bluca!~bluca@88.98.246.218> has joined #yocto | 10:24 | |
| *** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-uuuxklvxbkxpsldb> has joined #yocto | 10:26 | |
| *** falk0n <falk0n!~falk0n@a109-49-156-195.cpe.netcabo.pt> has joined #yocto | 10:27 | |
| yocti | New news from stackoverflow: Listing SRC_URI of all packages/files needed to build Yocto image <https://stackoverflow.com/questions/50345536/listing-src-uri-of-all-packages-files-needed-to-build-yocto-image> | 10:29 |
| LetoThe2nd | RP: if you leave out one specific word, then the mail is pretty funny: "How about extending uninative with more bits?" :) | 10:44 |
| *** ThomasD13 <ThomasD13!~ThomasD13@DSL01.212.114.255.148.ip-pool.NEFkom.net> has joined #yocto | 10:55 | |
| *** jklare <jklare!~jklare@157.97.76.18> has quit IRC | 10:57 | |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC | 10:58 | |
| *** JaMa <JaMa!~martin@109.238.218.228> has joined #yocto | 10:58 | |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has joined #yocto | 10:58 | |
| *** jklare <jklare!~jklare@157.97.76.18> has joined #yocto | 10:59 | |
| *** guerinoni <guerinoni!~guerinoni@internet.micro-systems.it> has quit IRC | 11:04 | |
| *** farnerup <farnerup!~farnerup@h-254-84-175.A137.corp.bahnhof.se> has joined #yocto | 11:09 | |
| *** farnerup <farnerup!~farnerup@h-254-84-175.A137.corp.bahnhof.se> has quit IRC | 11:32 | |
| *** goliath <goliath!~goliath@nat002-WLTU1.uibk.ac.at> has quit IRC | 11:33 | |
| JaMa | RP: with the sstate changes from yesterday I'm seeing: Exception: bb.process.ExecutionError: Execution of '/OE/build/oe-core/tmp-glibc/work/x86_64-linux/quilt-native/0.66-r0/temp/run.sstate_create_package.25465' failed with exit code 1: | 11:35 |
| JaMa | mktemp: failed to create file via template ‘/OE/build/oe-core/sstate-cache/universal/5b/sstate:quilt-native:x86_64-linux:0.66:r0:x86_64:3:5b5ddc2dc26dbbdaa89060f194e5a6b56a048a7a6ad3b71bd290bd528355e70d_populate_sysroot.tgz.XXXXXXXX’: No such file or directory | 11:35 |
| JaMa | in clean build, any idea what went wrong? | 11:36 |
| JaMa | only .siginfo files were created in sstate-cache | 11:37 |
| *** berton <berton!~berton@189.103.49.163> has joined #yocto | 11:38 | |
| *** berton <berton!~berton@189.103.49.163> has quit IRC | 11:40 | |
| *** berton <berton!~berton@189.103.49.163> has joined #yocto | 11:43 | |
| RP | JaMa: fix is in master I think | 11:51 |
| RP | JaMa: I messed up the last fix :( | 11:51 |
| *** farnerup <farnerup!~farnerup@h-254-84-175.A137.corp.bahnhof.se> has joined #yocto | 11:54 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.245.67> has quit IRC | 11:54 | |
| JaMa | RP: I do have this one http://git.openembedded.org/openembedded-core/commit/?id=0af4dae84099e8632a9ea6a4afdbea2f232bb170 | 11:55 |
| RP | JaMa: and its still breaking? :( | 11:55 |
| RP | JaMa: the patch is messed up, again. The mkdir needs to be about 8 lines higher :( | 11:56 |
| JaMa | yes, here is the trace if you can spot the code path leading to this https://paste.ubuntu.com/p/4TZP5w6dTN/ | 11:56 |
| JaMa | ok, let me check | 11:57 |
| RP | JaMa: sorry, these changes were meant to be straight forward small tweaks and have turned into a disaster ;( | 11:57 |
| *** jklare <jklare!~jklare@157.97.76.18> has quit IRC | 11:57 | |
| JaMa | ah right, above mktemp | 11:58 |
| JaMa | strange that it's failing only on some hosts it seems | 11:58 |
| *** goliath <goliath!~goliath@nat002-WLTU1.uibk.ac.at> has joined #yocto | 11:59 | |
| RP | JaMa: depends how many of the sstate dirs are present? | 12:00 |
| RP | JaMa: I've put a fix in master | 12:00 |
| JaMa | both builds were clean without sstate-cache | 12:00 |
| *** jklare <jklare!~jklare@157.97.76.18> has joined #yocto | 12:00 | |
| JaMa | and mktemp fails without existing directory on the builder where the build itself doesn't fail as well | 12:01 |
| JaMa | might be that only my local build where it was failing has hashequiv enabled | 12:01 |
| * RP stops rc5 and goes to rc6 | 12:02 | |
| LetoThe2nd | disaster? i hear disaster? | 12:08 |
| *** stuom1 <stuom1!3eecd81d@62.236.216.29> has joined #yocto | 12:14 | |
| JaMa | RP: btw: that mkdir is using spaces for indentation and other lines around are tabs | 12:16 |
| JaMa | whitespace fix http://git.openembedded.org/openembedded-core-contrib/commit/?h=jansa/master&id=dd8620447448df890799e63a8cc300b44d99b3f4 | 12:19 |
| stuom1 | anyone have experience making recipes for npm projects? | 12:21 |
| LetoThe2nd | stuom1: many have, and it universally considered a pain in the .... not only there, about everywhere. | 12:24 |
| stuom1 | in my recipe (made with devtool) I have PV = "0.1.0+git${SRCPV}" but I get npm error for not finding file '/path/to/project-0.1.0+git999.tgz' because it is called '/path/to/project-0.1.0.tgz'. Where is that 999 coming to SRCPV and how to get it match | 12:25 |
| stuom1 | LetoThe2nd oh good, im not alone | 12:25 |
| *** u1106_ is now known as u1106 | 12:26 | |
| *** opennandra <opennandra!~marek@bband-dyn215.178-40-242.t-com.sk> has quit IRC | 12:27 | |
| stuom1 | I get it to build, if I remove the +git${SRCPV} part completely, but it builds only ONCE, next try fails with completely new problems, so I try to tackle them one at a time | 12:27 |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 12:31 | |
| RP | JaMa: ahhrg, right :/ | 12:33 |
| stuom1 | with PV = "0.1.0" I can build it once using "devtool build" but if I try second time without any changes, or try to bitbake an image, I get "npm ERR! Cannot read property 'replace' of null" | 12:34 |
| *** leon-anavi <leon-anavi!~Leon@78.130.245.67> has joined #yocto | 12:37 | |
| tlwoerner | LetoThe2nd: hey! it was off to bed seconds after i wrote that; i didn't even see the DMARC reply :-) | 12:42 |
| LetoThe2nd | tlwoerner: hehe | 12:43 |
| LetoThe2nd | tlwoerner: hope you had a good night then! | 12:44 |
| tlwoerner | LetoThe2nd: it was a little shorter than i would have liked; i'll probably need a nap this afternoon ;-) | 12:45 |
| LetoThe2nd | tlwoerner: happends, that! just had one remark, and one idea/question. | 12:46 |
| LetoThe2nd | tlwoerner: remark: once you find (or even create) a good outline on the topic you put on the ML, i'd be glad to see it! | 12:47 |
| qschulz | does anyone know how to increase loglevel or verbosity for qemu-wrapper? I'm trying to give more information on that gobject-introspection + icecc bug on >= warrior and khem asked for more info | 12:50 |
| tlwoerner | LetoThe2nd: sounds good. it's not enough to simply read a recipe top-to-bottom, one has to consider *when* various parts (e.g. tasks) will run. it's like reading VHDL or verilog: the order doesn't matter! | 12:51 |
| *** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC | 12:52 | |
| *** vmeson <vmeson!~rmacleod@24-52-239-53.cable.teksavvy.com> has quit IRC | 12:52 | |
| LetoThe2nd | tlwoerner: the other is, like an idea. what do you think about preparing a bootable thumb drive that brings a fully prepared yocto/oe setup for a specific board, including hot sstate and all? | 12:53 |
| LetoThe2nd | i've been looking into ubuntu-based stuff here, but no real clue yet. | 12:54 |
| LetoThe2nd | i mean, it would be rather huge, hard to make it downloadable - but not exactly unheard of, but drives are cheap and shipping them trough mail is easy. | 12:56 |
| *** jklare <jklare!~jklare@157.97.76.18> has quit IRC | 12:59 | |
| tlwoerner | sneakernet! or carrier pigeon | 13:00 |
| LetoThe2nd | bth! | 13:00 |
| *** goliath <goliath!~goliath@nat002-WLTU1.uibk.ac.at> has quit IRC | 13:02 | |
| tlwoerner | a long time ago ndec and myself were giving a tutorial at a Linaro Connect (in Dublin, if I remember correctly?) and we brought a thumb drive with a hot cache, sstate-cache, tmp etc. the only *gotcha* is that the host distro version has to match for the sstate-cache to work | 13:03 |
| tlwoerner | i think this was in the days before the amazing build accounts halstead sets up for devdays | 13:04 |
| *** jklare <jklare!~jklare@157.97.76.18> has joined #yocto | 13:04 | |
| tlwoerner | we handed out the drives and people copied them to their machines before starting the tutorial | 13:04 |
| tlwoerner | in sstate-cache is a host-distro-specific directory, if the host distro version doesn't match, the hot sstate is ignored and the machine ends up building everything from scratch | 13:05 |
| tlwoerner | but you can take the same sstate-cache directory to several hosts and the directory will contain multiple host-distro-specific directories | 13:06 |
| LetoThe2nd | tlwoerner: eactly, there's still a couple of gotches. | 13:06 |
| erbo | You could also maybe do builds in a docker container, to make sure "host distro" is the same regardless of the users distro choice. | 13:08 |
| *** stuom1 <stuom1!3eecd81d@62.236.216.29> has quit IRC | 13:09 | |
| LetoThe2nd | erbo: and ship a 50GB docker container? | 13:10 |
| LetoThe2nd | i'm rather envisioning a setup that boots, and has the absolutely highest chances of supporting one target instantly. without downloads, without big rebuilds. | 13:11 |
| *** stuom1 <stuom1!3eecd81d@62.236.216.29> has joined #yocto | 13:13 | |
| JaMa | tlwoerner: uninative helps with that, doesn't it? | 13:13 |
| tlwoerner | LetoThe2nd: ooh, i hadn't thought of making it bootable. that would solve the "host distro version" matching thing. but would mean you'd need drives for everyone in the class (which isn't too onerous) | 13:14 |
| LetoThe2nd | tlwoerner: i'm not thinking about classes. | 13:14 |
| tlwoerner | JaMa: isn't uninative about having the same host (native) tools? uninative doesn't setup sstate does it? | 13:15 |
| erbo | LetoThe2nd: I usually bind mount the sstate-dirs, downloads, meta-data and tmp-dir etc into the container. So that the container doesn't ever change, it's basically just a poky-container with a few extra packages for conveniece. | 13:16 |
| erbo | But sure, a bootable USB solves it too | 13:17 |
| LetoThe2nd | erbo: yeah. we do that too, and its all nice and such for people who know their way. | 13:17 |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto | 13:18 | |
| LetoThe2nd | i want something that i can give to somebody who literally has *no* *clue* | 13:18 |
| erbo | Yeah then adding a layer of docker might not be the best thing to do :) | 13:18 |
| LetoThe2nd | bingo | 13:19 |
| LetoThe2nd | anything that requires manual interaction/setup is too much | 13:19 |
| *** tgamblin <tgamblin!~tgamblin@128.224.252.2> has joined #yocto | 13:21 | |
| *** georgem <georgem!~georgem@216.21.169.52> has joined #yocto | 13:24 | |
| tlwoerner | LetoThe2nd: https://dilbert.com/strip/1995-06-24 | 13:27 |
| LetoThe2nd | tlwoerner: yeah | 13:30 |
| *** vmeson <vmeson!~rmacleod@128.224.252.2> has joined #yocto | 13:32 | |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto | 13:35 | |
| *** PaowZ_ <PaowZ_!~Vince@193.252.149.222> has joined #yocto | 13:44 | |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has joined #yocto | 13:44 | |
| PaowZ_ | Hello there! I'm trying out YP through the use of Build Appliance.. I then ran a "bitbake core-image-minimal" as a simple test and ran into an error while building /home/builder/poky/meta/recipes-devtools/gcc/gcc-cross_9.2.bb.. well, it seems it does not build out of the box.. where should I look into, first ? | 13:47 |
| LetoThe2nd | build appliace? | 13:47 |
| PaowZ_ | LetoThe2nd: yes, Build Appliance - Zeus 3.0 | 13:49 |
| LetoThe2nd | PaowZ_: can you pointme to your source? | 13:50 |
| PaowZ_ | The Build Appliance is a virtual machine which enables you to build and boot a custom embedded Linux image with the Yocto Project using a non-Linux development system | 13:50 |
| PaowZ_ | https://www.yoctoproject.org/software-overview/downloads/ | 13:50 |
| PaowZ_ | I just ran that image into VirtualBox | 13:51 |
| LetoThe2nd | you see me surprised that the build appliance even is seeing new releases | 13:52 |
| PaowZ_ | new package releases, you mean ? | 13:52 |
| LetoThe2nd | new yocto releases, i mean | 13:53 |
| RP | PaowZ_: what was the error? | 13:53 |
| *** abhiarora44 <abhiarora44!uid396576@gateway/web/irccloud.com/x-kajgomwkjlautkws> has joined #yocto | 13:55 | |
| PaowZ_ | RP: https://snipboard.io/wQByfq.jpg | 13:55 |
| RP | PaowZ_: if you "bitbake gcc-cross-x86_64 -c clean" and rerun the build do you get the same error? | 13:56 |
| PaowZ_ | by "rerun the build", there is a specific command or I just "bitbake core-image..." ? | 13:57 |
| *** jklare <jklare!~jklare@157.97.76.18> has quit IRC | 13:58 | |
| PaowZ_ | I'm cleaning the way you advise, though.. | 13:58 |
| RP | PaowZ_: just bitbake core-image... again | 13:58 |
| PaowZ_ | ok.. I keep you posted.. thanks.. | 13:59 |
| RP | PaowZ_: its unusual for gcc-cross to break that like. The times I've seen a VM do this before were often memory issues on the system :( | 13:59 |
| RP | PaowZ_: if it does exactly the same thing again its probably not memory, if it breaks randomly somewhere else each time, it probably is | 14:00 |
| RP | PaowZ_: but its the best place to start in figuring out what is wrong... | 14:00 |
| PaowZ_ | interesting point, RP.. here the settings for the VM: 4cores, 2048MB for ram and 54GB for disk.. | 14:01 |
| *** jklare <jklare!~jklare@157.97.76.18> has joined #yocto | 14:01 | |
| PaowZ_ | aside, I have IO-APIC enabled and PAE disabled (don't need it, I think..) | 14:02 |
| LetoThe2nd | 2048mb ram is a serious bummer | 14:02 |
| PaowZ_ | too short ? | 14:02 |
| LetoThe2nd | yup | 14:03 |
| PaowZ_ | ok.. well.. I gonna change the settings for upper amount.. | 14:03 |
| PaowZ_ | I keep you posted, guys, thanks for the responsiveness :) | 14:03 |
| LetoThe2nd | it hopefully shouldn't hit that hard, but "GB including the whole building host system is really, really tiny :P | 14:04 |
| PaowZ_ | 2GB is really short in my guess, when it comes to build toolchain, indeed.. I should have thought about it.. | 14:05 |
| *** stuom1 <stuom1!3eecd81d@62.236.216.29> has quit IRC | 14:07 | |
| RP | PaowZ_: I'm more worried about whether there is an issue with the underlying memory hardware or the virtualisation mechanism. We've seen both give errors a bit like that... | 14:07 |
| RP | The virt issue was many years ago when it was much newer technology | 14:08 |
| PaowZ_ | this used to be true, for virtualization mechanism, back then.. but now it tends to be quite reliable | 14:10 |
| RP | PaowZ_: see how the build goes, that should give a hint | 14:10 |
| PaowZ_ | yup.. it's currently ongoing.. | 14:11 |
| PaowZ_ | thanks to the cache.. | 14:11 |
| RP | PaowZ_: has it gotten past gcc-cross? | 14:12 |
| PaowZ_ | RP: currently being built :) | 14:22 |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC | 14:23 | |
| JaMa | tlwoerner: maybe I misunderstood what you meant with "sstate-cache is a host-distro-specific directory, if the host distro version doesn't match, the hot sstate is ignored" but with uninative the ssate isn't specific to host distro and the path to sstate-cache or sstate mirror isn't included in the signatures, so it should be used just fine (as long as the metadata are matching) | 14:28 |
| tlwoerner | JaMa: ooh, i didn't know that! interesting | 14:29 |
| JaMa | tlwoerner: without uninative all native sstate will be in host distro specific LSB directory inside sstate-cache and indeed not reused in different distros and because target recipes now include native signatures, it will make whole sstate-cache host-distro specific | 14:30 |
| tlwoerner | yes, that's what I've seen. i got around that by mounting the same sstate directory into different hosts and running each build on each host but with one sstate. it inflated the sstate, but then ensured the cache was "hot" for anyone using it on their machine | 14:32 |
| tlwoerner | but your suggestion would be much better. noted! thanks :-) | 14:32 |
| PaowZ_ | RP: do_compile ok for gcc-cross-x86 | 14:35 |
| *** andycooper <andycooper!uid246432@gateway/web/irccloud.com/x-kxbjcrcvlceuhkdw> has joined #yocto | 14:39 | |
| RP | PaowZ_: I'd probably run memtest on the hardware that VM is running on | 14:41 |
| RP | PaowZ_: also possible it was some kind of parallel make race but less likely | 14:41 |
| qschulz | I'm wondering, what's the rationale behind having MACHINEOVERRIDES loosely set to MACHINE, forcing us to use prepends. We're leveraging this prepend stuff in some of our includes as well, but I discovered today that we should put those MACINESOVERRIDES =. *before* all `require` prepending to [e=13]pike [r=14]NickServ [t=15]#brootlin [y=16]alex [u=17]#guy [i=18]NamNam [o=19]atenart [20]paulk-leonov | 14:42 |
| qschulz | ugh | 14:42 |
| qschulz | I'm wondering, what's the rationale behind having MACHINEOVERRIDES loosely set to MACHINE, forcing us to use prepends. We're leveraging this prepend stuff in some of our includes as well, but I discovered today that we should put those MACHINESOVERRIDES =. *before* all `require` prepending to the said variable | 14:42 |
| PaowZ_ | RP: Using "top" command I could estimate how heavy the threads build are.. It really needed 8GB at least.. | 14:42 |
| RP | qschulz: MACHINEOVERRIDES is what is added to OVERRIDES, not MACHINE | 14:43 |
| RP | PaowZ_: right, but that should have given an OOM error, not an assembler failure | 14:43 |
| qschulz | RP: MACHINE is in MACHINEOVERRIDES: http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/bitbake.conf#n740 | 14:46 |
| RP | qschulz: exactly, so what is your question? | 14:46 |
| RP | it has a default, a machine can override it to what it needs if the default doesn't work? | 14:47 |
| RP | qschulz: I guess the answer you probably are looking for is some machines may want to override the whole thing and not have MACHINE in there | 14:48 |
| qschulz | RP: In my mind, one would absolutely want MACHINE to be the rightmost part of MACHINEOVERRIDES | 14:52 |
| PaowZ_ | RP: "god knows.." ;) | 14:52 |
| RP | qschulz: not if you're making some clone of a machine to change one setting and want it to otherwise behave as the original | 14:53 |
| RP | qschulz: we even test that | 14:53 |
| qschulz | RP: we require the original machine conf file for that | 14:53 |
| qschulz | and MACHINEOVERRIDES the name of the required machine conf file | 14:53 |
| qschulz | which means we need this MACHINEOVERRIDES before the require | 14:54 |
| qschulz | I'm not saying it does not work. It just feels weird to me for this particular variable to "be forced" to have it prepended before doing requires | 14:55 |
| RP | qschulz: well, I'm saying that people do use it like I describe and its very hard to undo an append/prepend so this is why its like this | 14:55 |
| RP | qschulz: I suspect its expected that most machines would just force a new value and include MACHINE | 14:56 |
| RP | then no prepending required | 14:56 |
| *** jklare <jklare!~jklare@157.97.76.18> has quit IRC | 14:56 | |
| *** roussinm <roussinm!~mroussin@ipagstaticip-d73c7528-4de5-0861-800b-03d8b15e3869.sdsl.bell.ca> has joined #yocto | 14:59 | |
| qschulz | RP: that means that we need to force MACHINEOVERRIDES for each similar machine, error-prone if you have many different includes and MACHINEOVERRIDES. | 14:59 |
| RP | qschulz: so build it carefully with prepends and appends | 15:00 |
| *** jklare <jklare!~jklare@157.97.76.18> has joined #yocto | 15:00 | |
| qschulz | RP: Is there any known use case for not wanting MACHINE in MACHINEOVERRIDES? | 15:00 |
| RP | qschulz: yes, I described it above | 15:00 |
| *** kanavin__ <kanavin__!~kanavin@141.113.66.202> has quit IRC | 15:00 | |
| *** kanavin__ <kanavin__!~kanavin@141.113.66.202> has joined #yocto | 15:00 | |
| RP | qschulz: I create a machine called "qemux86copy", I don't want "qemux86copy" in overrides | 15:00 |
| RP | qschulz: mentioned in meta/lib/oeqa/selftest/cases/sstatetests.py and used by several people as a way of testing various pieces of the system | 15:01 |
| qschulz | RP: if we don;t leverage qemux86copy anywhere, it does not hurt to have it MACHINEOVERRIDES | 15:01 |
| qschulz | RP: ok, will read. Thanks ,anyway was just being curious :) | 15:02 |
| RP | qschulz: extra overrides slow down the datastore and have a habit of being dangerous IMO | 15:02 |
| * RP is suitably scared of overrides but I know how the code works :( | 15:02 | |
| RP | qschulz: you are correct in that it could have been done differently however it was done this way and it has pros/cons | 15:03 |
| qschulz | well, I'm scared too now (again) because I thought we already fixed our disordered MACHINEOVERRIDES but no :) forgot this one | 15:03 |
| *** ThomasD13 <ThomasD13!~ThomasD13@DSL01.212.114.255.148.ip-pool.NEFkom.net> has quit IRC | 15:04 | |
| *** AndersD <AndersD!~AndersD@h-98-128-162-82.NA.cust.bahnhof.se> has quit IRC | 15:05 | |
| qschulz | RP: I just wanted to hear if there was a very specific use case which warranted this behavior or if it just turned out to be the chosen implementation. I.e. I wanted to know if I should say to people in my company "it is how it is" or "it is like that because of..." | 15:05 |
| *** sstabellini <sstabellini!sstabellin@gateway/shell/xshellz/x-wwwzglyzdetzrhzc> has joined #yocto | 15:06 | |
| qschulz | your qemu example looks like a very specific use case so I'll read that file. Thanks for having taken the time to answer me, much appreciated | 15:06 |
| RP | qschulz: the principle use case is to allow overriding when MACHINE isn't what you want in overrides | 15:06 |
| RP | changing an append/prepend is near impossible so that is why we don't use them here | 15:06 |
| qschulz | RP: understood, I was failing to see the "when MACHINE isn't what you want in overrides" use case | 15:06 |
| qschulz | RP: yeah and we don't want to use _remove as much as possible | 15:07 |
| RP | qschulz: I'd prefer never ;-) | 15:07 |
| RP | qschulz: using _remove in the middle of overrides construction would also be asking for trouble/performance problems | 15:09 |
| RP | qschulz: sorry, I think I'm feeling jaded today :/ | 15:12 |
| * RP has an inbox of email about how performance sucks and we have all these other problems :/ | 15:13 | |
| LetoThe2nd | RP: pipe to /dev/null and let people screw themselves :) | 15:13 |
| RP | LetoThe2nd: perhaps you could take care of bug triage this week :) | 15:14 |
| LetoThe2nd | RP: i can declare it as a yocto bof? | 15:15 |
| RP | LetoThe2nd: not really :) | 15:23 |
| LetoThe2nd | RP: no deal then. | 15:23 |
| JPEW | RP: Here's my PoC on how I think the AB hash equiv failure could be fixed: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=jpew/reproducible&id=2030f68d109a1f7e9c3fd4635b5a95724e18ce22 I don't think it's doing the "uncover" in the correct location, and it royal screws up the build stats reporting (but I have an idea for that). | 15:25 |
| *** goliath <goliath!~goliath@clnet-p04-043.ikbnet.co.at> has quit IRC | 15:29 | |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto | 15:29 | |
| RP | JPEW: Allowing multiple "normal" task exection? | 15:30 |
| RP | JPEW: that breaks a ton of assumptions all over the system :( | 15:30 |
| JPEW | RP: Ya, basically, but only when they were previously covered by setscene | 15:31 |
| JPEW | RP: e.g. were previously skipped because they were covered by setscene | 15:31 |
| RP | JPEW: ah, right. I thought the code could already handle this, we just disabled it due to problems? | 15:33 |
| JPEW | RP: Maybe... but that might of been before we had the "force tasks to be equivalent" | 15:33 |
| JPEW | RP: Without that, stuff was reexecuting all the time | 15:34 |
| JPEW | (unnecessarily) | 15:34 |
| JPEW | I think we need it back for the specific (and rare) case where the server can't give us the hash we want | 15:34 |
| RP | JPEW: I don't like it, we disabled this for a reason :/ | 15:36 |
| *** ericch <ericch!~ericch@50-205-235-218-static.hfc.comcastbusiness.net> has joined #yocto | 15:43 | |
| *** farnerup <farnerup!~farnerup@h-254-84-175.A137.corp.bahnhof.se> has quit IRC | 15:48 | |
| *** jklare <jklare!~jklare@157.97.76.18> has quit IRC | 15:57 | |
| *** jklare <jklare!~jklare@157.97.76.18> has joined #yocto | 16:00 | |
| *** leon-anavi <leon-anavi!~Leon@78.130.245.67> has quit IRC | 16:04 | |
| JPEW | RP: Hmm.... Ok. I'll keep thinking about it. | 16:08 |
| RP | JPEW: sorry, not trying to be negative, I appreciate the thought. I just worry about the problems we had with this previously. Perhaps it would be ok in the rare case this happens... | 16:12 |
| RP | JPEW: I'll ponder it some more too | 16:12 |
| JPEW | RP: It's fine :) | 16:13 |
| * RP wonders why buildperf is breaking but only for release builds | 16:13 | |
| * RP suspects need to file another bug | 16:13 | |
| RP | reproducibile builds failed the selftests for 3 out of 4 in the release build too :( | 16:14 |
| *** yann <yann!~yann@85.118.38.73> has quit IRC | 16:16 | |
| *** yann <yann!~yann@85.118.38.73> has joined #yocto | 16:16 | |
| *** orzen <orzen!~orz@84-216-100-149.customers.ownit.se> has quit IRC | 16:17 | |
| JPEW | RP: Do you have a log on that one? | 16:17 |
| armpit | RP, the buildperf systems are Union | 16:19 |
| armpit | RP, are the failures saving perf results? | 16:19 |
| * armpit should just go look | 16:20 | |
| RP | JPEW: selftests from https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/570 | 16:20 |
| RP | JPEW: will be the perl issue I expect | 16:21 |
| RP | armpit: /home/pokybuild/yocto-worker/buildperf-ubuntu1604/yocto-autobuilder-helper/scripts/upload-error-reports: line 11: cd: /home/pokybuild/yocto-worker/buildperf-ubuntu1604/build/build/../: No such file or directory | 16:21 |
| RP | whatever that means | 16:21 |
| armpit | two build dirs ?? | 16:21 |
| RP | armpit: normal | 16:22 |
| RP | armpit: one is buildbot, one is ours | 16:22 |
| armpit | there have been a range of issue. your master-next build where lookin for /master | 16:22 |
| armpit | I opened a bug on that one | 16:23 |
| RP | armpit: master-next would look for master to compare against | 16:23 |
| armpit | it was looking for /master dir to save | 16:23 |
| JPEW | RP: One of them looks like libgcc, I don't think thats one of the usual perl ones | 16:24 |
| RP | JPEW: this is the problem with failures, that mask things | 16:24 |
| RP | s/that/they/ | 16:24 |
| JPEW | RP: Ya :( | 16:26 |
| * JPEW really needs to get the diffoscope reporting into the test result | 16:26 | |
| *** TobSnyder <TobSnyder!~schneider@ip5f5aa32f.dynamic.kabel-deutschland.de> has quit IRC | 16:26 | |
| JaMa | should unzip be in HOSTTOOLS? (there is gunzip already), today I've started seeing do_unpack failures "/bin/sh: 1: unzip: not found | 16:30 |
| *** bernardoaraujo <bernardoaraujo!uid179602@gateway/web/irccloud.com/x-vumbctcbyunqnwme> has quit IRC | 16:31 | |
| *** orzen <orzen!~orz@84-216-100-149.customers.ownit.se> has joined #yocto | 16:32 | |
| *** yann <yann!~yann@85.118.38.73> has quit IRC | 16:33 | |
| *** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC | 16:34 | |
| RP | JaMa: doesn't the fetcher code add an unzip-native depends (or zip-native or whatever?) | 16:40 |
| RP | JaMa: gzip is common for sources and our bootstrap, zip, less so on linux | 16:40 |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 16:41 | |
| RP | JaMa: yes, it does in base.bbclass | 16:42 |
| *** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has joined #yocto | 16:50 | |
| *** hpsy <hpsy!~hpsy@217.66.60.5> has quit IRC | 16:51 | |
| *** vineela <vineela!~vtummala@134.134.139.76> has joined #yocto | 16:52 | |
| kergoth | Anyone know offhand if oe.package/package_manager/sdk/rootfs provide methods to produce the list of files for an installed package (ideally, all installed packages) in a rootfs/sysroot/sdk? | 16:56 |
| kergoth | looking to provide a recipe/files mapping in a sysroot in a non-package-manager-specific way | 16:57 |
| *** jklare <jklare!~jklare@157.97.76.18> has quit IRC | 17:00 | |
| milloni | how is TARGET_ARCH set? i cant find the history for it in `bitbake -e` | 17:02 |
| *** jklare <jklare!~jklare@157.97.76.18> has joined #yocto | 17:03 | |
| *** marble_visions_ <marble_visions_!~user@68.183.79.8> has quit IRC | 17:06 | |
| *** marble_visions <marble_visions!~user@68.183.79.8> has joined #yocto | 17:07 | |
| *** ka6sox is now known as zz_ka6sox | 17:07 | |
| marble_visions | hi all, i want to support two versions of the kernel, built from the same source, dev and rel | 17:10 |
| marble_visions | i am wondering what's the best approach to this, without involving yocto-kernel-cache | 17:11 |
| marble_visions | one thing that pops up in the manuals is to have config fragments that enable features... so with this scheme i'd have a stripped down rel kernel, with features adding the dev stuff on top | 17:12 |
| milloni | marble_visions: do i understand correctly that you have your own kernel tree, that is you dont want/cannot use the default yocto one | 17:12 |
| marble_visions | milloni: the kernel comes from a semi vendor, namely nxp, via the meta-fsl-bsp-* layers | 17:12 |
| marble_visions | and i'm not sure how much of the upstream yocto kernel dev practices they follow, i need to doublecheck | 17:13 |
| milloni | and you want to continue using their recipe, pointing to the same git commit, just use a different config? | 17:13 |
| marble_visions | exactly, different configs* | 17:13 |
| marble_visions | and i guess i would select the configs on the image-level | 17:14 |
| *** jonmason <jonmason!sid36602@gateway/web/irccloud.com/x-abmfbzflozsxqqwh> has quit IRC | 17:14 | |
| marble_visions | although i'd like all of them to be build at the same time.. since there won't be any complex dependencies between kernels and userspace | 17:14 |
| *** jonmason <jonmason!sid36602@gateway/web/irccloud.com/x-utkoeprpuhmnusyb> has joined #yocto | 17:14 | |
| milloni | i suppose you dont want to keep two different configs | 17:14 |
| milloni | because you want to avoid having an overlap between (and then having to be careful that they dont become out of sync)? | 17:15 |
| marble_visions | actually i'd like to | 17:15 |
| marble_visions | oh yeah.. | 17:15 |
| marble_visions | what's the alternative? kernel feature selection? | 17:15 |
| milloni | there are config "fragments" | 17:16 |
| milloni | so you would have your defconfig for your rel build | 17:16 |
| milloni | and then assume for your dev build you want to enable additional options | 17:17 |
| milloni | you would put those options in a config fragment | 17:17 |
| marble_visions | yep, that was the cleanest i could figure out | 17:17 |
| milloni | but first, you want to be able to build rel and dev builds | 17:18 |
| milloni | it seems to me that the best way to implement this is this | 17:18 |
| milloni | you'd create two distro configs | 17:19 |
| milloni | one for rel the other dev | 17:19 |
| milloni | and that's going to tweak the options you want for your rel/dev images | 17:19 |
| marble_visions | so it would be one distro, two images? | 17:20 |
| milloni | two distros | 17:20 |
| milloni | or actually, i suppose a two machine configs would make more sense | 17:20 |
| *** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto | 17:21 | |
| milloni | so, do you understand the distinction between distro, machine, and image? | 17:21 |
| marble_visions | i know they're distinct, but i don't know the details | 17:21 |
| marble_visions | if it's in the manuals i will find it | 17:21 |
| marble_visions | but if there is any arcane knowledge please share :) | 17:22 |
| milloni | it's not really arcane knowledge, it's just a bit fuzzy... | 17:22 |
| milloni | hopefully someone will correct me if im wrong, but here's my understanding | 17:22 |
| milloni | first, image is defined by your image recipe, and it's just a regular recipe | 17:23 |
| milloni | this is important and a lot of people miss this | 17:23 |
| milloni | an image recipe defines how an image is built, it will use the artifacts built from other recipes etc, but the way it is implemented it's just a regular recipe | 17:23 |
| milloni | this is important because it means any option set in the image recipe only affects the image recipe | 17:24 |
| marble_visions | okay | 17:25 |
| milloni | it's a common mistake to set let's say PREFERRED_VERSION_virtual/kernel in the image recipe and think it's going to affect the entire build | 17:25 |
| milloni | so in your specific case we're going to leave the image reciple alone | 17:26 |
| milloni | the other two set global build options | 17:26 |
| milloni | i.e distro and machine | 17:26 |
| milloni | which means that any option you set there will affect every recipe in the build | 17:26 |
| milloni | this is perfect for making build-wide tweaks | 17:27 |
| JaMa | RP: looks like unzip issue might be caused by broken sstate for it (run out of disk space during the build last night), the interpretrer doesn't look right sysroots-components/x86_64/unzip-native/usr/bin/unzip: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /jenkins, for GNU/Linux 3.2.0, BuildID[sha1]=1c1124606c58a4945ee41e0a453376b9827bb5d7, stripped | 17:27 |
| milloni | i said the concept is a bit fuzzy because to a degree it's a matter of convention what should go into distro and what should go into the machine | 17:27 |
| milloni | both are build-wide | 17:28 |
| JaMa | make interpreter also doesn't look very complete sysroots-components/x86_64/make-native/usr/bin/make: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/l, for GNU/Linux 3.2.0, BuildID[sha1]=9b552261fb11831ed9c357668beae0962cb967d4, stripped - actually it's in all native binaries I've checked now | 17:28 |
| marble_visions | milloni: right | 17:28 |
| milloni | marble_visions: but basically, i assume you've got your bsp for the board that you're using? | 17:28 |
| milloni | does it define a machine config? | 17:29 |
| marble_visions | it does | 17:30 |
| milloni | so lets say your machine config is called machine.conf | 17:30 |
| milloni | in your layer, i would create a new machine config | 17:30 |
| milloni | conf/machine/myproject-dev.conf | 17:30 |
| milloni | put | 17:31 |
| milloni | require conf/machine/machine.conf | 17:31 |
| milloni | and then below that, anything you want to set for you machine | 17:31 |
| milloni | now we just need to figure out how to conditionally include a kernel config fragment based on the machine | 17:32 |
| marble_visions | i guess the quick and dirty way would be in local.conf with the VAR[var] syntax? | 17:33 |
| *** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC | 17:33 | |
| marble_visions | i see uboot does this with UBOOT_CONFIG[mfg/nand/etc] | 17:33 |
| milloni | im not familair with that syntax | 17:33 |
| milloni | i was thinking | 17:34 |
| milloni | SRC_URI += "debug-config.cfg" | 17:34 |
| milloni | sorry | 17:34 |
| milloni | SRC_URI += "file://debug-config.cfg" | 17:34 |
| milloni | expect you would only append that for your debug machine | 17:34 |
| milloni | not sure but i think this may be the syntax: | 17:35 |
| milloni | SRC_URI_myproject-dev += "file://debug-config.cfg" | 17:35 |
| milloni | means only append to SRC_URI for MACHINE myproject-dev | 17:35 |
| marble_visions | and i select MACHINE when setting up the build | 17:36 |
| marble_visions | when sourcing yocto setup | 17:36 |
| marble_visions | okay, that looks reasonable | 17:36 |
| milloni | yeah, either in local.conf or by setting MACHINE env variable | 17:36 |
| milloni | the sstate cache will be valid betwen dev and rel builds (most of it) | 17:37 |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 17:37 | |
| milloni | so you won't have to rebuild too much, and you wont have to maintain separate layers for your debug build | 17:38 |
| milloni | we went for a separate layer approach on our project and it kind of proved to be a pain in the ass :) | 17:38 |
| milloni | i hear zeus has support for building multiple machines at the same time. not sure how that works but it makes it even simpler | 17:38 |
| milloni | potentially you can build both with one command (?) | 17:39 |
| marble_visions | zeus? | 17:39 |
| milloni | the latest version of yocto | 17:39 |
| marble_visions | ooh | 17:39 |
| marble_visions | nice | 17:39 |
| marble_visions | milloni: thanks for the info, it puts things into perspective | 17:40 |
| marble_visions | i'll bet on two mach confs | 17:40 |
| marble_visions | see where that takes me | 17:40 |
| milloni | im happy to help, unfortunately i've not been able to test that out myself | 17:40 |
| milloni | so i dont know how good it's going to be in practice | 17:41 |
| milloni | i'd be interested to hear how it works out for oyu | 17:41 |
| marble_visions | indeed, i might share in due time | 17:41 |
| *** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto | 17:44 | |
| *** kanavin__ <kanavin__!~kanavin@141.113.66.202> has quit IRC | 17:44 | |
| *** abhiarora44 <abhiarora44!uid396576@gateway/web/irccloud.com/x-kajgomwkjlautkws> has quit IRC | 17:45 | |
| *** kanavin <kanavin!~kanavin@141.113.66.202> has joined #yocto | 17:46 | |
| *** BobPungartnik <BobPungartnik!~BobPungar@187.113.157.89> has joined #yocto | 17:46 | |
| *** BobPungartnik <BobPungartnik!~BobPungar@187.113.157.89> has quit IRC | 17:48 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 17:53 | |
| *** jklare <jklare!~jklare@157.97.76.18> has quit IRC | 17:58 | |
| *** pohly <pohly!~pohly@p54BD54FC.dip0.t-ipconnect.de> has quit IRC | 18:00 | |
| *** mckoan is now known as mckoan|away | 18:00 | |
| *** jklare <jklare!~jklare@157.97.76.18> has joined #yocto | 18:02 | |
| *** frsc <frsc!~frsc@mue-88-130-71-136.dsl.tropolys.de> has quit IRC | 18:06 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 18:13 | |
| *** ericch <ericch!~ericch@50-205-235-218-static.hfc.comcastbusiness.net> has quit IRC | 18:21 | |
| *** ericch <ericch!~ericch@50-205-235-218-static.hfc.comcastbusiness.net> has joined #yocto | 18:21 | |
| *** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto | 18:23 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC | 18:25 | |
| *** H-U <H-U!2518b581@b2b-37-24-181-129.unitymedia.biz> has joined #yocto | 18:27 | |
| *** H-U <H-U!2518b581@b2b-37-24-181-129.unitymedia.biz> has quit IRC | 18:32 | |
| *** pohly <pohly!~pohly@p54BD54FC.dip0.t-ipconnect.de> has joined #yocto | 18:34 | |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC | 18:35 | |
| *** yann <yann!~yann@91-170-159-152.subs.proxad.net> has joined #yocto | 18:36 | |
| *** H-U <H-U!2518b581@b2b-37-24-181-129.unitymedia.biz> has joined #yocto | 18:38 | |
| *** pohly <pohly!~pohly@p54BD54FC.dip0.t-ipconnect.de> has quit IRC | 18:39 | |
| *** H-U is now known as hu | 18:39 | |
| *** hu is now known as h-u | 18:39 | |
| *** h-u <h-u!2518b581@b2b-37-24-181-129.unitymedia.biz> has left #yocto | 18:44 | |
| *** h-u <h-u!2518b581@b2b-37-24-181-129.unitymedia.biz> has joined #yocto | 18:44 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 19:21 | |
| RP | Looks like we've destroyed the performance of world builds with hashequiv :( | 19:23 |
| RP | https://autobuilder.yoctoproject.org/typhoon/#/builders/52/builds/1327 - 7 hours and task 1806 of 23848 | 19:23 |
| *** fray <fray!~fray@kernel.crashing.org> has quit IRC | 19:28 | |
| *** orzen <orzen!~orz@84-216-100-149.customers.ownit.se> has quit IRC | 19:30 | |
| JPEW | huh, thats not really the desired effect | 19:31 |
| JPEW | Lots of "checkins sstate mirror object availibilty..." | 19:32 |
| *** orzen <orzen!~orz@84-216-100-149.customers.ownit.se> has joined #yocto | 19:35 | |
| *** Ad0 <Ad0!~Ad0@93.124.245.194> has quit IRC | 19:39 | |
| *** Ad0 <Ad0!~Ad0@93.124.245.194> has joined #yocto | 19:45 | |
| *** tgamblin <tgamblin!~tgamblin@128.224.252.2> has quit IRC | 19:58 | |
| *** jklare <jklare!~jklare@157.97.76.18> has quit IRC | 19:59 | |
| *** jklare <jklare!~jklare@157.97.76.18> has joined #yocto | 20:02 | |
| *** Lihis <Lihis!~Lihis@ns3006753.ip-151-80-42.eu> has quit IRC | 20:03 | |
| *** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-uuuxklvxbkxpsldb> has quit IRC | 20:03 | |
| *** Lihis <Lihis!~Lihis@ns3006753.ip-151-80-42.eu> has joined #yocto | 20:04 | |
| *** nerdboy <nerdboy!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 20:05 | |
| RP | JPEW: I need to reproduce this under profiling, see where the bottleneck is. Has to be something silly like the log messages | 20:26 |
| *** fray <fray!~fray@kernel.crashing.org> has joined #yocto | 20:43 | |
| *** goliath <goliath!~goliath@212-186-42-13.cable.dynamic.surfer.at> has quit IRC | 20:45 | |
| *** tgamblin <tgamblin!~tgamblin@CPE64777de11593-CM64777de11590.cpe.net.cable.rogers.com> has joined #yocto | 20:46 | |
| *** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto | 20:49 | |
| *** jklare <jklare!~jklare@157.97.76.18> has quit IRC | 20:57 | |
| *** jklare <jklare!~jklare@157.97.76.18> has joined #yocto | 21:01 | |
| *** Pharaoh_Atem <Pharaoh_Atem!~neal@fedora/ngompa> has quit IRC | 21:06 | |
| rburton | RP: dare i say, turn off hash equiv for m1? | 21:07 |
| RP | rburton: I'm starting to think we may have to :( | 21:09 |
| *** Pharaoh_Atem <Pharaoh_Atem!~neal@fedora/ngompa> has joined #yocto | 21:09 | |
| RP | Running setscene task 287565 of 11921 | 21:12 |
| JPEW | Hah! That's impressive | 21:13 |
| RP | JPEW: for 23000 tasks in total, very | 21:13 |
| kergoth | Oof | 21:14 |
| RP | I think its an accounting error rather than the real number of tasks it ran FWIW | 21:16 |
| RP | but still looks insane | 21:16 |
| fray | Hmm.. 23000 tasks doesn't seem all that large.. but ya, 287k of 23k is a problem.. ;) | 21:16 |
| RP | NOTE: Running setscene task 222166 of 11921 | 21:16 |
| RP | NOTE: Running setscene task 222246 of 11921 | 21:16 |
| RP | NOTE: Running setscene task 223302 of 11921 | 21:16 |
| RP | that is it incrementing | 21:17 |
| fray | lol | 21:17 |
| RP | JPEW: I think its the sstate rescans which are slow | 21:17 |
| JPEW | RP: Ya, that's what I was thinking. | 21:17 |
| RP | halstead: this comes back to the NAS not responding very quickly :( | 21:18 |
| JPEW | Why are there so many each time? | 21:18 |
| RP | JPEW: I'd guess a world build has lots of endpoints which means lots of rehashes | 21:18 |
| *** berton <berton!~berton@189.103.49.163> has quit IRC | 21:19 | |
| JPEW | RP: I'm not too familar with the "checking for object availablilty"; is it just looking for a single file for each message (e.g. just a LOOKUP) | 21:19 |
| RP | JPEW: in this case probably | 21:20 |
| RP | JPEW: that message comes from the hashvalidate function in sstate.bbclass | 21:20 |
| halstead | RP, I think fixing this will require something other than optimizing the NAS. We could remove more objects or change the directory structure. | 21:20 |
| RP | JPEW: its from the update_scenequeue_data([tid] call in runqueue | 21:21 |
| RP | halstead: right, we talked about changing the directory structure | 21:21 |
| RP | halstead: I think ext4 as a filesystem may be faster for this btw but I know that isn't feasible | 21:22 |
| halstead | RP, or I suppose we could have a dedicated mount point for sstate with caching enabled. Caching lead to races in the past so it's disabled. | 21:22 |
| RP | halstead: wish I could remember the details of the race issue. I wonder if we fixed that somehow] | 21:23 |
| JPEW | RP: Hmm, we could batch them all together in a single call to update_scenequeue_data. That would allow them to at least happen in parallel | 21:23 |
| RP | halstead: is it easy to turn on the caching to test? | 21:23 |
| RP | JPEW: yes, we should do that | 21:23 |
| * JPEW writes a patch | 21:24 | |
| * RP clearly isn't thinking straight as that wasn't clear to me :/ | 21:24 | |
| halstead | RP, I don't know the details but there were multiple workers trying to write to the same file because it didn't exist in the cached dir list. | 21:24 |
| RP | halstead: easy to turn on? | 21:25 |
| fray | that has been reported by other users as well.. I'm wondering if there needs to be some kind of a lock file for things | 21:26 |
| RP | fray: you need to be specific about what exactly | 21:26 |
| RP | fray: I remember what michael is talking about in this case and I know we changed the code | 21:27 |
| RP | I wonder if we change the sstate write code to do a mv -n, how nfs copes with that. Is the -n a syscall/nfs preserved operation (no-clobber) | 21:28 |
| fray | sstate-cache directory | 21:28 |
| mischief | is there an easy way to debug why 'apt-get install ...' fails with 'unmet dependencies' in my do_rootfs task for my image? | 21:28 |
| fray | I've been told more then once at the ELC / ELC-E in the last 3 years that people are seeing multiple writes when the original didn't exist.. often nearly at the same time | 21:28 |
| fray | (lesser I've also been told that about the dwonloads directory.. but that was before we fixed a bunch of lock files prior to Zeus) | 21:29 |
| halstead | RP, requires remounting nfs. Simple to do between builds. | 21:29 |
| RP | halstead: server or client side? | 21:30 |
| *** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC | 21:30 | |
| RP | halstead: client I'd assume? | 21:30 |
| halstead | RP client, yep | 21:30 |
| RP | halstead: could we remount mid build, see if it speeds up? | 21:31 |
| RP | risk taking is a skill at times, right? :) | 21:31 |
| RP | looks like we'd want the RENAME_NOREPLACE flag of renameat2 | 21:32 |
| halstead | RP, We can try. Shall I go for it? | 21:33 |
| RP | halstead: yes, which machine/build are you going to change? | 21:35 |
| RP | halstead: just so I can watch the log output | 21:35 |
| RP | halstead: looks like the world builds are on centos7-ty-1 and debian8-ty-1 | 21:36 |
| halstead | RP, I was going to push to all of them. Starting with just on is a better idea. :) | 21:36 |
| RP | halstead: yes, lets just try one | 21:37 |
| *** hpsy <hpsy!~hpsy@195.67.91.135> has joined #yocto | 21:37 | |
| halstead | RP, I'll change debian8-ty-1 | 21:37 |
| RP | halstead: ok | 21:38 |
| *** vmeson <vmeson!~rmacleod@128.224.252.2> has quit IRC | 21:39 | |
| RP | Looking at the processes on the autobuilder I'm doubting this is NFS bound, its burning 95% cpu in cooker | 21:43 |
| RP | halstead: hmm, I think that has dropped cpu usage | 21:46 |
| zeddii | has anyone else tried to build a static libcrypt ? | 21:47 |
| zeddii | I'm trying and failing at the moment. | 21:47 |
| halstead | RP, I've lazy unmounted /srv/autobuilder and mounted with the new options at the same location. Testing to see if it's working as expected. | 21:48 |
| RP | halstead: thanks, I think it may be helping, we'll see... | 21:49 |
| RP | zeddii: we disable static libraries so I assume you're disabling that? | 21:49 |
| *** alessioigor <alessioigor!8c69cfe3@out-207-227.elettra.trieste.it> has quit IRC | 21:50 | |
| RP | JPEW: I think its spending so much CPU in the rehashing code, the rest of runqueue is simply sitting waiting :( | 21:51 |
| RP | nfs is part of it but only a small part :( | 21:51 |
| zeddii | rp: hmm. that might be it, I've never had to worry about this before. so I've never looked. I'll see if I can find the right toggle. | 21:51 |
| zeddii | I'm just trying to build a static busybox and it is chaining to needing a static libcrypt .. | 21:52 |
| zeddii | I'll go check the initramfs layers to see if they have something for this already. | 21:52 |
| RP | zeddii: meta/conf/distro/include/no-static-libs.in | 21:53 |
| RP | +c | 21:53 |
| zeddii | ahah. will go poke around. | 21:53 |
| RP | zeddii: enabling those wastes so much more build time ;-) | 21:55 |
| *** adelcast <adelcast!~adelcast@130.164.62.221> has left #yocto | 21:55 | |
| JPEW | RP: Also possible | 21:55 |
| zeddii | yah. and I just want it for this one package + its depenendencies .. so I'll see if I can figure out another way | 21:55 |
| RP | zeddii: we used to special case sqlite-native for pseudo-native | 21:56 |
| zeddii | I can see about forcing it on for the libxcrypt build in my distro. | 21:56 |
| *** jklare <jklare!~jklare@157.97.76.18> has quit IRC | 21:58 | |
| *** adelcast <adelcast!~adelcast@130.164.62.221> has joined #yocto | 21:58 | |
| RP | JPEW: I think I can see how we could unroll the loops at the top of process_possible_migrations() too, at least to have one big recursive rehash rather than multiple | 21:59 |
| *** jklare <jklare!~jklare@157.97.76.18> has joined #yocto | 22:01 | |
| halstead | RP, Caching is now in effect. | 22:03 |
| JPEW | RP: Ah, ya! thats probably causing the server to switch in and out of the fast streaming mode | 22:04 |
| JPEW | If we can make all the get_unihash() calls occur sequentianlly without intermixing report_unihash_equiv() that would be good | 22:04 |
| RP | JPEW: We're not seeing any _equiv() reports I see in the logs so that isn't the issue | 22:05 |
| JPEW | RP: I saw a few in the log I was looking at | 22:06 |
| halstead | RP, I have the sstate cache clean disabled. Do we need a way to inform the hashserv about deleted objects before enabling it? | 22:06 |
| JPEW | Maybe not otfen enough to be the culprit though | 22:06 |
| RP | halstead: I think we've worked around it | 22:06 |
| RP | JPEW: pretty sure its runqueue's code given the pattern | 22:06 |
| RP | JPEW: lines 2264-2309 | 22:07 |
| halstead | RP, Nice. So it's fine to turn back on now? I'll also start saving logs to deleted object names. | 22:07 |
| RP | halstead: yes, thanks | 22:07 |
| *** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has quit IRC | 22:08 | |
| RP | JPEW: I think we can take 2275-2309 out of the top for loop | 22:08 |
| RP | but I doubt its the only problem | 22:08 |
| RP | JPEW: The local reproducer is to do a big build, then make a change to sstate.bbclass which doesn't change output but does force a complete rebuild where the output will always match | 22:09 |
| * RP suspects an O2 or worse slowdown | 22:09 | |
| JPEW | Ok, I'll give that a try. I think I have the batching of the sstate object check sorted out | 22:10 |
| RP | JPEW: I'm talking out loud btw, not saying you need to do this! :) | 22:11 |
| RP | I think I need to reproduce under bitbake -P and check where the time in the loop is spent | 22:11 |
| JPEW | RP: Ya, that's fine :) I figured moving the update out looked easy enough. I wasn't going to look at the rest yet | 22:12 |
| RP | could be as simple as commenting the logger.debug() | 22:12 |
| RP | we've had this before | 22:12 |
| RP | JPEW: fixing the mirror check would help a lot as it clearly crazy atm :) | 22:13 |
| *** hpsy <hpsy!~hpsy@195.67.91.135> has quit IRC | 22:15 | |
| *** hpsy <hpsy!~hpsy@217.66.60.5> has joined #yocto | 22:15 | |
| JPEW | RP: Patch sent if you want to take a look. I have to go to a Christmas program now | 22:18 |
| *** dv_ <dv_!~dv@62.178.50.190> has joined #yocto | 22:21 | |
| RP | JPEW: thanks! | 22:26 |
| RP | JPEW: its the get_taskhash and get_unihash calls | 22:32 |
| RP | JPEW: I managed to get a profile | 22:32 |
| *** fray <fray!~fray@kernel.crashing.org> has quit IRC | 22:39 | |
| *** fray <fray!~fray@kernel.crashing.org> has joined #yocto | 22:42 | |
| RP | JPEW: you won't believe what the problem is :/ | 22:56 |
| *** jklare <jklare!~jklare@157.97.76.18> has quit IRC | 22:59 | |
| *** jklare <jklare!~jklare@157.97.76.18> has joined #yocto | 23:03 | |
| *** vineela <vineela!~vtummala@134.134.139.76> has quit IRC | 23:11 | |
| rburton | RP: g'wan tell | 23:14 |
| *** rburton_ <rburton_!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto | 23:17 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC | 23:19 | |
| *** hpsy <hpsy!~hpsy@217.66.60.5> has quit IRC | 23:34 | |
| *** mrc3 <mrc3!~mrc3@linaro/mrc3> has quit IRC | 23:39 | |
| *** hpsy <hpsy!~hpsy@195.67.91.135> has joined #yocto | 23:41 | |
| *** bluca <bluca!~bluca@88.98.246.218> has quit IRC | 23:42 | |
| *** hpsy <hpsy!~hpsy@195.67.91.135> has quit IRC | 23:46 | |
| RP | rburton_: well, it turned out to be complicated | 23:58 |
| *** rburton_ <rburton_!~rburton@35.106.2.81.in-addr.arpa> has quit IRC | 23:58 | |
| RP | heh, he ran away :) | 23:59 |
Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!
