**** BEGIN LOGGING AT Mon Nov 25 02:59:58 2019 Nov 25 07:44:02 good morning Nov 25 07:58:57 New news from stackoverflow: Yocto bitbake script not displaying echo statement Nov 25 10:29:23 New news from stackoverflow: How to clone a git repo with its submodules recursively in Yocto Nov 25 12:06:05 when firing a new build, remember to push Nov 25 12:07:06 push harder! Nov 25 12:29:55 Hi guys! I just noticed that the certificates file that is shipped with openjdk (which resides in "/usr/lib/jvm/java-7-openjdk/jre/lib/security/") have expired, however it is still being included in the image instead of being updated at build time. Is this the default behavior? Should I perform any manual action in order to get the current Nov 25 12:29:55 certificates? Nov 25 12:50:36 Hi, I've got a strange issue which is not directly yocto related.... maybe someone has an idea what the problem could be? https://pastebin.com/GNHERJj7 (Accessing /dev/mem as root) Nov 25 12:51:49 ThomasD13: https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.16-Def-Strict-Dev-Mem? Nov 25 12:52:31 rburton, thats should be no problem. This kernel configuration just limits the access of /dev/mem to the first megabyte. Nov 25 12:53:10 I already set this in my .config to "n". I just want to verify that... and now I'm facing the issue that I cannot access /dev/mem on my linux image Nov 25 12:59:47 New news from stackoverflow: PHP odbc driver as shared extension Nov 25 13:50:06 I have a layer "A" which appends some kernel cfg files. It's structured like /A/recipes-kernel/linux/linux-raspberrypi-rt_%.bbappend Nov 25 13:50:27 in /A/recipes-kernel/linux/files are the .cfg-files Nov 25 13:51:41 Now I have a second layer "B" which should also append some kernel cfg files. It has the same structure as A: /B/recipes-kernel/linux/linux-raspberrypi-rt_%.bbappend + the file directoy with .cfg-files Nov 25 13:52:37 However, only the .cfg-files from layer "A" are applied to my kernel config. Should it work with my structure or did I setup something wrong? Nov 25 13:53:10 Layer "A" has 6 as priority, Layer "B" has 99 Nov 25 15:42:53 I set PV = "${DATETIME}" and PV[vardepsexclude] = "DATETIME" in an image recipe, however, I still get basehash value changed errors. bitbake-diffsigs says "Variable PV value changed from '20191125153756' to '20191125153809'", shouldn't that be solved by using vardepsexclude? Nov 25 15:45:29 JPEW: happen to be around yet? Nov 25 15:56:13 RP: Ya, I'm here Nov 25 15:58:10 JPEW: just wondering what you make of our email discussion Nov 25 15:58:20 JPEW: and how horrific my patch is? :) Nov 25 15:59:02 RP: It's what I expected (e.g. what I would have done :) ) Nov 25 15:59:04 sagner, do: PV := "${DATETIME}" it will be evaluated -once-. Nov 25 16:00:00 RP: So is the problem limited only to -cross recipes? They seem to be outliers, since AFAICT they are "target" recipes but generate "native" executable? Nov 25 16:00:24 ^^ Didn't look closely, I might be wrong Nov 25 16:00:29 JPEW: I think I uncovered another latent bug with the new hash not being written out to the stamp causing setscenes to rerun in the next build Nov 25 16:00:41 JPEW: would apply to any native recipe too Nov 25 16:01:10 foo-native built on an ARM server will be different to an x86 server Nov 25 16:01:21 Primarily because the native arch isn't part of the task hash, and sstate deals with that by putting them in different directories? Nov 25 16:01:34 JPEW: right, its part of the filename Nov 25 16:01:49 JPEW: I hadn't quite realised how important that was here :/ Nov 25 16:01:55 me either Nov 25 16:02:11 fray: hm, I remember doing that in DISTRO_VERSION where it caused trouble. Its basically imeadiate expansion, but from what I understand we parse multiple times, so the variable will change the value non the less Nov 25 16:03:31 JPEW: I'm wondering how to proceed. I could apply my patch (have an updated fixed version locally) and update the autobuilder server instance with it, then retest Nov 25 16:04:21 Ya, it's probably worth a try to see if it fixes the problem (if there are free cycles), but I'd like to keep thinking about it Nov 25 16:04:45 JPEW: Cycles are available for this, its key we get this fixed. Nov 25 16:05:01 JPEW: also a question of whether this is 3.0.1 material and we should delay that? Nov 25 16:05:14 * RP suspects not delaying is the right thing to do Nov 25 16:05:39 The hashes reported to the equiv server don't *have* to be taskhashes... would it be bad to include the host arch in the hashes reported for -native? Nov 25 16:06:20 RP: I don't think we should delay either Nov 25 16:06:32 JPEW: how would the arch help us? Nov 25 16:09:53 fray: just tried it, still the same issue... Not sure what's going on, but it feels as if PV behaves somewhat different Nov 25 16:12:01 When bitbake asks the server for an equivalent hash, it won't report the x86-native unihash for arm-native or vis-versa Nov 25 16:14:10 JPEW: that isn't the problem we have though, its the opposite Nov 25 16:15:29 The server should report the same unihash, but it isn't? Nov 25 16:16:47 JPEW: right. we need the same hash for meta-extsdk-toolchain regardless of whether gdb-cross was arm or x86 Nov 25 16:17:25 same taskhash, same unihash or both? Nov 25 16:19:43 RP, 3.0.1 should go and fix the hash issue afterwards Nov 25 16:20:07 RP, will this hash issue be a M1 blocker? Nov 25 16:21:23 armpit: yes, I think so for M1 and agreed on 3.0.1 Nov 25 16:23:49 Checking for unpackaged file(s): /data/poky-tmp/master/work/intel_corei7_64-poky-linux/packagegroup-core-boot/1.0-r17/recipe-sysroot-native/usr/bin/../../usr/lib/rpm/check-files /data/poky-tmp/master/work/intel_corei7_64-poky-linux/packagegroup-core-boot/1.0-r17/package Nov 25 16:23:49 Segmentation fault (core dumped) Nov 25 16:23:50 argh Nov 25 16:25:06 kanavin_: seen rpm crash like that? ^^^ Nov 25 16:32:12 rburton, nope Nov 25 16:32:17 bah Nov 25 16:34:50 ERROR: ParseError at ../meta-96boards/recipes-graphics/mesa/mesa-lima.inc:29: Could not inherit file classes/features_check.bbclass Nov 25 16:35:31 Does anyone something about it ^^^^ ? Nov 25 16:35:39 *know Nov 25 16:35:52 alessioigor: you've updated meta-96boards to master but not oe-core Nov 25 16:36:18 distro_features_check: expand with MACHINE_FEATURES and COMBINED_FEATURES, rename Nov 25 16:36:25 oe-core 5f4875b950ce199e91f99c8e945a0c709166dc14 Nov 25 16:37:12 if you're using a stable branch of oe-core then use the corresponding branch for meta-96boards, otherwise stuff like this happens Nov 25 16:38:18 rburton: meta-96boards doesn't provide zeus branch :-( Nov 25 16:38:28 alessioigor: tell them to, because they just broke zeus users Nov 25 16:38:51 should be trivial to find the patch which did the rename in meta-96boards and revert it locally until they add a zeus branch Nov 25 16:39:13 khem: ^^^^ Nov 25 16:39:18 rburton: Thanks for the tip! Nov 25 16:39:21 yeah its the top commit Nov 25 16:41:31 ndec: fyi meta-96boards is broken with zeus Nov 25 16:42:19 kergoth: you need to subscribe to yocto@ :) Nov 25 16:43:37 oh, huh, i never noticed i hadn't Nov 25 16:43:42 oops Nov 25 16:45:15 uhhh Nov 25 16:45:36 rburton: if i try to login, it says "That email address does not have a lists.yoctoproject.org account.". if i try to register, it says "That email address is already registered." Nov 25 16:45:39 i think it's confused. Nov 25 16:45:50 kergoth: nice Nov 25 16:46:06 well you're on the approved list now Nov 25 16:46:18 maybe halstead knows what its trying to say with those errors Nov 25 16:46:18 k, thanks Nov 25 16:46:29 rburton: broken how? Nov 25 16:46:42 * kergoth tries again Nov 25 16:47:11 nevermind, got i. halstead ignore that Nov 25 16:47:18 * kergoth yawns Nov 25 16:50:50 fray: hm, I think this causes problems: http://lists.openembedded.org/pipermail/openembedded-core/2016-July/242143.html Nov 25 16:54:32 Good morning. Glad that's sorted. Nov 25 16:55:46 RP: Ok, I think I understand the problem: We want the unihashes to look like this: https://docs.google.com/spreadsheets/d/1wicdc6rO67cxglRkORmKkP7nPxzWUNJX5tw5eIIer3o/edit?usp=sharing Nov 25 16:58:03 JPEW: yes Nov 25 16:58:29 JPEW: realistically that isn't possible so the equiv mapping gives the best way I can think of to establish it Nov 25 16:59:01 Right. Theortcially, if you can get the A:arm and A:x86 to match, B would fall in automatically Nov 25 16:59:22 JPEW: yes Nov 25 17:01:06 JPEW: although its actually the case we have D which depends on this task and its D we want the same unihash for Nov 25 17:01:35 the arch of D being irrelevant as its target, not native Nov 25 17:02:01 sagner, when ysing DATETIME, it does the current date and time at that exact momemnt.. thus you need VALUE := "${DATETIME}" because you need to evaluate it ONCE, or it will result in hash problems Nov 25 17:03:34 even then it can cause problems when files are reparsed, as they are when the tasks run.. Nov 25 17:03:56 fray, unfortunately I get basehash value changed even when using := Nov 25 17:04:36 Embedded a moving data/time stamp is never a good idea.. but that used to work at least.. Nov 25 17:05:05 you can define in your local.conf a data-time (using the :=) and then use that value in all of the recipes where it matters Nov 25 17:05:10 the key is it has to be evaluated only once Nov 25 17:07:39 RP: Ok, I filled in what I think the code currently does in the file, does that look correct? Nov 25 17:11:42 JPEW: I'm confused now. E2 should be B ? Nov 25 17:11:49 er, E3 Nov 25 17:12:35 and E7 should be D, not C Nov 25 17:13:45 RP - is there any documentation on how to use the hash equivalency stuff in Zeus/Master? I thought you posted something, but I'm failing to find it Nov 25 17:15:21 fray: look at local.conf.sample ? Nov 25 17:15:45 Fail, I didn't look there.. :P Nov 25 17:17:09 I thought you had to enable a bbclass to do the comparison though.. Nov 25 17:17:27 fray: no, all magic done behind the scenes Nov 25 17:18:10 ok, so I misunderstood that then.. ok Nov 25 17:18:45 How/where does it detect two hashes are actually the same and publish that to the server? Nov 25 17:19:22 fray: hook in sstate.bbclass which calls into the siggen Nov 25 17:19:45 default siggen handler is an empty function for the old sig hander. For hashequiv its not Nov 25 17:23:38 ok.. thanks Nov 25 17:31:59 JPEW: I added patches to -next for this Nov 25 17:33:07 ok.. so if I'm understand correctly.. the way it works is during initial parse, it contacts the server to see if there is an existing hash equivalence.. if there is, it uses it... if not it goes ahead and builds, then as it constructs sstate-caches, it checks for equivalency in output and marks a hash as equivalent if they come out the same, uploading that data to the server.. is that correct? Nov 25 17:51:21 fray: yes Nov 25 17:51:37 thanks.. that helps a bunch.. it was the second half I wasn't aware of before.. Nov 25 17:51:43 RP: ross/next is about to go green if you want to pick from that Nov 25 17:51:54 just a couple of bits left Nov 25 17:52:47 rburton: cool, will take a look Nov 25 17:53:46 rburton: thanks Nov 25 17:53:51 RP: don't pick the u-boot patch, alex has sent something that supercedes it Nov 25 17:54:21 pushing a revert to make that clear :) Nov 25 17:54:51 rburton: I'm already editing :) Nov 25 17:55:23 i'd base it on master-next but there's some of your HACK BREAK ALL THE THINGS patches in there ;) Nov 25 17:55:44 rburton: right, trying to get to the bottom of the problems Nov 25 17:56:23 rburton: parted missing S-o-b Nov 25 17:56:27 damnit Nov 25 17:56:44 feel free to drop that, there was more originally Nov 25 17:56:48 so relatd ... does packagefeed stability use any of the same components as the hash equivalency? Nov 25 17:57:14 fray: i'd say hash equiv is a prerequisitic for easy feed stability Nov 25 17:57:34 it moves the 'these binaries are the same' away from the feed and into the build Nov 25 17:57:47 so instead of building it all and throwing away the result, just don't build Nov 25 17:58:23 yes, I assumed they could both be used at the same time... Nov 25 17:58:53 rburton: pushed stuff. There are more patches in -next which are probably safe Nov 25 17:59:15 I'm in the process of writing up some guidelines for a binary distribution and I'm trying to remember all of the moving pieces. Nov 25 17:59:46 fray: hashequiv will definitely make a binary distro easier Nov 25 18:00:00 RP: Ok, it's order dependent. I left comments in the cells to explain the logic Nov 25 18:00:13 package stability, pr service, hash equivalency... the reproducible builds.. Nov 25 18:00:21 In the second example, it does what we want (by accident) Nov 25 18:00:25 Am I missing anything? Nov 25 18:01:10 fray: would we need package stability? Nov 25 18:01:36 yes, otherwise different builds of common tools could result in slightly different contents.. (i.e. the whole python internal hash thingy) Nov 25 18:01:56 'er.. wait that is the reproducible builds.. Nov 25 18:01:58 * fray backs up.. Nov 25 18:02:23 the package stability and pr service are linked AFAIK.. so I thought they the stability would still be desired with the hash equivalency Nov 25 18:02:38 JPEW: I think I understand now Nov 25 18:02:53 JPEW: I was misreading what you meant in there I think Nov 25 18:03:11 Ya, the important thing to remember is that the unihash defaults to the taskhash Nov 25 18:03:31 fray: I hope that you can just get away with hash equiv and prserv Nov 25 18:03:53 I was concerned that that could result in odd pr behavior but maybe not? Nov 25 18:03:55 RP: will do a build test here then fire another round on the AB Nov 25 18:04:01 fray: shouldn't Nov 25 18:04:41 RP the other thing we talked about before was a way to extend the buildhistory.. Based on some conversations from ELC-E, I want to implement ABI/API comparison using build history as the storage mechanism.. but I'd first need the extension support we talked about earlier in the year Nov 25 18:04:52 rburton: cool. Bonus marks for enabling reproducibile builds as default in poky but not hashequiv as a test build. THink that may be ready Nov 25 18:05:08 fray: right Nov 25 18:05:16 * RP -> afk, food Nov 25 18:05:47 fray: redhat have a nice abi comparison tool Nov 25 18:06:06 Eww, that first case is pathological :( Nov 25 18:07:15 yes.. I already know how to implement it.. Nov 25 18:07:25 (turns it I'm not sure it's actually Red Hat, but something Red Hat uses) Nov 25 18:07:48 the comparison parts of the tooling Fedora/RH use aren't nearly as useful to us as the dumping of the API and ABI info, and storage to the build history.. Nov 25 18:07:56 if that happens, then we can have our own comparison tooling.. Nov 25 18:08:00 the one i'm thinking of - the name of which i've forgotten - was written by an ex-colleague at RH Nov 25 18:08:03 (RP: dodji!) Nov 25 18:08:50 libabigail! Nov 25 18:08:52 that's the one Nov 25 18:11:32 rburton, is that Gaelic ? Nov 25 18:12:01 or one too many beers ? Nov 25 18:43:52 armpit: abigail is a name, and its an ABI tool, so i guess that's the derivation? Nov 25 18:45:24 RP: Ok, I think i have the server side fix Nov 25 18:45:55 Effectively does the same thing but probably more efficiently. I'll have to think about repercussions Nov 25 19:03:54 fray: I think I start to understand now: bitbake these days parses twice, once in the cooker and once in the worker. Even when using immediate expansion those two parse runs will result in different hashes and ultimately to the basehash value changed error message (this is what https://git.openembedded.org/bitbake/commit/?id=857829048c14338132784326ba98a71f12192db8&h=master explains nicely) Nov 25 19:04:25 fray: the only way out here is using vardepsexclude, however, this i broken for PV for two reasons: Nov 25 19:05:28 fray: 1. We use PV[vardepvalue] = "${PV}" in sstate.bbclass. Nov 25 19:06:06 was fray's suggestion to set it with := in local.conf or elsewhere in the config metadata and then use it in the recipe not viable? Nov 25 19:06:52 fray: 2. for tasks generated in IMAGE_CMD_x "localdata.setVar('PV', d.getVar('PV'))" is used in image.bbclass, which forces expansion Nov 25 19:07:09 kergoth: no, since PV will still change Nov 25 19:08:03 what's the purpose behind using the datetime stamp in the version at all? Nov 25 19:10:07 kergoth: we use the image's PV as version for a custom image format (since "package version" on the image sounds like a reasonable variable to reuse for this case...). This we do since quite a while, only recently we'd like to have a timestamp in the version. So that is why I started investigating Nov 25 19:11:07 kergoth: one option is to not use PV in our custom image format but some other variable. Nov 25 19:11:10 i'd suggest either emitting the stamp into a .conf that bitbake includes before running bitbake, so it's locked down before bitbake even starts, or use a different variable rather than PV Nov 25 19:14:10 kergoth: yeah that works for scripted CI jobs, where we already add build numbers. I was considering this for development, where it is sometimes hard to link a currently installed build from what is lying on my build machine when doing several cycles a day. So ideally it should be "OE built-in" functionality... Nov 25 19:15:30 kergoth: anyways, I think I will move away from using PV. Will also send an email to the mailing list as I haven't found anything about that topic (PV vs. DATETIME vs. vardepsexclude). Nov 25 19:16:22 * kergoth nods, sounds like a good plan, could arguably open a bug proposing a future enhancement to make this workflow easier in the future Nov 25 19:50:44 RP: Ok, I'm convinced that updating the hashes is the correct thing to do, but I think it will be much easier server side Nov 25 20:31:11 New news from stackoverflow: YOCTO Change kernel version and select drivers Nov 25 20:38:43 JPEW: My SQL in my patch is horrid ;-) Nov 25 20:39:51 JPEW: not sure you can do this totally server side since you need more information about the previous hash Nov 25 20:41:00 hi kergoth , something looks odd with your mailing list account. are you receiving emails? Nov 25 20:41:25 it's gmail, i highly doubt it's down :) Nov 25 20:41:47 i can see your mentor email address. Nov 25 20:41:59 set to 'no email' in the system. is that what you wanted/ Nov 25 20:42:13 your last message still needs to be moderated. Nov 25 20:43:23 i don't believe any of my patch emails were from my mentor address. they cc'd the mentor address, but weren't from it Nov 25 20:43:35 more likely i was just not subscribed to all the lists, i didn't check them all Nov 25 20:43:43 * kergoth shrugs Nov 25 20:43:54 catching up on my upstream submission backlog Nov 25 20:44:23 kergoth: hmm.. what email address do you expect to use on lists.yoctoproject.org (before the transition)? Nov 25 20:45:13 ah, i can see your gmail address.. and it's set to deliver emails. let me check what you subscribed to. Nov 25 20:45:23 the only address i use with lists.yoctoproject.org is kergoth@gmail Nov 25 20:46:00 well, there is one email from your mentor email sent a couple of hours ago, which is the moderated queue Nov 25 20:46:14 a reply to "[meta-intel][PATCH] thermald: fix the url" Nov 25 20:48:08 ah, that was unintentional, apparently Sparrow picked the wrong from address Nov 25 20:48:23 the reply was just saying to ignore that patch anyway, i sent it to the wrong list :) Nov 25 20:48:37 re-sent it to meta-intel@ Nov 25 20:49:09 ok, so i should delete that email, and i guess you mentor address as well? Nov 25 20:55:12 kergoth: is sparrow still around? Nov 25 20:59:33 er, i meant Spark, not sparrow. stopped using hte latter ages ago Nov 25 21:00:01 RP: I'll do some cleanup and documentation and post it up for review Nov 25 21:06:42 kergoth: can you let me /query you please, want to pick your brains for a moment Nov 25 21:12:11 JPEW: ok, curious how you plan to do it differently! Nov 25 21:45:47 armpit: I merged zeus. I've sneaked a couple of other bitbake fixes in ;-) Nov 25 22:49:42 * armpit looks Nov 25 22:52:09 ack Nov 25 22:52:26 thanks Nov 25 22:55:02 rp, what about the other changes core changes /me looks at merge request Nov 25 22:56:01 RP: my python 'clean up' patch is broken. or actually it's good, but its too good, and breaks packaging. Nov 25 22:56:30 did the other 8 not being accepted ? Nov 25 22:57:06 rburton, we don't want too good Nov 25 22:57:33 for some reason .pyo files are generated when they were not before, and they all end up in python-xml :) Nov 25 23:54:05 * armpit cool 5.4 dropped Nov 25 23:54:59 * armpit short eol **** ENDING LOGGING AT Tue Nov 26 02:59:57 2019