**** BEGIN LOGGING AT Wed Oct 02 02:59:58 2013 Oct 02 05:20:02 hi yocto. I am getting QA error of kernel firmware package. I posted the log at http://pastebin.com/XQXKt1d4. Oct 02 05:20:31 i am using meta-beagleboard layer for beaglebone black. Oct 02 05:25:06 vicky: I am not sure about that error (don't know anything about the bbb stuff) but you can add "INSANE_SKIP_pn-linux-mainline = "installed-vs-shipped"" to your local.conf and bypass the error Oct 02 05:48:38 MACHINE_EXTRA_RRECOMMENDS = " kernel-modules" << In my machine conf but the image doesn't containt the kernel-modules. What is wrong about this? Oct 02 05:59:59 RagBal: have you got your build setup to install reccomended packages? Oct 02 06:00:34 RagBal: if not set it up as such, or use MACHINE_EXTRA_RDEPENDS Oct 02 06:06:11 I think it doesn't follow the variable because I'm not using a image based on packagegroup-base Oct 02 06:06:24 I just read it in the ref-manual Oct 02 06:40:18 How do you guys add layers to your poky repo? As submodules? Oct 02 06:43:56 tasslehoff: we currently use repo, similar to https://github.com/Freescale/fsl-community-bsp-platform Oct 02 06:46:46 erbo: ok. I'm probably moving from using the angstrom setup scripts to "pure poky" Oct 02 09:10:00 Zagor: there? Oct 02 09:31:26 if I wanted to stop the busybox syslog from starting at boot, would it be as simple as setting INITSCRIPT_PARAMS_${PN}-syslog = "" Oct 02 09:31:35 where ${PN} is busybox Oct 02 09:56:19 I am trying to build a kernel for a mips46 architecture and I am getting the following error: ERROR: QA Issue: Bit size did not match (64 to 32) linux-yocto Oct 02 09:56:30 what can be the cause of that Oct 02 09:59:32 rburton: here now Oct 02 10:00:30 zagor: have you looked at the new gnomey installed-tests thing, and ptest? I've a local patch to upgrade glib to 2.38 which can install its test suite, and didn't want to replicate any work. Oct 02 10:03:09 ah, no I haven't. Oct 02 10:40:41 tasslehoff: I use combo-layer Oct 02 11:07:00 My image generation takes 8 mins longer when I use MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS = "kernel-modules" in the machine config, do the kernel-modules take that much time to be inserted in the rootfs or am I doing something wrong? Oct 02 11:07:23 RagBal: i think you'll find its running depmod for every module :( Oct 02 11:07:50 Ugh, so it's a very time consuming action? Oct 02 11:07:57 it is for 200 modules Oct 02 11:08:15 needs to be done one instead of N times Oct 02 11:08:26 there's a framework for that you can use if you want to fix it Oct 02 11:09:14 I use it to populate my /boot folder with the uImage and *.dtb files, haven't found another way to do this. My image is based on BeagleBone black Oct 02 11:11:41 rburton, is there any way I can find out where the /boot folder is being populated? By a tasks or some sort Oct 02 11:12:08 So perhaps I can only populate it that way instead of calling kernel-modules every generation Oct 02 11:41:55 rburton, I found the splitted packages and use them individually. That works =) Oct 02 11:43:06 kernel-image, kernel-devicetrees, kernel-devicetree-overlays and kernel-image Oct 02 11:50:02 RP: thanks. will check it out Oct 02 11:50:38 RP: In a commit from about two weeks ago you added a fat warning to meta/recipes-kernel/linux-libc-headers/linux-libc-headers.inc about not copying it. Since we had such a copy to get at some kernel headers for our hardware I though I should heed your warning and use ${STAGING_KERNEL_DIR} instead. Oct 02 11:51:34 Saur: sounds good :) Oct 02 11:52:05 RP: However, I realized that I need the user-space sanitized headers that are typically output by make headers_install. How come these are not included in ${STAGING_KERNEL_DIR}/usr/include? Oct 02 11:53:13 Saur: you have most of a kernel build in there so you should be able to access the headers? Oct 02 11:53:41 Saur: you need a user space sanitiized installed version? Oct 02 11:58:04 RP: Well, make headers_install outputs a somewhat different layout than what is in the kernel sources, e.g., include/asm/mach which is the mach that the kernel was actually built for rather than arch/mips/include/asm/mach- that are in the sources. Oct 02 11:58:56 RP: Without the sanitized headers the user space program would need to explicitly know which mach the kernel was built for. Oct 02 11:59:51 RP: I added this bbclass http://pastebin.com/21X3rGG3 and use it from my recipe, but it seems somewhat redundant to need to sanitize the headers for each recipe that needs them... Oct 02 12:00:57 Saur: I imagine you might want to share those headers between machines of the same arch even. I do but there isn't a simple way nowadays. Oct 02 12:01:43 or do you need explicit mach? Oct 02 12:02:46 make_headers_install takes ARCH= fwiw Oct 02 12:07:54 Saur: Can we discuss this on the mailing list with Bruce and Darren and other kernel people please? Oct 02 12:08:19 Saur: I think you have a valid point, we just need to figure out what we need to do about it Oct 02 12:08:52 ant_work: please don't try and make square pegs fit a round hole. This is a different problem Oct 02 12:11:22 sure, just it seems to be some misunderstunding about how headers are installed. It is not per-machine in se Oct 02 12:11:55 * ant_work follows quietly Oct 02 12:17:40 hi, this is in my u-boot.inc: UBOOT_MAKE_TARGET ?= "all" Oct 02 12:17:51 will that be overriden from an "external" value in my bitbake recipe? Oct 02 12:18:00 I would like to have something else there than "all" Oct 02 12:24:37 lpapp: you can override it in your distro conf or with a bbappend for u-boot Oct 02 12:25:15 lpapp: depends if you set it before or after you include u-boot.inc Oct 02 12:25:32 lpapp: ?= means set if not already set Oct 02 12:25:46 RP: I guess oe-core would be the appropriate mailing list? Oct 02 12:26:12 Saur: yes please, A cc to Bruce Ashfield and Darren Hart might be good too Oct 02 12:26:25 RP: Ok, will see what I can come up with... Oct 02 12:27:43 RP: if he is using UBOOT_MAKE_TARGET = "somevalue", the order shouldn't matter Oct 02 12:29:28 Net147: it depends where you put it. If you put it in distro or machine config, that is parsed before the recipe so it works. If its put somewhere before the include of u-boot.inc, it will also work, if its after that include it works Oct 02 12:29:34 It is all about order Oct 02 12:29:55 RP: I was planning to use it the same as the other uboot variables, i.e. the machine config. Oct 02 12:30:53 RP: you basically wrote "works" for each scenario. :> Oct 02 12:34:17 lpapp: yes, the machine config is a good place to put it Oct 02 12:34:38 lpapp: sorry, the last bit should be " if its after that include it doesn't work" Oct 02 12:34:44 machine config is fine Oct 02 12:35:02 Net147: k, thanks. Oct 02 12:35:18 (it is weird u-boot does not build everything for "all", and I actually have to customize it) Oct 02 12:35:21 RP: :-) Oct 02 12:35:57 Saur: forgive me if I'm confusing you (RP will beat me;) but what we do is installing our copy of the headers in sysroot and create a relative symlink to asm, asm-generic, ... Oct 02 12:40:16 RP: ah yes. I was referring to = but you are referring to ?= Oct 02 12:46:58 bitbake -c cleansstate u-boot && bitbake u-boot Oct 02 12:47:06 is this good enough for rebuilding u-boot cleanly? Oct 02 12:56:03 Hi All! I have just created my first bsp (with yocto-bsp) only for purpose to provide a specific kernel version and its configuration. Unfortunately the configuration in tmp/work/-poky-linux/linux-yocto-custom/2.6.29.4+gitAUTOINC+6c36696ffc-r0/linux--standard-build doesn't match with the defconfig which I provided to yocto-bsp. AFAIK I haven't added any "configuration fragments" (voluntarily at least). Any advise? Oct 02 13:20:04 lpapp: yes, that's almost as good as you'll get. -c cleanall will wipe out the downloads cache so you'll be re-fetching too. Oct 02 13:20:48 rburton: cheers Oct 02 13:45:08 is there a way to tell yocto not to patch? I would like make an experiment for a package without my custom change. Oct 02 13:45:20 (ideally it would be nice if I did not need to remove the patch file from the files folder) Oct 02 13:46:00 you can reset the src_uri in a bbappend Oct 02 13:46:40 i guess you could add a do_patch() that did nothing in a bbappend too Oct 02 13:46:44 to just disable all patching Oct 02 13:47:31 well, this u-boot is mine Oct 02 13:47:40 I am not using the one u-boot Oct 02 13:48:07 do_patch() {} looks ok to me Oct 02 13:48:30 if its for a test, just remove the patch from the SRC_URI Oct 02 13:49:06 yeah, I will comment that out Oct 02 13:49:41 not in src_uri -> not applied Oct 02 13:55:38 rburton: right, so interestingly enough the stuff is not copied to tmp/deploy. Oct 02 13:55:52 my u-boot.ais file which is a bit different to u-boot.bin Oct 02 13:55:59 is that expected? Oct 02 13:57:31 is that because I did not run an image creation, eventually? Oct 02 14:00:54 * rburton doesn't use uboot, sorry Oct 02 14:05:16 rburton: https://bugzilla.yoctoproject.org/show_bug.cgi?id=5304 Oct 02 14:05:17 Bug 5304: normal, Undecided, ---, saul.wold, NEW , License warning when building any package Oct 02 14:08:04 lpapp: can you include the stat output on some of those target directories Oct 02 14:09:18 rburton: sure Oct 02 14:11:35 rburton: done Oct 02 14:49:00 lpapp: are you seeing those license warnings right now? those stats are mode 0755 which is right, i thought earlier they were 0644 (which would be a problem) Oct 02 14:50:26 rburton: yes, I see them now. Oct 02 14:51:22 then the perms don't seem to be a problem. if you could put a different print at every failure exit point in the copyfile function that might help. Oct 02 14:51:30 obviously this is hard to debug without seeing it in person. Oct 02 14:55:03 how would that help ? Oct 02 14:57:09 its failing but not telling you why Oct 02 14:58:35 "if you could put a different print at every failure exit point in the copyfile function that might help." -> then I assume, I do not understand what exactly you meant there. Oct 02 15:01:14 copyfile is returning false for some reason, so before every way it can return false, put "bbwarn error1", "bbwarn error2", etc. so you can tell easily what ways its failing. Oct 02 15:01:38 or whatever, all i'm asking if that you debug this a bit, because without you taring up your build tree i can't replicate it and the log doesn't have anything useful in to help. Oct 02 15:03:24 lpapp: of course, prints disappear, so change all the prints to bb.warn Oct 02 15:03:27 in copyfile Oct 02 15:04:00 well, it does not sound high priority enough of a bug to me to spend so much time with it Oct 02 15:04:06 sure Oct 02 15:04:10 it will stay open then Oct 02 15:04:23 until someone steps up. :> Oct 02 15:04:31 someone *who can replicate it* Oct 02 15:04:38 never seen it, can't replicate it, impossible to debug. Oct 02 15:05:05 heh, we should really fix that api. if it's failing, it should raise an exception, if it's doing something the user might need to know about, it should return that, and leave it up to the caller whether to pass the message(s) along to the log.. Oct 02 15:05:16 rburton: well, try to change the perms Oct 02 15:05:21 and see if you can reproduce it Oct 02 15:05:22 kergoth: rp just pointed out its using *print* Oct 02 15:05:37 lpapp: according to the stat logs, your perms are fine. Oct 02 15:05:40 yikes Oct 02 15:05:48 kergoth: so the messages are ... somewhere. Oct 02 15:05:54 incoming patch to make those bb.warn :) Oct 02 15:06:00 rburton: well, you could still give it a try though. Oct 02 15:06:21 presumably in the task log if it was called in task context, and possibly nowhere elsewhere? :) Oct 02 15:06:42 * kergoth gets caffeine Oct 02 15:06:56 kergoth: mine's a flat white, thanks Oct 02 15:07:43 rburton: while you're in there, movefile has issues too :( Oct 02 15:10:52 rburton: bb.warn gave a bunch of errors. Oct 02 15:26:37 lpapp: try http://pastebin.com/9AWNqmR8 for better diagnostics Oct 02 15:28:20 rburton: bb.warn will not fly. Oct 02 15:28:29 I already tried as written, but got a bunch of errors due to it. Oct 02 15:28:53 (not the text it is supposed to print) Oct 02 15:29:11 lpapp: if you just s/print/bb.warn/ you'll get errors from python as you're doing invalid things Oct 02 15:29:15 which is why my patch doesn't just do that Oct 02 15:30:28 - print("copyfile: Stating source file failed...", e) Oct 02 15:30:28 + bb.warn("copyfile: stat of %s failed (%s)" % (src, e) Oct 02 15:30:37 that looks syntax error to me for instance. ;-) Oct 02 15:30:42 damnit Oct 02 15:30:46 fixed Oct 02 15:31:26 morning zenlinux_ Oct 02 15:31:45 gm rburton Oct 02 15:32:00 yes, it's in the environment.. Oct 02 15:32:07 oops Oct 02 15:32:08 I assume we'll get to meet in person at elc-e this year? Oct 02 15:33:34 rburton: WARNING: copyfile: failed to chown/chmod /home/lpapp/Projects/Yocto/poky-dylan-9.0.1/build/tmp/work/mymachine-myvedor-linux-gnueabi/u-boot/v2013.07+gitAUTOINC+62c175fbb8a0f9a926c88294ea9f7e88eb898f6c-r1/license-destdir/u-boot/generic_GPLv2 ([Errno 1] Operation not permitted: '/home/lpapp/Projects/Yocto/poky-dylan-9.0.1/build/tmp/work/mymachine-myvendor-linux-gnueabi/u-boot/v2013.07+gitAUTOINC+62c175fbb8a0f9a926c88294ea9f7e88eb898f6c-r1/license-destdir/u-boo Oct 02 15:34:24 that got truncated, anything interesting after the second repeat of the path? Oct 02 15:34:49 not truncated. Oct 02 15:34:52 that is the end of the line Oct 02 15:34:58 hm, can you check the license files in your checkout - maybe they're owned by root? Oct 02 15:35:03 nothing interesting, just the previous stuff. Oct 02 15:35:06 the line ends "u-boo"? Oct 02 15:35:23 ? Oct 02 15:35:38 ah, you mean truncated on IRC Oct 02 15:35:46 well, nothing interesting anyhow Oct 02 15:35:49 the error is at the beginning. Oct 02 15:36:15 not sure what you mean by the license file really. Oct 02 15:36:26 it is just 644 Oct 02 15:36:28 lpapp:lpapp Oct 02 15:36:39 the source file its copying from, in meta/files/common-licenses/ Oct 02 15:36:41 Access: (0644/-rw-r--r--) Uid: ( 1000/ lpapp) Gid: ( 1000/ lpapp) Oct 02 15:36:47 hmm Oct 02 15:37:12 nah, those are lpapp:users Oct 02 15:37:15 644 Oct 02 15:37:46 Access: (0644/-rw-r--r--) Uid: ( 1000/ lpapp) Gid: ( 100/ users) Oct 02 15:41:02 rburton: FWIW that looks like do_populate_lic and that does not run in pseudo contenxt Oct 02 15:41:26 rburton: I don't know why do_populate_lic would use that copyfile... Oct 02 15:41:50 copyfile is not as generic as it name suggests, its a bit more specialised Oct 02 15:42:11 rburton: find ../meta* -not -user `whoami` -> returns empty. Oct 02 15:43:22 RP: agreed. patch 1 is to change to bbwarn, patch 2 is to use shutil Oct 02 15:43:35 rburton: chmod/chown sounds crazy Oct 02 15:43:40 that requires root permission. Oct 02 15:43:47 lpapp: not in pseudo-context Oct 02 15:44:02 and chmod will work if you own the file, obviously Oct 02 15:47:10 rburton: then I have no clue, sorry. Oct 02 15:47:26 rburton: maybe some file cached that I was trying to run bitbake as root once Oct 02 15:47:26 ? Oct 02 15:47:36 maybe Oct 02 16:53:55 hey guys: yocto/poky newbie here trying to build an image/cross qmake toolchain to run a QT4 embedded application. Oct 02 16:54:07 when I try to bitbake meta-toolchain-qte I get a QA error Oct 02 16:54:11 QA Issue: nativesdk-dbus: Files/directories were installed but not shipped Oct 02 16:54:28 How can I fix it? (or maybe ignore it if it doesn't matter?) Oct 02 16:55:32 I don't know where the recipe is for nativesdk-dbus and I don't see which QA step that is to do a WARN_QA in the docs (I don't even know where that WARN_QA would go? in local.conf i'm guessing?) Oct 02 16:58:42 danbeard: nativesdk-dbus is the dbus recipe in meta/recipes-core/dbus, what files are not being installed? Oct 02 16:59:48 /run and /run/dbus Oct 02 17:01:45 danbeard: doing a quick check here, be right back with you. Oct 02 17:02:00 k, thanks for the help :) Oct 02 17:02:33 i found a few other people in a google search who had the same error, but no solution :/ Oct 02 17:03:48 hmm, we seem to have missed that then. The right answer would be to remove those in the dbus/do_install_class-nativesdk, I want to verify that right first Oct 02 17:10:07 where is dbus/do_install_class-nativesdk in my poky root? (Sorry still learning the directory structure).... I just remembered my poky is checked out to a specific changeset ... the version that the board manufacturer (http://www.mscembedded.com/) provided ... it could be that it is out of date Oct 02 17:10:33 let me check it ... against the danny branch right? Oct 02 17:12:08 danbeard: sorry should have been more specific, it's in the dbus.inc file located in meta/recipes-core/dbus Oct 02 17:33:19 looks like it's the same in the danny branch Oct 02 17:35:03 so I'm trying to remove those directories in the do_install_class-nativesdk() function at the bottom of dbus.inc right? would that be as simple as adding rmdir /run/dbus ? is there a directory prefix variable I should add... like ${D} ? (Sorry, first time looking beyond a simple bb image recipe file) Oct 02 17:39:51 danbeard: Ok, I could reproduce it here, and it seems strange to me right now what's happening, the rm won't work, I think there is something strange Oct 02 17:42:17 is there a quick way to stop all the tool from rebuilding after I changed kernel slightly Oct 02 17:42:24 ok glad to know it's not just me :) Oct 02 17:42:49 nothing affects api/libc etc, but any kernel change will trigger a rebuild for gcc/etc, which takes forever Oct 02 17:44:54 danbeard: you stumbled on to an honest to goodness bug! Oct 02 17:45:45 I hate when people do that :) Oct 02 18:01:12 hmm you sure that do_install_class-nativesdk() is getting called? I threw in a 'mkdir ${D}/TEST to see if it would complain about that and its still the same error message about just /run and /run/dbus Oct 02 18:05:59 danbeard: there is something strange going on, for now you can set WARN_QA and ERROR_QA in your local.conf, I will pm you the settings Oct 02 18:39:06 can anyone confirm whether python-3 is added into yocto or not? Oct 02 18:40:55 is -not- Oct 02 18:41:14 likely in a few months it will be introduced (next verson of YP development) Oct 02 18:43:18 how about OE? I saw there are patches in mailing list ... Oct 02 18:43:31 weren't accepted.. Oct 02 18:43:39 OE and YP go in step.. so when it's in one it'll be in the other Oct 02 18:43:48 I need it for now, if someone already create receipt and patches, can you share it with me? Oct 02 18:46:50 find Khem -- or pull his patches off the mailing list.. Oct 02 18:46:59 I don't know if he has piushed them anywhere public Oct 02 18:47:59 fray: thanks a lot Oct 02 18:49:28 yes they are in contrib repo kraj/python3 branch Oct 02 19:05:12 hi Jefro Oct 02 19:13:19 jama: thanks Oct 02 19:24:34 jama: can you point me to the link of contrib repo? Oct 02 19:25:12 http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/python3 Oct 02 19:25:31 reeve: ^ Oct 02 19:25:52 JaMa: appreciate it Oct 02 19:38:36 JaMa: how to specify to build python3 intead of 2 in bitbake? Oct 02 19:41:11 they have different name, so just bitbake python3 will build python3 for you Oct 02 19:41:31 JaMa: thanks, will give it a try Oct 02 21:46:35 JaMa: I got this error to build python3. NOTE: Error during finalise of /home2/reeve-ws/yocto-dylan-merge/meta/recipes-devtools/python/python3-distribute_0.6.32.bb | ETA: --:--:-- ERROR: ExpansionError during parsing /home2/reeve-ws/yocto-dylan-merge/meta/recipes-devtools/python/python3-distribute_0.6.32.bb: Failure expanding variable DEPENDS: ExpansionError: Failure expanding vari Oct 02 21:47:02 do you know what it is? Oct 02 22:00:16 reeve: it's for master not for dylan so you're probably mixing incompatible bitbake and oe-core or something like that Oct 02 22:01:38 JaMa: Yeah we're on dylan. So python3 requires different bitbake and oe-core? enh? If that's the case, I cannot do it at this point Oct 02 22:18:25 reeve: that's not what I meant Oct 02 22:25:19 JaMa: then what you meant is ...? Can it be built on dylan branch? Oct 02 22:43:35 reeve: you're probably mixing incompatible bitbake and oe-core or something like that Oct 02 23:06:40 welcome galak **** ENDING LOGGING AT Thu Oct 03 02:59:58 2013