**** BEGIN LOGGING AT Fri Nov 22 02:59:57 2019 Nov 22 03:35:07 Mailing lists are online and redirection is in place. Nov 22 04:04:28 halstead: stupid question. were the existing subscribers automatically moved to the new lists ? Nov 22 04:04:48 Migration is complete! Nov 22 04:05:02 zeddii, I just sent an e-mail about that. Yes they are. Nov 22 04:05:33 yah. I was trying to log into meta-virtualization as the owner and failed. so I need to figure that out. Nov 22 04:06:34 * zeddii reads: If you are currently a member of any list your account is already created. Visit https://lists.yoctoproject.org/sendloginlink and enter the e-mail you receive list mail at to receive a login link and set a password. Nov 22 04:06:59 zeddii, Can you please help me check moderators were carried over properly? Once you set your password check if you are already a mod at meta-virt and let me know. Nov 22 04:08:12 yep. looks good. I sent myself the link and can see linux-yocto and meta-virtualiation in the list with me as the owner. Nov 22 04:08:59 my gmail filters are going to go nuts :D Nov 22 04:09:56 zeddii, Awesome! (for the first part) Good luck! (for the second) Nov 22 04:10:08 :D Nov 22 05:28:12 how do I get the ${PV} of a package from DEPENDS? Nov 22 07:38:07 I have a multilib-enabled distro, and I want to add the font ttf-dejavu. When I try to add that to my image I get an error message stating: ttf-dejavu was skipped: Don't extend allarch recipes which are not packagegroups Nov 22 07:40:27 I did some reading and it seems like because ttf-dejavu inherts allarch, it cannot rdepend on a package which is not allarch, which I assume it does. Nov 22 09:20:10 bluelightning_: ping devtool glibc :) Nov 22 09:20:22 bluelightning_: sorry... Hi first :) Nov 22 09:39:04 Hi! (How) can I use bitbake with git+ssh and a passphrase? Nov 22 09:42:04 jmiehe: there are usually ways to do things like that, but the main problem is: "where will the passphrase come from?" Nov 22 09:42:25 CI system Nov 22 09:42:43 and how do you intend to pass it into the recipe that shall use it? Nov 22 09:45:44 The CI system can write out the key (with pf) into the build user's ssh directory as usual, and may pass the PF itself anywhere. As CLI param, into temp file, whatever bitbake might want best. Nov 22 09:47:06 then theres already half your answer. pass it as environment variable, make bitbake let it pass (ENV_EXTRAWHITE orwhatsitcalled), and then let the recipe use it Nov 22 09:47:51 we use a similar approach for git+https Nov 22 09:50:56 .netrc works too Nov 22 09:58:19 LetoThe2nd: So you're telling me to provide a custom do_fetch? Nov 22 09:59:03 jmiehe: no, a custom crafted SRC_URI Nov 22 10:00:16 other approaches might be fine too, i just can say that he did this. Nov 22 10:00:21 s/he/we/ Nov 22 10:06:18 kanavin: new gettext failed on the ab https://autobuilder.yoctoproject.org/typhoon/#/builders/73/builds/1255/steps/8/logs/step1b Nov 22 10:07:11 i'll quickly see if it breaks here too like that, in case that was integration failure Nov 22 10:12:57 Thoughts about cloning the recipe's repository before bitbake invocation? Can I somehow flag to bitbake "Do not try to fetch, this one is already fine!"? Nov 22 10:13:56 jmiehe: if it's in the DL_DIR it should be fine without any change I guess Nov 22 10:21:12 You mean if there's a bare (or mirror?) clone in DL_DIR with the requested SRCREV, bitbake will not try to update that? Nov 22 10:50:59 For the log: This currently works with either a bare or a mirrored git clone. Now I just need our CI to clone in bare mode :) Nov 22 10:57:53 rburton, did you pick the commit for the gettext-minimal-native as well? It does break like that if that is missing. Nov 22 10:58:01 ah Nov 22 10:58:07 maybe i missed that Nov 22 10:58:12 stupid gettext-minimal Nov 22 10:58:17 rburton, I see you did not ;) Nov 22 10:58:32 thanks :) Nov 22 10:59:21 so my evil plan is 1) use autopoint instead of hacking about 2) swap gettext-minimal for gettext-tiny Nov 22 11:00:20 it is somewhat annoying to upgrade gettext because of that, you need to first build gettext-native, cherry pick from there the needed pieces for gettext-minimal-native, fix that, then you can build the target gettext Nov 22 11:01:49 right Nov 22 11:01:59 and i want to use autopoint in gettext-minimal which means repacking the lot again Nov 22 11:02:13 i guess i should add a task to generate the bits directly Nov 22 11:03:38 also, they nowadays insist that components use AM_GNU_GETTEXT([external]) Nov 22 11:03:56 if someone omits [externa], it will error out Nov 22 11:04:01 yes Nov 22 11:04:02 love gettext Nov 22 11:04:20 it's old school GNU Nov 22 11:04:37 they fully rejected the suggestion to use meson Nov 22 11:05:03 because basically fashions in build systems come and go, but autotools are still with us Nov 22 11:26:43 +1 Nov 22 12:37:36 Checking for unpackaged file(s): /home/pokybuild/yocto-worker/qemux86-64/build/build/tmp/work/i686-nativesdk-pokysdk-linux/gcc-cross-canadian-x86-64/9.2.0-r0/recipe-sysroot-native/usr/bin/../../usr/lib/rpm/check-files /home/pokybuild/yocto-worker/qemux86-64/build/build/tmp/work/i686-nativesdk-pokysdk-linux/gcc-cross-canadian-x86-64/9.2.0-r0/package Nov 22 12:37:36 free(): double free detected in tcache 2 Nov 22 12:37:37 malloc(): invalid size (unsorted) Nov 22 12:37:37 Aborted (core dumped) Nov 22 12:37:39 WARNING: exit code 134 from a shell command. Nov 22 12:37:39 ok who can i blame for that Nov 22 12:37:42 * rburton glares around Nov 22 12:37:50 RP: ^ seen that before? Nov 22 12:38:04 NOTE: recipe gcc-cross-canadian-x86-64-9.2.0-r0: task do_package_write_rpm: Failed Nov 22 12:38:39 turned on rpm here and rebuilding to see if it happens reliably Nov 22 12:40:18 rburton: hmm. that was what opkg-build was doing Nov 22 12:40:24 huh Nov 22 12:40:28 rburton: but clearly not the same issue for an rpm task failure Nov 22 12:40:54 rburton: I think some of the workers have enabled double free detection so it may be distro specific Nov 22 12:41:03 interesting Nov 22 12:41:13 going to test a bit then Nov 22 12:46:25 just ran master on the same worker Nov 22 12:46:30 hooray for the worker selector button Nov 22 12:51:00 JaMa: congrats on webos 2.1 Nov 22 12:51:30 that new launcher ui looks very much like the tele stuff Nov 22 12:54:00 * rburton grabs rpi image to actually boot his new rpi Nov 22 12:55:14 rburton: :) Nov 22 12:57:47 why can't my monitor put enough power on usb to power a rpi3 Nov 22 13:00:06 it needs around 2.5A, so either your monitor just doesn't have enoguh juice or is too clever and sees rpi as headset device which obviously doesn't need so much power (google rpi4 usb-c power issue) Nov 22 13:00:32 i doubt its too clever Nov 22 13:00:49 if you have original rpi3 psu and adapter from microUSB to usb-c, then it works fine for me Nov 22 13:01:08 its probably just a bit lame, the other monitor has decent charging usb sockets but that means a cable across the desk Nov 22 13:01:28 the bad monitor also powers down usb if the display is off, which isn't useful to power on a device :) Nov 22 13:01:47 so i can just drop the .wic onto a sd card, no faffing about? Nov 22 13:02:01 yes Nov 22 13:02:33 hm all of my sd cards are in cameras Nov 22 13:03:10 JaMa: if i find occasion one day, i shall give you a 's' Nov 22 13:03:29 yeah, I was using similar monitor to power my gta02 before and it was even more strange, because it powered down the usb couple minutes after the screen powered down, so it was working while I was @home and usually stopped working when I was trying to ssh into gta02 remotely from somewhere else (because at that time monitor was completely off already) Nov 22 13:03:46 JaMa: bacause thats all you're lacking from having a "we boss"-product :) Nov 22 13:04:56 so we now "we bo"-product? :) Nov 22 13:05:35 no... "WebOs" + "s" = "We Boss" :) Nov 22 13:05:40 *sighs* Nov 22 13:05:46 JaMa: so what oe is webos 2.1 based on? Nov 22 13:05:50 TGIF. i shouldn't try to be funny. Nov 22 13:06:14 rburton: finally upgraded from morty to thud Nov 22 13:06:27 when are you switching to zeus? :) Nov 22 13:06:54 LetoThe2nd: ah I see now, it's actually funny, I just haven't had enough coffee today to see it :) Nov 22 13:07:12 JaMa: hrhr Nov 22 13:07:20 rburton: I'm on dunfell already, but when they will let me to merge the changes .. that's completely different question Nov 22 13:08:03 whenever i read the new codenames i instantly want to start blasting Gloryhammer Nov 22 13:08:33 rburton: I'm not working mostly on meta-ros, so I have even less influence on webOS itself (even when I still probably have the most commits there) Nov 22 13:08:42 s/not/now/ Nov 22 13:09:28 JaMa: doing anything cool with ros? Nov 22 13:17:28 RP: ok it broke here too if i turn on rpm Nov 22 13:18:28 bisecting Nov 22 13:20:37 rburton: we had a cool robot demo on ROSCon, but I don't have the robot itself at home Nov 22 13:20:49 shame :) Nov 22 13:21:34 JaMa: https://www.youtube.com/watch?v=nZ3QQ2HL5V? Nov 22 13:21:59 erm, add a g to the end of that url Nov 22 13:25:29 any idea if devtool can be used to create an ipk? Nov 22 13:25:50 rburton: yes, that's the one Nov 22 13:52:53 JaMa: huh even with a 5V2A charger i get the lightning thing Nov 22 13:55:06 JPEW: it may be safe to upgrade, see https://www.reddit.com/r/Fedora/comments/dznczn/f31_problem_with_ruby_gem_install/ Nov 22 13:55:31 I haven't seen the error since upgrading binutils to the rawhide version as specified there Nov 22 13:55:47 tgamblin: Ok, thanks Nov 22 14:04:30 rburton: any idea of the cause? Nov 22 14:10:47 gettext, apparnetly Nov 22 14:19:49 rburton: yes 2A is too low Nov 22 14:27:20 rburton: ah :/ Nov 22 14:37:09 JaMa: pretty wallpaper how do i made webose do anything. i briefly saw some buttons but they faded away :) Nov 22 14:37:16 maybe i need a better power supply Nov 22 14:39:11 what?! wallpaper isn't enough for you? You need to touch the magic button.. which I'm not sure which one it is now, windows key was used before and it might work again in 2.1, other more reliable way is mouse gesture dragging from bottom up Nov 22 14:42:38 rburton, how do we typically handle ptests that fail under root, and expect a regular user? Nov 22 14:42:51 add a user Nov 22 14:43:04 kanavin_: can you remember how to get better logs from failing postinsts during do_rootfs? Nov 22 14:43:22 JaMa: aha Nov 22 14:43:22 RP: log.do_rootfs I think? Nov 22 14:43:29 kanavin_: trying to figure out https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/496/steps/8/logs/step2d :/ Nov 22 14:43:35 kanavin_: it doesn't say :( Nov 22 14:43:39 rburton, is there an off the shelf example for adding such a user? Nov 22 14:44:02 JaMa: every time i move the pointer over a tile it jerks up and the lightning bolt appears :) Nov 22 14:44:06 * rburton will order a better adapter Nov 22 14:44:39 kanavin_: quilt-ptest ? Nov 22 14:44:42 rburton: order the official psu if you can, other more clever psu might not work Nov 22 14:45:08 or try your soldering skills inside rpi4 :) Nov 22 14:45:20 RP, WARNING: core-image-minimal-1.0-r0 do_rootfs: busybox-syslog.postinst returned 1, marking as unpacked only, configuration required on target. Nov 22 14:45:20 WARNING: core-image-minimal-1.0-r0 do_rootfs: busybox-hwclock.postinst returned 1, marking as unpacked only, configuration required on target. Nov 22 14:45:20 ERROR: core-image-minimal-1.0-r0 do_rootfs: Postinstall scriptlets of ['busybox-syslog', 'busybox-hwclock'] have failed. If the intention is to defer them to first boot, Nov 22 14:45:20 then please place them into pkg_postinst_ontarget_${PN} (). Nov 22 14:45:22 Deferring to first boot via 'exit 1' is no longer supported. Nov 22 14:45:24 Details of the failure are in /home/pokybuild/yocto-worker/oe-selftest-debian/build/build-st-22425/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/temp/log.do_rootfs. Nov 22 14:45:27 ERROR: Logfile of failure stored in: /home/pokybuild/yocto-worker/oe-selftest-debian/build/build-st-22425/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/temp/log.do_rootfs.2132 Nov 22 14:45:43 RP, I think you need to fetch that log :-/ Nov 22 14:45:51 kanavin_: right, but what was the failure? Nov 22 14:46:11 kanavin_: I reproduced it, I have a do_rootfs log in front of me. Its no more helpful Nov 22 14:47:02 kanavin_: when I say reproduced, I reproduced on that system. Doesn't reproduce locally Nov 22 14:47:30 can I take a look at that log? Nov 22 14:48:45 otherwise, you need to look at the actual postinst scriptlets, and see what they're trying to do. The package managers are supposed to print their output, including error messages, but I am only well familiar with rpm, not ipk. Nov 22 14:48:57 rburton: https://www.raspberrypi.org/forums/viewtopic.php?t=249975 Nov 22 14:49:16 JaMa: i'm on a ghetto 3b+ Nov 22 14:49:31 kanavin_: https://www.rpsys.net/wp/rp/log.do_rootfs.gz Nov 22 14:49:47 kanavin_: above is rpm Nov 22 14:50:31 kanavin_: sorry, not its not is it Nov 22 14:50:51 kanavin_: sorry, I'm thinking this is rpm. opkg is normally more verbose :/ Nov 22 14:51:40 The * file_md5sum_alloc: Failed to open file /home/pokybuild/yocto-worker/oe-selftest-debian/build/build/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/rootfs/etc/syslog-startup.conf: No such file or directory Nov 22 14:51:45 is suspicious Nov 22 14:55:21 rburton, cheers, I can actually skip user creation and run as nobody Nov 22 14:57:21 yeah that would work Nov 22 14:58:12 rburton: ah, I tought you have 4 as you mentioned new rpi :), unfortunately 3B_+_ isn't well supported by webOS (for silly reasons) Nov 22 14:58:41 rburton: https://github.com/webosose/meta-webosose/pulls helps Nov 22 14:59:18 i like that the CLA bot is upset with you Nov 22 15:00:34 well new power supply won't turn up until monday, so maybe next week i'll see if a new image has been built with that in Nov 22 15:01:07 presumably 'porting' to eg intel-corei7-64 is fairly trivial as you have a qemux86 image already Nov 22 15:03:15 you mean new image from build.webos-ports.org? There is an image with it already Nov 22 15:03:27 rburton, is valgrind okay as a ptest dependency? a number of tests are skipped otherwise Nov 22 15:03:34 kanavin_: I think this is a package left over from the previous breakage Nov 22 15:03:47 (I am rewriting sed ptest support, nearly done) Nov 22 15:04:11 JaMa: ah neat. i just grabbed the latest rpi3 image. Nov 22 15:04:23 well CLA bot is upset with me, because I've created public pull request after getting upset with internal people not understanding why we should fix 3B+ support now when only rpi4 is officially supported Nov 22 15:04:25 can't decide whether to cancel the power adaptor order and just get a pi4 Nov 22 15:04:25 kanavin_: valgrind is a dangerous dependency, its just too big :( Nov 22 15:04:40 RP: right, then I'll omit that Nov 22 15:05:05 TOTAL: 67 PASS: 59 SKIP: 8 is fine Nov 22 15:05:14 kanavin_: rburton and I were finding the extra ptests dependencies have already badly inflated dependency graphs Nov 22 15:05:21 rburton: https://forum.webosose.org/t/pre-built-images-available/392/29?u=jama Nov 22 15:05:44 RP: http://errors.yoctoproject.org/Errors/Details/279198/ Nov 22 15:05:59 i see 3 such fails Nov 22 15:06:03 JaMa: yeah that one, thanks. :) Nov 22 15:06:26 hmm, if I change opkg-utils, shouldn't all ipks have rebuilt? Nov 22 15:06:35 gah, its update-alt exclusions Nov 22 15:06:44 does this mean it was hidden Nov 22 15:06:49 * RP quietly curses Nov 22 15:07:29 khem: yes, those were likely quietly ignored previously Nov 22 15:08:03 hmm interesting i guess xz parallelism is too high Nov 22 15:13:52 khem: I'd say so Nov 22 15:31:50 https://github.com/kergoth/dotfiles/commit/55a3da0 terribly hacky, but works.. heh Nov 22 16:09:22 RP: woudl it make sense for meta-mingw to set SOLIBS=".dll" in the sdkmachine conf? Nov 22 16:13:28 is there a way to get the environment (`bitbake -e`) for meta-environment.bb? Nov 22 16:13:52 what you do want that isn't 'bitbake -e meta-environment'? Nov 22 16:14:40 rburton: maybe Nov 22 16:15:09 RP: new gettext causes the mingw layer to break as it has a bbappend, and some of it is just fixing packaging with .dll files Nov 22 16:15:23 presumably if we let the layer switch out solibs then they'd be fine Nov 22 16:15:45 rburton: seems reasonable to me, just not sure how it worked in the past? Nov 22 16:15:52 RP: me neither! Nov 22 16:16:53 bitbake -e meta-environment outputs Nov 22 16:16:55 ERROR: Nothing PROVIDES 'meta-environment' Nov 22 16:16:57 rburton: ^ Nov 22 16:17:12 PN = "meta-environment-${MACHINE}" Nov 22 16:17:48 (the recipe overrides its own name) Nov 22 16:19:14 thanks, that worked Nov 22 16:29:17 RP: hm nativesdk-zlib with mingw builds .so and .a files Nov 22 16:30:06 i've got an interesting problem here: according to `bitbake -e meta-environment-machine`, SDKPATH is set to a correct path - "/opt/agl-sdk/8.0.2-aarch64" Nov 22 16:30:21 RP: but nativesdk-gettext makes .dll.a and .a files Nov 22 16:30:24 however when running the build, it behaves as though it were set to something else, so the build fails Nov 22 16:30:40 creating meta-environment.bbappend with the contents: Nov 22 16:30:46 SDKPATH="/opt/agl-sdk/8.0.2-aarch64" Nov 22 16:30:48 fixes it Nov 22 16:30:54 any idea whats going on here? Nov 22 16:31:24 (`bitbake -e meta-environment-machine was run before creating the bbappend, of course) Nov 22 16:35:31 rburton: these are twoolchains that run on Linux so gettext is wrong Nov 22 16:35:41 rburton: they *target* linux Nov 22 16:35:50 er, target windows Nov 22 16:36:01 right isn't gettext right as its making .dll Nov 22 16:37:13 maybe i'll just let JPEW handle this Nov 22 16:37:16 milloni: what does FOO := "${@bb.warn(str(d.getVar("SDKPATH")))}" do ? Nov 22 16:37:27 (what does it print) Nov 22 16:38:17 * JPEW looks at gettext.bbappend in meta-mingw... Nov 22 16:38:48 JPEW: i'm mainly confused why some recipes build .a and .so files, others build .dll and .dll.a Nov 22 16:39:12 are they actually the same content but just bad names from makefiles that don't know windows? Nov 22 16:39:27 rburton: Seems likely Nov 22 16:39:36 i thought 'oh SOLIBS should be .dll' but that would probably break more than it fixes Nov 22 16:39:46 They have to be .dll to work on mingw. Is the new gettext not produing .dll files? Nov 22 16:40:47 bbappend is breaking as its versioned Nov 22 16:40:49 that is all Nov 22 16:41:03 Ah, yes. That happens frequently Nov 22 16:41:09 rburton, JPEW: remember that meta-mingw is an sdk that targets windows so it should be generating .so for anything nativesdk Nov 22 16:41:13 well, it happens every gettext update Nov 22 16:41:18 right :) Nov 22 16:41:22 at least the backport might be able to go now Nov 22 16:41:46 rburton, tweaking flex is annoying, as any slightest change causes a rebuild of flex-native and everything that depends on it on the way to target flex :( Nov 22 16:42:03 but I might have an upgrade to latest, if ptest doesn't regress Nov 22 16:42:25 kanavin_: if you wanted a fun experiment, I'd love to have a "lock" functionality which stopped that happening Nov 22 16:42:53 kanavin_, RP: That should be *much* easier with all the existing hash equivalence plumbing Nov 22 16:42:57 kanavin_: locked sigs and hashequiv would be two ways Nov 22 16:43:13 JPEW: indeed Nov 22 16:43:30 kanavin_: that is why i invented bb-lockdown Nov 22 16:43:56 kanavin_: https://github.com/rossburton/bb/blob/master/libexec/bb-lockdown very ghetto but works Nov 22 16:44:11 RP: Err, your comment about generating .so libraries for mingw, did you mean .dll for nativesdk? Nov 22 16:45:04 JPEW: I think I'm confused, yes Nov 22 16:45:12 Ok, just checking :) Nov 22 16:45:25 JPEW: too much staring and autobuilder failures Nov 22 16:45:29 kanavin_: 'bb lockdown flex flex' should let you rebuild flex without anything else changing Nov 22 16:46:56 rburton: we could make this a lot easier with a "include conf/lockdownsigs.inc" in bitbake.conf by default Nov 22 16:47:07 rburton: then the "lock" and "unlock" scripts could be trivial Nov 22 16:47:08 right Nov 22 16:47:16 the trick is a nice note when you're locking Nov 22 16:47:30 rburton: so we make a dedicated file and have proper scripts Nov 22 16:47:46 * RP would love patches Nov 22 16:47:56 then I can worry about not having time to review them :) Nov 22 16:48:18 * Crofton|work thinks about inventing tinder for patches Nov 22 16:49:32 Crofton|work: only if I can tweak the matching algorithm ;-) Nov 22 16:51:35 rburton, I am trying to start the weekend here :) Nov 22 16:51:41 haha Nov 22 16:51:42 but sure looks promising! Nov 22 16:51:44 have a good one ;) Nov 22 16:53:25 RP: shouldnt the inner quotes be escaped Nov 22 16:53:26 so Nov 22 16:53:31 FOO := "${@bb.warn(str(d.getVar(\"SDKPATH\")))}" Nov 22 16:55:06 milloni: sorry, use ' for one set Nov 22 16:56:21 I'm including package-management in my image, with opkg package manager, I set the PACKAGE_FEED_URIS = http:// but it doesn't reflect anywhere in the image Nov 22 16:57:28 I was expecting that it will configure the opkg configuration to that but apart from the rootfs[vardeps] there is no other handling being done on base of this variable, Nov 22 17:03:23 rburton: If we can drop the gettext patch in meta-mingw, perhaps we can make the bbappend to use '%' instead of a specific version? Nov 22 17:07:13 RP: WARNING: /usr/local/oecore-${SDK_ARCH} Nov 22 17:08:14 milloni: hmm, so its seeing the "bad" value. What does the history in bitbake -e look like for that var? Nov 22 17:08:17 but in fact, when the build failed, that wasn't the path it was failing with Nov 22 17:08:25 it was trying to populate opt/agl-sdk/8.0.2-armv7a Nov 22 17:08:32 milloni: so there are three bad paths? Nov 22 17:09:04 sorry, thats the warning i got when running the image recipe - should i run this with meta-environment instead? Nov 22 17:09:45 milloni: no, its the same thing Nov 22 17:09:55 ok, that's the message i got Nov 22 17:10:29 i added FOO := ... in local.conf if that makes a difference Nov 22 17:10:58 milloni: oh, I think I remember this problem. Are there two similar variables and if you change one you need to change the other? Nov 22 17:11:16 not that i know of Nov 22 17:11:17 milloni: that explains it, I meant for you to add it in meta-environment Nov 22 17:11:24 okay, i'll do that Nov 22 17:11:26 sorry Nov 22 17:12:33 milloni: are you using poky? Nov 22 17:13:26 RP: it's a distro/bsp derived from AGL (which is derived from poky) Nov 22 17:16:24 JPEW: yes Nov 22 17:18:13 milloni: I think the agl layer is setting it to something. Its hard to know why it isn't working Nov 22 17:18:39 milloni: variable history output from bitbake meta-env -e would help Nov 22 17:20:07 RP: https://paste.debian.net/1117484/ Nov 22 17:20:43 ah, i think i know what's going on Nov 22 17:21:39 i cant really paste the histrory for DEFAULTTUNE cause the interesting parts are from proprietary layers, but there's an override Nov 22 17:22:10 # override[virtclass-multilib-lib32]:set /censored/path/ Nov 22 17:22:18 # "armv7a" Nov 22 17:22:48 is it supposed to be doing that for an aarch64 build? Nov 22 17:40:24 hmm, yes it is supposed to do that - according to an example in meta-skeleton Nov 22 17:50:16 New news from stackoverflow: How to pass cmake runtime parameter in yocto Nov 22 18:00:06 milloni: well, the default tune bit comes from the AGL layer and is the one that seems to be breaking Nov 22 18:00:37 sure - have you seen the example multilib configuration from meta-skeleton though? Nov 22 18:00:43 it looks identical Nov 22 18:00:46 milloni: if you're using multilib there will be two meta-environments, one 32 and one 64 Nov 22 18:01:01 hm Nov 22 18:01:12 milloni: not recently but I probably wrote it ;-) Nov 22 18:01:20 hah Nov 22 18:02:43 milloni: yes, I did write it in 2013 ;-) **** BEGIN LOGGING AT Fri Nov 22 22:21:57 2019 Nov 22 23:54:32 was zeus branch just upgraded (6431e86 -> cabaff5) to be immediatelly rolled back (cabaff5 -> 6431e86)? Nov 22 23:55:09 I've received bunch of e-mails with updates in zeus, but wasn't seeing them in git and now I see another e-mail rolling it back which might explain it, but was it intentional? **** ENDING LOGGING AT Sat Nov 23 02:59:57 2019