**** BEGIN LOGGING AT Fri Jun 28 02:59:58 2013 Jun 28 07:51:13 good morning Jun 28 08:27:59 is there some issue with bitbake removing more functions from shell tasks (when creating run.do_task.sh) then it should be? Jun 28 08:28:44 with pkgsize=`get_size_of_installed_package $pkg`, it fails because get_size_of_installed_package was optimized out, adding it without `` works Jun 28 08:39:31 JaMa: It only adds functions it can see being used so this sounds like a bug in the pysh parsing Jun 28 08:39:39 jama: does doing pkgsize=$(get_size_of_installed_package $pkg) make any difference? Jun 28 08:40:17 JaMa: you can "fool" if with an 'if false get_size_of_installed_package fi' type expression Jun 28 08:41:32 heh. clever :) Jun 28 08:43:36 RP: yes I have something like that now Jun 28 08:43:45 but prefixing with false is even better :) Jun 28 08:44:04 RP: do you remember why this wasn't merged? other 2 sstate changes were http://patches.openembedded.org/patch/51429/ Jun 28 08:44:31 JaMa: Its an ugly hack and I was worried about how it would interact with the bitbake-worker changes Jun 28 08:44:42 RP: ok fair enough Jun 28 08:44:50 I think the latter is ok having thought more about it, I would still prefer it were fixed properly Jun 28 08:45:04 but we could merge this short term Jun 28 08:45:09 I'm asking because we're using SSTATE_MIRROR mounted over NFS and every now and then it shows many ERRORs just because of IOError: [Errno 116] Stale NFS file handle Jun 28 08:45:14 i.e. we'd end up using it for the next 5 years :/ Jun 28 08:46:19 and then after successful build it shows Summary: There were 73 ERROR messages shown, returning a non-zero exit code. Jun 28 08:46:28 which is bad for jenkins Jun 28 08:46:38 JaMa: I can understand that, yes :/ Jun 28 08:50:51 RP: I have hanging bitbake just now, anything new I should try? Jun 28 08:52:28 JaMa: do we have a pstree of the hang somewhere? Jun 28 08:52:39 JaMa: Just to give a clue about which processes are there Jun 28 08:53:09 JaMa: I am struggling for ideas with it unfortunately :( Jun 28 08:53:52 RP: rburton: thanks for your help yesterday. i was able to implement my chroot stuff , quite easily, and nicely ;-) Jun 28 08:54:08 ndec: glad you got it sorted! :) Jun 28 08:54:29 do you think we could have a 'chrootadd.bbclass', to some extent similar to useradd.bbclass ? Jun 28 08:54:34 does that make any sense? Jun 28 08:54:43 RP: ah it's with dylan build, so nothing new http://pastebin.com/drQd3h8b Jun 28 08:54:58 RP: sorry for noise I'll shout again when I have it again with master Jun 28 08:55:31 JaMa: ok Jun 28 08:56:48 ndec: feel free to mail the list with your work and thoughts about how to generalise it Jun 28 08:57:34 ndec: Its certainly worth a discussion as rburton says Jun 28 08:57:44 rburton: ok. i have made it a class for now, and hack'd into my image, but i will do it and send. Jun 28 08:58:05 btw: I'm working on improving buildhistory to record real installed-package size on target (instead of .ipk/.rpm/.deb size) Jun 28 08:58:33 i think it's not limited to chroot, it can be used for any 'containers', like LXC or maybe even VM. Jun 28 08:59:06 I'll probably send RFC to ML, because I'm not very familiar with rpm/smart and don't know if there is some nice way to count size of installed files Jun 28 08:59:45 with opkg I need to do for i in `opkg files foo`; and count only files (because it shows also directories like /usr) Jun 28 09:04:00 JaMa: couldn't we do that during do_package on the packages-split directory? Jun 28 09:09:17 RP: that's very good idea Jun 28 09:09:33 thanks Jun 28 09:12:52 morning all Jun 28 09:13:45 JaMa: I haven't checked but you may find we gather this info already and store it in pkgdata Jun 28 09:14:49 JaMa: in fact, aren't we already collecting size per-package for the files themselves in the package part of buildhistory? Jun 28 09:24:38 bluelightning: ah of course you're right Jun 28 09:25:03 bluelightning: I blame NOCOFFEE this week Jun 28 09:25:17 JaMa: well that's foolish of you Jun 28 09:25:34 JaMa: it's OK, I have had one of those weeks this week myself :) Jun 28 09:25:47 NOCOFFEE? my doctor disagrees :/ Jun 28 09:27:18 bluelightning: would you take patch gathering that info in one image file like installed-package-sizes-real.txt sorted from biggest like .ipk sizes are? Jun 28 09:31:51 JaMa: hmm... I wonder if the rpm/ipk/deb package sizes themselves are actually useful to anyone - should we just change the existing installed-package-sizes.txt file to report the real installed size? Jun 28 09:32:31 that would work for me to Jun 28 09:36:44 I think when the original implementation of that was done (in testlab?) we didn't have the per-package sizes, so looking at the package size was easiest Jun 28 09:52:43 Hey, which is the proper directory to install into in a bb recipe, ${D}? Jun 28 09:52:57 yes Jun 28 09:56:44 JaMa: turns out there isn't a --enable-gallium option Jun 28 09:56:54 so your gallium line doesn't actually do what you want Jun 28 09:57:31 also, enabling gallium but not gallium-llvm means gallium gets turned off Jun 28 09:57:40 and i didn't want to do the llvm bits as i don't have that to hand Jun 28 10:08:46 rburton: ah sorry about that, I was runtime testing only both together, but I'm pretty sure I've checked log.do_configure for unrecognized options, I'll recheck Jun 28 10:10:27 maybe we should warn when configure reports unrecognised options... Jun 28 10:14:11 agreed, more visibility would be nice, only concern is shared .inc with options which aren't available in all versions Jun 28 10:14:24 e.g. when some layer is reusing .inc with a lot older or newer recipe Jun 28 10:15:19 JaMa: actually with the layer-model the .inc can be troublesome Jun 28 10:15:48 $ grep "WARNING: unrecognized options" */*/temp/log.do_configure| wc -l Jun 28 10:15:50 502 Jun 28 10:15:53 yeah maybe not :) Jun 28 10:16:07 on the other hand you can include the .inc in your .bbappend and overide the necessary vars Jun 28 10:16:14 +r Jun 28 10:16:29 we always pass --with-libtool-sysroot and --disable-silent-rules Jun 28 10:16:43 i guess we could filter those out of the list Jun 28 10:16:43 heh Jun 28 10:16:57 oh, yes, klcc dislikes that as well :) Jun 28 10:19:25 ok, might not be practical... just a thought Jun 28 10:20:49 RP: updated pstree https://bugzilla.yoctoproject.org/show_bug.cgi?id=4338 still hanging Jun 28 10:20:50 Bug 4338: normal, Medium, 1.5, richard.purdie, NEW , bitbake hangs forever before showing any output Jun 28 11:01:14 JaMa: i don't suppose you can mail me a breaking compile log of mesa without x11 in that winsys_xlib place? I can't replicate the failure (although its obviously unguarded) Jun 28 11:03:06 rburton: will do a bit later Jun 28 11:03:38 rburton: I'll also include log.do_configure so that you will see what exactly is enabled Jun 28 11:04:03 but first I need to finish webkit build to get some more cpu power :) Jun 28 11:05:25 JaMa: sure, i'm going to eat now anyway Jun 28 11:47:52 was sed applet removed from busybox or something like that? upgrade path seems to be broken Jun 28 11:47:56 Configuring busybox-syslog. Jun 28 11:47:58 /usr/bin/update-alternatives: line 186: sed: not found Jun 28 11:48:17 and then all applets in main busybox package fail to set u-a because of missing sed.. Jun 28 11:48:46 and then fixing that is more complicated because wget symlink is gone too, so opkg update opkg upgrade wont work Jun 28 11:48:59 JaMa: IIRC the specific postinst was removed from busybox?! Jun 28 11:50:14 /var/lib/opkg/info/busybox.postinst is still there Jun 28 11:50:21 with a lot of u-a calls Jun 28 11:50:53 JaMa: generated by the bbclass and not the one that was in the busybox.inc (but i only read the digest and skip stuff) Jun 28 11:50:57 that commit says it removes redundant u-a Jun 28 11:51:30 SHR root@gjama ~ $ grep sed /var/lib/opkg/info/busybox.postinst update-alternatives --install /bin/sed sed /bin/busybox.nosuid 50 Jun 28 11:51:42 JaMa: Do you know if they/he tested on device upgrade? Jun 28 11:52:15 i am obviously just guessing Jun 28 11:53:24 all u-a are still pointing to /bin/busybox, but that one is gone replaced by /bin/busybox.(no)suid Jun 28 11:54:04 we should install /bin/busybox -> /bin/busybox.nosuid to fix upgrade path.. Jun 28 11:56:05 obviously bad time to test it myself on 5 devices.. Jun 28 11:56:44 now I cannot reboot them until this is resolved (manually) Jun 28 11:57:35 ln -s /bin/busybox.nosuid /bin/busybox Jun 28 12:03:27 rburton: mesa logs sent Jun 28 12:06:33 is there a way to override a .bbclass from another layer, or recipes only? Jun 28 12:11:21 no, not for classes and .inc. Redeclare the same variables after inheriting it or create your own class Jun 28 12:11:57 hbragge: .bbclasses are searched in directories listed in BBPATH Jun 28 12:12:35 hbragge: so if you put new .bbclass before the old one, your .bbclass will be used, but you have to overwrite it all (not just append part like .bbappends do) Jun 28 12:18:57 JaMa: interesting, will try that too Jun 28 12:19:51 need to replace most of the class anyway, but wouldn't like to use a different name Jun 28 12:27:45 hbragge: if it's something that might be useful to others you might consider how the changes could possibly fit into the original class Jun 28 12:28:17 not always practical or appropriate, but worth considering at least Jun 28 12:34:55 bluelightning: true, i will consider sending a patch, but first i need to hack myself through this Jun 28 12:35:26 sure :) Jun 28 12:39:11 I've tried discouraging you fiddling with layers and bbpath, remember it ;) Jun 28 12:42:51 ant_work: actually trying your approach now, seems to do the trick as well Jun 28 12:44:07 not sure if I even needed to do this, but haven't found another way to disable appending "console=tty0" kernel parameter from syslinux.bbclass Jun 28 12:57:34 hbragge: that code may well be naive and in need of reworking Jun 28 13:02:03 bluelightning, I think many of the "differences" Scot fins are accidental :) Jun 28 13:06:45 Crofton|work: when I put up the layer index I did go through and add all the ones I thought made sense Jun 28 13:06:56 heh Jun 28 13:07:32 it sounds like he is going through things very carefully Jun 28 13:07:51 we just need to be careful not to document things that just need fixing :) Jun 28 15:19:33 zeddii: any kern-tools update pending? Jun 28 15:22:46 ant_work, yep. I have several queued. I'm scrambling for a week off, but planned to finish them while removed from 'work' email :P Jun 28 15:23:20 ok, I've seen last one of yesterday Jun 28 15:23:56 I'll play a bit with the .scc without declaring it in SRC_URI Jun 28 15:24:09 the .scc's even Jun 28 15:24:56 I'll tell you in case something's fishy Jun 28 15:25:01 btw Jun 28 15:25:14 hello Jun 28 15:25:18 * Ahmed is now known as Guest69357 Jun 28 15:25:33 I did resist mocking him this time Jun 28 15:25:46 I've got some changes related to that. an easier way to declare "recipe space" search paths for .scc files, that blend in with in-tree and external "krnel-caches". It's a 1.5 feature, should simply your management. Jun 28 15:27:39 so the rule still is "Only .scc files that don't Jun 28 15:27:39 define KMACHINE's are automatically used" Jun 28 15:36:21 Hi! , I have image of hypervisor in my tmp/deploy/images folder but I am having hard time running it on qemu. The command line option I am using is - runqemu qemux86 I have also tried runqemu p4080ds. I watched the tutorial video from yoctoproject.org site and it says that we can change the machine name in local.conf file and use that machine name with runqemu to see it on qemu. I see two MACHINE variables inside local.conf. MACHINE ?= 'q Jun 28 15:37:40 zeddii: would you suggest to make patch+logo a feature? Jun 28 15:47:33 kissmanga Jun 28 15:59:03 can someone try "bitbake -c cleansstate bzip2-native" and confirm that it's also showing: Jun 28 15:59:46 NOTE: Tasks Summary: Attempted 0 tasks of which 0 didn't need to be rerun and all succeeded. Jun 28 16:00:00 and tmp-eglibc/stamps/x86_64-linux/bzip2-native/ are still there? Jun 28 16:06:10 is bzip2-native in your assume_provided? Jun 28 16:07:33 fray: you're right it's in default ASSUME_PROVIDED from bitbake.conf, but then I don't understand why image build is failing in bzip2-native.do_install Jun 28 16:08:14 I've removed stamps manually and now image build is still building bzip2-native Jun 28 16:09:35 it's probably required by linux-yocto_3.8.bb, do_package, because that was started just after bzip2-native.do_populate-sysroot finished Jun 28 16:11:59 I don't know.. assume_provided should be able to do allow that other thing to continue (and avoid a build) Jun 28 16:12:18 do_populate_sdk[depends] += "dpkg-native:do_populate_sysroot apt-native:do_populate_sysroot bzip2-native:do_populate_sysroot" Jun 28 16:12:49 maybe ASSUME_PROVIDED doesn't cover task dependencies like this? Jun 28 16:12:49 remove it from your assume_provided then.. thats the best I can suggest.. Jun 28 16:12:55 it may not, I thought it did Jun 28 16:13:07 nerdboy: Have you tried building qtwebkit? Jun 28 16:13:23 sounds like somewhere someone introduced a bug and didn't try the SDK... Jun 28 16:13:30 testing with -g Jun 28 16:16:24 I'll try to revert bzip2 ptest support just in case it;s somehow caused by: "bzip2-native.do_compile_ptest_base" -> "bzip2-native.do_compile" Jun 28 16:18:14 that would not surprise me.. Jun 28 16:18:27 I know I ran into some unexpected issues with ptest stuff in the past, but I thought it was all corrected Jun 28 16:18:35 (past = greater then 3 weeks ago) Jun 28 16:21:55 fray: somehow it's caused by python recipe :) Jun 28 16:23:45 python-native_2.7.3.bb:DEPENDS = "openssl-native bzip2-replacement-native Jun 28 16:29:17 mr_science: Hi! How are you? Could you please help me with my question today as well? Jun 28 16:29:49 which was? Jun 28 16:34:45 mr_science: I have image of hypervisor in my tmp/deploy/images folder but I am having hard time running it on qemu. The command line option I am using is - runqemu qemux86 I have also tried runqemu p4080ds. I watched the tutorial video from yoctoproject.org site and it says that we can change the machine name in local.conf file and use that machine name with runqemu to see it on qemu. I see two MACHINE variables inside local.conf. MACHINE Jun 28 16:35:40 second MACHINE variable is set to 'p4080ds' and i tried both names with runqemu but doesn't work Jun 28 16:36:41 well, you can only have one MACHINE defined for a given build Jun 28 16:37:38 ok I will try to remove one and run runqemu to see if it works like that Jun 28 16:38:00 so i would rm -rf your tmp and cache dirs, set the MACHINE to what you want, rebuild your target image, then try qemu again Jun 28 16:39:51 allright let me try all this then. Thanks a lot! Jun 28 16:41:23 if you have the right layers configured then the key is pretty much the machine/image recipe Jun 28 16:41:31 mr_science: Are you talking about ccache dir which is under meta/recipes-devtools? Jun 28 16:41:54 as far as I know qemu does not support the p40xx series processors.. Jun 28 16:41:55 the cache dirs under buid-foo/ Jun 28 16:41:58 you need actual hardware to test them Jun 28 16:42:28 if you change your machine to qemuppc or something, that will work.. but won'tbe the same configuration as the p4080 Jun 28 16:42:44 then you'd need a machine that's supported by qemu Jun 28 16:42:51 fray: ok thanks! Jun 28 16:44:24 so can I have anything for my machine name? I mean I am using P4080DS BSO so can I put qemux86 for machine name? Jun 28 16:44:33 BSP* Jun 28 16:46:15 p4080ds is an e500v2 if I remember right.. Jun 28 16:46:21 qemux86 is well, an x86 processor Jun 28 16:46:27 qemuppc is a PPC 603e processor Jun 28 16:46:43 if you want to verify your configuration, apps, software in an emulator, you need to find one that is compatible with your board.. Jun 28 16:46:51 if you just want to "build something", then picking any qemu machine is fine Jun 28 16:46:58 fray: Got you! thanks a lot! Jun 28 16:47:06 mr_science: Thank you very much! Jun 28 16:48:44 np... Jun 28 16:49:36 khem, ping. Jun 28 16:49:47 zeddii: yes Jun 28 16:49:55 just emailed you. Jun 28 16:50:02 ok Jun 28 16:50:40 I didn't get a qemumips64 system binary in my fresh build by default. I thought we merged that ? I'm hunting to see if I've got a commit lurking around that turned it off. Jun 28 16:51:41 I've enabled it locally and am building it now, but wanted to check with you. Jun 28 16:53:20 zeddii: and I replied Jun 28 16:53:43 its at poky's interest if it should be supported. I can send a patch Jun 28 16:53:51 I have actually emailed the patch to you Jun 28 16:54:03 great. thx! Jun 28 16:54:06 in OE-Core its enabled by default but poky's policies override Jun 28 16:54:15 when you use poky Jun 28 16:54:19 ah gotcha. Jun 28 16:54:31 yah. I'm on my poky tree. limited space on my laptop I'm taking with me next week. Jun 28 16:54:39 ok Jun 28 16:54:53 are you on beach somewhere over 3G connection ? Jun 28 16:55:07 sheesh these geeks Jun 28 16:55:13 both. driving to the coast. Jun 28 16:55:22 I have a blackout of 4 days, but after that, I'm peeking back in. Jun 28 16:55:24 cool Jun 28 16:55:29 i.e. no laptop when I go to the beach! :P Jun 28 16:55:31 :) Jun 28 16:55:32 enjoy Jun 28 16:56:52 damn. systemd just booted for me. I may need an oe-core only build Jun 28 16:57:09 zeddii: OK thats a data point Jun 28 16:57:16 now switch to using GCC 4.8 Jun 28 16:57:22 aha. good point. Jun 28 16:57:27 * zeddii rebuilds Jun 28 16:57:39 Just build the kernel with gcc 4.8 Jun 28 16:57:44 and see if that boots Jun 28 16:57:58 is there a trick to doing that quickly ? i.e. not triggering a full rebuild ? Jun 28 16:58:05 I have a hunch its gcc-4.8/mips-64 kernel Jun 28 16:58:07 issue Jun 28 16:58:21 hmmm heh Jun 28 16:58:24 we can hunt Ralf if something is lurking, and try the -dev kernel. Jun 28 16:58:29 right Jun 28 16:58:30 I can build it by hand I guess :P Jun 28 16:58:41 and I heard Ralf works for you guys now ? Jun 28 16:59:23 or may be in past Jun 28 16:59:35 yes build it by hand Jun 28 16:59:48 just bitbake gcc-cross after swiching Jun 28 17:00:02 and then use the gcc from the staging to build kernel by hand Jun 28 17:00:14 and then copy it to deploy dir to make runqemu scripts happy Jun 28 17:00:19 I cheat like that Jun 28 17:00:39 when you have slow machines there is no way Jun 28 17:02:42 holy crap how did i survive without git cherry-pick ..[branch] Jun 28 17:04:37 that cherry-pick all of the enw stuff on your branch, on top of your working rbanch? Jun 28 17:12:12 fray: yes Jun 28 17:12:24 before i was doing stupid things to get the list of SHAs Jun 28 17:16:56 ahh didn't know that.. I usually do git log ... reverse the list and apply them Jun 28 17:26:09 rburton: about that mesa x11 header issue.. I had also problem to reproduce it with oe-core only, but then I realized that I have x11 in default distro-less DISTRO_FEATURES so libx11 was always built before mesa Jun 28 17:26:50 rburton: as quick hack to reproduce "bitbake -c clean libx11 && bitbake -b mesa_git.bb" shows that imediatelly Jun 28 17:49:56 khem, I baked gcc-cross for gcc 4.8, but I'm not entirely sure it did what I expected. I only see a gcc-cross in tmp/work, but it doesn't hold what I expect. Jun 28 17:53:43 zeddii: see whats in tmp/sysroot/x86_64-linux/usr/bin/mips64* Jun 28 17:56:25 hmm. interesting. I missed it when I looked before: mips64-poky-linux-gcc-4.8.1 Jun 28 17:56:30 I'll fire that up and build the kernel. Jun 28 17:56:54 yes Jun 28 17:56:59 thats the one you want Jun 28 18:06:11 fray: seems your sanity patch is giving us serious grief on the AB Jun 28 18:07:33 my guess is that many of the AB machines are broken Jun 28 18:07:41 pidge: it looks like we need to get the buildtools-tarball installed on the ABs Jun 28 18:07:43 we found the same thing here.. something like 10 of 15 were broken Jun 28 18:07:50 sgw_, that is exactly what we had to do Jun 28 18:08:12 pretty much all recent Fedora derived distros, many Debian and some SuSe were broken Jun 28 18:08:29 which is what's running Jun 28 18:08:50 Fedora 18/19 should have software updates that will resolve the failure Jun 28 18:09:21 halstead or pidge: Can we work to get the updated buildtools installed Jun 28 18:10:46 sgw_, Only on the ABs with python < 2.7 or on all of them? Jun 28 18:12:11 halstead: right, but now we have issues with the version of make, based on a new sanity test. Jun 28 18:24:30 At WR, our builder scripts use the same check as what is in sanity (tar, git, make and python) if any of them fail, it just installs the buildtools... Jun 28 18:24:35 otherwise it continues as normal Jun 28 18:24:42 you might want to do something like that Jun 28 18:25:49 BTW the error message on sanity failure really needs to be updated to tell people they need to either update their host -or- get the buildtools standalone Jun 28 18:29:46 fray: patches welcome! Jun 28 18:29:46 khem, http://pastebin.com/KYJ9TWDz Jun 28 18:30:01 my gcc 4.8.1 booted with systemd, just the kernel build with 4.8.x of course. Jun 28 18:30:22 next question. what's the top commit of your kernel branch you built ? Jun 28 19:03:58 fatal: unable to access 'https://github.com/MentorEmbedded/linux-meibp.git/': Protocol https not supported or disabled in libcurl Jun 28 19:04:02 hmm Jun 28 19:04:11 we don't use libcurl to fetch, last i checked.. Jun 28 19:04:14 * kergoth scratches head Jun 28 20:08:15 fray: is bug 3086 still and issue with smart? I tried searching my log files for pythoneggs and did not come up with any. Jun 28 20:08:16 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=3086 minor, Low, Future, bogdan.a.marinescu, NEW , The do_package process may generate warnings about a missing pythoneggs.py file Jun 28 20:08:24 yocti thanks! Jun 28 20:08:25 sgw_: Error: "thanks!" is not a valid command. Jun 28 20:08:31 it's not a problem with smart.. Jun 28 20:08:45 it's an issue where the rpmdeps can attempt to use pythoneggs in some way cuasing the failure Jun 28 20:08:46 fray so can it be closed? Jun 28 20:09:29 it's stilla problem last time I looked Jun 28 20:09:45 look at the logs for a build of various python applications.. you will probably see that error inthe log files, but it's not fatal Jun 28 20:10:10 this doesn't have anything to do with image generation Jun 28 20:10:17 fray, can you add some information on reproducing it? I just searched a world build and did not find any messages Jun 28 20:13:47 macros.d/python:%__python_provides %{_rpmhome}/pythoneggs.py --provides Jun 28 20:13:48 macros.d/python:%__python_requires %{_rpmhome}/pythoneggs.py --requires Jun 28 20:14:09 # Path to scripts to autogenerate python package dependencies, Jun 28 20:14:09 # Jun 28 20:14:09 # Note: Used if _use_internal_dependency_generator is non-zero. The Jun 28 20:14:16 that happens when rpmdeps is executed Jun 28 20:17:29 do you RPMDEPS on or off in your builds? Jun 28 20:18:05 what's the default? Jun 28 20:18:11 I'm looking Jun 28 20:18:24 at one point RP was going to disable it.. but I don't know if he did Jun 28 20:18:36 I see RPMDEPS set in package.bbclass and used there Jun 28 20:19:04 ya.. the functiona ppears to be enabled by default Jun 28 20:19:19 the error is still possible, the function is still enabled... Jun 28 20:19:36 it doesn't seem to be logging the erorr though, which makes me suspicious stderr is being sent to /dev/null Jun 28 20:21:36 import multiprocessing Jun 28 20:21:37 nproc = multiprocessing.cpu_count() Jun 28 20:21:37 pool = bb.utils.multiprocessingpool(nproc) Jun 28 20:21:37 processed = pool.imap(oe.package.filedeprunner, pkglist) Jun 28 20:21:37 pool.close() Jun 28 20:21:37 pool.join() Jun 28 20:21:43 somthign in there is likely dumping stderr Jun 28 20:22:53 I'm not understanding the code though, somewhere in there it has to execute the rpmdeps command.. Jun 28 20:22:54 can I assign this back to you? The Engineer working on has left Jun 28 20:22:56 I see just above that Jun 28 20:23:03 thats fine Jun 28 20:23:06 or to Robert? Jun 28 20:23:08 it's low priority Jun 28 20:23:29 and as the comment says, we need to figure out if python deps is something we DO want to generate.. (answer for 1.5, no) Jun 28 20:23:49 Ok Jun 28 20:24:00 just trying to do some bug cleanup Jun 28 20:24:24 yup.. no problem.. Jun 28 20:24:36 RP, http://free-electrons.com/blog/buildroot-2013-05/ Jun 28 20:49:56 fray, sgw_: The oe.package.filedeprunner() call is the actual execution Jun 28 20:50:16 http://free-electrons.com/blog/free-electrons-at-lsm2012/ Jun 28 20:50:16 Crofton|work: shame we can't work together :/ Jun 28 20:50:22 pastebining links across :) Jun 28 20:50:29 what, you and me? Jun 28 20:50:32 :) Jun 28 20:50:50 Crofton|work: OE and the buildroot people... Jun 28 20:50:58 heh Jun 28 20:51:05 http://free-electrons.com/blog/experiment-with-yocto/ Jun 28 20:52:26 this is what I was looking for: http://free-electrons.com/blog/bdd-2012-brussels/ Jun 28 20:53:01 RP -- I'm looking at lib/oe/package.py filedeprunner Jun 28 20:53:06 but I don't see an exec Jun 28 20:53:25 never mind.. Jun 28 20:53:27 I'm blind Jun 28 20:53:32 os.popen :P Jun 28 20:53:42 I suspect hat is where the stderror is getitng lost Jun 28 20:54:10 fray: the popen is an exec Jun 28 20:54:30 it was on the page break on my screen.. and when I scrolled I missed it.. :P Jun 28 21:37:20 fray: ping Jun 28 21:37:36 so, we're trying to fix the ab situation... Jun 28 21:37:37 hey Jun 28 21:38:01 buildtools-tarball requires nativesdk-make which is 3.82 Jun 28 21:38:28 check_sanity does NOT like that Jun 28 21:38:32 it wants 3.81 Jun 28 21:38:48 so.... advice here? Jun 28 21:39:29 no Jun 28 21:39:39 heh, trying to build buildtools-tarball on a machine that needs buildtools-tsarball? ;) Jun 28 21:39:40 check_sanity checks for 3.82, and if so checks to see if the bugs in it are fixed Jun 28 21:40:03 pidge: I think ab04 is a good machine, try building the tarball there Jun 28 21:40:03 so exactly, you need to bootstrap the buildtools-tarball.. once you do.. just reuse it to build new versions Jun 28 21:40:21 kergoth: I didn't build it. halstead can give details on that... Jun 28 21:40:40 buildtools-tarball from a few days ago didn't have make as part of it.. Jun 28 21:41:56 fray: does now: more meta/recipes-core/meta/buildtools-tarball.bb |grep make Jun 28 21:41:58 also the version of make that was in oe a week or so ago was broken.. a patch went in to fix that Jun 28 21:42:44 sgw_ ok, let me sync with halstead and I'll get to the bottom of this Jun 28 21:42:48 file://make-savannah-bug30612-fix_white_space.patch Jun 28 21:42:51 shakes fist at broken makes Jun 28 21:42:57 thats the fix in meta/recipes-devtools/make Jun 28 21:43:17 sgw_, I built it on ab01 which is the same as ab04. Neither one of them has a new enough python to build the buildtools now. Jun 28 21:43:43 ab01 should have worked Jun 28 21:44:16 halstead: can you build with the older tarball that has python in it? since the make is good? Jun 28 21:44:34 sgw_, pidge, I had to use the environment-setup to build on ab01. Jun 28 21:45:13 dylan should work sgw_, correct? Jun 28 21:45:55 sgw_, Yes I can. But what are we changing in the rebuild? Jun 28 21:46:54 halstead: sorry I mean "you can build with the older tarball", the newer one will have the fixed version of nativesdk-make Jun 28 21:50:13 So pidge all of the builders have the patches make 3.82 now. Jun 28 21:50:24 s/patches/patched/ Jun 28 21:52:20 verify it with the reproducer Jun 28 21:52:26 it's -very- simple Jun 28 21:53:15 halstead: ok, take two Jun 28 21:53:20 test.a: test_a.c test_b.c test.a( test_a.c test_b.c) Jun 28 21:53:22 Jun 28 21:53:27 test_a.c: Jun 28 21:53:31 touch $@ Jun 28 21:53:33 Jun 28 21:53:35 test_b.c: Jun 28 21:53:38 touch $@ Jun 28 21:54:18 (the patch that is usually missing is the one that allows the space after the ( Jun 28 21:57:47 pidge, http://autobuilder.yoctoproject.org:8011/builders/nightly-arm-lsb/builds/187/steps/Building%20Images/logs/stdio is a separate issue we may want to look at. Jun 28 21:59:04 halstead: hrm. ok, let's run master and see what we get first. Jun 28 21:59:38 now that everything should be set up ok. Jun 28 22:05:36 pidge: is everything restarted or do you need a AB HUP? seems like only some are running Jun 28 22:18:47 sgw: give me a moment. looking now Jun 28 22:19:03 ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded: ignored. Jun 28 22:19:10 that's a weird one... Jun 28 22:19:16 fray ^^^ Jun 28 22:21:21 sgw: things are still belly up but it's not due to make now... Jun 28 22:21:23 looking Jun 28 22:27:14 that says you most likely are running 32-bit on a 64-bit machine Jun 28 22:27:26 ...and you have no32lib = 1 Jun 28 22:34:44 ty fray. sgw, fray, halstead. I need to grab lunch. I'm going to look at this when I get back. no one touch the ab, please, or if you do, let me know what you did. I don't like seeing things this broken. Jun 28 23:25:04 khem: I get "/usr/lib/libstdc++.so: could not read symbols: File in wrong format" building gcc package for Atom target on x86_64 host. it is trying to link to the host /usr/lib/libstdc++.so when building libasan Jun 29 01:06:14 Net147: such issues are sometimes libtool related mostly Jun 29 01:06:29 check whats in .la files in the pacakge Jun 29 01:53:56 is there a policy on what to do with .la files? Jun 29 02:17:58 nerdboy: I'ld like to know, too. (about. .la files) Jun 29 02:46:53 raise your hand if your wife hoards too much crap... **** ENDING LOGGING AT Sat Jun 29 02:59:58 2013