**** BEGIN LOGGING AT Tue Oct 28 03:00:00 2014 Oct 28 07:18:30 good morning * Oct 28 08:23:14 I have a tool that auto-generates code, and when it changes all code that has it as dependency requires to be rebuild as well. But i think just putting it in the DEPENDS line does now accomplish this, no? Oct 28 08:25:22 irontia, that would make it a build dependency, yes Oct 28 10:24:58 morning all Oct 28 10:52:44 morning Paul Oct 28 10:55:13 I got a newbie question i guess. The image i generate has a /sbin/init -> /sbin/init.sysvinit as a symlink. The initramfs i have to use breaks on this, because it mounts the root first the symlink fails. Where can i hook in to change the symlink to one which is relative instead of absolute? Oct 28 10:57:40 bluelightning: Is there any alternative for PSTAGING_DISABLED variable in yocto ? Oct 28 10:58:49 lsb_tester: er, no, you can't disable that on a per-recipe basis - what are you attempting to work around? Oct 28 10:58:51 bluelightning: I want a scratch build for all the packages. So wondering what should I set in local.conf ? Oct 28 10:59:30 you would just delete your TMPDIR and sstate-cache in order to force that Oct 28 10:59:43 (or rename them) Oct 28 10:59:49 brb Oct 28 10:59:56 bluelightning: Thanks :) Oct 28 11:09:32 bluelightning: Even if I do that(del tmp & sstate-cache), looks like it again populates the prebuilts on next bitbake attempt Oct 28 11:09:58 bluelightning: Is there a way to prevent it ? Oct 28 11:17:51 bluelightning: How about running bitbake with "--no-setscene" option ? Oct 28 12:05:10 <_valle_> One of my recipe get stuck at do_fetch. The folder doesn't get any bigger and it has been stuck for a long time. Oct 28 12:06:04 <_valle_> The SRC_URI looks like this: "git://server/app.git;branch=something;protocol=http;user=someone Oct 28 12:06:14 <_valle_> The SRC_URI looks like this: "git://server/app.git;branch=something;protocol=http;user=someone" Oct 28 12:06:52 <_valle_> Does anyone have an idea why it get stuck at do_fetch? Oct 28 12:16:04 lsb_tester: perhaps you have SSTATE_MIRRORS set so it's downloading the sstate packages from somewhere else? Oct 28 12:16:17 lsb_tester: otherwise I can't imagine how that could be happening Oct 28 12:21:03 bluelightning: Yes you are right. We have mirrors . Oct 28 12:37:39 has anyone else seen problems with fetching linux-yocto-3.10 today? I get this https://communities.intel.com/thread/56464?sr=stream&ru=170977, although it's not my post Oct 28 13:08:25 anybody know how difficult it would be to implement *xattr calls in pseudo? It looks like they are currently unimplemented and its somewhat required to get selinux labelling working for rootfs. Oct 28 13:15:56 mebrown: seebs is the pseudo maintainer, perhaps when he's around he can help to answer that Oct 28 13:16:10 thanks Oct 28 13:59:38 hi! In a custom layer I'm bbappend-ing a recipe from Yocto official layers which already defines a do_install_append() task. My need is to install an extra file. Is there any better way than amending the original do_install_append() by copy-pasting to just insert an extra line? Oct 28 14:01:22 mebrown: looks like seeb already did something around xattr in pseudo, see http://git.yoctoproject.org/cgit/cgit.cgi/pseudo/commit/?id=9485ba46bd622e328fe3557f94c38b77109e54fa and some of the preceding commits. Oct 28 14:02:10 Ah, thanks. I checked the pseudo tarballs in 1.3 and 1.6, but didn't have a chance to test git. Oct 28 14:02:23 I'll update and see if that fixes things! thanks for the pointer. Oct 28 14:04:21 g1zer0, just add a do_install_append() in your own layer. They will all be appended to do_install(). Oct 28 14:08:49 AndersD: do you mean that they *both* (mine and the one from the .inc in Yocto) get appended to do_install()? Oct 28 14:19:46 g1zer0, that's right Oct 28 14:22:48 great! I didn't know it was behaving in a cumulative way... ;-) thx! Oct 28 15:29:49 Hi, is there some place where we have package lists for 1.6 ? Oct 28 17:50:44 anybody doing a Yocto booth at SCaLE this time? Oct 28 21:29:04 Hello. Currently I am trying to write a do_unpack_append() which should extract an rpm using rpm2cpio and cpio. Unfortunatly cpio has no option for a destination directory and extracts to the current dir. How can I write something like this (cd ${S}/SOURCES && rpm2cpio ${S}/SRPMS/some.src.rpm | cpio -indv) in do_package_append()? Oct 28 21:30:38 This line makes bitbake say, cd is not defined. Sorry, I am not very familiar with python. Oct 28 21:30:54 you can't append to python from shell or vice versa Oct 28 21:31:04 _append/_prepend is a direct concatenation Oct 28 21:31:23 Oh, ok Oct 28 21:31:38 you can use a postfunc, or you can add a new task that sits between two existing tasks Oct 28 21:31:45 either should accomplish the goal Oct 28 21:31:51 there should be examples of both in oe-core Oct 28 21:32:06 Thank you, I will try this. Oct 28 21:33:45 that shouldn't be necessary just to do this though Oct 28 21:34:14 don't we already have rpm extractions upport somewhere? Oct 28 21:34:17 yes Oct 28 21:34:24 it's built-in Oct 28 21:34:30 i know we used to support src.rpm extraction ages ago, even with spec->bb conversion, but that was twisted and wrong :) Oct 28 21:34:47 you just need to set subdir= on the SRC_URI entry Oct 28 21:35:27 we even have meta/classes/bin_package.bbclass if you want to repackage an existing rpm Oct 28 21:36:11 Oh, nice. :) Oct 28 21:37:26 This one I have to recompile, but there are a bunch of rpms I want to install later, so I was already looking for this. Oct 28 21:38:09 can anyone explain why sed hardcodes an rdependency on locale-base-ru-ru? Oct 28 21:38:17 this doesn't make any sense, and is bound to break if one doesn't generate that locale Oct 28 21:38:45 maybe i'm missing something, though Oct 28 21:38:49 guess i'll email chong lu Oct 28 21:40:39 kergoth: I guess some of the ptests fail if that locale isn't installed Oct 28 21:41:11 should probably be an RRECOMMENDS if that's the case Oct 28 21:41:16 I kno bash's ptests expect locales, currently we're missing the dependencies for those Oct 28 21:41:21 s/kno/know/ Oct 28 21:41:29 That seems extremely silly. I'd rather be able to run some of the tests than not even be installed. Perhaps the test should opt-itself-out from execution if it isn't available, and indeed, rrec it Oct 28 21:41:38 s/it isn't/the locale isn't/ Oct 28 21:42:14 as it is, i'm unable to build an image with ptest-pkgs that includes sed :) Oct 28 21:42:20 * kergoth tweaks in an append for now Oct 28 22:12:25 Am I right that the subdir option of SRC_URI work like: extract the directory of ? I have a .tgz that contains the .src.rpm that again contains a .tgz. Oct 28 22:13:10 SRC_URI = "http://<..>.tgz" Oct 28 22:13:31 SRC_URI[subdir] = "SRPMS/<..>.src.rpm/<..>.tgz" Oct 28 22:13:47 that would be nice, but does not work Oct 28 22:15:03 I only need the content of the inner .tgz. Oct 28 22:21:36 Maybe I should use kergoth's recommendation to use a postfunc or a new task. Or do you know if the subdir option can help me yet? Oct 28 22:40:05 heh, yeah, our built in extraction stuff doesn't have automatic support for nested archives other than tar.{gz,bz2,..} Oct 28 22:49:47 The postfunc solution works so I don't mind. ;) Oct 28 23:24:00 Can I just use autotools.bbclass if I am building/installing kernel modules or is module.bbclass or something better? do_install throws the error, Permission denied for creating directory '/lib/modules/3.10.0-123.el7.x86_64/extra/ofa_kernel'. Oct 28 23:24:45 I wonder why do_install wants to create a directory in the hosts modules path. Oct 28 23:28:14 no, autotools alone will not do Oct 28 23:44:55 I am using modules and autotools now but it is still trying to build kernel modules on the host. Oct 28 23:45:00 | DEBUG: Executing shell function do_compile Oct 28 23:45:01 | NOTE: make -j 32 KERNEL_PATH=/var/tmp/yocto-ohliger/sysroots/crystalforest/usr/src/kernel KERNEL_SRC=/var/tmp/yocto-ohliger/sysroots/crystalforest/usr/src/kernel KERNEL_VERSION=3.10.38-ltsi-yocto-standard CC=x86_64-poky-linux-gcc LD=x86_64-poky-linux-ld.bfd AR=x86_64-poky-linux-ar Oct 28 23:45:03 | Building kernel modules Oct 28 23:45:04 | Kernel version: 3.10.0-123.el7.x86_64 Oct 28 23:45:06 | Modules directory: //lib/modules/3.10.0-123.el7.x86_64/updates Oct 28 23:45:07 | Kernel sources: /lib/modules/3.10.0-123.el7.x86_64/build Oct 28 23:45:45 Those lines in the output seem to be strange. Oct 28 23:46:40 sounds like you need to examine its buildsystem and figure out where those paths are coming from Oct 28 23:50:57 Ok, I will go into that Makefile later. Thank you for the support, you helped me a lot. Oct 28 23:51:26 Have a good night. **** ENDING LOGGING AT Wed Oct 29 03:00:00 2014