**** BEGIN LOGGING AT Thu Dec 22 02:59:57 2011 Dec 22 10:39:28 morning all Dec 22 12:50:32 morning Dec 22 12:55:10 good morning Dec 22 14:55:41 Hmm, is there a machine/layer for crossville? Dec 22 14:55:54 doesn't look like it at first glance, was curious, though Dec 22 14:56:38 * kergoth kicks google, not being very helpful about this platform Dec 22 15:04:45 kergoth: crossville? Dec 22 15:27:45 bluelightning: don't know much about it, appears to be an intel-based machine used in automotive. looks like nothing out there yet Dec 22 15:27:58 hmm, the qemu kvm workaround for rhel5 in qemu.inc doesn't appear to work Dec 22 15:28:07 need to do a --disable-kvm, not just not pass --enable-kvm Dec 22 15:35:29 argh, I even wondered about using --disable-kvm Dec 22 15:35:45 but FWIW the patch does work on CentOS 5.7 as-is Dec 22 15:36:03 kergoth: are you building on actual RHEL? which version? Dec 22 15:36:32 nah, it's an ancient box, I'm sure its not officially supported, but figured it was worth noting Dec 22 15:36:37 this is CentOS 5.4 :) Dec 22 15:37:09 well personally if it's not a huge patch, does no harm and helps people I'm in favour of fixing it :) Dec 22 15:37:25 * kergoth nods Dec 22 15:43:53 kergoth: I'm having some trouble with error handling in bitbake's multithreading parsing. Taking out the self.pool.terminate() in cooker.py allows the errors to be shown Dec 22 15:44:46 interesting, maybe the threads are still feeding events, don't get flushed? Hmm Dec 22 15:44:53 kergoth: Does anything spring to mind about logging interaction with the processes? (a straight print goes onto the console) Dec 22 15:45:32 * kergoth thinks back Dec 22 15:53:10 kergoth: I think this may be the same issue Stefen reported on the list where bitbake just appears to hang Dec 22 15:53:15 Nothing is immediately coming to mind. IIRC it shouldn't be terminating in the common case, just in a failure mode Dec 22 15:53:28 terminate() uses SIGTERM, and can corrupt any open queues/pipes Dec 22 15:53:37 according to http://docs.python.org/library/multiprocessing.html, anyway Dec 22 15:53:44 it's been quite a while since I looked at that code Dec 22 15:54:03 I'll take a look at the code later today, if need be, don't have time right now Dec 22 15:54:17 kergoth: Right, the issue is that rather than showing the user some error, its just sitting there with now output until you Ctrl+C out of it Dec 22 15:54:34 kergoth: I'd appreciate it if you could take a look later, thanks Dec 22 15:54:39 I tested a wide variety of cases when I originally wrote it, including various recipe parse failures Dec 22 15:55:09 kergoth: I don't doubt it but there is something odd going on, maybe some bad interaction with some later changes or something Dec 22 15:55:30 yeah, perhaps. will take a look later, hopefully it's something I cat spot via inspection :) Dec 22 15:57:42 afaik what it *should* be doing is a close(), then join() (or let it join implicitly), letting them shut down naturally. terminate() should only be used, iirc, if someone needs to force a shutdown. will see Dec 22 16:17:19 bluelightning: ping Dec 22 16:17:26 hi sgw Dec 22 16:18:05 bluelightning: good afternoon can you take a quick glance at the qt4 failures on the Autobuilder Dec 22 16:18:47 bluelightning: beagleboard has it. Dec 22 16:19:17 sgw: you mean http://autobuilder.yoctoproject.org:8010/builders/nightly-arm/builds/232/steps/shell_81/logs/stdio ? Dec 22 16:19:24 that one at least is an internal compiler error Dec 22 16:20:39 kergoth: To reproduce this you seem to need to trigger parsing failures in some subset of recipes. I could do this by changing sstate.bbclass' anonymous python to d.setVar2('SSTATE_PKGARCH', d.getVar('BUILD_ARCH')) in the inherits native case Dec 22 16:20:44 bluelightning: do you know why it's cropping up now? Did something else change? Dec 22 16:21:13 kergoth: If I do that it just sits at "Parsing recipes:" Dec 22 16:21:52 sgw: I don't, but it looks a lot like this issue: https://bugs.launchpad.net/gcc-linaro/+bug/723185 Dec 22 16:23:30 sgw: my next port of call was going to be khem Dec 22 16:24:28 bluelightning: thanks Dec 22 16:25:18 bluelightning, congrats on your election to the TSC Dec 22 16:25:36 zenlinux: thanks :) Dec 22 17:56:36 bluelightning: nice find with the qt native tools Dec 22 17:57:30 RP__: yeah I'm glad it was that simple... still not positive on how it became intermittent but I'm guessing it's a make vs. date/time race Dec 22 17:57:53 well, mtime Dec 22 17:58:44 I figured those install commands were new but I traced them all the way back to 2007 in oe-classic.. Dec 22 18:00:02 RP__: any idea what enabling libiberty in which actually does? Dec 22 18:00:59 bluelightning: I had a look and it seems just different memory allocation routines. Nothing I felt depending on binutils was warranted for Dec 22 18:01:24 doesn't sound like a fair exchange no Dec 22 18:03:05 quick sanity check. I know _ isn't valid in a package name, but is it also not valid in a version? I'm pretty sure its invalid in either case, but wanted to confirm Dec 22 18:17:05 bluelightning: check with nitink also, do we have that in master now, have not checked yet Dec 22 18:18:44 sgw: I have to admit that I have not seen it and I built qt4 for qemuarm just today (although it was qt4-embedded) Dec 22 18:39:19 sgw: have emailed Dec 22 18:39:21 bbl Dec 22 18:41:06 RP__: have you seen my reply on dbus issue? there are important parts of log.do_rootfs, but I'll share whole.. scping it now Dec 22 18:51:22 RP__: http://build.shr-project.org/tests/jama/dbus-issue/ Dec 22 18:54:28 zeddii: can you comment on this error log http://autobuilder.yoctoproject.org:8010/builders/nightly-mips/builds/209/steps/shell_30/logs/stdio Dec 22 18:55:28 zeddii: should the kernel be depending on binutils to ensure all bits are in place? Dec 22 19:03:56 sgw. nothing has changed in that area. so I'm surprised that popped up. Dec 22 19:04:04 that's being triggered from the perf-tool build. Dec 22 19:04:26 has anyone poked at that lately, it does use bfd to manipulate symbols, etc. Dec 22 19:05:08 zeddii: it was a build of edison 1.1.1 with a load of sstate, so there might have been an ordering issue. Dec 22 19:05:53 sgw. ok. but yes, there would be a dependency there. just hidden until now perhaps ? we can fix it by disabling demangling of symbols if it comes back. Dec 22 19:06:27 the builtin-kvm.c error being reported on the log is odd though, this is surely perf related from my check. I'll go look again to be sure. Dec 22 19:06:56 zeddii: thanks Dec 22 19:08:42 I just searched the entire kernel source, only user of bfd.h is perf, so regardless of the log, this must be triggered there, and as you said, could just be a lurking ordering issue. Dec 22 20:39:03 JaMa: Do you have those packages in a feed somewhere? Dec 22 20:47:27 RP__: yes http://jama.homelinux.org/org.openembedded.shr-core/ Dec 22 20:48:54 JaMa: hmm, that url isn't working well here :( Dec 22 20:49:05 RP__: looking for this? http://paste.pocoo.org/show/524701/ Dec 22 20:49:13 RP__: yes http://jama.dyndns-home.com/org.openembedded.shr-core/ Dec 22 20:53:56 JaMa: Partly, I was going to try building a small image off your feed and see if I can reproduce this Dec 22 20:56:23 RP__ do you think there would be an objections of the buildstats inherit was removed from base.bbclass and added to either the iNHERI_DISTRO or USER_CLASSES? Dec 22 20:56:32 this should resolve the runtask issue I found a bit ago.. Dec 22 20:56:46 fray: I'm ok with that Dec 22 20:56:53 any preference? Dec 22 20:58:07 (I'm leaning toward user_classes myself) Dec 22 21:09:07 any hint why 'INHERIT_append_pn-phoneuid = "srctree gitpkgv"' doesnt' work anymore? it worked with OE-classic Dec 22 21:13:00 fray: sounds ok off the top of my head without looking at the code Dec 22 21:13:09 JaMa: nothing oe-core specific, likely bitbake Dec 22 21:14:03 RP__: ok :/ Dec 22 21:14:03 ok.. I'll work on a patch.. Dec 22 21:14:51 JaMa: I'm surprised at that ever working tbh Dec 22 21:48:10 JaMa: I have a reproducer for this using your feed, debugging the opkg code now... Dec 22 21:51:37 RP__: great, thanks! Dec 22 21:59:37 JaMa: I think I've found the problem, and can explain why this only fails on some machines Dec 22 22:00:39 * JaMa fetches coffee and listens :) Dec 22 22:00:50 JaMa: it only happens on feeds where there is more than one base-passwd package available (armv4 and armv5te in this case) Dec 22 22:03:56 that brings me to other question, I'm using meta-oe/recipes-core/meta/distro-feed-configs.bb is there something like this in oe-core? Dec 22 22:04:54 because this has (in combination with opkg and oe-core small problem) "for feed in all ${PACKAGE_EXTRA_ARCHS} ${MACHINE_ARCH}; do" produces a lot of feeds Dec 22 22:06:19 http://paste.pocoo.org/show/524723/ and only a few does exist on server (ie no package with just arm architecture -> no Package.gz) Dec 22 22:06:37 so it shows a lot of 404 errors for opkg upgrade Dec 22 22:06:43 ^W update Dec 22 22:07:29 and what's worse opkg will upgrade to foo-1.0_armv4t and stay with this 1.0 even if there is foo-1.0_armv5t with higher priority later Dec 22 22:07:51 JaMa: I guess its up to the distro to decide which feeds are on the server... Dec 22 22:08:10 JaMa: noting its compatible with an architecture is different to having a feed for it Dec 22 22:08:51 I'm just asking if someone found some better solution than what's in meta-oe (imported from oe-core) Dec 22 22:09:37 JaMa: I think http://paste.pocoo.org/show/524724/ is the fix Dec 22 22:10:16 JaMa: I'm not aware of anything Dec 22 22:10:26 ok, I'll try on spitz Dec 22 22:10:52 de Dec 22 22:10:57 JaMa: thanks. My quick remote test showed the installation order changed in a positive way Dec 22 22:11:28 zeddii: any reason your new kerenl stuff with fail with fri2? Dec 22 22:11:28 fatal: A branch named 'yocto/eg20t' already exists. Dec 22 22:11:29 | ERROR: could not complete git cmd "git branch yocto/eg20t yocto/base" Dec 22 22:11:29 | ERROR. could not update git tree Dec 22 22:12:16 RP__: just cleansstate opkg opkg-native; build image, right? Dec 22 22:12:23 JaMa: yes Dec 22 22:13:22 RP__: and do you know what does e.g. RPM when there is the same version of some package (as installed) but with higher arch priority? Dec 22 22:13:54 JaMa: rpm installs from each arch in descending priority Dec 22 22:13:57 RP__: does it reinstall (ie to get machine specific package instead of arch specific) or does it ignore such "upgrade" like opkg does? Dec 22 22:14:17 JaMa: I'm actually not sure what it would do Dec 22 22:15:00 RP__: the problem is when the same version gets available for that arch later (so without version change) Dec 22 22:15:17 JaMa: I can see the problem :/ Dec 22 22:15:59 I was talking with Graham about it and IIRC the conclusion was something like "difficult to do with current opkg codebase" Dec 22 22:16:14 hi JaMa, RP Dec 22 22:16:23 fray: Any idea what on target device rpm would do if a more optimised package architecture became available? Dec 22 22:17:39 RP__: I've finally seen why /boot/zImage symlink is missing... in oe-classic the symlink is added by kernel.postinst Dec 22 22:17:49 JaMa: I can imagine that being a hard thing to fix :/ Dec 22 22:17:52 for som ereasons this doesn't happen in oe-core Dec 22 22:20:49 RP__: as work around, I'm rsyncing feeds in descending priority, but that's still not 100% Dec 22 22:20:58 * RP__ loves the fact that this behaviour change is from a variable called "quiet" Dec 22 22:23:34 yes, pkg_postinst_kernel () seems ignored Dec 22 22:23:39 hm... Dec 22 22:35:30 RP__: ... still running :/, btw any hint for that package-index taking damn long? Dec 22 22:37:18 RP__: ah, I think I see why... it is kernel-image-3.1.4.postinst ' Dec 22 22:37:43 and not opkg/info/kernel.postinst anymore Dec 22 22:40:07 JaMa: I've not looked at that problem, no :/ Dec 22 22:40:23 RP__: opkg patch worked.. image saved, thanks again! http://paste.pocoo.org/show/524730/ Dec 22 22:40:44 JaMa: great! :) Dec 22 22:40:49 JaMa: I'll push that Dec 22 22:44:28 JaMa: its in master Dec 22 22:44:41 I can't see anyone reviewing that any better than we just have :) Dec 22 22:53:20 :) Dec 22 22:53:40 I'll remove postinst from shr branch and test it even more on other hosts tomorrow Dec 22 22:55:42 jeez.. that's new "Cannot satisfy the following dependencies for task-core-x11-sato:| * libsdl * Dec 22 22:59:23 ant____: missing PR bump somewhere Dec 22 22:59:30 ant____: after fixing libsdl packaging Dec 22 23:00:36 ant____: you can also add RREPLACES to libsdl to fix upgrade path Dec 22 23:01:14 I see, thx Dec 22 23:05:45 JaMa: are your issues with gcc-cross solved now Dec 22 23:06:43 khem: no Dec 22 23:14:36 JaMa: some of the issues you said were bewildering Dec 22 23:14:46 but one which changed the sysroot seems a real one Dec 22 23:18:14 khem: I've seen a lot of issues with last toolchain update and they were real.. but I'm not saying they were new or caused by your patch Dec 22 23:19:43 khem: basically rebuild from scratch as well as increamental builds are failing on all 3 machines where I'm building and I have reports from other users too, but it behaves quite unreproducible as whole, so I cannot even report what is wrong Dec 22 23:19:43 patch or not those errors sounded that something has been misconfigured and then rerun Dec 22 23:20:24 JaMa: hmm interestin Dec 22 23:20:34 I would like to understand the problem Dec 22 23:20:48 e.g. today eglibc-initial was failing because of empty /OE/shr-core/tmp/sysroots/om-gta04-tcbootstrap/usr/include/ Dec 22 23:21:16 this was build of new machine on that host -> om-gta04 Dec 22 23:22:42 so it reused some parts of previous armv7a builds and it was after finishing gcc-cross-initial Dec 22 23:23:28 NOTE: package gcc-cross-initial-4.6.2+svnr181430-r23: task do_populate_sysroot: Succeeded Dec 22 23:24:00 to build eglibc-initial without cleaning (which would wipe all other armv7a machines) I've used: Dec 22 23:24:03 bitbake -b /OE/shr-core/openembedded-core/meta/recipes-core/eglibc/eglibc_2.14.bb -c unpack -f Dec 22 23:24:33 with eglibc-initial_2.14.bb.. then eglibc failed so I have used the same ^ Dec 22 23:27:01 JaMa: eglibc-initial expects linux-headers to be there so empty /usr/include seems problem to me Dec 22 23:28:01 let me check cooker log when were linux-libc-headers installed Dec 22 23:29:43 NOTE: package linux-libc-headers-3.1-r1: task do_populate_sysroot: Succeeded just before gcc-cross-initial failed Dec 22 23:30:50 ok so eglibc-initial should not have begun before gcc-cross-initial:do_populate_sysroot finished Dec 22 23:31:10 since thats a dependency for eglibc-initial Dec 22 23:31:53 http://build.shr-project.org/tests/jama/gcc-issue/ here are cooker logs if you don't belive me Dec 22 23:33:25 I do believe you Dec 22 23:33:39 trying to think through the problem Dec 22 23:33:52 did you have sstate populated with other build Dec 22 23:34:03 probably for similar arch e.g. armv7a Dec 22 23:34:10 but different machine Dec 22 23:38:01 I've added bash.history to that dir with commenst to show which command resulted in which cooker log Dec 22 23:39:20 khem: I've removed sstate-cache completely before starting that first command in bash.history so from toolchain only binutils was there (because of PR bump) Dec 22 23:41:04 khem: and WORKDIR was also clean before this build Dec 22 23:41:21 I'm not even using rm_work (only rm_old_work now) Dec 22 23:43:10 hmm Dec 22 23:43:19 so you did bitbake -k gcc-cross Dec 22 23:43:22 essentially Dec 22 23:44:23 why unpack -f ? Dec 22 23:45:39 to rebuild eglibc-initial from scratch without removing stamps by -c cleansstate Dec 23 00:44:52 hm, is there an easy way to get a debug shell in a sysroot? Dec 23 00:45:10 basically to where i can run 'make' manually Dec 23 01:12:12 bitbake -cdevshell Dec 23 01:16:07 khem, <3 Dec 23 01:17:15 initially it failed, but that appears to be because i am in both a jhbuild and oe-init-build-env shell Dec 23 01:17:47 this makes me notice i have probably polluted my yocto builds with the jhbuild environment variables =/ **** ENDING LOGGING AT Fri Dec 23 02:59:56 2011