[00:55] <skaet> ubuntu-desktop i386, amd64, amd64+mac images published for smoke test purposes
[01:09] <cody-somerville> slangasek, maxb suggests that maybe the publisher is in manual mode?
[01:11] <GrueMaster> ubiquity isn't building all packages on armel, which has caused a cascade failure for image builds.
[01:11] <maxb> Purely a guess based on the timestamps at
[01:11] <maxb> http://gb.archive.ubuntu.com/ubuntu/project/trace/
[01:13] <maxb> cody-somerville: ah. He's already checked on cocoplum, ignore what I said
[01:16] <skaet> GrueMaster, urk   thanks for flagging.
[01:33] <slangasek> cody-somerville: putting the publisher in manual mode never affects mirroring
[01:34] <cjwatson> GrueMaster: details?  looking at it on the archive master system doesn't seem to bear out that claim
[01:37] <slangasek> I suspect he's looking at an artifact of syowa's mirroring problem (cf #is)
[01:37] <cjwatson> it seems likely, yes
[01:41] <cjwatson> ok, so that looks like it should be fixed soon
[01:41] <skaet> ubuntu headless (omap3, omap4) are off the builder,  and have been posted.
[01:42] <skaet> GrueMaster, ^
[01:43] <GrueMaster> cjwatson: https://launchpad.net/ubuntu/+source/ubiquity/2.6.9/+buildjob/2491220
[01:43] <GrueMaster> Or am I missing something?
[01:44] <GrueMaster> I also had an image build failure email.
[01:44] <slangasek> GrueMaster: those are the only two binary packages that are architecture-dependent
[01:44] <GrueMaster> Ah.
[01:45] <cjwatson> yeah, what he said.  notabug :)
[01:45] <slangasek> the rest are architecture: all - so you could indeed have seen problems because the arch: all packages, built as part of the i386 build, were published but the armel ones not
[01:45] <slangasek> (particularly given the aforementioned mirroring issue)
[01:47] <GrueMaster> I'm going to assume a false positive somewhere.  The email I have is from the headless omap3 image failing to build, but it is now on cdimage.u.c
[01:47] <GrueMaster> (nothing to see here, move along).  :P
[02:28] <skaet> xubuntu desktop i386, amd64 posted
[02:33] <kees> skaet: it looks like cyrus-sasl2-heimdal is not on the images, can I upload a fix for LP: #768707?
[02:33]  * skaet looking
[02:34]  * kees just added comment 1
[02:37] <kees> and now the debdiff
[02:37] <skaet> kees, can you give me some context on how its used?
[02:37]  * skaet looking at the debdiff too now
[02:38] <kees> skaet: when people use heimdal instead of mit kerberos with their sasl authentication, they need this package
[02:39] <kees> skaet: so, like dovecot, postfix, sendmail, using kerberos, but not mit kerberos
[02:39] <skaet> kees,  thanks for the context,  it was a new one for me.
[02:40]  * kees will be back in a little bit to upload it if it's approved. thanks for looking!
[02:47] <skaet> kees,  diff looks limited in scope,   go ahead and upload.  If we're in reasonable shape with the images we're smoke testing now, and a review of the dependencies doesn't reveal any surprises, we'll try to pull it in.  Otherwise we should be considering it as an SRU candidate.   Please also update the bug to reflect the importance, and milestone target.
[02:51] <charlie-tca> Ubuntu 386 desktop has the progress data at the bottom of the install, 64bit does not in hardwarew
[02:51] <ubot4> Ubuntu bug 386 in baz "change to removed files does not conflict" [Medium,Confirmed] https://launchpad.net/bugs/386
[03:03] <kees> skaet: thanks, uploaded
[03:03] <charlie-tca> ooops, eyes are getting tired. They both have the same progress reports
[03:04] <skaet> charlie-tca,  :)
[03:04] <charlie-tca> easier to see when I do them side-by-side
[04:02] <ScottK> Unseeded Universe packages are still open, so no release review of the cyrus-sasl2-heimdal  package should have been needed.
[04:04] <ScottK> kees: I don't like the hard coding.  Please have a look early in oneiric to put it back.
[04:42] <skaet> Edubuntu dvd i386, amd64 posted
[04:58] <skaet> kubuntu mobile i386 posted
[04:59] <skaet> ubuntu netbook omap3 + omap4 posted
[04:59] <skaet> GrueMaster, ogra_ ^^ fyi.
[05:07]  * skaet --> calls it a night
[06:14] <kees> ScottK: in oneiric it'll be totally dropped because cyrus-sasl2 merged heimdal finally
[06:15] <kees> but for natty we ended up with a -heimdal newer than the base, so i had to hardcode the versions
[06:15] <ScottK> kees: Great news.  Thanks.
[06:15] <kees> np
[06:15] <ScottK> Right, that's why I accepted it, just wanted to make sure the longer term got dealt with.
[06:18] <slangasek> kees: cyrus-sasl2 merged heimdal, yes, but we haven't merged that version of cyrus-sasl2 into Ubuntu... I skipped over it because it would pull heimdal into main
[06:19] <slangasek> is that the way we want to go?
[08:26] <kees> slangasek: i'm not excited about it for oneiric, but this solves it for natty at least (still in universe)
[08:26] <kees> slangasek: I assume we'll just keep the binaries in universe or something
[11:02] <pitti> lamont: 8002> ah, good to know; it worked for some builders, but I think these just timed out
[15:50] <ScottL> skaet, the qa iso release was a little surprising to me, did i misread natty schedule?
[15:50] <ScottL> skaet, oops, nevermind, i see the r"elease image built" listing
[15:52] <skaet> ScottL, if you've got questions about the plans for the next week, feel free to join us in #u-meeting,  as we do a last round table.
[15:52] <skaet> :)
[16:34] <robbiew> ScottK: sorry...so which bugs are you talking about?  the 2 listed on http://iso.qa.ubuntu.com/qatracker/build/kubuntu/all ?
[16:34] <ScottK> bug 557261
[16:34] <ScottK> bug 656486
[16:34] <ubot4> Launchpad bug 557261 in casper (Ubuntu) "The session live persistent with USB don't start, error in the prompt initramfs (affects: 1) (heat: 6)" [Medium,New] https://launchpad.net/bugs/557261
[16:34] <ubot4> Launchpad bug 656486 in xserver-xorg-video-ati (Ubuntu Natty) (and 3 other projects) "error de Video - [DRM: radeon_ttm_backend_bind] * * ERROR no pudo enlazar 1.772 páginas (affects: 7) (dups: 1) (heat: 37)" [Medium,Confirmed] https://launchpad.net/bugs/656486
[16:36] <ScottK> robbiew: Kubuntu images are marked failed by QA due to those, but they aren't Kubuntu specific, so I think foundations needs to assess if they are important enough to fix or can be release noted and dealt with later.
[16:38] <robbiew> ScottK...ack
[16:39] <robbiew> thnx
[16:39] <robbiew> they can both be release noted, imo
[16:49] <ScottK> Up to you.
[16:50]  * ScottK just doesn't want them hanging on Kubuntu specifically.
[17:20] <stgraber> skaet: Because of bug 695590 which won't be fixed for natty, we'll remove gally from Edubuntu. I'll be updating the seeds and meta soon. I'm just checking with highvoltage that we don't mention it anywhere on our website, documentation, screenshots, slideshow.
[17:20] <ubot4> Launchpad bug 695590 in python-kde4 (Ubuntu) "pykdeuic4's processUi() calls compileUi() with 3 args instead of the 4 required by PyQt4.uic.Compiler.compiler (affects: 10) (dups: 8) (heat: 82)" [Medium,Triaged] https://launchpad.net/bugs/695590
[17:21] <jibel> ScottK, robbiew looking at this bug it seems to be a kernel oops and hw specific. not related to kubuntu in any way.
[17:21] <slangasek> ScottK, robbiew: what was this about failed images?  Is that http://iso.qa.ubuntu.com/qatracker/result/5544/51 ?
[17:22] <skaet> stgraber,   thanks for letting me know.
[17:22] <ScottK> slangasek: Yes.
[17:22] <robbiew> slangasek: yeah...nothing to worry about, imo
[17:24] <slangasek> agreed, seems these bugs are nothing new
[17:24] <GrueMaster> Ok, I have narrowed down the oem-config issue on the headless images to between 2.6.5 & 2.6.6 release.  I believe it may be related to commit 4701 as that is the only one that looks like it touches the crash site.  Will remove this commit & see.
[17:26] <maco> skaet: is it too late for a11y patches to ubiquity for some of the stuff jibel's noticing?
[17:26] <maco> should i just send them to vinux?)
[17:27] <robbiew> too late
[17:30] <skaet> maco,  yeah,  best plan now is for them to be 0-day/SRU fixes - are there patches ready?  or still to be created?
[17:30] <ScottK> slangasek: Agreed.  I was reacting to the QA report about failed images in the release meeting.  I didn't have a chance to review it.
[17:32]  * slangasek nods
[17:33] <maco> skaet: i have one that's sorta halfway-there, was going to attack it with accerciser tonight.  but can ubiquity bugs be SRU'd?
[17:35] <ScottK> maco: I believe if you have internet access during the install it will update.
[17:35] <slangasek> they can be, but it's less effective for non-LTS releases (but what ScottK said)
[17:36] <maco> ok
[17:41] <ScottK> Even though Universe unseeded isn't frozen left, I'd like to start leaving a Universe package in queue in case we need a publisher run.
[17:42] <GrueMaster> So, do we have someone that can fix ubiquity, specifically oem-config?  I have it working by reverting revision 4701, but I am not familiar enough with the code to get a true fix for it.
[17:47] <stgraber> ^ is the removal of gally discussed before. Would be great to have this one approved soon so I can rebuild weblive and work on upgrade testing + have it on the next daily.
[17:47] <stgraber> thanks
[17:50] <ScottK> stgraber: No problem to accept it.  Why are you removing gally?
[17:51] <GrueMaster> skaet: Bug #769081 is release critical for ubuntu-headless-preinstalled-armel.  Marked it as high as I don't know if it affects other arches.
[17:51] <ubot4> Launchpad bug 769081 in ubiquity (Ubuntu) "oem-config-debconf crashes on armel headless due to undefined attribute. (affects: 1) (heat: 8)" [High,Confirmed] https://launchpad.net/bugs/769081
[17:51] <ScottK> (We have a candidate kdebindings patch that should make it buildable that we'll likely get in as a 0 day SRU)
[17:51] <stgraber> ScottK: maco asked us to remove it
[17:51] <skaet> GrueMaster,  ok.   Will work with slangasek and robbiew to see if we can come up with options.
[17:51] <ScottK> stgraber: Excellent reason then.
[17:51] <maco> ScottK: until the rebuild happens, it wont even start up
[17:52] <ScottK> So we'd need to get the bindings fix into -release.
[17:52] <maco> and i dont think itd look good to have something crashing on the live cd
[17:52] <ScottK> Agreed.
[17:52] <ScottK> It's unfortunate, but I think that's the best solution.
[17:53] <skaet> GrueMaster,  by other arches, armel ones,  or oem-config on other i386, etc.?
[17:53] <GrueMaster> oem-config on other platforms.  This doesn't appear to be armel specific.
[17:53] <GrueMaster> But it doesn't affect the netbook image.
[17:54] <GrueMaster> It may be visible in alternative image installs.
[17:54] <slangasek> I think you need cjwatson or ev for that (769081)
[17:54] <ScottK> I targetted/milestoned it for 11.04.
[17:54] <skaet> jibel,  ^^  can you see if you can get quick confirmation on the other archs if this is a problem?
[17:55] <ScottK> stgraber: Accepted.
[17:55] <stgraber> I can have a look at bug 769081 if cjwatson and ev aren't around, so we can have a fix by Monday
[17:55] <ubot4> Launchpad bug 769081 in ubiquity (Ubuntu Natty) (and 1 other project) "oem-config-debconf crashes on armel headless due to undefined attribute. (affects: 1) (heat: 8)" [High,Confirmed] https://launchpad.net/bugs/769081
[17:55] <stgraber> ScottK: thanks
[17:55] <skaet> stgraber,  that would be awesome!  Thanks!
[17:55]  * GrueMaster puts head back on and goes to test netbook.
[17:56] <ScottK> skaet: The other uploads I thought ought to perhaps go in today are desktop-file-utils, svgalib, and ubuntu-docs (this is our other after the release meeting conversation).
[17:56] <ScottK> slangasek: Could you take a glance at svgalib.  My non-C programmer brain suspects that's either obviously correct or obviously wrong to someone who knows C.
[17:57] <skaet> ScottK,  agree on the ubuntu-docs, and have scanned it earlier today.
[17:57] <ScottK> OK.  I'll accept that one then.
[17:58] <ScottK> Done
[17:59] <slangasek> ScottK: hmm, but the diff is to debian/rules? :)
[17:59] <ScottK> Oh, I was thinking of a different one.  Sorry.
[17:59] <ScottK> slangasek: Now that you've looked, what do you think?
[18:00] <slangasek> it's an imperfect fix; if chmod (somehow) fails to set the perms on a file, the error is ignored
[18:00] <slangasek> but that's pretty low risk
[18:01] <ScottK> If you think it should go in, now's the time.
[18:01] <slangasek> also pretty low gain, it only helps getting the package built on !x86 where it's also not particularly useful... but it's in universe... so pushing
[18:02] <ScottK> skaet: I've looked at desktop-file-utils and it's not an RC kind of issue, but it's low risk, so I'd say go ahead (the discussion in the bug has resolved my concerns about it).
[18:04] <skaet> ScottK,  right now confirming whether or not the langpacks did already get picked up.
[18:04] <skaet> If they did, we may not respin.
[18:04] <ScottK> Well you'll need to respin for docs anyway.
[18:04] <ScottK> Plus I expect we'll have to fix Ubiquity for GrueMaster's bug.
[18:05] <GrueMaster> Unfortunately, yes.  We have no way of updating this without a respin.
[18:06] <skaet> ScottK,  GrueMaster, depends on the scope,  but yes,  the docs should go in and be ready.
[18:07] <ScottK> It sounds like this is a fix it or don't release the headless images kind of situation.
[18:08] <GrueMaster> exactly.
[18:08] <skaet> if you and slangasek are comfortable with svgalib, I won't fuss.
[18:08] <ScottK> skaet: The docs update that was in queue is in.
[18:08] <skaet> ScottK, yeah, just saw that in the backscroll,  svgalib too.
[18:09] <skaet> ScottK,  can I ask you to hold off on the desktop-file-utils though until I study it a bit.
[18:09] <ScottK> So I think it's safe to say we're in for a respin independent of the language packs.
[18:12] <skaet> ScottK, agree its likely, for some images at any rate, but scope of respinning will depend on what else is found.   (and langpacks).
[18:12] <skaet> Edubuntu needs it
[18:12] <skaet> and some of the arm images (at a minimum).
[18:13] <ScottK> Plus the desktop images for the docs update.
[18:13]  * skaet nods
[18:13] <skaet> although the docs could be 0-day updates.
[18:13] <ScottK> Docs are already in.
[18:14] <ScottK> So it's a bit late for that.
[18:14]  * skaet nods 
[18:14] <slangasek> I apparently have the wrong branch of ubiquity checked out here; fixing that so I can see better what's going on with 769081
[18:15] <slangasek> stgraber: you commented "fix by Monday" - does that mean you're not comfortable tackling it yourself today?
[18:15]  * skaet -> lunch,  biab
[18:16] <stgraber> slangasek: If I look at it, it's going to be later this afternoon (on the bus back to Sherbrooke) or tonight. So if someone knows how to fix it and has time to do it before then, go ahead.
[18:17]  * stgraber lunch, back later
[18:17] <slangasek> stgraber: no clue how to fix it; maybe that will change, we'll see
[18:17] <stgraber> oops, that was meant for a /away :) anyway, talk to you later
[18:18]  * slangasek waves
[18:32] <slangasek> stgraber: yeah, I don't know my way around this code at all, I can't even figure out what self.ui is here
[18:34] <slangasek> rather, I can see that it's a "PageDebconf", but not how that's supposed to work with any of the *other* stuff (like set_timezone())
[18:39] <maco> slangasek: know where the "import debconf" pulls from?
[18:41] <maco> nvm found /usr/lib/python2.6/dist-packages/debconf.py
[18:43] <GrueMaster> Actually, self.ui.controller is defined in PageGTK (which we don't use in PageDebconf further down.
[18:44] <maco> i dont see PageGTK in ubi-timezone.py
[18:44] <slangasek> yes, I don't see where PageDebconf is supposed to inherit from /anything/ else... so is it also broken when trying to call self.ui.set_timezone, self.ui.set_timezone ?
[18:44] <slangasek> maco: PageGtk
[18:44] <maco> slangasek: i think PageDebconf inherits from plugins.PluginUI
[18:45] <maco> class PageDebconf(plugin.PluginUI):
[18:45] <slangasek> that's what the code says, yes
[18:45]  * GrueMaster loves well documented code.
[18:45] <slangasek> so either there are more latent bugs wrt self.ui, or I'm failing to understand the inheritance here
[18:45] <maco> cant find plugins.PluginUI though. lots of things inheriting from it...not finding its definition though
[18:46] <slangasek> plugins.PluginUI is a directory up in plugins.py
[18:48] <GrueMaster> Well, when I change line 597-598 in ubi-timezone to only "i18n.reset_locale(self.frontend, just_country=True)", it works, so the other self.ui calls should be ok.
[18:49] <slangasek> I think the other self.ui calls are just not being hit in the current code path
[18:49] <slangasek> and they probably break oem-config under other circumstances
[18:49] <maco> every other use of controller uses self.controller, not self.ui.controller
[18:50] <maco> oh wait... ubi-language has 4 uses of it with ui, and usersetup has 1
[18:51] <maco> related maybe?
[18:53] <GrueMaster> I just noticed that PageGTK & PageKDE are very similar in definition, but PageDebconf is almost non-existent.  I wonder if it just needs to be defined.
[18:55] <slangasek> given that we're all speculating, I'd say no solution we come up with should be pushed to the archive before review by someone who has an actual handle on ubiquity code
[18:56] <cjwatson> I'm not really here, not enough to write a patch, but I can do patch review with some delay on request
[18:56] <slangasek> ah, ok :)
[18:57] <cjwatson> I agree this is delicate
[18:57] <cjwatson> hm, thinking about it
[18:58] <cjwatson> the set_timezone/get_timezone stuff probably isn't a problem, because the oem-config debconf frontend doesn't have enough UI to hit it
[18:58] <cjwatson> but cleanup is called rather less conditionally
[18:59] <cjwatson> so try http://paste.ubuntu.com/597539/ ?
[18:59] <slangasek> GrueMaster: ^^ can you hot patch oem-config and give that a try?
[18:59] <GrueMaster> Will do.
[19:00] <cjwatson> maco: the ui element of a Page is a Page<Frontend>
[19:00] <cjwatson> so in Page you'll find self.ui.controller.blah, but in PageGtk etc. you'll find self.controller.blah
[19:00] <cjwatson> (I blame mterry)
[19:01]  * slangasek throws a mixin
[19:01] <cjwatson> yeah, run and ok_handler only get called in frontends that do debconf filtering, which the debconf frontend doesn't
[19:01] <cjwatson> (too many things called debconf, sorry)
[19:01] <cjwatson> so set_timezone/get_timezone aren't issues
[19:01] <slangasek> ok, cool
[19:02] <cjwatson> unless somebody rearranged everything some more while I wasn't looking
[19:04] <GrueMaster> Give me ~15 minutes to get results.  Have to reflash then edit before execute.
[19:04] <cjwatson> I'm off for dinner
[19:05] <cjwatson> I'll look in later and can upload if it works
[19:17] <skaet> ScottK,  could you look into:  kubuntu/daily-live: natty-desktop-amd64.iso oversized by 1269760 bytes (735272960)
[19:23] <GrueMaster> cjwatson: Looks good!
[19:24] <GrueMaster> Colors on oem-config are still wonky in screen, but it is during package removal so I'm not going to complain.  That can be resolved in Oneiric.
[19:28] <GrueMaster> bug 769081 updated & patch attached.
[19:28] <ubot4> Launchpad bug 769081 in ubiquity (Ubuntu Natty) (and 1 other project) "oem-config-debconf crashes on armel headless due to undefined attribute. (affects: 1) (heat: 10)" [High,In progress] https://launchpad.net/bugs/769081
[19:29]  * GrueMaster takes a small break.
[19:42] <ScottK> skaet: Yes.
[19:49] <ScottK> skaet: I just pushed the seed change.  IIRC it takes two publisher runs before you can rebuild the image.  I took advantage of the moment to add some language packs to the powerpc image since it's substantially under the size limit.
[19:58] <ScottK> I'm going at accept fgrlx-installer to make sure the publisher runs.  We'll need a Kubuntu DVD respin anyway since I changed the seeds.
[20:06] <skaet> ScottK,  have also accepted the desktop-file-utils,  agree with your assessment, and since we'll be respinning, it may as well be in.
[20:19] <ScottK> skaet: I noticed LibreOffice is still building so any relevant armel images (probably just Kubuntu) will need a respin for that at some point.
[20:19] <skaet> ScottK,  ok
[20:56] <cjwatson> GrueMaster: cool, will deal with an upload shortly then
[21:00] <jibel> skaet, I do not reproduce the oem-config-debconf crash on i386 and amd64 if that was your question. Are there specific steps to follow ?
[21:04] <cjwatson> jibel: I think we've moved on from that now :)
[21:04] <jibel> thanks :)
[21:07] <ScottK> cjwatson: I fiddled the Kubuntu seeds a little bit ago to fix oversize on live amd64 (and I bumped live powerpc up on langpacks since it had a lot of room).  Is there time that it would be worth a test respin of those images now before the respin we'll need anyway for your Ubiquity fix?  The publisher run that just started would be the second one since the see change (I don't recall if the two publisher runs counts to when the second run
[21:07] <ScottK> starts or when it finishes).
[21:09] <Daviey> o/ There are two libcgroup in natty unapproved queue.  I uploaded twice when dput seemed to fail.  Seems to be a false error returned (https://answers.launchpad.net/launchpad/+question/152715).  Apologies.
[21:11] <cjwatson> uploading ubiquity now; there's a slight discrepancy in tzsetup common.templates between 2.6.9 and 2.6.10, which I think is due to ev uploading from a built tree and tzsetup being a bit out of date with respect to tzdata.  I chose to leave this as it was rather than trying to do build system judo on a holiday; it shouldn't make much difference
[21:11] <cjwatson> ScottK: somebody else is worrying about respins at the moment, I hope - I'm just here very briefly
[21:22] <ScottK> skaet: The only seeded package pointed at -release now is Ubiquity.  Once there's a diff available I'll have a look at it.
[21:26] <ScottK> cjwatson: skaet: Ubiquity accepted.
[21:27] <ScottK> skaet: I gave an OK on #ubuntu-devel for some additional docs updates if they can be uploaded quickly (since we arleady are in respin territory).
[21:27] <cjwatson> thanks
[21:28] <ScottK> I'm glad you warned me about the timezone skew.
[21:28] <cjwatson> it's a lot easier to read in wdiff than diff -u
[21:39] <stgraber> cjwatson: Hi, any idea of what's the right way to fix bug 759545 for good ?
[21:39] <ubot4> Launchpad bug 759545 in grub2 (Ubuntu Natty) (and 1 other project) "user prompted to update unmodified grub configuration during Ubuntu server upgrade (affects: 1) (heat: 12)" [Medium,Triaged] https://launchpad.net/bugs/759545
[21:41] <ScottK> stgraber: I think that was fixed a few days ago.
[21:42] <Daviey> I'm not sure it was... smoser commented on it to me last night.
[21:43] <cjwatson> stgraber: I'm going to look at it with my Debian hat on post-natty, by rewriting all the ucf handling
[21:43] <Daviey> Ah, might be a differing bug
[21:43] <cjwatson> stgraber: it's not fixable for natty in a safe way now, IMO
[21:43] <smoser> its not grub's fault.
[21:43] <cjwatson> it sort of is, ish
[21:43] <smoser> its my fault. and i think we have to live with it.
[21:43] <cjwatson> I mean there are elements that are the fault of grub's packaging
[21:43] <cjwatson> but as I say
[21:43] <smoser> outside of adding "if this looks like a grub/default file that smoser screwed with, then be nice"
[21:44] <cjwatson> the fundamental problem is that we're applying ucf to /etc/default/grub *after* applying debconf answers to it, which is wrong
[21:44] <stgraber> cjwatson: ok, so we're fine having every upgrade prompting for /etc/default/grub ?
[21:44] <smoser> which is, somewhat what I am proposing at bug 768625 (for sudo). I'd like someone to take a look at that.
[21:44] <ubot4> Launchpad bug 768625 in sudo (Ubuntu) "user prompted for sudo changes on upgrade in ec2/uec image (affects: 1) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/768625
[21:44] <cjwatson> (or else we need to keep copies around of all the old versions of /etc/default/grub so that we can patch them in the same way)
[21:45] <cjwatson> stgraber: I'm not *fine* with it, but further attempts to fix it are too risky
[21:45] <cjwatson> that code is insane and best not touched in a rush
[21:45] <smoser> i would greatly appreciate it if someone could (offline from here) look at that sudo bug. it seems to me to be straight forward.
[21:47] <stgraber> cjwatson: agreed. Do we want that targeted to natty -updates or should we skip Natty completely and just fix it for Oneiric ?
[21:47] <cjwatson> oneiric
[21:47] <cjwatson> it'll be too substantial for an SRU, IMO
[21:49] <cjwatson> fwiw, it's not (at root) a new bug - we've had it in one form or another since we switched to grub2
[22:02] <slangasek> I'm very sad that we still have such problems with grub2
[22:03] <slangasek> is the fix not as simple as redirecting the debconf edits to whichever file ucf will use as input?
[22:03] <slangasek> (this is how samba does it; it's not perfect, but it's pretty good)
[22:04] <slangasek> and I realize the answer may well be a simple "no, it's not that simple" :)
[22:33] <micahg> I have a few more security uploads but could hold off until sat night, should I leave the builders free?
[22:40] <cjwatson> slangasek: that might end up being the answer, yes
[22:40] <cjwatson> slangasek: this is pretty much the one bit of grub2 that I have so far steered clear of touching, because I hate config file mangling code; I expect I'll just have to hold my nose
[22:41] <cjwatson> slangasek: how does samba deal with telling ucf the right set of md5sums, though?
[22:41] <cjwatson> this file has changed maybe five times in two years, keeping the list of md5sums isn't onerous, but I can only do that for the file before the debconf edits
[22:43] <slangasek> cjwatson: it never gives ucf md5sums, it always does 'ucf --three-way --debconf-ok "$NEWFILE" "$CONFIG"' where "$NEWFILE" is the file populated with the debconf answers
[22:43] <slangasek> there was some transition code to handle the migration to this from pre-ucf versions, using the md5sums of the stock files from various Debian and Ubuntu releases; that's been dropped from the maintainer script now as obsolete, but I could dig it up
[22:44] <slangasek> hmm, not the md5sums actually - bundled copies of the old default config files
[22:47] <cjwatson> perhaps that's the answer, then
[22:48] <cjwatson> I wouldn't mind looking at this with you at UDS, if we have time and I haven't fixed it by then already :)
[22:48] <slangasek> sounds good :)
[22:51] <ScottK> micahg: We're good on everything but powerpc,  I might be nice to let it catch up.
[22:52] <micahg> ScottK: k, I'll hold off till sat night, will you be around this weekend?
[22:52] <ScottK> I'll be gone most of the day tomorrow, but generally.
[22:53] <micahg> ScottK: cool, might need a release ack on sunday, not sure yet
[22:53] <ScottK> micahg: Shouldn't take that long to catch up, you can just monitor https://launchpad.net/builders
[22:53] <ScottK> Universe is still open for bugfix uploads, so just keep them coming.
[22:54] <micahg> ScottK: well, it's minitube, so might have new features, but idk if I have time for it
[22:54] <ScottK> OK.
[22:54] <ScottK> I'll be checking bugmail every now and then even during the day.
[22:56] <micahg> cool, tuesday at noon UTC is the cutoff for universe?
[23:12] <ScottK> IIRC, yes.
[23:52] <ScottK> skaet: Everything that was pending is built and published and i386 and amd64.  All except LibrOffice is done on armel (which IIRC only affects the Kubuntu image).  powerpc has a ways to go.
[23:53] <ScottK> So, modulo language pack exports, this is a good time for respins.