**** BEGIN LOGGING AT Thu Jan 05 02:59:57 2012 Jan 05 06:11:28 RP__, okay, I'm pretty sure I know what's going on, and I'm testing a couple different ways of fixing it. Should have something in the next day or two Jan 05 06:24:19 i am getting an error for oe_runmake install func , http://pastebin.com/3PmKf7j9 does anyone has any idea Jan 05 06:56:02 erwt: makefile of x264 project doesn't have "install" target Jan 05 06:56:29 la4de, then how do i add it Jan 05 06:57:12 bcoz my build process stops there Jan 05 07:01:30 la4de, thanks a lot Jan 05 07:09:30 if the project does not have a make install in it's makefile then what is the preferred method to install it? Jan 05 07:51:38 la4de: that was the trick, thanks a lot :) Jan 05 07:51:44 (just reading the backlog now) Jan 05 08:00:20 erwt: i just checked x264 source files and there was makefile with install target. is your makefile corrupted somehow? try: bitbake x264 -c cleanall && bitbake x264 Jan 05 08:01:12 la4de, ya i will try that Jan 05 08:13:21 morning all Jan 05 08:17:39 morning Jan 05 08:17:55 bluelightning: fwiw my qt4-x11-free build with oe-core gcc also finished fine Jan 05 08:18:21 bluelightning: rebuilding now with meta-oe and will discuss it with khem if I can reproduce it, thanks for testing and 4.8 :) Jan 05 08:18:22 JaMa: hi Jan 05 08:18:40 JaMa: OK, no problems... I guess it's likely it's the meta-oe gcc Jan 05 08:19:38 ouch Jan 05 10:00:14 la4de, do you the latest uclibc version which has all patches and works well with all packages ,i am using 0.9.30.2-r35.1 Jan 05 10:21:22 bluelightning: more info about that ICE issue http://lists.linuxtogo.org/pipermail/openembedded-devel/2012-January/037179.html Jan 05 10:37:39 erwt: sorry, what was your question? i haven't compiled anything. i just downloaded source tar ball of x264 and checked makefile Jan 05 10:40:14 la4de, I think there are not enough patches for uclibc version 0.9.30.2 so i asked the latest stable uclibc version Jan 05 10:44:14 i have never used uclibc. can't help Jan 05 10:48:14 la4de, thk Jan 05 13:10:40 when running do_configure, the environment (PATH etc.) should be set with the correct values rig Jan 05 13:10:42 ht? Jan 05 13:11:15 I have a autotools project here, that is using AC_PATH_PROGS to find moc Jan 05 13:11:21 and it picks up the one from my host (!) Jan 05 13:16:25 hmmm no the env seems right, at least in do_configure_prepend Jan 05 15:54:58 kergoth: cool, you were able to reproduce ok then? :) Jan 05 15:55:20 yeah. though its not every time, its random Jan 05 15:55:41 kergoth: I'm using a lot of threads here which perhaps makes it happen more often Jan 05 15:55:58 I *think* what's happening is active usage of the Queue connecting the processes to the UI while they receive the sigterm from the terminate() may be corrupting the queue in a way that affects the other processes using it Jan 05 15:56:07 the multiprocessing docs about Process.terminate() mention this Jan 05 15:56:31 still working on it Jan 05 15:56:49 but it would explain this behavior, since that queue is how log messages get to the ui Jan 05 15:57:17 at least, it explains the silence, not so much the hang Jan 05 15:57:21 getting there. Jan 05 15:57:31 kergoth: yes, makes sense. its a tricky one... Jan 05 15:59:13 I was playing around with possibly replacing multiprocessing.Pool with the backport of python 3.2's concurrent.futures, and the problem doesn't occur Jan 05 15:59:19 it finishes parsing the current files and then exits Jan 05 15:59:35 for what thats worth. but i'd like to avoid the backport unless we have to, so i'm working on a home rolled method Jan 05 16:00:36 kergoth: I did wonder whether we could delay the terminate call somehow until there was no progress Jan 05 16:01:50 kergoth: right, backport from 3.2 is a possibility but probably worth avoiding if we can Jan 05 16:02:10 yeah, basically a more clean shutdown. the problem with Pool is, once jobs are inbound, you can't tell it to stop handing them off. Jan 05 16:02:15 insufficient control over it Jan 05 16:02:30 futures gives you a future object back from each job handoff, and that future can be canceled Jan 05 16:02:36 if canceled, it won't work on it Jan 05 16:03:03 RP__, the backport already eixsts, its a copy/paste, but still, less clutter in lib/bb is good ;) Jan 05 16:03:32 so I'm working on changing how we do the job handoff at the moment Jan 05 16:03:33 will see Jan 05 16:03:55 http://pypi.python.org/pypi/futures - for reference Jan 05 16:11:26 has anyone seen this build failure recently? Jan 05 16:11:27 https://gist.github.com/1565817 Jan 05 16:13:58 I havn't.. but that is a weird one Jan 05 16:31:17 fray: not reproducible though Jan 05 16:36:12 something is wrong with the new QA warning code Jan 05 16:36:20 bluelightning: remember the issue I had yesterday with python-pyside-examples? Well, after deleting every file/dir under tmp/ which mentioned pyside-examples, rebuilt the package, and now the RDEPENDS works as suposed :) Jan 05 16:36:20 a function "check_output" appears to be missing from the merge Jan 05 16:36:26 (poky maste) Jan 05 16:36:55 s0undt3ch: great... would be nice to know why it failed yesterday, but at least it works now :) Jan 05 16:43:05 bluelightning: my only guess is some "cached" stuff prevented the new package to be built, re-using what was already packaged, which, did not contain the python-pyside-embedded dep Jan 05 17:42:26 drat the prelinker doesn't seem to be "working" on MIPS.. it completes at least now.. but the binaries are not loading at their prelinked addresses.. Jan 05 17:42:43 now I'm checking ARM to see if it's happening there... Jan 05 17:50:37 the only check_output I know of is the one in subprocess, which exists in 2.7 but not 2.6 Jan 05 17:50:50 if someone is using that one in the metadata, that's a problem, theys hould use bb.process or something for now Jan 05 17:51:05 * kergoth hasn't looked at that failure though Jan 05 17:52:15 linux-yocto failed in perf tools Jan 05 17:52:28 did someone unbreak it already Jan 05 17:52:36 I havent tried an update today Jan 05 17:52:55 the only problem I am aware of is the QA issue.. with the workaround of removing the check Jan 05 17:57:41 util/include/linux/compiler.h:8:0: error: "__attribute_const__" redefined [-Werror] Jan 05 18:06:44 in this case, 4MB of "something" before the data really begins.. Jan 05 18:07:38 crap wrong channel Jan 05 18:12:23 ok so its not fixed Jan 05 18:14:03 Does someone see this http://paste.ubuntu.com/794010/ Jan 05 18:47:32 khem: what task is that? Jan 05 18:48:00 do_compile_perf? Jan 05 18:50:51 bitbake failing? Jan 05 18:50:52 | ERROR: Error executing a python function in /home/otavio/hacking/ossystems/embedded-linux/openembedded-core/meta/recipes-core/util-linux/util-linux_2.20.1.bb: Jan 05 18:50:55 | AttributeError: 'module' object has no attribute 'check_output' Jan 05 18:51:11 otavio: there is something on the ML about that Jan 05 18:51:26 Python 2.7 code introduced by accident Jan 05 18:52:36 incandescant: seems like a good case for a git revert Jan 05 18:53:01 otavio: possibly, I've not read the list yet this morning so I don't know if that's been discussed Jan 05 18:54:16 otavio: you can disable the py2.7 using QA check until it's fixed. Add the following to your local.conf: Jan 05 18:54:16 WARN_QA = "ldflags useless-rpaths rpaths" Jan 05 18:59:11 otavio, I'm testing a fix for that now Jan 05 18:59:26 frantically trying to get a fix ready in the next few hours Jan 05 18:59:43 zenlinux: nice Jan 05 19:02:52 someone fix this? http://www.yoctoproject.org/projects/openembedded-core Jan 05 19:03:22 i think there should be a layer meta-oe right on top of oe-core, it should not be yocto directly on top of oe-core Jan 05 19:26:44 kergoth, what's the benefit of using bb.process.popen vs. os.popen? Jan 05 19:30:11 zenlinux: bb.process.popen does add sane default params to it Jan 05 19:30:30 like shell=False which if True can be a security risk Jan 05 19:31:47 xxiao: fix what exactly? Jan 05 19:41:21 khem, I see, thanks Jan 05 19:45:31 I have a patch for perf which is part of linux-yocto Jan 05 19:45:38 whats the process to submit it Jan 05 19:45:53 since I dont see usual patch files for linux-yocto Jan 05 19:45:58 the patch is here http://paste.ubuntu.com/794114/ Jan 05 19:46:09 zenlinux: bb.process.popen wraps subprocess.popen, which is the future of system calls in Python. Mainly to provide a more unified/consistent API afaics - http://www.python.org/dev/peps/pep-0324/ Jan 05 19:48:13 and better error handling and communication with the called process Jan 05 19:54:14 incandescant: i think there is a big layer between oe-core and yocto itself, it's meta-oe Jan 05 19:54:54 xxiao: that's not strictly correct at all, the Poky system shipped by the Yocto project does not include meta-oe Jan 05 19:55:07 xxiao: what makes you think that's the case? Jan 05 19:55:26 i think TI arm and possible freescale layer need that Jan 05 19:55:51 xxiao: that may be true, but that doesn't make the diagram incorrect Jan 05 19:55:58 the yocto layer does not need meta-oe Jan 05 19:56:03 ok then Jan 05 19:58:11 incandescant: it should be poky layer and not yocto layer Jan 05 19:58:37 if yocto is umbrella project Jan 05 20:07:48 zenlinux, you mean vs the Popen class? os.popen is extremely low level. python provides subprocess.Popen, which we then adjust further Jan 05 20:08:03 xxiao: meta-ti is mostly done with meta-angstrom in mind. I use it with meta-oe only but there're some corner cases in this scenario Jan 05 20:09:12 xxiao: meta-freescale works with oe-core only Jan 05 20:09:39 otavio: I think whatever is used by developers the dependencies nature accordingly Jan 05 20:09:41 And there's a certain amount of needing to get stuff that meta-ti needs but lives in meta-angstrom moved to meta-oe or oe-core, as appropriate Jan 05 20:09:45 It's just not there, yet Jan 05 20:09:48 its when its used in more than one scenario Jan 05 20:09:54 and I expect meta-oe to be like that Jan 05 20:52:13 RP__, kergoth: how does this look? http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=sgarman/qa-fix&id=5af4de45676535f36acc8f009122cb24a1a804e3 Jan 05 20:57:01 you remove the logic surrounding the return code, was that intentional? and if so, why isn't it mentioned in the commit message? Jan 05 20:57:13 the return co de is still available in the popen object Jan 05 20:58:12 pipe = bb.process.Popen(["prelink-rtld", "--root", sysroot_path, path], stdout=sub.PIPE); output = pipe.communicate()[0]; print(pipe.returncode); Jan 05 20:58:26 kergoth, yeah, I was just about to improve the commit message - since process.Popen doesn't throw an exception when the return status != 0, I'm just ignoring it now, because the previous warning was mostly noise Jan 05 20:59:27 this qa test is intended to focus on specific paths that binaries might be linked to, and not to handle cases where there is a missing library Jan 05 20:59:42 * kergoth nods Jan 05 21:00:07 zenlinux: why do u need stdout=sub.PIPE there Jan 05 21:00:13 it should be default isnt it Jan 05 21:00:28 good point, that should indeed be default with our Popen Jan 05 21:00:51 khem, I was following an example of the code as it was used in buildstats.bblcass, I believe. Thanks for the tip Jan 05 21:01:49 zenlinux: also, did you not see bb.process.run(), which returns the output and raises an exception on failure? Jan 05 21:02:03 same behavior as check_output, just a different exception raised and slightly different implementaiton Jan 05 21:02:23 kergoth, I started out trying to use bb.process.run, but didn't get it to work immediately Jan 05 21:02:55 it's used in a number of places and works fine in those.. Jan 05 21:02:57 * kergoth shrugs Jan 05 21:03:07 the whole point of it was to avoid the need to fuss with Popen for the common case Jan 05 21:03:17 hmmm, perhaps I'll revisit it then Jan 05 21:05:49 either way works, was just curious Jan 05 21:06:23 it might be best for me to get this committed ASAP and then refactor it again...just trying to be mindful that builds are broken now, and I want to resolve that ASAP Jan 05 21:10:44 * kergoth nods Jan 05 21:10:48 fair enough :) Jan 05 21:13:18 RP__, pull request sent Jan 05 21:14:51 I see This message may not have been sent by: xxx@yyyy.com regularly Jan 05 21:15:00 for emails from oe-devel and oe-core Jan 05 21:15:25 I wonder if there is some config problem with mailman Jan 05 21:27:19 I am trying to compile mono on target hardware (using core-image-sato-sdk for now). I am getting the following error and I am not sure what to do. libtool: link: cannot find the library `=/usr/lib/libglib-2.0.la' or unhandled argument `=/usr/lib/libglib-2.0.la' Jan 05 21:28:27 in the filesystem /usr/lib/libglib-2.0.la does exist and seems to be valid Jan 05 21:29:05 i wanted to ask here before asking over at #monodev Jan 05 22:10:52 zenlinux: thanks for the quick turnaround, I'll merge it Jan 05 22:11:15 sgw: autobuilder is pretty much green which is nice :) Jan 05 22:11:32 One failure due to a known locking issue already being worked upon Jan 05 22:11:43 RP__: great news, I saw that one failure. Jan 05 22:13:33 msm: ping Jan 05 22:16:05 RP__, sgw: is this a known issue against latest poky-master for meta-toolchain? http://pastebin.com/sWRHBqkb Jan 05 22:17:00 jzhang: looks like you hit the problem zenlinux just fixed with the qa tests Jan 05 22:17:02 jzhang: fixed by zenlinux's patch Jan 05 22:17:38 good and sounds like RP__ going to merge it pretty soon? Jan 05 22:17:55 jzhang: it just merged as of 5 seconds ago Jan 05 22:18:04 RP__: It seems you missed some patches you claimed to have pulled (the matchbox change and libusb from zenlinux) Jan 05 22:18:16 sgw: oh, sorry :/ Jan 05 22:18:20 cool, will do my local update Jan 05 22:18:21 sgw: let me merge them Jan 05 22:18:46 RP__: No problem, I also repaired my commit messages Jan 05 22:18:59 sgw: hi Jan 05 22:19:41 sgw: good catch, thanks Jan 05 22:19:51 msm: I am looking into an older bug #1535 space issue Jan 05 22:20:19 sgw: ah Jan 05 22:20:27 sgw: im not sure i've seen that in a while Jan 05 22:20:27 RP__: part of my behind the scene tracking Jan 05 22:20:45 sgw: right, helps to have us both keeping an eye on the patches Jan 05 22:20:47 msm ok, do you remember what image/machine combo you where building? Jan 05 22:21:38 sgw: I did a confusion on the depmod patch; ignore it Jan 05 22:21:43 msm: I want to try and reproduce it or close and "worksforme" Jan 05 22:21:49 otavio: OK Jan 05 22:22:57 sgw: let me find a thread for you Jan 05 22:23:15 sgw: the person who submitted the bug had a long email Jan 05 22:23:33 it was on an 831x Jan 05 22:24:16 msm: thanks, does it mention the image? minimal, sato, ??? Jan 05 22:25:25 sgw: http://article.gmane.org/gmane.linux.embedded.yocto.general/2661/match=rootfs+ramdisk+error Jan 05 22:26:55 msm great thanks. Jan 05 22:32:36 autif: that error means your libtool is old in the package Jan 05 22:32:41 otavio: why disable the syslog.conf? We have a change in already that renames it to syslog-startup.conf for the init.d/syslog Jan 05 22:32:47 autif: to autoreconf your package Jan 05 22:34:44 sgw: in this case this works for me; the problem of having it as syslog.conf is that it makes busybox' syslog unusable Jan 05 22:35:34 sgw: i didn't see this patch Jan 05 22:35:57 otavio: as I said this was fixed, do you have a layer with a syslog.conf? If maybe rename it to syslog-startup.conf Jan 05 22:36:22 sgw: I'll check it Jan 05 22:37:23 otavio: in oe-core: b406998 busybox: rename syslog.conf to syslog-startup.conf Jan 05 22:37:49 It came in in the huge pull from a couple of days ago. Jan 05 22:39:09 sgw: found it Jan 05 22:39:12 sgw: works for me Jan 05 22:39:25 Ok great, I will drop that patch then Jan 05 22:46:11 sgw: i had it queued for long time Jan 05 22:46:18 sgw: drop it, better Jan 05 22:46:37 sgw: u want to do bug triage, or we cancel for this week since we had the meeting this Tue, and Darren's out Jan 05 22:48:55 jzhang: cancel Jan 05 23:02:04 nitink: ping Jan 05 23:06:17 halstead: you around? Jan 05 23:07:13 sgw, Yes. Currently in a web design call with jefro and Tracey. Jan 05 23:07:40 halstead: Ok, please ping me when done. Jan 05 23:07:57 sgw, Will do. Jan 05 23:13:49 anyone saw this error for meta-toolchain? * satisfy_dependencies_for: Cannot satisfy the following dependencies for task-sdk-host-nativesdk: Jan 05 23:13:49 | * m4 * gnu-config * Jan 05 23:13:49 | * opkg_install_cmd: Cannot install package task-sdk-host-nativesdk. Jan 05 23:21:24 zeddii: are do you have the PPC kernel changes (matching with the qemuppc changeset) in the recent kernel patch Jan 05 23:29:31 jzhang: pong Jan 05 23:30:20 nitink: do you know the above error that i ran into seems relate to autotool m4 for nativesdk Jan 05 23:31:00 jzhang: you may need to build from scratch, after automake upgrade the file generated by old automake are breaking things Jan 05 23:31:21 nitink: this is a scratch build Jan 05 23:32:02 jzhang: i did build meta-toolchain couple of days ago, and it worked. I will try again Jan 05 23:32:38 nitink: this is against latest poky master for x86-arm Jan 05 23:33:38 jzhang: I am trying here, will let you know more later Jan 05 23:34:01 thx Jan 05 23:39:21 sgw, I have a moment now. Jan 06 00:28:22 jzhang: the meta-toolchain is building fine for me for qemuarm machine Jan 06 00:29:08 nitink: interesting, this is against latest poky master? Jan 06 00:29:29 It was master from the morning Jan 06 00:31:37 and you didn't hit the do_package_qa issue as well which zenlinux had a patch this afternoon? Jan 06 00:31:54 + my local commits Jan 06 00:32:00 I did not hit that issue Jan 06 00:32:38 ok, how do a clean rebuild of toolchain, I can give that a try... Jan 06 00:33:45 jzhang: delete everything except conf directory from your build directory, and rebuild Jan 06 00:35:32 jzhang: I thought your's was a build from scratch Jan 06 00:35:58 nitink: it is, it's a newly cloned poky-master Jan 06 00:36:35 jzhang: when did you clone it? Jan 06 00:36:59 this afternoon then I did an update to pull in the package_qa fix Jan 06 00:37:27 I see Jan 06 00:39:39 jzhang: I am also doing another build from scratch to verify the issue is not getting masked at my side Jan 06 00:40:07 I'm building against another meta which hasn't run build against and I just did update, i'll let you know the result, if it still fails, probably you have to clone the latest poky master and give that a try... Jan 06 00:57:05 pidge: you around, have an AB question for you. Jan 06 00:59:22 sgw: yup, what's up? Jan 06 01:01:33 pidge: nevermind, must have been stuck in the checkout (rm phase) and needed to finish before allowing me to restart (started master by accident). Jan 06 01:02:59 sgw: hrm. weirdness. I'll look at that as I muck with the layer tooling for it. Jan 06 02:31:35 jzhang: I am seeing the issue now, RP: It is caused by this commit: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=0fa52f70789afe5a53384ba20249af34c16a8568 Jan 06 02:41:22 and I have a fix for the issue now Jan 06 02:49:04 jzhang: fix sent to OEcore mailing list **** ENDING LOGGING AT Fri Jan 06 02:59:57 2012