=== jmp_ is now known as _jmp_ [01:05] jerusalem === jmp_ is now known as _jmp_ === smb` is now known as smb [07:21] * smb mornings [07:52] * apw yawns [07:52] apw, sync;sync;sync [07:53] reboot [07:53] oops [07:53] heh [08:13] bloody jetlag... [08:17] * dileks thinks if there where a hwclock.service for internal human clock [08:52] bug 985354 [08:52] Launchpad bug 985354 in ubiquity "Lubuntu 12.04 20120418 install fail" [Undecided,Confirmed] https://launchpad.net/bugs/985354 [08:56] cking_, did we decide to enable ALPM for Q ? [08:57] apw, it was not discussed, but it probably should be to see what fall out we hit === cking_ is now known as cking [09:05] Bryan Wu (1): [09:05] MAINTAINERS: add maintainer for LED subsystem [09:05] cooloney, congrats [10:50] * cking notes that there is only so much coffee the brain can handle to try to overcome jetlag [11:57] * ppisati -> goes looking for food [12:00] apw, hows it coming on collapsing generic and virtual ? [12:01] just looking at those patches now [12:02] apw, I promised the preempt guy that we'd add his flavour only if we could collapse virt and generic [12:02] tgardner, yeah ... we should add an item for that, then i can follow through when this is done [12:03] apw, to the blueprint ? [12:03] yeah [12:04] apw, I started the lts-backport-quantal branch in precise yesterday. still a bit of messing around to do. [12:04] tgardner, ok cool. do we have a PPA for that yet? [12:04] apw, not yet, thought I'd get the kernel building first. [12:05] i more meant have they decided where the combo ppa will land [12:05] apw, I think we can just use an existing PPA, can't we ? [12:05] we probabally want another team which holds it [12:05] as its gonna be for us and X [12:05] oh, right, forgot about X [12:06] we need to poke bryceh about what might work [12:06] apw, I'll hassle byrce when I've got it building [12:11] hi, issue with networking/suspend since kernel update. details: http://pastebin.com/VdMVRWQb anyone recognise the symptoms, or have an idea what to try next? [12:13] Gup, sounds like you have a known working and known not working kernel version, so get a bug filed and let us know the number, we would want to then to a bisect between the two to work out whats bust things [12:13] Gup, there is a page on doing bisects if you want to attempt it yourself [12:13] jsalisbury, can you point us to the bisect guide ? [12:14] i'll certainly file a bug. i'll have a look at the bisect guide and see what it involves [12:15] i tried to find a changelog to get an idea but it looked like it contained lots of changes that might have been the cause [12:15] Gup, probabally a stable update or similar [12:17] i'm not overly familiar with the kernel and its workings, i did compile one a couple of times, but thats been a few years [12:24] smb, ok you'll be pleased to know all of the patches in that intel-idle branch you pointed me to are now in mainline [12:24] smb, is this something we can test works ? [12:29] smb, with the quantal kernel, before i commit removing this thing :) [12:37] the link to the bisect guide on here is broken :s https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies [12:42] jsalisbury, you have been doing a number of these, would you be able to fix the docs :) [12:43] https://wiki.ubuntu.com/Kernel/KernelBisection [12:43] Gup, have you seend the above one ?? [12:44] ahha thanks apw, i hadn't found that yet, i will have a go [12:47] apw, I see that the hv folks are getting traction with the Debian kernel community [12:58] * tgardner bounces for quantal kernel backport to precise [13:01] hrmph, https://launchpadlibrarian.net/105081769/buildlog_ubuntu-quantal-amd64.linux_3.4.0-2.4_BUILDING.txt.gz [13:02] bah, https://launchpadlibrarian.net/105086088/buildlog_ubuntu-quantal-i386.linux_3.4.0-2.4_FAILEDTOBUILD.txt.gz [13:02] ogasawara, puny little buildds [13:04] ogasawara, I have a patch in master-next to fix the perf build problem [13:05] * ogasawara fetches [13:05] ogasawara, I thought the erro you were pointing at was because the buildd ran out of disk, but I see that its really a packaging error [13:06] tgardner: I was confused as why it would fail on i386 and not amd64, but seeing your patch explains it [13:06] ogasawara, it seems its a change from precise [13:07] ogasawara, I had at least one build trace that failed within the perf makefile, so I can only assume its a concurrency level issue. [13:26] apw, About those patches, I can confirm on intel and on my amd that it enables the cpufreq in xen. There were no bad effects. [13:27] smb, ok cool. so as all of them are in quantal things should be good. i'll clean up and get this merger in [13:27] To see whether it gains something, one needs to check performance [13:27] yeah not expecting it to be better, just not worse [13:28] In theory it should be better at least on intel as it should allow usage of turbo mode. [13:32] apw, I'll review and fix up the kernel bisection docs. [13:32] jsalisbury, thank [13:34] tgardner, ogasawara, Do you still want to have the top ten meeting today, since all the top ten bugs are currently precise bugs? [13:34] jsalisbury: anything new for precise on the list? [13:34] ogasawara, nothing yet, but I'm still catching up from pre-uds. [13:35] jsalisbury: if there's nothing new atm, we can probably skip it. just ping us if anything does pop up that need discussing [13:35] ogasawara, sounds good. Thanks. [13:41] jsalisbury, yeah, what she said. [13:42] tgardner, ack [13:47] apw: sorry for missing your msg [13:48] * cooloney is still in jetlag, [13:48] cooloney, heh, when i heard you had fun with a bird in SFO i assumed you would be off [13:50] apw: yeah, it's really fun. hah, we heard a very loud crashing noise in the air. [13:50] cooloney, man that must have been a fright and no mistake [13:50] cooloney: heh, I wouldn't call hearing a crashing noise while in flight "fun" [13:50] apw: after a while, pilot said our engine was hit by a bird. OMG, I just sat close to the engine [13:51] cooloney, shit, thats just the kind of noise you _never_ want to hear on a plane. [13:51] * apw bets that the engine does not enjoy eating birds [13:52] so we flew back to SFO. [13:53] i saw some dirty liquid in the engine when I was getting off the aircraft [13:53] so we had to stayed in SFO for one more night [13:56] cooloney, sounds awful. especially staying another night [13:57] apw: actually i was upgraded to economic comfort classed in first flight [13:58] apw: after a bird hitting, i had no chance to upgrade [13:58] double buggeration [13:59] ... another ass hurting... [14:01] smb: heh, any wiki or lp link for lxc stuff? i intend to try the testcase on my pandaboard. [14:02] cooloney, test cases, we do have test cases? ;-P [14:04] cooloney, But joke aside. I am not sure... [14:04] cooloney, hallyn is probabally the right person to talk to about how we are using it and so what to test [14:05] He and stgraber [14:06] For a quick test, I just installed the package, made sure the cgroup fs is mounted (which should be automatic now) and tried running some of the quick examples from the man page [14:07] cooloney: I'm in the middle of an update that i haven't tested yet, but lp:~serge-hallyn/+junk/lxc-test has my testcases [14:07] (high-level ones mostly, besides the reboot ones) [14:08] cooloney, There is also a chapter in the server guide https://help.ubuntu.com/12.04/serverguide/lxc.html [14:09] smb: yeah, i heard hallyn mentioned that during that lxc session. [14:09] hallyn: thanks for pointing out this. i will try that [14:10] and i believe arm server folks already run them on arm server [14:12] cooloney: yup, that's what ahs3 said. But thanks, the more people running it the better [14:12] i guess this means i better go test my changes :) [14:13] hallyn, cooloney soon will :) [14:13] heh, good point, on to my next work item :) [14:14] hallyn: sure, [14:14] * cooloney setting up pandaboard [14:14] j/k. i couldn't test at end of uds bc of bandwidth. need to try it out === yofel_ is now known as yofel [14:36] jsalisbury: did we pick kernel-kvm as the tag for fwded bugs? or kvm-kernel? :) [14:38] tyhicks: ping [14:38] tyhicks: can you please fix the work items for the ecryptfs blueprint? [14:38] tyhicks: it seems not to want to take my changes and it is messing up the work items ... sorry [14:38] herton, does shank-bot make bugs for linux-lowlatency ? [14:39] apw, no, just for our kernels at the moment [14:39] herton, are we doing linux-amardaxp ? [14:39] apw, yes [14:39] apw, we should be on next cycle, bjf added the code there [14:40] * apw notes lowlatency is lagging severely already ... [14:40] herton, bjf, cool stuff [14:40] apw, that's a "community" kernel is it not? [14:40] bjf, yes currently so, wondered if it would make sense to make bugs for them [14:41] apw, we don't for ports kernels either [14:41] bjf, there are no ports kernels which arn't in master are there? [14:41] apw, ah, true [14:42] so we may be being lucky there more than anything [14:42] gema: Hey - what changes would you like me to make? [14:42] * apw will chat to abogani about it, and maybe ask you again [14:42] apw, ack [14:42] bjf, btw, armadaxp lacks a entry for the meta-package on ubuntu.py. I was wondering also if we should make Ike the owner of prepare-package on workflow.py [14:42] abogani, your lowlatency kernel is lagging, who am i meant to poke about that, you ? [14:43] herton, for now ike is on the hook for everything armada related [14:43] apw, wasn't tgardner considering us picking up lowlatency (uds session) [14:43] bjf, preempt in Quantal [14:43] bjf, it may become portlike in Q yes [14:44] herton, yes, we should hadd the meta package. i thought there was a LP "team" that got assigned, that should be used [14:44] tgardner: you are correct as always [14:44] bjf, herton Just happened to notice that the vcs-git line of precise linux-meta refers to Karmic... Wonder whether fixing this should require a bug report and all the fun... [14:44] smb, lol [14:44] smb, you might file 'one bug' and use it for all the releases, cause i bet its wrong in all of them [14:44] bjf, I think the team thing never flied, I'm not sure Ike is on ubuntu-armel-kernel and watches it [14:45] * apw says stike ike on, he'll soon ask you to change it to a team once he starts drowning [14:45] apw, Likely at least between karmic and now... :) [14:45] herton, lets coordinate with ike. i want it to be a team and not a person [14:45] bjf, ok [14:46] bjf: +1 [14:46] herton, even if it's a team of one right now [14:46] * apw suggests we make a team with just vanhoof on it [14:46] bjf: we have a few teams now, would you like something trimmed down in size? [14:46] * vanhoof *hides* [14:46] yes, it's better being a team [14:47] * ogasawara back in 20 [14:51] bjf, herton opened bug 999726 for tracking [14:51] Launchpad bug 999726 in linux-meta "Fix Vcs-Git in linux-meta" [Undecided,New] https://launchpad.net/bugs/999726 [14:51] smb, ack and thanks [14:51] henrix: ^ [14:52] bjf: ack [14:52] bjf, Was just about to ask whether I should do something about it ... :) But this wfm2 [14:53] smb, nah, we'll take it [14:53] tyhicks: I reckon I probably didn't take notes in the modern work-item manner [14:53] tyhicks: apologies [14:53] tyhicks: behind on the times [14:53] * bjf will brb [14:53] hallyn, yes, kernel-kvm is the tag [14:54] * tgardner biab [14:54] thanks, written down :) [15:02] ogasawara, whould you like me to change "[TOPIC] Status: Precise Development Kernel (ogasawara)" to Quantal? [15:02] jsalisbury, makes sense [15:03] apw, sounds like a plan then [15:03] tell me we don't already have a meeting today ... yawn [15:04] apw, yup. Top Ten is canceled, but the IRC meeting is still on, for 17:00 UTC [15:04] good grief do we get no time off [15:05] heh === BenC__ is now known as BenC [15:15] * bjf is back [15:16] gema: I *think* that I fixed the work items according to the comment you left. Let me know if it still isn't right. [15:18] tgardner: was reviewing https://wiki.ubuntu.com/Kernel/Release/Rolling, the 14.04 section, should that be linux-image- will reference the current supported kernel, not linux-image-- ? [15:18] ogasawara, prolly [15:19] ogasawara, feel free to correct that [15:19] tgardner: ack [15:43] tyhicks: looks good to me, as long as you are sure you haven't lost any other task, I am happy [15:43] gema: I'll take a second look at the notification emails to ensure that nothing was lost. Thanks! [15:49] tyhicks: ack [15:49] (everything looks good) [15:49] * cking punches fwts json logging into submission === BenC__ is now known as BenC [16:20] O_o lucid pointing at karmic [16:22] smb: yeah, a couple of branches had that problem too :) [16:25] Somehow I would have understood them pointing at something earlier but forward is confusion [16:27] * henrix is confused... isn't karmic earlier than lucid? [16:28] err yes [16:29] * smb needs to get his letters right... [16:38] smb: btw, i tried to add lucid to the bug you filled... but couldn't figure out how to do that :-/ [16:40] henrix, No you cannot by bad design [16:40] smb: ah, cool! [16:40] henrix, its approved now [16:41] smb: thanks [16:42] hm, and to make this small thing really big, I probably should add the topic branch packages, too.. [16:44] henrix, Oh, but fsl-imx51 and mvl-dove not relevant anymore... [16:44] smb: yeah, i was not sure if all of them were relevant... so you can just NACK those two [16:46] henrix, yup, oh seems natty/ti-omap4 is pointing at maverick [16:50] ogasawara, i just did a test build and it failed with the same (i think) perf thing even with the top of master-next (inc tims fix) [16:51] install: cannot stat `/home/apw/build/ubuntu-quantal/ubuntu-quantal/debian/build/tools/tools/perf/perf': No such file or directory [16:51] apw: bah, my test build passed. [16:51] * ogasawara holds off on the upload [16:52] apw: that was indeed the same failure. were you using one of out build machines or something local? [16:52] ogasawara, that was a gomeisa build, doing a 'full_build=true' build to test dropping -virtual [16:52] henrix, Ok, I hope I have added all the tasks you would need for that bug [16:53] apw: I'll try to reproduce [16:53] apw, so wtf is going on with perf ? [16:53] smb: ok, cool. i missed the natty/ti-omap4, as i just grep'ed for karmic. i should have manually checked everything [16:53] well the base error says perf wasn't built, or it got removed before we made the package i guess [16:53] smb: will check them all again [16:53] apw, thats different then the intermediate failure [16:54] apw, how could it get removed? [16:54] tgardner, yeah and i think its what leann saw [16:54] henrix, topic-branch madness. Looks like all ti-omaps like maverick [16:54] tgardner, reading the logs now, hopefully i can see where it broke [16:55] smb: ok, i'll edit the bug description so that it's a little bit more generic [16:55] henrix, Cool, thanks [16:56] smb: i'll replace the "karmic" in the desc by something else [16:56] tgardner, ogasawara, ok it looks like when we build the indep version the manual build is now wacking it [16:57] rm -rf /home/apw/build/ubuntu-quantal/ubuntu-quantal/debian/build/tools [16:57] ... [16:57] Yeah, can now be Vcs-Git is wrong just about anywhere in linux-meta... :-P [16:57] make[1]: Leaving directory `/home/apw/build/ubuntu-quantal/ubuntu-quanta [16:57] l/debian/build/tools/tools/perf' [16:57] apw, hmm, wonder why ? [16:57] smb, you know, copy & paste everywhere :) [16:57] rm /home/apw/build/ubuntu-quantal/ubuntu-quantal/debian/build/tools/tools [16:57] install -s -m755 /home/apw/build/ubuntu-quantal/ubuntu-quantal/debian/build/tools/tools/perf/perf \ [16:58] so i think we build and prep the mans and the tools binaries in the same directory [16:58] so depending which order we do them depends on which we have to package [16:58] apw, that seemsl ike a bad thing [16:58] ** [16:58] ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting [16:58] ** [16:58] herton, sure. :) [16:58] tgardner, indeed it does [16:58] * apw pokes ... [17:00] tgardner, this has almost cirtainly come out of our paralellisation work, and likely in P we were just lucky [17:00] apw, it has been bugging me for awhile [17:01] it just hasn't happened enough to got to the top of my list [17:01] tgardner, its just wrong, we do two things which can be done in parallel on i386 on the same tmp dir... just working out which is easier to move [17:01] I'm surprised we were lucky all of Precise to not get hit by this [17:01] apw, seems simple in retrospect [17:01] ogasawara, -j1 on the buildds [17:01] ogasawara, i think we do more parallelism now that we did [17:02] apw, we could just serialize tools packaging. its not like it takes that long [17:04] tgardner, its not tools which need serializing, they need serialising wrt 'indep' in general, which isn't reasonable. they should be in differnet places [17:05] apw, which is gonna be a bit of churn. I think Leann is OK to upload given the buildds are at most -j2, don't you think ? [17:06] tgardner, it looks trivial to move the perarch indep, so i'd say give me an hour to work it and decide after [17:06] apw, ack [17:06] tgardner, the bid buildds are -j16 arn't they ? [17:06] apw, whats a bid buildd? [17:06] tgardner, big ... there are two which are monsters relativly speaking [17:07] apw, ah, didn't realize we had anything other then the -j1 xen instances [17:07] tgardner, oh is this going to a PPA, then yes [17:07] tgardner, in that case shove it in [17:07] apw, no, she's gonna upload it to the quantal archive [17:07] apw: I'm not uploading to a PPA [17:08] so it all depends on the buildd then that it hits [17:08] apw, we could clamp it to -j1 just for the buildds, but thats kind of a hack. [17:09] apw: I think we want the patch rather than rolling the dice on buildd's [17:10] apw: or we could have infinity or someone retry the current i386 build on a more susceptible buildd [17:11] yeah you could just put it back and see what happens [17:11] i think i have a fix so will go test build it to confir [17:15] tgardner, ogasawara, we may be simply hitting it more on quantal cause of a make change for instance === jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues May 22nd, 2012 - 17:00 UTC || If you have a question just ask, and do wait around for an answer! [17:15] apw, its certainly been annoying me more of late [17:18] tgardner, we have be going more and more parallel and releasing the bits which stop it going fast, so we should be hitting it more really [17:18] apw, indeed, that is my empiracal experience [17:19] tgardner, and possibly depending how you build it you could make it happen, i think the act of building it with dpkg-build package, the make build-foo; fakeroot make foo; ought to near guarentee it happens i think [17:19] well i suspect we either lose the binaries or the manuals, but the manuals we don't install by name we just take * so we'lll only notice one way round perhaps [17:20] bjf, just pushed some cruft onto ubuntu-precise-meta master. please review prior to uploading. [17:23] tgardner, ack [17:23] henrix, herton ^ [17:23] ack [17:24] bjf: ack [17:24] Hi, I'm trying to implement "syscall" and having trouble. My code looks like this: http://cl.ly/3Q2n12113a2X3737191R [17:25] It always returns -1. [17:25] tgardner, that seems to only refer to generic and server, but we have generic-pae on i386 and only that right ? [17:25] * henrix will be back in ~30mins [17:26] apw, since its a meta package its abstracted by one level. it should refer to -pae in i386 [17:26] cking: https://chrome.google.com/webstore/detail/bcjindcccaagfpapjjmafapmmgkkhgoa [17:26] tgardner, plus there are only linux-image ... shouldn't there be linux-headers-* as well [17:27] apw, not sure if we wanna propogate that level of complexity, do we ? do we need the headers ? [17:27] bjf, I'm using: http://jsoneditor.net/ [17:27] tgardner, anyone needing dkms needs a meta package for their headers [17:28] tgardner, so either make them linux-hwe- and dep on both headers and image, or you need both me thinks [17:28] apw, they can always reference the header meta-package directly. I don't think we should support automatic dkms upgrades from release to release. [17:29] tgardner, but then they update their kernel automatically and any dkms they have just stops building even if its compatible [17:29] I think dkms is guaranteed to break. look at nVidia. [17:30] tgardner, well we should be testing those before we inject the new kernels if they are supported if thats going to be the only kernel in a while [17:30] tgardner, especially for binary drivers for graphics [17:30] as those are no longer opting in really are they, they are getting updated [17:32] apw, well, I guess I'm OK with depending on the headers from the -hwe- and -current- meta packages. I just didn't want the combinatorial explosion. [17:32] we might want to take out 'image' to make it clear if we do that [17:33] apw, yeah, I'll update it in a bit. need fuud first === tgardner is now known as tgardner-lunch === tgardner-lunch is now known as tgardner [17:54] tgardner-lunch, i can see why my builds never see this normally as i build the indep and dep parts separatly always [17:57] ogasawara, have you been able to reproduce the perf thing locally, you would have to build 'binary' to see it i think ... as it requires a perarch and an indep run to be in parallel [17:57] ogasawara, anyhow if you are, i have a patch which seems to resolve it ... shall i shove it [17:57] apw: go ahead and shove it. I have not been able to reproduce yet [17:58] yeah, its kind of tweaky [17:58] building binary-gneeric will never show it, nor will indep, but for me a binary always tiggers it at -j256 [17:59] apw: lemme try that. In the mean time I did kick off a re-build for i386. It landed on aatxe. [17:59] ogasawara, ok pushed. [18:00] apw: I'll clean up the tree since I never did officially upload 3.4.0-2.5 [18:00] ogasawara, i also have an overlayfs.v13 update pending, but don't want to throw that in if you are struggling to build [18:01] apw: ack [18:11] apw, repushed ubuntu-precise-meta [18:13] tgardner, so i wonder if the package is going to bring image and headers should it be just linux-hwe-generic [18:13] as 1) its different and 2) if we ever do need them separate for some reason, like for the CDs we have space to put them [18:13] apw, ah, forgot that. will fix. [18:14] apw, fixed [18:15] now I need to fix the descriptons as well [18:16] tgardner, i wonder if the linux-generic references should be linux-image-generic [18:16] apw, why? [18:16] tgardner, we were talking aboue making linux-gneeric be both perhaps, or removing them, so it might be nice to miss the double indirect [18:16] tgardner, either way right now they are just a double indirect, do we want that [18:17] it seems simpler form a conceptual viewpoint, but its really 6 of one, half dozen of another [18:17] ie we'd have linux-hwe-generic -> linux-generic -> linux-image-generic -> linux-image-xxxx-generic [18:18] and linux-hew-generic seems same as linux-generic in the hierachy, so perhaps we should point to l-i-generic [18:18] matters not much at this point as its not affecting any new names or anything [18:28] apw, ok, repushed again [18:29] tgardner, so the only thing i find confusing now is that we have -generic and not -generic-pae at the top level for i386 [18:29] apw, you mean linux-hwe-generic ? [18:30] yeah i'd expect that to be amd64 specific i think, and have a -pae i386 specific [18:31] apw, I think -pae will disappear on our way to 14.04. this is supposed to be an abstract meta-package name [18:32] apw, frankly, I;d like to change Quantal so that -pae disappears [18:32] tgardner, i almost want to it be -desktop and -server or something, but thats probabally reaching bikeshedding [18:33] apw, quantal should have _just_ a generic flavour (that also happens to be the PAE kernel) [18:33] then we've homogonized across i386 and amd64 [18:33] yeah makes sense, and we should do that rsn [18:33] apw, I can make that happen :) [18:34] tgardner, it will conflict heavily with my -virtual work, so perhaps i should do it on top of that [18:34] as soon as ogasawara is done faffing about [18:35] apw, when you do that, remember to go back and fix ubuntu-precise-meta lts-backport-quantal [18:35] ACK [18:36] and ubuntu-precise lts-backport-quantal [18:36] tgardner, *cough* lts-hwe-12.10 surely [18:36] apw, its a branch name [18:36] who cares [18:37] :) [18:50] apw, am wondering, given your builddirpa patch, if perf build really is parallel safe. [18:58] tgardner, it may well be, i have not tested it reverting your change to -j1 yet [18:58] i figured you'd probabally re-test once this upload was up and we could revert [18:59] apw, yep. I'm backporting it to older releases, so it'll get some good testing. tangerine is gonna get worked [19:02] tgardner, i assume the issue is somewhere back to O in theory, not really sure why we've never noticed before [19:02] tgardner, so you are doing the backport for the tools build bit yes ? [19:02] apw, dunno, but it is pretty racy [19:02] apw, yep [19:03] then i can crack a beer and let these virtuals build [19:03] thats common all the way back to lucid [19:03] la la la ... [19:03] apw, I'm also thinking this is bogus: install-tools: install-source $(stampdir)/stamp-build-perarch [19:04] there are two linkages there, install-source to get source done at all, and stamp-* to build the perarch tools [19:05] i think its odd but right, the build-arch (ish) which has install-tools on it, should have install-source i think, but i'd be less keen to fix that back to L [19:05] apw, its the stamp-build-perarch dependency that is unorthogonal [19:06] ahh ... we wen't through that phase of getting rid of the direct build-xxx things forgetting that they were used to allow make build-foo; fakeroot make foo [19:07] tgardner, so it should be build-tools and build-tools: stamp-* with the @; to make make happy thing we see elsewhere ... probabally [19:07] but we optimised a number out, that was inserted after that optimisaiton [19:08] apw, yeah, lemme noodle on it for awhile. you go have a beer. [19:08] ogasawara, i've done two test builds with that perf fix 'full_build=true' stylee on gomeisa and no problems, i was 2/2 bad before [19:08] apw: I just reproduced here as well w/o the patch, am going to redo with it. assuming it's successful I'm going to upload. [19:09] apw: I've pushed the proposed upload to master-next [19:09] ogasawara, nice ... fingers crossed, its pretty blatently wrong [19:10] apw: the re-build for i386 on the buildd failed with the same error [19:57] * tgardner -> EOD