**** BEGIN LOGGING AT Tue Jul 19 02:59:57 2011 Jul 19 08:15:17 morning all Jul 19 09:01:08 morning all Jul 19 14:34:28 RP__, around ? Jul 19 14:59:42 RP__, sgw, ping about the bits I posted yesterday Jul 19 15:00:12 Tartarus: I'm waiting on a combined pull request from Saul Jul 19 15:00:40 Tartarus: once the contents of that is known I'll look at the other bits Jul 19 15:01:21 another one? or just catching up on emails/etc now? :) Jul 19 15:01:41 We're trying to get back into the pattern of his testing and then I merge Jul 19 15:03:35 OK Jul 19 15:04:05 sgw: ping on if you think I need a v5 / v3, don't wanna have too many series pending if I can help it Jul 19 15:04:15 * Tartarus is going to split up the deep path bits next and get that out hopefully in a few hours Jul 19 15:05:20 RP__: here's something you won't like I suspect. If you build $foo with perlnative users of $foo need to also have perlnative inherited, since we can't #!/full/path/to/perl as that's very not safe Jul 19 15:05:31 ie sato-icon-theme or so needs perlnative now Jul 19 15:07:04 Tartarus: sorry, was on a call, I will be getting to this today. Jul 19 15:07:58 k, thanks Jul 19 15:07:59 Tartarus: What exactly isn't very safe? Jul 19 15:08:14 RP__: shebang limit is 80 chars Jul 19 15:08:28 Which given TMPDIR/TOPDIR/sysroot/.. isn't very hard to hit Jul 19 15:08:59 fray: we use /usr/bin/env perl Jul 19 15:09:05 But that needs to return the perl we built with Jul 19 15:09:14 otherwise it gets all "hey, I don't know where ... is!" Jul 19 15:09:21 don't we have the sysroot path first in the PATH=? Jul 19 15:09:32 We moved perl out of sysroot/usr/bin Jul 19 15:09:39 and into sysroot/usr/bin/perl-native/perl Jul 19 15:09:44 So you have to opt-in Jul 19 15:09:44 ohh Jul 19 15:10:03 This, I believe, was some of the "you're going to have problems" bits I was alluding to, but couldn't recall the details on Jul 19 15:10:56 Tartarus: Well, I don't think it acceptable to always require perl-native build to resolve this Jul 19 15:11:14 RP__: you're already there Jul 19 15:11:20 icon-theme-native has perlnative today Jul 19 15:11:47 This is just finishing up the job since we can't use #!/full/path/to/perl in scripts Jul 19 15:12:08 Tartarus: So what are you saying is the problem? Jul 19 15:12:21 I understand you need to change the env business Jul 19 15:12:40 RP__: Right. I'm saying that we need to add 'inherit perlnative' to recipes like sato-icon-theme Jul 19 15:12:49 which I'm guessing you wouldn't like Jul 19 15:12:53 So we're clearly not already there Jul 19 15:12:54 This will be clearer with the patch series Jul 19 15:13:00 and no I don't like it Jul 19 15:13:37 I'm open to ideas Jul 19 15:13:45 But 80 chars on shebang is the most you can expect Jul 19 15:13:46 and.. Jul 19 15:14:00 $ echo tmp/sysroots/x86_64-linux/usr/bin/perl-native/perl | wc -c Jul 19 15:14:00 51 Jul 19 15:14:08 doesn't leave much room to start building under Jul 19 15:14:46 add a perl-native redirector script? Jul 19 15:15:00 so env perl-native would work Jul 19 15:17:07 hm Jul 19 15:17:24 ok, i'll split things up nicely and then give that a try Jul 19 15:32:24 sgw: Should have another small series of obvious bits for your next go-round then Jul 19 15:32:49 Ok Jul 19 15:33:51 And, yeah, once these bits are done I'll rebase to something a bit more current and get back on the siteinfo train, ug Jul 19 16:21:10 dvhart: ping Jul 19 16:21:52 pong Jul 19 16:22:22 dvhart: do you use -directdisk images or -live images? Jul 19 16:22:28 -live Jul 19 16:22:31 dvhart: I assume -live Jul 19 16:22:33 -directdisk is broken Jul 19 16:23:00 is anyone using -directdisk or is it just plain broken, would they be used if fixed? Jul 19 16:25:43 sgw, the meego folks wanted it way back when - I don't see any sense in keeping it around Jul 19 16:26:03 sgw, something seems off with the dd usage - it seems to stomp on top of itself while generating images Jul 19 16:26:21 Ok, I am doing the live image work and wanted to simplify things, I will ask on the oe-core list also. Jul 19 16:26:23 sgw, clearly there aren't any current users :) Jul 19 16:26:33 good plan Jul 19 16:28:46 sgw: can I mark bugs 1180 and 962 as resolved? I don't know which revision fixed them but we have confirmation for each one from myself and one other person that the issues are no longer present Jul 19 16:31:37 bluelightning: sure, they can be mark resolved Jul 19 16:31:54 sgw: ok, thanks, just checking Jul 19 16:31:56 bluelightning: speaking of bugs, are you working on any of the QT related ones? Jul 19 16:32:12 sgw: haven't looked at any of them for a while no Jul 19 16:44:38 bluelightning: sorry stepped away, OK the WindRiver guys would like to look at them is it OK for me to reassign? Jul 19 16:45:04 sgw: no problem... some of the qt bugs were already assigned to other people fwiw Jul 19 16:45:32 right, there are a couple of yours. Jul 19 17:01:14 RP__: OK, I can't call the wrapper script perl-native since it lives in bindir with...perl-native Jul 19 17:01:37 and calling the dir perl-native-${PV} introduces a lot of un-fun in figuring out what perl version is, in cpan.bbclass Jul 19 17:01:51 ideas for the wrapper script name or new name of the perl native bin dir? Jul 19 17:02:56 Tartarus: nativeperl ? Jul 19 17:03:04 wrapper? ok Jul 19 17:03:24 Tartarus: I just looked at the unzip patch - I assume you're ok for me to remove the src_uri bit and then merge it? Jul 19 17:03:39 * RP__ replied via email but I'll do it now assuming you're ok with that Jul 19 17:04:15 Oh, I see Jul 19 17:04:16 yeah, sure Jul 19 17:05:01 RP__: any comments on this: http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=nitin/x32&id=6220e9316f6033364724b5d7a86917848dadf6be Jul 19 17:05:48 nitink: I have a dislike of adding more core variables like that :/ Jul 19 17:06:01 nitink: I'm not sure I see alternatives in this case though :/ Jul 19 17:06:17 RP__: any recommendations? Jul 19 17:06:47 nitink: I guess I'm left wondering how the other architectures can manage without these Jul 19 17:07:10 RP__: x32 is special, Jul 19 17:07:25 where linker, & assembler need special parameters Jul 19 17:07:25 nitink: compared to mips n32? Jul 19 17:07:52 IFAIU mips n32 is not supprted in yocto/oe Jul 19 17:08:11 nitink: but does that need different parameters to the assembler/linker? Jul 19 17:08:27 don't know, I can check gcc Jul 19 17:08:55 I mean liker & assembler Jul 19 17:10:16 RP__: btw it does not affect lots of recipes, only few recipes are affected Jul 19 17:10:58 nitink: I just worry as once these variables exist we have to then ensure every recipe is using them correctly Jul 19 17:11:10 nitink: and we have enough problems with CFLAGS and LDFLAGS atm :( Jul 19 17:12:22 RP__: these new vars would not need any recipe changes, these gets translated in other flags like CFLAGS, LDFLAGS for recipes Jul 19 17:13:15 RP__: The purpose of these changes is to avoid changing recipes Jul 19 17:20:40 nitink: true Jul 19 17:20:55 nitink: I'll probably take the patch after I think about it a bit more Jul 19 17:21:14 RP__: I am open for any recommendations. Jul 19 17:21:15 I find those variable names confusing too and the tune file changes might be a good time to fix that Jul 19 17:21:28 meanwhile I am looking at mips n32 Jul 19 17:21:37 Tartarus: I'm having second thoughts about this magic "lets add things to ASSUME_PROVIDED" changes Jul 19 17:22:02 Tartarus: On the grounds that we're no longer going to be as deterministic about builds Jul 19 17:22:28 Well, we aren't before this change Jul 19 17:22:33 I agree we need to take care Jul 19 17:22:57 But we've gone from "provide this, somehow" to "provide this somehow, or we'll make it" Jul 19 17:23:37 If we wanna be deterministic we'd need to be "always, we'll make it" Jul 19 17:24:42 Tartarus: well, before we always asked the user for it, now, the user's version could be used, or the version we provide could be Jul 19 17:25:00 * RP__ gets nervous about "or" situations Jul 19 17:25:26 We need to take care, I agree Jul 19 17:25:37 my assumption is we always provide, unless the user overrides us... Jul 19 17:26:13 git, hg and help2man are things I would expect a user to safely provide Jul 19 17:26:20 maybe with some version checks no git Jul 19 17:26:32 That's really the worst set to do that with Jul 19 17:26:44 I've got 0 of those in RHEL5 Jul 19 17:26:52 Unless I wander off into random-land Jul 19 17:26:57 Tartarus: well, I'm find with fall back to building then Jul 19 17:27:11 Tartarus: but I'm wondering about making the ASSUME_PROVIDED automatic Jul 19 17:27:12 RP__ I wouldn't expect a user to have hg.. Jul 19 17:27:18 AFAIK, nobody actually uses hg.. ;) Jul 19 17:27:23 hell I didn't even know it existed before OE Jul 19 17:27:36 fray: I mean that its easy to install on most sane distros Jul 19 17:27:38 git people need to have to do kernel development and such.. Jul 19 17:27:39 * darknighte laughs Jul 19 17:27:55 RP__: Well, I'm also ok with we build it every time unless the user adds to local.conf Jul 19 17:28:05 * fray notes he read the 'hg' propoganda and still went "uhh why?" Jul 19 17:28:08 But I'm really disliking the "make sure this is provided" position we have today Jul 19 17:28:18 Tartarus: I think we should go for that Jul 19 17:28:38 Tartarus: I'm fine with the building them position... Jul 19 17:29:13 ok, so I'll v3 things with add h2m-native, drop from required_utils Jul 19 17:29:14 I'd just like the user make a conscious choice to use the provided version Jul 19 17:29:18 Do you want a local.conf.sample addition? Jul 19 17:29:26 for our commercial products we have a small set (like 6 packages) that we need in order to do the equivalent of do_fetch and do_patch and such.. we provide the build scripts and the tarballs for those items so they never have to be downloaded.. (we also have a thing that says we can't download this.. you need to do it and place it here) Jul 19 17:29:29 Tartarus: sounds good Jul 19 17:29:47 * RP__ would ideally also like a sanity check on the git version if its in assume_provided Jul 19 17:30:12 someone seeing this http://pastebin.com/UygaeW85 Jul 19 17:30:18 Tartarus: sorry for the churn on this, I just want to get this right Jul 19 17:30:33 Yeah, no worries, I get it Jul 19 17:31:04 And about 95% there on a first pass at nativeperl wrapper Jul 19 17:31:07 * RP__ -> back shortly Jul 19 17:31:20 need iputils to build, then I'll check this in, start on v3 of the native bits and get a world build going Jul 19 17:34:31 dvhart: new machine is being set up now -- I can try compilation on an SSD, a spinny disk, or some combination of up to two disks of each (raid0 for instance) Jul 19 17:34:40 I'm also thinking of trying compilation in memory Jul 19 17:34:59 Doing that now as I get my gentoo system set up and it's, um, quite fast Jul 19 17:35:22 I assume there's a predictable location where the compilation happens Jul 19 17:37:03 jefferai, the compilation happens in the build directory that you specify when using the oe-init... script Jul 19 17:37:07 right Jul 19 17:37:17 jefferai, how much memory? Jul 19 17:37:18 but the results of that compilation is saved, right? Jul 19 17:37:25 or does it clean the package each time? Jul 19 17:37:30 I'd have 8GB available for tmpfs Jul 19 17:37:38 maybe more, but I've heard not to go above half Jul 19 17:37:42 it saves it unless you specify rmwork Jul 19 17:37:49 hm Jul 19 17:37:53 perhaps if I do that... Jul 19 17:37:55 jefferai, I suggest you talk with pidge about building from RAM Jul 19 17:38:06 pidge->jefferai jefferai-> pidge Jul 19 17:38:09 heh Jul 19 17:38:17 dvhart: just thinking in terms of running your bbmatrix Jul 19 17:38:19 * pidge waves hi to jefferai and backreads Jul 19 17:38:22 it'd be a nice result Jul 19 17:38:26 to post Jul 19 17:38:28 but, for that size system, I think you'll find RAID0 is the way to go Jul 19 17:38:35 jefferai, absolutely! Jul 19 17:38:44 yeah, you said raid-0 on spinny disks, which makes sense, sure Jul 19 17:38:51 I'd run 4-10 on each Jul 19 17:39:00 no point going past 10 on a 4 core IMO Jul 19 17:39:05 4-10 meaning number of jobs Jul 19 17:39:15 or number of threads Jul 19 17:39:17 especially given my and pidge's results on the 12 core Jul 19 17:39:19 or both Jul 19 17:39:22 yeah Jul 19 17:39:29 that's a future upgrade :-) Jul 19 17:39:30 jefferai, setting BB and PM ranges in bb_matrix Jul 19 17:39:45 right -- should I keep those numbers in lockstep then? Jul 19 17:39:47 04,05,06,07,08,09,10 Jul 19 17:39:54 for now Jul 19 17:39:56 okay Jul 19 17:40:02 as opposed to different values for each, is what I meant Jul 19 17:40:09 right Jul 19 17:40:14 for now I think that makes sense Jul 19 17:40:16 e.g. to take advantage of hyperthreading, for whatever that does/doesn't get you Jul 19 17:40:38 bb_matrix will run all combinations of 4-10 for BB and PM Jul 19 17:40:45 ah, ok Jul 19 17:40:55 that clears that up, then Jul 19 17:41:07 that will keep you box busy for...4 to 5 days Jul 19 17:41:14 :-) Jul 19 17:42:44 jefferai: I've tested in tmpfs. you need a lot of memory and the performance that we've measured so far isn't that much better (shaves like 10 minutes IIRC). Jul 19 17:43:04 Ah Jul 19 17:43:25 Ok, then, I'll test spinny disk raid-0 and ssd raid-0 Jul 19 17:43:43 although darren (probably rightly) believes that I won't saturate the spinny disk I/O Jul 19 17:43:51 so I'll do that first, and the ssd raid-0 if it seems relevant Jul 19 17:44:37 jefferai, while you're at it - we need a script to characterize a build machine Jul 19 17:44:48 Windows Customer Experience Jul 19 17:44:53 so that the results from bb-matrix.sh and others to follow can be the most useful Jul 19 17:45:06 jefferai, if it strikes your fancy, we'd love a patch :-) Jul 19 17:45:18 Why use our own script when we can piggyback on the excellent work of Microsoft in this regard Jul 19 17:45:25 ;) Jul 19 17:46:25 dvhart: I'll keep it in mind as I go along Jul 19 17:46:56 actually getting something useful in an automatic fashion is likely to be challenging Jul 19 17:47:00 especially if it's not being run as root Jul 19 17:47:05 which is probably the case Jul 19 17:47:20 obviously we're not going to be running e.g. bonnie++ Jul 19 17:47:52 and even the output from mdadm and hdparm and the like might require root access Jul 19 17:48:04 RP__: there are similar options to linker for n32 Jul 19 17:48:58 jefferai, obviously non-root is ideal - an optional collection with root access might be a good way to go Jul 19 17:49:47 yeah... Jul 19 17:50:22 dont run oe builds as root it can hose your system Jul 19 17:50:33 nitink, I think we're going to need tune specific assembler and linker flags at some point Jul 19 17:50:34 we do take care of not installing into / Jul 19 17:50:42 khem: no, just a collection part Jul 19 17:50:44 but there are always apps which dont agree with sysroot Jul 19 17:50:51 I'm surprised we don't have an insane check that you are NOT root Jul 19 17:51:14 fray: nitink: introducing more and more knobs would not be nice Jul 19 17:51:39 x32 is a multilib of x86_64 so why dont we solve it with multilib work Jul 19 17:51:59 infact x32 is same as n32 is for mips64 Jul 19 17:52:49 khem, fray, RP__: these knobs abstracts the common things for recipes in the machine conf Jul 19 17:53:08 khem: x32 & multilib will merge Jul 19 17:53:30 but x32 is not dependent on miltilib or vice versa Jul 19 17:53:51 why we have TARGET_CC_ARCH was sort of filling in for missing multilib but more importantly it was passing machine specific things Jul 19 17:54:12 and what this patch is doing is making its scope larger than that Jul 19 17:54:41 khem: I think multilib would use the TARGET_x_FLAGS too Jul 19 17:54:44 I think if we have multilibs then it should be just saying multilib = x32 or some sort and right toolchain options should be passed down Jul 19 17:55:21 ideally we should even get rid of TARGET_CC_ARCH Jul 19 17:55:21 khem: I guess that is what we will get after miltilib support is complete Jul 19 17:55:39 yes and your work on x32 ties to it Jul 19 17:55:55 I would say keep it up with the multilib work Jul 19 17:56:18 * khem looks for sgw Jul 19 17:57:42 khem: what's up? Jul 19 17:57:57 libiconv update Jul 19 17:58:06 I am getting license mismatch Jul 19 17:58:13 did I blow something up? Jul 19 17:58:27 hmm, I build with that change Jul 19 17:58:29 may be since this is pure oe-core Jul 19 17:58:32 no layers on top Jul 19 17:58:38 so I dont have any mirrors or anything Jul 19 17:58:56 http://pastebin.com/UygaeW85 Jul 19 17:58:58 let me check things out. Jul 19 17:59:15 and you moved the patches to files Jul 19 17:59:17 dir Jul 19 17:59:27 its better to keep them in ${PN} Jul 19 17:59:48 files is last resort when recipes with different names share the patches Jul 19 18:00:42 sharing patches also has a downside suppose you upgrade 1.13.1 to something newer and touch those patches then you have to test 1.11.1 too Jul 19 18:00:48 which hardly will change Jul 19 18:07:51 khem, right, I got bite by the virtual provider problem. So even in a world build libiconv was not actually built, I was doing world builds, so yes a license mismatch is my fault. Jul 19 18:10:08 sgw: you should also do uclibc builds Jul 19 18:10:12 then you will catch those Jul 19 18:10:56 hmm that patch for now should be reverted Jul 19 18:11:02 since the patches are not applying as well Jul 19 18:11:43 * sgw hangs my head in shame Jul 19 18:11:57 did u look into meta-oe ? Jul 19 18:12:08 there is a recipe for 1.13 in meta-oe too Jul 19 18:12:25 you could just import that into oe-core Jul 19 18:12:37 and meta-oe recipe could then be deleted Jul 19 18:13:05 khem, are you willing to take that one since you have better test setup for libiconv? Jul 19 18:13:26 ok I can do that Jul 19 18:13:46 for now lets just revert it Jul 19 18:13:57 is RP__ around ? Jul 19 18:13:58 khem: thanks, this does show a hole in my testing Jul 19 18:14:10 sgw: no worries happens Jul 19 18:14:31 sgw: you can run some TCLIBC=uclibc bitbake core-image-minimal tests Jul 19 18:14:52 it should start to work once my latest work goes into oe-core Jul 19 18:15:06 I will start to do that with your latest changes Jul 19 18:37:19 sgw: I just sent an update for libiconv stuff which should fix the issue Jul 19 18:37:36 Ok thanks Jul 19 18:37:57 I am working on the next Consolidated request now, will get that in with a uclibc test also Jul 19 18:54:20 RP__: do we boot core-image-sato on all arches Jul 19 18:54:29 RP__: I have so far tried on x86 Jul 19 18:54:33 and it seems to boot well Jul 19 18:54:38 but wanted to know Jul 19 18:54:54 qemu machines that is Jul 19 18:59:20 khem, it should yes Jul 19 19:00:48 RP__: Oh ya, review of the bit siteinfo.bbclass change? Jul 19 20:56:27 woot core-image-sato boots with uclibc/x86 too Jul 19 20:57:16 dates app does not start others seems to work fine Jul 19 20:58:39 khem, nice Jul 19 20:58:47 I'm a little surprised :) Jul 19 20:59:08 and its lot agile than eglibc based system somehow Jul 19 21:37:41 khem, as in more responsive Jul 19 21:37:43 ? Jul 19 21:40:01 yes Jul 19 21:40:14 gui seems to be zappier on my qemu :) Jul 19 21:41:02 thats not a surprise though in some case uclibc based systems do show performance Jul 19 21:41:20 I guess locales might be reason here Jul 19 21:45:06 Did you turn on the testsuite? :) Jul 19 22:17:41 Tartarus: nope, I was far from testsuite Jul 19 22:18:34 Tartarus: IMAGETEST = "qemu" in local.conf Jul 19 22:18:50 what else Jul 19 22:32:32 tps://wiki.yoctoproject.org/wiki/Enabling_Automation_Test_in_Poky Jul 19 22:32:36 hmm Jul 19 22:34:57 yeah, just that + expect installed Jul 19 22:35:00 and DISPLAY working Jul 19 22:35:08 it's not bad for xhosting even Jul 19 22:50:26 sgw: 85274.60user 22330.24system 4:18:40elapsed 693%CPU (0avgtext+0avgdata 8277632maxresident)k for world, here Jul 19 22:53:43 Tartarus: about the same what kind of machine and THREADS did you use Jul 19 22:54:26 it's a VM, 8core/12gb and 12threads, 16 parallel Jul 19 22:55:26 Intel(R) Xeon(R) CPU X6550 and bluearc storage **** ENDING LOGGING AT Wed Jul 20 02:59:57 2011