**** BEGIN LOGGING AT Wed Jun 27 02:59:58 2012 Jun 27 08:28:08 hm hm we need to teach bitbake an option that it runs only 2 or 3 task with heavy disk access at once Jun 27 08:48:15 | pth_mctx.c: In function '__pth_mctx_set': Jun 27 08:48:15 | pth_mctx.c:170:1: error: expected expression before ')' token Jun 27 08:48:15 | pth_mctx.c:171:1: error: expected expression before ')' token Jun 27 08:48:15 | make: *** [pth_mctx.lo] Error 1 Jun 27 08:48:18 | ERROR: oe_runmake failed Jun 27 08:48:21 | ERROR: Function failed: do_compile (see /home/hrw/HDD/devel/canonical/ci-linaro/oecore/build/tmp-eglibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/pth-2.0.7-r2/temp/log.do_compile.11534 for further information) Jun 27 08:48:24 ugly ;( Jun 27 08:48:29 woglinde: define 'heavy disk' ;( Jun 27 08:48:38 woglinde: some unpacks or rather compile? Jun 27 08:49:03 with fast cpus do_compile can be more disk heavy than unpack Jun 27 08:50:29 unpack packaging sysroot staging Jun 27 08:50:42 ups sstate Jun 27 09:00:51 * JaMa using tmpfs for workdir, so do_compile/do_install/do_package are quite fine here, only unpack, sstate IO bound Jun 27 09:01:24 so if you plan to teach it, keep in mind this scenario too :) Jun 27 09:01:27 jama I dont have this much ram Jun 27 09:01:38 JaMa thats why I meant option Jun 27 09:01:49 so everyone can suite it to his needs Jun 27 09:02:33 I know.. but the option should have different list of tasks which are IO hungry for different scenarios Jun 27 09:03:28 like optimize IO for whole tmpdir or optimize IO only for sysroots/sstate-cache etc Jun 27 09:04:34 but from last benchmarks it seems like intel people have SSDs almost as fast as my tmpfs is, so they don't see IO as bottleneck Jun 27 09:04:59 maybee the xfs fs is the bottleneck here Jun 27 09:05:37 ext4 here Jun 27 09:05:46 and ~100MB/s hdd Jun 27 09:06:09 JaMa: I lack 48GB of ram to have workdir in tmpfs Jun 27 09:06:28 *g* Jun 27 09:06:40 hrw buy an ssd Jun 27 09:07:21 I'm using 16G ram -> building image in smaller steps to give rmwork a chance to cleanup it before next step Jun 27 09:07:24 woglinde: my desktop has 60GB ssd/sata, 500GB hdd/sata, 1.5TB hdd/sata, 3TB hdd/usb3 Jun 27 09:07:28 woglinde: and 16GB ram Jun 27 09:07:55 e.g. gcc, kernel, lite-image, webkit-gtk, webkit-efl, qt4-x11-free, full-image Jun 27 09:09:06 JaMa hm there was an option to do all tasks on a package including rm_work after another Jun 27 09:09:06 ok, someone got pth to fail? Jun 27 09:10:25 woglinde: if you mean that hint to scheduler to try to finish package as soon as possible then it's not so precise as building in steps Jun 27 09:10:50 woglinde: and e.g. webkits are very close to 16G boundary here Jun 27 09:11:10 so nothing else can be in workdir if building them with sstate enabled Jun 27 09:21:37 hi all Jun 27 09:22:12 the completion scheduler does get used when rm_work is enabled but it seems it does not result in do_rm_work to happening throughout the build Jun 27 09:25:42 hi bluelightning Jun 27 09:28:01 bluelightning: hi, did you notice my e-mail about buildhistory tracking runtime package names? Jun 27 09:28:41 JaMa: er, I might have missed that one - when did you send it? Jun 27 09:29:27 about a week ago, mmt will find it (it was about libjpeg-turbo and I've just added you to Cc because of buildhistory question..) Jun 27 09:30:08 blupp: http://lists.linuxtogo.org/pipermail/openembedded-devel/2012-June/040135.html Jun 27 09:35:15 JaMa: hmm, that would be useful information to record Jun 27 09:35:37 JaMa: I'll investigate - sorry for missing the message originally Jun 27 09:36:13 yup a lot of upgrade issues is caused by those renames from debian.bbclass, so it would be really usefull Jun 27 09:36:38 no problem I planed to resend it with updated subject if needed Jun 27 09:40:34 hi all Jun 27 09:44:35 hi pb Jun 27 09:44:52 hello, crowded today ! Jun 27 09:45:06 hm why we dont use the older libpng which dont have the arm optimisations? Jun 27 09:46:14 hi pb_ Jun 27 09:46:58 good morning Jun 27 09:47:08 hi florian Jun 27 09:47:38 JaMa, pb_, woglinde: what do you think about the status of the things today? It is clear there is any valid updated OE documentation and the site suffers bitrot. On the Yocto side things are luckily different. Jun 27 09:47:48 bluelightning: florian: ^^ you too Jun 27 09:48:38 Documentatation is bad as always imho Jun 27 09:49:00 most docs reflect oe-classic Jun 27 09:49:38 the plan we were discussing in a TSC meeting a while ago was that we would have a "wiki day" where we would all try to pitch in and fix a whole bunch of pages at once Jun 27 09:49:57 unfortunately I never got around to sending out the email proposing it to the wider community... Jun 27 09:51:00 It would be useful to propagate this to Yocto folks since they are the most experienced users of oe-core and might be able to contribute documentation stuff they already have. Jun 27 09:51:45 about Yocto, just two words: after one year there is still the confusion yocto/poky . meta-oe seems beautifully disregarded (now and then I read some plans but nothing happens). Jun 27 09:52:07 oe-core is just fine Jun 27 09:53:22 I wouldn't say disregarded - as you mentioned on a number of occasions there are some pieces in there that ought to be moved into oe-core (e.g. some of the X11 stuff) and there are pieces that need to be cleaned up (e.g. systemd) Jun 27 09:53:40 but motivation to actually do that work seems to be, well, lacking Jun 27 09:56:12 regarding meta-oe, yes, we seem to have periodic discussions on the mailing list about things which "should be done" to improve it, but little seems to actually happen. Jun 27 09:57:00 which, I guess, is a bit of a vicious circle: it's problematic, so people don't use it, and when they aren't using it they don't have a great deal of motivation to make it better. Jun 27 09:57:04 I guess the most immediate help would be if anyone using systemd who has not already evaluated the patch series to split it out to a separate layer could do so Jun 27 09:57:06 the same we can say about gnome stuff in oe-core ... Jun 27 09:57:23 there is patchset for that already Jun 27 09:57:27 sato, you mean? Jun 27 09:57:40 I've tested it and after review we're waiting for v2 Jun 27 09:57:43 JaMa: patchset for which? Jun 27 09:57:52 meta-systemd population Jun 27 09:57:58 right, so we're waiting for Andreas to send out a v2 Jun 27 09:58:56 IMHO biggest problem of meta-oe is that nobody seems to like it.. and tries to push every recipe to oe-core Jun 27 09:59:11 instead of creating smaller layer in meta-oe repo Jun 27 09:59:13 lunch.. Jun 27 09:59:36 JaMa: I think if it did less things (and especially less unexpected things) then it would be more acceptable Jun 27 10:00:45 yes, exactly. Jun 27 10:01:16 the first thing is to move out systemd... then we have to look at what other things are overlayed and try to resolve those Jun 27 10:01:46 specifically, if it tried to confine itself to adding new recipes (rather than making arbitrary behaviour changes/upgrades/downgrades of ones that are in oe-core) then it would be much easier to enable without suffering a load of unwanted fallout. Jun 27 10:02:00 pb_: right, exactly Jun 27 10:02:12 bluelightning: outstanding are e.g. udev and xserver, just two little crumbs ;) Jun 27 10:03:26 it's sad to say it but I've stopped includinf full meta-oe long ago Jun 27 10:03:43 yeah, I think many people are in the same situation. Jun 27 10:03:49 core-image- are b0rked by that Jun 27 10:03:57 personally, I just cherry-pick recipes that I want from meta-oe into a private layer. Jun 27 10:04:06 right, and lots of other people do the same Jun 27 10:04:08 which sucks, but meta-oe itself is just too toxic to turn on the whole thing. Jun 27 10:05:29 the first stopper is the old udev in oe-core. an upgrade is overdue Jun 27 10:06:13 ant_work: seems that way to me as well... especially since we're using a much newer kernel, eglibc etc. in oe-core now Jun 27 10:08:21 we have no declared no-update-reason in the distro tracking files, and I don't recall anyone saying "no, we can't upgrade udev because..." recently Jun 27 10:08:47 anyway, we could well send a CEWG proposal for the documentation work. Ever Tim Bird got lost... Jun 27 10:10:04 hm is it possible to exclude sstate for some packages? Jun 27 10:11:57 woglinde: why do you need to do that? Jun 27 10:12:32 I'm not sure it's possible to exclude sstate at all nowadays/ Jun 27 10:12:36 bluelightning ti-xdctools for instance Jun 27 10:12:55 that only copies some gigs around Jun 27 10:15:09 so this is closed-source I presume...? Jun 27 10:15:33 hi bluelightning Jun 27 10:15:35 some stuff Jun 27 10:15:40 hi Noor Jun 27 10:16:05 if it does any compiling at all we're at least saving that part... Jun 27 10:16:32 I have one confusion ..... right now oe-core do_fetch does not check shasum and md5sum of the source file it is downloading ... is it correct? Jun 27 10:16:54 bluelightning or would do_sstatefoo () {} help in the .bb? Jun 27 10:32:30 woglinde: staging relies on sstate functioning correctly so I suspect that will break things, unless nothing cares about that being staged Jun 27 10:32:37 still might cause breakage though Jun 27 10:33:02 Noor: it will, unless a .done file exists indicating the check has been performed when the file was previously fetched Jun 27 10:37:32 bluelightning: strange thing is happening ... i removed source folder and remove md5sum line from recipe as well but bitbake is still not throwing error Jun 27 10:38:13 Noor: right, but is it true that the file exists in DL_DIR and so does a corresponding file with .done appended to the name ? Jun 27 10:49:23 bluelightning: I removed DL_DIR folder Jun 27 10:50:46 Noor: so it's actually performing a do_fetch step for that recipe? Jun 27 10:51:37 yeah Jun 27 10:52:57 bluelightning: after do_fetch i can see tar file and .done file in DL_DIR Jun 27 10:53:10 that is not expected behaviour Jun 27 10:53:28 yeah Jun 27 10:54:04 Noor: which version of bitbake are you using? Jun 27 10:54:50 bluelightning: thats why I said I am facing strange behaviour .... I compared the base_do_fetch with oe classic and I saw that on oe classic we have some md5sum checks but those checks are not in oe-core do_fetch Jun 27 10:55:10 that checking is done in bitbake's fetcher code now Jun 27 10:55:49 bitbake 1.15.1 Jun 27 10:57:45 Noor: are you using a local source mirror? Jun 27 10:58:23 bluelightning: yeah Jun 27 10:58:23 i.e. do you have something pointing to a file:// location in PREMIRRORS/MIRRORS in your configuration Jun 27 10:58:31 right, that bug was fixed after 1.15.1 Jun 27 10:59:09 http://patches.openembedded.org/patch/27533/ Jun 27 10:59:31 bluelightning: aaahhhh OK .... thanks very much Jun 27 11:00:15 mystery solved :) Jun 27 11:00:19 woglinde: SIGGEN_EXCLUDERECIPES_ABISAFE in layer.conf Jun 27 11:01:12 jama uhm Jun 27 11:01:13 JaMa: woglinde: if you're talking about stopping it from being rebuilt because of deps that is the mechanism, but it seemed to me you were asking about just disabling it entirely Jun 27 11:01:30 s/you/woglinde/ Jun 27 11:01:38 bluelightning yes entirely for some recipes Jun 27 11:01:46 I don't think that's possible Jun 27 11:01:50 okay Jun 27 11:03:44 if it's just moving files then exclude common deps and it shouldn't be so bad Jun 27 11:07:16 woglinde: yeah .... some tasks like do_deploy and do_populate_sysroot depend on sstate Jun 27 11:07:39 so i cant execute those tasks without sstate if u r using oe-core Jun 27 11:07:49 noor sure Jun 27 11:12:03 woglinde: for internals of sstate u can look my blog http://noorahsankhawaja.blogspot.com/ Jun 27 11:12:13 i will be sending out it second part sooon Jun 27 11:15:50 also there is now a section in the yocto project reference manual: http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#shared-state-cache Jun 27 11:19:21 bluelightning: after applying the patch the behavior is still the same :( Jun 27 11:19:28 need to dig more into it Jun 27 11:39:48 can someone try armv7ahf-vfp-neon build of pth? Jun 27 14:23:03 Hello! Please help with uclinux romfs building! Jun 27 14:23:46 hm Jun 27 14:25:58 I try to "make romfs", but output said "cp: cannot stat `busybox`: no such file in directory". Then I added full path in Makefile, but error still present... Jun 27 14:26:21 make? Jun 27 14:26:26 we use bitbake Jun 27 14:26:33 which may call make Jun 27 14:26:34 oh.. Jun 27 14:27:07 so what the difference? Jun 27 14:27:55 It is small problem, I think, but google doesn't helped me yet Jun 27 14:29:00 openembedded is a distro building project Jun 27 14:29:24 we support some uclinux stuff but I dont know the state Jun 27 14:30:29 Ok, sorry and thanks! Jun 27 15:21:43 hm. does armv7ahf works for somene? Jun 27 16:26:20 hrw: yes it works Jun 27 16:26:38 hrw: if you are on master it should work better Jun 27 16:31:52 khem: try to build pth Jun 27 16:32:29 khem: gcc 4.7.1/oecore/master for armv7a works, armv7a-thumb works, armv7ahf-vfp-neon fails, armv7ahf-vfp fails Jun 27 16:33:23 khem: reverted gcc update, armv7ahf-vfp fails ;( Jun 27 16:33:35 wtf... have to do build in clean precise chroot probably Jun 27 16:34:18 hrw: thats interesting Jun 27 16:34:23 is it compile error or what Jun 27 16:35:26 khem: http://pastebin.com/RY5BFfBj Jun 27 16:35:31 compile error Jun 27 16:35:55 qemuarm, qemux86, qemuarmv7a (softfp) compile Jun 27 16:41:14 pth_mctx.c:170 what does that line look like Jun 27 16:45:49 >170 mctx->uc.uc_stack.ss_sp = pth_skaddr(makecontext, sk_addr_lo, sk_addr_hi-sk_addr_lo); Jun 27 16:45:59 171 mctx->uc.uc_stack.ss_size = pth_sksize(makecontext, sk_addr_lo, sk_addr_hi-sk_addr_lo); Jun 27 16:47:54 same with oecore and linaro gcc Jun 27 16:55:22 hrw: nothing seems obvious there Jun 27 16:55:30 can you preprocess this file and see Jun 27 16:55:39 with a working compiler and one with non working compiler Jun 27 16:55:54 I assume there is something getting wiped out may be due to defines Jun 27 16:56:11 ok Jun 27 16:58:08 will do that tomorrow - have to go Jun 27 17:41:04 RP_: because bitbake understands now git:// (PRE)MIRRORS, would it make sense to modfiy latest_revision() to try PREMIRRORS? This will allow to expand ${AUTOREV} in offline case. Jun 27 17:48:07 hi stefan Jun 27 17:48:25 hi woglinde Jun 27 18:10:22 re Jun 27 18:10:32 hi florian Jun 27 18:58:10 woglinde: spain or portugal Jun 27 18:58:27 woglinde: I think portugal will stun iberians Jun 27 18:58:40 I think they are peaking at right time Jun 27 21:32:17 khem 4:2 Jun 27 21:32:19 for spain **** ENDING LOGGING AT Thu Jun 28 02:59:58 2012