**** BEGIN LOGGING AT Fri Sep 16 02:59:56 2011 Sep 16 06:48:09 03Koen Kooi  07org.openembedded.dev * r959f7272f5 10openembedded.git/classes/gtk-icon-cache.bbclass: Sep 16 06:48:09 gtk-icon-cache bbclass: python += doesn't add a leading space like bitbake does, so fix that Sep 16 06:48:09 Signed-off-by: Koen Kooi Sep 16 07:14:55 hi all Sep 16 08:31:45 sigh...tzdata2011i has been removed from ftp://elsie.nci.nih.gov/pub/ Sep 16 08:38:04 overnight build failed twice..are the mirrors down? Sep 16 08:38:16 otavio, hi Sep 16 08:53:29 ant_work, it seems tzdata2011i didn't propagate to mirrors. Sep 16 08:53:46 Got orig.tar.gz from debian and renamed bad to tzdata2011i.tar.gz Sep 16 09:55:04 03Steffen Sledz  07org.openembedded.dev * rb16d53e480 10openembedded.git/recipes/linux-libc-headers/ (2 files in 2 dirs): (log message trimmed) Sep 16 09:55:04 linux-libc-headers 2.6.24: backport arm/asm/hwcap.h from linux 2.6.26 Sep 16 09:55:04 Enables building of OpenJDK which uses HWCAP_THUMBEE that is not present Sep 16 09:55:04 in 2.6.24 headers and was introduced with Sep 16 09:55:04 commit d7f864be8323e5394040e2877594645b0e7da85d Sep 16 09:55:05 Author: Catalin Marinas Sep 16 09:55:06 Date: Fri Apr 18 22:43:06 2008 +0100 Sep 16 10:06:44 hi Sep 16 10:25:07 hi all Sep 16 10:29:27 hi pb_ Sep 16 10:52:44 gosh, evince is slow at searching big documents Sep 16 10:53:16 * pb_ stabs chip suppliers who publish 9000-page datasheets Sep 16 11:17:25 Strange. Is meta-micro used by somebody? Sep 16 11:17:42 I see some wery strange problems with it. Sep 16 11:26:56 what problems are you seeing? Sep 16 11:32:33 pb_: hey, I still count on your review wrt klibc. In exchange I promise to test meta-micro ;) Sep 16 11:36:28 pb_: my doubts are mostly about the approach taken for the package split, implying cross-compilation of the packages Sep 16 11:37:10 pb_: i.e. no way to compile on target is provided, even after installing libklibc-dev on it Sep 16 11:37:43 yeah, sorry, I haven't had time to look at that yet Sep 16 11:38:34 with a bit of luck I will have some time at the weekend Sep 16 11:38:35 I guess those doubts have already been answered for other *libc Sep 16 11:39:35 pb_: not in hurry, as long kernel.org is down no klibc_2.0 will appear Sep 16 11:39:41 ah yes, right Sep 16 11:39:52 it does seem to be taking those dudes a long time to get their machines un-owned Sep 16 11:39:58 it's been, what, a couple of weeks now? Sep 16 11:40:01 heh Sep 16 11:40:42 last I've heard cause would have been a leaked ssh password Sep 16 11:42:16 ah, right Sep 16 11:42:36 and did linuxfoundation get owned as well? I heard some rumour that they did. Sep 16 11:42:49 brrr Sep 16 11:43:41 cough... Sep 16 11:43:52 "..ecurity breach that was discovered on September 8, 2011" Sep 16 11:44:16 btw kernel.org "We discovered this August 28th" Sep 16 11:44:55 they did Sep 16 11:48:22 oh well Sep 16 12:03:48 hi, all, again! Sep 16 12:04:40 since kernel.org is down and www.angstrom-distribution.org does not have a copy, how do people build images from scratch, since udev is unavailable for fetching? Sep 16 12:05:05 lumag: hi! Sep 16 12:06:36 slapin, hello! Sep 16 12:06:53 slapin, use orig.tar.gz from debian, ubuntu :) Sep 16 12:13:41 or don't use udev :-) Sep 16 12:13:51 or use a mirror of kernel.org, e.g. scp pb@lander:git/bcm7425-oe/sources/bs/source/pandora2/apps/brightsign/cheeta Sep 16 12:13:58 er, not that Sep 16 12:14:05 e.g. http://www.mirrorservice.org/sites/ftp.kernel.org/pub/linux/ Sep 16 12:16:21 anyhow, facing this big outage, our mirror system did not shine Sep 16 12:16:54 slapin: udev-173? do you have http://git.openembedded.org/cgit.cgi/meta-openembedded/commit/?id=efd2f36f7388e1cca963dc91cc2af34b60b48f7f ? because to find git checkout is even harder :) Sep 16 12:21:22 JaMa|Off: thanks a lot! Sep 16 12:50:39 GNUtoo|work: hi Sep 16 12:56:35 otavio, hi Sep 16 12:57:10 hi otavio Sep 16 12:57:48 otavio, I tested your patch Sep 16 12:57:57 the one about the translations Sep 16 12:58:03 1)it worked Sep 16 12:58:22 2)also bump qt4-embedded.inc's INC_PR Sep 16 12:58:45 GNUtoo|work: ahh fine. will do it locally and send it to mailing list Sep 16 12:59:58 ok nice Sep 16 13:07:46 GNUtoo|work: you and Eric has any public available tree I can merge? Sep 16 13:07:59 GNUtoo|work: so we both have the qt changes in sync Sep 16 13:08:16 otavio: I'm working on the git server Sep 16 13:08:30 ericben: why don't use github? Sep 16 13:12:21 otavio: could be a solution Sep 16 13:13:05 ericben: I've been using it and works quite nicely Sep 16 13:13:09 but I have git server with gitosis somewhere so that's easy to have everything at the same place Sep 16 13:13:30 ericben: besides, make easy to people to work with you since fork is quite useful sometimes Sep 16 13:13:54 as I'm sure github has some usage conditions which may be quite restrictive Sep 16 13:14:07 ericben: not really Sep 16 13:14:22 ericben: the only issue is that your repo is public Sep 16 13:14:47 ericben: i have the private one in our internal server but I avoid the maintainence work of having a public one Sep 16 13:15:03 ok so that may be a solution for this Sep 16 13:15:04 ericben: also is nice to allow us to grant commit access to other people Sep 16 13:15:19 ericben: in the public one i meant Sep 16 13:15:48 as I won't have to over admin our git server if it's not open :) Sep 16 13:16:10 ericben: i set up a organization and our team has commit access to all repo on that Sep 16 13:16:16 ericben: easy and simple Sep 16 13:16:17 otavio, we published all our patches to oe-core I think Sep 16 13:16:23 GNUtoo|work: me too Sep 16 13:16:33 GNUtoo|work: but I have an internal layer Sep 16 13:16:48 us too Sep 16 13:17:11 it'll be public but we need to set it up Sep 16 13:17:14 GNUtoo|work: and internally I use combo-layer to manage our "all-in-one" repo Sep 16 13:17:29 GNUtoo|work: in this case, github seems perfect Sep 16 13:17:58 ok Sep 16 13:18:45 GNUtoo|work: ah, a plus is that we have it working in create-pull-request too heh Sep 16 13:26:03 whai is LIC_FILES_CHKSUM and how I am supposed to fix this? Sep 16 13:26:09 *what Sep 16 13:26:20 slapin: git grep LIC_FILES_CHKSUM Sep 16 13:26:29 slapin: you'll have many examples ;-) Sep 16 13:26:50 http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#usingpoky-configuring-LIC_FILES_CHKSUM Sep 16 13:30:18 otavio, GNUtoo|work: thanks a lot! Sep 16 13:30:43 slapin: you're welcome Sep 16 13:34:08 I have lots of local test recipes, is it possible to skip license tests for them? is there some tool to automate license check e.g. for kernel recipes? Sep 16 13:34:31 I mean to automate proper setting generation Sep 16 13:34:36 for LIC_FILES_CHKSUM Sep 16 13:35:24 or i will have to fille 50+ values by hand, which is not thing I'd like to do at the moment. Sep 16 13:38:25 or I will set LIC_FILES_CHKSUM = "/dev/null;md5=d41d8cd98f00b204e9800998ecf8427e", will it work? Sep 16 13:38:56 LIC_FILES_CHKSUM = "file:///dev/null;md5=d41d8cd98f00b204e9800998ecf8427e", will it work? Sep 16 13:46:37 slapin: if you want to just skip it you can just comment out the code in sanity.bbclass Sep 16 13:47:21 or, if they're local recipes, just set LICENSE = "CLOSED" and not worry about it. Sep 16 13:47:43 pb_: the problem is that's something that could slip out externally Sep 16 13:48:54 I'm not quite sure I understand what you mean. Sep 16 13:49:32 pb_: i.e. if you commit LICENSE = "CLOSED" as a stopgap, forget about it, then publish the metadata, that would not be good Sep 16 13:49:42 and not good advice to give to people as a general rule IMHO Sep 16 13:50:01 if all you need is to disable the check quickly, just comment it out... Sep 16 13:51:13 fair enough, I guess Sep 16 13:51:52 he did say they were "local test recipes", which doesn't sound as though it's something that one would be publishing, and shipping a .bb file with LICENSE accidentally set to CLOSED wouldn't exactly be the end of the world, but still. Sep 16 13:54:24 not the end of the world, but not ideal either... Sep 16 13:55:42 it's not totally obvious to me that it's any worse than accidentally publishing a recipe which doesn't build unless the sanity check is commented out. Sep 16 13:55:51 but, anyway, it doesn't really matter. Sep 16 14:10:01 has anyone successfully built nut >2.2? Sep 16 14:10:22 I've merged net-snmp into my staging directory but nut is failing to properly define some functions from the net-snmp header files Sep 16 14:19:27 pb_, bluelightning: Thanks a lot, LICENSE = "CLOSED" is ok with me as these are ad-hoc hardware tests, so not intended for publishing. Sep 16 14:22:23 have anybody built OE with amazon ec2? how much does it costs approximately. Sep 16 14:45:26 I'm facing some strange problems with meta-micro. It looks like it tries to rebuild packages already built during previous bitbake runs, but fails miserably. Sep 16 14:47:43 so, once again, what actually are the problems? Sep 16 14:49:42 I can't think offhand of anything meta-micro does that would be likely to cause that sort of rebuilding issue, but without a concrete example of what's going wrong it is hard to say. Sep 16 14:51:57 pb_, E.g. I run bitbake libopie2, it builds several native packages to bootstrap (e.g. openssl, libtool, etc. -native). At some point I interrupt bitbake (or it finished running). I see stamps in the usual dir, I see correct binaries. All work is cleaned by rm_work. Sep 16 14:52:54 And then if I rerun bitbake I'll see all built packages rebuilding. Usually it fails in openssl-native (check build logs at http://bugs.lumag.spb.ru/show_bug.cgi?id=33). Sep 16 14:53:16 But the problem is that it actually tries to rerun all tasks. Sep 16 14:53:59 That's certainly rather strange. Sep 16 14:54:29 I can retry later but using plain oe-core, w/out distro 'scripts' Sep 16 14:54:52 just oe-core + meta-oe + meta-opie ? Sep 16 14:54:56 What version of bitbake do you have, the trunk? Sep 16 14:55:17 trunk bitbake, layers used: oe-core, meta-hh, meta-opie. Sep 16 14:55:42 hm, strange. Sep 16 14:55:53 pb_, I can try debugging that if you point me somewhere. Sep 16 14:56:03 well, I haven't seen that problem but I guess my configuration is a bit different. I don't use rm_work, and I don't use meta-hh or meta-opie. Sep 16 14:56:14 let me check what bitbake I have Sep 16 14:56:49 lumag: no meta-oe ? Sep 16 14:56:57 ant_work, no meta-oe Sep 16 14:57:00 seems to be d5abdacaf9ac604ef8d8c1bafb9b30617827cb4f, about a month old from the trunk Sep 16 14:57:29 I think I have done builds both with and without meta-oe recently so I doubt it is that Sep 16 14:57:58 lumag: well, the obvious place to start would be to see what the difference is in the stamp filenames that it creates the second time Sep 16 14:58:34 so, pick a recipe that does actually rebuild successfully (ie not openssl), let it run through, and then see what stamps you have after it's finished Sep 16 14:59:20 afaik meta-opie depends on meta-openembedded Sep 16 14:59:45 ant_work, I don't know, I didn't get till opie stuff comes to play. Sep 16 15:00:03 and meta-hh too, implicitely (klibc, klibc.bbclass) Sep 16 15:04:09 you should have meta-oe for meta-opie... I'm surprised you don't get errors Sep 16 15:04:30 ant_work: you don't need meta-hh for opie Sep 16 15:04:44 ant_work, meta-hh contains klibc.bbclass Sep 16 15:04:54 sorry, meant meta-hh has same dependency on meta-oe Sep 16 15:06:27 klibc.bbclass yes but not klcc-cross Sep 16 15:07:12 bluelightning: pls remove the class from meta-hh :) Sep 16 15:07:28 ant_work: ??? Sep 16 15:07:59 I missed that we have the class in both layers Sep 16 15:08:04 pb_, I got exactly the same recipes with updated timestamps Sep 16 15:08:09 ant_work: ah, so did I... Sep 16 15:08:18 pb_, s/recipes/stamp files/ Sep 16 15:08:34 okay Sep 16 15:08:46 so, if bitbake is regenerating the same stamps like that, I think that is probably a bitbake issue Sep 16 15:09:01 I'm not sure offhand how to debug why it isn't respecting the original stamp. Sep 16 15:09:59 lumag: check sstate signatures with bitbake-diffsigs Sep 16 15:10:13 JaMa|Off: about the # .. / fun Sep 16 15:10:29 do you think klibc_1.5.25.bb suffers of it? Sep 16 15:10:55 there is a blank line afterward... Sep 16 15:11:05 Moreover not all timestamps got updated. only build, distribute_sources, fetch, package_setscene, package_write_ipk_setscene. rm_work and unpack Sep 16 15:11:13 JaMa|Off, tell me more please :) Sep 16 15:11:34 ant_work: done Sep 16 15:11:40 thx Sep 16 15:11:50 that was fast, thx Sep 16 15:12:15 ant_work: easy for me to check and there was no material difference between the two versions Sep 16 15:12:57 yes, even if I'd like to hear pb_ about that, in fact only kexec-tools refuses to compile using OE flags... Sep 16 15:19:07 lumag: read http://lists.linuxtogo.org/pipermail/openembedded-core/2011-May/003231.html Sep 16 15:19:33 JaMa|Off, I see no new siginfo files. Or do you ask me to check .siginfo before and after rebuild. Sep 16 15:25:34 ant_work: next line after # blah \ is also considered as comment Sep 16 15:26:14 ant_work: so if you have # --enable-foo \ \n --enable-blah.. then both foo and blah are not enabled, but I guess most people like me will expect blah to be enabled Sep 16 15:27:04 JaMa|Off: I looked a bit at the linking issue you reported about openssl Sep 16 15:27:33 JaMa|Off: since I saw this problem on mips Sep 16 15:27:44 JaMa|Off: but I could not reproduce it when I tried again Sep 16 15:28:12 JaMa|Off: This is a race issue in parallel build Sep 16 15:28:15 khem: yes it's weird.. I've tried to compile it more times and it fails only in some cases Sep 16 15:28:24 where archive is not written properly as yet when its used Sep 16 15:28:33 in another branch of the build Sep 16 15:28:35 khem: yes usually if you run do_compile again it finishes Sep 16 15:28:59 JaMa|Off: so the problem really is in openssl and its a long standing issue in openssl Sep 16 15:29:20 the workaround fix for us is to disable parallel build for openssl Sep 16 15:29:32 ok.. just this version was first where I've noticed it Sep 16 15:29:57 better if someone can poke at openssl build sytem/makefiles and fix the root cause Sep 16 15:30:11 agreed Sep 16 15:30:12 JaMa|Off: I found more reports about very same issue Sep 16 15:39:30 khem, JaMa|Off. Seems I also hit this problem. I'll post my (proposed) patch in a minute. Sep 16 15:40:29 posted to oe-devel Sep 16 15:42:58 JaMa|Off, I checked the thread you referenced. My problem is that sigdata files don't get updated. Sep 16 15:44:47 JaMa|Off, can my problem be related to the fact that I also use basic and not basichash BB_SIGNATURE_HANDLER ? Sep 16 15:45:35 otoh angstrom also doesn't set BB_SIGNATURE_HANDLER Sep 16 15:47:28 lumag: sorry, no idea why it's rebuilt with same sigdata.. I was also using basic BB_SIGNATURE_HANDLER but got it rebuilt quite often.. but that was probably different cause.. Sep 16 15:54:22 bye all Sep 16 15:54:25 bye Sep 16 16:10:22 what to do if there's no any license file in source code? example recipe is libsocketcan_git.bb in oe-dev Sep 16 16:10:46 you will need to find a license file somewhere (web?) copy it in, and point to that.. Sep 16 16:10:52 be sure to annotate WHERE the license file came from.. Sep 16 16:11:07 * fray thought socketcan had a license declaration at the top of the source files.. Sep 16 16:11:17 (that is enough to point to as a license file) Sep 16 16:22:13 fray: how can I calculate md5sum for part of file automatically? how this is generally done? Sep 16 16:22:58 I believe you can use head/tail and md5 on the command line.. Sep 16 16:23:08 what i do is add the item to LIC_FILES_CHKSUM with "md5=". if you set the md5 to an invalid value,including hte empty string, it will display the md5sum in the error message Sep 16 16:23:09 i.e. if it's the first 10 lines... head -n 10 | md5sum Sep 16 16:23:12 :) Sep 16 16:23:30 kergoth ya, that is actually what I do most of the time.. ;) Sep 16 16:23:39 I do the md5sum myself though to verify it's really the one I want as well.. Sep 16 16:23:43 (most of the time) Sep 16 16:23:52 speaking of which, if you don't include teh md5 in the line at all, it doesn't show it. we should add that, to be consistent Sep 16 16:23:56 kergoth: thanks for idea! Sep 16 16:24:18 ahh didn't realize that.. I usually add a dummy one "md5=0000" just as a placeholder if I don't know Sep 16 16:24:51 yeah, me too. just happened to do file://foo without md5= one time and noticed it Sep 16 17:32:04 jo Sep 16 18:01:01 How do I remove a specific compiler flag for a given recipe? (I would like to remove the compiler flag -fvisibility-inlines-hidden from opensp, opensp_1.5.bb) to see if that is the cause of the linkage problems. Sep 16 18:08:17 runix: do a git grep on oe_filter_out, iirc Sep 16 18:08:22 that'll show some examples Sep 16 18:09:15 ugh, I hate svn merge. weak. Sep 16 18:10:38 thanks Sep 16 18:47:45 kergoth: I curse svn everyday Sep 16 18:48:19 I was hoping merging had improved since merge tracking got added, etc, but not so much :| Sep 16 18:49:13 when I have to work with SVN (read-only generally) I always import it into a git tree.. ;) Sep 16 18:49:36 I usually use git-svn Sep 16 18:50:04 ya same Sep 16 18:50:36 hi khem Sep 16 18:50:47 hey woglinde Sep 16 18:50:50 khem can you look at systemd in meta-oe Sep 16 18:51:04 the uclibc-patch stuff dont works anymore Sep 16 18:51:24 woglinde: hmmm did it get updated ? Sep 16 18:51:46 khem problem is in bitbake code somewhere Sep 16 18:51:57 woglinde: bitbake ? Sep 16 18:52:27 after some gap yesterday I did builds on latest and its building fine Sep 16 18:52:47 it dont likes Sep 16 18:52:48 UCLIBCPATCHES = "" Sep 16 18:52:48 UCLIBCPATCHES_libc-uclibc = "file://paper-over-mkostemp.patch \ Sep 16 18:52:48 file://format-replace-m-uclibc.patch \ Sep 16 18:52:49 " Sep 16 18:52:54 here Sep 16 18:53:40 ERROR: Error executing a python function in /devel/arm/git/setup-scripts/sources/meta-openembedded/meta-oe/recipes-core/systemd/systemd_git.bb: Sep 16 18:53:43 AttributeError: 'module' object has no attribute 'domain Sep 16 18:55:34 woglinde: hmm it could be something else Sep 16 18:55:39 how can I reproduce it Sep 16 18:56:26 here is the rest Sep 16 18:56:28 https://gist.github.com/1222815 Sep 16 18:59:18 hi jkridner Sep 16 19:01:25 hi Sep 16 19:03:10 hi denix Sep 16 19:03:21 heya woglinde Sep 16 19:03:51 ah, i see the problem. svn merge is almost like rebase, it applies the changes incrementally Sep 16 19:03:52 hrmph Sep 16 19:04:26 woglinde: lib/oe/patch.py has a bb.msg.fatal() call that uses bb.msg.domain. change that to bb.fatal and you'll get the proper message Sep 16 19:04:36 saw that yesterday Sep 16 19:05:26 wasnt there patches for all this stuff? Sep 16 19:10:09 * kergoth shrugs, didn't make any of the recent bb.msg changes Sep 16 19:10:41 woglinde: it seems a bitbake problem doesnt it Sep 16 19:11:26 I am trying again Sep 16 19:11:33 but need to recompile gcc-cross Sep 16 20:22:56 hi ant Sep 16 20:23:48 hm meta-oe Sep 16 20:24:00 WARNING: For recipe libgcc, the following files were installed but not shipped in any package: Sep 16 20:24:02 WARNING: /usr/lib/arm-angstrom-linux-uclibceabi/4.5.4/libgcov.a Sep 16 20:24:12 WARNING: QA Issue: No GNU_HASH in the elf binary: '/devel/arm/git/setup-scripts/build/tmp-angstrom_2010_x-uclibc/work/armv7a-angstrom-linux-uclibceabi/libgcc-4.5-r40+svnr176640/packages-split/libgcc/lib/libgcc_s.so.1' Sep 16 20:24:45 lack of libgcc_s.so.1 looks like a mistake to me Sep 16 20:29:52 fray? Sep 16 20:29:57 no lack Sep 16 20:30:00 only HASH Sep 16 20:31:14 woglinde_: can you try the patches I posted Sep 16 20:31:25 that should fix this problem Sep 16 20:31:28 khem hum Sep 16 20:31:31 not this evening Sep 16 20:31:51 or can I pull them easily? Sep 16 20:31:55 yes Sep 16 20:32:10 git remote add what? Sep 16 20:32:40 git://git.openembedded.org/openembedded-core-contrib kraj/hashstyle-eglibc-updates Sep 16 20:32:48 branch is kraj/hashstyle-eglibc-updates Sep 16 20:36:35 Crofton: ping Sep 16 20:36:58 hi woglinde_ Sep 16 20:37:06 hello khem, wb Sep 16 20:37:48 Crofton: have you been able to resolve internal compiler error while building kernel for usrp? Sep 16 20:38:17 hi fray, I reopened #775 Sep 16 20:41:09 hm hm which package needs bison-target Sep 16 20:41:20 HI! Got some issues with "do_install" for libgcc. There is "chown -R root:root {D}" string in a recipe and it fails, should i add fakeroot before this string? Sep 16 20:41:23 and flex-target Sep 16 20:41:34 I will find out Sep 16 20:41:50 mike11 uhm Sep 16 20:42:00 yeah try fakeroot Sep 16 20:42:11 dont know if we have a variable for it Sep 16 20:42:16 but a native package Sep 16 20:42:23 try git grep Sep 16 20:42:25 to find out Sep 16 20:44:10 hm intressting Sep 16 20:44:12 libpam-runtime Sep 16 20:44:15 needs it Sep 16 20:44:33 irrhks Sep 16 20:44:34 WARNING: For recipe libxml2, the following files were installed but not shipped in any package: Sep 16 20:44:37 WARNING: /usr/lib/libxml2.a Sep 16 20:54:05 ericben: Hi Sep 16 20:54:34 hi otavio Sep 16 20:55:08 woglinde_: :-) Sep 16 20:55:24 ericben: I've push my current translation fix to qt4 into https://github.com/OSSystems/oe-core/commits/master Sep 16 20:55:35 hi tartarus Sep 16 20:55:51 hey Sep 16 20:55:57 stupid/pidgin Sep 16 20:56:05 use psi Sep 16 20:56:08 *g* Sep 16 20:56:09 denix, no Sep 16 20:56:18 I have been at the gnuradio conference this week Sep 16 20:56:31 crofton hehe Sep 16 20:56:36 sold some units? Sep 16 20:57:00 ericben: it would be awesome if you could put it into your pull request Sep 16 20:57:06 Crofton: hmm, we are getting the same issue building 3.0.4 kernel with the toolchain from 2011.03-maintenance Sep 16 20:57:34 feels like something in the 3.0 kernel Sep 16 20:57:35 trying to see if there's anything needs to be ported from oe.dev/oe-core/meta-oe to fix that Sep 16 20:57:36 same file? Sep 16 20:58:01 yeah, same file same error - saw your identical pastebin Sep 16 20:58:14 cool Sep 16 20:58:29 crofton/denix where is the pastebin? Sep 16 20:58:45 ask denix0 I do not have it handy Sep 16 20:59:02 http://pastebin.com/ZDDm70ME and http://pastebin.com/tEhh6hdN Sep 16 20:59:10 * Crofton is checking in for his airline flight Sep 16 20:59:17 first is ours and second is Crofton's from 2 days ago Sep 16 20:59:29 Crofton: when are you back? Sep 16 20:59:48 tomorrow Sep 16 21:00:00 flying from PHL to ROA at 2100 Sep 16 21:00:11 in module.c Sep 16 21:00:14 intressting Sep 16 21:00:55 ok, back to "work" Sep 16 21:10:04 denix0: what issue do u see Sep 16 21:10:18 khem look at the pastebin Sep 16 21:10:25 kernel/module.c:3353:1: internal compiler error: in arm_unwind_emit, at config/arm/arm.c:22672 Sep 16 21:10:40 http://pastebin.com/ZDDm70ME and http://pastebin.com/tEhh6hdN Sep 16 21:10:47 but without source code Sep 16 21:11:10 denix0: thats a compiler problem Sep 16 21:11:12 woglinde_: which source code do you need? Sep 16 21:11:26 what is on module.c:3353 Sep 16 21:11:32 and config/arm/arm.c:22672 Sep 16 21:11:35 denix0: is it happening with some special flags ? Sep 16 21:11:38 like march Sep 16 21:11:51 khem: right. that's 3.0.4 kernel with toolchain from 2011.03-maintenance. it works with toolchain from oe-core/meta-oe Sep 16 21:12:10 denix0: I have fixed it on 4.5 branch in meta-oe Sep 16 21:12:21 denix0: you need to backport let me see which fix Sep 16 21:12:22 *g* Sep 16 21:12:46 khem: that's what I was looking for! a specific commit to backport! :) you are the man, thanks! Sep 16 21:14:47 uhm why usbutils needs bash Sep 16 21:15:44 test passed Sep 16 21:16:13 woglinde_: I noticed other packaginbg issues: libffi, glib2, dbus-glib Sep 16 21:16:47 I'd say a bit unexpected... Sep 16 21:16:55 hm they passed for me Sep 16 21:17:04 maybee you need build from scratch Sep 16 21:17:11 or QA? Sep 16 21:17:12 yes, but installs without packaging some files Sep 16 21:17:37 there are more Sep 16 21:17:46 unerwartet Sep 16 21:17:48 libcgroup for pam Sep 16 21:18:00 denix0: try this meta-openembedded/meta-oe/recipes-devtools/gcc/gcc-4.5/linaro/gcc-4.5-linaro-r99479.patch Sep 16 21:18:02 nobody fixing those QA? Sep 16 21:18:14 make yocto bugs Sep 16 21:18:20 low hanging fruits Sep 16 21:18:26 for the intel guys Sep 16 21:18:41 denix0: if my memory serves me right then there is another patch that might be needed to augment it Sep 16 21:18:46 ok, I'm already subscribed Sep 16 21:19:01 make a bug for usbutils-> bash dep too Sep 16 21:19:05 if not already is Sep 16 21:19:06 heh Sep 16 21:19:13 *g* Sep 16 21:19:18 he I am old Sep 16 21:19:19 and lazy Sep 16 21:20:09 hm wireless-tools have HASH error to Sep 16 21:23:45 woglinde_: Are you testing out oe-core or doing some quality check? Sep 16 21:25:25 Me again, I've made some corrections to recipes to add fakeroot, here is diff with my corrections http://dl.dropbox.com/u/2632562/fakeroot.patch Can it be usefull or it just wrong host system setup? Now I'm on Debian, but before I tried Ubuntu and compilation went without any troubles Sep 16 21:28:53 khem: thanks a lot! I'll give it a try Sep 16 21:29:05 gn Sep 16 21:29:09 bbl Sep 16 21:34:34 mike111: what made you add that patch? OE and OE-Core already support fake root privileges Sep 16 21:34:42 that sort of change shouldn't be required Sep 16 21:38:44 I've needed this changes to do "bitbake core-image-minimal", i'm not sure that this changes are really needed, but without them there is some errors with permitions. I'm using oe-core (git revision 20529035a4c0befb3c6bdbcb289a2de930fb143d) Sep 16 21:41:02 mike111: can you share what the errors are? how are you running bitbake? If you source the oe-init-build-env script it will set up your environment and then invoke bitbake from that shell you should have a pseudo program which performs fakeroot tasks Sep 16 21:43:43 I run ". ./oe-init-build-env ../build" then type "bitbake core-image-minimal" and then this error http://dl.dropbox.com/u/2632562/libgcc.log Sep 16 21:46:32 strange indeed, it's only libgcc where you see this error? Sep 16 21:48:08 no, also base-passwd, db and gcc-configure-runtime (but it is included by gcc). Sep 16 21:50:47 it happens on Debiam, but not on Ubuntu, maybe there is some Debian-specific stuff Sep 16 21:52:44 perhaps Sep 16 21:55:21 how old is your Debian? perhaps there's a problem with the build pseudo binary on that platform Sep 16 21:56:56 Debian GNU/Linux 6.0.2 (squeeze) latest stable release Sep 16 21:59:04 mike111: would you be willing to file a bug report on bugzilla.yoctoproject.org? Sep 16 21:59:16 sounds like something we should have the pseudo folks look at Sep 16 21:59:21 no rule to make target 'oldconfig' stop Sep 16 21:59:26 oe_runmake failed Sep 16 21:59:51 does that scream at anyone? for target linux_falconwing Sep 16 21:59:53 fray: ping? Sep 16 22:02:23 good nite Sep 16 22:18:02 is there a way to tell if bitbake suceeded? the return value seems wrong Sep 16 22:21:29 msm: it should return 0 on success at least Sep 16 22:28:30 bah.. how is it we have tzdata_2011g and tzcode-native_2011i in meta-oe? Can we get rid of both? Sep 16 22:29:28 * incandescant has a love-hate relationship with meat-oe Sep 16 22:29:38 meta-oe, even :-) Sep 16 22:29:50 incandescant: nice lapsus Sep 16 22:31:22 khem: 0 failures, and jenkins thinks it fails Sep 16 22:31:23 .... Sep 16 22:31:31 khem: anyways, gotta run now Sep 16 22:31:48 perhaps I have a love-hate relationship with meat, too? Sep 16 22:32:36 other recurrent is stale/stable Sep 16 22:37:02 hehe, debian stale? :-) Sep 16 22:37:42 lol Sep 16 22:45:26 khem: There's I guess still some problem with qa errors Sep 16 22:45:36 They cause a non-zero exit status and 0 failures message Sep 16 22:45:40 or at least they have historically Sep 16 22:46:26 ah right Sep 16 22:46:41 with logger I thought it was taken care of Sep 16 22:48:31 Tartarus: er, that shouldn't be the case anymore... Sep 16 22:48:42 Sounds like msm was hitting it Sep 16 22:51:18 Tartarus: all of the yocto builds would be marked as failed if that was the case... Sep 16 22:51:34 (on the autobuilder) Sep 16 23:20:36 confirmed, QA warnings don't set errno Sep 16 23:21:27 now, if you get a bb.error "ERROR: some message" outside of a task, that won't increase the errors count at the end but you'll get a non-zero exit value Sep 16 23:21:45 Right, exactly Sep 16 23:21:54 er, s/errno/exit code/ Sep 16 23:22:19 so we'd need to see the full output really Sep 16 23:22:20 You just confirmed you see both "0 failures" at the final message and a non-zero exit status Sep 16 23:22:24 yes? Sep 16 23:22:39 what I meant was it's possible Sep 16 23:23:05 but that's a genuine failure if that happens and it *should* return nonzero if something calls bb.error Sep 16 23:23:22 right Sep 16 23:23:26 but it's saying, confusingly Sep 16 23:23:30 textually, no errors Sep 16 23:23:33 exit code, non-zero Sep 16 23:23:38 the final message is somewhat misleading, I agree Sep 16 23:23:41 Which causes all sorts of havok Sep 16 23:24:07 if bb.error gets called you will see a line with "ERROR:" in the log somewhere Sep 16 23:25:56 yes Sep 16 23:26:11 It's just annoying that you can't use exit code as easily as expected Sep 16 23:26:23 Since it's not obvious from the final line that there's really a problem you need to look for Sep 16 23:27:17 but that's just an issue with that final message - sure we should fix that, but the exit code is correct under those circumstances Sep 17 00:30:05 hey msm Sep 17 00:30:35 msm: in sum, it's expected behavior that QA errors cause non-zero exit codes but also don't increase the "failed" task count Sep 17 00:35:02 right, how do I go and determine 0 failures besides parsing the output? Sep 17 00:36:25 Tartarus: ^ =) Sep 17 01:05:33 msm: look for failed task count Sep 17 01:06:23 NOTE: Tasks Summary: Attempted 3376 tasks of which 168 didn't need to be rerun and 0 failed. Sep 17 01:11:50 khem: yep… is there a strategy on the return code though? Sep 17 01:12:07 im fine with parsing the results either way **** ENDING LOGGING AT Sat Sep 17 02:59:57 2011