**** BEGIN LOGGING AT Tue Nov 15 02:59:57 2011 Nov 15 03:55:49 http://pastebin.com/dRb5Dum8 Nov 15 03:55:56 I keep running into problems Nov 15 03:56:08 anybody have any idea why some rpms build with "wierd" dependencie? Nov 15 03:56:33 my tcp-wrappers rpm is being built with a dep on libc.so.6(GLIBC_2.3) is needed by tcp-wrappers-7.6-r0.sh4 Nov 15 03:56:52 but the libc6 rpm doesnt have any of the (GLIBC_X.Y) PROVIDES Nov 15 03:57:03 this is happening on a small handful of rpms Nov 15 03:57:36 portmap, tcp-wrappers, gupnp Nov 15 03:58:04 In the past, if I've had issues like that, it's usually ended up being that somehow I got a host-contaminated binary in that had a dependency on a GLIBC_X.Y that the host had and the target didn't. Nov 15 03:58:13 Mind, this wasn't actually in yocto. :) Nov 15 03:58:21 not happening here... Nov 15 03:58:30 ]$ rpm2cpio tcp-wrappers-7.6-r0.sh4.rpm | cpio -div Nov 15 03:58:36 $ file usr/sbin/* Nov 15 03:58:36 usr/sbin/safe_finger: ELF 32-bit LSB executable, Hitachi SH, version 1 (SYSV), for GNU/Linux 2.6.16, dynamically linked (uses shared libs), for GNU/Linux 2.6.16, stripped Nov 15 03:58:56 Your argument is compelling. :) Nov 15 03:59:05 I've verified that everything is sh4, as far as I can tell Nov 15 04:00:18 though I can totally see how it would look like that would be happening Nov 15 04:01:07 Well, that's the one thing I've seen cause weird GLIBC_X.Y dependency issues. Nov 15 04:01:30 Congratulations! You have stumped the guy who happened to be looking at IRC. Your prize is... a long delay before the next person wanders through! Nov 15 04:01:52 I've not had much luck in irc here Nov 15 04:02:27 It has good days and bad days. Pretty specialized, still. Nov 15 04:02:44 Yocto has a very *slightly* smaller active user community than, say, Ubuntu. Nov 15 04:03:00 Heck, I'm only even here in case of pseudo stuff. Nov 15 04:03:10 yup. got that. Nov 15 04:03:28 so, you do psuedo? Nov 15 04:03:34 *pseudo Nov 15 04:03:42 Yah, it's my baby. Nov 15 04:03:55 I've started yocto/oe work as of about two weeks ago now. Nov 15 04:03:56 I was the one who said "I bet we could replace fakeroot. It shouldn't be too hard." Nov 15 04:04:20 trying to do bringup and port over what will be three different platforms over to yocto Nov 15 04:04:30 Trivia point: Suggesting that a major component of a build system be replaced by something that does not yet exist does not result in *someone else* writing it. :) Nov 15 04:04:35 Cool! Nov 15 04:04:53 oh, I've had the same experience. congrats. Nov 15 04:05:09 seebs, did you see my question above? =) Nov 15 04:05:38 Huh. Well, sorta yes, sorta no. Pseudo doesn't currently have any concept of where you "should" be writing. Nov 15 04:06:00 That said, if you turn on logging, you can do all SORTS of cool stuff. Nov 15 04:06:39 oh god Nov 15 04:06:49 pilot error nevermind =/ Nov 15 04:06:55 Ahh, see. Nov 15 04:07:06 That's why a future version of pseudo will have a rubber duckie mode. Nov 15 04:07:09 ok, enlighten me about debugging options, pls... Nov 15 04:07:17 In which you can tell it the problem you're having and it'll do nothing. :P Nov 15 04:07:44 Boy, haven't had to use it in ages. Basically, if you invoke pseudo "-l", I think, it then logs all filesystem operations it's aware of. Nov 15 04:07:51 You can then use the pseudolog utility to browse the logs. Nov 15 04:08:35 for future reference, how would I properly set pseudo options in my build? Nov 15 04:09:27 I don't actually know in yocto land. Nov 15 04:10:12 oe? Nov 15 04:10:15 I think that pseudolog -p ^project/path will dump stuff. Nov 15 04:10:20 Nah, I'm from the wrlinux side of things. :) Nov 15 04:10:45 ah. ok. Nov 15 04:10:51 You *might* get what you want by running PSEUDO_OPTS=-l [whatever command] Nov 15 04:11:19 ok. just collecting useful information for future use. thanks. Nov 15 04:11:50 pseudolog is much more powerful than it really needed to be. Nov 15 04:11:59 I got sort of caught up in writing a reasonably general interface. Nov 15 04:13:20 a common afflicton Nov 15 04:13:34 Net result, it's surprisingly good at being able to actually report what probably happened. Nov 15 07:50:19 Hi, whats the roadmap on possibly supplying pre-built native packages ?. I'm building the core-image-minimal, and it seems anything but minimal. Nov 15 09:43:18 How do you clean out a package to be rebuilt from scratch (eg. running through unpack to build)? Nov 15 09:43:31 Have tried "bitbake busybox -f -c clean" Nov 15 09:45:07 ...removed all files I have found related to busybox in work/stamps/cache. And still seems to think that the downloaded tar is already unpacked and fails at configure. Nov 15 09:45:54 -c cleansstate Nov 15 09:47:23 Still seems to think it's already unpacked Nov 15 09:47:41 and do_configure fails Nov 15 09:48:38 better to pastebin whole output because maybe you're doing something wrong.. Nov 15 09:49:15 sure Nov 15 09:50:09 http://pastebin.com/EE769isx Nov 15 09:52:10 Think it fails because there's no Makefile where it's supposed to be Nov 15 09:54:05 and ls /home/olle/cimpresshd/poky-edison-6.0/build/tmp/work/core2-poky-linux/busybox-1.18.5-r3/ ? Nov 15 09:55:20 contains "busybox-1.18.5 defconfig temp" Nov 15 09:55:34 busybox-1.18.5 is empty Nov 15 09:55:45 temp contains "log.do_cleansstate log.do_configure.25351 run.base_do_fetch.25347 run.do_cleansstate.25306 run.do_patch.25350 run.sstate_cleanall.25305 Nov 15 09:55:48 log.do_cleansstate.25306 log.do_unpack run.base_do_patch.25350 run.do_configure.25351 run.do_unpack.25348 run.sysroot_cleansstate.25351 Nov 15 09:55:51 log.do_configure log.do_unpack.25348 run.base_do_unpack.25348 run.do_fetch.25347 run.patch_do_patch.2535" Nov 15 09:56:38 sorry, busybox-1.18.5 contains ".config" Nov 15 10:01:42 and output from -c cleansstate? Nov 15 10:02:36 http://pastebin.com/2MNXd5Ew Nov 15 10:07:23 Any ideas? Nov 15 10:08:00 How does bitbake decide when a task has been executed and does not need to be runned again? Nov 15 10:08:55 from output it looks like it was propery executed, but not sure why there is no source in that folder :/ Nov 15 10:09:37 No, me neither Nov 15 10:09:52 maybe read temp/log.do_unpack for possible hints what went wrong Nov 15 10:10:02 It says it does unpack but the unpacking is done very quickly Nov 15 10:10:12 I'll check Nov 15 10:42:19 Seems like it was my .bbappend file's fault, but didn't see in the bitbake output that the bbappend was actually executed. But thanks for helping anyway JaMa . Nov 15 10:43:58 bitbake-layers show_appends will help you next time Nov 15 10:45:15 Nice, didn't know about that Nov 15 12:08:19 * JaMa happy to see patches flowing Nov 15 12:09:21 JaMa: thx for that...don't forget to finish X11 cleanings+improvemens, thx Nov 15 12:09:53 ant_work: feel free to do it as I don't have much time for it lately.. Nov 15 12:10:24 I'm sorry but I don't have yet the whole picture in my mind Nov 15 12:10:35 how is X11 supposed to evolve in oe-core? Nov 15 12:10:53 where have th edrivers to be hosted? Nov 15 12:11:10 meta-oe or oe-core? Nov 15 12:15:17 ant_work: which drivers? Nov 15 12:16:19 i.e. xf86-video-fbdev_0.4.2.bb Nov 15 12:16:33 not machine specific Nov 15 12:16:51 in which case I don't see why it can't be in core Nov 15 12:17:04 plus the whole xinput / xinput-calibrator stack Nov 15 12:17:21 (now that XCALIBRATE went away from X11) Nov 15 12:22:57 ant_work: my plan is to replace nodm-init with elsa autologin and needed in xserver-common to support xinput / xinput-calibrator by systemd service after starting elsa Nov 15 12:24:59 well, what about non systemd images? Nov 15 12:25:28 someone using them & xinput should think about it Nov 15 12:26:14 maybe I misunderstand but we cannot force oe-core to use systemd (yet) Nov 15 12:27:13 I'm not forcing anybody.. but my plan is to use systemd in images supported by me and then I won't be able to test non systemd images on my devices Nov 15 12:28:31 RP__: could you merge also libsdl patches? IIRC those weren't in sgw's consolidated pull just because alsa-nativesdk issue Nov 15 12:32:19 JaMa: ok, see it like this: I'd like to b able to build a core-image-sato using as few layers as possible Nov 15 12:32:46 and no distro, to test the (sane ?) defaults Nov 15 12:33:09 RP__: nvm, I've read your reply now :) Nov 15 12:33:24 doing that requires not trivial steps Nov 15 12:33:28 ant_work: ok, that's your goal, work on it Nov 15 12:33:29 today Nov 15 12:33:38 that's the point Nov 15 12:33:44 is not 'my' goal Nov 15 12:33:51 I/we pretend sane defaults Nov 15 12:34:04 I don't care about external distros/layers doing theirs tricks Nov 15 12:59:53 JaMa: trying to keep things moving whilst get some green builds... Nov 15 13:02:50 ant_work: you should be able to build core-image-sato without any layers Nov 15 13:11:38 RP__: sure, I just want to add my BSP Nov 15 13:12:43 RP__: and being the devices can use xfbdev and have touchscreen, I'd like to make good use of that so I need some bits of meta-oe Nov 15 13:13:31 RP__: simply adding full meta-oe layer has too many side-effects Nov 15 13:16:30 ant_work: you have a list of the meta-oe pieces? Nov 15 13:16:43 I didn't think Xfbdev or touchscreens were that badly suported in OE-Core Nov 15 13:16:58 ^_^ Nov 15 13:17:13 xfbdev is not in oe-core Nov 15 13:18:17 xtscal can't work with latest xserver (X 1.11 removed XCALIBRATE extension (xext)) Nov 15 13:19:32 so I picked xorg-driver/xf86-video-fbdev , xinput, xinput-calibrator Nov 15 13:20:35 and changed the RDEPENDS of x11-common Nov 15 13:21:52 to xserver-common? because you need xserver-common to call xinput-calibrator after xserver start Nov 15 13:22:22 in fact I've installed by hand to test calibration Nov 15 13:22:35 (and jitter ;) Nov 15 13:27:33 ant_work: ah, we should add xfbdev then Nov 15 13:28:19 JaMa: the second part of the story is indeed x11-common vs. xserver-common and related xserver-nodm-init falldown Nov 15 13:28:39 I see meta-oe is focusing on systemd support Nov 15 13:29:13 just don't see the same interest in oe-core...maybe I missed Nov 15 13:42:46 https://lists.yoctoproject.org/pipermail/yocto/2011-November/005652.html Nov 15 13:43:10 sent a message to mailing list yesterday. does anybody know how or why my rpm dependencies are messed up? Nov 15 13:44:19 I'm getting "Requires: libc.so.6(GLIBC_2.3)" in some RPMS, with no corresponding Provides: in the eglibc rpm Nov 15 13:54:03 hmm race condition between alsa-lib and base-passwd? Nov 15 13:54:04 | cp: cannot stat `/OE/shr-core/tmp-eglibc/sysroots/nokia900/usr/share/aclocal/alsa.m4': No such file or directory Nov 15 13:54:07 NOTE: package base-passwd-3.5.22-r9: task do_configure: Failed Nov 15 13:54:17 ERROR: Task 2399 (/OE/shr-core/openembedded-core/meta/recipes-core/base-passwd/base-passwd_3.5.22.bb, do_configure) failed with exit code '1' Nov 15 13:54:20 NOTE: Running task 6485 of 8448 (ID: 1388, /OE/shr-core/openembedded-core/meta/recipes-multimedia/alsa/alsa-lib_1.0.24.1.bb, do_populate_lic) Nov 15 14:41:42 RP__: btw with those changes I could boot core-image-sato on poodle and c7x0 http://paste.debian.net/145453/ http://paste.debian.net/145454/ Nov 15 14:42:00 well, doesn't shine on 32MiB devices... Nov 15 14:45:30 mebrown: which version of yocto is that? Nov 15 14:46:48 JaMa: Looks like a race where something is adding .m4 files yet aclocal is looping over them Nov 15 14:46:58 JaMa: I thought we added locking to avoid that :( Nov 15 14:47:10 er, removing, not adding Nov 15 16:24:24 http://pastebin.com/iUe3gWUL Nov 15 16:24:37 pygobject won't build Nov 15 16:24:44 soemthing is foul in python land Nov 15 16:44:54 RP__: alsa-lib is broken Nov 15 16:46:44 everything is broken :) Nov 15 16:49:04 deleting the tmp dir, shouldn't lead to several days of work fixing build breakages Nov 15 16:49:18 otavio: what's broken on alsa-lib? Nov 15 16:49:44 JaMa: Nov 15 16:49:45 | aclocal: unknown warning category `cross' Nov 15 16:49:46 | aclocal: aclocal: file `/home/ostt-devel/src/embedded-linux/tmp-eglibc-eglibc/sysroots/x86_64-linux/usr/share/aclocal/alsa.m4' does not exist Nov 15 16:49:48 | autoreconf: aclocal failed with exit status: 1 Nov 15 16:49:51 | + bbfatal 'autoreconf execution failed.' Nov 15 16:51:04 that's probably same race I reported before, isn't it? Nov 15 16:51:18 how you workarounded it? Nov 15 16:51:48 let alsa-lib finish build Nov 15 16:52:20 and then I have alsa.m4 again -rw-r--r-- 1 bitbake bitbake 4346 Nov 14 17:07 tmp-eglibc/sysroots/x86_64-linux/usr/share/aclocal/alsa.m4 Nov 15 16:52:22 http://pastebin.com/3YdPRAsm Nov 15 16:52:28 anothert python related fail Nov 15 16:53:10 Crofton|work: is your python-native taken from sstate? Nov 15 16:53:37 Crofton|work: check "python: wrong config/Makefile when reused sstate from other machine build" on OE-core ml Nov 15 16:53:50 this is all built local Nov 15 16:54:04 so nothing copied from elswhere Nov 15 16:57:49 I wonder how this passwd the autobuild test; it failed onto my autobuilder and my manual build Nov 15 17:00:09 maybe it is doing incremental builds? Nov 15 17:00:59 Crofton|work: I had it built too and it failed anyway Nov 15 17:02:09 Crofton|work: was the above an incremental or a build from scratch? Nov 15 17:02:24 I styarted from scratch and have been falling over failures Nov 15 17:02:31 I can start again Nov 15 17:02:41 since work is completly messed up Nov 15 17:02:42 JaMa: hello Nov 15 17:02:55 Crofton|work: and no previous sstate-cache? Nov 15 17:03:04 hmm Nov 15 17:03:12 is that always under tmp? Nov 15 17:03:14 * Crofton|work looks Nov 15 17:03:18 Crofton|work: no Nov 15 17:03:27 urg Nov 15 17:03:35 so I need to wack sstae and tmp ..... Nov 15 17:03:38 Crofton|work: I know it *should* work but I suspect something has gone wrong Nov 15 17:03:47 suspect ? Nov 15 17:04:00 wacking both and restarting ..... Nov 15 17:04:15 RP__: i reproduce it in two builds Nov 15 17:04:33 otavio: reproduced what exactly Nov 15 17:05:01 RP__: alsa-lib fail Nov 15 17:08:24 otavio: you mean the race between alsa-lib and base-passwd? Nov 15 17:08:42 otavio: presumably restarting the build continues past that? Nov 15 17:09:48 otavio: I suspect I didn't see that as I tested the changes in isolation :/ Nov 15 17:09:56 otavio: (or in a from scratch build) Nov 15 17:10:09 RP__: might be Nov 15 17:10:19 RP__: but you have a cooked fix for it? Nov 15 17:10:39 otavio: no, I don't even know what the problem is and have not reproduced it Nov 15 17:11:01 I really do my best to help people but I can't work miracles :( Nov 15 17:11:22 about races, anybody has seen the install of linux-firmwares fail? Nov 15 17:11:42 ant_work: not here Nov 15 17:12:00 I somehow reproduced that Nov 15 17:12:08 8 BB threads, -j5 Nov 15 17:12:42 ant_work: being able to reproduce it puts you in a great position to try and fix it... Nov 15 17:12:53 ;) Nov 15 17:13:08 I somehow remembering someone laying with PARALLEL_ stuff... Nov 15 17:13:13 *playing Nov 15 17:13:37 if you look at the linux firmware recipe, its hard to see how its racing. How did it fail? Nov 15 17:13:56 it happens on do_install Nov 15 17:14:10 I have a fresh failure, last night Nov 15 17:14:13 ant_work: pastebin please Nov 15 17:14:23 sure, let me head home ;) Nov 15 17:14:25 bbl Nov 15 17:14:29 thx Nov 15 17:15:46 RP__: a log helps? Nov 15 17:20:05 otavio: maybe, yes Nov 15 17:20:49 otavio: I just tried all kinds of permutations of trying to get base-passwd and alsa-lib to conflict with each other here and failed :( Nov 15 17:21:52 RP__: http://arquivos.ossystems.com.br/~otavio/ostt-image-ossystems-x86-15-05-10.log Nov 15 17:33:29 otavio: maybe you and I can sit down on Thursday or Friday and look at this together! Nov 15 17:34:46 JaMa: I am still having problems with the libsdl change, seems to be a problem with meta-toolchain-gmae, I am looking into, but libsdl is causeing virtual/libgl-nativesdk to get pulled in and nothing currently provides that. Nov 15 17:37:50 otavio: FWIW I can't find the code I thought existed to prevent this Nov 15 17:40:54 otavio: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=23774530c1c2df8c306807d20baaea693250ef16 Nov 15 17:41:14 otavio: http://bugzilla.pokylinux.org/show_bug.cgi?id=861 Nov 15 17:41:34 I thought we did a), not b) so its no wonder I couldn't find the code Nov 15 17:56:05 otavio: If you can reproduce this bug, try adding export ACLOCAL="aclocal --acdir=${B}/aclocal-copy/" to the bottom of that if statement that the above patch adds. Nov 15 18:02:15 bottom line I think we need to override aclocal's internal idea of where to look for those files Nov 15 18:02:21 please file a bug and we can take it from there Nov 15 18:20:31 how do you guys normally iterate development on a given recipie? I find myself running: bitbake -c cleanall foo; bitbake foo Nov 15 18:22:17 walters, you can save yourself some time not redownloading the sources each time if instead you do bitbake -c cleansstate foo; bitbake foo Nov 15 18:22:32 ah hah Nov 15 18:22:34 that will wipe everything except your sources Nov 15 18:22:36 that's what i want indeed Nov 15 18:22:39 thank you! Nov 15 18:22:42 np Nov 15 21:39:55 hi bluelightning Nov 15 21:40:02 hi ant____ Nov 15 21:40:25 RP__: log of the race http://paste.debian.net/145641/ Nov 15 21:44:12 ant____: which just goes to show communication is tricky. I thought you meant the "linux-firmware" recipe was buggy Nov 15 21:44:30 ouch..no, just basic stuff Nov 15 21:45:19 ant____: does make modules_install on a kernel install firmware these days? Nov 15 21:45:28 ant____: It looks like a bug in the kernel makefiles if it does Nov 15 21:45:45 ant____: missing dependencies on the directory creation Nov 15 21:46:10 usually after 5-6 bitbake core-image-sato the recipe completes Nov 15 21:46:37 ant____: it looks like a kernel makefile bug Nov 15 21:47:03 it happened with 2.6.39.4 sources , very frequently if not always Nov 15 21:47:13 now with 3.1.1 this is the first time Nov 15 21:47:32 ant____: that doesn't change my diagnosis Nov 15 21:47:38 I think we can exclude layer-inducted issues Nov 15 21:51:50 RP__: I suspect bitbake.conf: Start using parallel make for do_install Nov 15 21:52:21 ant____: well, yes. You can also disable that on a per recipe basis PARALLEL_MAKEINST = "" Nov 15 21:52:23 the issue appeared in the last months Nov 15 21:52:37 I'd prefer the problem fixed properly, obviously Nov 15 23:02:45 sgw: what if I use PACKAGECONFIG only for alsa? Nov 15 23:02:49 RP__: just trying rebuild it "fixed" it Nov 15 23:02:58 RP__: so I cannot reproduce it again Nov 15 23:03:54 sgw: I don't have alsa or opengl in DISTRO_FEATURES.. that's why I didn't see the issue with alsa-nativesdk in first place, but PACKAGECONFIG does not support to add DEPENDS only for target and keep DEPENDS_virtclass-sth without it Nov 15 23:03:55 JaMa: that might be part of it, so how would you handle the opengl case? Nov 15 23:04:14 sgw: keep it as it was with hardcode DISTRO_FEATURE checks Nov 15 23:04:47 So we need to extend the way PACKAGECONFIG works? Nov 15 23:04:52 sgw: when you asked to turn alsa into PACKAGECONFIG I've changed opengl the same (as they are doing the same) Nov 15 23:05:11 not sure if it's worth extending PACKAGECONFIG Nov 15 23:05:21 as usually you want to add it to all DEPENDS Nov 15 23:06:36 sgw: but old state was also probably wrong in this aspect because it did pass --enable-opengl while overriding DEPENDS_virtclass-nativesdk (to be without opengl in it) Nov 15 23:06:54 right I understand, ok let's see get the DISTRO_FEATURE back, please test with alsa and opengl, I know they aren't part of your changes, but they tripped us up and I want to make sure it's working, because it take our time to track down the failure. Nov 15 23:15:16 sgw: you come to Brazil tomorrow? Nov 15 23:16:03 sgw: I will arrive in Sao Paulo tomorrow night Nov 15 23:16:22 sgw: be aware ... it is raining :) Nov 15 23:18:43 sgw: it's updated in jansa/pull now (as 2 separate commits, one for alsa PACKAGECONFIG and last patch for opengl as PACKAGECONFIG which should not be applied) Nov 15 23:19:31 JaMa: maybe drop it from pull them? :P Nov 15 23:20:02 I'm not sending this pull Nov 15 23:20:39 it's in that branch as reminder that PACKAGECONFIG does not work in some cases Nov 15 23:31:15 sgw: "[CONSOLIDATED PULL 02/16] default-providers: add alsa to resolve multiple runtime providers" this shouldn't be needed as my PKGSUFFIX patch for alsa-lib is in now Nov 15 23:36:31 otavio: I actually arrive Thursday morning at 6:30am I will try to be awake for my talk at 5:30pm! Nov 15 23:37:19 JaMa|Zzz: Ok, I will review that with RP__. Nov 15 23:40:50 sgw: I see. Nov 15 23:41:00 sgw: see you there then Nov 15 23:41:13 sgw: and I hope you have a nice trip Nov 15 23:51:34 otavio: me also, I could not get the upgrade, so I hope to have an exit seat maybe. Nov 15 23:56:58 sgw: are you in Brazil ? Nov 15 23:57:17 khem: I will be on Thursday, are you back? Nov 15 23:57:50 yes Nov 15 23:57:54 today Nov 15 23:58:10 severly Jet lagged Nov 15 23:58:21 wb Nov 15 23:58:55 khem: welcome back! nitink also just returned and I asked him to look into the beagleboard issue and check with you if needed, so he might be in touch in the next day or so. Nov 15 23:59:16 yes Nov 15 23:59:17 It was tough having both the compiler guys gone at the same time! Nov 15 23:59:38 Crofton|work: thx Nov 16 00:04:38 RP__, that's built from the edison git tag Nov 16 00:05:33 oh netbase is not fetchable Nov 16 00:20:03 sgw, khem: I could reproduce the issue here, will get back to you regarding it soon Nov 16 00:20:36 ok **** ENDING LOGGING AT Wed Nov 16 02:59:57 2011