**** BEGIN LOGGING AT Fri Aug 16 03:05:29 2019 Aug 16 07:32:57 How you are testing your images without hardware? via `-c testimage`? There exists some other tools which are good to know to test images? Aug 16 08:26:37 RP: and with latest bitbake a5e084a266f63c2fd370122327615e49beaeb94e http://paste.ubuntu.com/p/YhMCHPmg56/ Aug 16 08:51:54 JaMa: thanks Aug 16 08:54:34 RP: now I'm running it with even older 18d4a31fdcec1f0e5d2199d6142f0ce833fca1a7 Aug 16 08:54:51 JaMa: http://paste.ubuntu.com/p/RMGbm9DyZz/ is quite interesting, the sorted() shows up badly Aug 16 08:55:22 and pformat Aug 16 08:56:12 18d4a31fdcec1f0e5d2199d6142f0ce833fca1a7 seems to be fine, it's already executing tasks Aug 16 08:57:03 JaMa: just to confirm, http://paste.ubuntu.com/p/RMGbm9DyZz/ was without the logger.debug removal? Aug 16 08:57:44 I think that sorted comes from part of pformat, going to need to be careful with that Aug 16 09:00:34 yes, http://paste.ubuntu.com/p/RMGbm9DyZz/ was 1f630fdf0260db08541d3ca9f25f852931c19905 without any modifications, it was supposed to be the "good old" baseline based on the times with old image, but it seems that this revision already regressed badly Aug 16 09:02:09 so it's something in 6 commits between 18d4a31 and 1f630fdf Aug 16 09:04:39 the later has the line logger.debug(2, "Holding off tasks %s" % pprint.pformat(self.holdoff_tasks)) Aug 16 09:10:03 JaMa: right, that line in particular performs terribly! :) Aug 16 09:20:15 RP: yes, I just thought that this was only in master-next at that time, not in master, will send an e-mail once last run with even older bitbake revision is uploaded to make it a bit clearer what is what Aug 16 09:21:53 RP: latest world build last night with latest bitbake shown some unexpected failures with missing native deps when building e.g. some node recipes, but maybe it wasn't caused by bitbake, will re-test Aug 16 09:25:54 JaMa: I'm not aware of deps going missing like that but there were various fixes made, this is partly why I've merged everything to master, so we all have a common test target with the known issues fixed Aug 16 09:59:30 hmm, python3 doesn't seem to build without readline (GPLv3) due to do_install check. Any hints how to make the test compatible with non-default PACKAGECONFIG which removes readline support? Aug 16 10:48:04 seems I really need to patch python3 recipe to remove check_build_completeness.py if I build without readline support Aug 16 10:51:49 RP: I've sent a change to the bitbake list that adds a progress meter for the part between "Initialising tasks" and "Checking sstate mirror object availability" where runqueue currently hangs for a while without any output. Aug 16 10:52:53 RP: So unless you can't make the delay introduced by that part of the code go away, this will at least make it obvious that something is happening. Aug 16 11:39:56 Saur: ok, but wrapping everything in more progress bars isn't really the answer... Aug 16 11:42:26 RP: Well, if the delay is unavoidable then the progressbar is needed to show that something is happening. But if you can find ways to make the delay go away, then that is of course even better. ;) Aug 16 11:42:46 Saur: I just hate progress bars Aug 16 11:43:31 RP: Well, I hate long periods of no output even more. Aug 16 11:47:24 Saur, welcome to my life Aug 16 11:48:04 I made a fake progress bar once, always fun when underlying thing crashed and kept showing progress Aug 16 11:48:50 Crofton|work: That sounds like the worst of both worlds... Aug 16 11:48:56 I follow progress with strace if things are taking too long. should have known about bitbake -P earlier and started debugging the sometimes long delays.. Aug 16 11:53:21 Saur: does the progress bar even increment properly with the way you've written that patch? Aug 16 11:53:34 RP: Yes it does. Aug 16 11:53:36 Saur: it looks to me like the increments are around the fast part of the code Aug 16 11:54:03 RP: "Properly" in the sense that it updates once per task. Aug 16 11:54:16 Saur: so it doesn't get quickly to say 95% then sit there? Aug 16 11:54:24 No. Aug 16 11:54:44 then there is something very wrong :( Aug 16 11:55:52 RP: Well, one thing I noticed was that nothing is ever added to tocheck (with the current state I have: some updated recipes and stuff). Aug 16 11:56:34 Because I first had the update at the end before I noticed the continue statements, and then the update event never fired. Aug 16 11:56:48 Saur: a clean build or an existing completed build? Aug 16 11:57:34 RP: A completed build that then have had a couple of layer updates that have not built as I've been using bitbake -n. Aug 16 11:58:06 Saur: tocheck should be added to for things it needs to check the sstate cache for Aug 16 12:00:10 Saur, I was told to do it :) So I did Aug 16 12:00:59 RP: Ok, it seems tocheck isn't completely empty. There are 24 entries in it for my current build. Aug 16 12:01:25 Saur: try it on an empty build and it will be much higher Aug 16 12:01:59 RP: I guess those 24 updates to the progress were so few compared to the 5600 tasks in total that the loop checks that i never saw the progress meter move. Aug 16 12:02:47 Saur: we need to fix the underlying code not to suck, this should be fast Aug 16 12:03:20 This is why I wanted to get correctness before looking at performance Aug 16 12:03:28 RP: I'll probably leave that part to you. ;) Aug 16 12:03:41 Now I'm trying to optimise code before its even working properly :( Aug 16 12:03:45 RP: Now you at least know where one of the delays are... Aug 16 12:05:21 RP: Btw, if I remove the tmp directory, that delay goes away. Aug 16 12:05:48 Saur: right, no stamps so that code does less Aug 16 12:11:37 Saur: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=9ab56f41b8785fb8e3ede91bbad9d094f4806e27 (top patch) might help Aug 16 12:14:45 Saur: if that doesn't make it fast enough there is another change we can try. Each one of these moves the goalposts on the other issues I'm trying to fix of course :/ Aug 16 12:21:12 RP: That change took the time for that part from 36 to 25 seconds for me. Aug 16 12:23:02 RP: And no, I do not expect you to focus on the performance at this time. As long as you are aware of the performance implications, make it work first. Aug 16 12:25:22 RP: Hmm, I no longer seem to have push rights to poky-contrib. Have something changed regarding it? Aug 16 12:26:16 (Haven't tried pushing to it for a couple of months so it is not necessarily recent.) Aug 16 12:26:21 Saur: ssh git@git.yoctoproject.org will show the perms Aug 16 12:26:39 Saur: don't think anything changed Aug 16 12:26:41 git@git.yoctoproject.org: Permission denied (publickey). Aug 16 12:27:09 Saur: sounds like the key isn't right :/ Aug 16 12:27:23 It does, doesn't it... Aug 16 12:32:55 Saur: you can try adding http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=1b5162b94c0b61317e547a3f881f569350aac0fb on top, see if that brings the time down further Aug 16 12:33:13 Saur: less sure about what that last one might break Aug 16 12:35:00 selftest says its ok Aug 16 12:37:56 RP: That brought the time down to 3 seconds, so yes if that still does what it is supposed to, then I guess that progress meter is no longer needed. :) Aug 16 12:38:19 Saur: it moves work around Aug 16 12:40:12 RP: Well, the lost 22 seconds didn't show up anywhere else at least as the total time decreased correspondingly. :) Aug 16 12:42:15 Saur: Its more a question of whether anything accesses those data structures while the data is out of date Aug 16 12:47:56 Looking at the updated profile, those two changes look to optimise most of the recent changes out the profile data Aug 16 13:05:37 RP: Here is the latest update. bitbake is now out of the picture. Aug 16 13:05:45 I duplicated the problem outside of bitbake. Aug 16 13:06:06 /glibc-locale/2.28-r0/locale-tree% ls -d usr/lib64/locale/*.ISO* |xargs rm -rf ; make -j128 Aug 16 13:06:55 What ever the cross-localedef is doing is not safe to run in a massively parallel context. Aug 16 13:07:41 Because it is moving files from a .tmp -> real and or hard link, stuff is disappearing that is actually needed. Aug 16 13:08:01 I can probably run it without pseudo at all to rule pseudo out. Aug 16 13:08:53 It will require quite a bit of further analysis, but at least we know conclusively all the bitbake/oe and such is out of the picture. Aug 16 13:13:01 these 5.2 libc-headers are going to make me insane Aug 16 13:13:05 * zeddii goes for coffee Aug 16 13:28:25 coffee worked. bluez5 is building again. Aug 16 13:50:43 hello folk Aug 16 13:51:03 is it OK to query the value of DEBUG_BUILD in a recipe, and pass some package Makefile specific flag depending on it? Aug 16 13:51:46 I.e DEBUG_BUILD ?= "0" MyDebugFlag = "${DEBUG_BUILD}" ?. In the docs, it'ss said that DEBUG_BUILD is used to specify that yocto should build packages with debug information Aug 16 13:53:59 jwessel: cool, always good to narrow down the issue! :) Aug 16 13:54:49 heh... I already found the offending code in the cross-localedef Aug 16 13:55:03 I don't exactly know how to fix it yet, but I see why it is clearly not parallel safe. Aug 16 13:55:21 The code is written to assume hard links might not work. Aug 16 13:55:52 And it will unlink a file, which could be in the process of being tested and used by one of the other parallel treads. Aug 16 13:56:16 If you were to run this serially with just a single cross-localedef there is no way to hit that problem. Aug 16 13:56:36 It replaces the file with a hard link when they test out to be the same. Aug 16 13:57:04 the original use of cross-localedef was serial... Aug 16 13:57:26 So if you go back to that, the problem is solved. Aug 16 13:58:17 Or change cross-localedef to not be stupid and allow --force-hard links and write out a .tmp file to perform the test. Aug 16 13:58:33 serial is very very slow so hacking localedef would be better Aug 16 13:58:36 Testing against a file that might go-away for a fraction of a second will not end well. Aug 16 13:58:47 jwessel: no, it explains alot Aug 16 13:59:02 ya, that's why it moved to parallel.. but ya, definitely a race to check and then act.. Aug 16 13:59:13 I have no reason to believe that pseudo is the issue here. Aug 16 13:59:42 I'd say at this point we have the root cause. Aug 16 14:00:04 ya.. I agree, sounds more like fix the issue first.. :) Aug 16 14:00:44 other systems BTW do the hard linking in two steps.. one step to generate all of the files, then a second to hash them and set them as parallel Aug 16 14:00:56 It was mighty interesting to have a log though in pseudo for a place in the code that should never happen. Aug 16 14:01:03 We might consider keeping that change. Aug 16 14:01:25 'er.. set them as hardlinks I mean Aug 16 14:01:31 Because it tells you... "You really screwed up somewhere else..." Aug 16 14:02:47 fray: You might have to do just that. Aug 16 14:03:38 if I remember right (like 18 years ago right) that is what was being done.. then it was merged into a single program.. Aug 16 14:03:53 the origin of the cross-localedef is either MontaVista or CodeSourcery.. it's -old- Aug 16 14:05:19 Looks liek CodeSourcery Aug 16 14:05:19 + Cross-Compiling GLIBC Aug 16 14:05:19 + Jim Blandy Aug 16 14:05:34 Perform generation, and then coalesce Aug 16 14:05:39 ya Aug 16 14:06:09 Does the generation even support skipping the combine step? Aug 16 14:06:11 I knew it was old though, far pre-YP Aug 16 14:06:27 Because there are other programs that can combine stuff. Aug 16 14:06:42 Ya, looking at Khem's repo.. 2006 or before.. :) Aug 16 14:06:48 I know the first version was before.. :) Aug 16 14:07:03 the original version of the code didnt do the hardlink stuff.. Aug 16 14:07:15 we (WR) paid CodeSourcery to do that back in 2007/2008 timeframe? Aug 16 14:07:38 (not saying they wouldn't have done it on their own or someone else didn't pay them as well...) Aug 16 14:07:53 I just remember having that discussion with them as a system optimization Aug 16 14:09:13 (probably was before 2007 now that I think of it.. probably closer to 2005/2006 Aug 16 14:09:51 /* Compare the file with the locale data files for the same category in Aug 16 14:09:51 other locales, and see if we can reuse it, to save disk space. */ Aug 16 14:09:51 other_paths = siblings (output_path); Aug 16 14:10:07 FYI that is what kills you in the parallel case. Aug 16 14:10:25 Those other ones may in the act of being processed. Aug 16 14:11:04 ya.. I think 'easiest' to implement fix is break into two steps.. generate (& hash?) and (hash &) hardlink (not sure where the hashing should be done, but it can be done in parallel) Aug 16 14:11:09 Which is 100% the reason it could be unlinked and replaced with a hard link while someone else is executing. Aug 16 14:11:12 so maybe three steps? Aug 16 14:11:21 You don't necessarily have to. Aug 16 14:11:43 But it would be the best way to do it. Aug 16 14:13:50 The problem even with the current code is that since all these are running in parallel you really won't get the right number of hard links ever. Aug 16 14:15:03 there is the '--no-hard-links' option in locale generation.. enable that and do the hardlinks later? Aug 16 14:15:21 I was advocating adding one. Aug 16 14:15:25 Ohh ok Aug 16 14:15:32 It won't work though due to the problem I just mentioned. Aug 16 14:15:49 If you are generating these all in parallel some will simply be generating at the same time. Aug 16 14:16:04 the no-hard-links commit mentions: Aug 16 14:16:08 You can't check the existence of something that isn't there yet. Aug 16 14:16:15 Add --no-hard-links option to localedef (bug 23923) Aug 16 14:16:15 Aug 16 14:16:15 Downstream distributions need consistent sets of hardlinks in Aug 16 14:16:15 order for rpm to operate effectively. This means that even if Aug 16 14:16:15 locales are built with a high level of parallelism that the Aug 16 14:16:15 resulting files need to have consistent hardlink counts. The only Aug 16 14:16:15 way to achieve this is with a post-install hardlink pass using a Aug 16 14:16:15 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=23923 was not found. Aug 16 14:16:16 program like 'hardlink' (shipped in Fedora). Aug 16 14:16:38 Correct. Aug 16 14:16:40 so it might even be helpful to break it in two for determinism sake Aug 16 14:17:21 But why bother doing the summing and checking in cross-localedef? Aug 16 14:17:39 You can do the hardlink pass outside of pseudo if you want. Aug 16 14:17:58 psuedo will be happy so long as the inode had created was preserved. Aug 16 14:17:59 Has to be done under control of pseudo or the DB will get messed up.. Aug 16 14:18:02 For at least one file. Aug 16 14:18:17 Not really. Not the way it works... Because I read the code :-) Aug 16 14:18:22 that wasn't always true.. at one point it was a combo of inode and filename Aug 16 14:18:36 I suspect fakeroot still works based on filename.. (at least it also used to) Aug 16 14:18:49 fakeroot yes. pseudo is fine. Aug 16 14:19:01 I don't know what the timepenalty is for the hardlink Aug 16 14:19:14 I'd still be cautious and do the hard linking under pseudo.. Aug 16 14:19:38 We used 'hardlink' in the past for something, and I remember it being fast.. but I don't completely remember how it worked.. Aug 16 14:22:10 locale-tree% hardlink -n usr/lib64/locale Aug 16 14:22:10 Mode: dry-run Aug 16 14:22:10 Files: 4919 Aug 16 14:22:10 Linked: 389 files Aug 16 14:22:26 So we missed 389 files in my sample run. Aug 16 14:22:44 Just to prove my point :-) Aug 16 14:23:23 I'd say we just add a fast exit on the checks in localedef either via cmdline arg or environment variable. Aug 16 14:23:24 looks like hardlink might be part of util-linux now (or at least is on Fedora) Aug 16 14:23:42 that's what the --no-hard-links is supposed to do.. fast exit Aug 16 14:23:47 or am I missing something? Aug 16 14:24:00 lets look... I didn't see that option. Aug 16 14:24:24 commit 8cebd4ffe67bf94508809ea0caa02a4f1d52e8b1 Aug 16 14:24:29 (in glibc of course) Aug 16 14:24:55 + if (hard_links) Aug 16 14:24:55 + other_paths = siblings (output_path); Aug 16 14:25:07 otherwise it skips that whole section of code Aug 16 14:25:10 That is not in the version I have. Aug 16 14:25:21 That is what I was considering adding. Aug 16 14:25:23 Date: Mon Nov 26 09:51:51 2018 -0500 Aug 16 14:25:29 I'm looking at master Aug 16 14:25:33 glibc 2.30 Aug 16 14:25:46 commit 8cebd4ffe67bf94508809ea0caa02a4f1d52e8b1 Aug 16 14:25:46 Author: Carlos O'Donell Aug 16 14:25:46 Date: Mon Nov 26 09:51:51 2018 -0500 Aug 16 14:25:46 Add --no-hard-links option to localedef (bug 23923) Aug 16 14:25:47 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=23923 was not found. Aug 16 14:25:50 I am on thud glibc-2.28 Aug 16 14:25:55 Which is why I don't have it. Aug 16 14:26:08 ya, too old.. you'd need to backport it.. but the commit is -simple- Aug 16 14:26:13 it's not YP bugzilla this is upstream glibc Aug 16 14:26:17 All you need to do, to make this problem go away is use that option + the hardlink program. Aug 16 14:26:18 look at the glibc bugzilla Aug 16 14:26:36 I just don't know if 'hardlink' is now standard or not Aug 16 14:26:37 Then your mystery localedef issue is fixed :-) Aug 16 14:26:46 (on non-Fedora/RH based systems) Aug 16 14:26:59 It is on ubuntu, if you install it. Aug 16 14:27:07 Ubuntu 18.04 does NOT have hardlink Aug 16 14:27:08 It will have to go into host-native. Aug 16 14:27:20 ok.. so it's optional there.. Aug 16 14:27:25 % cat /etc/issue Aug 16 14:27:25 Ubuntu 18.04.2 LTS \n \l Aug 16 14:27:28 ya.. sounds like a host-native... Aug 16 14:27:29 It is optional. Aug 16 14:27:52 I shudder to think how far we have to back port, but I assume we need to at least fix thud. Aug 16 14:27:55 Fedora claims it's part of util-linux, but I don't know if it's 'real' util-linux or Fedora's version Aug 16 14:28:03 yes.. we need to at least fix thud.. Aug 16 14:28:13 I'd say fix master first, make that work and backport to warrior and thud Aug 16 14:28:21 since we now know the problem is common Aug 16 14:28:41 (and at least master has a partial fix already implemented from upstream, warrior probably does?) Aug 16 14:28:52 The generation should be faster with the checking gutted too. Aug 16 14:29:16 That code was _really_ not efficient, or parallel safe. Aug 16 14:30:15 so the 'hard part' is getting 'hardlink' (or finding something equivalent) Aug 16 14:31:11 http://jak-linux.org/projects/hardlink/ Aug 16 14:31:40 I would just use what works. Aug 16 14:31:47 If that works Aug 16 14:31:57 I was looking at the Fedora version.. and it went 'away' Aug 16 14:32:02 Ubuntu used 0.2.0 the 14.04 release. Aug 16 14:32:08 https://src.fedoraproject.org/rpms/hardlink/c/6f80279847fc132377e1110b57360358c2920b07?branch=master Aug 16 14:32:14 0.3 is the latest. Aug 16 14:32:54 jwessel: nice to finally have some answers, nice work! Aug 16 14:32:55 Fedora's version was 1.3 Aug 16 14:32:56 That site states fedora has a different version. Aug 16 14:33:06 It is different code. Aug 16 14:33:11 removed in Feb of this year I think.. Aug 16 14:33:17 ok Aug 16 14:33:26 I suspect there are other programs that do the same thing. Aug 16 14:33:37 hardlink from the jak linux just works. Aug 16 14:34:05 https://pagure.io/hardlink/blob/master/f/hardlink.c Aug 16 14:34:10 that appears to be the latest version Aug 16 14:35:16 Makes no difference to me where we get it from. Aug 16 14:35:26 I am just happy we don't have to fix pseudo. Aug 16 14:35:55 I did just verify.. util-linux-2.34 includes 'hardlink' Aug 16 14:36:21 version included looks like it's the Red Hat version.. (or at least a refactored one) Aug 16 14:36:22 https://paste.fedoraproject.org/paste/rnsbsvEHQbH9iVrc0A-fOg Aug 16 14:36:45 this just started showing up when building this image. i have no idea why Aug 16 14:36:52 clues would be appreciated Aug 16 14:37:30 the image was building fine a week or two ago.. Aug 16 14:37:39 not sure.. pyro is pretty old so it might justbe a simple bug Aug 16 14:38:20 I'd simply start with rebuilding (clean and build) the locale's Aug 16 14:38:32 fray: are you talking to me? Aug 16 14:39:27 yes Aug 16 14:39:46 fray, jwessel: please keep in mind that adding a util-linux-native depends to glibc-locale would be pretty bad for build performance Aug 16 14:40:01 If there is a python script we can use it would be much more efficient Aug 16 14:40:29 * RP finally figures out the one line fix bitbake needs :/ Aug 16 14:40:43 I'm more thinking we add just 'hardlink' until a time comes when all of the regular hosts have updated to more modern util-linux Aug 16 14:40:55 hardlink itself is very small.. 430 something lines Aug 16 14:41:04 fray: right, fine by me Aug 16 14:41:41 but with that said, re-implementing those 430 lines in python should be possible, just don't know the performance impact Aug 16 14:42:20 this isn't rocket science.. it basically parses the filesystem and checksums everything into a linked list.. with the items inode, device, checksum and filename.. Aug 16 14:42:35 it searches that list for the device and checksum, and if they are the same then hardlinks Aug 16 14:42:46 if item is unknown it adds to the data structure and moves on to the next file Aug 16 14:43:37 fray: we already do similar kinds of things elsewhere, its trivial in python Aug 16 14:44:44 looks like the hardest thing in the code is there is something that if the file is in-use it renames it and removes it when it hardlinks to keep the old file alive.. Aug 16 14:44:50 that shouldn't be a problem Aug 16 14:44:50 http://git.yoctoproject.org/cgit.cgi/poky-contrib/patch/?id=6e19aa62ad8d0d1ded272690d21186d95743bb00 - so simple yet problematic Aug 16 14:45:51 RP is there exisitng oe code that does checksum and hardlink behavior or would this be a new lib/oe function? Aug 16 14:46:41 (I know we have copy or hardlink functions) Aug 16 14:47:50 Dude... Don't do it python. Aug 16 14:48:06 Use the C one. It is faster than python is ever going to be. Aug 16 14:48:33 but it' one more thing to compile and support that's my only concern Aug 16 14:49:01 How is it any better than having to compile cross-localedef Aug 16 14:49:04 and for the python it would run in the native bitbake context, not execute 'another thing'.. (conceptually) Aug 16 14:49:08 If anything add it in there. Aug 16 14:49:12 cause that is existing Aug 16 14:49:32 either we have to add a new native recipe for hardlink itself (which may someday go away) or we implement it as a library function Aug 16 14:49:47 either way will work -- but it moves around support items Aug 16 14:50:09 jwessel: I suspect there isn't that much difference C to python for this... Aug 16 14:50:12 builing native-util-linux is too big and has been avoided for a long time Aug 16 14:50:13 https://code.google.com/archive/p/hardlinkpy/ Aug 16 14:50:20 That is the code you are looking for btw. Aug 16 14:51:41 jwessel: I say this as someone who thought bitbake in C might be faster, once. Aug 16 14:53:09 I guess that older version is not python 3 compliant. Aug 16 14:53:17 It says to run 2to3 on it... Aug 16 14:53:18 JPEW: I had to drop the extra stats code, it was causing the autobuilder to lock up :( Aug 16 14:53:24 that python one looks like it doesn't hash once and store, but instead compares each time Aug 16 14:53:30 that's going to be less efficient then hash and store Aug 16 14:53:42 yes, but that is just bad design Aug 16 14:53:48 (not python per se) Aug 16 14:54:43 I'd be inclined to just add the c file to the cross-localedef package. Aug 16 14:54:55 the modern 'hardlink' have two hash points.. one based on size, owner, group, mode.. and then one based on content.. Aug 16 14:55:04 The c file does exactly what is needed, and you have to compile the cross-localedef anyway. Aug 16 14:55:09 since if the first hash doesn't match, you can skip the second (kind of)... Aug 16 14:55:12 Just name it cross-localedef-hardlink. Aug 16 14:55:26 then if you find a match in the first, you have to hash them both to compare -- but then youc an cache those for the future.. Aug 16 14:55:26 The modern one is much more effecient. Aug 16 14:55:38 yes.. adding it to cross-localdef is fine Aug 16 14:55:53 (least in my opinion) key is to be careful that it's efficient in what it's doing Aug 16 14:55:56 Take the path of least resistance, call it a day. Aug 16 14:56:52 I'd take the util-linux (modern) hardlink, and put it into cross-localdef for now.. it'd be the easiest to maintain.. (I think) Aug 16 14:56:53 right Aug 16 14:57:04 You'll spend time debugging and porting it to python otherwise. I am saying you can't make it portable etc... but why bother. The hardlink compiles on everything. Aug 16 14:57:39 oops. I meant you can make it portable with python, but I don't believe the effort is worth it. Aug 16 14:57:50 I was working on the assumption there is a sane python version around which there isn't Aug 16 14:58:06 if we can get a C version and use that, fine Aug 16 14:59:11 You might as well just stick it in cross-localedef. No new package etc... Don't know if the license is compatible. Aug 16 14:59:15 Didn't look at that bit. Aug 16 14:59:39 it's GPLv2 so should be fine.. Aug 16 14:59:48 (latest util-linux version) Aug 16 15:00:24 https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/tree/misc-utils/hardlink.1 Aug 16 15:00:35 https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/tree/misc-utils/hardlink.c Aug 16 15:00:37 'er.. ya .c not .1 Aug 16 15:01:15 #include "c.h" Aug 16 15:01:16 #include "xalloc.h" Aug 16 15:01:16 #include "nls.h" Aug 16 15:01:16 #include "closestream.h" Aug 16 15:01:27 that bit might need to be ported or hacked aorund.. but otherwise it looks entirely standard Aug 16 15:02:06 (and I don't see any reason to build it with the PCRE support which is newer then the old standalone version) Aug 16 15:02:44 khem: I've sent one more RDEPENDS fix which might look like duplicate, but it's for another package in scsirastools Aug 16 15:02:59 removing tmp and rebuilding got rid of that Aug 16 15:03:19 khem: feel free to squash them if you want, It was detected in follow-up builds, that's the only reason why I haven't put both in first commit Aug 16 15:30:53 JaMa:yes queued up Aug 16 15:31:45 JaMa: the gcc problem you are seeing, whats best way to reproduce it, does it only happen with multilib builds Aug 16 15:33:13 JaMa:https://errors.yoctoproject.org/Errors/Build/86953/ was the full build where these qa errors are listed Aug 16 15:33:29 hoping your series will fix most if not all of them Aug 16 15:39:06 khem: I've fixed all which I was seeing in my builds Aug 16 15:39:27 ok Aug 16 15:40:02 didn't you realize I was hinting you to fix mine too :) Aug 16 15:40:20 e.g. hplip shown in ours is blacklisted in all our builds, because needs lp group which we don't have Aug 16 15:40:38 wasn't alex going to fix them? :) Aug 16 15:40:38 I see Aug 16 15:42:08 and mime-construct burn-boot libextutils-parsexs-perl webmin recipes aren't in my world Aug 16 15:43:00 will check the gomp issue on some non-multilib config soon Aug 16 15:58:17 ok Aug 16 15:58:44 I will report the results and see if Alex helps Aug 16 16:31:17 RP: maybe I'm reading the profile badly, but to me it looks like worker thread was waiting in select most of the time and then finished executing tasks relatively quickly Aug 16 16:31:59 e.g. latest builds shows 4082.736 seconds in main process, 3977.939 seconds in worker and Aug 16 16:32:09 877733 3294.319 0.004 3294.319 0.004 {built-in method select.select} Aug 16 16:32:18 58394 366.063 0.006 366.063 0.006 {built-in method posix.fork} Aug 16 16:32:31 58394 6.290 0.000 493.595 0.008 bitbake/bin/bitbake-worker:431(handle_runtask) Aug 16 16:33:35 if it was handling tasks for 8 minutes from 68, then it seems reasonable Aug 16 16:36:10 khem: the omp.h issue is reproducible without multilib as well, should I try it without 9.2.0 upgrade or is it definitely the gcc-runtime change? (I belive it is) Aug 16 16:43:59 JaMa: you read that correctly, it does spend most of its time waiting Aug 16 16:44:08 JaMa: turnaround time for tasks is important too though Aug 16 16:45:15 Rewrite bitbake in go Aug 16 16:45:54 rewrite go in bitbake Aug 16 16:48:23 even better Aug 16 16:57:02 we just add the new sentience module to bitbake and make it self hosting... Aug 16 17:01:45 The hardlink program takes 2.3 seconds in pseudo context, and .7 seconds outside of pseudo. Aug 16 17:02:12 That is still way faster than what it takes for the cross-localedef Aug 16 17:03:49 jwessel: that is a nice win! Aug 16 17:04:17 * RP -> away (most of the weekend to) Aug 16 17:06:59 Would more machine learning help? Aug 16 17:17:14 I wonder what the bugzilla id is for the glibc-locale issue. Aug 16 17:17:26 jwessel: https://bugzilla.yoctoproject.org/show_bug.cgi?id=12434#c48 Aug 16 17:17:27 Bug 12434: normal, Medium+, 2.8 M3, randy.macleod, ACCEPTED , pseudo: Incorrect UID/GID in packaged files Aug 16 17:17:42 Thanks. Aug 16 17:18:16 I am testing a fix for it. Aug 16 17:18:35 I'll send it out as an RFC, since it is kind of ugly looking. Aug 16 17:18:37 cool, let me know if you want me to test it as well Aug 16 17:18:48 For sure, we'll need it tested. Aug 16 17:18:50 pseudo standard :) Aug 16 17:19:30 I'll have to forward port it when I am done because I did all the work on thud, where I am stuck at the moment. Aug 16 17:28:16 JaMa:I have a fix that I am testing Aug 16 17:41:57 khem: that was quick! thanks will include it in next world build Aug 16 17:44:33 khem: btw for those gcc patches it would be useful to use "git format-patch --no-signature --no-numbered" when refreshing them for new version (like devtool does now) Aug 16 17:46:04 anyone hiding bullet3 or netpbm recipes from layerindex? Aug 16 17:49:20 JaMa: thats a good idea, it has bothered me a bit but not enough Aug 16 17:50:11 I keep a local fork for these patches Aug 16 17:50:20 and devtool workflow does not fit in there Aug 16 18:07:51 khem: understood, I use the same e.g. with qt* patches, I've noticed only because when replacing 9.2.0 v1 with v2 there were much more changes than expected just because many patches were re-numbered after removal of one and then the include path change changed the git signature as well :) Aug 16 18:26:45 RP: Strange that the stat code caused lockups. Aug 16 19:06:06 can i put INITRAMFS_IMAGE somewhere other than build/conf/local.conf? Aug 16 19:16:12 mischief: yup! I have INITRAMFS_IMAGE defined in a distro conf file in my layer. I'm guessing you could define INITRAMFS_IMAGE in an image recipe as well, but I've never tried it. I would definitely appreciate another perspective on that possibility. Aug 16 19:17:20 we're starting to use yocto with pretty much 0 experience, so i'm sure i've done something wrong Aug 16 19:17:49 i made a directory for TEMPLATECONF and that is checked into git but build/conf/local.conf is not in git, where INITRAMFS_IMAGE is currently defined Aug 16 19:18:17 robbawebba: do you have something i can read about making distro layers/confs? Aug 16 19:18:59 mischief: sure! give me a few minutes to find the right links Aug 16 19:19:29 thank you.. i've asked a few questions here previously but you are the first to answer any of them :-) Aug 16 19:22:08 mischief: This entire section, section 7.1, contains tons of information on how to create and manage layers. Please let me know if you have any other questions! Aug 16 19:22:12 https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#understanding-and-creating-layers Aug 16 19:23:32 I'll try and find info on Distros next, but you'll need a layer before you create a custom distro :) so the layer stuff should keep you busy in the meantime Aug 16 19:24:48 right now we have a git repo with meta-$COMPANY with basically just our kernel recipe, and poky as a submodule. not sure if this is right but i've been able to make at least a kernel build. Aug 16 19:26:13 so i guess we have one layer. Aug 16 19:26:14 mischief: nice! That's essentially a layer. Did you add that meta-$COMPANY to your build/conf/bblayers.conf file, either manually or using the bitbake-layers tool? Aug 16 19:26:26 also, here's the distro documentation: https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#creating-your-own-distribution Aug 16 19:26:28 yes Aug 16 19:26:36 cool! Then you have a layer :) Aug 16 19:26:47 i put that in meta-$COMPANY/conf/bblayers.conf.sample Aug 16 19:27:24 so unfortunately if i modify it in build/conf then it is not tracked in git.. but if i modify bblayers.conf.sample it would require a user to re-initialize build/conf, correct? Aug 16 19:28:04 yup! Aug 16 19:29:17 is there no better way to track build/conf changes in revision control? Aug 16 19:29:23 (i.e, for INITRAMFS_IMAGE) Aug 16 19:29:41 and as long as the command `bitbake-layers show-layers` command shows your layer, then your're good! Plus, you mentioned that you're able to build your kernel recipe that's in your layer, so that's another sign that bitbake can find your layer Aug 16 19:30:01 and yes, there are a couple of options, the TEMPLATECONF mechanism is one that you already mentioned Aug 16 19:31:24 would it be a Bad Idea (tm) to just put build/conf/*.conf in the git repo? Aug 16 19:32:22 yup, I believe it is not a good practice Aug 16 19:32:35 I'm pretty sure that would be awful :) Aug 16 19:33:08 mischief: are you aware that you can put local.conf.sample in your layer, just like bblayers.conf.sample? Aug 16 19:33:23 robbawebba: that is currently what i am doing Aug 16 19:33:44 https://github.com/balister/meta-sdr/tree/master/conf Aug 16 19:33:57 but my concern is that if i change a variable and commit that to git, other developers would not see it unless they re-initialize build/conf from TEMPLATECONF. Aug 16 19:34:19 good concern Aug 16 19:34:29 auto.conf and site.conf are also searched Aug 16 19:34:34 in the BBPATH Aug 16 19:34:55 https://github.com/balister/meta-sdr/blob/master/conf/bblayers.conf.sample#L5 Aug 16 19:35:12 I use that so all build on one machine check .oe in my home dir Aug 16 19:35:30 and I can insert something like site.conf where I might point to a local source mirros Aug 16 19:37:27 some of my coworkers are going to embedded linux conference and now i am somewhat regretting not attending ._. Aug 16 19:37:41 as well you should Aug 16 19:37:53 well I am not going either, but I will be at ELCE Aug 16 19:38:09 Crofton|work: nice! So mischief can just add site.conf to his layer's conf directory and check those configuration options into version control? Aug 16 19:38:48 with careful tweaking of BBPATH Aug 16 19:39:05 my BBPATH is just $TOPDIR Aug 16 19:39:10 and use custom distro.conf also Aug 16 19:39:38 https://github.com/balister/sdr-build Aug 16 19:39:53 do something like this and have actual content with conf files also Aug 16 19:40:11 you want to split things that imapct product from things that are truly local Aug 16 19:40:19 like local source irrors, DL_DIR etc Aug 16 19:40:33 yes I ahve screwed up having important stuff in local.conf Aug 16 19:41:04 Crofton|work: currently we have just one git repo containing meta-$COMPANY/{conf,recipes-*} and poky/ as a submodule Aug 16 19:43:25 personally, I do what I do and drop the meta-poky stuff and use your own distro.conf Aug 16 19:43:30 and keep the settings there Aug 16 19:43:41 depending on what they are of course Aug 16 19:43:51 and we are sorry this is really well spelt out for people Aug 16 19:44:39 i'm not sure my skill level with this stuff is high enough to jump the boat on poky just yet :-) Aug 16 19:45:08 you are asking the questions that suggest you are there Aug 16 19:45:38 You are basically changing stuff set in poky.conf? Aug 16 19:45:49 * Crofton|work has never used poky :) Aug 16 19:47:03 creating a distro .conf is not difficult. cp poky.conf to your own, go Aug 16 19:47:03 i see, you are suggesting removing meta-poky layer from layers.conf? i thought you meant remove the poky/ submodule from my git repo :s Aug 16 20:02:17 New news from stackoverflow: Yacto/BitBake new dir does not show up Aug 16 20:53:56 <__angelo> in a machine.conf, is the field "#@SOC:" used for any special purpose or it's just a comment ? Aug 16 20:59:24 mischief: in conf/ dir you can create a site.conf file and put your customizations in that file Aug 16 20:59:47 __angelo:I think linux yocto uses it Aug 16 21:00:03 i mean linux-yocto kernel recipe Aug 16 21:00:28 <__angelo> khem, ok. mmm i have a linux-mystuff recipe Aug 16 21:00:41 then it wont bother you Aug 16 21:02:40 <__angelo> khem, thanks !รน Aug 16 21:03:09 Crofton|work and mischief take a look here https://github.com/YoeDistro/yoe-distro Aug 16 21:05:23 thats one way to solve it Aug 16 21:07:21 I put the RFC patch set out there to solve the glibc-locale issue. Aug 16 21:09:31 We could certainly benefit from some testing on it for those who were most affected by this issue. Aug 16 21:09:31 I only saw it once, myself. But our automated build cluster would have a number of failures each week. Aug 16 21:09:51 There could be other corner cases, but they will certainly not be the same as the one the patch set corrects. Aug 16 21:10:44 JPEW: I don't understand it. We also have a small race with the hash reporting and the generation of the sstate package. I think the latter is lagging the former and leading to a race :/ Aug 16 21:11:00 jwessel:cool.. pointer ? Aug 16 21:11:38 RP: That... shouldn't be possible? Aug 16 21:11:39 [OE-core] [RFC PATCH 1/2] cross-localedef-native: Add hardlink resolver from util-linux Aug 16 21:12:08 It is a two patch set with some explanation about the problem, but not about how it was tracked down. Aug 16 21:12:09 RP: Unless we are thinking of different things Aug 16 21:12:42 I had to use a modified version of pseudo, which I'd likely use in the future, if we have other such problems. Aug 16 21:13:21 jwessel: I think this may be related to all of: https://bugzilla.yoctoproject.org/show_bug.cgi?id=11551 https://bugzilla.yoctoproject.org/show_bug.cgi?id=11299 https://bugzilla.yoctoproject.org/show_bug.cgi?id=12664 https://bugzilla.yoctoproject.org/show_bug.cgi?id=12434 Aug 16 21:13:24 Bug 11551: normal, Medium+, 2.99, ross.burton, NEW , inconsistent dependencies in glibc-locale packages Aug 16 21:13:25 Bug 11299: normal, Medium+, 3.1, Qi.Chen, NEW , glibc-locale warning [host-user-contaminated] Aug 16 21:13:26 Bug 12664: normal, Medium+, 2.8 M4, ross.burton, NEW , glibc-binary-localedata packages may contain .tmp files Aug 16 21:13:27 Bug 12434: normal, Medium+, 2.8 M3, randy.macleod, ACCEPTED , pseudo: Incorrect UID/GID in packaged files Aug 16 21:14:31 JPEW: https://autobuilder.yoctoproject.org/typhoon/#/builders/97/builds/282/steps/8/logs/step1b is interesting. There is obviously a bitbake problem with the rebuild of encodings but why wasn't it in sstate? Aug 16 21:14:40 I don't doubt there are a number of cases to reference for this particular problem. Aug 16 21:14:59 jwessel: the .tmp thing in particular in hindsight is a smoking gun Aug 16 21:15:22 I don't think I ever saw a build with .tmp files though. Aug 16 21:15:39 Something really had to go wrong to have that happen. Aug 16 21:15:54 But given the nature of the race. It is probably possible. Aug 16 21:15:55 jwessel: there were references to X.tmp files in that log you shared weren't there? Aug 16 21:16:11 Sure but that is the mechanics of how the linkage works. Aug 16 21:16:32 jwessel: I suspect somehow that leaks. Perhaps this doesn't solve it, not sure Aug 16 21:16:41 Oh it solves it. Aug 16 21:16:51 There are no more .tmp files at all with this change. Aug 16 21:17:01 I can see how a tmp file could have leaked. Aug 16 21:17:13 jwessel: right. We've only seen that .tmp thing on very few occasions Aug 16 21:17:44 The timing window on that one was way smaller for failure, than promoting the link to a file. Aug 16 21:17:49 Which was happening in ever single build. Aug 16 21:17:55 We just didn't know it. Aug 16 21:18:35 If I put some sleeps right after the unlink. You can make it explode into flames easily. Aug 16 21:19:04 RP: How many AB nodes are hitting the hash server at the same time? Aug 16 21:19:26 But there is no point anymore. This is a concise type of failure, with a number of different symptoms. Aug 16 21:19:36 RP: ^ I'm trying to see if I can get the timeouts to reproduce locally Aug 16 21:20:08 I do think we should consider patching pseudo a bit to have the special logs. But that is a back burner task. Aug 16 21:20:33 I don't know any other way to track down a problem like this, even when it is not pseudo that is the root cause. Aug 16 21:20:55 Only an strace log could have told the story. And those are even harder to read. :-/ Aug 16 21:22:17 JPEW: ~40 builds Aug 16 21:22:45 jwessel: totally agreed. I'm just trying to think ahead about which bugs this covers Aug 16 21:23:00 jwessel: indeed, they're also huge Aug 16 21:23:12 Probably a number of them with glibc-locale Aug 16 21:25:29 jwessel: do we have to include hardlink files into cross-locale-def, or can it call the utility from util-linux-native and then we depend on util-linux-native that gives us maintained version of hardlink utility Aug 16 21:25:42 khem: I just replied on list about that Aug 16 21:25:54 khem: its a build performance nightmare if we add that dependency Aug 16 21:27:52 khem: I'd kind of preferred a simple python script but that didn't appear so simple Aug 16 21:28:23 RP: I've forgotten; does bitbake check for an sstate tarball before adding the _setscene task to the runqueue? Perhaps the encoding unihash changed after it was added but before the task actually ran? Aug 16 21:29:05 im;\' Aug 16 21:29:24 I would have preferred to just depend on util-linux-native... RP said it was too much of a problem. Aug 16 21:30:08 I'm just the person who's spent a lot of time trying to speed the builds up, what do I know :( Aug 16 21:30:58 I would have thought the host tools simply don't recompile too often. RP, you have more data points than I. Aug 16 21:31:01 JPEW: I think you don't quite comprehend the runqueue as it isn't an actual list of tasks we're running, its a list of all tasks we could possibly run Aug 16 21:31:02 I think if its adding some significant bit then I agree but there is maintainance part as well Aug 16 21:31:11 So I implemented what was asked. Aug 16 21:31:49 To make it easier, should it need to be upgraded for some reason. I did separate the patch to the raw version. Aug 16 21:31:50 it would not matter much for endusers since they hardly rebuild things so deep so often Aug 16 21:31:55 My instinct says it will hurt things. Its based on us having done this in places before and knowing what the changes on performance in glibc-locale do to the build Aug 16 21:33:24 JPEW: in that sense if you're asking when we mark it as buildable, we'd check the sstate cache after something is marked as having a new unihash. Aug 16 21:33:25 I wouldn't worry to much about needing to replace it down the road. The reasons for the patches over the years were all to add features. Any kind of bug fixes were few and far between. Aug 16 21:33:47 There are only so many ways to make a checksum and a series of calls to link() unlink() Aug 16 21:33:48 JPEW: so you're right, we should have already checked this was valid in sstate so its strange it suddenly wasn't Aug 16 21:34:31 That being said, we can just use the host version 3-4 years from now, when util-linux is upreved in the distros. Aug 16 21:34:43 hardlink was a very recent addition from RedHat. Aug 16 21:34:47 khem: it would hurt anyone building from scratch and people do that a fair bit and criticise the project for it Aug 16 21:34:50 RP: Ya, I think I'm confusing some terminology somewhere... need to read more code :) Aug 16 21:35:40 RP: I understand that but I dont know how much, Aug 16 21:36:13 khem: based on experience it will hurt a fair bit, particularly on people with fewer cores Aug 16 21:36:14 and util-linux appears in many recipes as dependency Aug 16 21:37:40 e.g. python3-native needs util-linux-native Aug 16 21:37:52 do we build glibc before that ? Aug 16 21:39:15 so my caution is to not create technical debt for ourselves unless absolutely required Aug 16 21:39:28 khem: I suspect that is a recently introduced performance regression then :( Aug 16 21:40:06 khem: If we don't care about build times, sure but I have done one heck of a lot of work to try and keep the bootstrap process clear of this kind of painpoint Aug 16 21:40:49 * RP notes systemd also has the dependency. On the plus side most of the rest of the system does not Aug 16 21:40:59 we patch it out of quilt-native for example Aug 16 21:42:15 khem: glibc is kind of special as its the choke point on the task graph. The locales connect to it not as a direct blocker but influencing packaging Aug 16 21:42:22 RP:we do care, but if python3-native is required early enough and its building util-linux-native for us, then we can certainly use it in cross-localedef isnt it or am I missing something Aug 16 21:43:09 khem: IMO we should fix python3-native, not use it as a justification for slowing down the build further Aug 16 21:47:11 its not justifying it, its calling out what is is Aug 16 21:48:23 I looked a bit of forever technical debt that we will carry and it does come at some cost Aug 16 21:50:44 khem: its not forever, its until we can depend on it from the host systems Aug 16 21:51:14 this is why I also preferred the python option but what do I know Aug 16 21:53:42 at one point util-linux-native was also a 'provided' thing.. stuff could specify it, but it never actually built Aug 16 21:55:05 perhaps uninative should capture all native dependencies and we should have none of those during build maybe Aug 16 21:56:20 so which hosts dont yet provide it Aug 16 21:56:21 khem: that isn't the point of uninative but was the point of buildtools-tarball Aug 16 21:56:27 Ubuntu Aug 16 21:56:44 I assume current Debian doesn't as well, but not sure Aug 16 21:57:05 Fedora and RHEL/CentOS have for a very long time Aug 16 21:57:29 RP: uninative is the right answer a collection of packages which are distro independendent and are downloaded automatically during build there is no third party involved Aug 16 21:58:18 khem: it is not the problem uninative is designed to solve Aug 16 21:58:18 current debian/buster is going to live for next 5 years :( I was hoping it was some old stinky centos Aug 16 21:58:43 RP: I understand that Aug 16 21:58:45 khem: it could be extended to solve that problem sure but its a very different one Aug 16 21:59:02 I am asking for widening its scope Aug 16 21:59:05 and we do already have a different solution there called buildtools-tarball, its just not downloaded automatically Aug 16 21:59:58 this would be a candidate for buildtools-tarball, but reality is that we'd then need to make hardlink a sanity checked item... Aug 16 22:00:21 and the out-of-box-experience for this one binary is better this way (for now)... Aug 16 22:00:36 khem: after all the complaints about naming we need to try and be really clear with names. uninative has a specific purpose and I'd prefer not to break that... Aug 16 22:00:38 I think its something we should do, otherwise we are spreading ourselves into supporing host distros Aug 16 22:01:04 khem: we already do that Aug 16 22:01:07 that's why (in this case) the tooling goes into the recipe and isn't distributed elsewhere.. it's local to limit support Aug 16 22:01:50 RP:question is should we keep doing that or have some solution to abstract on host distro Aug 16 22:02:36 we (WR) use the buildtools-tarball to bring old OSes up to date to be able to build.. but since hardlink is -so- new, even 'current' versions don't have the missing functionality to we're stuck for a bit Aug 16 22:03:06 khem: good question. I'd just like to know who is going to do the work in developing it and making it work and handling the transition and its relative priority to everything else Aug 16 22:03:15 meanwhile it would be nice to fix the locale corruption issue Aug 16 22:04:14 fray: thats understood, instead of making tools tarball an optional thing it should be made made mandatory and downloaded automatically during build Aug 16 22:06:03 currently we build same number of native packages irrespective of buildtools tarball is my understanding, it just brings those arcane machine to something that can build modern OE Aug 16 22:06:05 khem: people hate prebuilt binaries to the point I can't make uninative the default for OE-Core Aug 16 22:07:43 you mentioned build times earliers thats why I brought this up, its the time we spend building python-native and other large time consuming enabling packages that irritates the user Aug 16 22:08:46 khem: but buildtools-tarball doesn't help us with python-native or perl-native :( Aug 16 22:09:10 those recipes are so tightly coupled you can't do much but have identical versions -native and target Aug 16 22:09:24 We need to have option to rebuild the releases tarballs, otherwise shared state and buildtools tarballs are same, people should hate them equally Aug 16 22:09:37 python-nativesdk which is what would be in the buildtools-tarball isn't good enough Aug 16 22:10:22 khem: I do understand the attraction but I've been told binaries like that aren't acceptable Aug 16 22:10:56 and same folks would be using containers eh ? Aug 16 22:11:23 khem: no idea. Perhaps people have come around to the idea of uninative now Aug 16 22:11:37 or nobody uses poky and therefore they don't see it, I don't know Aug 16 22:14:33 anyway, I would rest my case Aug 16 22:16:13 we use uninative at WR, but in the same way that poky does.. Aug 16 22:16:23 we use buildtools to augment old (broken) OSes.. Aug 16 22:16:32 the combo works really well for us an our customers.. Aug 16 22:18:05 fray: do you use ASSUME_PROVIDED then to not build bunch of native packages becasue they now are in buildtools ? Aug 16 22:18:37 Only the same ones that Poky has Aug 16 22:18:55 python3, make, tar were the major things we've needed on older RHEL Aug 16 22:19:52 (RHEL / CentOS 7 is still REALLY common..) Aug 16 22:22:00 yes they are Aug 16 22:22:52 oh btw. glibc also needs python3 now during build, fun fun Aug 16 22:46:30 khem: can that not come from the host system though? Aug 16 22:47:03 python3-native is really for the python builds and python modules, not general python3 Aug 16 22:52:25 khem: I guess a key question is any version reqs? Aug 16 22:54:42 i have a kernel module.. and it has RPROVIDES_${PN} += "kernel-module-${PN}" inside of it. if i add kernel-module-$foo to PACKAGE_INSTALL, i get an error saying 'no installation candidate' even though it also says it is a virtual package provided by ${PN}. why is that? Aug 16 22:55:13 if i just use the kernel module ${PN} for PACKAGE_INSTALL it seems to work Aug 17 00:11:39 * armpit hmm, am I on swat next week??? Aug 17 00:14:32 * armpit cool, following week **** ENDING LOGGING AT Sat Aug 17 03:00:04 2019