**** BEGIN LOGGING AT Fri Sep 06 03:00:56 2019 Sep 06 05:48:29 New news from stackoverflow: Linux booting stop at Starting kernel when using Yocto build image with SD card Sep 06 06:45:23 LetoThe2nd: I haven't seen the fifth installment of the live coding yet, but if you have not talked about wic yet, that would be an interesting topic. Sep 06 06:48:57 iceaway: yeah i totally have wic on my to-do list. problem is rather that i'd have to learn it myself first :( Sep 06 06:52:36 I am creating a custom distro/image (based on poky/core-image-minimal) for our product. Would the recommended approach be to put everything that should end up in the production image in the distro/image settings, and keep local.conf only for things to customize for the developer/development session? Sep 06 06:57:01 iceaway: absolutely Sep 06 06:57:42 in a perfect world, local.conf sets MACHINE and DISTRO, besides that only things that affect the build process but not build content Sep 06 06:57:55 good morning, TGIF Sep 06 06:58:32 mckoan: heh yeah Sep 06 07:12:45 mckoan, LetoThe2nd: Good morning Sep 06 07:15:18 LetoThe2nd: great, then I have my bearings sortof correct :) Sep 06 07:18:25 alessioigor: i fail to agree on the "good" part, sorry. Sep 06 07:46:52 RP: so if you hadn't already solved the concurrency ptestresults issue. I think i might have a solution. experimentation commit here: https://github.com/nathanrossi/openembedded-core/commit/6870a18a833299e3d84f4dfde50cdbc64762e2a8 Sep 06 07:47:20 RP: execution output here: https://gist.github.com/nathanrossi/89898a1488905f410d3c3976865b13fb Sep 06 07:50:41 nrossi: I'm only just starting to think about that so its good timimg! Sep 06 07:52:02 nrossi: good news is the still going autobuilder run is quite green after 17 hours :) Sep 06 07:52:09 nrossi: i.e. the keepalive works Sep 06 07:52:31 and we've addressed most of the failures Sep 06 07:52:56 kernel upgrades also look under control so things are starting to calm down a bit Sep 06 07:52:58 RP: nice to know :), I have to afk for a little while will be back in <1h Sep 06 07:53:24 nrossi: np, I appreciate all the help! Sep 06 08:02:02 nrossi: should that be self.successes.append((test, details)) ? Sep 06 08:05:25 nrossi: think I'm missing something with that commit but its in the right area... Sep 06 08:24:37 khem: thanks Sep 06 08:45:01 Hi guys... I have an image that I built with yocto... I deployed that image to my device... after some time I get some bug reports about that image... how can I link that image to layer commit ids? Sep 06 08:45:24 is there a "standard" way of doing this? Sep 06 08:45:36 like some yocto image tracebility? Sep 06 08:45:39 wooosaiiii: by making sure you know how you built the image that you handed out Sep 06 08:46:17 wooosaiiii: common approaches include repo or kas for layer setup, or git submodules as a combined distro Sep 06 08:46:33 I checked /etc/version timestamp -> this can be linked to images in deploy folder Sep 06 08:46:46 wooosaiiii: sounds very, very fragile Sep 06 08:46:51 LetoThe2nd: :) Sep 06 08:47:30 wooosaiiii: anything that depends on anything in tmp is to be considered a bad practise. the name "tmp" alone should already tell you these files are only temporary. Sep 06 08:47:53 LetoThe2nd: ok... Sep 06 08:49:10 wooosaiiii: a means of total emergency could be to look at the output of bitbake starting up, it at least givesthe git state of layers in use. but that does not tell you anything about local modifications and such Sep 06 08:49:29 LetoThe2nd: exactly... Sep 06 08:49:38 wooosaiiii: in a nutshell, never ever hand out something that hasn't been created through a reproductible build pipeline (CI!) Sep 06 08:50:39 LetoThe2nd: ok... Just wanted to hear if there is any "standard" way of doing so... Sep 06 08:51:41 LetoThe2nd: but is there any mechanism in place to link image on the device to repo layer commits? Sep 06 08:51:48 wooosaiiii: the standard way is making sure you know what you handed out, and i named the commonly used approaches. Sep 06 08:51:57 wooosaiiii: the image-buildinfo class can write the layer SHAs to the image for you Sep 06 08:52:02 LetoThe2nd: I thought about buildhistory + /etc/version on the device Sep 06 08:53:03 rburton_: thanks for info... will try it out... Sep 06 08:53:30 RP: oh sorry should have been clearer, that commit is just about solving the cross process transfer of extraresults Sep 06 08:58:06 How handle in-kernel config fragments for defconfig generation in Yocto? KBUILD_DEFCONFIG seems looking for a physical file and not for the generated ones... Sep 06 09:31:23 nrossi: are you saying that should fix the problem? Sep 06 09:31:32 nrossi: are you sure that is the right commit? Sep 06 09:32:21 RP: its just a proof of concept. Aka passing the extraresults via the testresult class, which is handled by subunit to pass through the protocol stream to the parent processes testresults class Sep 06 09:32:49 RP: the other step is to take that dictionary and update the testcontext object from the testresults class Sep 06 09:33:14 nrossi: I think I need to stare at the code a bit as I'm not quite understanding! :) Sep 06 09:33:58 nrossi: ah, this is probably related to the way addSucess has compat fallbacks? Sep 06 09:34:01 RP: dw, its was complex at first. But the subunit module handles a kwarg called details that it will encode/decode across processes Sep 06 09:34:24 RP: compat fallbacks? Sep 06 09:34:35 nrossi: ignore me :) Sep 06 09:34:40 nrossi: that does make sense Sep 06 09:34:59 nrossi: I guess since you're close I'll let you figure this out? Sep 06 09:35:46 RP: i can finish it up of course and make sure it works locally. Not 100% sure it scales perfectly since it is passing the large json objects between processes Sep 06 09:36:25 nrossi: Hopefully we won't hit that... Sep 06 09:36:59 RP: i will make sure its only trying to do the passing for tests that have the extraresults Sep 06 09:38:35 nrossi: The other data probably isn't significant anyway Sep 06 09:38:36 ? Sep 06 09:39:01 RP: not sure, have not dug that deep yet ;) Sep 06 09:44:38 nrossi: I think I'm going to merge some of the base recipes but not the oeqa pieces yet Sep 06 09:44:48 nrossi: just to make the queues a bit more managable Sep 06 09:45:03 rburton_: ok with you? Sep 06 09:49:32 G'day. Hopefully a quick question - is it possible to run a QA step after wic image creation? Sep 06 09:49:35 nrossi: also cc'd you on a discussion with JPEW on how we might want to think about log processing in due course Sep 06 09:49:54 ball-hayden: addtask qacheck after do_image_wic ? Sep 06 09:50:23 ball-hayden: probably after do_image_complete actually Sep 06 09:50:37 ball-hayden: in short, yes Sep 06 09:50:39 Huh. That simple. (sorry - still fairly new to this game) Sep 06 09:50:54 Would it be easy enough to get hold of the partitions from there? Sep 06 09:51:00 Specifically, I'm wanting to run fsk Sep 06 09:51:26 (we've managed to generate images with FAT errors, and I'd quite like to know earlier next time...) Sep 06 09:51:46 I'll give that a go though - thanks :-) Sep 06 10:19:13 New news from stackoverflow: How to create a yocto recipe that installs only the libraries to the target machine rootfs and all headers and libraries to the sdk host rootfs? Sep 06 10:30:37 RP: https://patchwork.openembedded.org/patch/164139/ - ping on that patch, since it is has been over two weeks. Sep 06 10:30:49 I'd like to cross that off my list since it is a regression. Sep 06 10:31:29 jwessel: it had slipped the net, I'll queue it Sep 06 10:31:52 I wasn't sure if there was a problem in general with it or not. No worries. :-) Sep 06 10:32:23 jwessel: just drowning in problems tm Sep 06 10:32:24 atm Sep 06 10:34:24 Do the OE minutes cover say what major problems are still left to go? I had been out of the office all week, traveling back home today. Sep 06 10:34:37 RP: if there's something I could help with let me know Sep 06 10:34:50 Or is it the typical dying the death of a 1000 cuts from small stuff. Sep 06 10:35:33 I had the same concern as kanavin_. I can take a peak at something if I can download it before I get a on plane :-) Sep 06 10:35:51 jwessel: we've been struggling with the 5.2 kernel but that is now hopefully all resolved Sep 06 10:36:21 Indeed. Hopefully that is set. We have our test/bsp folks chewing away at it. Sep 06 10:36:35 jwessel, kanavin_: right now the pain points left are hashequiv problems and getting the toolchain testsuite pieces integrated into the autobuilder Sep 06 10:37:40 I also need to test adding systemd to altcfg and see what that does on the autobuilder. I should sechedule that now Sep 06 10:38:01 jwessel: it was systemtap that turned into a major pain but I think we're past that now Sep 06 10:38:52 kanavin_: I appreciate the offer, just not sure how to break up anything else left Sep 06 10:39:03 nrossi: are you ok with the testsuite pieces you have left on your plate? Sep 06 10:40:13 Thanks for the update RP. Sep 06 10:41:04 RP: yes, assuming that is of course that the remaining issues are concurrency-ptestresults and selftest -t/-T arg changes Sep 06 10:45:30 nrossi: I think so (along with then sorting out the autobuild ptest log extraction but that is M4) Sep 06 10:46:26 RP: sure can look at that later, have not completely read and understood what that is about though :) Sep 06 10:47:21 nrossi: right, its a "for later" thing Sep 06 11:09:07 nrossi: there was one other thing I remembered Sep 06 11:09:32 nrossi: the parallelism in oeqa is done per class. If we split some of the tests into more classes, they'll run in parallel Sep 06 11:09:54 nrossi: might be worth considering since they're independent? Sep 06 11:10:34 RP: should I setup e.g. "GccSelfTest" as a base class and make gcc, libatomic... super classes? Sep 06 11:11:03 nrossi: I'm thinking yes as we'll get parallelism wins Sep 06 11:11:53 nrossi: this is what the numbers in the likes of https://autobuilder.yoctoproject.org/typhoon/#/builders/74/builds/997/steps/8/logs/step3d mean Sep 06 11:12:20 nrossi: the X/6 means there are 6 parallel sets of tests running with X/21 being the total number of tests. Sep 06 11:12:58 nrossi: the X: at the start tells you which thread was reporting Sep 06 11:13:26 RP: there wont be much win on the system emulation classes though.... qemu is just slow for those :( Sep 06 11:14:30 nrossi: executing in parallel compared to serial is still a win Sep 06 11:15:53 RP: sure, but its only really going to split off libstdcxx tests from check-gcc ones in terms of parallel tasks as the other lib* ones are alot faster Sep 06 11:31:36 RP: sounds sensible (merging bits) Sep 06 11:39:56 oh god another ota updater https://www.fullmetalupdate.io Sep 06 11:40:09 can people please stop writing new ones and start consolidating Sep 06 11:41:23 rburton_: it's a "big" French company behind Sep 06 11:41:42 qschulz: was wondering who made it, never easy to identify Sep 06 11:42:07 rburton_: Witekio, previously Adeneo Embedded IIRC Sep 06 11:42:39 rburton_, https://github.com/FullMetalUpdate/meta-fullmetalupdate/branches Sep 06 11:42:45 meh, just rocko/thud Sep 06 11:43:05 kanavin_: was 'allow shell-style wildcards in PRIVATE_LIBS' a repost or a v2? Sep 06 11:43:21 rburton_, repost Sep 06 11:43:29 cool, its in mut already Sep 06 11:44:31 and the virgl bits are the same too, I'm not sure whether they'll be picked up for 3.0, but posted them once more just in case Sep 06 11:44:49 yeah i wanted to give those a play Sep 06 11:45:09 yeah, somewhere on the way, SDL started working Sep 06 11:45:11 not entirely sure i like how something in there needs mesa-dev installed to use the .pc files Sep 06 11:45:21 rburton_, only for egl-headless Sep 06 11:45:29 sdl/gtk frontends don't need them Sep 06 11:46:01 sdl/gtk work through libepoxy which falls through to the host mesa Sep 06 11:46:24 but egl-headless loads native mesa directly, and so we need to (mis)guide it to use host drivers Sep 06 11:46:49 because building a useful set in mesa-native would simply be way too much Sep 06 11:47:00 any reason why it can't use libepoxy too i wonder Sep 06 11:47:09 just the way it's written in qemu Sep 06 11:48:00 Just to be sure, commit message in 6b8e0077339a89cb01aa40c1b367a4e41a638892 in current master states that the commit perhaps shouldn't be merged. Sep 06 11:48:26 oe-core repo that is Sep 06 11:48:51 JPEW, RP: ^^^ Sep 06 11:48:57 nrossi: FWIW I'm leaning towards tagging the tests as "toolchain-user", "toolchain-system" and "toolchain-ypab" and then from the autobuilder we just run "toolchain-ypab" Sep 06 11:49:25 kroon: It was intentional, I'd just not realised the commit said it was a test Sep 06 11:49:40 RP, cool Sep 06 11:50:06 rburton_: -next looks a little more trim Sep 06 11:51:12 nrossi: I guess that still means conditional tags though :/ Sep 06 11:51:25 RP: i assume that would mean for qemux86-64 you would run all "toolchain-ypab" and "toolchain-system" tags, but only "toolchain-ypab" for the others? Sep 06 11:51:52 nrossi: right, toolchain-ypab doesn';t help us does it :/ Sep 06 11:52:37 nrossi: we'd just have to override the template for x86/x86-64 Sep 06 11:53:00 RP: yer, maybe its best to keep it simple for now :) Sep 06 11:53:37 nrossi: still haven;t figured out how to trigger things conditionally properly for quick/full Sep 06 11:53:49 I guess that is my next job Sep 06 11:55:06 RP: repushed mut with revised patches for meson/weston from the contributors instead of my fixup patches on top. if the ab goes green you should be good to pull the lot into next Sep 06 12:29:46 in local.conf, does the order of IMAGE_INSTALL_append matter? Sep 06 12:37:59 hmm, it's not possible to include another .bbappend from .bbappend? It fails with "u-boot_2019.01.bbappend: not a BitBake file" Sep 06 12:43:08 JaMa: what's the use case? Sep 06 12:44:06 rburton_: into next or straight to master? Sep 06 12:44:36 JaMa: not sure that is something we've ever tried or supported Sep 06 12:48:51 qschulz: https://github.com/shr-project/meta-raspberrypi/commit/b5ff395e749acfaefbe526ee159065228a1529c2 Sep 06 12:49:18 RP: probably not useful in most cases, I was just surprised Sep 06 12:50:00 JaMa: you could certainly include an inc from both Sep 06 12:50:14 RP: yes, that's what I did now Sep 06 12:50:48 JaMa: ah, interesting problem indeed :) Sep 06 13:17:07 rburton_: any idea why qaextras step 4b is so slow? Sep 06 13:30:03 fullstop: no Sep 06 13:30:33 RP: what does 4b do :) Sep 06 13:30:39 we need to start renaming those Sep 06 13:31:41 rburton_: not sure we can do that easily Sep 06 13:32:12 rburton_: "SDK_EXT_TYPE = 'full'" Sep 06 13:32:15 why can't we just change the string from step2 to 'api documetation build" Sep 06 13:32:24 rburton_: I wonder if we have some performance regresion with that Sep 06 13:32:29 maybe we do Sep 06 13:32:42 surely that just changes the build of the sdk itself Sep 06 13:32:49 rburton_: you have no idea what magic is behind these strings :( Sep 06 13:32:57 ah Sep 06 13:33:42 rburton_: thanks! Sep 06 13:34:03 RP: locked signatures test failed in mut again Sep 06 13:34:11 ive seen that happen occasionally and a rebuild makes it go away :/ Sep 06 13:34:15 rburton_: I wonder if the issue is slow NAS Sep 06 13:34:28 (for 4b) Sep 06 13:35:36 rburton_: AssertionError: unexpectedly None : Didn't find the expected warning message. Output: Loading cache...done. Sep 06 13:36:27 # Verify you get the warning and that the real task *isn't* run (i.e. the locked signature has worked) Sep 06 13:36:27 patt = r'WARNING: The %s:do_package sig is computed to be \S+, but the sig is locked to \S+ in SIGGEN_LOCKEDSIGS\S+' % test_recipe Sep 06 13:37:47 rburton_: wonder if that test races and something else can wipe self.testlayer_path ? Sep 06 13:38:34 nrossi: FWIW I think I've untangled the autobuilder piece of this ready Sep 06 13:39:26 kroon, RP: Hah, I guess I should be more clear with my commit messages :) Sep 06 13:41:10 rburton: I see you are still using the reprodcible_build_simple... is that just for sato? The AB is using reproducible_build currently, so I think it should be working? Sep 06 13:42:10 * Crofton|work missed a reproducible build meetup at camp :( Sep 06 13:42:53 Crofton|work: I just noticed that in the news bulletin Sep 06 13:43:22 I follow them on twitter now Sep 06 13:43:41 Crofton|work: what's twitter? Sep 06 13:43:54 how I get all my news Sep 06 13:44:12 Apparently you have MP's resigning to spend less time with their families Sep 06 13:44:38 rburton_: going to merge the systemd by default for poky-altcfg since that went green (and call that good for systemd by default in 3.0) Sep 06 13:44:58 cool Sep 06 13:45:07 Crofton|work: yes, understandably :/ Sep 06 13:45:25 Crofton|work: what an original joke i've never heard that one before Sep 06 13:46:22 rburton_: we call mut green and merge? Sep 06 13:46:46 RP: yeah Sep 06 13:46:58 RP: i do wonder if this is racing with something else wiping out the bbappend Sep 06 13:47:17 the bbappend creation should be in a per-test path so they don't conflict Sep 06 13:47:44 like the devtool workspace is in build dir Sep 06 13:47:47 that layer path is per test? Sep 06 13:48:11 rburton_, it took me a while before I understood the underlying news story Sep 06 13:48:57 RP: is it? looks like it ends up in get_test_layer which is just the first layer called meta-selftest Sep 06 13:49:09 so dropping a bbappend in there impacts all running tests Sep 06 13:49:49 New news from stackoverflow: cannot su to new user added in yocto build Sep 06 13:53:12 rburton_: which is bad and we shouldn't be doing that Sep 06 13:55:56 rburton_: I can drop the X: prefix from the pango uprev? Sep 06 13:56:31 RP: yeah thats a reminder that i need to post the patch Sep 06 13:56:44 so please strip and post Sep 06 13:56:50 * rburton_ needs to get the kids now Sep 06 14:05:44 Hi all Sep 06 14:08:57 I would like to enable the libdns-sd support in avahi. To do so, I had a look to avahi recipe in master and try to "backport it" to my rocko version as a bbappend, but it seems I missunderstood how packages are created from recipes because to expect library are missing in the final image Sep 06 14:10:51 I have customized PACKAGECONFIG with PACKAGECONFIG[libdns_sd] = "--enable-compat-libdns_sd," and then declare that the recipe generates the package if option is set with PACKAGES =+ "${@bb.utils.contains("PACKAGECONFIG", "libdns_sd", "libavahi-compat-libdnssd", "", d)}" Sep 06 14:13:01 and finally just add generated files to the package with FILES_libavahi-compat-libdnssd = "${libdir}/libdns_sd.so.*". But if I do a bitbake libavahi-compat-libdnssd, I get error: Nothing PROVIDES 'libavahi-compat-libdnssd'. What did I missed? Sep 06 14:13:40 ykrons: you bitbake a recipe, always Sep 06 14:14:16 so bitbake avahi and then look in the deploy/deb or rpm or ipk for libavahi-compat-libdnssd package Sep 06 14:15:15 rburton_: sorted, thanks for looking at that patchset Sep 06 14:15:24 * RP has another load in -next to test Sep 06 14:15:26 PACKAGES is for RPROVIDES. You can use recipes for DEPENDS only, and packages for RDEPENDS. It happens that most of the time, there is a package named after the recipe so it is confusing Sep 06 14:15:57 nrossi: mips64 and ppc are still going after 24 hours on the toolchain testsuite! :) Sep 06 14:20:32 qschulz, thanks for clarification. I will rebuild to check but think I will not have th eipk for libavahi-compat-libnsssd Sep 06 14:21:59 qschulz, nthe ipk has not been generated, but other libavahi-xxxx have been Sep 06 14:26:43 I'm doing a cleanall of avahi and a rebuild to be sure Sep 06 14:40:32 ykrons: what is the value of the PACKAGECONFIG for avahi? Sep 06 14:41:21 also, why don't you put ${libdir}/libdns_sd.so.* in the default avahi package? Sep 06 14:50:02 New news from stackoverflow: cannot su to new user added in yocto build [on hold] Sep 06 14:55:26 ykrons: all you need to do is add libdns_sd to PACKAGECONFIG for avahi Sep 06 14:58:03 rburton_, it has been done just before setting PACKAGECONFIG[libdns_sd] Sep 06 14:59:45 ykrons: then you bitbake a *recipe*, so bitbake avahi Sep 06 15:01:16 bitbake avahi is on going (after a cleanall), I tell you the result in few minutes Sep 06 15:02:19 cleanall is very rarely ever needed Sep 06 15:02:34 especially as it deletes *all* sstate (slow) and the source tarballs (why?) Sep 06 15:02:43 just bitbake avahi, it will rebuild Sep 06 15:04:24 I have changed the recipe in different ways and want to be sure to have something clean to troubleshoot, but I agree, it is probably not needed but I expect avahi not to be to long to fully rebuild Sep 06 15:17:30 qschulz, rburton_ : build finished and no libavahi-compat-libdnssd package found in deploy Sep 06 15:17:59 To clarify here is my avahi_%.bbappend: Sep 06 15:18:14 PACKAGECONFIG = "dbus ${AVAHI_GTK} libdns_sd" Sep 06 15:18:14 PACKAGECONFIG[libdns_sd] = "--enable-compat-libdns_sd," Sep 06 15:18:15 PACKAGES =+ "${@bb.utils.contains("PACKAGECONFIG", "libdns_sd", "libavahi-compat-libdnssd", "", d)}" Sep 06 15:18:15 FILES_libavahi-compat-libdnssd = "${libdir}/libdns_sd.so.*" Sep 06 15:19:00 ykrons: It won't generate a packages called libavahi-compat-libdnssd because of the so renaming Sep 06 15:19:47 ykrons: It will should be called "libdns_sd" (sorry, I don't remember the exact rules for the renaming) Sep 06 15:20:07 New news from stackoverflow: create symbolic link in bitbake recipe Sep 06 15:21:35 JPEW, you're right I have libdns_sd1... package with the expected libs Sep 06 15:21:44 but what is the "so renaming" ? Sep 06 15:22:45 ykrons: Basically, if a package contains only a library (.so), it gets renamed to a specially formatted name based on that library Sep 06 15:25:04 Ok, I don't know that point! Thanks Sep 06 15:25:09 ykrons: This allows the packaging code to look at the linktime libraries an ELF executable requires and automatically add the correct dependencies as runtime dependencies... this is why you usually don't have to add linktime library dependencies as RDEPENDS, but they still get picked up Sep 06 15:26:16 LetoThe2nd: Is library packaging (and so package renaming) on your list? I feel like I explain it a lot :) Sep 06 15:27:40 In the original recipe from master, there is also RPROVIDES_libavahi-compat-libdnssd = "libdns-sd" that I have commented, it is a way to create an "aliases" from libavahi_compat_libdnssd to libdns-sd ? Sep 06 15:29:28 ykrons: The RPROVIDES should do that? Sep 06 15:30:15 Sorry, it was a question, what is doing this RPROVIDES? Sep 06 15:33:19 I have to leave sorry, but thanks it seems my problem is solved now. Sep 06 15:33:30 ykwrons: Ok Sep 06 15:38:12 JPEW: the renaming isnt needed for that, the magic deps work if you turn off debian renaming Sep 06 15:38:20 the renaming is because early oe wanted to be like debian Sep 06 15:39:23 rburton_: Huh. I figured they were related.... it must be able to look at the RPROVIDES to determine the dependencies then? Sep 06 15:39:42 do_package of libraries writes a map of sonames to package names Sep 06 15:42:33 rburton_: The .list files in ${SHLIBSWORKDIR}? Sep 06 15:44:01 JPEW: right Sep 06 15:44:37 rburton_: Ah. Thanks! Sep 06 16:56:38 nrossi: http://git.yoctoproject.org/cgit.cgi/yocto-autobuilder-helper/patch/?id=68c19d067d663570adda351d3fe89739443dc8e9 - not merged but ready and hopefully should work with the changes you're working on Sep 06 16:57:00 moto-timo: I did figure out that autobuilder nfs patch and merged it Sep 06 16:57:55 RP: do we have a writeup to run toolchain tests Sep 06 16:58:53 khem: "oe-selftest -t toolchain-user | toolchain-system" will be the end result Sep 06 16:59:02 khem: right now with master-next its -t machine Sep 06 17:03:09 26 hours to run the ppc toolchain tests Sep 06 17:10:15 no wonder Sep 06 17:10:25 you chose the best case Sep 06 17:26:55 does yocto support shallow cloning git repos? Sep 06 17:27:00 there was some work on that here http://lists.openembedded.org/pipermail/bitbake-devel/2016-July/007657.html Sep 06 17:27:43 shallow clones are not supported, use of shallow mirror tarballs are. that is, *someone* has to do a full clone to populate a mirror, but everyone using the mirror could pull down shallow tarballs to speed things up Sep 06 17:28:14 we can't do a shallow clone because our fetcher supports fetching an arbitrary revision, while clone with shallow requires that you specify a branch and depth, and we don't know how many commits separate SRCREV and the specified branch until we've cloned it Sep 06 17:28:29 we *could* support shallow only when using AUTOREV, but that hasn't been done Sep 06 17:28:39 s/tarballs are/tarballs is/ Sep 06 17:29:24 so you can pull a tarball from a git remote? is that a standard git feature? Sep 06 17:29:53 no, you can pull a tarball from an oe/yocto mirror using our mirror support Sep 06 17:30:00 doesn't use get for that part at all Sep 06 17:30:13 ah okay Sep 06 17:30:30 the fetcher can fetch an upstream git url, convert it to shallow, tar that up, and put the tarball in your DL_DIR, then you can use that to populate a mirror to be used in PREMIRRORS Sep 06 17:30:52 oh, thats news to me Sep 06 17:31:33 still worthwhile IMO since it's nicer for the rest of the team to download a 150mb kernel tarball than a gig git repo, even if it doesn't help the person or CI job populating the mirror in the first place Sep 06 17:31:35 ..so kind of like a "download cache"? Sep 06 17:33:40 hm, an example scenario: assuming i have set up a mirror that has a git revision A of project X tar'ed up Sep 06 17:33:55 https://www.yoctoproject.org/docs/2.7.1/mega-manual/mega-manual.html#var-PREMIRRORS Sep 06 17:33:56 https://www.yoctoproject.org/docs/2.7.1/mega-manual/mega-manual.html#var-bb-BB_GENERATE_MIRROR_TARBALLS Sep 06 17:34:16 and i've got a bitbake recipe that fetches from that mirror Sep 06 17:34:36 assuming i want to change the revision to fetch to B Sep 06 17:34:47 can i do that quickly and without too much effort? Sep 06 17:36:02 you jus tmodify the recipe to change SRCREV to the new revision. when you do a new build or —runall=fetch, it'll download the new/updated git repo locally, if you set BB_GENERATE_MIRROR_TARBALLS=1, it'll also create a new git tarball, and you could rsync your local DL_DIR to the remote mirror directory to get the updated tarball there Sep 06 17:36:21 shallow works similarly, just it creates smaller shallow tarballs instead, and the user has to enable it to use them instead of the full git mirror tarball Sep 06 17:36:25 okay that sounds good, i'll read the docs, thanks Sep 06 18:50:21 JPEW: i have already done a session on packaging and package splitting. i won't be going more in depth there in the near future probably, sorry Sep 06 18:50:50 LetoThe2nd: Cool, I must have missed that one. I'll look through the archives Sep 06 18:54:28 JPEW: i think it #3 Sep 06 18:54:32 +is Sep 06 18:58:41 JPEW: if you want to witness me making a total fool of myself, tune in on tuesday :) Sep 06 19:00:07 LetoThe2nd, we are all fools Sep 06 19:00:14 just less foolish than others Sep 06 19:00:55 i'll be talking about *gasp* kernel things! Sep 06 19:02:35 * Crofton|work shivers Sep 06 19:03:57 yeah Sep 06 19:42:12 version Sep 06 19:42:16 zeddii Sep 06 19:42:51 must be Fri afternoon, sorry about that folks Sep 06 20:47:44 How can I make a change to something in sysroot before a package configures? Sep 06 20:48:02 there is a header file which was renamed and I need to either copy or symlink it for compatibility with a particular package. Sep 06 20:49:29 do_configure_prepend looks interesting Sep 06 20:50:56 why not just patch the include in the sources of the package? Sep 06 20:51:42 Modifying the sysroot is kinda asking for trouble. You might now get away with it since Yocto now has separate sysroots per recipe, but back when it didn't, you'd have modified the build env for all other packages, too. Sep 06 20:52:04 I'll consider it Sep 06 20:52:09 With the obvious unexpected side-effects of race conditions and so on, which is why it's best not to touch the sysroot. Sep 06 20:52:25 the source package is some binary doo-dad from nvidia Sep 06 20:52:40 if it's a binary, why does it care about the name of a header file? Sep 06 20:52:53 If you really need the header file back, bbappend the recipe that provides the header file and modify what it puts into the sysroot. Sep 06 20:53:45 it's a library with a header file Sep 06 20:54:20 anyway, I'll look at those options Sep 06 20:54:41 right, but if it's a header file, you can patch it ;-) Sep 06 20:55:52 well, it's a renamed header Sep 06 20:55:57 but yes Sep 06 20:57:31 Maybe I'm misunderstanding you… I'm suggesting to patch the source that uses the renamed header, not patching the header itself. Sep 06 20:58:44 that gets into cmake and I don't like that area.. :-) Sep 06 21:05:11 that may not have been that bad. thanks, neverpanic. Sep 06 21:06:01 okay, that worked.. onto the next problem Sep 06 21:10:38 gah, here had to be a single failure in -next. Now I get to play guess the patch Sep 06 21:10:44 * RP powers the build machine back Sep 06 23:41:31 * armpit has flash back to the power twins **** ENDING LOGGING AT Sat Sep 07 03:03:37 2019