**** BEGIN LOGGING AT Tue Mar 28 03:00:04 2017 Mar 28 07:41:59 pohly: Can you check I pulled v4 of your patches into -next? We hit the same failures again :/ Mar 28 07:42:28 rburton: your boost patches broke on arm Mar 28 07:44:16 RP: master-next looks alright now. The "discard_writes=True" gets added to qemurunner.py and qemutinyrunner.py, which are all implementations of the start() method that I know of. Mar 28 07:45:35 In the log that you linked to yesterday, where can I see the full build configuration? My theory was that it occurred for DISTRO=poky-tiny, but I couldn't find anything about the DISTRO in that log/. Mar 28 07:46:11 pohly: https://autobuilder.yocto.io/builders/nightly-oe-selftest/builds/235 failed the same way then Mar 28 07:46:25 pohly: https://autobuilder.yocto.io/builders/nightly-oe-selftest/builds/235/steps/CreateAutoConf/logs/stdio is the config Mar 28 07:48:06 Oh, launch(), not start(). Mar 28 07:49:24 pohly: oe-selftest -r runqemu.RunqemuTests should reproduce it Mar 28 07:49:51 I see what the problem is - I did fix something yesterday for DISTRO=poky-tiny, but not this failure with launch(). Mar 28 07:52:13 This whole code has become way too complex, with start() operating in two completely different modes :-/ Still, I should have noticed. Mar 28 07:54:13 pohly: I'm open to ideas on making it less complex :/ Mar 28 07:54:58 RP: having suffered through several blunders on my part now, I have some ideas - but that's something for 2.4. Mar 28 07:55:39 pohly: Agreed, just wanted to say I'm open to it Mar 28 07:55:58 pohly: we may have missed the window for this for -rc2 now to be honest Mar 28 07:56:49 Does it still have a chance for M4? Mar 28 07:57:00 pohly: possibly Mar 28 07:58:02 The main AB is running slowly :( Mar 28 08:03:12 V5 sent - I'll go and hide in shame under a rock somewhere now :-( Mar 28 08:04:19 * LetoThe2nd totally misread that as "hide under a shamrock" Mar 28 08:07:10 pohly: thanks. Not sure what I'm going to do about builds but I have the option now Mar 28 08:10:31 anyone good with runqemu/qemurunner? QemuRunner.stop() apparently sends SIGTERM to to runqemu ... is runqemu supposed to cleanup when this happens? It doesn't AFAICT Mar 28 08:11:50 the wall I'm banging my head into is that when this happens I'm left with a tap interface that runqemu created and it no longer has an ip Mar 28 08:13:01 on the next run runqemu finds the interface and re-uses it. This doesn't work of course because the ip is not set Mar 28 08:35:42 RP: bb.utils.which needs to be documented that it doesn't look for 'executables' but files generally, as it's used when looking for SRC_URI entries and stopping it find directories breaks things :) Mar 28 08:43:35 jku: sounds like the exact behaviour I've seen with runqemu for ages now :( Mar 28 08:43:54 I thought it was something to do with Fedora Mar 28 08:44:09 bluelightning: I'm on debian so no :/ Mar 28 08:44:21 hmm, ok Mar 28 08:44:43 for me the problems started occurring when I moved to Fedora some years ago, but then that could just have been coincidence Mar 28 08:45:07 in any case it would be a good thing to solve but I don't have much in the way of clues as to what's broken Mar 28 08:45:18 I don't _think_ this used to happen to me before... Mar 28 08:45:49 but it really became a problem when testing a oe-selftest that runs qemu multiple times Mar 28 08:59:55 kanavin: nativesdk-dnf causes errors here Mar 28 09:00:06 systemd bits not being packaged Mar 28 09:13:53 rburton: which is designed to look for files, yes. I was kind of abusing it for HOSTTOOLS Mar 28 09:14:13 seemed like a good idea at the time :/ Mar 28 09:16:50 i'll file a bug for the problem that happened yesterday Mar 28 09:27:17 is it end of university project time somewhere again? Mar 28 09:27:42 LetoThe2nd: ? Mar 28 09:29:32 CTtpollard: feels like a recent rise in very simple questions on the ML lately, with little to no context and own research visible. Mar 28 09:38:16 * RP fires M3-rc2 Mar 28 09:54:13 joshuagl, rburton: I can't help feel there is something wrong with sstate reusage on the main AB :( Mar 28 09:54:27 the whole idea of a prebuild was it wouldn't be rebuilding stuff :/ Mar 28 09:57:36 RP: probably the logic around using a separate SSTATE_DIR for a release Mar 28 09:59:24 joshuagl: but it found sstate artefacts? Mar 28 10:00:54 RP: sorry, I'm not sure I understand the problem Mar 28 10:04:37 joshuagl: https://pastebin.com/rdN6wr84 Mar 28 10:05:15 so the previous build created that sstate object if it didn't exist. Both f24 and f25 use universal uninative (not 4.8/4.9) Mar 28 10:06:41 joshuagl: its confusing as the environment variables differ from what is written into auto.conf Mar 28 10:06:53 SSTATE_DIR ?= "/srv/www/vhosts/autobuilder.yoctoproject.org/pub/sstate/2.3/" Mar 28 10:06:54 SSTATE_MIRRORS += "\ Mar 28 10:06:54 file://.* http://sstate.yoctoproject.org/dev/PATH;downloadfilename=PATH" Mar 28 10:07:50 joshuagl: so despite the different sstate dir, the mirror url should technically have covered it Mar 28 10:11:32 the environment variables not matching the auto.conf is worrying Mar 28 10:12:06 joshuagl: what worries me more is bitbake appears not to be finding the native sstate Mar 28 10:12:28 failing to update uninative? Mar 28 10:13:04 NATIVELSBSTRING = "fedora-24" Mar 28 10:13:10 that means it's not using uninative, right? Mar 28 10:14:05 joshuagl: no :/ Mar 28 10:14:13 joshuagl: well, hmm Mar 28 10:14:55 joshuagl: I wonder if that is the issue :/ Mar 28 10:15:09 seems likely Mar 28 10:15:18 need to understand why, of course Mar 28 10:15:40 I wonder also if we/I need to restart the workers (for the environment not being as expected) Mar 28 10:16:30 joshuagl: it depends what this environment is used for Mar 28 10:17:38 joshuagl: the NATIVELSB string is printed incorrectly for a clean tmpdir where uninative hasn't been downloaded yet. I just confirmed the mirrors do get checked correctly though Mar 28 10:17:51 RP: OK, good Mar 28 10:18:09 I noticed that a while ago Mar 28 10:20:45 its an annoying artefact of the way we fitted uninative into the build process :( Mar 28 10:20:59 The urls its looking for sstate in look bust :/ Mar 28 10:21:17 * RP looks at the bitbake fetcher code sternly Mar 28 10:29:25 hmm, no, the fetcher is doing the right thing :/ Mar 28 10:33:03 AB configuration is awry, then? Mar 28 10:35:22 joshuagl: actually, found it. We have races :/ Mar 28 10:35:59 joshuagl: https://pastebin.com/VZbNv5QC Mar 28 10:36:15 joshuagl: multiple builds downloading the same file? Mar 28 10:36:42 RP: hmm, could be Mar 28 10:37:09 joshuagl: grep https://autobuilder.yoctoproject.org/main/builders/nightly-deb-non-deb/builds/743/steps/BuildImages/logs/stdio for WARNING Mar 28 10:37:23 joshuagl: its racetastic :/ Mar 28 10:38:08 ouch, ~50 sstate failed to stage Mar 28 10:38:28 joshuagl: which does make sense when you think of the thundering start of build herd Mar 28 10:38:47 clearly something in the fetcher locking failed Mar 28 10:38:58 RP: yeah, does seem to make sense Mar 28 10:39:12 or even with the locking, its racy :/ Mar 28 10:39:43 the lock isn't held whilst unpacking Mar 28 10:40:04 ah well, we have an idea what is bust now Mar 28 11:04:42 What is the purpose of host sysroot ? Mar 28 11:05:16 joshuagl: this rabbit hole just gets more and more crazy Mar 28 11:09:03 RP: hmm, found the Mad Hatter's tea party in there? Mar 28 11:11:29 Does anyone knows what is the purpose of host sysroot ? Why do we need the libraries there ? Mar 28 11:11:31 joshuagl: we're mapping a file:// url to an http:// one. file:// urls don't have done stamps, http ones do. This creates some interesting codepaths Mar 28 11:12:08 RP: urgh, my faulty assumptions biting us here Mar 28 11:19:31 What is the purpose of host sysroot ? Mar 28 11:21:18 ranchu: somewhere to put native tools we need? Mar 28 11:22:39 Is it that this native tools are using some libraries in that host sysroot ? I mean, the libraries in host sysroot have no relation to the packages installed in target, Right ? Mar 28 11:22:54 RP. Mar 28 11:23:26 ranchu: some native tools need libraries and yes, there can be no relation to the target Mar 28 11:23:37 RP- many thanks! Mar 28 11:24:33 RP - one more, can you give some example when we need this host sysroot ? I don't see any example for that. Mar 28 11:24:44 some practical example Mar 28 11:25:03 ranchu: somewhere to put gcc-cross? or pseudo-native? or any other native tool we use? Mar 28 11:27:35 RP - OK, got it. Mar 28 11:27:40 Thanks. Mar 28 11:29:06 joshuagl: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip-rss2&id=4f5668a6a74bbe855297b9d8110904fdbb95d74e is what I think might fix this... Mar 28 11:29:27 * RP isn't even sure how to test that :/ Mar 28 11:31:58 rburton: thanks for fixing Mar 28 11:32:40 np Mar 28 11:32:45 trivial Mar 28 11:33:14 RP: I can try and run it through a one machine AB in release mode? Mar 28 11:33:47 joshuagl: that wouldn't race though? Mar 28 11:34:17 RP: right, I'd need at least two workers and a pre-seeded build Mar 28 11:34:54 joshuagl: dnf is running on python 3 now :) Mar 28 11:35:23 kanavin: nice! that was fast Mar 28 11:35:40 joshuagl: yes, because my head is still in that space Mar 28 11:35:49 would've been more difficult to do several weeks from now Mar 28 11:36:11 I have a single-tasking, obsessive brain :) Mar 28 11:36:21 joshuagl: we could test on the new cluster which is idle atm Mar 28 11:36:33 joshuagl: that might work since we've not done release builds there Mar 28 11:36:58 RP: yes, good idea Mar 28 11:37:16 joshuagl: I can put that in master-next and fire a test build? Mar 28 11:37:35 joshuagl: well, let me put in -next and let you fire a test build with the right config? Mar 28 11:37:46 RP: works for me, thanks Mar 28 11:38:38 joshuagl: done Mar 28 11:38:54 kanavin: nice to maximise on the hot cache :) Mar 28 11:41:51 RP: ack, will fire the pre-build now Mar 28 11:42:19 joshuagl: you shouldn't need a prebuild given the master-next it just ran Mar 28 11:42:41 RP: great Mar 28 11:42:43 thanks Mar 28 11:43:22 RP: what was the issue with gpg on debian testing that you are trying to figure out? Mar 28 11:43:26 marquiz: ^^^ Mar 28 11:44:00 I run debian testing too, and one thing that's a problem is that it seems to serialize the signing through a central 'agent' process, so it's much slower than it could be Mar 28 11:44:18 people have been complaining here https://bugs.gnupg.org/gnupg/issue2813, but it could be debian specific Mar 28 11:44:47 kanavin: it appeared to lock up entirely on a build, was going for 30+ hours before I killed the gpg processes Mar 28 11:45:25 RP: possibly something ran out of resources somewhere and decided to lock up instead of failing? Mar 28 11:46:00 kanavin: I don't know. marquiz was going to write it up in a bug, ideas would be welcome Mar 28 11:46:23 RP: I don't know either :( Mar 28 12:07:54 RP: build is looking much better with that patch Mar 28 12:09:47 "cc1: error: unknown pass static specified in -fdisable" Mar 28 12:10:11 has anyone seen this before? what could it possibly mean? #crypticgccerrors Mar 28 12:17:36 kanavin: some vague recollection... is there a "--disable-static" somewhere that it should not be in? Mar 28 12:17:56 jku: yes, there is Mar 28 12:18:18 not sure why that is a problem, but it's present in the command line Mar 28 12:18:34 | x86_64-poky-linux-gcc -m64 -march=core2 -mtune=core2 -msse3 -mfpmath=sse --sysroot=/home/ak/development/poky/build-64/tmp/work/core2-64-poky-linux/openssl11/1.1.0e-r0/recipe-sysroot -I. -Icrypto/include -Iinclude -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM Mar 28 12:24:26 joshuagl: cool :) Mar 28 12:30:00 Hi! I'm giving a look at why 'devtool build linux-raspberrypi' fails (at least with current masters, but I guess it has been broken for a while...). Is anyone aware of the issue? Seems to be related to how linux-raspberrypi deviates from typical linux-yocto practices... noticed while also investigating on why kernel config fragments don't work either Mar 28 12:32:06 kanavin: https://bugzilla.yoctoproject.org/show_bug.cgi?id=11258 Mar 28 12:32:08 Bug 11258: normal, Undecided, ---, paul.eggleton, NEW , rpm signing failed with gpg hanging Mar 28 12:35:58 marquiz: didn't we see this earlier that when rpm runs gpg as subprocess, and gpg fails, rpm is not able to detect that and waits forever+ Mar 28 12:36:14 so there are two issues here really Mar 28 12:37:32 kanavin: hmm, i don't remember that (anymore) Mar 28 12:38:00 i just remember rpm getting stuck because gpg was asking for passphrase or smth Mar 28 12:41:47 marquiz: I think gpg will quit if no passphrase is given after a timeout, but rpm would be still stuck Mar 28 13:03:31 kanavin: that could well have been it Mar 28 13:04:55 joshuagl: now wondering how https://autobuilder.yocto.io/builders/nightly-x86-lsb/builds/222/steps/Running%20Sanity%20Tests/logs/stdio broke as I added that to DL_DIR :/ Mar 28 13:05:46 joshuagl: does a release build use different sources? Mar 28 13:08:48 [pokybuild@fedora25 ~]$ ls /srv/autobuilder/autobuilder.yoctoproject.org/current_sources/galculator-2.1.4.tar.bz2 -la Mar 28 13:08:49 -rw-r--r--. 1 pokybuild users 472989 Sep 5 2015 /srv/autobuilder/autobuilder.yoctoproject.org/current_sources/galculator-2.1.4.tar.bz2 Mar 28 13:08:59 so why is it downloading it :/ Mar 28 13:10:01 RP: fairly certain it doesn't use a different DL_DIR Mar 28 13:10:33 joshuagl: /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-lsb/build/meta/lib/oeqa/utils/buildproject.py in _download_archive - why isn't that triggering? :/ Mar 28 13:12:06 dl_dir defaults to None, presumably the caller is passing a non-default value? Mar 28 13:12:26 joshuagl: dl_dir = cls.tc.td['DL_DIR'] from /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86-lsb/build/meta/lib/oeqa/runtime/cases/buildgalculator.py ? Mar 28 13:16:26 joshuagl: that build does seem to be turning around quite fast though :) Mar 28 13:17:35 the same paths seem to work on the production cluster :-/ Mar 28 13:18:03 joshuagl: well, the issue is if something races on this location in /tmp/ Mar 28 13:18:10 joshuagl: if nothing races, it "works" Mar 28 13:18:28 joshuagl: need to figure out where/why DL_DIR isn't being set or being used Mar 28 13:18:43 that means the tests won't hit the network and will be faster and more reliable Mar 28 13:23:32 joshuagl: are you looking into that one or should I poke it (or file a bug?) Mar 28 13:24:18 RP: I'm looking Mar 28 13:24:35 joshuagl: cool, thanks Mar 28 13:24:54 * RP adds to cache drop list Mar 28 15:09:10 morty (2.2) seems that the file-native recipe is broken at the do_fetch task Mar 28 15:09:45 hopefully not again... Mar 28 15:10:37 CTtpollard: seems so, revision does not exist, the same problem as in master Mar 28 15:10:44 will send a patch for this Mar 28 15:11:13 Are you upto date with the head of morty? If so the file upstream really needs to stop rebasing Mar 28 15:11:47 CTtpollard: f518787: Robert P. J. Day: Mon Mar 27 11:08:34 2017 +0100: classes: Replace "if test" file tests with POSIX file tests Mar 28 15:11:54 CTtpollard: that is HEAD Mar 28 15:11:58 ouch Mar 28 15:12:19 lsandov: that branch sounds like master Mar 28 15:14:31 RP: sorry, copied wrong commit shortlog Mar 28 15:15:20 the head of OE-core master&morty has a revert commit for files uri Mar 28 15:15:59 the commit mentioned in master still exists in the file repo afaict Mar 28 15:17:33 you might need to do a fetch lsandov Mar 28 15:18:47 CTtpollard: yes, double checking. Starting from scratch Mar 28 15:24:45 CTtpollard: mm strange, both SRCREVs (master and morty) do exist but I do have hte fetcher problem Mar 28 15:25:06 CTtpollard: it is happening at file-native Mar 28 15:26:49 CTtpollard: perhaps my DL_DIR have the old repo with old commit ids, let me check Mar 28 16:01:27 kanavin: you there? Mar 28 16:04:13 CTtpollard: seems to be problem in my build host, sorry for the noise Mar 28 16:07:32 joshuagl, rburton: 3h20 selftest: https://autobuilder.yocto.io/builders/nightly-oe-selftest/builds/236 :) Mar 28 16:07:36 getting better Mar 28 16:07:37 ! Mar 28 16:07:41 that's awesome Mar 28 16:07:51 \o/ Mar 28 16:07:56 nice. Mar 28 16:08:04 * joshuagl has a fear when notifications pop up with autobuilder urls Mar 28 16:08:09 hehe Mar 28 16:08:11 rburton: that was the last bit to finish too, the rest beat it by some margin (thanks to hot sstate) Mar 28 16:08:32 joshuagl: understandable given recent issues :/ Mar 28 16:09:42 I should try and keep my todo list light during M3 next cycle ;-) Mar 28 16:10:22 RP much better that 6-8 hrs Mar 28 16:10:47 6-8 was a good run Mar 28 16:10:53 i've seen 14 Mar 28 16:11:03 rburton: or 36 :) Mar 28 16:11:05 we were spending longer than 3h20 just on kernel cloning recently Mar 28 16:11:24 what? why joshuagl? Mar 28 16:11:32 joshuagl: 3h30 + 5h kernel clone ~= 8 hours Mar 28 16:12:32 how about the selftest harness monkey-patches cleanall to be a fatal error :) Mar 28 16:12:34 lsandov: cloning linux-yocto to NFS is slow (NFS doesn't like creating lots of small files) and one of our tests was doing a cleanall for linux-yocto → recipe for frustration Mar 28 16:13:21 got it. Mar 28 16:13:24 RP: sounds like that clone was masking recent speed improvements? Mar 28 16:13:37 joshuagl: yes Mar 28 16:14:16 rburton: I was tempted by a local commit hook failing any patch which contained cleanall Mar 28 16:14:29 ha Mar 28 16:14:33 RP: graphs look better if we make it seem like one massive speed improvement ;-) Mar 28 16:15:05 joshuagl: :) Mar 28 16:16:43 just don't forget to sneak in that "slow everything down week by week" commit so we can revert it in m3 next cycle Mar 28 16:16:52 WHOOPS wrong channel Mar 28 16:16:57 there are several pending tasks for reducing oe-selftest, many test cases behave different when doing it manually that in the oe-selftest environment Mar 28 16:17:04 * rburton kidding Mar 28 16:19:11 rburton: you had to spoil it... Mar 28 16:19:41 lsandov: we're definitely not done yet, its just nice to have it behaving better Mar 28 16:20:31 right Mar 28 16:49:02 * pidge hides from autobuilder discusssions Mar 28 16:50:32 pidge: you mean we can't assign all the bugs to you? :) Mar 28 16:51:00 RP: You are more than welcome to assign them. And I am more than welcome to ignore them. Mar 28 16:51:42 pidge: I wish I could do that... Mar 28 16:56:23 lol Mar 28 18:16:31 Hi, I'm having some trouble making some changes to a Yocto build for a Freescale i.MX6 board I'm working with; specifically a Hummingboard2 ... Mar 28 18:16:52 I think the problems unfortunately stem more from my lack of understanding within Yocto though Mar 28 18:17:51 anyone here that might be able to help? Mar 28 18:22:36 mhilt: what's the problem Mar 28 18:23:25 I started, working mostly from this guide: http://wiki.solid-run.com/doku.php?id=products:imx6:software:os:yocto Mar 28 18:23:58 unfortunately, the source all seems still in Fido, so I guess it's somewhat old Mar 28 18:24:30 mhilt: make sure all meta layers are aligned with Fido Mar 28 18:24:40 mhilt: are you using repo ? Mar 28 18:25:00 I think that is the case, I pulled from all Fido branches Mar 28 18:25:22 what is the error Mar 28 18:25:26 the build works ... Mar 28 18:25:28 that isn't the issue Mar 28 18:25:37 problem is that I need a driver built that doesn't build Mar 28 18:25:47 when I try to make changes, I run into issues Mar 28 18:26:01 to start, I was building core-image-x11 Mar 28 18:26:31 I need a specific camera driver to build ... Mar 28 18:26:43 so one thing I'm not sure about, is where I'm supposed to be doing kernel config ... Mar 28 18:27:11 Solidrun has a layer that includes a kernel linux-solidrun-imx6 Mar 28 18:27:43 I have changed that configuration and seem to be able to rebuild the changes Mar 28 18:28:08 but if I later try to build core-image-x11 again, I lose all those changes Mar 28 18:28:33 ok, so config fragment is not ending in the final config Mar 28 18:30:11 should I be using config for virtual/kernel ? Mar 28 18:30:54 these seem to be different, but I don't really understand how that's structured Mar 28 18:33:40 kernel recipes usually provide virtual/kernel and they may be multiple providing the same, so you need to decide (if not decide yet by solid run meta layer) the preferred provider Mar 28 18:39:55 is the preferred provider indicated in the kernel .bb file? Mar 28 18:42:13 no, it a conf file Mar 28 18:45:45 okay, I see: PREFERRED_PROVIDER_virtual/kernel = "linux-solidrun-imx6" Mar 28 19:32:42 RP: hey! How to report a bitbake/fetcher bug/issue? Mar 28 19:34:54 zecke_: https://bugzilla.yoctoproject.org/buglist.cgi?query_format=specific&order=relevance%20desc&bug_status=__open__&product=BitBake&list_id=594021 Mar 28 20:01:27 mhilt: exactly Mar 28 20:02:04 zecke_: bugzilla.yoctoproject.org Mar 28 20:10:39 lsandov: thank you. Filed #11262 Mar 28 20:12:47 zecke_: seems that you already found a fix Mar 28 20:17:00 but it is only partial (as indicated in the ticket) Mar 28 20:18:04 thanks zecke_ Mar 28 20:20:03 zecke_: that perhaps solves for wget Mar 28 20:53:07 I am hoping to find someone to chat with about implementing SELinux on a Beaglebone black Mar 28 20:55:28 add in the meta-selinux layer, you will need to add 'selinux' to your distribution configuration to get started.. Mar 28 20:55:49 the base version in meta-selinux may require work, especially to upgrade to master or to implement the policy you require Mar 28 20:57:06 can this be accomplished as a bitbake scripts parameter once the BSP is setup from yoctoproject.org? Mar 28 20:58:01 depends on what you need, but most likely it means you will need to set parameters in your local.conf and/or custom distro.conf file(s) -- as well as create .bbappends in your own project to configure selinux behavior Mar 28 20:59:10 first step is to download meta-selinux and add it to your project. You can switch to the oe-selinux or poky-selinux distro as a starting point Mar 28 21:01:10 I don't recall seeing meta-selinux as a download option form yoctoproject.org... where is this referenced from? Mar 28 21:01:30 go to layers.openembedded.org -- pick the branch you want and then search for it.. Mar 28 21:01:34 then download fromt he url given Mar 28 21:04:33 I see it at https://layers.openembedded.org/layerindex/branch/master/layer/meta-selinux/. So this is basically a layer that will be added onto my BBB BSP from yoctoproject.org when I bit bake the local server project Mar 28 21:16:26 Thank you fray for your help! Mar 28 21:25:43 I see that the OE core "contains only emulated machine support". Does this mean that there will be significant performance reduction on my hardware? I do not care about sound or video on my BBB... Mar 28 21:26:24 you need to select a layer that provides the BSP for your hardware or create one for you. The OE group only supports QEMU.. Mar 28 21:26:54 OE-Core itself only provides QEMU-based machine configurations, to be techically correct Mar 28 21:27:09 other machine configurations are provided via a BSP layer Mar 28 21:27:09 Oh, I see. So I get full hardware capabilities once the BSP for BBB is used in project compilation? Mar 28 21:27:17 yes Mar 28 21:27:33 Thanks! Mar 28 21:28:28 hello Mar 28 21:28:49 is there a way to print a single recipe using bitbake? Mar 28 21:29:20 bitbake -e recipename will dump all the metadata for a given recipe Mar 28 21:29:23 e.g. using bitbake -s to list packages, then try to get the url for all of them to do some bookkeeping Mar 28 21:29:24 see bitbake --help Mar 28 21:30:04 a nice, wasn't obvious that most of the options take package names Mar 28 21:30:29 (obvious after reading --help output more carefully :-) Mar 28 21:30:42 thanks Mar 28 21:39:24 robsta: perhaps it's not clear from the help text, but the recipe name isn't an argument for the option - it's just a general argument for the command Mar 28 21:41:26 bluelightning: seems -s doesn't honor it :) Mar 28 21:41:48 passing a recipe Mar 28 21:41:54 robsta: right, -s lists all recipes and ignores any target arguments Mar 28 21:42:06 well, lists all targets I should say Mar 28 21:42:16 Hmm Mar 28 21:42:32 would really be nice to make bitbake-diffsigs compare a bit more intelligently Mar 28 21:42:40 add word diff with color for strings Mar 28 21:42:48 kergoth: FYI I have been working on just that Mar 28 21:43:02 variable changed from <873 characters> to not helpful Mar 28 21:43:04 bluelightning: ah, nice :) Mar 28 21:43:06 kergoth: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=paule/sigstuff Mar 28 21:43:15 that's one of the first things I fixed ;) Mar 28 21:43:18 bluelightning: doesn't matter really, asking for a friend who's looking to get all input sources easily Mar 28 21:43:35 robsta: archiver.bbclass ? Mar 28 21:43:49 bluelightning: for prefetching or some such Mar 28 21:44:14 in a CI env Mar 28 21:44:51 robsta: oh, right - for pre-populating a source mirror typically we just recommend bitbake -c fetchall Mar 28 21:45:36 that could be useful, not sure to what extent he wants to frob the proxying Mar 28 21:45:43 kergoth: I should be tidying up that patchset today and submitting what I can FWIW Mar 28 21:46:20 bluelightning: distributed CI env Mar 28 21:46:43 anyhow, thanks, will pass it on Mar 28 22:12:04 bluelightning: fyi, tried your branch and it changed the info it showed. without it, i see a Variable changed of an RDEPENDS, with it, i see the change to runtaskdeps, but no info about what variable changed to cause that dependency changed. this gives me less context as to the root cause, not more Mar 28 22:12:32 though i did merge it into our branch, could be i messed up the merge, but worth testing.. Mar 28 22:12:53 kergoth: right - this is with a simple change to RDEPENDS_${PN} value? Mar 28 22:13:01 yep Mar 28 22:13:09 ok, I'll check it out Mar 28 22:13:10 well, not directly, but that's the result Mar 28 22:13:26 this is why I hadn't submitted the patchset yet :) Mar 28 22:13:37 thanks Mar 28 22:15:56 bluelightning: this speccific example alters DISTRO_FEATURES for a single recipe to alter its default PACKAGECONFIG, which changes the rdeps. specifically DISTRO_FEATURES_remove_pn-libsdl = "opengl", which drops the opengl packageconfig. i have noi dea why this append didn't modify PACKAGECONFIG directly, but .. this is what showed the behavioral difference in bitbake-diffsig, if oyu want to try it specifically there Mar 28 22:16:15 erm, it was an append, not a _pn-, but presumably would do it with either Mar 28 22:16:22 s/append/bbappend/ Mar 28 22:16:31 * kergoth caffeine insufficiency Mar 28 22:16:39 looks promising, though :) Mar 28 22:16:52 i wonder how much work it'd be to teach difflib to emit wdiff format word-based-diff info Mar 28 22:17:23 would be nice for really long single lines, like that rdepends Mar 28 22:18:00 indeed, yes Mar 28 22:19:57 kergoth: there's this, not quite like what git does with --word-diff, but could be made to be: https://github.com/paulgb/simplediff/tree/master/python Mar 28 22:24:32 yo warthog9! Mar 28 22:25:02 warthog9 is in yocto land?! Mar 28 22:28:55 * warthog9 waves at ulf` Mar 28 22:29:05 clsulliv: it's been known to happen Mar 28 22:30:29 warthog9: the scars aren't so bad? :) Mar 28 22:44:05 warthog9: miss us already? ;) Mar 28 22:44:32 ulf`: lol I've been hanging out in here for years ;-) Mar 28 22:45:52 RP: did a bit more work/speed improvements on pkgdataui. if you have ideas on what should be implemented next then email Mar 28 22:45:57 but now bed Mar 28 22:46:19 rburton: remind me tomorrow :) **** ENDING LOGGING AT Wed Mar 29 03:00:03 2017