**** BEGIN LOGGING AT Fri Jun 12 02:59:59 2015 Jun 12 03:57:32 xulfer, what "debug" stuff? Jun 12 07:15:58 <[w00t]> Hi, I've encountered a rather strange error. I've compiled busybox with selinux support using yocto and the meta-selinux layer. The resulting binary in the work directory contains selinux when using grep, however the binary in the packaged rpm does not contain selinux and has a different checksum. Does anyone know what might be the issue? Jun 12 07:17:33 <[w00t]> I've tried to clean the cache as well Jun 12 08:25:16 [w00t]: could it be that you can't grep for selinux in the binary after it has been stripped (which the packaged version will be). Jun 12 08:26:17 morning all Jun 12 08:30:17 <[w00t]> I found the reason why.. apparently the meta-selinux layer does not change the busybox config and was compiling it without selinux support. Had to run the menuconfgi for busybox Jun 12 08:42:26 morning Jun 12 08:45:38 bluelightning: I noticed that linux-yocto doesn't come with it's config file, so how does poky build the kernel without a config file? by generating one on the fly? Jun 12 08:47:10 parrot: it generates it based on a few things including KERNEL_FEATURES and the contents of the branch specified by KMETA Jun 12 08:53:55 bluelightning: mind elaborating more about 'contents of the branch specified by KMETA". Suppose that KMETA is "meta", so what does that mean in generating the config file? Jun 12 08:55:35 parrot: I'm not really the best person to ask; you may find our kernel development manual helpful, particularly this section: http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html#kernel-dev-advanced Jun 12 08:56:10 bluelightning: reading....thanks :-) Jun 12 08:56:14 if you look at our linux-yocto-* kernel repositories you can see the "meta" branch (which is what KMETA is usually set to point to) Jun 12 08:56:20 http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.19 Jun 12 08:58:07 so you mean that KMETA variable sets the branch of the cloned repo? Jun 12 08:58:27 hrmm, nightly-multilib failed on my AB run with multiple connectivity QA failures (ping, ssh and error reporting) Jun 12 08:58:33 coz I saw branch=${KBRANCH},${KMETA} in SRC_URI Jun 12 08:58:39 oh! an icu failure, that seems more like something I can fix Jun 12 08:59:15 bluelightning: never mind...got the answer from the page Jun 12 08:59:52 * joshuagl wonders how to repro the multilib config Jun 12 09:03:59 pidge: is there somewhere I can browse the conf files for the builders? particularly looking for details on nightly-multilib so I can try and repro a failure Jun 12 09:06:22 joshuagl: sure. the easiest is to go to the CreateAutoConf/CreateBBLayers step and look at stdio Jun 12 09:06:46 joshuagl: the better way is to talk to halstead about you getting builder shell access Jun 12 09:06:57 hmm, I think I may have that Jun 12 09:08:36 but the createautoconf stdio is a canny idea, I'll look at that Jun 12 12:01:53 rburton, know anything about this Jun 12 12:01:54 * satisfy_dependencies_for: Cannot satisfy the following dependencies for xf86-video-modesetting: Jun 12 12:01:54 * xorg-abi-video-18 * Jun 12 12:02:03 is there more to using external source than setting inherit += "externalsrc" and EXTERNALSRC_pn-myproject = "/my/funny/path"? i'm trying to use it on a package and it seems to pick up changes in the autotools files, but not in the sources, especially not files that get added Jun 12 12:05:59 hey, is anyone still using sysv init in here? Jun 12 12:06:06 I do not know how to get the coredump with that :) Jun 12 12:06:19 is this some configuration to turn it on? Jun 12 12:06:47 what do you mean, coredump with that? Jun 12 12:07:30 sysvinit Jun 12 12:07:56 since I am using sysvinit, I do not use busybox's coredump functionality, neither systemd's. Jun 12 12:08:07 I would like to see why my service keeps relaunching :) Jun 12 12:08:14 whether it is a normal exit or coredump, etc. Jun 12 12:08:23 of course, I could also debug it by logging, but still. Jun 12 12:08:54 does sysvinit even have built-in functionality for that? Jun 12 12:09:00 if it does it's news to me Jun 12 12:09:41 ah, ok Jun 12 12:09:52 so what do you recommend to use? Jun 12 12:10:00 sysvinit + busybox's coredump functionality? Jun 12 12:10:06 Crofton|work: sounds like you got the new xserver but are using the old modesetting driver Jun 12 12:10:09 it's not an area I have had to personally deal with I'm afraid Jun 12 12:10:09 but as far as I know busybox is not PID 1 on our system, but let me check Jun 12 12:10:22 Crofton|work: new server ships its own modesetting driver, and iirc the abi bumped Jun 12 12:10:33 hmm Jun 12 12:10:38 LetoThe2nd: which version of the build system is this with? Jun 12 12:10:40 not sure how to fix this Jun 12 12:10:44 1 root 1720 S init [5] Jun 12 12:10:49 so it is init, not busybox. Jun 12 12:11:04 ah Jun 12 12:11:06 maybe a clue Jun 12 12:11:09 I guess people use systemd these days. Jun 12 12:11:14 with which, it is simpler. Jun 12 12:11:19 certainly not everyone... Jun 12 12:11:32 I call for old one an an inage Jun 12 12:11:40 I wonder if that confuses the new system? Jun 12 12:12:37 Crofton|work: if this is newish master, then xorg-abi-video is 19 ... Jun 12 12:12:51 checking something Jun 12 12:13:12 this channel should be renamed to #oe-intel Jun 12 12:13:43 cehcking something, but some other stuff is building ... Jun 12 12:14:01 bluelightning: :-) Jun 12 12:14:03 bluelightning: dizzy Jun 12 12:14:53 LetoThe2nd: ah right - I believe there's nothing in dizzy's externalsrc to force recompilation on every invocation as we do in fido Jun 12 12:15:13 bluelightning: well not even cleaning or cleansstating will help Jun 12 12:15:43 bluelightning: if i modify some file thats already there, everything is fine. the changes get pulled in Jun 12 12:15:48 LetoThe2nd: surely the issue lies in your app's build system then? Jun 12 12:16:36 bluelightning: if i add a new file, Makefile.am and firend get accordingly processed so bitbake tries to compile the new files - and can't find them in tmp/work/..../ Jun 12 12:17:38 LetoThe2nd: ah so it's not that it's not picking up the change, that's what I took from what you said earlier Jun 12 12:18:03 bluelightning: correct Jun 12 12:19:40 LetoThe2nd: perhaps a silly question your recipe doesn't inherit autotools-brokensep does it ? Jun 12 12:20:43 bluelightning: nope, doesn't. doesn't need to so far - should i add it for the time using externalsrc? Jun 12 12:20:52 no, I was just checking Jun 12 12:22:08 changing a Makefile.am is not a case I have tested myself, though I don't immediately see why it would not work Jun 12 12:23:39 if you wanted to force it to use B = S as a workaround, the way to do that would be to set EXTERNALSRC_BUILD_pn-myproject to the same directory Jun 12 12:35:51 bluelightning: doesn't seem to do the trick. hm. guess' i'll have to spam a git repo branch then :) Jun 12 12:36:40 LetoThe2nd: I can only assume there's something funny going on with autotools Jun 12 12:37:08 Hi everyone! I'm confused again! so, i have this build using one machine, and it works as expected. if i then rename conf/machine/x.conf to conf/machine/y.conf, and change machine to y in conf/local.conf, it still works Jun 12 12:37:35 bluelightning: i asume the sam ;) Jun 12 12:37:56 but if i copy x.conf to another layer (meta-customlayer/conf/machine/z.conf) it fails during the last step while building the image, in do_rootfs: Jun 12 12:38:20 LetoThe2nd: if you could file a bug, I'll try to get someone to investigate Jun 12 12:39:41 http://pastebin.com/mSZstvQd Jun 12 12:40:12 bluelightning: i'll try, but gotta leave now... hopefully tonigt :) Jun 12 12:41:12 my problem looks alot like this thread: https://www.mail-archive.com/yocto@yoctoproject.org/msg23943.html, but his problem was solved in an update. not clear what his problem was. Jun 12 12:41:43 this happened to me while moving from dizzy to fido as well. the machine i'm copying is raspberrypi from meta-raspberrypi... Jun 12 12:45:49 ionte: we definitely seem to have some kind of bug here - can you perhaps reply to that mailing list thread saying you've also experienced this? anything you can do to shed light on how to reproduce the problem would be really helpful Jun 12 12:46:02 LetoThe2nd: ok, no worries Jun 12 12:49:26 bluelightning: ok, i'll try that Jun 12 12:55:05 rburton, I included the old modesetting thing in an image, that seemed to be the issue Jun 12 13:30:13 Crofton|work: new one should have seamlessly replaced it (same name, newer version, old recipe removed) Jun 12 13:53:38 it would be nice to have more information available about coredump usage with Yocto images. Jun 12 13:54:12 perhaps somewhere in the debugging section or so. Jun 12 14:01:38 rburton, I had to Jun 12 14:01:39 - xf86-video-modesetting \ Jun 12 14:01:45 remove from image file Jun 12 14:01:56 I wonder if there are artifacts in tmp? Jun 12 14:01:59 Crofton|work: huh Jun 12 14:03:09 I'm afk through monday, need to test some stuff and pooke harder Jun 12 14:08:05 autobuilder cluster going down for a bit. back up soon. Jun 12 14:59:03 ab is back up. Jun 12 20:11:51 I'm trying to understand the following recipe: http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx-community/tree/recipes-bsp/u-boot/u-boot-zx3_git.bb Jun 12 20:12:33 When looking at https://github.com/netmodule/meta-ze7000 as referenced by SRC_URI I cannot seem to find any relevant files Jun 12 20:15:25 The metalayer contains appends to base_files and adds a smart-config recipe; but they aren't depended on by the u-boot-zx3 recipe Jun 12 20:51:15 Yeah silly me > > Just tired. Looked at the wrong repo. The correct one is https://github.com/netmodule/uboot-ze7000 Jun 12 20:56:32 Is there a way to remove the package qa pertaining to static libraries in packages other than staticdev? **** ENDING LOGGING AT Sat Jun 13 02:59:59 2015