**** BEGIN LOGGING AT Wed Mar 15 03:00:03 2017 Mar 15 07:03:06 Hi, how can I export the kernel source code of my current build so that I get a nice git-repository with the mainline kernel and all the additional patches on top? Mar 15 07:04:09 In short: How to get a kernel-git-directory with all the commits of a local build? Mar 15 07:04:28 kalpu: i don't think there's a build-src-to-git converter. Mar 15 07:04:53 kalpu: as there is no reason git is even involved in that build flow Mar 15 07:05:01 How can I do this by hand? Mar 15 07:05:21 How can I list all patches getting applied to a kernel-version in my current build? Mar 15 07:06:08 kalpu: bitbake -e virtual/kernel should give you the complete SRC_URI, which should contain the starting point and all patches. Mar 15 07:07:21 kalpu: but usually things are done the other way round. you have a kernel repo that you tinker with until you are satisfied, and then pour that into a recipe Mar 15 07:07:52 I know, but this time it's the other way... Mar 15 07:08:44 wow "bitbake -e virtual/kernel | wc -l" shows 22494 lines... I will NOT read this. Is there another more human possible approach? Mar 15 07:09:27 kalpu: *sigh* bitbake -e virtual/kernel | less, and then "/SRC_URI" ... Mar 15 07:10:51 ;) ... okay thx Mar 15 07:56:33 hi everyone Mar 15 08:00:23 would it be possible to compile a package twice but with a different configuration? Mar 15 08:05:56 hi, wenn i switch from linux-xlnx to linux-xlnx-dev ethernet stops working, and I don't see the eth0 interface anymore. Mar 15 08:22:05 I have a problem with /etc/group, in my image build directory (rootfs) there is group file containing avahi-autoipd group but it is not present in the file in my final filesystem... Mar 15 08:22:29 does anyone knows why Mar 15 08:22:30 ? Mar 15 08:49:24 hi there ! Mar 15 08:50:12 I have a compilation issue when compiling gstreamer1.0 : it includes a DEPENDS="glib-2.0" but do_configure is started before populate_sysroot from glib-2.0 is finished Mar 15 08:51:20 from what I understand of the DEPENDS it should not happen... but seems to be parallel jobs related... Mar 15 10:06:40 Heya, does anyone know how t get the linux kernel headers working? I keep missing things like curses.h and files like that Mar 15 10:07:57 maka_: *crystalballmode* *on* i guess you are talking about in-target Mar 15 10:08:33 Yes, sorry if im not clear enough Mar 15 10:09:03 Im trying to run a ./configure, but it throws the error Failed to find Linux sources Mar 15 10:09:33 DISTRO_FEATURES tools-sdk is enabled? Mar 15 10:09:42 Besides that when im trying to run the "make all modules" it misses files like curses.h curses_dll.h and some more header files Mar 15 10:10:31 (besides that being a totally horrible, hacky, unreproductible approach and all, of course.) Mar 15 10:11:10 oh iknow, i'm just trying to figure something out Mar 15 10:11:11 ah no IMAGE_FEATURES it is. tools-sdk and dev-pkgs Mar 15 10:12:01 i only have the EXTRA_IMAGE_FEATURES set to debug-tweaks and package-management Mar 15 10:12:17 well then. please see: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#ref-features-image Mar 15 10:12:51 and in the core-image-base.bb IMAGE_FEATURES set to splash, which is default Mar 15 10:13:19 splash has absolutely nothing to do with that. Mar 15 10:13:45 i know, it's just a default thing Mar 15 10:15:08 my kernel is missing dmaengine and dma-mapping and so forth Mar 15 10:15:21 but I think I enabled it in the menu config... Mar 15 10:15:41 yourfate: what does /proc/config.gz say? Mar 15 10:18:35 luchtime, I'll check afterwards. Mar 15 10:24:36 still had some time, grepped for "dma", uploaded the results: https://gist.github.com/youRFate/c57d18b671441ce7e6c888d4774a8123 Mar 15 10:24:58 it's linux-xlnx, 4.6 Mar 15 10:25:25 running on digilent zybo board (xilinx zynq) Mar 15 10:26:15 yourfate: seems like the kernel at least has dma and dmaengine, then. Mar 15 10:26:32 shouldn't I see the associated .h files then? Mar 15 10:26:41 in usr/include/linux ? Mar 15 10:26:42 yourfate: um, why? where? Mar 15 10:27:23 food time, bbl, thanks so far! Mar 15 10:40:56 LetoThe2nd: it does indeed find the header files now, yet i still get the error that it can't find configured linux sources Mar 15 10:46:49 maka_: sounds like you also need the kernel-dev package Mar 15 10:46:51 maka_: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=68a8caa738caa25f313a0bccfd8179cc5584afa5 Mar 15 10:51:56 LetoThe2nd: Am i supposed to create a completely new image with that? Mar 15 10:52:25 maka_: you can install it whatever way you see fit. its a package like any other in the end Mar 15 10:52:52 But, the one you send looks like a full yocto folder? Mar 15 10:53:47 huh?!? Mar 15 10:54:19 i sent you a link to a commit that also explains what it is and why and where. Mar 15 10:55:40 and as you can see from the commit date, the poky revision you are using hopefully already includes this commit, so the packages mentioned should be available in your build Mar 15 11:20:23 joshuagl, ed2: https://autobuilder.yoctoproject.org/main/builders/nightly-wic/builds/648 Mar 15 11:20:35 rburton: https://autobuilder.yoctoproject.org/main/builders/nightly-oe-selftest/builds/848 :( Mar 15 11:21:09 and https://autobuilder.yoctoproject.org/main/builders/nightly-arm-lsb/builds/1056/steps/Running%20Sanity%20Tests/logs/stdio which was clearly cosmic rays :/ Mar 15 11:28:42 hmm, oe-selftest failure is interesting. ed isn't in the sstate-cache? Mar 15 11:29:19 RP: sstate pruning gone mad again? Mar 15 11:30:09 joshuagl, rburton: except that oe-selftest doesn't use the common sstate iirc? Mar 15 11:30:10 RP: re 1056 wget exit 4 is 'network failure' Mar 15 11:30:31 rburton: right, hence cosmic rays. We should ensure the AB has a local copy of that file... Mar 15 11:31:07 maybe change the test to use the source mirrors Mar 15 11:31:09 RP: joshuagl: looks like ab is looking for wic images in the wrong place. wic puts images into tmp/deploy/wic_images//*/*/*.direct, but ab is looking into tmp/deploy/wic_images//*/*/build/*.direct Mar 15 11:31:25 RP: ed: was just about to say that. What changed? Mar 15 11:31:31 iirc that has worked up until recently? Mar 15 11:33:21 rburton: I just added gcalc locally to the source mirror so that should hopefully be avoided Mar 15 11:33:27 (and faster) Mar 15 11:33:59 ed2: looks like we've been publishing wic artefacts from that directory since we first started publishing wic artefacts in ~July 2016 Mar 15 11:35:27 joshuagl: I didn't change wic lately. wic is running with -o /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-wic/build/build/tmp/deploy/wic_images//directdisk// Mar 15 11:35:51 joshuagl: could it be so that we're publishing some old images? Mar 15 11:36:21 joshuagl: I did some work related to output directory location some time ago. Mar 15 11:37:02 rburton: I did check the nas logs fwiw and it never touched a file called that... Mar 15 11:37:18 ed2: how long ago? Mar 15 11:37:39 joshuagl: remember that the publishing step isn't triggered until milestones which is why we only find out about issues like this now :/ Mar 15 11:37:52 RP: joshuagl: it was merged in the start of Feb: https://bugzilla.yoctoproject.org/show_bug.cgi?id=10783 Mar 15 11:37:53 Bug 10783: minor, Medium+, 2.3 M3, eduard.bartosh, RESOLVED FIXED, wic should not be writing out to /var/tmp/wic Mar 15 11:38:30 ed2, joshuagl: that fits the timeline between M2 and M3 Mar 15 11:39:51 RP: ed2: ah, ok. So we need to publish wic artefacts differently for pyro or newer? Mar 15 11:40:47 joshuagl: appears so, or on the last layer version bump Mar 15 11:42:54 RP: ed2: OK, I'll work on it Mar 15 11:43:27 joshuagl: hm, this build was green 2 days ago: https://autobuilder.yoctoproject.org/main/builders/nightly-wic/builds/647 Mar 15 11:43:49 ed2: the final publishing step isn't usually enabled in test builds Mar 15 11:44:13 ah, ok. now I understand. thanks Mar 15 11:52:52 Yay! My custom board arrived this morning. Now I better put my money where my mouth is and get (Yocto built) Linux up and running on this thing..! :p Mar 15 11:54:05 I'm working at a company and this is our first Linux based board. Everything up until now has been RTOS based on smaller processors. :) Mar 15 11:58:18 JoiF: nice :) Mar 15 12:00:26 https://hastebin.com/opumaginoz.coffeescript Mar 15 12:00:34 problem building qtwebengine for agl Mar 15 13:13:42 Hi! In the last few weeks I have been incrementally generating and publishing some eSDK updates via oe-publish-sdk for an image of mine. What I often see but didn't expect is the need for the updated SDK to rebuild a lot of stuff as soon as I try to 'devtool build something' just after the upgrade. Since my understanding of taskhashes and locked signature is really poor, I hope someone can tell me if the Mar 15 13:13:48 WARNING/ERRORS I pasted at http://pastebin.com/raw/DJYhPh28 are related and if so, I'd appreciate any clue to dig further the root cause Mar 15 13:38:31 joshuagl, rburton: SSTATE_MIRRORS += "\ \n file://.* http://sstate.yoctoproject.org/dev/PATH;downloadfilename=PATH" is in auto.conf for oe-selftest so I think we can suddenly understand how that test breaks Mar 15 13:40:29 Confirmed that adding that to local.conf here makes it break Mar 15 13:49:51 RP: ah, OK. That makes sense Mar 15 13:49:53 hmm Mar 15 13:50:32 joshuagl: I have a fix for the test. I'd just forgotten the above was even enabled Mar 15 13:50:50 ok, great! Mar 15 13:53:37 * RP feels happier knowing how that test broke Mar 15 13:54:00 joshuagl: did we only add sstate mirrors to selftest recently? Mar 15 14:00:12 that auto.conf change happened a few weeks ago, I think. Mar 15 14:00:19 hmm, did I add different code paths for a release? Mar 15 14:00:22 * joshuagl checks Mar 15 14:02:57 joshuagl: this could be important... Mar 15 14:04:37 RP: I didn't. I was getting mixed up with SSTATE_DIR which is handled differently for a release **** BEGIN LOGGING AT Wed Mar 15 16:22:12 2017 Mar 15 16:42:12 hi everyone Mar 15 16:42:45 would it be possible in a same image to compile a package twice with two different configurations Mar 15 16:42:48 ? Mar 15 16:53:40 anyone got oprofile working on yocto Mar 15 16:54:46 alimon: I'm finding I can break yocto-compat-layer a little easily :/ Mar 15 16:57:59 RP: what you do? Mar 15 16:59:11 wesam: why oprofile instead of perf? Mar 15 16:59:57 sandsmark: I assumed they were different? Mar 15 17:00:29 well, perf has ~no overhead, I'm not sure what oprofile can provide that perf can't Mar 15 17:00:40 alimon: patches explain better, top two commits of http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=rpurdie/wip-rss2 Mar 15 17:01:24 alimon: it does raise a question about the contents of local.conf during these tests though, I'm wondering if the script needs to clone its own OE-Core Mar 15 17:01:28 oprofile seems to have been dead for a couple of years as well Mar 15 17:01:47 RP: yes may be will be a better option to isolate the test environment Mar 15 17:01:54 sandsmark: is perf open source? Mar 15 17:02:22 of course Mar 15 17:02:30 it's hosted on kernel.org :p Mar 15 17:02:32 https://perf.wiki.kernel.org/index.php/Main_Page Mar 15 17:05:02 sandsmark: thanks i will look into this Mar 15 17:05:08 np Mar 15 17:05:20 I haven't used any other profilers after I discovered perf Mar 15 17:09:41 diego_r: hi! knowing RP I bet he meant to say: "I would *not* have said bothered..." :-) Mar 15 17:13:41 tlwoerner, diego_r: Yes, that clearly was meant to be "I would not have said", you didn't bother me! Mar 15 17:14:10 alimon: I think its going to need more isolation as its too easily broken right now :( Mar 15 17:14:51 alimon: We may also need to exclude meta-world-pkgdata :/ Mar 15 17:18:36 alimon: I think pohly has filed a bug for the latter but I just confirmed we do need to exclude it Mar 15 17:18:47 alimon: we probably need a bug for the isolation issue Mar 15 17:24:27 RP: ok, good to know that we have some bugs to improve the tool, i plan to work in M4 onit Mar 15 17:24:42 RP: also i'll file the bug for the isolation Mar 15 17:25:41 alimon: sounds good, thanks! Mar 15 17:25:54 alimon: Should I send the above patches? Mar 15 17:26:29 RP: yes looks good to me Mar 15 17:26:48 alimon: my other question is about the location of the README files since we can have multiple layers in a single repo with a top level README :/ Mar 15 17:27:09 alimon: not sure whether we should require one per layer Mar 15 17:28:05 alimon: I guess meta-openembedded does it Mar 15 17:29:56 I need advise. I'am currently working on automating test on a Intel Joule based on Yocto image meta-intel. Currently have to install build using USB mount. Is there a asoftware/Process for flashing a Yocto image straight the device emmc? Mar 15 17:34:11 Randy_: perhaps this might be helpful https://ostroproject.org/documentation/howtos/booting-and-installation.html#ostro-os-images Mar 15 17:35:30 RP: i don't know it depends on the layer provider, may be we can support both of the manners, so only search for a README at top level Mar 15 17:35:52 Thank you khem. I will take a look. Mar 15 17:35:52 if isn't found search for individual README's Mar 15 17:36:41 khem: Thank you Mar 15 17:38:05 alimon: That one needs more thought. Having a README per layer is perhaps easiest Mar 15 17:38:33 RP: yes that's the current implemented logic Mar 15 19:13:48 Hi, I have a puzzling issue with kernel fragments. I have quite a few already that function properly, but my most recent fragment doesn't appear to apply properly. However, when I put contents of the fragment inside another fragment it appears to show up in menuconfig. The command kernel_configcheck doesn't show any errors and I see that the config fragment is copied into my kernel WORKDIR. So I think my SRC_URI is correct. Is there anything find in the Mar 15 19:13:49 logs showing the fragment apply step? Mar 15 19:38:05 dscully: the only changes you should expect in menuconfig is if you have a config which depends on another config Mar 15 19:39:28 the logs for config frags being applied can be found in what is called the meta-series Mar 15 19:40:03 which you can find in tmp/work-shared/*/kernel-source/.kernel-meta/meta-series Mar 15 19:40:41 but the frags definitely don't change the data found in the kernel's Kconfig files, which you will see in menuconfig Mar 15 19:40:53 so it is either you just don't see it Mar 15 19:41:04 ie. it is hidden because of a dependency Mar 15 19:41:32 or possibly (but you should know if you have) you are patching the kernel and modifying a Kconfig file Mar 15 19:50:44 Thanks, I'll take a look at those logs. I am patching a Kconfig file at the same time, but that doesn't explain why the CONFIG_ line is picked up in one cfg and not the other.. Mar 15 19:59:14 dscully, there needs to be an explicit "include foo.cfg" line in an scc file somewhere ; sounds like the file that doesn't work isn't included. Mar 15 19:59:53 in the dir marka mentioned you'll find the log of all the CONFIG_ settings and what fragment(s) they came from. Mar 15 20:43:41 we're currently in the stabilization phase for pyro, yes? Mar 15 20:43:50 haven't been monitoring the release schedule recently Mar 15 20:44:31 finally got around to rebasing, cleaning up, and adding tests for git shallow, intend to submit for early on in the rocko cycle, since it's likely too late for pyro Mar 15 22:08:22 kergoth: yes Mar 15 22:08:37 kergoth: I keep remembering about that at the wrong times :( Mar 15 22:08:54 kergoth: my head is spinning trying to pull everything together and keep things working :/ Mar 15 22:15:28 i don't blame you, a hell of a lot of major stuff has gone in recently, you've done a good job at keeping the balls in the air thus far :) Mar 15 22:18:17 kergoth: "thus far" :) We'll see how stabilisation goes! Mar 15 23:33:44 RP: there is systemd 233 release are you interested to cut it into pyro Mar 16 00:57:49 trying to extract license lines from a source file barfs with a copy error Mar 16 00:58:04 yet everything looks correct Mar 16 00:58:11 the unicode/utf-8 encoding error? or something else? Mar 16 00:58:33 for a while there it was forcing a decode as utf-8, but not all such files are utf-8. it should obviously be reading and writing in binary mode Mar 16 00:58:39 not sure if that fix has gone in yet or not offhand Mar 16 00:58:44 LIC_FILES_CHKSUM = "file://${WORKDIR}/git/armada_ioctl.h;beginline=5;endline=7;md5=5f5464f9b3e981ca574e65b00e438561" Mar 16 01:01:05 https://bpaste.net/raw/f6bc559a913b < full spew Mar 16 01:02:13 ${WORKDIR}/git can it be ${S} Mar 16 01:02:45 ERROR: libdrm-armada-1_0.0.1+gitr${SRCPV}-r16 do_populate_lic: QA Issue: libdrm-armada: LIC_FILES_CHKSUM points to an invalid file: /home/sarnold/foss-boundary-new/oe-core/build-foss/tmp-glibc/work/cortexa9hf-neon-oe-linux-gnueabi/libdrm-armada/1_0.0.1+gitr${SRCPV}-r16/git/armada_ioctl.h [license-checksum] Mar 16 01:02:58 i'd see about figuring out why SRCPV is unexpanded before anything else Mar 16 01:03:12 your PV seems invalid Mar 16 01:03:17 who sets SRCREV ? Mar 16 01:03:23 yeah, make sure S/SRC_URI/SRCREV are all correct Mar 16 01:04:37 isn't LIC_FILES_CHKSUM files already relative to S? why the absolute path there? Mar 16 01:23:50 i pulled it out of another recipe but i did think about for a second or two... Mar 16 02:21:43 it was that cheesy cgit stuff Mar 16 02:22:09 i imported the repo to github and no more problems Mar 16 02:22:34 which i should have done in the first place... **** ENDING LOGGING AT Thu Mar 16 03:00:01 2017