[00:11] <cjwatson> ^- kexec-tools is on the Kubuntu DVD (no other images, according to seeded-in-ubuntu), but that's awaiting the python2.7 fix, and this is the right fix for one of the entries on http://people.canonical.com/~ubuntu-archive/testing/precise_outdate_all.txt with no run-time source change; can we squeeze this in?
[00:24] <slangasek> makes sense to me
[00:25] <skaet> cjwatson, ok,  we've got the window and its low impact.
[00:25] <skaet> s/impact/risk/
[00:27] <slangasek> accepted
[00:43] <skaet> hggdh, slangasek - looks like i386 and amd64 have published for https://launchpad.net/ubuntu/+source/python2.7/2.7.3-0ubuntu3.
[00:43] <skaet> hggdh, can we trigger the autotesting off, without waiting for the built in delay?
[00:44] <slangasek> that was the intent, yes
[00:49] <doko_> slangasek, pong (for 15min online)
[00:50] <slangasek> doko_: hey - the python2.7 change was never tested for oneiric->precise upgrades, there was a critical regression there
[00:50] <slangasek> doko_: I've sorted it in the archive (I think), you'll want to pick up the changes from their for your bzr branch
[00:50] <doko_> ouch, looking
[00:51] <slangasek> doko_: as a general rule, please don't use Conflicts in essential packages - this kind of problem is exactly what you get :)
[00:52] <doko_> slangasek, yeah, we discussed that on the channel, and didn't want the circlular dependency. and just a breaks wouldn't help
[00:58] <slangasek> Conflicts are almost universally worse than circular deps
[00:59] <slangasek> in this case, we probably could have kept the Conflicts with a lower version number that didn't break o->p
[00:59] <slangasek> (and if any problems show up with the circular deps, that'll be my next step)
[00:59] <doko_> right, not conflicting with the oneiric version sounds much better
[01:01] <doko_> anyway, afk now, will check updates from lucide and from oeneiric tomorrow
[01:02] <slangasek> ok - the QA team will also be testing that out ASAP
[01:02] <slangasek> so there's probably no need for you to worry about it
[01:02] <slangasek> anyway - g'night :)
[01:26] <cjwatson> slangasek: do you think the qemu-linaro/powerpc build failure might be fixable by release?  it last built in only the previous upload, and its effects on precise_outdate_all are a little tricky to unwind with simple removals since there are some dependencies on its binaries
[01:51] <slangasek> cjwatson: last time I looked at the build failure there, I couldn't work out how to fix it
[01:51] <ScottK> Is netbook a seed we need to worry about for accepting packages (I'm guessing it's obsolete, but someone please tell me)?
[01:51] <GridCube> im having an issue with today's release and i dont know if its a bug or not, if starting a sentence with sudo on a terminal, when trying to tab to complete the options, like with sudo apt-get i[tab] doesnt do anything, it used to complete the install, and then when writing the first letters of package, say exa[tab] doesnt complete exaile, or even gives option
[01:51] <GridCube> it looks like tab to complete is broken to me
[01:51] <GridCube> :/
[01:53] <ScottK> GridCube: Try in #ubuntu-testing or #ubuntu+1.
[01:53] <GridCube> ok
[01:53] <ScottK> infinity: What do you think about syncing csound for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661197
[01:53] <ubot2> Debian bug 661197 in csound "multiple vulnerabilities in csound" [Grave,Fixed]
[02:00] <slangasek> ScottK: netbook is obsolete TTBOMK
[02:07] <ScottK> slangasek: Thanks.
[02:18] <ScottK> AIUI, the security team declined to support cobbler in Main, which is why maas-provision exists (to be the supported subset of cobbler in Main so maas can be in Main).  The upload that fixes the dependencies so cobbler can go back to Universe is in the queue, but the diff is (due to other reasons) not insignificant.
[02:18] <ScottK> I think someone (not me) should either review the diff or we should reject it and ask for one that just does the dependency swap.
[02:30] <skaet> ScottK,  ^ that was an error that proved I got the syntax wrong on some timing runs I was doing and didn't want to publish.   I'll revert it manually to the earlier image.
[02:31] <hggdh> skaet, slangasek: testing upgrade from Lucid to Precise, AMD64, server
[02:32] <ScottK> skaet: OK.  I hope I just downloaded the right one.
[02:33] <ScottK> skaet: There's no testing on the current images, so it doesn't hurt to switch to a different one.
[02:33] <skaet> unless you can download in 3 minutes,  I think you're safe.  :0
[02:33] <hggdh> skaet, slangasek: this run (server) should take less than 20 min
[02:33] <skaet> :)
[02:33] <ScottK> I got 20120420.1
[02:34] <skaet> ScottK,  yup that's the one I'll revert the tracker back to so you can record results against the right image
[02:36] <skaet> hggdh,   Thanks for the estimate.  :)   we'll also need Lucid to Precise, desktop;   Oneiric to Precise, server;   Oneiric to Precise, desktop upgrade runs done as well.
[02:36] <skaet> can they be started in parallel?
[02:39] <hggdh> skaet: I started with (lucid|oneiric)->precise, server. If these pass, then I will start the others. It will delay just around 20min the full results, but it does not make sense to start all at the same time (not enough resources)
[02:40] <skaet> hggdh,  coolio.  Makes sense.  Thanks!  :)
[02:40] <hggdh> skaet: YW
[02:47] <skaet> ScottK,  which upload are you commenting on in unapproved?    maas?
[02:47] <ScottK> skaet: mass
[02:47] <ScottK> err maas
[02:47] <skaet> Daviey's agreed to review it.
[02:48] <ScottK> It seems like we're kind of running out of time.
[02:48] <skaet> however he's been traveling - so as soon as he surfaces, it should get resolved.
[02:48] <ScottK> I'd suggest you set a deadline after which we just swap the dependencies and they can do the other stuff in an SRU if they want.
[02:49] <ScottK> Does stuff in the ubuntu-server: daily seed end up on the server ISO?
[02:49] <ScottK> Because maas is seeded in that seed.
[02:50] <skaet> ScottK,  it needs to be resolved by Monday morning.
[02:50] <skaet> hmm.  Let me go check what's in the latest published image...
[02:51] <ScottK> BBIAB, need to reboot into a live session with this machine.
[02:53] <skaet> ScottK,  yes it does.
[02:54] <skaet> http://cdimage.ubuntu.com/ubuntu-server/daily/20120419/precise-server-amd64.list
[02:54] <hggdh> skaet: oneiric-precise, server upgrade successful
[02:55] <skaet> \o/
[02:55] <hggdh> skaet: lucid-precise, server, AMD64 successful, i386 still going
[02:55] <skaet> :)
[02:56] <skaet> in the .list file is /pool/main/m/maas/maas_0.1+bzr462+dfsg-0ubuntu1_all.deb
[02:56] <skaet> ScottK, ^
[02:57] <hggdh> I will bite the bullet, and start the desktop upgrades; oneiric-precise takes ~ 20 min, lucid-precise takes ~ 40 min
[02:58] <hggdh> the real heavy-weights, upgrades of all main and universe, for both ludic and oneiric will take ~ 8 hours to run
[03:00] <skaet> hggdh,  thanks for that info,  ok,   looks like we'll need to let the main and universe run overnight then.
[03:00] <hggdh> skaet: indeed :-)
[03:00] <hggdh> desktop upgrades have started. All server upgrades are successful
[03:00] <skaet> when slangasek gets back from dinner,   hopefully all of the targetted upgrades will be done,  and if all is well,  we can figure out a game plan.
[03:01] <skaet> Thank you hggdh, :)    Will be looking forward to the data in ~40 minutes on the desktop.   (and then decide on bed time ;) )
[03:04] <hggdh> bed time? What is bed time? ;-)
[03:04] <hggdh> skaet: you can follow results here: https://jenkins.qa.ubuntu.com/view/Precise%20Upgrade%20Testing%20Dashboard/
[03:04] <hggdh> it may take a bit for them to be published (some stuck jobs, and we can only clean them up *after* release)
[03:05] <skaet> Thanks hggdh. :)
[03:10] <skaet> ScottK,   the unity-greeter fix looks targetted to kubuntu - can you review it if you want it in this next set of respins?
[03:10] <ScottK> Back.
[03:10] <ScottK> OK.
[03:11] <skaet>  * debian/patches/recognize-kde-plasma.patch:
[03:11] <skaet> +    - Recognize the "kde-plasma" session as "kde" so it gets a properly
[03:11] <skaet> +      branded icon in the greeter.  LP: #986339
[03:18] <ScottK> skaet: It seems like something one would want, but it's a unity fix, so it won't affect the Kubuntu images.  I'd say yes, but I'm not the one that has to retest stuff.
[03:19] <skaet> ScottK,  ok,   it seems something that can be SRU'd easily enough,  so that may be option to take at this point.
[03:22] <ScottK> I agree.
[03:46] <ScottK> skaet: I expect a postfix upload from lamont sometime over the weekend that fixes an important bug.  It's not a regression and it's not essential for the CD, but it isn't something we want to leave laying around any longer than we have to.  I'd like to get it into precise-proposed and then, once it's tested, opportunistically copy to -release if there's a respin.
[03:46] <ScottK> If not, it can go to -updates at release.
[03:46] <infinity> ScottK: If it doesn't break anything, I don't have huge issues with acking the csound sync.
[03:47] <ScottK> infinity: That's the if.  My view would be sync and get the security fixes and then if someone cares about breakage we can work on an SRU.
[03:47] <ScottK> (breakage, if any)
[03:48] <ScottK> Is the python-minimal upgrade loop fixed yet?
[03:50] <infinity> ScottK: If by fixed, you mean "did we add a loop to fix the conflict breakage?", then yes.
[03:50] <infinity> And the loop seems to be working.
[03:51] <ScottK> OK.  I just saw mail on devel-discuss about it and I wasn't sure if that was just lag or not.
[03:51] <infinity> ScottK: As for the sync, if you're willing to follow up on potential fallout, go for it.  Though, my guess is that it'll be fine, who knows...
[03:51] <ScottK> Thanks.
[03:51] <infinity> ScottK: It at least built on all the Debian buildds, so that's promising.
[03:51] <ScottK> Yep.
[03:52] <ScottK> I'll be all radical and test build on Ubuntu first.
[03:59] <skaet> :)
[03:59] <hggdh> skaet: all upgrade tests are queued. So far, so good
[04:00] <skaet> thanks hggdh.  :)
[04:06] <ScottK> OK.  DOne.
[04:06] <ScottK> (csound)
[04:12] <ScottK> infinity: I'm thinking flumotion might deserve similar treatment.  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660553 - Looking at the Ubuntu bugs, I think it is extraordinarily unlikely we'll make it work.
[04:12] <ubot2> Debian bug 660553 in flumotion "flumotion fails to start" [Grave,Fixed]
[04:15] <ScottK> Is syncpackage "A new OAuth token consumer" in Launchapdspeak?
[04:16]  * hggdh calls it a day, and goes to bed.
[04:16] <skaet> thanks hggdh!   have a good evening.
[04:16] <skaet> I'll continue to monitor the site, until I do as well.  :)
[04:16] <hggdh> skaet: see you tomorrow, shabbat or not :-)
[04:17] <skaet> :)
[04:17] <ScottK> infinity: It builds fine.
[04:36] <ScottK> FWIW, I just updated a system I hadn't touched since either precise Alpha 2 or Beta 1 and it upgraded just fine (took a VERY long time though).
[04:38] <skaet> :)  nice to hear.
[04:54] <skaet> infinity, slangasek, cjwatson, pitti - if one of you is awake when the python2.7 testing on the iso tracker completes, and the results look reasonable,  please start off the rebuilds.   Otherwise,  I'll start them when I wake up tomorrow (if testing ends up looking ok ;) before heading to airport.
[04:54] <skaet> https://jenkins.qa.ubuntu.com/view/Precise%20Upgrade%20Testing%20Dashboard/
[04:54] <skaet> ^ site to check status of runs on.
[04:55] <skaet> ScottK,  I've updated the pad, and think I've caught the issues you've raised this evening,  please correct anything I may have misinterpreted.  (also,  is there a bug number for lamont's upload?)
[04:55]  * skaet --> zzz
[05:14]  * ScottK looks
[05:14] <ScottK> There is.  I'll find it.
[05:20] <ScottK> skaet: The bug for postfix is Bug #980682.
[05:20] <ubot2> Launchpad bug 980682 in postfix "postconf can't open main.cf with the result that /etc/resolvconf/update-libc.d/postfix fails trying to copy /etc/resolv.conf onto itself" [Undecided,Fix committed] https://launchpad.net/bugs/980682
[05:20] <ScottK> If by pad you mean the wiki page in /topic then I don't see the changes.
[06:15] <slangasek> so given the impact this python2.7 issue also has on upgrades in the wild, and given that we have evidence now that it fixes the oneiric->precise upgrade for at least the minimal case, I think we should probably copy it to -release now
[06:15] <slangasek> and let the tests continue running overnight before kicking off the respins
[06:16] <slangasek> ScottK, infinity: ^^ that sound right to you?
[06:17] <ScottK> OK.
[06:17] <ScottK> I have another respin worthy upload I'm about to make in any case.
[06:18] <slangasek> python2.7 copied
[06:18] <slangasek> so hopefully that will help the users
[06:18] <slangasek> ScottK: what's the other upload?
[06:19] <ScottK> Fix for Bug #986475
[06:19] <ubot2> Launchpad bug 986475 in bcmwl "Jockey-kde failed to install broadcom STA wifi drivers from Kubuntu Desktop ISO" [High,New] https://launchpad.net/bugs/986475
[06:19] <slangasek> aha
[06:19] <ScottK> (you'll see in the bug it turns out to be bcmwl's fault.
[06:20]  * slangasek nods
[06:20] <slangasek> so that's obviously a "can't use the CD" issue that's worthy of a respin, yes
[06:20] <ScottK> dput.
[06:21] <ScottK> Please stare hard at the dependency change I made to make sure it work for upgraders that still have the non-pae kernel.
[06:21] <slangasek> ack
[06:21] <ScottK> I'm as certain as I can be at 2:21AM it's right.
[06:25] <ScottK> At least the Groklaw Oracle vs Google day 5 summary is up so I have something to do while I wait to make sure it appears.
[06:26] <slangasek> looks right to me, accepting
[06:33] <ScottK> Thanks.
[06:33] <ScottK> And good night.
[06:35] <slangasek> 'night
[07:02] <slangasek> skaet: ok, given that the lucid-main and oneiric-main upgrade tests have been running for 4 hours now without kicking out a failure, that gives me enough confidence to start the image respins; doing now
[07:07] <jibel> oneiric and lucid main passed the upgrade calculation phase and is upgrading. other tests are back to normal.
[08:44] <ogra_> hmm, could someone accept my compiz upload to proposed from yesterday so my testers can actually test it ?
[13:18] <skaet> ScottK,  Thanks for tracking down the bug number.   pad I was referncing was: http://pad.ubuntu.com/ubuntu-release
[13:18] <skaet> now that we're spinning images,  we're using it to track image respins/bugs.
[13:19] <knome> is there a status of the adopt a iso -project somewhere? where do i know if xubuntu iso's are adopted or not?
[13:22] <skaet> knome,  http://iso.qa.ubuntu.com/qatracker/reports/subscriptions shows the testcase that folks have subscribed to (and if you mouseover,  who has subscribed)
[13:24] <skaet> just scan down to your product.   (there may be other mechanisms available)
[13:24] <skaet> (that the testing team is using as well - but the one on the iso tracker is what I look at.
[13:24] <skaet> ) :)
[13:47] <ogra_> skaet, is there a reason the compiz upload wasnt accepted so we can actually have binaries for testing in precise-proposed ?
[13:47] <cjwatson> I'm respinning server powerpc with a seed change to get it back undersized; it's had no tests as yet, so I assume nobody will much care
[13:49] <cjwatson> ogra_: should be no problem with that - I'm looking into it now
[13:50] <ogra_> thx
[13:51]  * cjwatson peers at LP's bonkers idea of which diff to display
[13:54] <ogra_> great, thanks a lot !
[13:55] <skaet> ogra_,  state of what needed to and someone comfortable reviewing it didn't seem to happen.   It wasn't recorded on either https://wiki.ubuntu.com/PrecisePangolin/FrozenArchiveStatus or on pad.ubuntu.com/ubuntu-release,  sigh.  That's fixed now at least.
[13:55] <skaet> Thanks cjwatson for reviewing and accepting.
[13:55] <ogra_> oh, should i have it noted there ?
[13:56] <skaet> ogra_ yes.  There are so many variables in flight,  IRC only traffic for important things results in process fail.  (as illustrated ;) )
[13:56] <ogra_> k, next time, sorry, my fault then
[13:57] <cjwatson> skaet: FWIW the compiz change no longer qualifies as "pervasive change" as in [15], IMO
[13:58] <cjwatson> one fglrx fix, and syncing up the gles patch
[13:58] <skaet> cjwatson,  affects more hardware than just fglrx
[13:58] <ogra_> yup
[13:58] <cjwatson> though I agree it needs testing, it's just not as crazy as stated
[13:58] <ogra_> needs testing on all non fglrx cards
[13:58] <cjwatson> certainly
[13:58] <ogra_> (and on arm indeed :) )
[13:59] <cjwatson> but "pervasive change on tree" suggested to me that everything was totally rearranged, which isn't the case :)
[13:59] <skaet> cjwatson,  not worries about the gles patch (localized scope) there.  but the other fix that's tangled in, in the tree needs much wider testing.
[13:59] <skaet> cjwatson,  feel free to edit.  :)
[13:59] <cjwatson> I've reworded the pad to be a bit more accurate
[13:59] <skaet> :)  yup.  Thanks.
[14:00] <cjwatson> hah, finally, daily-checks says "No problems found!"
[14:01] <skaet> WOOT!!!!!
[14:03] <knome> skaet, are those subscriptions reliable?
[14:04] <knome> skaet, or can somebody subscribe but rarely ever do a test?
[14:04] <skaet> knome,  anyone can subscribe but not test.   However they are getting emails when new images arrive,  if they have subscribed so...
[14:04] <knome> skaet, ok, thanks
[14:05] <knome> that's a good pieve of information altogether :)
[14:05] <skaet> cjwatson,  am seeing /pool/restricted/b/bcmwl/bcmwl-kernel-source_5.100.82.38+bdcom-0ubuntu6_amd64.deb in the latest builds (or at least ubuntu-desktop)
[14:05] <knome> btw, there's a small technical glitch
[14:06] <knome> scroll all the way down to xubuntu,and try to see the whole list of 12 subscriptors to desktop i386 install (man part)
[14:06] <knome> (second to last item)
[14:06] <skaet> so I think bcmwl made it in.   Haven't looked at all the affected images though so we may have some with,  and without.
[14:07] <skaet> (just a risk,  not sure this is the case,  will try to check later if I get some online time at airport)
[14:11] <skaet> strgaber, ^ see knome's comments.   Is there a project now for it - or should bugs be filed against https://bugs.launchpad.net/ubuntu-qa-website with [ISO TRACKER] in the subject?
[14:12] <knome> skaet, thanks
[14:12] <knome> stgraber, sorry ;)
[14:15] <knome> bbl
[14:16] <cjwatson> accepting gnome-games under SRU rules
[14:16] <cjwatson> skaet: yes, is that wrong?
[14:16] <cjwatson> skaet: that's needed to enable broadcom network cards in jockey
[14:17] <skaet> cjwatson,  not wrong,  just wasn't sure about the timing of it landing by reading through the backscroll.
[14:17] <skaet> ie.  did it make it in the builds or not,  timing wise
[14:17] <cjwatson> sorry, I don't think I understand - you're talking about the version?
[14:17] <skaet> it seems to have made it into one,  so likely all,   but risk is there until checked.
[14:17] <cjwatson> ah, I see, timestamped this morning
[14:18] <skaet> re: version.  right one should be:
[14:18] <skaet> bcmwl-kernel-source_5.100.82.38+bdcom-0ubuntu6_amd64.deb
[14:18] <skaet> will just make a note of it,  as I clean up the pad
[14:18] <skaet> (and remove note when, have had a chance to review the other affected images
[14:18] <skaet> )
[14:19]  * cjwatson greps
[14:19] <cjwatson> all current images have the newest version
[14:19] <skaet> yeah that's what I was doing on ubuntu-desktop.   Feel free to educate on more efficient way to see widely.  ;)
[14:19] <cjwatson> cdimage@nusakan:~/cdimage/www/full$ find -L -path \*/current/\*.list 2>/dev/null | xargs grep bcmwl-kernel-source | egrep -v '/(lucid|maverick|natty|oneiric)/'
[14:19] <cjwatson> (not elegant, I couldn't be bothered to think of a neater way)
[14:20] <skaet> looks good to me.  :)
[14:20] <stgraber> skaet, knome: https://bugs.launchpad.net/ubuntu-qa-website/+filebug and tag with qa-tracker
[14:20] <skaet> thank you.  :)
[14:20] <cjwatson> right, sorry for previous misunderstanding, juggling family stuff
[14:21]  * ogra_ now has a weird picture of cjwatson sitting on his desk jugglin babies 
[14:21] <skaet> cjwatson,  no worries.
[14:21] <cjwatson> not a million miles from the truth
[14:21] <ogra_> heh
[14:22] <ogra_> i hope you dont throw them in the air though :)
[14:22] <stgraber> knome: I need to investigate a replacement code for the tooltip stuff, it's currently CSS only and so isn't terribly flexible. I also have some code around that allows you to click on the number of subscribers and navigate to a page showing you the list of subscribers and some more stats, that should fix the issue for images with a lot of subscribers
[14:22] <skaet> jibel, hggdh,  can the auto update tester be kicked off again now (point it back to release)  - I'm wondering if some of the fails were due to package being copied from -proposed to -released before run was done?
[14:22] <skaet> Anyhow,  would like to get auto test runs done on these latest images so we can understand the status.
[14:23] <stgraber> skaet: I'm checking the status on flavour upgrades now, if it doesn't look good. I'll cancel and restart the test from scratch to get accurate results
[14:24] <cjwatson> ogra_: it's OK as long as you catch them :)
[14:24] <cjwatson> (and don't throw them too high ...)
[14:24] <cjwatson> my children are going to grow up to be rollercoaster fans, I'm pretty sure
[14:25] <skaet> stgraber,  not sure edubuntu should be affected.  It was just an ubuntu run for universe based off of -proposed last night to check all lucid, oneirc -> precise was sane.
[14:25] <skaet> but if there are problems,  certainly want to hear about them.   :)
[14:26] <jibel> skaet, 'main' and 'universe' are still running, that's why status is not updated. I'll remove proposed once it is finished.
[14:26]  * skaet giggling at the images that cjwatson and ogra_  have just put in my head.   lol
[14:27] <skaet> thanks jibel.     If you can kick off a clean set from the latest images that just got published,  would be helpful to have solid data tomorrow.
[14:27] <stgraber> skaet: well, all past upgrades failed because of the python2.7 breakage, so the current run will at least confirm that we're no worse than we were before that
[14:28] <skaet> stgraber,  oh definitely.  :)  Not saying not to do it,  just that the fails on the board may not have been relevant to you.
[14:29] <jibel> skaet, tests are scheduled to start at 1700UTC
[14:29] <skaet> jibel,  that will work.  :)  Thank you.
[14:31] <skaet> http://pad.ubuntu.com/ubuntu-release has been updated.
[14:34] <skaet> reenabling update testing on the tracker now as well...
[15:28] <ScottK> skaet: Thanks.  Would you please put that in /topic then.
[15:32] <ScottK> skaet: re bcmwl, it's availability was one of the things slangasek was tracking before he hit the respin button last night.
[15:38] <ScottK> stgraber: Could you have a look at Bug #974667.  It seems to have come up again in ISO testing today.
[15:38] <ubot2> Launchpad bug 974667 in dnsmasq "dnsmasq does not bind to a port" [Low,New] https://launchpad.net/bugs/974667
[15:40] <stgraber> ScottK: commented. It might be some kind of race condition, hopefully having the syslog will clarify the problem a bit. cyphermox might be interested too
[15:44] <ScottK> Thanks.
[15:48] <ScottK> Sigh.  It looks like my bcmwl fix wasn't sufficient.
[16:17] <ScottK> Laney: Since I know you're out there uploading stuff: What would you think about me syncing flumotion.  Looking at the RC bug fix it would bring (doesn't start) and the long list of Ubuntu bugs with the current package, it would seem unlikely to make things worse.
[16:21] <Laney> ScottK: if it tests out, go for it
[16:21] <ScottK> It builds.
[16:22] <ScottK> I'll take that as a yes.
[16:22] <Laney> I'd like it to at least have been run, but yes.
=== ChanServ changed the topic of #ubuntu-release to: Archive: frozen | http://pad.ubuntu.com/ubuntu-release | Precise Pangolin Release Coordination.  Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or chocolate | melior malum quod cognoscis
[16:23] <ScottK> OK.
[16:24] <ScottK> starts
[16:25] <hggdh> I do not think it is a big deal, but server amd64 JeOS install uses 680M, the test states <= 500M
[16:25] <hggdh> I tend to pass it, and open a bug to update the test
[16:25] <skaet> hggdh,  sounds ok,  thanks.
[16:26] <Laney> back to the pad again?
[16:27] <skaet> Laney,  yes,  as soon as we start working with images, back using the release pad.
[16:27] <Laney> righto
[16:29] <ScottK> Done.
[16:29] <ScottK> skaet: It looks like the bcmwl change I did lastnight (while correct) was not sufficient to induce the with linux-source package onto the ISO.
[16:31] <skaet> ScottK,  will you be working on something to queue up if we end up doing another respin?
[16:31] <ScottK> skaet: Yes.
[16:32] <ScottK> I think this is respin material all by itself as it can prevent you from getting online.
[16:33] <skaet> Thanks for explanation.   Ok,  please keep the status of your efforts updated on the pad as you go.
[16:35] <ScottK> I fixed it by adding the right package to the seed directly for Kubuntu (so I'm about to ask you to respin Kubuntu Desktop i386), but this likely means that any flavor that wants this fix will have to fix their own ship-live seed.
[16:35] <ScottK> cjwatson or slangasek: If you're about, I have a question or so about the above problem and how to fix it.
[16:36] <ScottK> Or infinity.
[16:36] <skaet> I'm going to be offline for a bit now (traveling to London).    Colin Watson and NCommander have agreed to keep an eye on things,  as backup.
[16:37] <NCommander> cya later
[16:37] <skaet> infinity's also traveling to London this weekend.
[16:37] <skaet> slangasek is reachable by phone in emergencies.
[16:39] <ScottK> skaet: I don't suppose you could respin Kubuntu Desktop i386 before you go?
[16:39] <cjwatson> hggdh: oversized jeos install has been a bug for most of this cycle
[16:40] <hggdh> cjwatson: I agree. I think it is time to reconsider this limit
[16:40] <skaet> ScottK,  just about to shut the computer off before heading to airport.   Is it all ready to build?
[16:40] <ScottK> Yes.
[16:40] <cjwatson> ScottK: I'm entertaining the children right now, but give me an hour or so
[16:40]  * skaet doing.
[16:40] <ScottK> It was just a seed change and it's done.
[16:40] <ScottK> cjwatson: Thanks.
[16:40] <cjwatson> question for me still outstanding?
[16:41] <skaet> cjwatson, am handling now.   Then powering off.
[16:41] <skaet> :)
[16:41] <cjwatson> safe travels
[16:41]  * skaet likes Screen ;)
[16:41] <skaet> Thanks!   see you in London.
[16:44] <Laney> are we still using ubuntu-release-notes?
[16:48] <skaet> ScottK,   building now.
[16:48] <ScottK> Thanks.
[16:50] <ScottK> skaet: Also I've now discovered this only affects Kubuntu because (apparently) we ship linux headers differently than the other flavors, so it's more contained than I thought it was.
[16:51] <skaet> ScottK,  that's good news.  Could you put the details of the package, and fix on the pad,  and mark that Kubuntu DVD will need respinning,  if this sorts it then?
[16:51] <ScottK> It won't affect the DVD.
[16:51] <ScottK> Will do.
[16:51] <skaet> Thanks!
[16:51]  * skaet --> airport
[17:55] <ScottK> That took care of it.
[18:03] <ScottK> cjwatson: (for when you get around to it): Unlike other flavors, Kubuntu doesn't have linux-headers-foo in the livefs, it's in the pool via live-ship.  Yesterday I changed bcmwl-kernel-source to properly depends on linux-headers-generic-pae [i386], but Kubuntu still had the wrong linux-headers-generic package on i386.  The other flavors where correct before.
[18:04] <ScottK> I've directly seeded linux-headers-generic-pae [i386] in Kubuntu live-ship, but it seems like I shouldn't have had to.
[18:05] <ScottK> The bcmwl-kernel-source depends on linux-headers-generic-pae [i386] | linux-headers-generic [amd64] | linux-headers should have been enough I'd have thought.
[18:05] <ScottK> so that's what the question was.
[18:05] <ScottK> (less urgent now that I've worked around it)
[18:12] <slangasek> jibel, hggdh: thanks for all the support on retesting python2.7 yesterday; I'm happy to see green and yellow on jenkins today, so looks like we're good
[18:13] <slangasek> ScottK: I'm not sure I understand exactly what the problem is currently.  You mention linux-source, which should never be required for a driver build; did you mean linux-headers?
[18:13] <ScottK> Yes.
[18:13] <ScottK> Sorry.
[18:14] <ScottK> After the bcmwl fix last night, the respin still had the wrong header package on it.
[18:14] <slangasek> ScottK: ah, you've already taken care of this, I see
[18:14] <ScottK> I seeded it directly to work around whatever the source of that was.
[18:14] <ScottK> Yes.
[18:14] <slangasek> right, because of the seed being picked up and satisfying the dep wrongly
[18:14] <slangasek> do you need a kubuntu respin for that?
[18:15] <slangasek> happy to kick one off now if it's ready
[18:15] <slangasek> (otherwise, I'm afk for the next 2h)
[18:15] <ScottK> No, skaet already did it.
[18:15] <slangasek> ok
[18:15] <ScottK> I just downloaded the updated image and confirmed it's correct.
[18:15] <ScottK> Thanks.
[18:15] <slangasek> sure
[18:15] <cjwatson> ScottK: I've only had time for a very quick investigation, but I think that germinate probably happened to follow the recommends of dkms first which permits linux-headers-generic, and then when it got to bcmwl-kernel-source it already had that disjunctive dep satisfied so didn't proceed further
[18:16] <ScottK> cjwatson: That would make sense.
[18:16] <cjwatson> A manual seed entry is a reasonable workaround, although it's slightly awkward that dkms doesn't have a preferred alternative matching the preferred kernel
[18:16] <cjwatson> but the whole business of deps on kernel headers is a mess anyway *shrug*
[18:16] <cjwatson> afk
[18:17] <ScottK> Thanks.
[18:17] <slangasek> yep - we need conditional depends ;P
[18:20] <ScottK> Any thoughts on uploading a dkms to -proposed with the recommends fixed up to DTRT?  It could be there as a target of opportunity if we do a global respin or an SRU for 12.04.1?
[18:24] <hggdh> slangasek: you are welcome :-)
[18:31] <kklimonda> ^ this is a simple fix to the debian/rules so the package installs libraries in the proper (multiarch) location. Without it people have to create symlinks manually to get it to work
[18:46]  * ScottK looks
[18:47] <cjwatson> ScottK: I'm not opposed, although I think it's slightly rearranging-the-deckchairs; but it might reduce chance of error in image building, yes
[18:47] <ScottK> kklimonda: Done.
[18:48] <kklimonda> thanks
[18:48] <ScottK> cjwatson: I'll take a shot at it then.
[18:48] <ScottK> (I agree about the deckchairs)
[20:16] <slangasek> ScottK: what's the impact of the dkms recommends being off?
[20:54]  * Daviey checks in
[21:05]  * slangasek waves to Daviey
[21:08] <ScottK> slangasek: No immediate impact as I've worked around it in seeds.
[21:09] <slangasek> is there a longer-term impact?  not understanding why it would even be SRU-worthy
[21:09] <ScottK> slangasek: I think it'd be nice to get it in, at least for the point release, in aid of overall correctness and surprise avoidance.
[21:09] <ScottK> I know I've worked around the case in seeds of which I was aware.
[21:09] <ScottK> I can't promise there might not be some other case.
[21:09]  * slangasek nods
[21:09] <slangasek> I would tend towards wait-and-see
[21:10] <ScottK> OK.
[21:11] <ScottK> My view was that it's a low risk, obvious step towards correctness, so get it in if we have an opportunity for it.
[21:11] <ScottK> But I'm the one playing normal developer here and you're the one playing release team, so wait and see it is.
[21:11] <slangasek> :)
[21:12] <slangasek> I can't see the downside to caution here, as any further issues that could arise would seem to be non-CD-affecting so an SRU would be just as good
[21:14] <ScottK> I agree SRU is fine.
=== Ursinha` is now known as Ursinha
=== Ursinha is now known as Guest65814
[23:35] <slangasek> bjf: would be nice if http://reports.qa.ubuntu.com/reports/kernel-bugs/reports/rls-p-tracking-bugs.html knew about the 12.04.1 milestone now that it exists