**** BEGIN LOGGING AT Thu Jan 16 02:59:59 2014 Jan 16 06:03:50 hi i have been using poky with atmel,i just tried to compile qt sdk application with yocto,it shows me the below error, http://pastebin.com/X9K1M3Qb can you please help me to solve this issues Jan 16 08:26:55 good morning Jan 16 09:01:01 Hi Jan 16 09:05:34 A possibly simple question: I want to rebuild a package if a n environment variable changes. Is that possible? A usable alternative to be is also to just always rebuild a specific receipe. Jan 16 09:05:54 Any hints would be very appreciated. :) Jan 16 09:08:33 Hmmm ... seems like task[nostamp] is the answer ..... please corect me if I'm wrong. Jan 16 09:14:37 nostamp will force a rebuild each time, not just upon a variable change Jan 16 09:27:30 SorenHolm: Make sure the variable is whitelisted (BB_ENV_WHITELIST iirc) and then in your recipe, export the variable. That should make bitbake track it Jan 16 09:30:46 RP: Why is the ${STAGING_KERNEL_DIR}/scripts built from module.bbclass rather than when ${STAGING_KERNEL_DIR} is populated? This means depending on virtual/kernel is not enough to be able to do: oe_runmake -C ${STAGING_KERNEL_DIR} headers_install INSTALL_HDR_PATH=${KINCLUDES} Jan 16 09:31:21 RP: I'm using the var already for other stuff. But thanks for that hint anyway :) Jan 16 09:32:07 Saur: because we don't know whether the kernel which could have come from sstate was built on a 32 or 64 bit machine Jan 16 09:32:28 Saur: therefore we build the scripts directory explicitly and don't put it into sstate Jan 16 09:34:27 RP: Hmm, ok. Would have been nice if there was a separate bbclass for it then, rather than having to inherit module-base and copying some parts from module.bbclass... Jan 16 09:36:52 Saur: I think that having some common code was why there is module-base at all Jan 16 09:37:19 RP: True, but it is still more than what I need in a class that have nothing to do with modules... Jan 16 09:37:54 Saur: the number of different ways users use the system makes it rather hard to please everyone :( Jan 16 09:39:10 RP: Not blaming you. Just found it somewhat odd... Jan 16 10:00:52 morning all Jan 16 10:25:18 hi there, pushed first initrd update to openembedded-core. is it going to be applied at some stage? Jan 16 10:35:41 Xz: saw your patch, thanks Jan 16 10:36:19 Xz: Richard usually leaves the patches out there for review for a few days (unless it's an urgent/obvious fix) Jan 16 10:41:36 bluelightning: ok Jan 16 10:41:50 bluelightning: how does it work later to merge back to dylan? Do I have to request that? Jan 16 10:42:52 Xz: yes, that usually needs to be done separately Jan 16 10:42:52 RP: Would something like this be acceptable: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=pkj/kernel-headers Jan 16 10:43:12 Xz: but I'm the dylan maintainer, so you can just ask me to backport it once merged ;) Jan 16 10:43:24 Xz: I'll add it to my todo list now since we're discussing it Jan 16 10:45:35 bluelightning: ok, I will be bothering you about backports from master to dylan :) Jan 16 10:45:50 Xz: np :) Jan 16 11:20:43 Saur: not really since it breaks exiting users of module-base Jan 16 11:22:44 RP: Are there any besides module.bbclass? Jan 16 11:23:23 Saur: externally to OE-Core, yes Jan 16 11:23:33 Saur: this is why it was split out in the first place Jan 16 11:24:04 RP: Hmm, ok. Do you know of any (would be interesting to look at...)? Jan 16 11:24:31 Saur: I know of several private layers that seemingly use it, not sure about public ones Jan 16 11:24:40 RP: Ah, ok... Jan 16 11:24:52 Saur: I only get to know about them through the bug reports Jan 16 11:24:59 RP: :) Jan 16 11:38:15 RP: Ok, I pushed a rebased version to http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=pkj/kernel-headers that should be backwards compatible. Better? Jan 16 11:39:13 Saur: yes, but two more classes? :( Jan 16 11:39:36 Saur: I know its hard to win here but I'm not thrilled about that either Jan 16 11:41:32 Saur: I think this perhaps needs to go to the list as a discussion, see if we can't break backwards compatibility to clean this up Jan 16 11:41:59 Saur: That takes effort I know but in this case its probably the right thing to do Jan 16 11:57:50 RP: Certainly, no problems. No one would be happier than me if I do not have to make a kernel-scripts-base class... Jan 16 12:21:08 RP: What exactly does EXPORT_FUNCTIONS do? (Can't see that it is documented anywhere...) Jan 16 12:21:43 Saur: its the magic which turns kernel_do_configure into do_configure Jan 16 12:21:55 Saur: but only if do_configure doesn't already exist Jan 16 12:22:02 Que? Jan 16 12:22:27 Saur: _functionname -> functionname Jan 16 12:22:37 I've described this on the mailing list before Jan 16 12:25:41 RP: Ok, that was definitely not intuitive. I hope that updated BitBake manual won't take too long... Jan 16 12:28:10 Saur: FWIW it used to be even more complex and crazy :/ Jan 16 12:29:27 Saur: I'll write a piece of documentation for it while I remember... Jan 16 12:30:52 RP: Yay :) Jan 16 12:47:40 Saur: https://bugzilla.yoctoproject.org/show_bug.cgi?id=5472 Jan 16 12:47:41 Bug 5472: enhancement, Medium+, 1.6, paul.eggleton, NEW , BitBake manual: copy / adjust BitBake variables Jan 16 12:50:46 RP: One thing though, EXPORT_FUNCTIONS is not a variable but a command (even though its casing fooled me into looking for a variable...) Jan 16 12:53:00 Saur: no, its a list of functions to apply this magic to ;-) Jan 16 12:53:09 Saur: but I know what you mean Jan 16 12:53:36 Saur: Its an odd one a bit like INHERIT Jan 16 12:53:56 RP: Like most of BitBake. ;) Jan 16 12:55:39 Saur: well, yes. I wasn't responsible for these bits at least ;-) Jan 16 12:55:48 * RP has other probably greater crimes Jan 16 12:57:01 RP: Should keep you busy the day you decide it is time for BitBake 2. ;) Jan 16 13:00:18 Saur: its been talked about but there isn't anything so big it justifies it right now Jan 16 13:02:00 RP: Better (complete?) documentation would go a long way to make writing recipes for BitBake a lot easier... Jan 16 13:03:13 Saur: it is being worked on. As you see in that bug we're trying to document all the variables bitbake uses Jan 16 13:03:30 Saur: help appreciated too ;-) Jan 16 13:06:41 RP: I assume you will document all the BitBake commands as well (including syntax). I couldn't even find documentation of addtask and what syntax it allows. Had to look in the code for examples... Jan 16 13:26:04 Saur: that's definitely on the agenda yes Jan 16 13:28:56 bluelightning: Me happy. :) Jan 16 14:01:06 RP: Sent a (long) mail to the OE core mailing list about what to do with the kernel-scripts and module-base classes. Feel free to comment. ;) Jan 16 15:39:38 Saur could join this weekend's "bug squashing weekend" with issue 5472 :-) Jan 16 15:50:00 I am having writing a custom recipe. Getting problems with do_install. My recipe is-->http://pastebin.com/JN79h4WW and I need to install apriltags_demo executable in my image which is located under /build/bin/apriltags_demo --> http://imgur.com/Xg9hip5 Jan 16 15:50:17 I am having problem with writing a custom recipe* Jan 16 15:51:12 bitbake says no such file or directory. http://pastebin.com/1eqmrFFZ Jan 16 16:01:14 Zaif: the line which is failing is likely this one "install -m 0755 apriltags_demo ${D}git/build/bin". does that file exist in your build? Jan 16 16:01:52 ah. i see. it's in a subfolder. Jan 16 16:02:21 so you need the first install -d to create the 'destination' folder where you want to copy your file to. Jan 16 16:02:35 then the 2nd install -m will copy your binary in that folder. Jan 16 16:03:32 install -d ${D}${bindir} Jan 16 16:03:32 install -m 0755 /foobar ${D}${bindir} Jan 16 16:03:42 you probably need something like that. Jan 16 16:05:27 ndec: in this install -m 0755 /foobar, will be my /git/build/bin? Jan 16 16:07:23 yes, it's install Jan 16 16:10:35 ndec: ok, changing the recipe. Jan 16 16:18:38 ndec: got QA errors http://pastebin.com/fWGbQBLy Jan 16 16:29:29 Zaif: well, at least that means you've fixed the first problem ;-0 Jan 16 16:29:51 you need to look at the makefile now, somehow you are using absolute paths. Jan 16 16:41:48 ndec: ya first problem is fixed. Thank You, but my doubt is bitbake is fetching the package and executing make and installing apriltags_demo in build/bin directory. What is the problem in copying that to {bindir}? Jan 16 16:42:44 It says files/directories were installed but not shipped http://pastebin.com/gj4uuEPG Jan 16 16:50:38 Zaif: i don't understand your first point. Jan 16 16:53:34 ndec: bitbake is fetching apriltags, compiling and installing apriltags_demo executable in build/bin directory. Why is it failing at " install -m 0755 ${WORKDIR}/git/build/bin/apriltags_demo ${D}${bindir} " ? Jan 16 16:55:39 Zaif: hmm. i got lost. what's the failure with install? Jan 16 16:57:52 ndec: The problem is that bitbake is installing but not shipping the files and also says package apriltags contains bad RPATH http://pastebin.com/gj4uuEPG Jan 16 16:58:51 you're installing the files to the wrong path, as ndec has pointed out repeatedly. don't do that. Jan 16 16:59:31 in do_install() you put all the files you care at the of the build in $D. everything there will then be packaged. Jan 16 17:00:26 ok. Jan 16 18:15:54 Hmm, no dora branch for meta-ti yet eh Jan 16 18:22:11 question: why cp -afl in bitbake/oe @ sstate_install, copyhardlinktree .. cp -afl so it of course shits itself when I have DEPLOY_DIR_IMAGE on a diffrent FS Jan 16 18:22:28 or a different mount etc. Jan 16 18:23:34 probably for performance, though it should really be checking the devices of the source and dest and fall back to real copying.. Jan 16 18:23:47 Yeah, would be nice. Jan 16 18:24:09 finally de-bastardized this patch someone had in Jan 16 18:24:22 got it properly attempting to deploy images to a targetted location Jan 16 18:24:26 and. splat Jan 16 18:25:04 I think there is 1 say I can get around that. Jan 16 18:28:51 we'll see how that works out... Jan 16 18:30:18 kergoth: just punching-bag testing dockbake Jan 16 18:30:25 nice Jan 16 18:30:40 i still haven't found the time to invest into playing with it or docker yet myself :\ Jan 16 18:30:42 one of these days Jan 16 18:30:46 might have to just move DEPLOY_DIR entirely, instead of DEPLOY_DIR_IMAGE Jan 16 18:32:07 /query kergoth so it is not logged to the channel bot -- http://pastie.org/8639855 Jan 16 18:32:10 haha Jan 16 18:32:15 nice one weechat. Jan 16 18:32:18 fail :) Jan 16 18:32:26 yeah Jan 16 18:32:28 lovely. Jan 16 18:32:32 meh Jan 16 18:33:05 looks promising, though that absolute path for that image symlink should really be a relative one :) Jan 16 18:33:20 point is that inside the container, it was seeing bitbake/image as a different FS, because it _is_ a seperate host dir mount Jan 16 18:33:41 no, those are built based on the environment it came from Jan 16 18:34:13 $BS_BUILD/$BS_TUPLE/image $BS_IMAGE/$BSD_TUPLE Jan 16 18:35:13 doesn't quite solve the issue in the end, but sorta does for the moment Jan 16 18:35:31 The idea is wanting to get the images available in a seperate directory as a result. Jan 16 18:36:30 ahh, cool Jan 16 18:36:55 well, in theory, I guess I can have all of deploy there. Jan 16 18:37:54 nah, that would still derp out. Jan 16 18:39:16 it wants to hardlink from tmp/work/package/version/something/* to $DEPLOY_DIR_IMAGE .. which would still be "wrong" for hardlinks. Jan 16 19:24:23 for anyone interested in joining this weekend's bug hunt (http://lists.openembedded.org/pipermail/openembedded-devel/2014-January/093723.html) Jan 16 19:24:40 here are some good janitorial bugs to consider: https://wiki.yoctoproject.org/wiki/Janitors Jan 16 19:24:54 (scroll down to the bottom of the page for bug entries) Jan 16 19:46:18 kergoth: I understand using the -afl in the end, since that technically is a space saver Jan 16 20:01:01 kergoth: interesting.. http://git.openembedded.org/openembedded-core/tree/meta/lib/oe/path.py?h=dora#n87 Jan 16 20:01:10 it "tries" to detect/prevent this. Jan 16 20:13:20 kergoth: wheee... yeah.. it does indeed look the same inside python with those test. Jan 16 22:15:01 hello all, a quick question: is there any way to include unstripped binaries in the main package? In my case, I need libpthread.so and libpthread_db.so to be unstripped, otherwise the gdb complains about thread debugging. Appreciate if someone could throw a simple solution Jan 16 22:16:15 reeve: INHIBIT_PACKAGE_STRIP="1" in the recipe should do that. Jan 16 22:17:15 ndec: appreciate it. Where should I add it? I only need two specific libs as unstripped Jan 16 22:17:23 not globally Jan 16 22:18:22 reeve: it may also be practical to just ensure libc6-dbg is included in your image Jan 16 22:19:33 not quite the same as unstripped, but GDB won't care about the difference Jan 16 22:20:13 reeve: sorry, i ready too quickly... Jan 16 22:20:27 if you just need to 'debug' then add the -dbg packages you need as evanp said. Jan 16 22:21:14 INHIBIT_PACKAGE_STRIP variable need to do in the recipe, and would impact all packages from that recipe Jan 16 22:21:36 ndec/evanp: Appreciate your help. This is a production image, i cannot add dbg package since it has source code, .la and .a ... Plus, my eglibc-dbg has nothing but source/header files Jan 16 22:24:01 then i don't think there is a 'direct' way to do it. you could install the -dbg and post process the image to remove what you need to remove.. but that's ugly.. Jan 16 22:24:45 ndec: enh! That would be nice if yocto could add such a feature Jan 16 22:26:00 hmm. maybe you could play with FILES_${PN}-dbg so that it does not package the source code. Jan 16 22:28:26 anyways, i agree that being able to package the 'symbols' for the libs separately from source code might be nice. Jan 16 22:29:14 actually I think this might work: FILES_${PN} += "${libdir}/.debug/libpthread.so.0 ${libdir}/.debug/libpthread-X.Y.Z.so" Jan 16 22:30:37 ndec: thanks for agreeing that Jan 16 22:30:50 or I suppose FILES_${PN} += "${libdir}/.debug/libpthread*" might be better Jan 16 22:30:54 evanp: that would be nice if it works, let me give it a try Jan 16 22:31:12 evanp: no, that won't. Jan 16 22:31:20 -dbg is processed before the main package. Jan 16 22:31:32 so the file will be packaged in -dbg in fact. Jan 16 22:32:02 we need to remove the regexp from FILES_${PN}-dbg so that the files aren't 'taken' by -dbg. Jan 16 22:33:40 the wearied thing is, my eglibc-dbg doesn't have any .so but source Jan 16 22:35:34 never mind, I found there is package called libc6-dbg has all of those ... sorry! Jan 16 22:35:36 I suppose you could PACKAGES =+ "${PN}-justpthreads" followed by FILES_${PN}-justpthreads += "..." Jan 16 22:36:10 and arrange for the image to include libc6-justpthreads Jan 16 22:37:41 ndec: sound plausible? Jan 16 22:38:26 evanp: yeah, both make sense. Let me see whether I could prevent -dbg include those two files Jan 16 22:38:33 well, maybe. though i don't know what kind of things you can mess up by changing such package names! Jan 16 22:39:03 not changing, just moving the two files Jan 16 22:39:33 yeah.. maybe ;-) Jan 16 22:39:38 though it probably would be wise to add RDEPENDS_${PN}-dbg += "${PN}-justpthreads" just to be safe Jan 17 00:16:58 what is easiest way to make an external loadable kernel module with yocto? I have been following the hands on lab PDF but still having a hard time modifying my fsl setup Jan 17 00:17:03 * newell feels slightly lost Jan 17 00:18:04 newell: by external, do you mean out-of-tree? Jan 17 00:18:52 well that and I also want to load it myself and unload it myself so I don't want it included in the image, I just want it compiled and placed in the filesystem somwhere so I can do an insmod etc. Jan 17 00:19:13 evanp, make sense? Jan 17 00:19:58 I am new to all these recipes etc....more familiar with just compiling the kernel and having it create the loadable module Jan 17 00:20:45 newell: yeah...is the reason it's autoloading that the kernel proper is matching a e.g. PCI device ID to it? Jan 17 00:23:15 ehh...I just need to go figure out all this recipe stuff Jan 17 00:23:20 * newell is off to read read and read Jan 17 00:39:02 newell: there is a hello-mod recipe in oe-core/meta-skeleton Jan 17 00:39:30 there is module.bbclass that you can use to build out of tree kernel. the .ko will be in the rootFS but not loaded. Jan 17 00:40:37 newell: i will be back tomorrow... good luck. Jan 17 01:05:05 ndec, you still around? Jan 17 01:05:56 ndec, thx for the tip...looking into it now **** ENDING LOGGING AT Fri Jan 17 02:59:58 2014