**** BEGIN LOGGING AT Tue Sep 20 02:59:57 2011 Sep 20 08:45:32 I am trying to force a re-build of u-boot using bitbake -c clean u-boot, bitbake u-boot, bitbake core-image-minimal - but the u-boot image refuses to be updated as if the package is still lying about in cache somewhere and is not being re-built, any ideas? Sep 20 08:46:02 -c cleansstate Sep 20 08:46:41 bitbake -c cleanstate? Sep 20 08:47:17 double 's' Sep 20 08:47:21 shared state Sep 20 08:49:08 that seems to be working JaMa, thanks - possibly a candidate for addition to the README - DO NOT DELETE FILES in tmp/deploy/images Sep 20 08:52:07 Snafflehog: or -c cleanall Sep 20 08:52:22 ant_work: that will remove also files from downloads dir Sep 20 08:52:37 ant_work: which is not very usefull if he wants to build it again after that Sep 20 08:52:58 I test my patch after a -cleanall Sep 20 08:53:03 yes, I was just re-building with a new patch applied Sep 20 08:53:26 ant_work: that's your problem that you want to redownload same sources again :) Sep 20 08:53:31 heh Sep 20 08:53:49 ant_work: but whole reason why I've added cleansstate is to keep downloaded sources when you want to rebuild something Sep 20 08:54:18 ie redownloading kernel sources just to check that new patch applies cleanly is not fun :) Sep 20 08:55:24 about sources, we'd need a script like 'eclean distfiles' Sep 20 08:56:20 yes Sep 20 08:56:59 I'm cleaning it by rebuild from scratch with my old downloads dir as premirror Sep 20 08:57:18 heh, I have Gentoo sources too there ;) Sep 20 08:57:25 but that's not optimal Sep 20 08:57:29 in same dir? Sep 20 08:57:40 no , as mirror Sep 20 08:57:48 ah :/ I had it like this too but separated them later Sep 20 08:57:49 another disk Sep 20 08:58:07 ah.. I had downloads dir pointing to distfiles dir Sep 20 08:58:31 but then eclean-dist was removing sources still in use by OE.. so I've separated them Sep 20 08:58:49 yes, needs a bit of study Sep 20 08:59:06 maybe I should write some oneliner to compare both dirs and replace duplicities with links Sep 20 08:59:20 would be nice Sep 20 08:59:36 let me know how you improve it ;) Sep 20 08:59:55 I'll first check how much space it can save Sep 20 09:00:15 morning all Sep 20 09:07:04 morning Sep 20 09:13:41 ant_work: only 232M is shared between gentoo's distfiles and my OE downloads dir Sep 20 09:13:52 ant_work: ah no big difference http://paste.pocoo.org/show/479031/ Sep 20 09:14:06 ah yes, the git stuff Sep 20 09:19:45 http://paste.pocoo.org/show/479035/ Sep 20 09:25:19 I'm amazed by your 13G distfiles/ Sep 20 09:26:19 I'm trying to keep it clean :) Sep 20 09:26:33 for reference the Gentoo server (LAMP) I have here is 1.4G /usr/portage/distfiles/ Sep 20 09:27:16 desktop profile + Gnome is bigger but not that much. I'll check later Sep 20 09:27:56 ie 4,7G distfiles/svn-src is mostly just chromium + 0ad Sep 20 09:28:22 but we're quite OT here.. Sep 20 09:28:29 ups... Sep 20 09:38:56 in what file do you set your preffered version of software, for example I want to build the 3.0 kernel instead of the 2.6.37 Sep 20 09:40:07 that's distro policy, so some distro config or local.conf if you want just to test something Sep 20 09:43:15 so could I put in distro/setup.conf PREFFERED_VERSION_linux-yocto ?= "3.0" Sep 20 09:43:58 and would that go in the build directory conf or a layers conf? Sep 20 12:10:31 On the yocto kernel config for beagleboard pin muxing by the kernel is enabled by default, isn't this bad practise and pin muxing should be done by u-boot? If I try to disable pin_muxing (CONFIG_OMAP_MUX=n in cfg fragment) then the kernel errors and refuses to build Sep 20 12:52:03 Ok, I fixed it - there were other options enabled which relied on pin_muxing being enabled. disabling this allowed me to build the kernel with pin_muxing disabled Sep 20 18:20:23 can someone explain what the 'closed' LICENSE is? Sep 20 18:22:22 fray: ping Sep 20 18:23:26 here Sep 20 18:23:52 kergoth: functionality wise, it tells the LIC_FILES_CHKSUM verification code not to do anything Sep 20 18:24:06 that much I know, I meant conceptually ,its purpose and intent Sep 20 18:24:39 kergoth: however, it's specifically for use by recipes for closed-source software such as firmware blobs that are not accompanied by any common license Sep 20 18:24:45 fray: did you see the install_multilib_solution.manifest if using the two step installation? Sep 20 18:25:01 I havn't gotten to trying it yet Sep 20 18:25:06 kergoth: at least that's my understanding Sep 20 18:25:22 I'm still trying to get the overall dependencies on simply builds/installs working properly.. Sep 20 18:25:32 fray: ping Sep 20 18:25:40 when I fixed the package_rpm typo, lots of little runtime dependency errors cropped in Sep 20 18:25:57 Hmm Sep 20 18:26:11 jzhang pong... Sep 20 18:26:13 fray: so you mean except those fixed in your branch, there is still other errors? Sep 20 18:26:24 yes.. so far all package errors.. Sep 20 18:26:42 I'm digging through them still, trying to decide if they are "real" errors.. or something else is wrong (i.e. class problems) Sep 20 18:27:00 once I get this done, I'll try the multilib split resolution... Sep 20 18:27:19 fray: ok, thanks :) Sep 20 18:27:22 fray: for bug 1489, the tcf-agent segfault which is triggered by remote debug, you mentioned it's fixed for ARM, or are you mixed it up with some other issue? Sep 20 18:27:38 someone emailed me and said the tcf-agent wasn't working right on ARM.. Sep 20 18:27:46 I had them retry after the prelink change and it fixed it for them.. Sep 20 18:28:08 1489 is specific to IA32.. so my question is, did someone re-try it after prelinker update went in a week or so ago? Sep 20 18:28:34 fray: then I think it's a different issue since my image built out is with the prelink issue fixed Sep 20 18:28:57 kergoth: I've been thinking about adding the ability to avoid the LIC_FILES_CHKSUM check for those recipes (such as tasks) that install no files Sep 20 18:30:43 it seems -D arguments are not passed to the build of pseudo-native Sep 20 18:31:01 jzhang yup, sounds different then Sep 20 18:43:07 is there a way to see the overall progress of hob? it's showing all the tasks without a percent complete Sep 20 18:44:33 msm: no for this release, I think there's a bugzilla enhancement track this requirement, if not, please file one Sep 20 19:00:10 jzhang: ok Sep 20 19:02:37 sgw -- good news.. core-image-core and core-image-core with my wacky multilib installs dependencies worked Sep 20 19:02:54 now on to core-image-sato.. if this works.. then we should be good with some cleaned up patches.. Sep 20 19:06:09 fray: great news Sep 20 19:06:29 ever get a chance to kick off an autobuilder run (w/o the sstate-cache)? Sep 20 19:42:50 whats the proper way to clean an image so everything is rebuild correctly? Sep 20 19:43:04 im just been rm'ing the files right before a run the image creation Sep 20 19:43:17 but it's says to not delete files in that folder Sep 20 19:44:01 msm, it also say to use -c cleansstate Sep 20 19:44:01 like for instance: Sep 20 19:44:01 bitbake -c cleansstate foo-image Sep 20 19:44:39 GNUtoo: but I need to do that for the uImage and DTB separately as well? Sep 20 19:44:57 DTB? Sep 20 19:45:00 database? Sep 20 19:45:01 device tree Sep 20 19:45:08 device tree binary to be exact Sep 20 19:45:14 ah ok (usually people uses DT) Sep 20 19:45:28 ah ok Sep 20 19:45:29 msm: what do you mean by clean an image? an image is always constructed from scratch. Sep 20 19:45:35 I don't know for device tree Sep 20 19:45:38 if you mean the recipes it depends on, that's something else Sep 20 19:45:51 maybe it cleans the tasks Sep 20 19:46:13 kergoth, there is some file in deploy dir telling to -c cleansstate instead of rm-ing the images Sep 20 19:46:27 ? Sep 20 19:46:30 so maybe because of sstate they may not be rebuilt from scratch Sep 20 19:46:55 completely depends on what you're trying to achieve Sep 20 19:47:15 ah ok sorry bad memory Sep 20 19:47:27 Files in the deploy directory will not be re-created automatically if you delete them. If you do delete a file, you will need to run: Sep 20 19:47:46 bitbake -c clean TARGET;bitbake TARGET Sep 20 19:47:54 I remembered the countrary Sep 20 19:47:55 sorry Sep 20 19:48:34 clean and run will result in the deploy files coming back, yes. no need to cleansstate unless you want to rebuild it from source as well Sep 20 19:53:08 bitbake -c clean core-image-minimal does not seem to work Sep 20 19:53:59 that will do nothing Sep 20 19:54:03 again, images are always built from scratch Sep 20 19:54:10 if you want toc lean the image and everything the image depends on, try cleanall Sep 20 19:54:44 i just want to clean the tmp/deploy/images folder Sep 20 19:54:59 and it explicitly says to not delete files in this folder Sep 20 19:55:01 the image recipe only emits the filesystem image Sep 20 19:55:09 everything else comes from other recipes (e.g. uboot, kernel) Sep 20 19:55:22 specifically, the do_deploy task of those other recipes Sep 20 19:55:52 fair enough, it sounds like there is no way to clean deployed images - unless we break the rules listed in the file "README - DO NOT DELETE FILES IN THIS FOLDER" Sep 20 19:56:33 hmm, not sure if the clean task removes deployed files or not, offhand Sep 20 20:04:19 I don't believe depoloyed files are removed when you run clean* on the image... but they are removed when you run clean on the various recipes Sep 20 20:04:36 ah are they? that's what I was wondering about, dont' think that used to be the case Sep 20 20:04:56 thats an artifact of the sstate work.. it knows which deploy files were generated (and sysroot files) and cleans them up.. Sep 20 20:05:16 * kergoth nods Sep 20 20:09:44 so there is nothing to clean these files up manually then? Sep 20 20:12:29 just run -c clean on the recipes that put the files there, or as has been suggested many times, cleanall may work Sep 20 20:35:39 kergoth: so nothing cleans the rfs themselves... Sep 20 20:35:50 not sure what you mean by that Sep 20 20:37:21 kergoth: tmp/deply/images/core-image-minimal* Sep 20 20:37:29 ? Sep 20 20:37:31 no combo of clean/cleanall Sep 20 20:37:33 can remove these files Sep 20 20:38:00 bitbake -c cleanall core-image-minimal Sep 20 20:38:02 oh, the filesystem files in deploy? doubtful, by design they're date/time stamped so you can access old ones Sep 20 20:39:59 kergoth: all i was saying it's weird to have files you can not remove with bitbake commands when a README says don't delete any files in the directory Sep 20 20:40:43 I expect that's there because people won't realize that deletion of, say, the kernel or u-boot won't result in them showing back up the next time you build an image Sep 20 20:40:45 but fair enough Sep 20 20:40:58 fray: ping Sep 20 20:41:11 yup, here.. Sep 20 20:41:27 fray: while trying to get sanity tests running on the autobuilder and on my personal box I hit this: Sep 20 20:41:41 ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded: ignored Sep 20 20:42:32 I've seen this before (long time ago, IIRC) Sep 20 20:42:40 two things usually cause this.. either it's being run from an setuid binary -- suid won't allow LD_PRELOAD Sep 20 20:42:53 LD_LIBRARY_PATH is broken -- or something similar.. Sep 20 20:43:13 shouldn't be a setuid issue Sep 20 20:43:14 I've been lead to believe that selinux or app armour or something like that can also disable LD_PRELOAD loading.. but I have no specifics and could be wrong there.. Sep 20 20:43:54 I'm pretty sure I don't have it on my box, but it may be on the ab. checking Sep 20 20:44:36 guh, seeing /var/log/apparmor on the ab Sep 20 20:44:37 fun Sep 20 20:47:25 fray: ok, yeah, have it on my personal box too. let me remove and see if this still happens. Sep 20 20:47:58 fray: ahh, ty! Sep 20 20:49:28 if that works, post something on the mailing list.. I wouldn't be surprised if more people end up with apparmor Sep 20 20:49:50 iirc RP was discussing with JaMa abouth how to reproduce this Sep 20 20:50:11 yesterday..check the logs Sep 20 20:50:14 fray: will do, let me yank it off the AB and verify Sep 20 20:52:40 pidge_: do you have LD_LIBRARY_PATH in BB_ENV_EXTRAWHITE? Sep 20 20:53:05 pidge_: I can reproduce this issue easily if I put it there (even when LD_LIBRARY_PATH is not set in my environment) Sep 20 21:05:55 JaMa: No. But, turning apparmor off doesn't seem to fix it on one machine. Checking to see if an uninstall of apparmor won't fix it. Sep 20 21:14:24 I deny everything. Sep 20 21:16:50 Ok: Ubuntu 10.04, apparmor uninstall, sanity test passes Sep 20 21:17:08 OpenSuse 11.4, apparmor disabled, sanity fails Sep 20 21:18:28 pidge_ seebs is the pseudo maintainer.. Sep 20 21:18:45 seebs, pidge may have found that app armour prevents LD_PRELOAD from working properly on some or all applications.. Sep 20 21:18:52 as you can probably guess, this is an "issue" Sep 20 21:19:33 hmm Sep 20 21:19:54 seebs: hi. I'm hitting ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded: ignored when trying to run yocto sanity tests. replicated it on my autobuilder pool and my personal machine. Sep 20 21:20:02 If it does, I'm not at all sure what we could do about it. I mean, that's exactly *by design* what stuff like that is supposed to do -- prevent this kind of chicanery. :) Sep 20 21:20:10 Hmm. Sep 20 21:20:18 I removed apparmor from my personal machine (ubuntu 10.04) everything is happy Sep 20 21:20:36 Anything in security logs or suchlike reporting on it? It'd be nice if we could get some more details about why it can't be preloaded. Sep 20 21:20:43 I disable it on one of the ab slaves and run it, still blows up. Sep 20 21:20:51 sure, one sec, let me check Sep 20 21:22:01 This may well be entering into "don't do that then" territory -- I can't imagine a good security system which sanity-checks validity of code and libraries letting pseudo work. Sep 20 21:22:59 It strikes me as essentially the kind of abuse that security systems are trying to prevent. :) Sep 21 00:52:24 I'm guessing it'll be another 15 minutes for my test.. and then I'll re-issue the pull request.. Sep 21 00:52:38 but I expect what is in mhatle/rpm.deps is current Sep 21 00:52:45 'er.. correct Sep 21 00:53:22 dongxiao -- it looks like your libpng patch will be needed as well (from the ml-testing) -- the skip of allarch should not be needed though Sep 21 00:54:40 fray: so you met the problem when you testing the case 3) ? Sep 21 00:54:57 no I didn't.. but I don't believe png came into that set.. if it did, it worked somehow.. :) Sep 21 00:55:53 fray: ok I will send it to RP today. BTW, for the testing of case 3), did you try the image boot? Sep 21 00:57:28 yes, booted into each of the images and reviewed the packages installed.. Sep 21 00:57:46 fray: ok, thanks very much Sep 21 00:57:51 they each functioned as best that I can tell, and the right sets of packages were installed.. however it made some choices of what to install that I wouldn't have made.. ;) Sep 21 00:58:02 (there was more of a mix of x86_64 and x86 packages that I would have expected) Sep 21 01:00:28 fray: building now, I have to go away for a couple of hours back again later. Sep 21 01:00:33 ok Sep 21 01:19:15 ok test passed.. **** ENDING LOGGING AT Wed Sep 21 02:59:57 2011