**** BEGIN LOGGING AT Tue Mar 31 02:59:57 2020 **** BEGIN LOGGING AT Tue Mar 31 03:07:53 2020 Mar 31 07:22:13 uh, how can += end up replacing the full variable? Added FILE_${PN}-bla += "bla.conf" and result is "WARNING: Variable key ... replaces original key ..." which is good. At least a warning, but I still wonder why doesn't the append work.. Mar 31 07:23:37 mcfrisk: hum, related to evaluation time? Mar 31 07:23:46 mcfrisk: is the original assignment done using ?= or ??= = Mar 31 07:24:22 the last = was supposed to be a ? Mar 31 07:28:42 I'll check the recipe. Could it be that in bbappend I was using FILES_${PN}-bla and recipe uses FILES_recipename-bla ? Mar 31 07:32:32 mcfrisk: I don't think that should matter Mar 31 07:32:33 yep, that was it. was not expecting this at all. So ${PN} in variable names changes the evaluation order completely and even += and _append end up overwriting the same variable name set without the ${PN}. Mar 31 07:33:04 this on sumo Mar 31 07:33:39 bananas Mar 31 07:34:12 e2fsprog is one example where ${PN} is not used in FILES Mar 31 07:34:17 e2fsprogs is one example where ${PN} is not used in FILES Mar 31 07:37:32 but I'm very happy that I saw the warning. Mar 31 07:45:43 Hello all, Someone knows the better way to pass EXt_DTB option to u-boot ? Thx Mar 31 07:48:57 "better than"? Mar 31 07:49:43 LetoThe2nd the best way, sorry for my english :S Mar 31 07:50:05 mcfrisk: seems like e.g. FILES_${PN}-resize2fs_append = " foo" work on zeus, but not FILES_${PN}-resize2fs += "foo" Mar 31 07:50:48 erbo: yes. this odd. or unexpected. Mar 31 07:51:02 I think I Mar 31 07:51:24 I would like to add an external dtb to u-boot binary in order to sign it, the the original recipe http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-bsp/u-boot/u-boot.inc?h=master doesn't take EXT_DTB option, so i don't know how to add, maybe rewrite do_compile inside a bbappend but not sure :) Mar 31 07:51:36 've run to this before, maybe even long time ago.. Mar 31 07:59:45 can killing bitbake build processes result in large amounts of "is owned by uid 1005, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated]" errors from sstate cache? could some data used by pseudo be out of sync if bitbake got killed violently? Mar 31 08:05:40 Ninic0c0: http://cgit.openembedded.org/openembedded-core/tree/meta/classes/uboot-sign.bbclass Mar 31 08:22:40 qschulz Yes I have already take a look here, but this support is not enable directly inside u-boot.bb ? Mar 31 08:24:40 Note: Functions in this bbclass is for u-boot only and i don't use official u-boot recipe :S Mar 31 08:28:13 Ninic0c0: why are you linking u-boot.inc from the official u-boot recipe then :) ? Mar 31 08:28:50 qschulz maybe because u-boot-xlnx require this file :) Mar 31 08:29:09 then you have u-boot-sign inherited Mar 31 08:29:23 Ninic0c0: http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-bsp/u-boot/u-boot.inc?h=master#n8 Mar 31 08:29:45 if you are actually using this .inc and not some from another layer Mar 31 08:30:41 qschulz the purpose here is to find the best way to add EXT_DTB to u-boot, yes i'm using this file but as my bootloder recipe is u-boot-xlnx and not u-boot only Yocot doesn't execute this part of code Mar 31 08:36:36 Ninic0c0: UBOOT_SIGN_ENABLE = 1 in your u-boot-xlnx somewhere? Mar 31 08:37:07 http://cgit.openembedded.org/openembedded-core/tree/meta/classes/uboot-sign.bbclass#n46 so if PREFERRED_PROVIDER_u-boot is "u-boot-xnlx" that should satisfy the if conditions you see in this class Mar 31 09:07:46 qschulz I didn't set PREFERRED_PROVIDER_u-boot, I'm using PREFERRED_PROVIDER_virtual/bootloader. I will search a solution thx for help Mar 31 09:10:47 Ninic0c0: set both? Mar 31 09:14:11 qschulz yes i(m not stupid ^^ But to be honest don't use kernel-fitimage.bbclass so i don't sure that a good idea to use u-boot-sign class, what do you think about that ? Mar 31 09:15:03 Ninic0c0: how exactly are you checking the kernel/dtb validity from u-boot? Mar 31 09:19:15 Ninic0c0: (authentication) Mar 31 09:30:43 New news from stackoverflow: Yocto beaglebone wired ssh Mar 31 09:32:07 qschulz I have done all the process outside Yocto. I mean RSA keys are used to create the fit image (with custom bbclass) I would like to create a bbappend or an other class to uses same keys to generate a dtb with key hash only, based on a dummy file u-boot_pubkey.dts Mar 31 10:02:25 Hello Yocto Guys Mar 31 10:02:40 i have a really short and simple question: Mar 31 10:02:54 "where is the free beer=" Mar 31 10:03:03 yeah i keep asking the same too! Mar 31 10:06:29 I have a really simple or may be complicated question. I want to install python3.7 with Yocto Sumo. I know Yocot Warrior offers python3.7 but how can I upgrade my python3.5 to Python3.7 in Yocto Sumo.It would be really nice of you If you could help me with this. Mar 31 10:07:04 *lesigh* Mar 31 10:07:06 https://twitter.com/TheYoctoJester/status/1244716883124850689 Mar 31 10:07:43 Mani88: in a nutshell, if you have to ask then you can not. this is a rather heavy and troublesome backport. Mar 31 10:13:17 Guys! I am using yocto:sumo and I would like to compile and install python3.7 on the target. Is there any straight-forward way to do that? Mar 31 10:13:45 fawad: go ask Mani88, he's sitting right next to you probably. you can team up! Mar 31 10:14:07 :) Mar 31 10:14:32 I am all alone in quarantine atm Mar 31 10:14:40 I am all alone in self quarantine atm Mar 31 10:15:00 10:07 < LetoThe2nd> *lesigh* Mar 31 10:15:00 10:07 < LetoThe2nd> https://twitter.com/TheYoctoJester/status/1244716883124850689 Mar 31 10:15:01 10:07 < LetoThe2nd> Mani88: in a nutshell, if you have to ask then you can not. this is a rather heavy and troublesome backport. Mar 31 10:15:07 fawad: same applies for you then. Mar 31 10:16:01 Thanks! Mar 31 10:16:11 and sorry to bother you LetoThe2nd! Mar 31 10:16:38 I guess it might be better to use upgraded version and fix the versions for kernel and other stuff. Mar 31 10:17:57 fawad: yep. Mar 31 10:19:52 Hey, I'm trying to integrate package feeding through smart/rpm int my image (https://wiki.yoctoproject.org/wiki/TipsAndTricks/EnablingAPackageFeed). Seems like this is outdated or lacks some information but I can't find `smart`, `smartrpm`, `smartpm` (all of these seems to be somewhere out there) in any layer or any recent information about those Mar 31 10:19:53 packages. What layer do I need to add and what recipe to I have to `IMAGE_INSTALL_append`? Mar 31 10:20:15 emrius: something dnf, probably. Mar 31 10:20:36 fawad: technically you could still have your old kernel versions with *hopefully* only a few changes in the recipe. So, if you're only using your own kernel and u-boot, upgrading should be rather easy and the way to go IMHO Mar 31 10:20:41 ah okay. So dnf replaced smart? Mar 31 10:21:17 no idea, i'm an ipk guy :) Mar 31 10:22:11 emrius: dnf is used on Fedora and it can install rpm AFAIK (basically replaces yum) Mar 31 10:22:13 I see ;) okay I'll give it a try and probably drop some info on stackoverflow in case others stumble across the same issue Mar 31 10:22:14 .14 Mar 31 10:22:31 thanks! Mar 31 10:22:56 emrius: wait Mar 31 10:23:08 are you on a release prior to Jethro? Mar 31 10:23:23 emrius: ^ Mar 31 10:24:40 because the IMAGE_INSTALL seems to apply only to pre-Jethro releases from the wiki Mar 31 10:26:42 does libstdc++ get included in the core-image-minimal by default? Mar 31 10:28:01 running cross-compiled binary on target. I get: error while loading shared libraries: libstdc++.so.6: Mar 31 10:28:49 spiel, no you need to add it explicitly Mar 31 10:28:50 spiel: it does not. Mar 31 10:50:35 hi, does anyone know how i can disable the password for the root user on a yocto build? Mar 31 10:51:13 FrazerClews: blunt: EXTRA_IMAGE_FEATURES += "debug-tweaks", as noted in the default local.conf Mar 31 10:51:23 qschulz sorry, I just read your message. I'm on warrior. Hence, post-jethro Mar 31 10:51:38 emrius: so read carefully the wiki you linked :) Mar 31 10:51:39 FrazerClews: more finegrained, look at image.bbclass and pick the triggerd parts that you actually need. Mar 31 10:51:56 If it does not work, then there's something to update in the wiki page and/or help you debug it Mar 31 10:52:32 Yeah, I actually read the passage that this does not seem required. But when I started the image `smart` was not available. Mar 31 10:52:35 LetoThe2nd thanks Mar 31 10:58:16 emrius: so the question is more, that's the package manager for rpm on the target :D Mar 31 10:59:34 Hi. Is twice `do_install_append()` inside a recipe correct? Mar 31 11:01:39 has anyone tried -c populate_sdk with package_deb? it explodes in strange ways for me Mar 31 11:01:43 nacknick: as many as you want Mar 31 11:02:09 shoragan: KABUM! <3 <3 <3 Mar 31 11:02:31 LetoThe2nd: that is indeed a strange sound Mar 31 11:02:42 hmm, glibc. should I update to stable branch from git in sumo... Mar 31 11:04:13 KABUM. https://www.youtube.com/watch?v=ub4VArS_xWk Mar 31 11:06:12 especially, https://youtu.be/ub4VArS_xWk?t=242 Mar 31 12:06:31 I have a strange-looking shared-state reuse failure on sumo. I've rsync'd my sstate from CI server as usual, and "bitbake -n " starts to show it wants to rebuild tons of stuff. Taking the kernel as example, comparing one by one the sigdata extracted from both envs using "-S none", bitbake-diffsigs on do_package.sigdata files show nothing (only on do_build.sigdata does rm_work_all introduce some "noise"). Yet bitbake fetch/.../compile/...:package Mar 31 12:06:31 my kernel. What am I missing ? Mar 31 12:18:46 yann: I'd try bitbake -DDDv and save the logs, then look at the section where it looks for sstate artefacts and see what its not finding Mar 31 12:36:21 there are a number of stampfiles listed as "notavailable", for my linux-rockchip it lists do_package_write_ipk_setscene, do_shared_workdir, do_deploy, and more; and complains about missing matchint .tgz's in sstate-cache. The first meaningful line seems to be "Cache: .../linux-rockchip_4.4.bb's dependency .../poky/meta/recipes-kernel/linux/linux-yocto.inc changed", though it does not make sense that this file would change :| Mar 31 13:19:08 hello Mar 31 13:19:51 I am trying to run some application automatically at booting Mar 31 13:20:24 I've written some scripts to run it and I wrote another echo message to know it works or not Mar 31 13:20:44 it echo the message well but still couldn't run the application Mar 31 13:20:55 i am try to run at Wayland Mar 31 13:21:32 any help ? Mar 31 13:22:05 moustafa: and what way of scripting did you try? Mar 31 13:22:22 Any error message? What's the line which you think is failing? Can you share your init script? etc... :) Mar 31 13:22:47 LetoThe2nd: you have a few usain bolt instead of fingers I see Mar 31 13:23:05 qtapp -platform wayland doen't work Mar 31 13:23:19 should I type my script here ? Mar 31 13:23:41 line by line or there are some repository to upload it Mar 31 13:23:42 no, a pastebin is usually the correct way to share 3+ lines of code Mar 31 13:24:04 moustafa: have you tried running on of the qt examples? Mar 31 13:24:13 one* Mar 31 13:24:26 it works well at terminal Mar 31 13:24:30 after booting Mar 31 13:24:37 ok, that is important information Mar 31 13:25:34 i typed checked msg : echo "hello script" >> /usr/share/test.txt before that line Mar 31 13:25:38 and it works well Mar 31 13:31:25 the key point is (probably) that when you're in the terminal, all of the boot process is finished and all the environment is set up. which might not be true depending on the way you run your script. Mar 31 13:34:13 so find out why it fails. read error messages. Mar 31 13:34:50 ok could u tell me how I can echo the error messages ? Mar 31 13:36:10 again, depends on the way you do your scripts. Mar 31 13:36:12 i think a good start would be to say how you're running this script on boot Mar 31 13:36:20 is it a sysv-style init script? a systemd unit? Mar 31 13:36:29 * LetoThe2nd feels like handholding and doing somebody elses homework Mar 31 13:37:47 LetoThe2nd: can you do mine? please? :) Mar 31 13:38:15 RP: is it on sumo? otherwise its not cool. all the cool kids are using sumo these days! Mar 31 13:38:31 LetoThe2nd: what's sumo? ;-) Mar 31 13:39:52 RP: https://twitter.com/TheYoctoJester/status/1244716883124850689 Mar 31 13:41:05 LetoThe2nd: sad, but probably true Mar 31 13:41:39 RP: cue https://youtu.be/A8MO7fkZc5o Mar 31 13:41:52 rburton it's sysv init scripts Mar 31 13:47:36 Hi, First, I hope you're all fine and safe. Second, I'm trying to reorganize our CI environment, and I'm wondering which folders I can share between simultaneous builds, regarding different yocto versions (zeus/dunfell) & different machines? Is it ok for source mirror and sstate-cache? or should I separate them? Is there any good-practices document or live example on yocto CI ? Mar 31 13:49:34 nayfe: Sharing sstate between different branches should be (and from expirence) is safe Mar 31 13:49:36 nayfe According to my experience you can share downloads and sstate-cache folder, I have done that with 12 different machines Mar 31 13:50:35 JPEW: for simultaneous builds with concurrent write access? i'm surprised. Mar 31 13:52:12 moustafa: still no script for us :) ? Otherwise, just redirect the output to a file. Something like qtapp 2&>1 or whatever is the correct way to redirect all outputs and errors to a file. But I think you should have some errors in the bootlog (except if it fails silently :/) Mar 31 13:52:45 LetoThe2nd: It doesn't work perfectly. Our ci builds pull from the sstate mirror and then rsync it back when they are done Mar 31 13:53:32 JPEW: ah, that sounds more like what i expected, indeed. Mar 31 13:53:41 LetoThe2nd: And we have a script we run that "sanitizes" it by removing .tgz files missing a .siginfo and vis-versa Mar 31 13:54:38 Oh, and a cron job that deletes the whole thing every Friday night ;) Mar 31 13:55:22 JPEW: you can have siginfo only for non-sstate tasks Mar 31 13:59:43 RP: Hmm, that error is odd Mar 31 14:00:14 It looks like the do_patch datastore finalization is racing with the do_unpack postfunc Mar 31 14:01:35 New news from stackoverflow: Trying to add nodejs and npm (or yarn) to a yocto image (poky:zeus) Mar 31 14:02:42 Doesn't seems straightforward then ;) Mar 31 14:02:51 JPEW: I haven't had a chance to look in detail as yet Mar 31 14:07:44 JPEW thanks for details, any reason to rebuild sstate-cache every week? Mar 31 14:10:30 nayfe: so you detect errors when there's no sstate-cache available (which is probably be the case of your clients). Some races etc... I remember few years ago it was recommended to release only after a sstate-cache, so you know everything worked from a fresh clean build. Don't know the recommendations now.. Mar 31 14:12:17 qschulz> Ok, it makes sense for people releasing yocto layers to their clients, thanks Mar 31 14:13:15 so many missing words in my sentence *sigh* Mar 31 14:15:21 It's ok for me, i'm better in french language ;) Mar 31 14:15:52 Ben on est deux tiens Mar 31 14:15:59 hehe Mar 31 14:37:21 RP: trying to diff the -DDDv logs, but even with SDL BB_NUMBER_THREADS = "1" on both sides, the lines are not sorted the same - any way to counter that ? Mar 31 14:39:16 LetoThe2nd, from what you said before about disabling the password for root, it seems to only make the password empty, is there anyway to remove it? Mar 31 14:40:18 FrazerClews: in the meaning of? Mar 31 14:40:50 LetoThe2nd> FrazerClews: blunt: EXTRA_IMAGE_FEATURES += "debug-tweaks", as noted in the default local.conf Mar 31 14:40:51 LetoThe2nd> FrazerClews: more finegrained, look at image.bbclass and pick the triggerd parts that you actually need. Mar 31 14:41:33 FrazerClews: yeah i know what i typed, but what different behaviour do you expect from a "removed" password in comparison to an "empty" one? Mar 31 14:42:11 is it about disabling root login? Mar 31 14:43:30 yann: I didn't say to diff them, I suggested looking at which objects it wasn't finding Mar 31 14:44:10 I know, but I do like diffing :) Mar 31 14:49:49 LetoThe2nd yes Mar 31 14:51:59 strangely though, now I don't have the same "missing" messages I saw this morning any more - after only running "bitbake -n" and not touching the sstate externally Mar 31 14:53:11 FrazerClews: https://wiki.yoctoproject.org/wiki/FAQ:How_do_I_set_or_change_the_root_password together with usermod -l, presumably. Mar 31 14:53:42 FrazerClews: empty-root-password should not be in IMAGE_FEATURES as well from the code I read Mar 31 14:53:50 ah no they are still there, just not in sa same order as before, which brings us back to the "predictable order" problem :) Mar 31 14:54:43 I don't have the "linux-yocto.inc changed" line any more, though Mar 31 14:55:04 thanks LetoThe2nd, i will give that a go and see if it fixes it Mar 31 14:59:58 RP: do you have precise patterns to look for in the log ? Mar 31 15:02:43 the thing that seem reliable in the logs is the "/stamps/.*not available$", but I'm not sure now best to dig into those Mar 31 15:03:33 YPTM: joined Mar 31 15:04:40 YPTM: Scott Murray is on Mar 31 15:04:43 (and the matching missing sstate lines) Mar 31 15:06:02 YPTM: Jan-Simon is on Mar 31 15:27:35 do'h - I was using the wrong sstate-cache all along, sorry for the noise :| Mar 31 15:36:22 YPTM: thank you Trevor for taking notes! Mar 31 16:01:59 New news from stackoverflow: Beaglebone dcan0 and dcan1 Mar 31 16:30:12 nayfe: We erase it once a week to keep it from growing unboundly Mar 31 16:38:52 JPEW> sstate-cache-management script is not enough? Mar 31 16:43:27 nayfe: Not sure.... we have 60 parallel builds across 4 different Yocto verisons, so it would be hard to coordinate Mar 31 16:44:08 Hello together, I'm running qemux86-64. I built a core-image-base which successfully ran on branch thud. Now, I moved to warrior and after kicking off qemu it gets stuck at Waiting for root device `/dev/mmcblk0p2...`. Does anybody have an ad hoc idea why? Mar 31 16:44:38 Sorry, wrong dashes. But you got it probably `Waiting for root device /dev/mmcblk0p2...` Mar 31 16:44:39 yann: sorry, been in meetings but glad you're sorted Mar 31 16:45:05 np, I understand better why I could not find any clue in the logs :) Mar 31 16:45:45 well, being able to diff them would definitly have pointed out the sstate discrepancy Mar 31 16:46:36 any idea on how to make this more deterministic ? Mar 31 17:24:41 when doing populate_sdk with debs i get "apt-dev : Depends: apt (= 1.2.31-r0) but it is not going to be installed" and similar also for dpkg. Mar 31 17:24:50 it works fine for ipkg and rpm Mar 31 17:25:51 i'm trying to compare what deb does vs ipkg, but haven't found anything obvious yet. Mar 31 17:35:55 JPEW> wow that's a lot! :) Mar 31 17:54:02 shoragan: file a bug and just use ipkg :) Mar 31 17:55:36 rburton, if it was up to me, i'd use ipkg ;) Mar 31 17:56:10 not ready to give up yet ;) Mar 31 18:25:18 hi im currently linting my work, i have been using oelint-adv https://github.com/priv-kweihmann/oelint-adv, but just saw theres a oe-stylize.py in meta-openembedded, does anyone know if one is better than the other, or are they both good at different things? Mar 31 18:50:17 any way to check if a bbclass its available before calling inherit? to avoid a parse error Mar 31 18:57:06 not a check. I have used DISTRO_FEATURES to or some other variable to include. Maybe a python function may do the trick Mar 31 19:26:10 hey uh , is there a preferred way to handle firmware symlinks ? Basically cypress has this https://github.com/murata-wireless/cyw-fmac-nvram which is not part of linux-firmware , so I am trying to package it Mar 31 19:26:35 but they have brcmfmac43455-sdio.1LC.txt and brcmfmac43455-sdio.1MW.txt in there and the kernel driver expects only one of them called brcmfmac43455-sdio.txt Mar 31 19:26:54 so I want to make that brcmfmac43455-sdio.txt a symlink to one of the two, but I would like to have the option to have packages for both Mar 31 19:27:15 I guess I need some runtime symlink creation ... hm, is update-alternatives actually an option ? Mar 31 19:58:25 Marex: that's the only thing that comes to mind off the top of my head, yeah Mar 31 20:01:09 smurray: except that only works between recipes (i.e. if a recipe packages a file, which is also packaged by another recipe) Mar 31 20:01:35 Marex: ah, hadn't realized that Mar 31 20:07:31 RP: v2 submitted for install-buildtools Mar 31 20:12:17 I'm trying to use tc on a target. I built iproute2 and installed it on the target but there's no tc binary Mar 31 20:17:19 did you add iproute2-tc package Mar 31 20:18:11 nhartman: see tmp/work/*/iproute*/*/package-split Mar 31 20:18:44 when I try build iproute2-tc I get `ERROR: Nothing PROVIDES 'iproute2-tc'` Mar 31 20:18:56 `Close matches: Mar 31 20:18:56 iproute2 Mar 31 20:18:56 iproute2 RPROVIDES iproute2-tc Mar 31 20:18:56 ` Mar 31 20:20:00 you must build iproute2 which creates an iproute2-tc package Mar 31 20:21:08 Ohhh, I see. Gotcha thanks! Mar 31 21:05:11 moto-timo: thanks, much appreciated Mar 31 21:27:05 yocto/oe-related talks from linaro tech days: Mar 31 21:27:29 xen-based arm autonomy stack using yocto: https://youtu.be/CCm7yC2rBP8?t=10500 Mar 31 21:28:11 yocto tricks and hacks: https://youtu.be/CCm7yC2rBP8?t=14793 Mar 31 21:28:44 yocto project long term support: https://youtu.be/CCm7yC2rBP8?t=17686 Mar 31 21:56:35 moto-timo: I think I'm getting confused. Right now 4.8 does work, we haven't dropped the 4.8/4.9 support yet Mar 31 21:57:03 moto-timo: I'm tweaking on -next as the AB exploded :/ Mar 31 21:57:24 moto-timo: we will need this check soon, just maybe not quite yet Mar 31 21:57:46 we do need the installer though Mar 31 22:09:42 RP: I thought the whole point was Centos-7 (4.8.5) is broken... why else did we do all this? Mar 31 22:10:02 * moto-timo not a gcc expert Mar 31 22:14:58 RP: i was just getting ready to send poky.conf update and noticed you beat me to it :) Mar 31 22:16:45 RP: maybe it was just getting very painful (thinking alex) to patch for centos-7 Mar 31 22:16:55 RP: I don't know anymore. brain == mush Mar 31 22:21:36 I notice from zeus->master qemu remote X support now fails due it wanting MIT-SHM, anyone know right off of a configuration tweak to get it working as before? Mar 31 22:26:35 moto-timo: We already have to use buildtools on centos due to python verison issues and tar. I know 4.8 is getting really hard to support Mar 31 22:26:58 moto-timo: I think I'm fuzzy on all the details now too, too much going on :/ Mar 31 22:27:11 RP: I guess I'll leave weaker language in the docs then ;) Mar 31 22:28:11 moto-timo: I just hacked poky.conf since I was there. The dependency issues probably still need documenting Mar 31 22:28:37 RP: I've got the dependency issues covered. just sanity checking the docs in html and pdf form Mar 31 22:28:55 moto-timo: we did test with buildtools tarball on centos so I guess we could switch to it but its probably less risky to leave things as they are for release now Mar 31 22:29:08 (with gcc min version) Mar 31 22:29:29 RP: something about crypt.h ? something something... Mar 31 22:29:41 ? Mar 31 22:30:05 https://www.youtube.com/watch?v=0oGMbAIcXCQ Mar 31 22:31:15 moto-timo: you know what else we need in there? A gcc too new check :/ Mar 31 22:31:17 RP: http://git.yoctoproject.org/cgit/cgit.cgi/yocto-autobuilder-helper/commit/config.json?id=af71a12919b78f42a94c7ca4ac1fd3ccb1112dd5 Mar 31 22:31:40 RP: I thought about that... what to test it on? Mar 31 22:31:44 * moto-timo scratches head Mar 31 22:31:53 tumbleweed? arch? Mar 31 22:31:57 moto-timo: well, when the time comes we at least have codehooks Mar 31 22:32:06 \o/ Mar 31 22:32:42 moto-timo: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=06972e2d4d87f56ffed187f1c9659313c09f4396 - we fixed the crypt issue so that should be in M3's buildtools Mar 31 22:32:44 tlwoerner: lol Mar 31 22:33:40 RP: ah-ha. I have been living under a rock. Mar 31 22:34:19 moto-timo: I guess the question is do we drop gcc 4.X support from 3.1 or not Mar 31 22:34:28 * moto-timo happy to drop one more worry from queue Mar 31 22:35:00 RP: that was where I thought we were, but again -- not an expert Mar 31 22:35:12 We have all the mechanism in place, just a question of whether we do it Mar 31 22:35:27 We wanted to do it, we're just quite late Mar 31 22:35:28 RP: I'd be happier knowing specifically what was broken like to old sanity.bbclass gcc checks did (rburton et al) Mar 31 22:35:45 RP: agreed. Mar 31 22:35:59 moto-timo: I think it breaks as soon as we start dropping gcc 4.X patches to hack things to build Mar 31 22:36:43 moto-timo: these changes and tarball will be key to supporting LTS in the future so it all needed to be done Mar 31 22:36:57 RP: indeed. Happy to have done it. Mar 31 22:37:23 RP: could use a little bit of refactoring and elegance, but ... it works Mar 31 22:38:03 moto-timo: applies to so much of the codebase ;-) Mar 31 22:38:12 RP: lol Mar 31 22:47:32 beeetlejuice beetlejuice beetlejuice Mar 31 22:47:34 Marex: if you didn't get a response then yeah update-alternatives is probably wise Mar 31 22:48:20 rburton: RP and I were just discussing the old gcc checks that were once in sanity.bbbclass... Mar 31 22:58:04 JPEW: I think that code is expanding SOURCE_DATE_EPOCH before MLPREFIX is set :/ Mar 31 23:04:11 JPEW: I think we need to set some kind of sentinel at the end of parsing so it knows when to attempt reading form the file. Alternatively, why is build_dependencies() calling it when its in BB_HASHBASE_WHITELIST Mar 31 23:04:19 anyhow, time to slkeep **** ENDING LOGGING AT Wed Apr 01 02:59:57 2020