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