**** BEGIN LOGGING AT Thu Feb 28 02:59:58 2013 Feb 28 03:13:47 #yocto Feb 28 03:56:36 Hi, I am doing custom kernel from github and build Feb 28 03:56:54 and getting this error "No rule to make target `oldconfig'", any one has run into this issue? **** BEGIN LOGGING AT Thu Feb 28 12:27:15 2013 Feb 28 17:19:17 newbie q: howto clean everything except ccache and rebuild target? Feb 28 17:30:21 don't delete the cache directory would be my guess Feb 28 17:32:00 mcfrisk: if you delete your tmp, it will rebuild in about five minutes from the sstate Feb 28 17:32:39 rburton: thanks Feb 28 17:34:06 depends on target and IO, world build still takes ~ hour from sstate Feb 28 17:34:47 hours is ok for verifying that a couple of targets can be build from scratch. Days not :) Feb 28 17:35:19 mcfrisk: world is insanely massive, ignore jama :) Feb 28 17:36:04 seriously i can do a core-image-sato from sstate in <10 minutes on my modest machine Feb 28 17:36:18 (timed in november, should be faster now too) Feb 28 17:41:44 rm -rf tmp takes minutes, not a good sign on this laptop.. Feb 28 17:42:20 i tend to do mv tmp foo ; ionice -c3 rm -rf foo Feb 28 17:43:37 is there any problem changing a recipe after bitbake parsed all the recipes? Feb 28 17:43:46 mcfrisk: it will take a lot more minutes on laptop, ignore rburton :) Feb 28 17:43:59 yeah, laptop will be slower Feb 28 17:44:11 i think the word i'm looking for is "painful" Feb 28 17:44:17 * rburton used to use a x220s Feb 28 17:47:15 really? Using yocto on a lappy is slow?... (That's what I often do) Feb 28 17:47:36 JaMa: hopefully not hours, just wanted to start two overnight builds after shoehorning meta-fsl-arm to poky denzil.. Feb 28 17:47:41 blloyd_: my i7 desktop does builds about twice as fast as my i7 laptop Feb 28 17:49:12 mine run about the opposite. I have a faster disk attached to the lappy (external SATA when), or my internal disk is faster than the raid controller I'm mandated to use in my desktop. It seems to all be about disk speed. Feb 28 17:49:17 rburton: crypto? Feb 28 17:49:41 (oh, and I figured out really, really fast don't do this to an encrypted disk) Feb 28 17:50:48 blloyd_: having a butt load of ram helps, as the kernel happily builds up 12G of disk cache here Feb 28 17:51:05 the laptop is also newer than the desktop. And I have all of 2GB difference between the two. Feb 28 17:51:20 rburton: thanks for the tip (ionice) Feb 28 17:52:02 ftonello: no idea if it makes a difference, but it's a good placebo Feb 28 17:52:03 16GB on the laptop. I will say it was a LOT slower with my 8GB laptop. Feb 28 17:52:34 ok, noticably slower. Feb 28 17:53:07 and don't try a 5400 RPM hard disk. THAT is painful. Feb 28 17:53:11 rburton: i will try that and check with top hows the process going Feb 28 17:54:38 ok, rm -rf tmp; bitbake image & go home. Thanks guys. Feb 28 17:55:21 hehe. I do mv tmp t; rm -rf t & Feb 28 17:55:22 mcfrisk: i also endorse a cron job :) Feb 28 17:56:32 build server, git hooks, test automation, jenkins... sure :) Feb 28 17:56:37 in my dreams Feb 28 17:56:51 i literally have a 5am cron that does a bitbake Feb 28 17:57:44 https://github.com/rossburton/poky-nightly <-- buildbox this isn't Feb 28 18:00:51 * kmacleod learns something new everyday: disown. from rburton's cron job. was just looking for that exact command just a few days ago. Feb 28 18:44:57 disown is indeed awesome Feb 28 19:21:26 kergoth: that is a new one Feb 28 19:21:43 wish i knew about that command before Feb 28 19:27:00 halstead: ping! Did my email to you about the pseudo 1.5.1 tarball escape our IT department's fearsome clutches? Feb 28 19:27:27 seebs, Ack. I did. Thanks for the reminder. Feb 28 19:27:35 k Feb 28 19:28:04 I am getting really, really, sick of writing code to work around filesystems which don't report their state consistently without syncs. Feb 28 19:29:13 seebs: which filesystems are these? Feb 28 19:29:33 Not entirely sure, but all our problems show up with ext4 on CentOS, I think. Feb 28 19:29:54 The basic problem we observe: Start with an unpacked rootfs in directory "foo". Feb 28 19:30:12 1. Run prelink on foo. 2. After prelink is done and the process has exited, "tar cvf foo.tar foo". Feb 28 19:30:52 This will OCCASIONALLY fail because "file foo/bar/mumble changed as we read it" Feb 28 19:31:25 Which means that stat before and after showed different values for either st_ctime or st_size. Feb 28 19:31:48 We also noticed that, quite frequently, we'd get wildly bogus values from "du" right after a prelink. Feb 28 19:32:16 As a side-effect of this biting us a while back, our local branch of prelink fsyncs everything, and the problems went away. Put in pseudo 1.5, and they suddenly came back. *sigh* Feb 28 19:47:29 Hi folks. Is there a way to get bitbake to print all package+versions needed to satisfy the RDEPENDS of some root target? Basically, if I do a 'bitbake core-image-foo', I'd like a list of all packages being installed on foo's rootfs. Feb 28 19:49:37 see tmp/deploy/license/ Feb 28 19:49:48 the image license manifest might do the job for you Feb 28 19:49:53 there's also the buildhistory info about the image Feb 28 19:49:59 tmp/buildhistory/ Feb 28 19:50:59 does tmp/deploy/license include information about packages needed to build other packages, but might not actually be on the rootfs? Feb 28 19:51:38 (e.g., I want A on rootfs, A need B to build, but B won't be on the rootfs, is B's license in tmp/deploy/license) Feb 28 19:51:55 I'll check out buildhistory Feb 28 19:52:23 the image license manifest only lists what went into that image, not everythign that was built, but elsewhere in license should be info on everything that was built Feb 28 19:52:28 outside of the manifest, that is Feb 28 19:52:34 look around both license and buildhistory Feb 28 19:52:43 buildhistory also tracks package metadata Feb 28 19:52:47 where is the license manifest? Feb 28 19:54:03 maybe `bitbake -g core-image-foo`, but I'm not sure about the versions being around there Feb 28 19:57:18 mihai: thanks, I'll take a look there too Feb 28 20:01:50 i just told you, the image license manifsets is under tmp/deploy/license/ Feb 28 20:02:01 if you'd spent 10 seconds looking there, you'd see the directories decided to the images you built :) Feb 28 20:04:48 fray: around Feb 28 20:04:58 ya Feb 28 20:05:16 I have a strange issue with rpm Feb 28 20:05:21 I think I know the issue Feb 28 20:05:42 package_rpm.bbclass Feb 28 20:05:47 around line 56 Feb 28 20:06:11 for keyword_die in "unpacking of archive failed" "Cannot find package" "exit 1" ERR Fail Feb 28 20:06:18 see ERR Feb 28 20:06:39 now in meta-java there are some post-installs which has ERROR: word in them Feb 28 20:06:59 so it dies Feb 28 20:07:00 That sounds "bad".. Feb 28 20:07:01 if (echo "$lf_txt" | grep -v log_check | grep "$keyword_die") >/dev/null 2>&1 Feb 28 20:07:11 I changed the above line to Feb 28 20:07:16 if (echo "$lf_txt" | grep -v log_check | grep "\<$keyword_die\>") >/dev/null 2>&1 Feb 28 20:07:21 The right approach (for rpm, and likely others) is to fix the 'ERROR'.. Fix == make it not appear Feb 28 20:07:33 and it worked Feb 28 20:07:35 so in the recipe post install, it might be reasonable to do: Feb 28 20:07:44 foo 2>/dev/null || true Feb 28 20:07:48 or something like that to avoid the message Feb 28 20:08:24 in my test I grepped for 'exact' ERR and it workd Feb 28 20:08:25 I think that was supposed to find any line that had 'ERR' in it.. Feb 28 20:08:30 (this is really old code BTW) Feb 28 20:08:30 so definitely yhats the issue Feb 28 20:08:46 so if its supposed to find 'ERR' Feb 28 20:08:55 exact match then my fix could be a good one Feb 28 20:09:22 AFAIK it's suppoed to be more then an exact match.. it's 'any match'.. Feb 28 20:09:27 I believe the same code is in ipk and deb Feb 28 20:09:35 I want sure since I thought the script might be a greedy regexpt to consume all ERR words Feb 28 20:09:43 for keyword_die in "exit 1" "Collected errors" ERR Fail Feb 28 20:09:43 do Feb 28 20:09:43 if (echo "$lf_txt" | grep -v log_check | grep "$keyword_die") >/dev/null 2>&1 Feb 28 20:09:47 that is ipk Feb 28 20:09:52 OK Feb 28 20:10:00 kergoth: sorry, there are 518 directories in tmp/deploy/licenses -- it took me longer than 10 seconds to find it :) Feb 28 20:10:03 for keyword_die in "^E:" Feb 28 20:10:03 do Feb 28 20:10:03 if (echo "$lf_txt" | grep -v log_check | grep "$keyword_die") >/dev/null 2>&1 Feb 28 20:10:05 that is deb Feb 28 20:10:28 so if that message could pop up in ipk at least, you'll get a failure just like RPM.. Feb 28 20:10:30 kergoth: but that's exactly what I'm looking for -- thanks again Feb 28 20:10:45 fray for loops are different Feb 28 20:11:03 :q Feb 28 20:11:23 Garibald1: hah, sorry. we use a class that deploys that file into deploy/images next to the license, so i forgot how confusing licenses might be directly - see http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor/tree/classes/deploy-license-manifest.bbclass. also deploys it in csv form for use in spreadhseets which can be useful in dealing with legal Feb 28 20:11:26 it's the same loop in the rpm/ipkg/deb log_check function -- except for what it's searching for.. Feb 28 20:11:34 s/next to the license/next to the image/ Feb 28 20:12:12 kergoth: ah, beautiful :) Feb 28 20:12:19 that's exactly what I'm in the process of doing Feb 28 20:12:38 figured that might be the case, it's a pain many of us are too familiar iwth Feb 28 20:14:37 fray: https://github.com/kraj/meta-java/blob/master/recipes-core/openjdk/openjdk-6-common.inc Feb 28 20:14:50 take a look there around line 500 Feb 28 20:18:29 which line? I see some greps and such in the postinst.. Feb 28 20:18:57 doesn't look like any of those shouldn't printed anything t the screen though Feb 28 20:53:32 kergoth: you don't happen to know how to get similar license information for a generated (ala -c populate_sdk) SDK do you? Feb 28 20:54:24 Hmm, not offhand, no. might want ot look over either license.bbclass or image.bbclass Feb 28 20:54:33 will do, thanks Feb 28 20:54:38 np Feb 28 21:11:14 fray: see https://github.com/kraj/meta-java/blob/master/recipes-core/openjdk/openjdk-postinst.inc Feb 28 21:14:12 seebs, Your release is up. Let me know if you didn't get my e-mail earlier. Feb 28 21:14:41 halstead: Thanks, I believe I did get it. And I think I even then remembered to ping sgw to let him know that it should be there now to match the pull request. Feb 28 21:15:01 seebs, Great. :) Feb 28 21:15:02 I've been fixing too many bugs lately and I'm dropping packets a bit, though. Feb 28 21:15:51 seebs, I'm scrambling a bit to make sure we have good backups again. Feb 28 21:16:23 backups: a task which varies inversely in importance with the degree to which it's been done successfully. :) Feb 28 21:32:18 seebs: I assume this pseudo fix only does things on the broken distros/versions that need it? Feb 28 21:32:55 What it actually does is: Nothing unless you set a particular environment variable. Which is never set by anything in oe-core. Feb 28 21:33:28 In our tree, where we have a prelink that calls fsync() and care about broken distros, we add a PSEUDO_ALLOW_FSYNC=1 in front of the call to prelink in image-prelink.bbclass. Feb 28 21:34:01 The main reason I think this should be in tree is that, if anyone else has "weird problems" like the tar cvf of a filesystem assembly failing, it makes it easier to quickly check whether that's the issue. Feb 28 21:44:09 seebs: ok, that is fine. I hadn't picked up how you trigger it Feb 28 21:44:40 Yeah. I think I had originally intended that kind of mechanism, then in a sleepless haze I thought "oh, but I have a configure option, that should be good enough". Feb 28 21:45:06 Turns out, this is a 30-50% increase in number of builds I can do, or better, for my regular use cases, and I'm not willing to give that up just for one stupid command. Feb 28 21:46:06 On my list: Modify tar to give more explicit details on what changed when it detects this, modify prelink to also give information on those values when done with a file, and start looking for a reproducer to file a bug report. Copious Free Time allocation puts this somewhere around Q2 2016. Feb 28 21:52:27 seebs: that soon? ;-) Feb 28 21:52:51 Hey, this week's been great, only thing I added to my list was writing a novel. Feb 28 21:53:20 But I'm forgetful, so stuff falls off the list at a respectable pace, and I do occasionally get to things. Feb 28 22:34:42 are there any examples of image recipes creating u-boot boot.scr files? Feb 28 23:16:32 dv_, hrm, I *thought* the beagleboard bsp did that.... Mar 01 00:29:19 when did we get a yocto bot? Mar 01 00:30:01 dv_: beagleboard bsp probably does that but the new format is uEnv.txt Mar 01 00:30:16 newer u-boot's that is... Mar 01 00:30:39 * mranostay never liked to run mkimage on a text file :) Mar 01 01:25:13 mranostay: We've always had one. It lived in #yoctobuilds or some such. Moved the bot here since no one other than a few people actually were in channel. Mar 01 01:26:25 * pidge frowns over the git failures. halstead, I keep seeing weird stuff like this. It's generally pretty hard to replicate. any idea of what load/network was like during the failure? I've a feeling it was high. Mar 01 01:28:35 pidge: I'll look into it. Load is high for sure. Mar 01 01:29:02 halstead: yeah. I'm guessing it's due to the second ab infrastructure. Mar 01 01:29:12 * pidge might have to trim that down a bit. Mar 01 01:32:03 halstead: trimmed down the new infra ab to one builder on ab01. the rest are at 2. Mar 01 01:33:13 Pidge okay. We have hardware on order that will help. Mar 01 01:33:43 weeee. moar hardware plz! Mar 01 02:55:33 is there any special magic people employ when switching branches? Mar 01 02:56:27 for example, I had a build (bitbake core-image-minimal) under master (which succeeded) then I simply did a git checkout of MUT and re-ran "bitbake core-image-minimal" Mar 01 02:56:46 it succeeded too, but i'm just wondering if that's the proper workflow Mar 01 02:57:26 sgwl: all set? Mar 01 02:58:00 trevor_: Hi there Mar 01 02:58:11 sgwl: hi Mar 01 02:59:10 trevor_: that's the kind of things I do, then I switch back, what you might see is things going backwards if you switch back to master Mar 01 02:59:42 sgwl: okay thanks, just checking **** ENDING LOGGING AT Fri Mar 01 02:59:58 2013