**** BEGIN LOGGING AT Fri Jun 10 02:59:57 2011 Jun 10 03:26:24 sgw: hi Jun 10 03:27:45 khem, hi, already sent you an email about the checksum change Jun 10 15:22:11 I think I failed the "are you awake" test this morning Jun 10 15:22:26 that was one heck of a nonsensical response I made.. Jun 10 15:23:25 dvhart: hey there Jun 10 15:23:48 Everything is now fully rebuild based off of master -- except ther kernel, which still has the same problems Jun 10 15:23:57 I guess perhaps the merge got messed up somehow Jun 10 15:26:22 fray: 'tis ok, I got the gist of it anyway :) Jun 10 15:26:34 jefferai, on the phone, give me 10m ? Jun 10 15:26:34 still thinking about the solution Jun 10 15:26:42 dvhart: no problem Jun 10 15:27:08 bluelightning I think the real answer is to teach bitbake that certain things that have been built need to cause a re-load of bitbake Jun 10 15:27:45 then something like bitbake can trigger this re-exec after adding the necessary stuff to invoke pseudo Jun 10 15:28:20 my assumption would be somehow the re-exec would prevent bitbake from re-evaluating all of the recipes.. maybe that's not feasible though Jun 10 15:33:35 Good Morning All ! Jun 10 15:35:45 RP__: ping Jun 10 15:40:56 fray: the other aspect is ensuring anything that requires pseudo is held off until the rebuild of pseudo completes... I guess that means introducting additional dependencies where appropriate Jun 10 15:41:27 bluelightning my view would be a special directive to BB that says these things are stageX, Y, Z.. Jun 10 15:41:34 then it knows to build X then Y then Z.. Jun 10 15:41:42 w/o having to add deps everywhere.. Jun 10 15:41:47 but maybe that is more complicated then necessary Jun 10 15:42:06 BTW in oe-core, only target packages depend on PSEUDO.. nothing else does Jun 10 15:42:19 so it would be pretty easy to only have a pseudo-native dependency at that point Jun 10 15:43:16 right Jun 10 15:43:39 (and for anyone here wondering, why can't you just run pseudo only when you need it... we tried that, we got a fairly significant speed up by doing it only once -- also the python tasks would have to be executed each time they are run under psueod control, which is a significant performance penalty) Jun 10 15:44:10 (so now we preload pseudo "early", and have it disabled.. in memory but not doing anything.. then we simply enable it by setting an environment variable..) Jun 10 15:46:22 fray: so that brings up an interesting question, why did my perl-native do_configure fail? I wouldn't have thought that would rely on pseudo even with poky's setup Jun 10 15:47:13 pseudo is in memory, it's LD_PRELOAD status.. if the binary goes out from under it during compilation (or is simply removed) then yo can get the can't LD_PRELOAD messages Jun 10 15:47:38 it should only be a short window when libpseudo isn't in the sysroot.. but there is a window.. Jun 10 15:48:07 (in the past I thought that when libpseudo was added to the sysroot it was copied over any existing versions.. if that was the case, then this shouldn't be a problem.. Jun 10 15:48:18 but it might have something to do with mmap libraries, I'm not exactly sure Jun 10 15:54:49 about ccache in ML Jun 10 15:55:07 afaik, ccache is good for rebuilding, not for building from scratch Jun 10 15:55:32 but rebuilding isn't our main task Jun 10 15:56:17 saving ccache dir after cleaning tmpdir is bad idea anyway.. so I see no real profit from ccache use Jun 10 15:57:20 Jay7, ccache is really useful in large groups, where sharing the cache can lead to performance gains for the group as a whole.. Jun 10 15:57:42 I'm a bit confused by the ccache within the tmpdir -- but the main thing is that if ccache can be built and configured in a shared space it can be a big win Jun 10 15:58:18 ccache can be helpful on individual builds as well, but only when you are rebuilding the same package to fix an issue -- or because an upstream dependency changed.. Jun 10 15:58:44 Once the hash stuff is all enabled, this may happen more often (rebuilds) making ccache adventagous to more OE users Jun 10 15:59:04 example, someone updates glibc.. everything depending on glibc is rebuilt.. ccache should avoid a lot of compilation then Jun 10 15:59:41 (only places where actual code changes, i.e. headers, would trigger a recompile.. otherwise ccache will re-assemble objects and relink.. resulting in a large speed up) Jun 10 16:00:20 fray: with ccache starting off in tmp it could be overridden by a local.conf setting similary to DL_DIR and SSTATE_DIR, that's the intention anyway. Jun 10 16:00:34 sgw, yup Jun 10 16:02:08 just doesn't seem to me that the tmpdir default will be as useful to groups -- only the rebuild case.. and it's unclear how much of the rebuild case will occur.. (my glibc example was a worst case) Jun 10 16:09:16 fray: I put that out there as a straw man. Its better than ~/.ccache which is the current default Jun 10 16:09:22 agreed Jun 10 16:16:24 poky cgit interface is slow as molassess this morning Jun 10 16:16:28 halstead, ^^ Jun 10 16:18:20 jefferai, ping Jun 10 16:18:59 jefferai, I've been building those branches here locally... I'm not sure what might the issue Jun 10 16:19:23 jefferai, the point where we are blocked right now is 4.6.0 and the ehci Jun 10 16:19:26 code Jun 10 16:19:38 I'm preparing the preprocessed code to send to khem Jun 10 16:19:39 dvhart: ok, maybe I should try re-doing the kernel repo manipulation... Jun 10 16:19:53 jefferai, I'd start there unless zeddii has any ideas Jun 10 16:20:14 jefferai, can you pastebin the error for zeddii ? Jun 10 16:28:30 bluelightning: In case you look at it, I have a fix for the -b issue Jun 10 16:28:39 zenlinux: Its nitin's patches Jun 10 16:28:43 zenlinux: huge :( Jun 10 16:28:47 RP__: zenlinux is on the case Jun 10 16:29:02 RP__: I realise it was my fault though :) Jun 10 16:29:06 zenlinux: I have a patch for the -b issue Jun 10 16:29:23 RP__, oh, I'm just preparing to email my patch Jun 10 16:29:36 zenlinux: please do, I'd be interested to see how you fixed it Jun 10 16:29:49 RP__, sure, it'll be incoming in a few minutes Jun 10 16:29:49 dvhart: yeah, after I try again Jun 10 16:29:53 RP__: which patch ? the gcc patch fixing ? Jun 10 16:29:59 This time I'm doing the clone using --mirror Jun 10 16:30:09 nitink: yes, it didn't fix anything, just broke things badly Jun 10 16:30:15 and I'm going to do my local clone off that without using hardlinks Jun 10 16:31:14 RP__: I could not build here without that patch Jun 10 16:31:31 jefferai, bare implies mirror Jun 10 16:31:39 nitink: There are clearly patches later in the queue that depend on things you removed in that patch Jun 10 16:31:39 iirc Jun 10 16:31:45 dvhart: no, other way around Jun 10 16:31:49 mirror implies bare Jun 10 16:32:01 ah Jun 10 16:32:17 jefferai, when you did the bare - did you clone from upstream or from your local non-bare ? Jun 10 16:32:25 upstream Jun 10 16:32:30 ok good Jun 10 16:32:33 then did a non-bare clone of my local bare Jun 10 16:32:40 right Jun 10 16:32:42 but by default that uses hardlinks Jun 10 16:32:47 RP__: I did build locally, but it did not show any errors here Jun 10 16:32:50 and I sorta wonder if somehow that messed things up Jun 10 16:33:15 jefferai, what I do is clone bare from upstream, then clone from upstream again for the non-bare but use the --reference Jun 10 16:33:24 * jefferai looks up --reference Jun 10 16:33:26 jefferai, that way I don't have to update the bare Jun 10 16:33:39 I view the bare tree is a push tree Jun 10 16:33:43 ah, cool Jun 10 16:33:46 I push my dev branches there and tell it to build Jun 10 16:33:59 using mirror basically lets you use the bare as a push tree Jun 10 16:34:21 but with the benefit (depending on your opinion) of resetting back to the original state when you do a git pull Jun 10 16:34:31 so if you want to clean house and re-push to it, you can do that easily Jun 10 16:34:44 I wonder if I did do mirror actually Jun 10 16:34:47 (git remote update, not git pull) Jun 10 16:34:59 you need all the remote branches to appear as local branches - I was thinking you got that with bare Jun 10 16:35:19 RP__, patch sent Jun 10 16:35:30 (to the bitbake list) Jun 10 16:39:03 RP__: are the gcc shared dir changes in ? Jun 10 16:39:20 nitink: no Jun 10 16:39:45 zenlinux: Still not appeared yet :/ Jun 10 16:39:57 RP__: just wondering why we see different things for the gcc patch Jun 10 16:40:05 * RP__ tries to be patient Jun 10 16:40:07 RP__, I will resend it. not sure what's going on Jun 10 16:40:15 I got my cc'ed version Jun 10 16:40:35 zenlinux: you did use the @lists.openembedded.org address for the list, right? Jun 10 16:40:46 RP__, yes Jun 10 16:41:57 the oe lists can be slow sometimes Jun 10 16:42:51 zenlinux: can you just forward to me please Jun 10 16:43:06 dvhart: OK -- I have my bare repo cloned from upstream, my non-bare repo cloned from upstream (but using --reference), and contrib, which I did a pull of your two branches in Jun 10 16:43:28 right Jun 10 16:43:29 I've added contrib as a remote to my non-bare, and checked out your two branches as tracking branches Jun 10 16:43:36 right Jun 10 16:43:53 now push them to the bare, but with the same names as those in the bare repo Jun 10 16:43:54 RP__, sent to your LF address Jun 10 16:44:01 dvhart/meta/beagleboard -> meta Jun 10 16:44:13 dvhart/yocto/standard/beagleboard -> yocto/standard/beagleboard Jun 10 16:44:18 zenlinux: usually its helpful if you set git config sendemail.to

inside the repo then you dont have to type the to address everytime you generate a patch it gets added Jun 10 16:44:42 yep Jun 10 16:44:47 khem, thanks for the tip Jun 10 16:44:49 khem, I can't make the date match no matter what I do...but I have the right bits. Jun 10 16:45:02 ka6sox-away: ok thx Jun 10 16:45:07 I will test it out Jun 10 16:45:38 if its a problem let me know as the mirroring is being tweaked and might have a few stale things. Jun 10 16:46:43 dvhart: ok, so like yesterday, doing a straight push results in a reject due to non-fast-forward Jun 10 16:46:51 ka6sox-away: problem still remains Jun 10 16:46:56 jefferai, ok hold on Jun 10 16:46:59 I haven't rebased, but I have a feeling that the rebasing is maybe what caused the problems yesterday Jun 10 16:47:00 :-| Jun 10 16:47:08 jefferai, let me rebase my contrib and repush Jun 10 16:47:11 ok Jun 10 16:48:09 jefferai, only meta has a problem right? Jun 10 16:48:15 * jefferai checks Jun 10 16:48:19 er Jun 10 16:48:19 no Jun 10 16:48:26 yocto/standard/beagleboard does Jun 10 16:48:29 not sure about meta Jun 10 16:49:04 meta does too Jun 10 16:49:33 * dvhart scratches his head confused Jun 10 16:49:51 there is a lot more rebasing than I expected... something isn't right here Jun 10 16:50:11 zeddii, you haven't rebased meta or yocto/standard have you? Jun 10 16:50:41 nope. Jun 10 16:50:46 all fast forward. Jun 10 16:50:56 very strange Jun 10 16:51:13 is it picking up the linux-omap merge in a odd manner ? Jun 10 16:51:22 I don't think so Jun 10 16:54:04 jefferai, ok, I've repased and updated contrib Jun 10 16:54:24 jefferai, please reset your local branches to the contrib versions and try pushing to the bare repo Jun 10 16:55:14 OK Jun 10 16:55:26 * jefferai *knew* he wasn't crazy :-) Jun 10 16:55:39 well, you weren't wrong Jun 10 16:55:50 the latter is still open for debate Jun 10 16:56:29 I'm rebuilding with the new branches as well Jun 10 16:56:32 so this is odd -- pulling into my contrib clone showed forced updates Jun 10 16:56:42 but pulling into my non-contrib clone from my contib clone showed fast forwards Jun 10 16:57:42 right, because contrib already had the old ones Jun 10 16:57:47 (locallY) Jun 10 16:58:11 jefferai, what hardware are you using? xM A? C4 ? Jun 10 16:58:14 xM Jun 10 16:58:16 not sure which rev Jun 10 16:58:27 ok, uboot will tell you on your next boot Jun 10 16:58:45 jefferai, the beagleboard branch has khem's suggested fix to ehci in it Jun 10 16:58:49 it hasn't worked for me Jun 10 16:59:08 but I'd appreciate another build with 4.6.0 for verification that _I'm_ not crazy Jun 10 16:59:50 ok, closer Jun 10 17:00:05 yocto/standard/beagleboard fast-forwarded Jun 10 17:00:14 zenlinux: Do you think we need to take priority data into account when using -b ? Jun 10 17:00:16 meta still says a force push would be needed Jun 10 17:00:25 zenlinux: I'm wondering about .bbappends Jun 10 17:00:31 jefferai, have you reset meta to origin/meta? Jun 10 17:00:41 jefferai, because I rebased to origin/meta and pushed Jun 10 17:00:47 zenlinux: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/temp5&id=3ee6c1cee587d3cc5b8a358a5b1d4fd8435545a3 was my version Jun 10 17:00:53 * RP__ is in two minds about it Jun 10 17:01:08 hm...which repo? I removed my branch in my non-bare that was tracking contrib/dvhart/meta/beagleboard Jun 10 17:01:11 then I recreated it Jun 10 17:01:21 which should have the effect of giving me a fresh branch with your recent changes Jun 10 17:01:37 wait... so where did you require a force? Jun 10 17:01:42 nowhere Jun 10 17:01:47 well Jun 10 17:01:49 except pushing meta to bare Jun 10 17:02:08 RP__, I definitely did not take bbappends into consideration when creating my patch version. I think I prefer your version Jun 10 17:02:12 and meta in bare was at what when you pushed it? Jun 10 17:02:24 let's see Jun 10 17:02:51 46a1be20b Jun 10 17:02:57 hrm Jun 10 17:02:58 RP__ I'm working on the directory ownership thing.. I put some debug statements into "populate_packages", but I'm not seeing them.. any suggestions on how to make sure I'm running through it.. I tried to do bitbake ... -c package -f Jun 10 17:03:02 should that be enough? Jun 10 17:03:12 fray: Add -D Jun 10 17:03:26 Your branch is ahead of 'origin/meta' by 676 commits. Jun 10 17:03:26 It won't put debug in the log unless you tell it to Jun 10 17:03:29 which doesn't appear to be in your branch Jun 10 17:03:29 yeow Jun 10 17:03:40 I have the debug as "bb.note" Jun 10 17:03:46 * dvhart tries again Jun 10 17:03:52 dvhart: :-) Jun 10 17:03:59 fray: try bb.error Jun 10 17:04:04 ok.. thanx Jun 10 17:04:07 fray: Those go *everywhere* Jun 10 17:04:09 jefferai, I'm a bit baffled to be honest Jun 10 17:04:14 there should only be the one change :-) Jun 10 17:04:17 fray: we should track down why the notes aren't appearing though Jun 10 17:04:43 I think the rebase did the wrong thing Jun 10 17:04:48 hm, perhaps Jun 10 17:04:58 changed it to warn and it's working now.. Jun 10 17:05:01 I mean it looks like your meta has nothing from around May 26-> now Jun 10 17:05:02 Interesting.. Jun 10 17:05:03 thanx Jun 10 17:05:04 except your one commit up top Jun 10 17:05:18 * jefferai suggests a merge instead of a rebase Jun 10 17:05:32 I know everyone likes to avoid extra merge commits, but... Jun 10 17:05:59 or, export your one commit as a diff, update the branch, re-apply the diff, recommit Jun 10 17:06:02 might be easier Jun 10 17:06:22 jefferai, I only rebase in my contrib - but in this case, I just did a new branch and cherry-picked my one chage Jun 10 17:06:24 pushed to contrib Jun 10 17:06:29 ok Jun 10 17:06:50 zenlinux: I've merged my version but I would have preferred yours ;-) Jun 10 17:06:52 heh, conflicts Jun 10 17:06:57 its' ok, will destory the branch and re-checkout Jun 10 17:07:03 heh Jun 10 17:07:16 I can't even take full credit for my version - bluelightning coached me :) Jun 10 17:07:18 dvhart: yikes: Jun 10 17:07:27 Your branch is ahead of 'origin/dvhart/yocto/standard/beagleboard-ti-patched-yocto' by 114 commits. Jun 10 17:09:10 I am trying this locally.... this is all very strange Jun 10 17:09:49 ok push to meta is a clean fast forward Jun 10 17:10:23 yep, push to meta is clean Jun 10 17:10:36 that message about the 114 commits was in my contrib repo Jun 10 17:10:51 which suggests that the rebase went wonky in that branch too Jun 10 17:10:51 I see what heppend Jun 10 17:10:58 yeah? Jun 10 17:10:58 I pushed the wrong branch Jun 10 17:11:35 ah! Jun 10 17:11:40 that could do it Jun 10 17:12:54 need some quick python help.. whats hte opposite of split? I'm blanking Jun 10 17:13:02 fray: join Jun 10 17:13:16 string.join(list)? Jun 10 17:13:25 um Jun 10 17:13:31 sure, something like that Jun 10 17:13:53 yup, join Jun 10 17:13:57 thanx Jun 10 17:14:14 fray: I think it's more like Jun 10 17:14:20 list.join(sep) Jun 10 17:15:03 oh, or string.join(string, sep) Jun 10 17:15:06 where sep defaults to ' ' Jun 10 17:15:11 (a single space) Jun 10 17:15:23 ahh ok Jun 10 17:15:23 http://docs.python.org/library/stdtypes.html#str.join Jun 10 17:15:50 I use duckduckgo as my search engine, which allows me to do !python join and it will search the python documentation site :) Jun 10 17:15:58 or, http://docs.python.org/library/string.html#string.join Jun 10 17:16:05 zenlinux: ah, duck duck go! Jun 10 17:16:10 fun company Jun 10 17:16:22 jefferai, at the risk of embarrassing myself here... I _think_ this is now clean Jun 10 17:16:22 I only use Google now for maps Jun 10 17:16:30 we'll see :-) Jun 10 17:16:40 jefferai, there are 114 patches in beagleboard-ti-patched-yocto over just beagleboard Jun 10 17:16:43 ok Jun 10 17:16:44 which is as it should be Jun 10 17:17:06 and each push cleanly to current upstream origin Jun 10 17:17:08 let me know when you push Jun 10 17:17:10 ok Jun 10 17:17:12 done Jun 10 17:17:28 hrm Jun 10 17:17:33 git remote update isn't pulling anything Jun 10 17:18:19 brb Jun 10 17:29:50 back Jun 10 17:30:33 jefferai, I suggest pushing the contrib branch to a branch that matches origin/yocto/standard/beagleboard, that should be a clean push of 114 patches Jun 10 17:30:41 dvhart: when I do a git log on your yocto branch I see commits from Jun 9, Jun 6, Jun 6, Mar 10, Mar 10 Jun 10 17:30:45 does that match what you see? Jun 10 17:30:57 that's from the contrib repo Jun 10 17:31:31 yes Jun 10 17:31:36 ok Jun 10 17:31:48 I wonder why when you pushed I got no update here Jun 10 17:32:25 not sure - lets see if things are in a working state now and start fressh Jun 10 17:33:06 ye Jun 10 17:33:08 p Jun 10 17:33:12 all apply cleanly to bare now Jun 10 17:33:19 phew Jun 10 17:33:21 :-) Jun 10 17:33:26 <- lame Jun 10 17:33:38 Well, we all need to go through our baby steps at some point Jun 10 17:33:40 TROLOLOLO Jun 10 17:33:45 ;) Jun 10 17:33:54 * jefferai restarts bitbake Jun 10 17:33:56 I think that rebase did something strange Jun 10 17:36:14 wouldn't be the first time Jun 10 17:45:30 SIGFOOD - forgot to eat, back soon Jun 10 18:07:41 * Jay7 catch SIGFOOD too Jun 10 18:44:01 khem, jefferai ... I think I may have good asm finally, trying a boot Jun 10 18:52:12 cool Jun 10 18:59:53 ok, X, USB mouse, and ethernet are working Jun 10 18:59:58 oddly, usb keyboard is not :/ Jun 10 19:00:46 jefferai, let me push this patch to contrib - maybe you can check if the keyboard is an issue for you? Jun 10 19:00:52 I have a slightly funky keyboard Jun 10 19:02:18 probably not today --- it's not even finished building the kernel the first time yet Jun 10 19:02:21 * jefferai isn't sure what's taking so long Jun 10 19:02:32 the git pain finally stopped ? Jun 10 19:02:53 zeddii, yeah Jun 10 19:03:01 jefferai, the modules :( Jun 10 19:03:10 the meta-ti fragment builds hundreds of them Jun 10 19:03:17 I still need to whittle that now Jun 10 19:03:44 my beast build box chokes on that too :/ Jun 10 19:09:42 no love on the C4 Jun 10 19:46:53 dvhart: I'm actually going to be seeing if I can get funded to work on some yocto-related things, if they are things that you guys are interested in Jun 10 19:49:13 :q Jun 10 19:49:17 oops Jun 10 19:49:51 jefferai, that would be great Jun 10 19:50:00 jefferai, what sorts of things did you have in mind? Jun 10 19:50:01 <16SAAJXNG> ReaperOfSouls: that wouldn't happen with emacs ;-) Jun 10 19:50:26 lol Jun 10 19:51:20 dvhart: distcc/icecream support, easy (for the end-user) layer management/creation, possibly work with qemu (I haven't used it with yocto yet) to make it easily scalable out to support lots of emulations Jun 10 19:52:12 jefferai, have you been following the layer tooling work on the list? as well as the image builder work? Jun 10 19:53:06 * dvhart isn't wholly sold on distcc - I've used it in the past, and found it's setup to be more effort than it was worth Jun 10 19:53:10 nope, I'm still very new to this, so not yet subscribed to lists -- I should probably fix that Jun 10 19:53:12 haven't tried it with yocto yet though Jun 10 19:53:25 dvhart: a lot of people prefer icecream for that reason Jun 10 19:53:33 so I hear Jun 10 19:53:42 it basically works with distcc but brings the entire compilation environment over with it Jun 10 19:54:21 but my thought was that it should be possible to write a tool that can hook into the bits to interpret and parse the different layer variables/definitions and present this to the user Jun 10 19:54:25 jefferai, you might also have a look at https://wiki.pokylinux.org/wiki/Yocto_Project_Unscheduled_Feature_List Jun 10 19:54:50 with the end goal of the user literally being able to pop up a GUI, pick the packages or package sets they want, and hit Build Jun 10 19:55:05 I guess that's similar to Image Creator? Jun 10 19:55:08 jefferai, :-) Jun 10 19:55:20 * jefferai didn't think he'd be the only one wanting this Jun 10 19:55:21 :-) Jun 10 19:55:22 jefferai you need to talk with incandecent Jun 10 19:55:26 ok Jun 10 19:55:28 well, not yet Jun 10 19:55:46 he has the start of an image builder that does pretty much that Jun 10 19:55:50 because if there's no funding, then I likely won't have time to work on it Jun 10 19:56:00 but if that comes through I'll definitely get in touch Jun 10 19:56:06 wouldn't be for a while, anyways Jun 10 19:56:44 jefferai, in particular, check out: https://wiki.yoctoproject.org/wiki/BitBake/GUI/CurrentState Jun 10 19:59:01 meh Jun 10 19:59:02 GTK Jun 10 20:01:54 distcc does not buy you much if you have multicore machines Jun 10 20:02:07 the bottleneck is the job dispatcher Jun 10 20:02:18 sure it does Jun 10 20:02:24 at work I have experimented with distcc more than anyone else Jun 10 20:02:41 and found that the gains diminished pretty fast Jun 10 20:03:03 jefferai, not a fan of gtk? what did you have in mind? qt? html5? Jun 10 20:03:04 it depends on how well your compilation parallelizes Jun 10 20:03:25 dvhart: I only know Qt well. It wasn't so much "not a fan of" as "don't know anything about and don't particularly feel like learning" Jun 10 20:03:38 it's not fun to go to a C framework when you have a much better C++ one that you're fluent in :-) Jun 10 20:03:48 jefferai, it also depends on how serialized your build is (independent of the individual package compilation parallel..iza..bility :-) Jun 10 20:04:07 yes, it does Jun 10 20:04:09 jefferai: the software we have is entirely parallelized so thats not an issue here Jun 10 20:04:11 jefferai, it's written in python Jun 10 20:04:36 after a while the jobs are not disapatched because the preprocessing is happening single threaded Jun 10 20:04:52 khem: what software is this? Jun 10 20:05:14 JUNOS Juniper's Network Operating System Jun 10 20:05:32 with roughly 90 million lines of code compiled for 12 architectures Jun 10 20:09:02 hm Jun 10 20:09:05 similarly ccache becomes useless on a shared ccache directories Jun 10 20:09:18 when multiple users are using a build machine Jun 10 20:09:28 and you have different branches being build Jun 10 20:09:36 I'm not sure at what point they diminish for you, but I know people running various boxes that do a lot of compilation of software that seem very, very happy with the speed boosts they get from running make -j99 Jun 10 20:10:08 maybe it's not much more than make -j30 Jun 10 20:10:19 but that's still a lot faster for them than make -j8 Jun 10 20:11:41 there are some other systems which work on shared file systems they are lot more scalable Jun 10 20:13:18 dunno -- I just know that if I can get my build time for each arch down to, say, 2 days instead of 3, it'd be very useful for me Jun 10 20:15:24 days? Jun 10 20:15:30 jefferai, what are you building? Jun 10 20:15:38 yes for medium build farms yes Jun 10 20:16:13 dvhart: my builds are like 24 hrs Jun 10 20:16:28 and thats on obcenely powerful machines Jun 10 20:16:38 khem, yeah, I was getting that from your statements above Jun 10 20:16:48 just wondering what jefferai was building Jun 10 20:17:04 if I build lnx kernel it takes seconds :) Jun 10 20:17:12 khem, is that one arch or for all 12 arches? Jun 10 20:17:20 all 12 Jun 10 20:17:22 ok Jun 10 20:17:41 that's not inconsistent with our total build time of several images across several archs Jun 10 20:17:49 dvhart: actually I have figured that packaging is the biggest serialization point Jun 10 20:17:55 me too Jun 10 20:17:59 so working on fixing it here Jun 10 20:18:01 it's incredibly slow Jun 10 20:18:02 dvhart: oe-core-sato Jun 10 20:18:09 I guess not days Jun 10 20:18:14 more like, 24-36 hours? Jun 10 20:18:22 jefferai: are you building it on smart phone Jun 10 20:18:25 no Jun 10 20:18:29 bwahaha Jun 10 20:18:34 on a quad core hyperthreaded xeon Jun 10 20:18:42 hmm Jun 10 20:18:50 jefferai, so you know, the goal is for that to build for 1 arch in 1 hour Jun 10 20:18:55 It *is* a lot of packages... Jun 10 20:18:56 we're more like 100 minutes right now Jun 10 20:19:04 dvhart: build what, exactly? Jun 10 20:19:11 dvhart: 1 hr on what spec build machine Jun 10 20:19:13 the linux build alone has been > 2 hours :-) Jun 10 20:19:19 linux-yocto build that is Jun 10 20:19:22 qemux85 core-image-sato quad core, 8GB Jun 10 20:19:28 qemux86 even Jun 10 20:19:30 what about arm? Jun 10 20:19:32 ok thats sane Jun 10 20:19:52 I heard you guys have some monsters with 40 cores Jun 10 20:20:09 khem, yeah, I have a 40 core (80 threads) with some unholy amount of RAM Jun 10 20:20:12 jefferai: so 36 hrs for sato-image Jun 10 20:20:17 on xeon Jun 10 20:20:18 as well as a 12 core (24 th) with 16 GB RAM Jun 10 20:20:27 this latter is a _really_ nice machine Jun 10 20:20:35 dvhart: I can bribe you for some time on it Jun 10 20:20:40 ;) Jun 10 20:20:40 RAID0 has been a big help as well Jun 10 20:20:59 I save 15 minutes with SSD and 10 minutes with spinning two disk RAID0 Jun 10 20:21:06 much cheaper and nearly the same benefit Jun 10 20:21:11 khem, ;) Jun 10 20:21:13 my best box is a core2duo :) T61 Jun 10 20:21:32 khem, not counting your hoards of hardware at work you mean? Jun 10 20:21:42 * jefferai does need to get a new box Jun 10 20:21:50 dvhart: no, at work I dont use OE or work on it Jun 10 20:21:55 OE work is all own time Jun 10 20:21:55 OH! Jun 10 20:22:06 khem, yikes, I didn't realize Jun 10 20:22:12