**** BEGIN LOGGING AT Fri Mar 17 03:00:02 2017 Mar 17 07:28:54 hello Mar 17 07:29:21 anybody can explain why e2fsprogs-mke2fs installs the same binary 5 times with different names? Mar 17 07:29:47 this has an impact if you are in a very small file system Mar 17 07:34:50 i've found they are actually hardlinked Mar 17 09:09:49 How to ad libtool to environment PATH for do_compile ? Mar 17 09:14:37 I am running an image with read-only rootfs and have notice some missing volatile folders in the generated tmpfs Mar 17 09:15:05 The /run/ folder exists but /run/lock is missing Mar 17 09:15:53 deva: if you're using systemd then look at tmpfiles Mar 17 09:15:54 And also /var/log points to /var/volatile/log which doesn't exist (/var/volatile is there but hasn't got a log subdor) Mar 17 09:16:12 mborzecki, I am using systemd... forgot to say that ;) Mar 17 09:16:20 tmpfiles is a recipe? Mar 17 09:16:57 it's part of system Mar 17 09:17:36 s/system/systemd Mar 17 09:18:03 aah, looks like the right place Mar 17 09:18:42 hmm.. it already contains the /var/volatile/log entry, so something appers to be broken Mar 17 09:20:51 qt-x: $LIBTOOL should be defined, use that Mar 17 09:21:14 systemctl will list systemd-tmpfiles-* services that are responsible for setting up volatile stuff Mar 17 09:23:25 or do I remember wrong? I ususally need to find an old recipe to look at for libtool issues... Mar 17 09:25:22 jku: in the Makefile the $LIBTOOL env. var. is redefined Mar 17 09:25:24 hi there. Is it possible to publish a Layer to the official repository of Yocto-Layers? Mar 17 09:25:34 right, that's it Mar 17 09:26:20 mborzecki, There exists a var-volatile-lib.service that creates the /var/volatile/lib folder but I cannot find any references to tmpfiles and non of the other dirs are created Mar 17 09:26:41 jku: so the solution is to patch the Makefile ? Mar 17 09:27:02 qt-x: that's quite common at least Mar 17 09:28:28 but there seem to be as many ways to use/misuse libtool as there are open source projects... Mar 17 09:31:33 RP: I can reproduce the error that Ross ran into, where enabling rm_work ends up installing glibc-initial into the recipe-sysroot as part of do_image_wic. Mar 17 09:31:38 jku: In devshell the $LIBTOOL is empty Mar 17 09:31:58 log.do_image_wic.10430:Exception: FileExistsError: [Errno 17] File exists: '/fast/build/poky/intel-corei7-64/tmp/sysroots-components/corei7-64/libgcc-initial/usr/lib/x86_64-poky-linux/6.3.0/crtprec64.o' -> '/fast/build/poky/intel-corei7-64/tmp/work/intel_corei7_64-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot/usr/lib/x86_64-poky-linux/6.3.0/crtprec64.o' Mar 17 09:32:29 RP: ^^^ that means it is trying to add libgcc-initial (sorry, that, not glibc-initial), right? Mar 17 09:33:15 The existing crtprec64.o is the one from libgcc. Mar 17 09:35:51 deva: unless i'm missing something, but it looks like systemd 232 recipe installs /etc/tmpfiles.d directory, also systemd-tmpfiles-* services should be there in the image Mar 17 09:36:19 I have the tmpfiles.d directory but no tmpfiles service Mar 17 09:36:37 The systemd-tmpfiles command exists Mar 17 09:37:17 Aah... I have deleted them manually in a bbappend file - DOH! Mar 17 09:38:00 mborzecki, Thank you for your help :-) Mar 17 09:39:39 pohly: it means it was trying to install libgcc-initial and libgcc, yes Mar 17 09:39:45 jku: I found a solution in some other recipe Mar 17 09:39:58 jku: thanks Mar 17 09:40:05 RP: It should have skipped libgcc-initial, right? Mar 17 09:40:11 pohly: correct Mar 17 09:40:41 There's nothing in the log.do_image_wic about libgcc-initial. I'm currently adding some more debug output. Mar 17 09:41:28 I think the last time we looked at it, you pointed me to some code which excludes -initial, and I looked at it and had the impression that the check was getting skipped in this case. Mar 17 09:41:48 if mytaskname in ["do_sdk_depends", "do_populate_sdk_ext"] and c.endswith("-initial"): Mar 17 09:42:14 mytaskname is do_image_wic, so libcc-initial doesn't get skipped here. Mar 17 09:47:59 RP: yes, that's it. Mar 17 09:48:23 RP: what was the rationale for skipping -initial only in those two tasks? Mar 17 09:49:30 Adding do_image_wic to that list makes no sense, any other random task may trigger the same problem. Mar 17 09:52:35 pohly: the code that did the skipping was in sstate.bbclass wasn't it? Mar 17 09:52:39 (there are two sections) Mar 17 09:54:14 I can also explain why it happens only with do_rm_work (well, kind of): with rm_work.bbclass active, libgcc-initial is part of the direct dependencies, without it isn't (from the "Direct dependencies are" debug output). I don't know why rm_work.bbclass changes dependencies like that - perhaps because it triggers more work. Mar 17 09:54:41 RP: the check I quoted is in extend_recipe_sysroot() Mar 17 09:55:10 At that point, glibc-initial is in configuredeps. Mar 17 09:56:10 pohly: it really shouldn't be a direct depends :( Mar 17 09:59:46 It only happens with my latest do_rm_work_all patch. Mar 17 10:00:35 Which adds Mar 17 10:00:35 do_rm_work_all[recrdeptask] = "do_rm_work" Mar 17 10:00:35 addtask rm_work_all after before do_build Mar 17 10:02:02 pohly: I'm familiar with the patch Mar 17 10:02:56 I don't see anything obviously wrong with it. Mar 17 10:03:38 pohly: I also don't see anything obvious but there clearly is a problem Mar 17 10:04:05 How are these "direct dependencies" calculated? Are they the dependencies of the do_image_wic task? Mar 17 10:04:32 Those don't change with and without the patch (just checked). Mar 17 10:05:00 pohly: If they're there before and after, the comment I made earlier on and that you ignored is probably the issue Mar 17 10:05:49 pohly: http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/sstate.bbclass?h=master-next&id=3e8fab0c0b6d1cc84d00d91ec3790b51a3c5dec1#n950 Mar 17 10:05:52 RP: which comment did I miss? Mar 17 10:06:22 pohly: I think the problem is probably with setscene_depvalid(), its probably missing some case to do with the extra added task Mar 17 10:06:46 pohly: have you some logs of this task's debug output? Mar 17 10:07:05 pohly: I may be able to spot the issue from that Mar 17 10:07:41 Of do_image_wic? Yes, I'm looking at that now. However, there's nothing in it about libgcc-initial except the final failure and the entry in "Direct dependencies". Mar 17 10:07:52 Let me pastebin it anyway... Mar 17 10:09:02 pohly: the logs before and after would be most interesting too... Mar 17 10:09:33 Before and after the patch? Mar 17 10:11:20 pohly: yes. but please share what you have Mar 17 10:11:50 rburton: master-next was a bit of a mess on the AB Mar 17 10:12:09 rburton: Brian's gen-lock patch was badly broken Mar 17 10:12:39 urgh Mar 17 10:12:47 rburton: I think one of roberts breaks a wic test Mar 17 10:13:04 rburton: there is some kind of nfc header race Mar 17 10:13:11 rburton: a mingw binutils breakage Mar 17 10:13:13 RP: with patch: http://pastebin.com/jjBVSV3w Mar 17 10:15:06 RP: and without: http://pastebin.com/mFCRknek Mar 17 10:15:54 pohly: Notice how the latter has Skipping setscene dependency /fast/work/poky/meta/recipes-devtools/gcc/libgcc-initial_6.3.bb:do_populate_sysroot for installation into the sysroot Mar 17 10:16:08 pohly: so the question is more about why it stopped doing that Mar 17 10:16:28 RP: because that is about an indirect dependency perhaps? Mar 17 10:17:56 pohly: You're confusing me. You said "(10:04:32) pohly: Those don't change with and without the patch (just checked)." however the direct dependencies clearly do change Mar 17 10:18:11 pohly: so I must have been confused what you were referring to Mar 17 10:18:55 RP: what I meant with that is that I ran "bitbake -g core-image-minimal" and looked at the core-image-minimal.do_image_wic dependencies in task-depends.dot. Those don't change. Mar 17 10:19:29 I was trying to figure out what "direct dependencies" means in this context, because that clearly is different in the two logs. Mar 17 10:19:36 pohly: the direct dependency lists are hugely different Mar 17 10:19:46 Yes, exactly. Mar 17 10:19:59 And that triggers the problem. Mar 17 10:21:01 Regarding "why it stopped doing that" [that = Skipping setscene dependency ] - that's probably because of the "if datadep in done" check that causes setscene_depvalid to be skipped. Mar 17 10:22:28 pohly: right, there is something wrong with that initial dependency calculation Mar 17 10:27:28 pohly: are you going to work on this or are you after me to dig into it? Mar 17 10:27:56 RP: I've enabled the log output for start near the top of extend_recipe_sysroots. Here's without do_rm_work_all: http://pastebin.com/qtKaabbh Mar 17 10:28:15 RP: I can look further, but I'm probably not going to be very productive about it. Mar 17 10:29:16 pohly: ok. Perhaps if I'm going to poke at this, could you glance at and see if you understand https://autobuilder.yocto.io/builders/nightly-musl/builds/195/steps/BuildImages/logs/stdio ? Mar 17 10:29:54 error 7000: Failed to execute command Mar 17 10:29:55 | make tbuild [/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-musl/build/build/tmp/work/i586-poky-linux-musl/ovmf/git-r0/git/Build/OvmfIa32/RELEASE_GCC5/IA32/OvmfPkg/AcpiTables/AcpiTables] Mar 17 10:29:55 | Mar 17 10:29:55 | Mar 17 10:29:55 | build.py... Mar 17 10:29:56 | : error F002: Failed to build module Mar 17 10:29:58 | /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-musl/build/build/tmp/work/i586-poky-linux-musl/ovmf/git-r0/git/OvmfPkg/AcpiTables/AcpiTables.inf [IA32, GCC5, RELEASE] Mar 17 10:30:01 | Mar 17 10:30:13 that's the pertinent part of ovmf-git-r0:do_compile failure, I think Mar 17 10:31:21 RP: yes, please have a look. The same output with do_rm_work_all just confirms what we already now, libgcc-initial gets added to the direct dependencies: http://pastebin.com/TNhvXmRz Mar 17 10:33:45 pohly: I don't really have the time but I'll do it anyway :( Mar 17 10:33:56 pohly: personally, I'd love just to rm rm_work Mar 17 10:34:13 RP: I'll check the ovmf error. I suppose it is limited to musl? Mar 17 10:35:23 Where do I find the configuration used for that again? Mar 17 10:35:27 pohly: I don't know. It was with the patches in -next and I don't know if one of them caused it or it was a one off race Mar 17 10:35:57 pohly: I guess I can try and reproduce it and let you know if its a general problem once I figure that out Mar 17 10:36:19 rburton: were you also only seeing this with wic? Mar 17 10:49:49 joshuagl: how do I enabled building like the AB for musl again? Mar 17 10:50:12 I tried DISTRO="poky-tiny" (because it is said to use musl) but that just worked for ovmf - no error. Mar 17 10:51:00 pohly: I think the only real change is TCLIBC="musl", but you can see what we're writing to auto.conf here: https://autobuilder.yocto.io/builders/nightly-musl/builds/195/steps/CreateAutoConf/logs/stdio Mar 17 10:52:07 yup, qemux86 with TCLIBC="musl" Mar 17 11:02:17 RP: I've tried to reproduce that AB failure locally, but for me, poky master-next with TCLIBC="musl" doesn't show that problem. Mar 17 11:03:48 sounds like a race Mar 17 11:12:13 pohly: does seem its likely some kind of race then :( Mar 17 11:12:56 RP: not sure. The error itself is coming from ovmf Elf64Convert.c or Elf32Convert.c and seems related to problems with handling of ELF input. Mar 17 11:13:42 It's a bit strange that there's no additional information after "ERROR 3000: Invalid" - all locations seems to have an additional explanation. Mar 17 11:15:54 pohly: if you disable classes/image_types_wic.bbclass:do_image_wic[depends] += "wic-tools:do_build" do you still have this problem? Mar 17 11:16:21 pohly: I suspect that adding in a do_build dependency causes a problem Mar 17 11:16:54 since do_build depends on do_rm_work_all which depends on do_rm_work which depends on libgcc-initial do_rm_work Mar 17 11:17:19 pohly: if we change do_build -> do_populate_sysroot for example, it may change things Mar 17 11:23:46 RP: yes, that worked. Mar 17 11:24:04 -do_image_wic[depends] += "wic-tools:do_build" Mar 17 11:24:05 +do_image_wic[depends] += "wic-tools:do_populate_sysroot" Mar 17 11:25:12 pohly: the question then becomes what the correct fix is... Mar 17 11:25:25 I was wondering about the same... :-/ Mar 17 11:25:30 pohly: it at least lets us see what the problem is Mar 17 11:28:21 I starting to suspect that the dependency model is too limited to solve the problem accurately - "foo -> bar" can mean all kinds of things at the moment, from "foo absolutely needs bar" to "foo does not need bar, but wants bar to be done" to "foo must run before bar, but not running bar is okay". Mar 17 11:29:13 That should be "bar must run before foo" in the last case. Mar 17 11:29:46 But I guess being more specific in do_image_wic would be a worthwhile enhancement, either way. Mar 17 11:31:03 lunch time for me... Mar 17 11:47:51 has patchtest email policy changed? I haven't seen any emails lately Mar 17 11:49:18 jku: I think something broke, there is an open bug Mar 17 11:59:55 has anyone looked at the neard failure in next? Mar 17 12:00:23 rburton: not yet :( Mar 17 12:00:37 rburton: I root caused the wic failure back to roberts patch though Mar 17 12:00:42 cool Mar 17 12:01:10 rburton: I'm trying to sort out the selftest failures :/ Mar 17 12:01:30 rburton: I can take a look Mar 17 12:01:48 thanks jku Mar 17 12:01:58 (builds fine here too) Mar 17 12:03:47 jku: thanks! Mar 17 12:03:59 jku: it failed in multiple different builds the same way which was odd :/ Mar 17 13:16:19 RP, rburton: neard fix is on list. It's still a mystery to me how it started showing up now Mar 17 13:18:05 thanks jku Mar 17 13:18:14 the gremlins were late, that was the build after the M3 one ;) Mar 17 13:18:22 IN YOUR FACE GREMLINS Mar 17 13:20:34 jku: thanks! Mar 17 13:20:47 * RP wonders why the devtool test fails on centos7 :/ Mar 17 13:42:23 hmm, my build fails during license_create_manifest, because it looks for a folder named kernel-4.9.0-xilinx-dev, but I'm not even using that kernel for this build, i Mar 17 13:42:35 i'm using 4.6-xilinx Mar 17 13:42:37 no dev Mar 17 14:03:35 RP: interesting. that dir doesn't exist in /tmp but based on the number of devtool* directories in there I don't think the test cleans up after itself Mar 17 15:29:11 joshuagl: some of this may be me experimenting Mar 17 15:32:03 we should really standardize on whether the first or second argument of assertEqual is the expected vs actual value, or write a wrapper for it that makes it more explicit, in our unit tests Mar 17 15:32:22 i just had 5 failures, but they flip flop on that behavior, which makes parsing the output more difficult Mar 17 15:32:29 kergoth: :( Mar 17 15:32:36 little thing, but.. Mar 17 15:32:48 kergoth: its nice to be consistent where we can... Mar 17 15:33:12 not always easy, particularly in a case like this. even if we do explicitly document a particular order, we'll forget the order when we write the tests :) Mar 17 15:33:33 sometimes i hate positional arguments Mar 17 16:58:57 rburton: there are couple of my patches missing from your mut once added they fix all build issues for musl world builds for all qemu machines Mar 17 16:59:15 khem: have a look now, literally just pushed Mar 17 16:59:50 if there's anything missing please say what :) Mar 17 16:59:57 musl for world \o/ Mar 17 17:00:02 * rburton faints Mar 17 17:01:26 rburton: http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/pu Mar 17 17:01:29 top two Mar 17 17:01:37 cheers Mar 17 17:03:33 khem: the go one is in, the ltp one never hit the lis Mar 17 17:03:34 list Mar 17 17:04:45 ah yes Mar 17 17:04:49 ltp is only one left Mar 17 17:04:52 good job Mar 17 17:05:04 i refreshed kraj/pu Mar 17 17:07:37 I am also carrying https://github.com/kraj/openembedded-core/commit/19dcba5dd8a34c73562a95ecc7cb5a1122a59321 to beat bash into submission with clang but its a hard nut to crash not done fully yet Mar 17 17:08:08 heh Mar 17 17:08:13 time to unlock some of packages blacklisted for musl world builds and see if something improved overtime Mar 17 17:08:24 i just pulled the ltp fix into mut so you must promise to send it to the list :) Mar 17 17:08:41 its already on list since last night Mar 17 17:08:43 when they're all merged maybe we should do more musl builds on the ab Mar 17 17:08:59 hm not in my inbox Mar 17 17:09:00 rburton: we should do world builds for all qemu machines Mar 17 17:10:08 for once I am wrong Mar 17 17:10:14 sending it now Mar 17 17:12:23 * kergoth mutters, forgot to test gitsm+shallow Mar 17 17:12:57 has anyone seen this warning http://sprunge.us/CTPb Mar 17 17:13:12 I keep seeing it with master on archlinux Mar 17 17:13:23 it annoys me for a few second and then I move on Mar 17 17:40:37 khem: any opinions on adding newlib to oe-core/meta? looking to need it for building some firmware in meta-xilinx (for a complex SoC) Mar 17 17:44:13 nrossi: put it in meta-xilinx? Mar 17 17:46:58 rburton: sure, that is the plan. But I just wanted to check to see if it would be worth sorting out for common use since at least one other layer uses newlib (meta-zephyr) Mar 17 17:48:35 RP: how do we proceed with the rm_work_all + do_image_wic dependency issue? Shall I submit the do_image_wic change? It's arguably a better dependency, with or without that do_rm_work_all dependency calculation thingie. Mar 17 17:49:03 nrossi: rburton: I think only to the limit of using it to generate a baremetal toolchain Mar 17 17:49:18 pohly: i wasn't entirely paying attention this morning, but the wic change seemed sensible Mar 17 17:49:32 rburton: okay, then I'll submit that now. Mar 17 17:49:51 nrossi: I would rather suggest to enhance nommu port of musl Mar 17 17:51:42 khem: the use case in meta-xilinx is for baremetal Mar 17 17:51:56 yes thats why I said nommu Mar 17 17:52:19 fwiw i'd prefer not to add a C library that isn't tested in oe-core Mar 17 17:52:33 which is why i'm so pleased that khem has been making musl work in world builds Mar 17 17:54:12 rburton: my covert ambition is to make it primary libc C for yocto :) Mar 17 17:54:31 khem: you've not been very covert at that :) Mar 17 17:54:53 would be interesting to see what selftest makes of musl Mar 17 17:54:57 its such a well written and small library Mar 17 17:55:11 my kodi uses 45M less RAM when running on musl Mar 17 17:55:23 rburton: that makes sense, I just wanted to make sure that putting it in a bsp layer is not to 'non-compliant' Mar 17 17:55:24 while playing HD streams it matters Mar 17 17:55:48 nrossi: for baremetal libc is just a helper Mar 17 17:55:59 so its treated as normal Mar 17 17:56:02 package Mar 17 17:56:21 rburton: I am starting to use selftest myself here now a days Mar 17 17:56:34 rburton: I want to automate it Mar 17 17:56:53 in my workflow, do we have some doc on knowing more about it ? Mar 17 17:57:23 not afaik. oe-selftest is the entry point, you can tell it to run all tests or just a module, or just a specific test Mar 17 17:57:45 I do this in my local.conf Mar 17 17:57:47 tests themselves are basically standard unittest, theres subclasses with helper stuff like bitbake() methods Mar 17 17:58:16 INHERIT ptest Mar 17 17:58:18 TEST_IMAGE = "1" Mar 17 17:58:27 don't inherit ptest in the local.conf Mar 17 17:58:33 oh Mar 17 17:58:50 ptest is the package test suite for on target Mar 17 17:58:51 sorry its in DISTRO_FEATURES Mar 17 17:58:56 right Mar 17 17:58:56 khem: rburton: thanks for the help, you even answered a question i had yet to ask (to tclibc-newlib or not :) ) Mar 17 17:59:21 khem: if you want testimage to run ptests then you need a tweak, one sec Mar 17 17:59:55 khem: TEST_SUITES = "_ptest" will run just the test suite, which basically ssh's in and runs all ptest packages it can find Mar 17 18:00:10 so if you have ptest-pkgs in IMAGE_FEATURES you get all test suites Mar 17 18:00:21 and then -c testimage will boot it in a qemu, ssh in, and run them all Mar 17 18:00:34 note that its _ptest so it doesn't run by default because it's known that a lot of them fail :( Mar 17 18:01:25 ah so _ptest are known to run ? Mar 17 18:02:00 tbh, you'll be better adding ptest packages explicitly. stuff like the python-ptest takes *forever* Mar 17 18:02:44 ok. if I have to run it on say rpi3 then what do I do Mar 17 18:02:51 hm Mar 17 18:02:59 i think testimage can handle that, but i've never tried Mar 17 18:03:04 ok Mar 17 18:03:33 worst case, ssh in yourself and then run the runner scripts yourself Mar 17 18:04:19 rburton: OK Mar 17 18:04:39 how is oe_selftest run Mar 17 18:05:20 https://wiki.yoctoproject.org/wiki/Oe-selftest Mar 17 18:05:22 i see Mar 17 18:05:39 pohly: probably submit it, yes Mar 17 18:06:43 RP: what do you think of making security_flags default ? Mar 17 18:07:13 if we do that, then I can think of hardening toolchain in next release cycle Mar 17 18:07:32 which will fix lot of issues that we currenlty see with -fPIE Mar 17 18:08:44 which would mean that toolchain will be configured to generate code will all security options on offer in toolchain Mar 17 18:09:41 khem: it already is the default for poky-lsb so we do test it continually FWIW Mar 17 18:10:17 RP: yes, and what I am saying is poky-lsb becomes poky Mar 17 18:10:34 khem: poky or nodistro? Mar 17 18:10:40 err nodistro Mar 17 18:10:43 yes Mar 17 18:10:52 khem: I'm torn on the idea, there are a lot of exclusions in there and workarounds :( Mar 17 18:11:04 because if we decide that then we can marshall the toolchain configuration Mar 17 18:11:25 khem: I suspect JaMa might have an opinion on this due to the meta-oe impact Mar 17 18:11:30 the workarounds are because we dont make the toolchain right Mar 17 18:11:52 khem: we don't? :/ Mar 17 18:12:00 well we cant Mar 17 18:12:15 khem: I'm open to trying it Mar 17 18:12:19 unless we agree that by default we want to produce PIE code Mar 17 18:12:45 khem: probably needs discussion on the arch list Mar 17 18:12:48 most of the exclusions in the blacklist are because tools dont communicate right options Mar 17 18:12:59 yes I will make a proposal for next release Mar 17 18:13:15 cool Mar 17 18:13:21 khem: sounds good Mar 17 18:13:25 * RP -> afk Mar 17 18:13:39 cool thanks have a good one Mar 17 18:14:06 secondly, it will be good to think about producing docker containers out of box Mar 17 18:15:47 rburton: so oe-selftest --run-all-tests doesnt depend on target being emulator or does it ? Mar 17 18:16:05 as I see thats its more for build system integrity Mar 17 18:16:29 iirc there's a few tests where it builds images and boots them but they should be checking machine Mar 17 18:16:39 but mostly it just cares about stuff building Mar 17 18:16:53 "does a readonly rootfs build without errors, as a failing postinst is fatal" Mar 17 18:16:55 etc Mar 17 18:20:35 yeah cool stuff Mar 17 18:20:39 its lot of hard work Mar 17 18:21:25 ok so we need couple of backports for openssl to tame it with clang Mar 17 18:21:32 where is my devtool Mar 17 19:07:24 rburton, https://autobuilder.yoctoproject.org/main/buildslaves is ready for a build now. Do we need anything started? Mar 17 19:51:05 khem: i've been seeing that python warning for a while now, a week or more? Mar 17 20:00:09 I think I have seeing it for a lot longer Mar 17 20:00:23 tlwoerner: I never got to your u-boot problem Mar 17 20:00:57 khem: i'm sorry i couldn't figure out how to help you investigate it :-( Mar 17 20:01:28 no worries though, thankfully there was a workaround Mar 17 20:13:13 halstead: thanks, i'll fire a build now Mar 17 20:13:34 Hello, I am Giouli and I am interested in improving documentation for autobuilder within the Outreachy internships. I have a degree in Informatics and Telematics and I would like some info on what my initial contribution should be, so I can make an application. Mar 17 20:13:35 rburton, .io is ready too. Do you have a second build? Mar 17 20:13:45 yeah Mar 17 20:14:53 fired and fired Mar 17 20:18:21 Thanks! Mar 17 20:18:32 no, thank you Mar 17 21:28:15 giouli: thats good. Feel free to ask questions here Mar 17 22:07:56 tlwoerner: if you would have tarred up the two u-boot directories and uploaded that would be sufficient Mar 17 22:11:55 anyone have a url handy that uses git-annex? Mar 17 22:12:00 i have a need to test it Mar 17 22:14:00 Hmm, I really want the git fetcher submodule handling to call out to the fetcher itself to acquire each submodule needed given our srcrevs, so each submodule gets its own mirror tarball, etc Mar 17 22:47:10 shit, git shallow breaks gitannex:// Mar 17 22:47:12 * kergoth grumbles Mar 17 23:10:40 https://git-annex.branchable.com Mar 17 23:10:50 nice Mar 17 23:10:53 never used it Mar 17 23:16:45 khem: literally going to bed so i haven't looked at what failed yet, but musl just broke on the ab: https://autobuilder.yocto.io/builders/nightly-musl/builds/196/steps/BuildImages/logs/stdio Mar 17 23:21:03 khem: git-annex and git-lfs both do similar things. lfs is supported by github. afaik annex isn't, but annex is far simpler Mar 17 23:21:08 should probably add a fetcher for lfs too Mar 17 23:21:25 there, both submodules and annex content are included in the shallow tarballs now Mar 17 23:21:27 * kergoth rolls eyes Mar 17 23:21:30 https://github.com/kergoth/bitbake/compare/bb-fetch-git-cleanup...kergoth:shallow-granular Mar 17 23:22:49 RP: for whenever you get back, i'm wondering if it'd be better or worse to add explicit extension capability to the git fetcher, rather than subclassing to add additional functionality Mar 17 23:41:45 rburton not related to musl as it seems from looks of it Mar 17 23:45:52 rburton its some other change thats breaking it. Since I checked my qemux86 logs from this morning with musl update and ovmf built fin Mar 18 00:24:56 ah this ovmf crap is using native compiler :( Mar 18 00:25:04 I wonder how it got into OE-Core Mar 18 00:25:28 its used on x86 platforms so it got along **** ENDING LOGGING AT Sat Mar 18 03:00:01 2017