[01:39] <mdeslaur> pitti: we have a kernel ABI mismatch: http://paste.ubuntu.com/756659/
[01:39] <mdeslaur> pitti: seems linux-ports-meta on lucid didn't get pushed
[01:40] <mdeslaur> jjohansen: ^
[01:40] <jjohansen> mdeslaur: ?
[01:41] <jjohansen> mdeslaur: as in can you point me at what I need to do
[01:41] <mdeslaur> jjohansen: linux-ports-meta on lucid is at ABI 35, but linux is at ABI 36
[01:42] <jjohansen> mdeslaur: right I caught that
[01:44] <mdeslaur> jjohansen: I usually tell pitti, the linux-ports-meta package needs to be pushed to updates also
[01:45] <jjohansen> mdeslaur: ah, so when we get the breakage email we need to ping piti
[01:46] <micahg> mdeslaur: jjohansen: he'll be around in ~3 hrs
[01:46] <jjohansen> micahg: hrmm, he starts early if its only 3 hrs
[01:46] <micahg> jjohansen: 6AM :)
[01:47] <jjohansen> micahg: but thats like bedtime
[01:47] <micahg> jjohansen: I know what you mean :)
[01:54] <slangasek> mdeslaur, jjohansen: linux-ports-meta copied; SpamapS was driving those and trying to work out whether linux-ports-meta was among the ones supposed to be copied, I guess we have the answer now :)
[01:55] <micahg> slangasek: ah, wasn't sure if you were around or not, so I didn't want to ping you
[04:15] <infinity> pitti: We stole celbalrai.buildd as a livefs builder, so it no longer shows up on the /builders/ page.  You might want to suck the ddebs down from it by hand at some point, since I suspect your scraper script won't find it.
[04:20] <mdeslaur> slangasek: thanks!
[05:01] <pitti> Good morning
[05:02] <pitti> infinity: we have 60 GB now on macquarie, I'll try whether that's sufficient now
[05:02] <pitti> ogasawara: no, when we lift the freeze, it's fine to upload
[05:02] <pitti> ogasawara: we usually do that at a time when it's clear that we won't respin any more, so no reason to further hold up development
[05:02] <pitti> skaet: ^
[05:03] <pitti> jdstrand: status.u.c. == cranberry.canonical.com
[05:04] <pitti> jdstrand: you can get the db from http://status.ubuntu.com/ubuntu-precise/ubuntu-precise.db
[05:06] <pitti> mdeslaur, jdstrand: seems someone already copied linux-ports-meta to -updates; I copied it to -security as well now
[05:27] <pitti> infinity: celbalrai ddebs salvaged
[05:28] <infinity> pitti: Danke.
[05:29] <infinity> lamont: You can rm -rf ~buildd/public_html/ddebs/* on celbalrai, BTW.  pitti's harvested them all.
[06:43] <pitti> stgraber: FYI, edubuntu DVD daily build should be fixed now, I uploaded a new nautilusy-python which ports the remaining stuff to GI
[06:52] <pitti> mdeslaur, jjohansen, jdstrand: meh, whoever copied that linux-ports-meta/linux to -updates yesterday night made a pretty big mess out of it :(
[06:52] <pitti> nothign on the tracking bug either; cleaning up now
[08:28] <jibel> pitti, bug 897680 is back on a1
[08:28] <ubot4> Launchpad bug 897680 in ubiquity (Ubuntu Precise) (and 1 other project) "Precise Desktop 64Bit: libc6 fails to install if "install 3rd party software" is selected (affects: 8) (dups: 7) (heat: 68)" [High,Triaged] https://launchpad.net/bugs/897680
[08:29] <pitti> jibel: ah, thanks
[08:29] <jjohansen> pitti: :(, thanks for cleaning it up.
[08:29] <pitti> jibel: I'll investigate this today then
[11:40] <jdstrand> pitti: re db> excellent, thanks! :)
[11:42] <jdstrand> pitti: thanks for the kernel cleanup. if you find out who did it, can you point them to me? (I'd like to see if find-bin-overrides is working correctly)
[11:44] <pitti> there's no logging for this unfortunately
[11:50] <jdstrand> pitti: btw, are you using ubuntu-precise.db for your reports? (I would like to, and if you already know the db schema, that could be helpful :)
[11:51] <pitti> jdstrand: "my" reports?
[11:51] <pitti> jdstrand: no, I just use the status.u.c. date
[11:51] <pitti> jdstrand: the schema is in the source, lp:launchpad-work-items-tracker
[11:51] <jdstrand> pitti: I thought we broke some stuff down by member
[11:52] <jdstrand> pitti: oh, excellent-- for some reason I was thinking this raw data on status was different from lp:launchpad-work-items-tracker
[11:52] <jdstrand> pitti: great, that is all I need :)
[12:06] <jdstrand> whoa, I've never seen this before:
[12:06] <jdstrand>  3448803 | X- | pxe-kexec            | 0.2.4-1              | 1 hour 30 minutes
[12:06] <jdstrand> 	 | * pxe-kexec/0.2.4-1 Component: universe Section: None
[12:06] <jdstrand> pitti: what does the 'X' mean?
[12:07] <jdstrand> sync
[12:07] <jdstrand> interesting, I never noticed that before
[12:08] <jdstrand> pitti: nm
[12:56] <pitti> jdstrand: ah, I never saw that either, thanks; good to know
[13:17] <mvo> hi, I prepared backports of apt/python-apt for lucid-backports, this will be used by the release upgrader plus it seems useful for users using apt-get dist-ugprade. any objections about the general approach (we talked briefly about it at uds)
[13:31] <jibel> mvo, would it be possible to backport apt-clone to lucid or publish it to a PPA. I'd like to send a call for testing after alpha2 to collect lucid clones and try to upgrade them.
[13:32] <mvo> jibel: oh, indeed! i will prepare that as well
[13:32] <jibel> mvo, fantastic, thanks!
[14:29] <stgraber> pitti: thanks
[14:30] <pitti> stgraber: err, thank you, too! (but for what?)
[14:30] <stgraber> pitti: 06:43 < pitti> stgraber: FYI, edubuntu DVD daily build should be fixed now, I uploaded a new nautilusy-python which ports the remaining stuff to GI
[14:30] <pitti> ah, right; sorry, already fell out of my brain :)
[14:31]  * pitti likes "nautilusy"
[14:37] <cjwatson> mvo: makes sense to me - that's what we've done in the past, isn't it?
[14:40] <mvo> cjwatson: the last time we (ab)used feisty-backports/debian-installer main, but I really would prefer to use the regular pocket this time as it seems cleaner and helps the manual upgraders
[14:43] <cjwatson> regular pocket?  you said lucid-backports above
[14:44] <cjwatson> oh, you mean you made it a udeb last time
[14:44] <cjwatson> I'm OK with it being in -backports but the backporters team ought to sign off on it I think since it's an exception to the usual rules for that pocket
[14:45]  * mvo nods
[14:46] <mvo> yeah, thats fair enough - indeed, last time it was a udeb, this time I would like it to be a proper deb
[15:09] <skaet> pitti, cjwatson.  https://wiki.ubuntu.com/MilestoneProcess - am reviewing, and the line pitti added (release-16) looks like its overlapping with (release-14) that cjwatson added.   Any issues with me consolidating and merging?  (or am I misunderstanding something)
[15:11] <pitti> skaet: hm, where do ou see the overlap? one is the conffile on nusakan, the other is the ISO tracker
[15:12] <skaet> pitti,  seems to me they're all related to getting the iso tracker back working with dailies.
[15:13]  * skaet agrees that they are on separate environements though.
[15:14] <pitti> skaet: I'm fine with merging them into one step
[15:15] <skaet> pitti, thnx.
[15:24] <skaet> pitti,  also trying to figure out how to clarify the unfreezing of the archive vs. announce going out.    In the steps archive does not unfreeze until after the announce goes out,  but I agree in practice for certain milestones its safe to unfreeze before, esp. for soft freezes.    However the checklist makes it explicit that the UpgradeTestingProcess is complete before the archive is unfrozen, and that's after the
[15:24] <skaet>  announce.   What are the other factors that should weigh in to when to unfreeze archive.   When its clear we won't be respinning,  seems to me to be what I'm seeing used.
[15:25] <skaet> ?
[15:35] <skaet> cjwatson, slangasek, ^ any thoughts about when safe to unfreeze?
[15:35] <cjwatson> I tend to think of it as we unfreeze once we're past point of no return
[15:36] <cjwatson> so once we've decided to release and are just pushing buttons
[15:36] <slangasek> yep
[15:39] <skaet> cjwatson, slangasek, pitti - ok,  will make some updates to reflect that.
[17:32] <mvo> jibel: apt-clone backport request is here https://bugs.launchpad.net/lucid-backports/+bug/899286
[17:32] <ubot4> Launchpad bug 899286 in lucid-backports "Please provide apt-clone backport (affects: 1) (heat: 6)" [Undecided,New]
[17:32] <mvo> jibel: once I get approval from the backports team, that should be fine, I ported it over to python-central
[17:45] <mvo> cjwatson, slangasek: python-apt/apt backport request is written here https://bugs.launchpad.net/lucid-backports/+bug/899281 - feedback (as always) welcome!
[17:45] <ubot4> Launchpad bug 899281 in lucid-backports "Please provide apt/python-apt multiarch backports (affects: 1) (heat: 6)" [Undecided,New]
[18:06] <micahg> mvo: shouldn't this go to -updates?
[18:13] <slangasek> mvo: ^^ same question as micahg; wasn't the plan to put these backports in as an SRU, to maximize mirroring and rely on the package names being different from anything in lucid to avoid them being incorrectly pulled into the system before the upgrader runs?
[18:14] <micahg> Bug #899286 makes sense as a backport, but it'll also need to go to {maverick-oneiric}-backports
[18:14] <ubot4> Launchpad bug 899286 in lucid-backports "Please provide apt-clone backport (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/899286
[20:29] <mvo> slangasek: sorry for the delay in answering. so we could make the package name different, but then python-apt would have to have a different prefix or a different import name for "apt" and "apt_{pkg,inst}" plus the locales would have to be renamed or put into a different prefix as well. possible, but it seems like the -backport is actually both simpler and more useful (as the current approach will be useful for people wanting to perform a ma
[20:29] <mvo> nual apt-get dist-upgrade as well).
[20:30] <mvo> micahg: apt-clone> the version for lucid should be fine for maverick too and for oneiric we can use the current precise version unaltered
[20:31] <broder> mvo: what micahg meant is that standard backport policies require backports to maverick, natty, and oneiric in addition to lucid
[20:31] <broder> it's an upgrade path thing
[20:31] <broder> but doing the dh_py2 -> dh_pycentral thing is fine - we tweak backports all the time to deal with toolchain changes
[20:32] <mvo> broder: thanks, I see. indeed
[20:40] <slangasek> mvo: oh.  we did discuss the -updates approach at UDS though, right, I didn't imagine that part?
[20:40] <slangasek> if it's simply not practical, then by all means, do what needs doing :)
[20:41] <mvo> slangasek: yes, we did :) let me think this through again, both approaches have some pros and cons and both will work, so in some sense its a good problem ;)
[20:43] <mvo> slangasek: the upgrade path that broder mentioned is actually a (big) con against the approach to provide a full backport of apt/python-apt, and a pro for the more targeted approach we discussed at uds
[20:43]  * mvo looks into this now
[20:44]  * slangasek nods