**** BEGIN LOGGING AT Mon Feb 03 03:00:39 2020 Feb 03 06:29:51 how to exclude qemu and qemu-native from the image dependencies? Feb 03 07:31:57 OpenCV recipe has the line PACKAGECONFIG[v4l] = "-DWITH_V4L=ON,-DWITH_V4L=OFF,v4l-utils," does it mean if I add v4l-utils to DEPENDS, it will be built with -DWITH_V4L=ON? Feb 03 07:32:37 (because it does not...) Feb 03 07:37:18 stuom1: No it means that if you set PACKAGECONFIG += "v4l" it will add v4l-utils to DEPENDS and build with -DWITH_V4L=ON Feb 03 07:41:50 hmm ok, it is already in PACKAGECONFIG ??= by default, but it is not build with v4l Feb 03 07:45:20 stuom1: So ??= is a lazy default value, so if something else modifies PACKAGECONFIG it will not be used. Could you verify it actually ends up in PACKAGECONFIG using "bitbake -e opencv | grep ^PACKAGECONFIG" ? Feb 03 07:49:13 there is PACKAGECONFIG=" libv4l" but grepping the do_configure lo gives me "libv4l/libv4l2: NO" Feb 03 07:50:06 libv4l is actually the one i want Feb 03 08:09:04 good morning Feb 03 08:12:29 stuom1: No you do not want "libv4l" in PACKAGECONFIG, you want "v4l" in PACKAGECONFIG. Feb 03 08:12:51 mckoan: good morning Feb 03 08:13:11 there is PACKAGECONFIG[libv4l] = "-DWITH_LIBV4L=ON,-DWITH_LIBV4L=OFF,v4l-utils," Feb 03 08:13:30 at least i think i want libv4l instead of v4l Feb 03 08:13:57 oh, there's two? Feb 03 08:14:01 or atleast it still should show YES in config log for libv4l Feb 03 08:14:09 yes Feb 03 08:17:11 Then I don't know what's going on. I would look in log.do_configure to try to see if the -DWITH_LIBV4L=ON option got passed ok, and see why it still didn't get enabled. Feb 03 09:54:21 if ssh asks for new key confirmation bitbake fail to load the repo. How can I prevent it? Feb 03 09:56:50 dv|2: maybe try to clone the repo manually once and make the key confirmation permanent Feb 03 09:57:10 not that clean sollution, but should work i guess Feb 03 09:57:38 creich, I did. But it is annoying to clients who will use my layers Feb 03 09:58:48 ok, in that case it depends on your infrastructure Feb 03 09:59:13 that key confirmation is not related to bitbake. it should be a setting inside your ssh client Feb 03 09:59:34 i don't know if you're using more than one repo server Feb 03 10:00:02 but you should make the key of your repo server(s) available to your ssh clients on the developer machines Feb 03 10:01:44 dv|2: make it part of your setup process so it's added to known_hosts before bitbake is called Feb 03 10:04:15 creich, I shared. I am talking about normal ssh configuration: "... are you shure? - Permanently added '' to the list of known hosts" Feb 03 10:05:20 oh, sorry, did not get your message. Oh, possibly it couldd be a better idea to just add to known_hosts. But if key will be changed? Feb 03 10:05:42 RP: if we're dropping pod2man from hosttools then the pod fix class i wrote can be dropped right? Feb 03 10:05:45 It will also ask then. I'm using several different repo servers Feb 03 10:05:58 dv|2: key shouldn't change. If it does, this is a major security issue or a fuck-up on your part. Both ways need manual verification and process. Feb 03 10:06:21 dv|2: you *want* to be notified the key has changed Feb 03 10:10:27 rburton: probably, yes Feb 03 10:10:37 rburton: I basically concluded we were fighting a losing battle :( Feb 03 10:10:56 rburton: limited people mean we can't afford to do it Feb 03 10:11:32 yeah, fair Feb 03 10:14:03 rburton: perl still isn't reproducible it seems :( Feb 03 10:14:46 goddamnit Feb 03 10:15:01 any idea what's changing now? Feb 03 10:15:16 rburton: have an rsync running to then allow debug Feb 03 10:15:38 rburton: the collection of breakage is at least much cleaner now Feb 03 10:16:28 hm did i post the fix for modules that disappear Feb 03 10:16:54 i got it fixed upstream but now cant recall if i backported it Feb 03 10:17:11 ah i worked around it, good Feb 03 10:19:18 not convinced we should be relying on opkg-utils to pull perl-native into recipes Feb 03 10:20:29 rburton: no, I'm not either Feb 03 10:21:13 rburton: I'm at the stage were I wanted to get fixes in and try and sort the builds though Feb 03 10:21:43 right Feb 03 10:23:02 rburton: it gets the patch queue back to something manageable too (since pod2man and my makeinfo changes conflicted) Feb 03 10:23:30 rburton: I'm probably going to merge Alex's patches from -next Feb 03 10:23:40 rburton: have run clean on the AB now Feb 03 10:23:44 i can have a glance over next in a second Feb 03 10:26:26 rburton: thank Feb 03 10:26:29 thanks Feb 03 10:29:54 also fired a world on the other machine with the goal of chasing all the pod2man missing deps in the background Feb 03 11:16:45 world build on a fast machine sits for a very long time in webkit and piglit Feb 03 11:16:52 (i'm sure that's not a surprise for anyone) Feb 03 11:22:43 New news from stackoverflow: About the wrong URI in tcf-agent_git.bb in Poky Feb 03 11:23:18 rburton: I'm shocked! (not) :) Feb 03 11:41:39 rburton: openssl ptest shows ·​perl_archname·​=>·​"x86_64-​linux-​thread-​multi",​68 ·​·​perl_archname·​=>·​"x86_64-​linux-​gnu-​thread-​multi",​ Feb 03 11:42:12 such fun Feb 03 11:49:11 rburton: the dilemma is to patch or just use perlnative :/ Feb 03 11:54:10 fun fact! Feb 03 11:54:13 pseudo-native calls pod2man Feb 03 11:54:25 rburton: it does? :/ Feb 03 11:54:36 rburton: how does anything work then? :/ Feb 03 11:55:33 hm actuallllly, where is that coming from Feb 03 11:57:01 fun fact! i cant read Feb 03 11:57:07 s/pseudo/quilt/ Feb 03 11:57:24 i can't read too. you don't have to feel alone. Feb 03 11:57:27 rburton: you're starting to worry me Feb 03 11:57:54 so i've a horrible hack that emits a warning when pod2man is ran Feb 03 11:59:14 (quilt checks for presence) Feb 03 12:00:33 RP: alex's patches in next get my seal of approval Feb 03 12:01:19 https://cdn.dribbble.com/users/10768/screenshots/3438065/seal-of-approval_dribbble.png Feb 03 12:03:27 rburton: thanks, will merge those and it at least keeps some patches moving Feb 03 12:03:45 rburton: need to make decisions on the others :/ Feb 03 12:03:53 Ignoring mine Feb 03 12:03:55 so maybe we can speed up piglit builds by not shuffling 2GB of files into the sysroot Feb 03 12:09:52 rburton: nice Feb 03 12:09:59 hmm, host leakage into target perl :/ Feb 03 12:28:28 how can I see why my bitbake freezing parsing recipes? Feb 03 12:29:14 dv|2: I don't know but you can turn the debug on and then you get tons of note messages Feb 03 12:29:28 I think it's -D(D)* Feb 03 12:29:38 dv|2: freezes suggests timing out somewhere Feb 03 12:29:50 Bugs https://bugzilla.yoctoproject.org/show_bug.cgi?id=13770 to 13777 files for reproducibility issues Feb 03 12:29:50 I usually type as many D as I can until I get bored pressing D :) Feb 03 12:29:51 Bug 13770: normal, Undecided, ---, unassigned, NEW , openssl records perl arch in ptest configdata.pm Feb 03 12:30:10 dv|2: (network timeouts, that is) Feb 03 12:30:14 qschulz: Two is usually enough Feb 03 12:30:37 qschulz, I did. It prints out alot of messages and then freezes at about 92% of parsed recipes. Feb 03 12:31:45 then all subprocesses exit and only 1 is running in the background taking 0.3% of cpu. Feb 03 12:33:52 then check what this subprocess is doing? what are the messages printed just before? (tail /proc//fd/2 could help maybe) Feb 03 12:33:56 the process is Cooker. It just polls the descritor and do nothing. all other subprocess are stopped Feb 03 12:33:59 RP: thanks Feb 03 12:35:32 dv|2: can you tell which recipe the Cokker is working on? Feb 03 12:36:37 creich, the last one was alsa-state. it parsed it several times and freezed: https://i.imgur.com/8T33hvX.png Feb 03 12:38:55 rburton: re: your piglit patch. I remember RP saying we should avoid _remove because it slows down the build. Would it make sense to add it to SYSROOT_DIRS_BLACKLIST instead? Feb 03 12:39:08 (by it I mean libdir) Feb 03 12:39:21 qschulz: no, because blacklist is implemented by deleting after the copy Feb 03 12:39:35 if speed is a concern we canjust set SYSROOT_DIRS to "" Feb 03 12:41:02 rburton: indeed. Feb 03 12:41:06 thanks Feb 03 12:41:48 dv|2: did you modify the recipe in any way? Feb 03 12:42:15 do you use poky? and if so, which version/branch? Feb 03 12:44:13 * clementp[m] sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/rFkyDZiXKGwbwNRqFGEhHooQ > Feb 03 12:45:13 The grpc_cpp_plugin is available locally Feb 03 12:45:13 ./iwg27-release-bsp/build_imx8qm/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-grpc/1.14.1-r0/packages-split/nativesdk-grpc-dbg/opt/fsl-imx-wayland/L4.14.98-2.0.0_GA/sysroots/x86_64-pokysdk-linux/usr/bin/grpc_cpp_plugin Feb 03 12:45:13 But not when i install the SDK :( Feb 03 12:45:31 clementp[m]: just write your message in here without having matrix make a snippet Feb 03 12:46:44 clementp[m]: That's outside of my knowledge area but from the path of your file, the plugin makes it to nativesdk-grpc-dbg which isn't the default package right? I can't help further, just a hint Feb 03 12:50:22 qschulz sorry bad copy/paste Feb 03 12:50:24 find -name grpc_cpp_plugin./iwg27-release-bsp/build_imx8qm/tmp/work/x86_64-linux/grpc-native/1.14.1-r0/image/home/outsight/iwg27-build-script/iwg27-release-bsp/build_imx8qm/tmp/work/x86_64-linux/grpc-native/1.14.1-r0/recipe-sysroot-native/usr/bin/grpc_cpp_plugin./iwg27-release-bsp/build_imx8qm/tmp/work/x86_64-linux/grpc-native/1.14.1-r0/sysroot-des Feb 03 12:50:24 tdir/home/outsight/iwg27-build-script/iwg27-release-bsp/build_imx8qm/tmp/work/x86_64-linux/grpc-native/1.14.1-r0/recipe-sysroot-native/usr/bin/grpc_cpp_plugin./iwg27-release-bsp/build_imx8qm/tmp/work/x86_64-linux/grpc-native/1.14.1-r0/build/grpc_cpp_plugin./iwg27-release-bsp/build_imx8qm/tmp/work/imx8qm_iwg27m-poky-linux/core-image-base/1.0-r0/sdk/ Feb 03 12:50:25 image/opt/fsl-imx-wayland/L4.14.98-2.0.0_GA/sysroots/aarch64-poky-linux/usr/bin/grpc_cpp_plugin./iwg27-release-bsp/build_imx8qm/tmp/work/imx8qm_iwg27m-poky-linux/core-image-base/1.0-r0/sdk/image/opt/fsl-imx-wayland/L4.14.98-2.0.0_GA/sysroots/aarch64-poky-linux/usr/bin/.debug/grpc_cpp_plugin./iwg27-release-bsp/build_imx8qm/tmp/work/aarch64-poky-linu Feb 03 12:50:25 x/eslam/1.0-r0/recipe-sysroot-native/usr/bin/grpc_cpp_plugin./iwg27-release-bsp/build_imx8qm/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-grpc/1.14.1-r0/image/opt/fsl-imx-wayland/L4.14.98-2.0.0_GA/sysroots/x86_64-pokysdk-linux/usr/bin/grpc_cpp_plugin./iwg27-release-bsp/build_imx8qm/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-grpc/1.14.1- Feb 03 12:50:26 r0/package/opt/fsl-imx-wayland/L4.14.98-2.0.0_GA/sysroots/x86_64-pokysdk-linux/usr/bin/grpc_cpp_plugin./iwg27-release-bsp/build_imx8qm/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-grpc/1.14.1-r0/package/opt/fsl-imx-wayland/L4.14.98-2.0.0_GA/sysroots/x86_64-pokysdk-linux/usr/bin/.debug/grpc_cpp_plugin./iwg27-release-bsp/build_imx8qm/tmp/work/x8 Feb 03 12:50:26 6_64-nativesdk-pokysdk-linux/nativesdk-grpc/1.14.1-r0/build/grpc_cpp_plugin./iwg27-release-bsp/build_imx8qm/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-grpc/1.14.1-r0/packages-split/nativesdk-grpc-dbg/opt/fsl-imx-wayland/L4.14.98-2.0.0_GA/sysroots/x86_64-pokysdk-linux/usr/bin/.debug/grpc_cpp_plugin./iwg27-release-bsp/build_imx8qm/tmp/work/x86 Feb 03 12:50:27 _64-nativesdk-pokysdk-linux/nativesdk-grpc/1.14.1-r0/packages-split/nativesdk-grpc-dev/opt/fsl-imx-wayland/L4.14.98-2.0.0_GA/sysroots/x86_64-pokysdk-linux/usr/bin/grpc_cpp_plugin./iwg27-release-bsp/build_imx8qm/tmp/work/x86_64-nativesdk-pokysdk-linux/nativesdk-grpc/1.14.1-r0/recipe-sysroot-native/usr/bin/grpc_cpp_plugin./iwg27-release-bsp/build_imx Feb 03 12:50:27 8qm/tmp/sysroots-components/x86_64/grpc-native/usr/bin/grpc_cpp_plugin Feb 03 12:50:52 https://pastebin.com/f3MnZkuh Feb 03 12:52:42 creich, yes, I add simple .bbappend file. but it builds on my host successfully Feb 03 12:53:26 dv|2: and if you remove your bbappend? Feb 03 12:55:34 clementp: I suspect /opt/fsl-imx-wayland/L4.14.98-2.0.0_GA/sysroots/x86_64-pokysdk-linux/usr/bin/grpc_cpp_plugin isn't really a path expected to end in the "normal" nativesdk package. If you build the same thing but for a target image (not a nativesdk), do you still not have grpc_cpp_plugin in your image? Feb 03 12:56:48 clementp: maybe a missing FILES_${PN} += "/opt/fsl-imx-wayland/L4.14.98-2.0.0_GA/sysroots/x86_64-pokysdk-linux/usr/bin/grpc_cpp_plugin" ? but i doubt it, I'm most likely talking garbage now and so I'm going to let room for experienced people to chime in Feb 03 13:04:38 qschulz: thanks for the reply, I'm quite new with Yocto (more familiar with Buildroot), I was hopping I missed an obivious thing in my conf... But maybe there is a bug with the SDK generation and gRPC. Feb 03 13:09:06 this doesn't look correct NOTE: Running setscene task 13536 of 3008 (...) Feb 03 13:09:26 JaMa: more is more. Feb 03 13:09:33 Feb 03 13:10:25 as long as it finishes eventually :) Feb 03 13:14:13 tlwoerner: pidge just said you are fixing u-boot for Marex Feb 03 13:15:23 qschulz, I deleted my bbappend and the result is same Feb 03 13:17:35 anyone know how to drive perf? Feb 03 13:17:55 rm -rf perf Feb 03 13:17:56 i want to trace all exec()s and log when a specific binary is executed Feb 03 13:18:09 rburton, in all seriousness, I serach it up everytime Feb 03 13:18:18 s/serach/search/ Feb 03 13:18:46 i'm sure this is actually fairly simple but i've only ever used perf to get profiling data and not to trace syscals Feb 03 13:19:23 yah. i've done something similar before, but the syntax escapes me every time. Feb 03 13:23:05 New news from stackoverflow: Integrating Python monorepo application into Yocto Feb 03 13:26:12 Crofton|road: of course! i'm enjoying U-Boot quite a bit :-) Feb 03 13:26:40 marex-cloud: is very excited to review your work Feb 03 13:26:59 I might have to muzzle him :) Feb 03 13:27:30 zeddii: https://github.com/leahneukirchen/extrace close enough, i can post-process Feb 03 13:31:10 zeddii: apart from the fact that tracing a bitbake results in pages of process disappeared before notification messages Feb 03 13:31:14 so that's mostly useless Feb 03 13:31:33 what bit of 'trace' wasn't understood Feb 03 13:31:36 i didn't ask for a sample Feb 03 13:32:43 can we bbappend a new config for u-boot? Feb 03 13:34:43 lol Feb 03 13:34:55 meta-bug is possibly hrw? Feb 03 13:35:42 RP: arhg i swore i fixed the libidb2 reprod thing already once Feb 03 13:36:33 rburton: clearly not :( Feb 03 13:36:59 rburton: there are a few of these that are surprising/painful :( Feb 03 13:37:12 does anyone have a sysvinit image booted handy? Feb 03 13:37:20 * RP wonders if /dev/shm is a tmpfs? Feb 03 13:38:22 RP: it usually is, AFAIK Feb 03 13:38:33 rburton, that has often been my experience as well. way to much data from perf. until I find some cryptic way to make it more selective. Feb 03 13:39:09 yah usually is Feb 03 13:39:28 RP: all dev is a devtmpfs on mine Feb 03 13:39:39 /dev Feb 03 13:40:15 qschulz: yes, but on the systems i know a tmpfs is addtionally mounted into /dev/shm Feb 03 13:45:04 Crofton|road: you should use kconfig fragments Feb 03 13:45:09 rburton: the biggest overhead in our builds is fork overhead of processes Feb 03 13:45:32 yeah, thus why autoconf die die die Feb 03 13:56:38 I think autotools may have figured out how to remove itself from the ecosystem :/ Feb 03 14:03:14 * tlwoerner prefers the good ol' days of 10 years ago where everyone only hated autotools rather than the case today where every hacker and their dog thinks they can write a better build system ("i just created the next language fad... and the 2 build systems you need to use it") Feb 03 14:03:23 lol Feb 03 14:07:23 qschulz: in gRPC FILES_${PN}-dev += "${bindir}" Feb 03 14:07:50 does that mean I need to add nativesdk-grpc-dev to toolchain_host ? Feb 03 14:08:03 https://github.com/openembedded/meta-openembedded/blob/zeus/meta-networking/recipes-devtools/grpc/grpc_1.24.1.bb#L51 Feb 03 14:15:03 YEAH ! Feb 03 14:31:55 RP: Why is forking so expensive? Feb 03 14:33:03 paulbarker: have a cookie for your 'trash on fire' comment re NPM in the license compliance presentation you did at ELCE Feb 03 14:33:07 made me lol Feb 03 14:33:18 JPEW: configure is a fork bomb Feb 03 14:33:44 rburton: Ah so not something we have control over Feb 03 14:34:16 JPEW: fun fact: on my machine i can make gettext configure several times faster by explicitly pinning it to a single CPU (as by default it was round-robining across 20 cores at lowest speed, instead of staying on one fast core) Feb 03 14:34:27 i should replicate that and see if the behaviour still happens Feb 03 14:34:29 RP: since my logrotate patch ended up not being the culprit for those failures, do you think it's worth trying the v3 patch again? Feb 03 14:34:40 rburton: Hah, that's fantastic! Feb 03 14:36:22 We should make that behavior a task flag ;) Feb 03 14:36:53 rburton: You should try running configure on Windows... still gives me nightmares Feb 03 14:37:03 oh god yes thats a whole new level of pain Feb 03 14:37:09 fork is significantly more expensive on that platform Feb 03 14:37:21 JPEW: i have a patch for the task flag thing, oddly didn't seem to help. interactions were odd. Feb 03 14:39:21 0: gettext-0.20.1-r0 do_configure - 1m10s (pid 19512) Feb 03 14:39:25 * rburton yans Feb 03 14:39:27 erm, yawns Feb 03 14:40:11 0: gettext-0.20.1-r0 do_configure - 2m0s (pid 19512) Feb 03 14:40:16 * rburton has a nap Feb 03 14:40:38 right ~2 minutes 10 Feb 03 14:40:45 I have the same feeling when bitbake parses all of the recipes.. ;-) Feb 03 14:41:17 fullstop: lots of layers, lots of multiconfig, or both? Feb 03 14:41:29 a fair number of layers Feb 03 14:41:49 JPEW: htop says configure is using 10 cores, all at ~20% usage Feb 03 14:42:09 oddly flipping between what 10 of my 20 it uses Feb 03 14:42:17 1-10 for a bit, then 11-20 Feb 03 14:42:53 rburton: Hmm. So many forks confuses the kernel scheduler perhaps? Feb 03 14:43:58 thats the guess Feb 03 14:44:23 trying taskset -c 0 now Feb 03 14:44:58 so yeah still terrible Feb 03 14:45:08 debian 5.3 kernel Feb 03 14:45:24 outside of bitbake, gettext configure takes 110 seconds Feb 03 14:45:38 with taskset -c0 to pin to cpu 0, 60 seconds Feb 03 14:46:39 rburton: So it takes twice as long and doesn't get faster when pinned if running in bitbake? Feb 03 14:46:56 trying in bitbake again, just rebasing my branch Feb 03 14:47:11 rburton: I did try and replicate that issue again with a modern kernel and couldn't Feb 03 14:47:57 JPEW: basically configure is a fork bomb and pinning it to the same cpu meant hotter caches (I think) Feb 03 14:48:09 RP: if you can try again (my testcase is gettext) and if you can't replicate then we should try to identify if its the scheduler or something Feb 03 14:48:13 * RP suspects spectre/meltdown stuff means the cache effect isn't visivle any more Feb 03 14:48:34 rburton: I was actually talking the tglx about it, then couldn't replicate :/ Feb 03 14:48:51 JPEW: I have patches which did the taskset pinning to cores! Feb 03 14:49:31 Does one need elevated privs to pin tasksets? Feb 03 14:49:33 RP: i definitely just replicated it on my debian 5.3 kernel Feb 03 14:49:34 no Feb 03 14:49:41 fullstop: no Feb 03 14:49:44 rburton: oh, interesting Feb 03 14:50:04 huh, I'll have to look into that. Feb 03 14:50:18 the taskset pinning doesn't help with larger builds Feb 03 14:50:23 it was all very odd Feb 03 14:50:55 rburton: I'll have to try again Feb 03 15:14:16 hmm, perl is using the host gcc for configure tests Feb 03 15:21:05 hmm, it has build and target modes. Something is confused though Feb 03 15:22:38 RP: I think I saw that also Feb 03 15:26:12 RP: Part of the non-reproducibility in perl was it trying to figure out how to generate valid code for the host compiler Feb 03 15:31:29 tgamblin: yes, we should retest your patch. Sorry about the confusion Feb 03 15:31:43 RP: No worries Feb 03 15:34:29 creich, fyi, i came in this morning and asked the guy who put this thing to gether. he gave me an answer i didn't like (basically "just duplicate the whole recipe for the target-specific case"), so i started digging a little harder. long story short, i found "MYCOMPANYNAME_IMAGE_INSTALL_COMMON" where i was able to conditionally add my package, and i got it working! thanks again for your time, and for the Feb 03 15:34:35 tip last night to look for the words "IMAGE_INSTALL" Feb 03 15:35:44 hi guys, i'd like to host a public mirror of yocto tarballs, is there a contact/guidelines/info on space used, needed, etc ? Feb 03 15:35:45 JPEW: the opkg issue is its reordering the files in the ipks Feb 03 15:36:05 JPEW: so a tar difference :/ Feb 03 15:38:29 * RP suspects we have an old host tar causing problems Feb 03 15:39:43 RP: Doesn't have --clamp-time perhaps? Feb 03 15:39:57 Or causing the ordering issues? Feb 03 15:40:01 JPEW: --sort option missing Feb 03 15:40:29 RP: Ah ya Feb 03 15:40:44 RP: getting cross host reproducibility is going to be hard :/ Feb 03 15:41:25 Piraty: thanks for the heads up! fortunately, the bug is on the OpenWRT fork, is not on code that is shared with upstream opkg, =) Feb 03 15:41:46 JPEW: I thought we had new tar on all the affected machines but clearly not :/ Feb 03 15:41:57 * RP ponders how to find it Feb 03 15:42:48 RP: On a related topic: what determines the order anon python fragments are executed? Feb 03 15:43:29 JPEW: they're sorted by their name iirc Feb 03 15:43:47 internally they get a name based on filename and linenumber Feb 03 15:44:34 cmtptr: glad you found a solution :) Feb 03 15:45:07 sorry to hear that there is kind of a messup going on Feb 03 15:45:14 btw Feb 03 15:45:59 instead of copying the whole recipe, you could create a new recipe with the name you by now probably already have und instead of copying everythin just set the first line to: Feb 03 15:46:08 require Feb 03 15:46:27 and then add the missing package to your MYCOMPANYNAME_IMAGE_INSTALL_COMMON Feb 03 15:46:36 should make things a bit cleaner Feb 03 15:48:34 JPEW: all have --sort except debian8 and centos7 which should have buildtools Feb 03 15:48:42 creich, thanks, i'll consider that Feb 03 15:52:10 yw :) Feb 03 15:57:23 JPEW: it also uses tar -T, I wonder if we need to sort that Feb 03 15:57:46 adelcast: looks like we may have some further opkg-build tweaks :/ Feb 03 16:00:12 adelcast: I think https://git.yoctoproject.org/cgit/cgit.cgi/opkg-utils/commit/opkg-build?id=1b577d8d1349b6a30493059ad39ac7336eeabc2f may need an extra "| sort" in it but I can't prove that as yet Feb 03 16:09:26 JPEW: done :-) Feb 03 16:12:56 RP: I guess the tar OE uses doesn't have --sort support? we could just use | sort as you mentioned, to avoid conditioning reproducibility to gnu tar Feb 03 16:22:33 RP: just as bison merges, khem finds somewhere it breaks! Feb 03 16:35:27 anyone seeing "| make[2]: *** No rule to make target 'oldnoconfig'. Stop." with the new 5.4 linux-yocto recipes? Feb 03 16:35:30 zeddii: ^ ? Feb 03 16:36:52 zeddii: it seems to be broken when gold is enabled, because olddefconfig fails with: Feb 03 16:36:55 scripts/kconfig/conf --olddefconfig Kconfig Feb 03 16:36:57 scripts/Kconfig.include:39: gold linker 'x86_64-oe-linux-ld' not supported Feb 03 16:44:58 introduced in 5.4-rc1 https://lore.kernel.org/r/CAMe9rOqMqkQ0LNpm25yE_Yt0FKp05WmHOrwc0aRDb53miFKM+w@mail.gmail.com Feb 03 17:28:27 adelcast: I think its the find command output not being sorted which is the issue Feb 03 17:28:43 adelcast: its unclear if --sort to tar would sort the input from -T Feb 03 17:29:08 adelcast: obviously more investigation needed :/ Feb 03 17:32:39 rburton: typical :( Feb 03 17:35:39 RP, JPEW: pinning configure invocation to a single random cpu on my machine, building gettext from scratch Feb 03 17:35:46 RP, JPEW: https://pastebin.com/z11UZcCB Feb 03 17:36:16 curious if the gpm thing was real or just because of how the build paralled but that's all walltime Feb 03 17:38:30 (ross/cpu is the hack, a better fix would be to let bitbake do it as a task flag) Feb 03 17:39:10 rburton: it is interesting. could be multiple configures pinned to the same cpu too? Feb 03 17:39:26 it randomly selects a CPU so yes, possibly Feb 03 17:40:25 rebuilding just that to see what happens Feb 03 18:18:52 rburton: one of the config is to build in a minimal debian10 container which has minimum set of deps and catches all sort of stuff Feb 03 18:31:35 khem: useful! Feb 03 18:41:40 ok, pushed the meta-gpl2 patches that were outstanding Feb 03 18:41:56 we need a maintainer for meta-gpl2, someone who actually uses it Feb 03 18:59:41 I'm having unexpected difficulty with a layer that was working before a clean.. is there a difference between recipe-sysroot-native/usr/bin/nativepython3 and recipe-sysroot-native/usr/bin/python3-native/python3 ? Feb 03 19:00:35 It's the meta-tensorflow layer which uses bazel to build things, so bitbake -c clean doesn't actually clean up the bazel build artifacts.. so this went unnoticed until I attempted to build everything from scratch. Feb 03 19:10:55 rburton: this error however seems more like a build race to me Feb 03 19:13:04 fullstop: bazel, maven they cache stuff, so its hard to make them repeatable, perhaps find ways to avoid caching Feb 03 19:13:21 alright time to boot into 5.5 kernel Feb 03 19:13:43 khem: yes, I'm not a fan.. but the layer exists already. Feb 03 19:13:59 and I see now that my layer doesn't exactly match what is in git. Feb 03 19:14:17 This stuff takes hours to compile Feb 03 21:34:28 Hello all, I'm trying to generate a FIT image using Yocto. I have added KERNEL_CLASSES += "kernel-fitimage" and KERNEL_IMAGETYPES_append = " fitImage" to my image recipe, but when I run bitbake I get the following error: Feb 03 21:34:44 output: install: cannot stat '/home/gpanders/Projects/yocto/build/tmp/deploy/images/zcu102-zynqmp/fitImage': No such file or directory Feb 03 21:35:10 Google searches have been fruitless so I'm not sure what else to try at this point Feb 03 21:58:21 I moved those two settings from my image recipe into local.conf and then ran `bitbake virtual/kernel` and that seems to work. So does that mean I cannot specify KERNEL_* configurations in my image? Since my local.conf file is not tracked in version control with my custom layer, is there somewhere I can add that change in the layer itself? Feb 03 21:58:53 gpanders: machine.conf? Feb 03 21:59:41 can I "extend" the current machine that way, or do I have to define a new machine, e.g. zcu102-zynqmp-custom ? Feb 03 22:01:12 gpanders: I've always defined custom machines.... but there might be other ways Feb 03 22:01:37 gpanders: Your custom machine can 'require' the upstream one to make it easier Feb 03 22:01:55 okay Feb 03 22:55:01 New news from stackoverflow: CouchDB Replication / Timeout Error || bitbake failed with ExpansionError Feb 03 23:40:25 JPEW: we're only going to get the ipk comparisons when the deb ones pass. I'm testing a patch to fix that **** ENDING LOGGING AT Tue Feb 04 03:00:51 2020