[00:00] <micahg> chrisccoulson: cool, I'm happy doing locally though as it allows me to test builds, but good to know in case I'm stuck on low BW
[00:01] <chrisccoulson> i shall be using it for the daily builds ;)
[00:01] <micahg> chrisccoulson: speaking of daily builds, would you be up for adding the crons for chromium to your build crons?
[00:02] <chrisccoulson> micahg, maybe once i've got the firefox builds going
[00:02] <chrisccoulson> in any case, i don't have access to the PPA's or branches anyway
[00:02] <chrisccoulson> so i can't do that
[00:02] <micahg> chrisccoulson: ok, I was thinking alternatively of switching to build recipes since it's svn based
[00:03] <chrisccoulson> ah, ok
[00:03] <micahg> chrisccoulson: yeah, I'll fix that soon, need to send an e-mail
[00:03] <chrisccoulson> i've been cloned now: https://launchpad.net/~chrisbot
[00:03] <micahg> but that's not happening until next week
[00:03]  * micahg is still in crisis mode
[00:03] <micahg> excellent...
[00:04] <chrisccoulson> thanks to robohash for the avatar :)
[00:04] <micahg> now we just need to train it to fix the build failures :)
[00:08] <chrisccoulson> ok, i have a good tarball again :)
[00:08] <chrisccoulson> now to make sure i delete the *correct* one this time
[00:08] <chrisccoulson> with the correct one being the broken one
[00:08] <chrisccoulson> now i'm confused ;)
[00:13] <chrisccoulson> micahg, m_conley bought up an interesting problem at the end of last week. how do we warn users before upgrading firefox or thunderbird that some of their extensions might not work afterwards?
[00:13] <chrisccoulson> the upstream updater checks this before offering an upgrade
[00:13] <chrisccoulson> and tells you if any of your extensions will stop working
[00:14] <chrisccoulson> i want to be able to do something similar from update-manager
[00:14] <micahg> chrisccoulson: we don't unfortunately, nor do I think we can, on first run, the new version checks for compatibility and warns if something won't work
[00:14] <chrisccoulson> we can :)
[00:15] <chrisccoulson> we can check the extensions that are installed and probe for updates ourselves
[00:15] <chrisccoulson> i'm sure i can write a tool which will do just that, which we could hook in to update-manager
[00:15] <micahg> updates aren't always needed
[00:16] <micahg> but I suppose you could make the calls to AMO for compatibility and display something nice
[00:16] <chrisccoulson> right, but there's no reason i can't do exactly the same thing that firefox does before offering an upgrade
[00:16] <chrisccoulson> yeah, that's what i was hinting at
[00:16] <chrisccoulson> i might start writing something this week to do that
[00:17] <micahg> cool, I think that will make users happy
[00:17] <chrisccoulson> yeah, it would be nice to have something like that
[00:17] <micahg> but I really don't like the idea of people not upgrading due to extensions breaking...
[08:05] <Ruedii> Does anyone know what the network.http.qos entry is in Firefox?
[15:34] <chrisccoulson> yay! all the builders came back :)
[20:16] <FernandoMiguel> evening
[20:22] <chrisccoulson> m_conley, when you listen for new messages on nsIMsgMailSession, does OnItemAdded fire before or after filters run on the new message?
[20:22] <chrisccoulson> eg, what happens if the spam filter marks it as spam, and it is moved to the junk folder?
[20:22] <m_conley> chrisccoulson: hm - good question.
[20:23] <m_conley> chrisccoulson: maybe ask bienvenu in #maildev?
[20:23] <chrisccoulson> m_conley, yeah, could do
[20:24] <chrisccoulson> ah, he's not there atm :/
[20:24] <m_conley> chrisccoulson: or Standard8.  I can't say I'm too familiar with the order of events wrt filters.
[20:25] <chrisccoulson> the only reason i mentioned it is because someone sent me an e-mail saying that the messaging menu notifies them of messages that get moved to their junk folder, from a POP account
[20:25] <chrisccoulson> and we're meant to ignore those
[20:25] <chrisccoulson> but the log he sent me suggests that we get an event before the message is marked as junk
[20:26] <chrisccoulson> but then he sent me another message saying the latest version seemed to fix it, but i'm not sure :/
[20:42] <m_conley> chrisccoulson: hrm
[20:43] <m_conley> chrisccoulson: I suppose we should wait to see if it *really* fixed it, which I somewhat doubt.
[20:43] <m_conley> chrisccoulson: while I have you, though, I was wondering if you knew the easiest way for me to get the debug symbols for libgio?
[20:44] <chrisccoulson> m_conley, this should help - https://wiki.ubuntu.com/DebuggingProgramCrash :)
[20:44] <m_conley> chrisccoulson: excellent, thank you. :)
[20:51] <chrisccoulson> m_conley, hmm, IIUC, it looks like filters are applied before we get notified
[20:51] <chrisccoulson> which is good :)
[20:51] <chrisccoulson> doesn't explain why it didn't work for this guy though :/
[20:52] <m_conley> hrm
[23:07] <FernandoMiguel> nite every1
[23:15] <spikebike> Anyone know if thunderbird on ubuntu uses the system wide SSL certs?
[23:15] <spikebike> i.e. /etc/ssh/certs
[23:15] <micahg> spikebike: yes, it does in the stable releases, I"ll be updating NSS and thunderbird soon
[23:16] <micahg> spikebike: err, it uses NSS, not ca-certificates
[23:16] <spikebike> ah
[23:16] <spikebike> ok, that's consistent with what I'm seeing
[23:16] <micahg> spikebike: are you concerned about the diginotar stuf?
[23:16] <spikebike> seems like University of California is standardizing on InCommon certs
[23:16] <spikebike> ah, no
[23:16] <micahg> ok
[23:17] <micahg> spikebike: we'll probably switch it to use internal NSS at some point
[23:17] <spikebike> InCommon has a komodo signed cert but I think the trust between the two is missing
[23:17] <spikebike> er comodo
[23:17] <micahg> spikebike: what release are you running?
[23:17] <spikebike> natty
[23:17] <micahg> ok, so the NSS version is a little behind and we're missing new roots
[23:18] <micahg> we'll probably update that soon
[23:18] <spikebike> https://spaces.internet2.edu/display/InCCollaborate/InCommon+Cert+Types
[23:18] <micahg> spikebike: does Firefox in natty have the root?
[23:18] <spikebike> that's the one that seems to be missing
[23:18] <spikebike> oh umm, checking
[23:19] <spikebike> is /etc/ssl/certs/mozilla certs that mozilla trusts?
[23:19] <spikebike> or certs that mozilla asked ubuntu to trust?
[23:20] <spikebike> firefox likes it, mostly anyways
[23:20] <micahg> hmm, that seems to have disappered in oneiric...
[23:20] <micahg> spikebike: ok, so the NSS update should fix it for thunderbird as well then
[23:21] <spikebike> it shows a blue bar, verified by internet2, but owner is listed as (unknown)
[23:21] <micahg> well, that's the specific site, not the cert listed on it
[23:22] <spikebike> yeah, not sure what field it's looking at though
[23:22] <micahg> spikebike: and that patch is maintained with ca-certificates which is another package that has certs in it, it gets periodic updates of the latest certs from NSS
[23:22] <spikebike> sounds promising
[23:22] <micahg> s/patch/path/
[23:23] <spikebike> thunderbird was rather unhappy with a similar InCommon cert, no matter what I did in /etc/ssl/certs it made me view and approve an exception
[23:23] <micahg> spikebike: yeah, thunderbird will ignore that path, you can import the cert in the thunderbird certificate manager
[23:24] <micahg> assuming you've verified it's authentic
[23:24] <spikebike> yeah, of course, and that's what I did... I was hoping to support a larger group of users though
[23:25] <spikebike> so google chrome and firefox like it, looks like thunderbird in natty doesn't
[23:28] <micahg> spikebike: the addtrust root seems to be in the latest versions
[23:28] <micahg> so, an NSS update should suffice
[23:30] <spikebike> cool
[23:30] <spikebike> I wish ssl was handled like dnssec
[23:30] <spikebike> just upload the equivalent of a DS record to your registrar
[23:30] <micahg> there are those discussing that


[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.  ;-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


[07:38] <brobostigon> morning boys and girls.
[07:50] <zmoylan-pi> o/
[07:58] <brobostigon> o/
[14:07] <HeavilyDressed> I ate a sandwich for the wedding - what you do other than Unity ? Oh wait .....
[14:09] <HeavilyDressed> No ?
[14:10] <HeavilyDressed> ah, Anyone see eurovision, then ?
[14:14] <HeavilyDressed> perhaps the colonial hat was a bit too much today.
[14:14] <HeavilyDressed> bye
[15:13] <ali1234> got to say... the android-studio snap works great. i installed it and made an app today and everything just worked.