**** BEGIN LOGGING AT Thu Mar 21 02:59:58 2013 Mar 21 08:28:46 good morning Mar 21 09:24:49 morning all Mar 21 09:37:53 silvio_: hi Mar 21 09:44:40 hi mckoan Mar 21 09:44:53 morning silvio_, mckoan, all Mar 21 09:45:02 hi bluelightning , all Mar 21 11:39:55 can I overlay .inc files by simply having an .inc file in a bblayer with higher priority? the recipe just to a require foo.inc and I want to do modifications to foo.inc but not the .bb Mar 21 11:57:34 what does one do when one gets "error: package version went backwards" ? Mar 21 11:58:38 increase the number? Mar 21 12:03:44 tasslehoff: exactly that; the last time the package was built it had a version higher than the one that you've just built Mar 21 12:05:17 let me explain :) Mar 21 12:05:46 I had a recipe for connman 1.4 that I tested, but threw it out to go back to 0.79 that is in denzil. Mar 21 12:06:33 so what I wonder is if that error message means I will have to clean out something Mar 21 12:08:17 tasslehoff: no, if you don't care about the version going backwards you don't need to do anything Mar 21 12:08:57 it's only really if you are using package management on target and providing feeds, then it's something you need to pay attention to Mar 21 12:12:19 bluelightning: ok. thanks. Mar 21 12:46:01 hi i'm building qt in oe-core using my own toolchain(arm) Mar 21 12:46:24 its throwing complation error saying Mar 21 12:46:48 better use pastebin Mar 21 12:46:50 ld: unrecognized option '-Wl,-O1' Mar 21 12:47:00 sure Mar 21 12:47:09 ld is from my toolchain Mar 21 12:47:17 its gcc options telling the linker to use -O1 Mar 21 12:47:20 that's a classic :-) Mar 21 12:47:58 oe-core: your build is sending gcc options to directly ld Mar 21 12:48:31 -Wl-O1 is a gcc option telling it to send -O1 to ld. Mar 21 12:48:36 is there any way that i can remove those options Mar 21 12:49:27 depends on the context Mar 21 12:49:30 i mean mask them Mar 21 12:49:39 just use gcc as linker Mar 21 12:49:49 not ld directly Mar 21 12:50:07 so i should pass ld as gcc Mar 21 12:51:09 oe-core: are you using all-upstream recipes or did you change anything? Mar 21 12:51:26 no set LD=gcc Mar 21 12:52:03 but maybee the problem is deeper Mar 21 12:52:12 is it ok? LD=${CC} Mar 21 12:52:25 woglinde: hi Mar 21 12:52:40 I'm trying to remember where I ran into this last... Mar 21 12:52:52 bcoz i'm using different toolchain Mar 21 12:53:11 it's a mismatch between bitbake's idea of LDFLAGS and the package's idea of what LDFLAGS is Mar 21 12:55:35 actually those options are passed in bitbake.conf in addition to TARGET_LDFLAGS Mar 21 12:55:54 oe-core: yes, and your build is sending LDFLAGS to ld instead of gcc Mar 21 12:56:04 which package is this happening on? Mar 21 12:57:14 he zecke Mar 21 13:02:05 qt Mar 21 13:09:11 I haven't built qt, but I've been bitten by this when building a kernel. it takes LDFLAGS from the environment and passes it to ld. this sounds similar, and in that case you need to "unset LDFLAGS" somewhere in your qt build. Mar 21 13:15:53 isnt it enough if i pass it through configure? Mar 21 13:17:22 maybe. I guess it depends on what level you want to fix it. if you have unmodified qt recipes this sounds like an issue that might want to be fixed in the recipes. Mar 21 13:17:25 and if i unset from where it will pass ldflags to ld? Mar 21 13:18:26 in the case of the kernel, it uses default flags if the environment is empty. I don't know for qt. Mar 21 13:29:05 guys, I need help with https://bugzilla.yoctoproject.org/show_bug.cgi?id=4069 "ptest files are packaged into core package". I don't understand why this happens. Mar 21 13:32:54 Zagor: assuming FILES_${PN}-ptest is set correctly, it may be a matter of where ${PN}-ptest appears in PACKAGES Mar 21 13:33:27 Zagor: the first one whose FILES value matches a file to be packaged will get the file Mar 21 13:33:31 bluelightning: it appears last, since it is put there by PACKAGES += "${PN}-test" in ptest.bbclass Mar 21 13:33:42 aha! Mar 21 13:33:42 right, that will be why Mar 21 13:34:09 you probably want =+ instead Mar 21 13:34:29 I thought that was only about where the space is added? Mar 21 13:34:37 does =+ prepend? Mar 21 13:34:44 =+ prepends yes Mar 21 13:35:00 it will put the space after the value instead of before (which is what you want in that situation of course) Mar 21 13:35:18 testing that now. thanks. Mar 21 14:25:56 eugh, putting it first violates the -dbg QA check... Mar 21 14:26:08 since it the sucks in the .debug dirs too Mar 21 14:26:11 *then Mar 21 14:31:01 Zagor: you could do something like PACKAGE_BEFORE_PN_prepend = " ${PN}-ptest" Mar 21 14:31:40 yeah, looking at that too. but some ptest packages need to have staticdev files in them too. Mar 21 14:32:16 so ideally I'd have to put it just after -dbg, I think. but adding a new variable doesn't feel very nice Mar 21 14:33:43 perhaps a better way is allowing .debug dirs in ptest packages Mar 21 14:35:41 putting ptest debug data in the normal -dbg packages doesn't feel completely elegant anyway Mar 21 14:37:57 ptest packages can, by definition, contain pretty much any type of files and should in my opinion not be QA-checked the same way as "production" packages Mar 21 14:53:25 Zagor: in that case you could in a python function (a) adjust your FILES_${PN}-ptest value dynamically to list files specifically, or (b) insert the ${PN}-ptest into just the right place within PACKAGES Mar 21 14:54:08 I think you can exclude packages by name from QA tests, you might want to do that Mar 21 14:54:35 yes, I'm preparing a patch that excludes -ptest from some checks in insane.bbclass Mar 21 14:55:19 and puts all ptest files, including .debug, into the ptest package Mar 21 16:06:37 I get a collision between libgles2 providers. "ERROR: Multiple .bb files are due to be built which each provide virtual/libgles2" the problem is that a set of custom drivers provide that, the X11 driver for that chipset depends on these drivers, and xorg wants to build mesa for some reason, which also provides libgles2 Mar 21 16:06:54 I am not sure how to fix this mess.. perhaps mask mesa? Mar 21 18:31:42 i am getting a very undecriptive parse error from bitbake Mar 21 18:32:05 waynr: can you pastebin the message? Mar 21 18:32:16 sure Mar 21 18:35:02 http://paste.debian.net/hidden/7113055d Mar 21 18:35:34 bluelightning: maybe i have file with no contents somewhere that i forgot about? Mar 21 18:38:44 waynr: what version of bitbake are you using? Mar 21 18:39:44 1.17.1 Mar 21 18:43:49 waynr: hmm... so the real error is being masked because some broken code there is tripping up on it Mar 21 18:44:05 waynr: I thought this had been fixed but AFAICT the fix got reverted (?) Mar 21 18:46:47 so this was a known issue in a previous version of bitbake? Mar 21 18:47:18 well, I have seen similar issues in recent versions of bitbake Mar 21 18:48:29 hey there Mar 21 18:48:38 hello Mar 21 18:48:45 waynr: just to get you going, can you add "if isinstance(result, BaseException): Mar 21 18:48:55 raise result Mar 21 18:48:58 " Mar 21 18:49:08 * eren <3 python Mar 21 18:49:22 waynr: after the "parsed, result = self.results.next()" line ? Mar 21 18:49:35 in bitbake/lib/bb/cooker.py Mar 21 18:49:46 okay i'll give that a shot Mar 21 18:50:05 then, once you can tell where the parsing error is I'd like to know so I can try to reproduce the problem here Mar 21 18:55:46 bluelightning: d'oh! i had a bunch of package names in IMAGE_FEATURES on separate lines without the backslash Mar 21 18:56:07 waynr: ok, and what was the exact error you received? Mar 21 18:56:15 i'll pastebin it Mar 21 18:56:54 thanks Mar 21 18:57:34 http://paste.debian.net/243471 Mar 21 19:02:47 waynr: thanks, will take a look at it tomorrow Mar 21 20:13:05 How is oe configured between the different versions of linux-mainline_X.X.bb when I've got PREFERRED_PROVIDER_virtual/kernel = "linux-mainline" set in my machine conf? Mar 21 20:15:40 it tooks the latest Mar 21 20:16:04 or you set it with PREFERRED_VERSION_virtual/kernel Mar 21 21:04:01 woglinde: ok, that is what though. PREFERRED_VERSION_virtual/kernel isn't set in any file (based on recursive grep). I've got recipes for 3.2, 3.7, & 3.8, yet 3.2 is being built. Mar 21 21:04:29 spacecolonyone: see DEFAULT_PREFERENCE or COMPATIBLE_MACHINE in the recipes Mar 21 21:04:35 also, don't use grep, use bitbake -e, to see what's really set Mar 21 21:09:50 spacecolonyone yes why PREFERRED_VERSION_virtual/kernel should be set by any recipe? Mar 21 21:11:11 I wouldn't think it be set by default: I'm trying to figure out why my machine conf file requests linux-mainline, I've got recipes for 3.2, 3.7, and 3.8 and 3.2 is being built Mar 21 21:11:24 so I gripped looking for it in conf files **** ENDING LOGGING AT Fri Mar 22 02:59:58 2013