=== mmrazik is now known as mmrazik|otp
=== mmrazik|otp is now known as mmrazik
=== yofel_ is now known as yofel
=== henrix_ is now known as henrix
[10:17] <jamespage> how are the packages associated with each team defined for the reports @ http://reqorts.qa.ubuntu.com/reports/rls-mgr/
[10:17] <jamespage> ?
[10:18] <jamespage> the server team are currently using this with another report and I'd like to consolidate on the official release management report
[10:18] <jamespage> but I think the list of packages needs to be expanded.
[10:25] <xnox> jamespage: if i remember correctly, bdmurray maintains package mapping in those reports.
[10:25] <infinity> Is it not just based on bug subscriptions?
[10:25] <infinity> If it isn't it probably should be, and those should be cleaned up.
[10:25] <infinity> Maintaining parallel lists is silly.
[10:26] <Daviey> Hmm.. it was maintained via a *spreadsheet*.. That might not still be the case.
[10:27] <Daviey> Ursula and brad would be good contacts for that, i think.
[10:27] <infinity> Daviey: I'm not arguing that it might not be in a spreadsheet currently, just that it shouldn't be. :P
[10:28] <infinity> We demand bug subscriptions when we do MIRs and such, we really should just formalise that as the one canonical place for team blame.
[10:28] <Laney> I think there was a BP to stop using the spreadsheet and do something else
[10:28] <Laney> which is the part bdmurray was working on
[10:28] <Daviey> well, that doesn't have a single poc when there are multiple subscriptions.
[10:29] <infinity> (And before anyone mentions that more than one team can subscribe to a package and then bugs would show pu twice in the report, tell me how that's bad that two teams would care?)
[10:29] <Laney> https://blueprints.launchpad.net/launchpad/+spec/other-p-package-mapping
[10:32] <Daviey> infinity: It's bad, in the situation that both teams think the other will deal with it.  Which has happend :)
[10:33] <Daviey> So having a single contact for the tracking/triaging, even if not the team solving it.. Is a good way IMO
[10:33] <infinity> Daviey: One could short the reports to only display for one team once it's been assigned to a member of that team.
[10:33] <infinity> Daviey: But I think the default assumption when unassigned should be "no one's looked at it yet".
[10:34] <infinity> Daviey: Besides, it seems a bit weird for people to use the reports to find bugs they shouldn't be working on, rather than the inverse.  Look at your own section, silly. :P
[10:34] <Daviey> hah
=== mmrazik is now known as mmrazik|lunch
[11:21] <cjwatson> I've disabled precise daily builds in preparation for 12.04.2
[11:21] <cjwatson> infinity,plars: ^-
[11:26] <infinity> cjwatson: Shiny.
=== mmrazik|lunch is now known as mmrazik
[12:03] <jamespage> xnox: thanks (and to *all for the general conversation - felt more difficult that is should have been)
[12:04] <xnox> jamespage: if we were in bdmurray timezone it should have been more simple =)
[12:30] <Riddell> ok I give up, how does xserver lts-quantal bits get on the precise CDs?  I don't see a seed change and I don't see it in the germinate output
[12:30] <Riddell> but it's there in the ubuntu desktop manifest
[12:31] <jamespage> xnox: indeed
[12:32] <infinity> Riddell: livecd-rootfs magic.  Is this about the alternate CD bug?  I'm going to fix that today.
[12:32] <infinity> Riddell: Or, at least, attempt to.  We'll see how it goes.
[12:33] <Riddell> infinity: I'm wondering what to do to get it on the kubuntu 12.04.2 candidate images
[12:33] <ogra_> btw, someone asked about documentation if you want to opt-in to the -lts package stack ... do we have any wikipage or so ?
[12:33] <infinity> Riddell: Oh, you didn't sign up for it earlier?  Indeed you didn't.
[12:34] <Riddell> ogra_: talking to me?
[12:34] <infinity> Riddell: ScottK may have opted out in earlier discussions.  Perhaps you two should quickly agree on that point before we go emergency SRUing livecd-rootfs.
[12:34] <infinity> ogra_: A wiki page for what?  For flavours, or users?
[12:34] <ogra_> Riddell, to the room, or anyone involved with the -lts stack
[12:35] <infinity> ogra_: Users can only opt in or out by either picking old/new install media, or manually changing packages.
[12:35] <ogra_> infinity, well, my 12.04 wont automatically upgrade to the -lts packages
[12:35] <infinity> ogra_: flavours were meant to opt in weeks ago, so we could make the right changes. :P
[12:35] <infinity> ogra_: No, upgrades won't.  And there's no reason they should.
[12:35] <ogra_> if i want the new stack, is there a meta or so i can install ?
[12:35] <infinity> ogra_: The whole point was hardware enablement.  If your hardware works, why upgrade the stack?
[12:35] <ogra_> because my steam games might run faster for example
[12:36] <ogra_> with newer driver and kernel
[12:36] <infinity> ogra_: You can install "xserver-xorg-lts-quantal linux-generic-lts-quantal" and you're there.
[12:36] <cjwatson> Riddell: sorry, you'll have to revert, there isn't time now to get the new stacks in
[12:36] <ogra_> infinity, rifght, *i* know that .... but there was someone asking of there is any documentation
[12:36] <Riddell> ok, c'est la vie
[12:36] <cjwatson> unless your images are broken without the new stacks
[12:36] <cjwatson> in which case an emergency SRU is probably possible ...
[12:37] <infinity> Given it's a straight cargo-cult from the other flavours, an emergency SRU is pretty low risk.
[12:37]  * ogra_ is just playing cassandra here 
[12:37] <cjwatson> well
[12:37] <cjwatson> I guess I don't mind terribly, but do try to get all the pieces
[12:38] <cjwatson> which I don't think Riddell's seed commit did
[12:38] <cjwatson> ship-live: * linux-headers-generic-pae [i386] # Make sure we get the right headers
[12:38] <infinity> Riddell: Talk it over with ScottK.  If you both feel pretty strongly about it, we'll talk.
[12:38] <cjwatson> (that should probably be removed rather than substituted)
[12:38] <infinity> cjwatson: Where's that commit?
[12:38] <cjwatson> kubuntu.precise seeds
[12:38] <infinity> Or, derp.
[12:39] <infinity> But yes, headers shouldn't be there at all.
[12:39] <cjwatson> it needs at least also (a) livecd-rootfs SRU (b) extend the thing in debian-cd/CONF.sh that sets BACKPORT_KERNEL=quantal
[12:40] <infinity> Plus the bits I'm about to change for seeds/debian-cd love.
[12:40] <cjwatson> (c) lib/cdimage/livefs.py search for quantal
[12:40] <cjwatson> [generic vs. generic-pae]
[12:42] <cjwatson> and it will involve switching Kubuntu over to metapackages in livecd-rootfs at the last minute, which means you need to do a test build, compare the resulting package lists, and add hacks for anything that gets added that shouldn't have been added (i.e. what I did for Ubuntu and Edubuntu)
[12:43] <cjwatson> (the "libqt4-sql-sqlite notify-osd" bit)
[12:43] <cjwatson> and you arguably ought to avoid adding SB support at the same time since all this is complicated enough
[12:44] <cjwatson> there are enough moving parts - and I'm not absolutely certain I've remembered everything - that I really recommend against doing this at the last minute; it might be better to do a proper job, including SB, for .3?
[12:44] <cjwatson> infinity: the metapackage hacks are why this isn't a straight cargo-cult
[12:46] <infinity> cjwatson: Yeah, I agree it looks hairy as a last-minute thing.  Deferring to .3 is certainly less pressure.  Though, we should probably do it immediately post-.2, so no one forgets until the next last-minute.
[12:47] <cjwatson> ... for all flavours, consistently
[12:48] <cjwatson> (which probably means getting consent from everyone nowish - which is why I didn't do it originally, I think I asked some set of people and fixed things up for the ones who responded)
[12:48] <cjwatson> (and being in a tearing hurry)
[12:48] <Riddell> ok let's stick with the old stack for kubuntu 12.04.2
[12:49] <cjwatson> sorry, I know this is basically my screwup
[12:49] <Riddell> could someone respin the image to get rid of the linux change I made (I just reverted seed)
[12:50] <infinity> Riddell: Will do.
=== Ursinha-afk is now known as Ursinha
[14:05] <Riddell> infinity: new kubuntu 12.04.2 candidates on their way?
[14:08] <infinity> Riddell: Yeah, I just need to hit enter in this terminal.  Wanted to make sure the world settled.
[14:08] <infinity> Riddell: Building now.
[14:08] <Riddell> thanks
[14:19]  * ScottK didn't opt out of anything.
[14:20] <infinity> ScottK: No, you may have just failed to opt in.  I could have sworn you were around and speaking up about it when we were discussing it in the channel with other flavours, but maybe not. :/
[14:20] <ScottK> Not that I recall.
[14:20] <infinity> ScottK: The backport stack stuff was all rather haphazardly organised, I'm afraid.
[14:20] <infinity> For .3, we should just make sure both the backport stack and SB is just universally enabled and be done with it.
[14:21] <infinity> (And soon after .2, so new dailies DTRT)
[14:22] <ScottK> Makes sense.
[15:14] <plars> cjwatson: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1122072 seems to be a regression for 12.04.1
[15:14] <ubot2> Ubuntu bug 1122072 in xorg (Ubuntu) "[Precise amd64 on VirtualBox] "Fatal server error: no screen found" in Xorg.0.log" [Undecided,Confirmed]
[15:23] <plars> cjwatson: alternate images seem to be oversized at the moment?
[15:29] <infinity> plars: Alternate images are being worked on for other reasons, we'll see where we end up.
[15:30] <plars> infinity: what else is being worked on with them?
[15:31] <infinity> plars: Making them use the enablement stack...
=== henrix is now known as henrix_
=== henrix_ is now known as henrix
[15:54] <bdmurray> jamespage: We are still using the spreadsheet but are planning on moving away from it
[15:55] <infinity> bdmurray: Planning to move to what, out of curiosity?
[15:55] <ogra_> a more shiny spreadsheed with colors
[15:55] <ogra_> :P
[15:56] <bdmurray> infinity: launchpad team subscriptions to packages
[15:57] <infinity> bdmurray: Ahh, good, exactly what I suggested above.
[15:57] <infinity> bdmurray: I appreciate when people have the same idea as me, spares a whole lot of time trying to convince them they're wrong.  *nod*
[15:58] <bdmurray> infinity: Well, I'm certain you heard me talk about on the train in Copenhagen and that it was my idea first. ;-)
[15:58] <jamespage> bdmurray: can i review/get that spreadsheet updated please?
[15:58] <infinity> bdmurray: Crazy talk.  That implies I listen to other people.
[16:00] <bdmurray> jamespage: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AhTVBLlLWapNdHRpM2QyRGQ5NGFzZmF3ODNpZ2E3d1E&authkey=CJzt1xo#gid=0
[16:02] <infinity> bdmurray: Not public readable?  Classy. :)
[16:06] <rtg__> infinity, what do you suggest for libaudit-dev in Precise with regard to the Raring LTS kernel ? just don't build perf ?
[16:10] <infinity> rtg__: Yeah.
[16:10] <rtg__> my thoughts exactly
[16:10] <infinity> rtg__: Unless you want to go to the hassle of tearing out whatever bits of perf reference libaudit.
[16:11] <rtg__> ick
[16:11] <rtg__> guess I could take a look
[16:13] <infinity> rtg__: Probably not worth the effort unless it's a dead simple case of removing the header include and a few function calls.
[16:13] <rtg__> infinity, maybe NO_LIBAUDIT in the Makefile will help. I'll keep digging
[16:14] <infinity> linux-tools so needs to grow a proper configure.
[16:15] <infinity> Actually, wait, I thought it had one?
[16:15] <infinity> It spews bits about disabling things if GTK isn't there, etc.
[16:15] <infinity> So, maybe the configure just needs to be smarter about audit. :P
[16:15] <infinity> Or, we could just not care.
[16:15] <rtg__> I'm leaning that direction.
[16:16] <infinity> rtg__: perf is a pretty awesomely useful debugging tool, but I suppose it's more interesting in an active development release than an LTS.  Maybe.
[16:17] <rtg__> infinity, I know cking has used it on older releases for a variety of profiling researches
[16:21] <infinity> rtg__: There's you answer.  Punt to cking.  If he cares, he'll fix it to build without audit and submit the patch upstream. ;)
[16:21] <rtg__> infinity, yeah, he'll punt it back to me.
=== Mirv_ is now known as Mirv
=== henrix is now known as henrix_
=== henrix_ is now known as henrix
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
[17:49] <antarus> infinity: do you have the src for that kernel pruner thing we talked about on Friday?
[17:50] <infinity> antarus: I'll upload it today and point you at it.
[17:50] <infinity> antarus: (Or you could check raring, but if you're looking for it backported to precise, no point doing the work twice)
[18:02] <antarus> infinity: whats the pkg name in raring?
[18:03] <infinity> antarus: apt.  You've probably heard of it.
[18:04] <antarus> heh
[18:04] <antarus> I'll poke at it then ;0
[18:04] <infinity> Heh.  I'll backport the relevant commits this afternoon.
[18:18] <antarus> infinity: is there a launchpad bug for the backport?
[18:19] <infinity> https://bugs.launchpad.net/ubuntu/+source/apt/+bug/923876
[18:19] <ubot2> Ubuntu bug 923876 in apt (Ubuntu Quantal) "FR: Limit and clean-up kernel images and headers automatically in LTS" [High,New]
[18:20]  * infinity sets that to In Progress, and gets progressing on it.
[18:22] <antarus> thx
=== rtg__ is now known as tgardner
=== tgardner is now known as rtg__
=== TheDrums_ is now known as TheDrums
=== scott-work_ is now known as scott-work
=== jbicha_ is now known as jbicha
[20:27] <balloons> It's been mentioned there's no upgrade test for 12.04.2 -- is this intentional? Did we simply not include it in the rollout?
[20:28] <stgraber> those need to be manually added as they're not pushed by nusakan
[20:30] <balloons> stgraber, ohh.. I do remember that now
[20:30] <balloons> ok,  I was holding off because I thought there was a reason
[20:31]  * balloons goes to add
[20:32] <stgraber> balloons: for dailies I have a script bumping the version every week, but I'm not doing that for milestones
[20:32] <balloons> hmm.. precise stll has the legacy stuff on it
[20:33] <balloons> that makes it tricky too
[20:34] <balloons> ohh ugh
[20:35] <balloons> how did I not notice these were all linking to the old legacy testcases
[20:38] <balloons> stgraber, well, since we're already chatting in here.. If I change and update the testcase links for everything, we re-write history and lose all of our old results, right?
[20:38] <stgraber> yep, precise doesn't have the shiny new testcases
[20:38] <balloons> but if we don't change the, we're stuck using the old stuff
[20:38] <balloons> which actually has broken testcases at this point?
[20:39] <stgraber> balloons: I haven't looked at the code in a while but I "think" accessing archived records should be fine even if you change the testsuites/testcases for precise
[20:39] <stgraber> might be worth testing with just a product to check though
[20:39] <stgraber> I don't keep an explicit history for those but results are linked to build and testcase
[20:39] <balloons> stgraber, well, if possible, we should get precise updated to the new stuff
[20:40] <balloons> I remember we avoided converting for simplicty
[20:40] <stgraber> so if I did it correctly, accessing an older build should still show you the old testcases and results
[20:40] <balloons> but since precise is going to keep coming up..
[20:40] <stgraber> balloons: can you convert let's say, Edubuntu amd64 and then let me know so I can check?
[20:40] <stgraber> balloons: I happen to know the testcaseid for Edubuntu by heart so if it ends up messing the history I can easily revert
[20:40] <balloons> stgraber, yes, I'll do that.. I'll remove the legacy links and put in the proper ones
[20:42] <stgraber> balloons: ok, let me know when you're done
[20:44] <balloons> stgraber, k, done
[20:44] <balloons> mm.. we lost today's results ofc
[20:44] <stgraber> balloons: alright, let me take a look at the history
=== Noskcaj is now known as Noskcaj_AFK
[20:45] <stgraber> balloons: history's broken. Let me poke at it for a bit see if we can get that working with some configuration
[20:50] <stgraber> balloons: ok, that doesn't work :( I thought I had written some code to detect cases where we had results for testcases and testsuites not currently linked to a product, but apparently I either didn't do that or the code is broken
[20:51] <balloons> hmm.. well, so where does that leave us?.
[20:54] <stgraber> nowhere particularly good, we don't have enough time for me to fix the code and land it and if we simply go ahead with swapping the testsuites and then land the fix post-release, it means we won't be able to access the results from any of the dailies which may be relevant
=== henrix is now known as henrix_
[21:04] <balloons> stgraber, right.. so, I guess we continue as-is then.. I wonder if I can even change the upgrade tests
[21:04] <balloons> I guess not
[21:08] <stgraber> probably not and they'd end up being wrong if you did as they need extra testcases for LTS-to-LTS
[21:11] <balloons> well, as you ca see I simply turned on the existing upgrade builds, with the old testcases
[21:11] <balloons> thanks stgraber
=== doko_ is now known as doko
[21:16] <balloons> stgraber, ohh.. since this will come up again, can we at least note it in the bug tracker.. whenever you have time to open and proper bug with description.. I'd prefer you to do it since you can describe the technical limitations better
[21:26] <stgraber> balloons: yep, I'll file a bug and get that fixed soon
[22:39] <knome> release team (ping micahg_): the xubuntu team wishes to move to a 1GB image; do you need something from us or will you process?
[22:41] <stgraber> it's actually a ping for the cdimage team :)
[22:41] <stgraber> but yeah, I can bump the limit for you
[22:42] <infinity> I was already there.
[22:42] <stgraber> infinity: if you remember where it's, go ahead ;)
[22:43] <stgraber> infinity: I vaguely remember cjwatson moving those bits to python so I was preparing to do some grepping around
[22:44] <infinity> stgraber: Already done.
[22:45] <infinity> knome: ^
[22:45] <knome> infinity, cheers!
[22:46] <knome> and thanks for stgraber too ;)
[22:48]  * ogra_ doesnt get why the nexus7 build failed
[22:48] <ogra_> the log doesnt show any errors
[22:48] <ogra_> yet i got a failure mail
[22:48] <infinity> ogra_: When?
[22:49] <ogra_> 1.5h ago
[22:49] <ogra_> which is weird, the build should have finished several hours ago
[22:49] <ogra_> (it starts at 13:30 UTC or so)
[22:49] <infinity> ogra_: I'm fiddling with some things, let me try again.
[22:49] <ogra_> oh, err
[22:50] <ogra_> thatt mail was from the 10th
[22:50] <ogra_> LiveFS ubuntu-nexus7/raring/armhf+nexus7 failed to build on 20130210
[22:50] <infinity> Oh, that was probably when the world was half exploded.
[22:50] <ogra_> seems todays worked
[22:50] <infinity> Anyhow, testing things now.
[22:50] <infinity> Today's would have been on cadejo, the one I'm doing now will be on celbalrai.
[22:51] <ogra_> still strange that nusakan held back the mail for 24h
[22:52] <ogra_> hmm, evolution, the chromebook and livefs build logs go better together than my high end x86 desktop
[22:52] <ogra_> (on my desktop evo crashes if i scroll to fast)
[22:55] <antarus> chromebook++
[22:55] <ogra_> yeah
[22:56] <ogra_> its soo ugly, but works so well :)
[22:57] <ogra_> (and properly working flash on ubuntu-arm is actually priceless)
=== robbiew is now known as robbiew-afk
[23:25] <plars> sorry for the vagueness in this bug, but https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/1122525 is blocking from testing ltsp on alternate. Also, shouldn't precise alternate images have apport in them? ubuntu-bug and apport don't seem to work there but it looks like it did at one time.
[23:25] <ubot2> Ubuntu bug 1122525 in ltsp (Ubuntu) " ltsp-build-client build ltsp chroot failed : Unable to locate package linux-image-generic" [Undecided,New]
[23:26] <plars> it's virtually identical to an older bug that was fixed by stgraber, so hopefully the breakage should be clear
[23:27] <plars> infinity: or is this related to the problem you mentioned earlier?
[23:34] <infinity> plars: The ltsp bug is related to the lts backport stack, but not the thing I was fixing. :/
[23:34] <infinity> stgraber: ^
[23:35] <plars> infinity: I'll cc him on the bug
[23:35] <infinity> stgraber: Looks like ltsp in .2 wants to be installing the lts-quantal kernel instead of -generic, if it's relying on the CD for its packages...
[23:37] <stgraber> infinity: hmm, yeah, I should have thought of that... we have logic to figure out the right kernel in there which needs updating
[23:38] <infinity> stgraber: Please with the emergency SRU? :)
[23:39] <stgraber> infinity: yep. Busy with other things tonight but will try anyway, worst case will have something first thing tomorrow
[23:41] <infinity> stgraber: Kay.  I'm airplaney tomorrow, but I'm sure you can convince someone else of the urgency and get it in. :)
[23:41] <stgraber> infinity: yeah, hopefully the change will be very simple and very readable. I'll do any necessary nagging to get it in once it's all tested.
[23:52] <skaet> stgraber, ScottK,  I just noticed there's a new kernel for raring 3.8.0-6.11 in -proposed.   Was it discussed with Edubuntu or Kubuntu teams during this alpha 2?
[23:54] <skaet> slangasek,  does it make sense to turn off the autobuilds now for raring edubuntu and kubuntu - until the alpha 2 is out the door.
[23:54] <skaet> ?
[23:55] <skaet> smoser,  any thoughts on whether you want to pick up the new kernel or not for your Alpha2 images?
[23:56] <infinity> I can block the migration if anyone cares deeply, but it should be fine.
[23:56] <stgraber> skaet: well, d-i has been uploaded so it's too late to avoid it but I don't really care
[23:57] <infinity> No one's asked for a freeze or anything.
[23:57] <stgraber> I think I looked at the changelog and nothing looked scary
[23:57] <slangasek> skaet: I'm assuming that someone from edubuntu and kubuntu will tell me when they want autobuilds disabled for testing purposes