**** BEGIN LOGGING AT Thu Oct 24 02:59:57 2019 Oct 24 05:49:00 sven^: thank, will look into it Oct 24 06:49:48 New news from stackoverflow: Auditd in Yocto Oct 24 07:19:53 New news from stackoverflow: U-boot environment is not the same as Linux "fw_printenv" Oct 24 08:50:06 New news from stackoverflow: Holding splash screen until X Server is ready using dbus Oct 24 09:49:48 hi all, I'm extremely puzzled by https://git.yoctoproject.org/cgit.cgi/poky/commit/?id=c2f72f6cb7646757bf0dc7e16b4e0715025b7df2 Oct 24 09:51:15 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. Oct 24 09:51:52 when we build machineA and then machineB, linux-libc-headers gets recompiled Oct 24 09:52:29 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) Oct 24 09:53:31 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 Oct 24 09:53:54 for me, with my very limited understanding of this, this has its place in module.bbclass, not kernel-arch.bbclass Oct 24 09:54:43 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 Oct 24 09:59:42 Does anyone know if the original commiter "He Zhe" from WindRiver is on IRC? Oct 24 10:00:00 I see rburton isn't here anymore so can't bother him with this :) Oct 24 10:02:00 qschulz: this does sound very much like a bug Oct 24 10:05:21 qschulz: what puzzles me is that we have tests for this kind of contamination Oct 24 10:06:20 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 Oct 24 10:06:26 I do not exclude that we've done something wrong in our custom layers though Oct 24 10:06:44 qschulz: have you tried diffsigs? Oct 24 10:07:46 (if you don't know what I mean that is fine, I can explain) Oct 24 10:08:03 RP: afk for 30min, I'll pick up then with whatever you wrote Oct 24 10:08:49 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) Oct 24 10:23:30 RP, regarding adding polkit to oe-core (for sysprof and systemd), polkit hard-depends on mozjs, the mozilla javascript engine :( Oct 24 10:23:44 RP, so I am leaning towards actually shifting sysprof to meta-oe Oct 24 10:27:21 kanavin: hmm, I think we used to have that in core, probably due to this Oct 24 10:27:44 kanavin: I do worry we should really have polkit there for systemd :/ Oct 24 10:29:32 kanavin: RP: if polkit and mozjs get sucked into the systemd defaults, i can already hear screaming and cursing Oct 24 10:29:42 RP, I'm not able to find any mentions of mozjs in oe-core Oct 24 10:32:26 (in oe-core git log) Oct 24 10:32:58 let's wait and see what rburton says Oct 24 10:36:19 kanavin: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=7056054f61b354adcafb8957fe166fda88ca58c0 is what I was thinking of Oct 24 10:37:13 LetoThe2nd: it would be optional Oct 24 10:38:29 RP: whoa i just had a heartattack. i misread "it would be optimal2 Oct 24 10:38:37 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 Oct 24 10:38:51 python 2.x bits Oct 24 10:47:36 kanavin: we really don't want py2... Oct 24 10:50:36 hi Oct 24 10:51:06 RP: right, so bringing mozjs into core is not a trivial task Oct 24 10:51:41 are `python __anonymous` in `.bb` or `.bbappend` simply anonymously injected, or are they addressable/overwritable in a `.bbappend`? Oct 24 11:02:29 kanavin: no, doesn't look like it. Nothing ever seems simple :/ Oct 24 11:02:39 T_UNIX: the former unfortunately Oct 24 11:12:37 RP: I knew about bitbake-dumpsigs diffsigs but I thought you had something very specific in mind Oct 24 11:13:41 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 Oct 24 11:13:48 so I'd say we're fucking up something Oct 24 11:14:04 (by we, I mean where I work, not YP :) ) Oct 24 11:14:18 do you have any pointers on how to debug this? Oct 24 11:15:12 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 :) ) Oct 24 11:15:21 so the debugging might take some time :) Oct 24 11:15:32 qschulz: diffsigs is exactly how to debug Oct 24 11:15:56 qschulz: it should tell you what is changing Oct 24 11:17:19 RP: alright, now the waiting game :) Thx for the help, will let you know if I find something interesting or need help Oct 24 11:17:35 sorry for the scare, looks like we messed up and nothing to do with YP :) Oct 24 11:19:00 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" Oct 24 11:19:23 what is this filtering mechanism and where is it used, what for, etc. :) Oct 24 11:20:55 qschulz: note you don't need to wait for the build. Just "bitbake linux-libc-headers" for each machine Oct 24 11:21:32 qschulz: you could even just do "bitbake linux-libc-headers -S none" and skip building entirely (will generate the sig files) Oct 24 11:22:20 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 Oct 24 11:22:34 some paths anyway Oct 24 11:22:43 RP: this does not reproduce the full build (bitbake linux-libc-headers) Oct 24 11:22:52 sorry, this does not reproduce the bug Oct 24 11:23:04 qschulz: but it rebuilds linux-libc-headers? Oct 24 11:23:50 It does not seem so, it's taken from the sstate-cache directly and I don't see anything new in stamps Oct 24 11:24:55 qschulz: so what you told me earlier about rebuilding it isn't quite right :/ Oct 24 11:25:09 qschulz: you need to find out what does actually rebuild, then use diffsigs there Oct 24 11:29:39 RP: sorry, I'm getting all confused. Starting from zero: Oct 24 11:30:49 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* Oct 24 11:30:57 Hash for dependent task linux-libc-headers/linux-libc-headers_4.18.bb.do_compile changed from 5ad454ec2f7f2cd3059917a80291509f to c554e27feec0caba02f1f8e9d205480b Oct 24 11:33:01 but wtf because in linux-libc-headers.inc => do_compile[noexec] = "1" Oct 24 11:34:03 damn... do_compile has set_icecc_env in it Oct 24 11:34:20 even if it's not executed I guess the task hash still matters atm Oct 24 11:36:09 RP: https://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/icecc.bbclass#n379 this line I think is the only change Oct 24 11:42:33 RP: thanks! Oct 24 12:19:51 is there an irc channel for automotive grade linux? Oct 24 12:20:41 milloni: #automotive Oct 24 12:21:00 thanks! - is that for automotive in general, not agl specifically? Oct 24 12:21:31 RP: https://git.yoctoproject.org/cgit.cgi/poky/commit/?id=8856289fb615698b9c5bf68431cceee1ef80a1bf guess that's the one Oct 24 12:21:47 milloni: topic is automotive foss, but it's 99% agl talk Oct 24 12:23:19 ok Oct 24 12:24:50 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 Oct 24 12:24:55 i will close my issue report in the evening Oct 24 12:29:22 RP: btw, have you seen http://sprunge.us/sT5062 ? Oct 24 12:29:49 RP: reporter didn't want to create a loging for bugzilla nor register to the ML. Oct 24 12:32:58 litb: cool Oct 24 12:34:57 qschulz: you mean you're missing this change in our build, right? Oct 24 12:35:44 JaMa: I mean that's the one commit which is missing in thud I think. I'm testing right now :) Oct 24 12:36:24 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 Oct 24 12:36:42 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 Oct 24 12:39:08 JaMa: I'm surprised it made it to warrior as a backport but not thud, that's all Oct 24 12:39:29 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 Oct 24 12:39:31 (considering thud was still maintained at that time) Oct 24 12:40:02 -> /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' Oct 24 12:40:35 qschulz: backport request sent now Oct 24 12:41:58 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) Oct 24 12:43:04 JaMa: Cool, thx. Oct 24 12:43:07 no worries :) Oct 24 12:43:21 Happy that's it's fixable (and fixed already upstreamed :) ) Oct 24 12:43:55 it's useful to run sstate-diff-machines.sh script as part of your CI to catch these issues early Oct 24 12:44:19 with many layers it's a bit problematic, because many layers still have even parsing issues with this and then the script cannot work Oct 24 12:44:56 e.g. http://jenkins.nas-admin.org/job/oe_world_workspace-compare-signatures/808/console isn't really useful now Oct 24 12:45:06 https://github.com/advancedtelematic/meta-updater/issues/603 Oct 24 12:45:07 tlwoerner: just tried, got same issue Oct 24 12:45:28 meta-virtualization adds even more issues I haven't reported yet Oct 24 12:47:07 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) Oct 24 12:47:17 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) Oct 24 12:47:20 syslinux was skipped: incompatible with host arm-webos-linux-gnueabi (not in COMPATIBLE_HOST) Oct 24 12:47:23 etc Oct 24 12:59:58 qschulz: I had to step away but looks like you found the source of the problem Oct 24 13:00:18 LetoThe2nd: strangely enough no, I have not seen that Oct 24 13:01:02 RP: any objects? can you take it, or want me to formally report/mail it? Oct 24 13:01:20 LetoThe2nd: question is about attribution I guess Oct 24 13:02:25 RP: np, I don't expect anyone to answer under a given time (or even at all). Oct 24 13:03:31 tgamblin: okay, thanks for checking! i'll report it in the mailing list Oct 24 13:03:35 RP: well its a rather trivial one, so i guess its fine if somebody just pushes it as "hum i noticed" Oct 24 13:03:56 LetoThe2nd: mailed it out with a guess at what its for Oct 24 13:05:32 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? Oct 24 13:06:06 RP: thanks. Oct 24 13:06:31 VoidNick: try pouring your question into a form that can be answered, then yes :) Oct 24 13:06:53 Ok, i'll try: Oct 24 13:09:35 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' Oct 24 13:09:52 Host is Ubuntu 18.04 Oct 24 13:09:57 VoidNick: w.0 is massively outdated Oct 24 13:10:07 2.0, i mean Oct 24 13:11:13 ok, so I have to do something different? Oct 24 13:12:06 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 Oct 24 13:12:49 VoidNick: can you retry following this? https://www.yoctoproject.org/docs/current/brief-yoctoprojectqs/brief-yoctoprojectqs.html Oct 24 13:13:03 RP: just cc’d you on my qemumips64 boot issues with v5.4-rcX Oct 24 13:13:23 that’s the earliest I’ve ever gotten around to finding an issue .. normally we find them when there’s no time left :D Oct 24 13:14:53 RP: No luck reproducing the Fedora perl non-reproducible error. Has anyone seen it on the AB since? Oct 24 13:15:26 LetoThe2nd: ok, I try Oct 24 13:20:29 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 Oct 24 13:20:59 New news from stackoverflow: How to add changed dts-file in kernel in Yocto? Oct 24 13:28:48 building mesa on zeus, I get a meson failure saying: meson.build:140:0: ERROR: Unknown variable "_drivers" Oct 24 13:28:49 JPEW: happens most builds :/ Oct 24 13:29:08 JPEW: https://autobuilder.yoctoproject.org/typhoon/#/builders/86 Oct 24 13:29:43 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 ? Oct 24 13:29:46 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 Oct 24 13:30:15 I'll keep trying Oct 24 13:30:43 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. Oct 24 13:31:34 JPEW: we could get you ssh onto that worker if that would help? Oct 24 13:31:55 zeddii: hmm, forwarded that to someone who might have contacts Oct 24 13:32:12 Ya, If I can pull the offending packages, I can run diffoscope on them Oct 24 13:32:33 JPEW: halstead can probably get you access Oct 24 13:33:25 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 Oct 24 13:33:46 Any ideas how to solve it? Been looking around the web but no luck as of yet Oct 24 13:34:09 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. Oct 24 13:37:22 JPEW: the host dependency issues with this worry/scare me Oct 24 13:37:57 JPEW: if you can hack the build to stash the different packages into /tmp/somewhere, I can run that on the AB btw Oct 24 13:38:01 RP: It might not be that FWIW. Perl does almost nothing correctly to be reproducible :) Oct 24 13:38:18 Also same thing happens with recipes-devtools/clang/compiler-rt_git.bb Oct 24 13:38:18 wertigon: as clang is not in poky nor meta-openembedded, things might be a bit difficult. Oct 24 13:38:40 I would not be suprised if there is a "bad" perl build in sstate that only the fedora builder pulls Oct 24 13:38:41 wertigon: maybe khem can chime in, but i guess your best chance is the mailing list. Oct 24 13:39:02 wertigon, maybe something todo with https://git.openembedded.org/openembedded-core/commit/?id=b0efd8d4d0dbc30e6505b42f5603f18fa764d732 ? Oct 24 13:39:17 Yeah, I've inherited a Poky distribution at work and my usual goto reference is on vacation :/ Oct 24 13:40:01 wertigon: well then, sounds like you're about to have fun. Oct 24 13:47:17 Bummer, I'll test that patch kroon sent and we'll see from there Oct 24 13:47:44 I did see SDK was defined as ${SDK}-${OS} in one place Oct 24 13:47:59 wertigon, you can just check your SDK_VENDOR Oct 24 13:48:42 wertigon, bitbake -e test-image | grep ^SDK_VENDOR= Oct 24 13:49:32 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 Oct 24 13:53:33 SDK image is "-test" Oct 24 13:53:48 Or sorry, SDK_VENDOR I mean Oct 24 13:54:01 And the name of my image is test-dev-image Oct 24 13:57:45 Hi Yocto community! Oct 24 13:58:55 hi Hellgineer Oct 24 13:59:07 * LetoThe2nd can't greet, is scared. Oct 24 13:59:21 * jofr hides behind LetoThe2nd Oct 24 13:59:49 * LetoThe2nd quickly turns round and pushes jofr forwards. Oct 24 13:59:54 * jofr whisper "Who is that cheerful person and what does he want with us??" Oct 24 14:00:28 * jofr collapses into a fetal-position. Oct 24 14:00:46 * Hellgineer wonders if the greeting was a good way to start this conversation Oct 24 14:00:58 Hellgineer: that can be answered with a clear "no" Oct 24 14:01:15 Hellgineer: just put a beer on the table and wait for LetoThe2nd to come out of his hideout Oct 24 14:01:18 :-) Oct 24 14:01:45 Software people can't do "conversation". We're embedded software people. We're WORSE! :p Oct 24 14:02:06 mh... did i hear "beer"? Oct 24 14:02:12 * Hellgineer puts a local IPA on the table and steps back Oct 24 14:02:27 Nooooo! It's a traaaaap! Oct 24 14:02:38 Damn it! Oct 24 14:02:58 * LetoThe2nd looks at bottle,reads, puts bottle back and shrugs "nah i dn't drink IPAs." Oct 24 14:03:00 I don't think LetoThe2nd even cares if it's a trap or not.. ;) Oct 24 14:03:09 Ohh, fine. Oct 24 14:03:53 I heard embedded software people might have knack for structuring Yocto layers (the good way (tm)) Oct 24 14:05:59 that sounds very much like a trick question! Oct 24 14:07:25 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? Oct 24 14:07:55 Would it be a sin to have a machine + distro + images in the same meta-* ? Oct 24 14:08:52 Not a sin, no... But it makes more sense to divide it in the way listed Oct 24 14:09:48 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) Oct 24 14:10:17 Hellgineer: it depends (TM) Oct 24 14:10:29 * Hellgineer lol Oct 24 14:11:14 And you might want to have different roles (cluster of 3 RPi that acts as a webserver, FTP and git servers, for instance) Oct 24 14:11:23 With the same hardwar Oct 24 14:11:46 Finally you might want to have different profiles for the distro without touching the rest Oct 24 14:12:07 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 Oct 24 14:12:12 e.g. debug / release Oct 24 14:13:18 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 Oct 24 14:13:31 That's why you want to separate hw/sw/distro, but yeah. Oct 24 14:15:57 so, i'd conclude: "if unsure, seperate the three." Oct 24 14:16:25 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 Oct 24 14:16:47 Hellgineer: absolutely. Oct 24 14:19:38 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? Oct 24 14:20:37 Would you checkout everything manually before build, or maybe create a new 'internal' repository with the poky repo + the metas. ? Oct 24 14:20:52 Hellgineer: can you rephrase? i guess you either mangles the sentence or typoed somewhere so i don't really get the question Oct 24 14:20:59 ah. Oct 24 14:21:44 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. Oct 24 14:22:52 git submodules for the win :) Oct 24 14:23:08 https://github.com/balister/sdr-build Oct 24 14:23:16 :-) Oct 24 14:24:18 That's nice! Oct 24 14:24:37 You guys are really helpful, thank you very much! Oct 24 14:25:14 * Hellgineer lefts a big tips on the table, besides the untouched IPA Oct 24 14:26:02 those are git submodule Oct 24 14:26:17 Need to add ${bindir} to SYSROOT_DIRS for cmake projects, because cmake expects dll files which are installed to bin/ to be present Oct 24 14:26:45 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 Oct 24 14:27:41 I use git-submodules of git-submodules! Oct 24 14:31:36 JPEW, Let me know if I can help with access. Oct 24 14:51:07 have got still the same error: undefined reference to __dso_handle Oct 24 14:52:34 VoidNick: so in that case, what is special about your host? :) Oct 24 15:05:37 ok it seems that the host pc still lacks some packages. Oct 24 15:07:00 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()!) Oct 24 15:10:46 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? Oct 24 15:35:21 halstead: Is it possible I could get ssh access to the fedora30 worker to pull some files off? Oct 24 15:36:03 halstead: Or anyway of pulling files would work. Doesn't need to be ssh Oct 24 15:36:23 JPEW, Yes. Let me see if I already have your ssh public key. Oct 24 15:36:34 Should be in meta-mingw Oct 24 15:36:44 and poky-contrib Oct 24 15:39:40 hmm, I suspect when I use multiconfig and both of the config need the same -native recipes, the -native recipes will be built twice :( Oct 24 15:39:43 * armpit hmm Alex's changes look promising for warrior's issue Oct 24 15:39:53 because sstate cache is not used during the multiconfig build Oct 24 15:42:02 litb: sstate should be shared between two multiconfig builds in the same invocation as of 3.0 Oct 24 15:42:33 oh nice Oct 24 15:46:55 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 Oct 24 15:48:17 nice, because when we build our linux firmware + windows/mingw customer programs , both of these will share many -native recipes. Oct 24 15:48:32 litb: Yep Oct 24 15:49:04 although I guess back to back execution would not be very slower Oct 24 15:49:39 after all, there's enough recipes in both such that they saturate the CPU when executed along Oct 24 15:50:19 litb: Ya. I suspect the more useful case there is when you have inter-recipe multiconfig dependencies (i.e. mcdepends) Oct 24 15:50:30 I see Oct 24 15:57:07 JPEW, I've sent an e-mail with connection information. Oct 24 16:15:19 halstead: Thanks Oct 24 16:18:07 hi Oct 24 16:18:37 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 Oct 24 16:25:30 shouldn't it be just build/tmp/deploy/ipk/polatisnic/kernel-3.2.1-r22_polatisnic.ipk Oct 24 16:30:07 lpapp: perhaps a mismatch in the recipe's variables? Oct 24 16:30:36 which variables? Oct 24 16:32:12 mckoan: this is what I have, =============================== Oct 24 16:32:16 https://justpaste.it/57uu2 Oct 24 16:32:19 the kernel recipe Oct 24 16:32:36 anything suspiciously wrong with it? Based on your reply, I assume that is not what you get in your builds, the pattern itself? Oct 24 16:34:50 lpapp: what's the recipe filename? Oct 24 16:35:25 you can see at the top from cat Oct 24 16:35:32 same as with the linux-yocto patterns Oct 24 16:35:58 oops, cat did not make it into the paste, my fault Oct 24 16:36:10 mckoan: linux-polatis_3.2.1.bb Oct 24 16:37:38 the other thing is that, this does not seem to make it into the uname: LINUX_VERSION_EXTENSION ?= "-polatis-${PR}" Oct 24 16:37:51 I would ideally like to resolve both Oct 24 16:38:53 lpapp: it is normal: kernel-image-4.4.26-yocto-standard_4.4.26+git0+3030330b06_ca6a08bd7f-r0_beaglebone.ipk Oct 24 16:39:48 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? Oct 24 16:40:05 lpapp: no clue, sorry Oct 24 16:40:19 hmm, I see, thanks, what about the uname issue? Oct 24 16:40:30 doc says: LINUX_VERSION_EXTENSION: The Linux kernel CONFIG_LOCALVERSION that is compiled into the resulting kernel and visible through the uname command. Oct 24 16:40:40 maybe, daisy did not support it Oct 24 16:41:04 oh, it did Oct 24 16:41:08 so, yeah, no clue really Oct 24 16:41:22 Linux polatisnic 3.2.1-r21 #1 PREEMPT Thu Nov 22 16:32:08 GMT 2018 armv5tejl GNU/Linux Oct 24 16:48:26 my colleague added some code to remove old kernel when we are upgrading the kernel... Oct 24 16:48:30 I think it makes no sense, opinions? Oct 24 16:48:57 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? Oct 24 17:06:09 lpapp: FWIW the version is in the name so that its possible to install two kernels in parallel Oct 24 17:06:31 lpapp: some users need to do that in for example an upgrade scenario to have a fallback Oct 24 17:08:54 JPEW, ah cool, yocto 3.0 was released yesterday! Oct 24 17:10:55 litb: sharing sstate between multiconfigs dyanmically mid build was one of the features :) Oct 24 17:32:25 RP: AB doens't seem to have preserved the non-reproducible perl packages for me to diff, so I'm back to trying locally Oct 24 17:32:43 Unless I'm looking in the wrong location Oct 24 17:33:55 JPEW, but this in the 3.0 mega manual is now incorrect? Oct 24 17:34:02 "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. " Oct 24 17:34:12 Yes, that is wrong Oct 24 17:35:05 JPEW: no, its selftest so it won't have it :( Oct 24 17:35:17 JPEW: could we try what I suggested - give me a patch to copy them to /tmp ? Oct 24 17:35:34 RP: Ok, I'll do that. Oct 24 17:35:59 JPEW: If you want it faster, hack it to disable other selftests :) Oct 24 17:36:23 JPEW: in fact put that in a poky branch on contrib and I can just run that :) Oct 24 17:36:31 RP: Ok Oct 24 18:17:04 RP: http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=jpew/ab-reproducible-test Oct 24 18:38:03 does anyone know why python3 native packages don't compile with icecc even when it is enabled? Oct 24 18:49:11 do we have a tool/script to clear out old taint on tasks? Oct 24 18:49:15 without wiping tmp, that is Oct 24 18:52:04 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 Oct 24 18:52:35 mischief: No. Perhaps it's not invoking the compiler specified in $CC, or it's passing some argument that icecc doesn't like Oct 24 18:53:01 mischief: Or, you have it blacklisted :) Oct 24 18:58:06 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 :-( Oct 24 18:58:36 mischief: I'm not too familiar with it either. Does it print the compile commands? Oct 24 18:58:54 * kergoth tries using meta-external-toolchain with an oe-built sdk Oct 24 19:00:47 seems so Oct 24 19:01:28 would it make sense to add a 'mingw' disto-feature, so that packages can use this to configure their default PACKAGECONFIGs ? Oct 24 19:01:45 another silly question, is there a way to enumerate all kernel module packages including external modules so i can put them in a image? Oct 24 19:02:33 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 Oct 24 19:02:34 'kernel-modules' package depends on all in-tree modules but i need out of tree ones as well Oct 24 19:19:35 mischief: grep for inherit module ? Oct 24 19:19:57 mischief: I don't know if there is a better way Oct 24 19:21:07 JPEW: i would preferrably do it programmatically, since different $MACHINE needs different modules for us. Oct 24 19:22:41 i don't really want to use $MACHINE_ESSENTIAL... since that might contain non-module packages Oct 24 19:24:14 mischief: If you had the list of all modules, what would you filter it on to figure out which ones when to which machines? Oct 24 19:26:05 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 Oct 24 19:50:27 kergoth: an rm tmp/stamps/*/*.taint (or similar) would probably work Oct 24 19:50:42 probably */*/*.taint Oct 24 21:13:12 JPEW: went and succeeded: https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/458 :( Oct 24 21:15:58 "BitBake finds and applies multiple patches for a single recipe in the order in which it locates the patches" hi! what does this mean? Oct 24 21:16:08 does this mean that it's the order in which they appear in SRC_URI? Oct 24 21:17:08 litb: yes Oct 24 21:34:20 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). Oct 24 21:35:08 JPEW: I think its a race depending on what makes it into sstate on the original build when perl is rebuilt :/ Oct 24 21:35:57 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 Oct 24 21:37:27 JPEW: agreed, I'll try and do that Oct 24 21:50:45 * 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 Oct 24 22:58:30 JPEW: A new plan - can you rebase those patches onto a failed master-next build? That might retrigger easier? Oct 24 22:58:55 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 Oct 24 22:59:01 * RP needs to sleep Oct 24 22:59:19 JPEW: I'm thinking if it failed once the broken sstate should be there **** ENDING LOGGING AT Fri Oct 25 03:00:03 2019