[01:44] <wgrant> slangasek, cjwatson: Since skaet doesn't seem to be around, is there any problem with doing an LP fastdowntime rollout during the usual window (in around 7 hours)? The 0802 publisher run will be skipped.
[01:47]  * ScottK doesn't know of any reason it would be a problem.
[02:02] <wgrant> We avoided them Mon-Thu due to beta. But I assume it's fine now.
[03:08] <slangasek> wgrant: I also don't know of any reason
[03:11] <wgrant> slangasek: Thanks.
[03:20] <slangasek> infinity: I think you may have misunderstood bug #820514
[03:20] <ubot4> Launchpad bug 820514 in ubiquity (Ubuntu Oneiric) (and 1 other project) "oem-config-remove-gtk not found during preinstalled desktop initialization (affects: 1) (dups: 1) (heat: 14)" [High,Confirmed] https://launchpad.net/bugs/820514
[03:21] <slangasek> infinity: it's not "selecting something to execute"; it's "you have ubiquity present, but not the package providing the script that cleans up after ubiquity in oem-config mode"
[03:22] <slangasek> infinity: if you have ubiquity-frontend-gtk, and you want to use oem-config, you're meant to have oem-config-gtk *to clean up ubiquity*.  Is there a reason oem-config-gtk can't be seeded here?
[03:36] <ScottK> I'm curious if there's some special rule requiring every other ubiquity upload to FTBFS?
[03:38] <micahg> must be one of those hard coded launchpad things
[03:57] <infinity> slangasek: Err, what?  oem-config-gtk is the GTK frontend to oem-config.  How is calling that from the command-line ever going to yield useful results?
[04:01] <infinity> slangasek: Both oem-config-remove and oem-config-remove-gtk do exactly the same thing (though the shell version sure is more readable), but oem-config-remove-gtk is a pygtk application.  The bug is that it's trying to call the pygtk app from debconf frontend.
[04:15] <ScottK> Could lack of oem-config-remove cause a hang on shutdown after prepare for shipping?
[04:17] <hyperair> ScottK: ping. could you ack an upload of banshee please? there's a unity lens bugfix thing
[04:17] <hyperair> yeah, that.
[04:17] <ScottK> I was just looking at the queue.
[04:18] <ScottK> Speaking of which ...
[04:18] <hyperair> :)
[04:18] <hyperair> speaking of which?
[04:18] <ScottK> infinity or slangasek: Would one of you please accept kde-baseapps.  It's hurting me to watch it languish there.
[04:19] <ScottK> hyperair: Waiting for Launchpad to generate the diff for review.
[04:19] <hyperair> alright
[04:21] <infinity> ScottK: Didn't you hear?  We're dropping kubuntu for final.
[04:22] <ScottK> Great.  More free time for me.
[04:22] <slangasek> infinity: ah - then *I* misunderstood, I thought oem-config-remove-gtk did different things on cleanup
[04:23] <infinity> slangasek: Not from what I can tell in reading them.  Unless "different things" means "fires up python and a ton of pretty GUI bindings".
[04:23] <slangasek> heh
[04:23] <infinity> slangasek: The actual package removal list in each is identical.
[04:23] <slangasek> ok then
[04:24] <infinity> ScottK: Accepted.
[04:24] <ScottK> Thanks.
[04:25] <infinity> ScottK: Oh, and to answer your other question, it could be the same bug we're seeing on preinstalled systems, if you have a GUI/live-ish seed installed, but you're using the texty oem-config to boot/prepare/shutdown.
[04:25] <ScottK> The problem I'm having is the shutdown hangs.
[04:25] <infinity> ScottK: If you do your prepare from a GUI, one would hope that the GUI removal bits would work on prepare.  But hey, that could be broken too. :P
[04:26] <ScottK> There is no KDE version of the GUI removal bits.
[04:26] <infinity> ScottK: Hanging can certainly be a symptom of being unable to call stuff.  Or entirely unrelated. ;)
[04:26] <ScottK> Shuts down just fine, every time without oem-config running.
[04:27] <infinity> After it hangs and you reboot, do you still have some packages installed that you shouldn't?
[04:27] <ScottK> Didn't check.
[04:27] <infinity> If so, could very well be a similar issue.
[04:27] <ScottK> Good point.
[04:32] <ScottK> infinity: If you're feeling brave, the python-defaults upload should fix some FTBFS.
[04:32] <ScottK> And if it breaks the world, it'll give doko_ something to play with when he wakes up ....
[04:41] <ScottK> Cool.  Thanks.
[04:41] <ScottK> doko_: ^^^ python-omniorb should build now.  If not, complain to POX.
[04:41] <ScottK> ~now
[04:46]  * ScottK holds his nose and accepts banshee
[04:52] <ScottK> (accepted it since you asked, but I think the idea behind the patch is quite unfortunate on many levels)
[08:16] <doko_> ScottK, still ftbfs
[08:58] <Daviey> Can i ask for a second opinion on bug 852479 ? The delta is *huge*, but fixes Security, High and Medium bugs.
[08:58] <ubot4> Launchpad bug 852479 in asterisk (Ubuntu) "Merge asterisk 1:1.8.4.4~dfsg-2 (universe) from Debian unstable (main) (affects: 1) (heat: 6)" [Wishlist,In progress] https://launchpad.net/bugs/852479
[08:59] <Daviey> We quite like aligning as close as possible with Debian on this package, and I really don't fancy the time it takes to cherrypick the Security and High fixes.
[08:59] <Daviey> Universe package.
[08:59] <Daviey> but semi-supported.
[10:31] <ScottK> doko_: Rats.  Please ask POX then.
[10:32] <ScottK> Daviey: In general, I think it's better to release slightly broken than with known security issues, so without knowing any details, I'd be inclined to say go for it.
[10:33] <Daviey> ScottK: that was my thoughts, thanks.
[10:39] <Daviey> Please can an AA promote glance based on bug 801299 MIR approval, thanks
[10:39] <Daviey> (it's blocking nova builds)
[10:55]  * Daviey notes that https://wiki.ubuntu.com/StandingFeatureFreeze should probably be updated or dropped.
[10:55] <ScottK> Gnome is the only thing that applies to, so updating should be easy enough.
[11:05] <ev> pitti: heads up: pygobject 3 breaks ubiquity as custom widgets instantiated via GtkBuilder no longer have their __init__ methods called.
[11:10] <ev> https://bugzilla.gnome.org/attachment.cgi?id=194787 fails on a fully up to date system as well
[12:30] <jdstrand> Daviey: I am not on the release team so I have no authority, but my opinion is *please, please* update the asterisk source. asterisk maintenance is hard enough without having to backport fixes
[12:31] <Daviey> jdstrand: already uploaded and published :)
[12:31] <jdstrand> perfecto!
[12:31]  * jdstrand hands Daviey a gold start
[12:31] <jdstrand> star
[12:33] <Daviey> \o/
[12:38] <Laney> ^ please accept
[12:45] <cyphermox> could someone please ack the network-manager-applet upload?
[12:54] <ScottK> Laney: Done.
[13:03] <Laney> thanks
[13:51] <seb128> could somebody review thunderbird-couchdb from NEW?
[13:51] <seb128> it's required to have u1 contact syncing with tb
[13:52] <seb128> which is something we want to work out of the box in Oneiric (the package is late but it was blocked on couchdb to start working which it didn't do for most of Oneiric)
[13:58] <skaet> seb128, +1 on that.   If another member of the release team with more familiarity doesn't beat me to it,  I'l take a pass on it after the meeting today.
[13:59] <seb128> skaet, thanks!
[14:25] <jbicha> hi, could we get pitivi pushed through?
[14:28] <ScottK> jbicha: Done
[14:29] <jbicha> thanks
[14:49] <cyphermox> ScottK: could you please release network-manager-applet?
[14:50] <ScottK> cyphermox: I took a glance at it and it's way too much diff for me to be comfortable with reviewing/accepting.
[14:50] <cyphermox> ah ok
[14:51] <Daviey> Is the release meeting on today?
[14:51] <cyphermox> I had discussed this shortly with pitti, much of the diff is that a library for the wireless and mobile dialogs was split out of the nm-applet binary so that they could be used by gnome-control-center
[14:51] <skaet> Daviey,  ypu
[14:51] <skaet> yup even.
[14:53] <Daviey> ugh.. better prepare. :)
[15:26] <Daviey> ScottK: Hmm, not sure how that blueprint got missed from the overview
[15:26] <Daviey> gah
[15:26] <Daviey> (I hate the blueprint tracker btw :)
[15:26] <ScottK> Dunno.
[15:27] <ScottK> There you go.  More reason it doesn't reflect reality.
[15:37] <skaet> Daviey,  just add it to the topic, and it will start to track
[15:40] <Daviey> skaet: yes, but i'm not sure *how* it got missed.
[15:40] <skaet> Daviey,  fair 'nuf. :)   will let you and robbiew sort it.
[16:38] <didrocks> ScottK: skaet: can you please look at oneconf in the queue? It's simply a timer change (I set it to 30s in the post beta2 version for debugging and forgot to remove it before upload), that will enable to not hurt the server too much during the week-end ;)
[16:38] <ScottK> diff is still pending
[16:41] <didrocks> ScottK: just for next time I don't annoy you before the diff is there, what page are you using to get the diff? not https://launchpad.net/ubuntu/oneiric/+queue?queue_state=1&queue_text=, the package page? diff is on it: https://launchpad.net/ubuntu/+source/oneconf/0.2.6.6
[16:41] <ScottK> didrocks: Just accepted.  https://launchpad.net/ubuntu/oneiric/+queue?queue_state=1
[16:41] <ScottK> It wasn't there when I'd looked before.
[16:42] <ScottK> It takes some time for LP to generate them.
[16:42] <didrocks> ScottK: thanks! but you just check on the package page, isn't it?
[16:42] <didrocks> like https://launchpad.net/ubuntu/+source/oneconf/0.2.6.6
[16:42] <ScottK> No.  The diff is on the +queue page.
[16:43] <didrocks> ah indeed, the line is just missing until it's generated, thanks for the info :)
[17:18] <ScottK> Seems like we lost the queue bot.
[17:18] <ScottK> cjwatson: ^^^
[17:20] <cjwatson> huh
[17:20] <cjwatson> flood alert
[17:21] <cjwatson> thanks for the note, I'd missed that
[17:21] <infinity> So... Much... Purple... Text.
[17:27] <Daviey> please can an AA accept cloud-init.
[17:27]  * infinity looks.
[17:28] <Daviey> Yes, including a Licence as a patch is wrong IMO..
[17:29] <infinity> Heh.
[17:29] <infinity> Rather.
[17:29] <Daviey> and carrying every damn upstream patch, rather than cutting a new release is wrong.
[17:29] <infinity> Oh well, it looks otherwise sane.
[17:33] <infinity> cjwatson: grub seems to have a much larger diff (postinst.d, etc) than the changelog would suggest.
[17:34] <infinity> cjwatson: The changelog clash between you and mvo in the diff would suggest perhaps a disgareement between your local copy and the archive reality?
[17:35] <Daviey> Is this really being tracked as release crtiical https://launchpad.net/bugs/852583 ?
[17:37] <infinity> Daviey: Hey, cosmetic things are important.  If you had buggered icons in the default install (say, the Ubuntu logo was green), it would be RC, right?  Now, pretend you're blind. ;)
[17:38] <Daviey> infinity: did you make an assumption that I wasn't?
[17:38] <infinity> Daviey: I'm not sure we've met.  But it's a fair assumption to make of the general population.
[17:39] <infinity> Either way, I'm not sure it's RC either, but it's also a simple and non-intrusive fix.  Someone should just upload it.
[17:39] <infinity> (Then again, I wouldn't care if logos were the wrong colour either, as long as no one messes with my terminals)
[17:41] <Daviey> infinity: You know we are defaulting to orange/purple split for termianls?
[17:41] <Daviey> Ubuntu branding.
[17:41] <infinity> </3
[17:41] <ScottK> Terminals are still nicely black by default in Konsole, so do whatever you want elsewhere ...
[17:56] <infinity> cjwatson: I'm going to reject that grub upload because of my above comments, re: dropped/clashed revisions.
[18:00] <cjwatson> infinity: hmm
[18:01] <cjwatson> yes, you're right about disagreement
[18:01]  * cjwatson goes to resolve
[18:02] <cjwatson> hah, what fun
[18:03] <cjwatson> my version was tagged in bzr and everything!  I must have missed the reject mail
[18:04] <cjwatson> or maybe the upload broke
[18:04] <cjwatson> no .upload file locally, I guess something went wrong such that my ubuntu-release script didn't actually upload it
[18:08] <infinity> FWIW, when working from a VCS, I tend to still apt-get source and debdiff against the previous version.
[18:09] <infinity> Usually to make sure I didn't introduce cruft from my working copy, but it avoids this sort of thing too.
[18:09] <cjwatson> I normally do, I'd just forgotten that anyone else was insane enough to upload grub
[18:09] <infinity> Hahaha.  That's fair. :)
[18:16] <skaet> cjwatson, am working through the thunderbird-couchdb patch,  and there's a /debian/copyright file, that has me wanting to cross check what the usual and reasonable is here.
[18:17] <ScottK> skaet: Can you pastebin it somewhere?
[18:17] <skaet> The fix part seems straight forward,   but do I need to do an audit of the original package now too,  to ensure the debian copyright is ok?
[18:17] <skaet> ScottK,  doing...
[18:17] <cjwatson> where's this?  don't see it in the queue
[18:18] <infinity> skaet: tb-couchdb in NEW?
[18:18] <cjwatson> there are scripts to help with licence checking
[18:18] <infinity> skaet: We do tend to audit NEW packages to make sure debian/copyright actually jives with reality.
[18:18] <skaet> infinity,  yup.
[18:18] <infinity> And yes, apparently there are now scripts to help with that.
[18:18] <infinity> (I feel old)
[18:18] <skaet> it was weird it was added with a patch.
[18:18] <cjwatson> err
[18:18] <skaet> cjwatson,  coolio.   link please.
[18:19] <cjwatson> it looks perfectly normal to me
[18:19] <cjwatson> it's in the Debian diff
[18:19] <infinity> Yeah...
[18:19] <skaet> cjwatson yes,  whats weird to me is why it wasn't in the original.
[18:19] <infinity> skaet: The orig shouldn't have a debian directory at all.
[18:19] <skaet> rather than showing up in the diff,  with a limited fix.
[18:19] <infinity> skaet: diff.gz == The debian packaging.
[18:20] <infinity> skaet: orig.tar.gz == the upstream tarball.
[18:20] <cjwatson> We would not expect debian/copyright to be upstream.
[18:20] <skaet> yah,  that makes sense.   Thanks for the explanation.
[18:20] <cjwatson> and I don't know what you mean by "limited fix"
[18:20] <ScottK> We would, in fact, be annoyed if it was.
[18:20] <cjwatson> the script I'm referring to is 'licensecheck', but it doesn't seem to understand this particular set of files very well, so probably needs by-hand inspection
[18:21] <infinity> Wow, this is really triple-licensed?  Whacky.
[18:21] <cjwatson> still, it looks correct to me
[18:21] <skaet> cjwatson,  it was my misunderstanding.   After the above explanation, it makes more sense now.
[18:21] <cjwatson> fairly straightforward tri-licensed Mozilla stuff
[18:21] <micahg> infinity: most of the mozilla products are
[18:22] <infinity> micahg: Yeah, but this isn't from Mozilla upstream.
[18:22] <cjwatson> and the copyright file syntax looks fine
[18:22] <infinity> micahg: I guess it makes sense to be in line with, though.
[18:22] <skaet> cjwatson,  I'll do the by-hand inspection,  no worries.    Just needed to be educated a bit it seems.
[18:23]  * skaet knows license inspecting by hand only too well.... :P
[18:23] <ScottK> grep -ir copyright *less
[18:23] <cjwatson> the packaging looks OK, although I trust somebody has a good reason for why it needs to have hardcoded dependencies on specific library versions
[18:23] <ScottK> err
[18:23] <ScottK> grep -ir copyright * | less
[18:24] <cjwatson> presumably because no shlibdeps facility is available; I guess we just have to bump it manually
[18:24] <GrueMaster> erm, problem with the ubuntu-core naming at http://cdimage.ubuntu.com/ubuntu-core/releases/oneiric/beta-2/.  ubuntu-core-11.10-beta2-core* .  core is redundantly duplicated.
[18:24] <cjwatson> ah, yes, javascript ctypes binding
[18:24] <cjwatson> GrueMaster: file a bug on the ubuntu-cdimage project, please, explaining how you'd like to iit to look instead
[18:24] <cjwatson> *like it to
[18:24] <infinity> GrueMaster: Yeah, I know.  It was like that in beta-1 as well.  I might muck with the release scripts before release to make it prettier.
[18:24] <cjwatson> (my preference would be to drop the first "core")
[18:24] <infinity> cjwatson: That's my preference too.
[18:25] <infinity> cjwatson: Just means futzing with for-project (or just using for-project ubuntu to publish instead of ubuntu-core)
[18:25] <cjwatson> look at server - we do the same for that
[18:25] <cjwatson> should preferably follow the same pattern
[18:25] <infinity> Server is for-project ubuntu, I believe.
[18:25] <infinity> IIRC.
[18:25] <GrueMaster> We seem to hit this problem with every new image.  We had the same problem with desktop & server iirc.
[18:25] <cjwatson> yes, but there are hardcoded bits in various scripts to help
[18:25] <cjwatson> GrueMaster: no, not every new image.  (trust me.)
[18:25] <infinity> So, yeah.  SHould probably just drop core from for-project, and do it the same.
[18:26] <infinity> GrueMaster: Just images that don't follow standard schemes (and preinstalled was equally different)
[18:26] <cjwatson> yeah, preinstalled still bites me occasionally.
[18:28] <GrueMaster> Also, there are no manifest files for the preinstalled-[server|desktop] images.
[18:30] <cjwatson> manifest files are produced by the livefs builds
[18:30] <cjwatson> I think
[18:31] <cjwatson> do the preinstalled builds produce them?
[18:31] <infinity> They do.
[18:31] <cjwatson> hmm
[18:31] <infinity> We don't publish manifests for releases.
[18:31] <infinity> Not for ISOs either.
[18:31] <infinity> This isn't new.
[18:31] <cjwatson> *blink*
[18:32] <cjwatson> we certainly do for livefseslive CD images
[18:32] <cjwatson> cf. http://releases.ubuntu.com/natty/
[18:32] <infinity> Oh wait, yeah.
[18:32] <infinity> *blink*
[18:32] <infinity> Where was I looking last time I thought this was true? :P
[18:32] <cjwatson> and the code seems to try to fetch the manifest unconditionally ...
[18:33] <infinity> No, you're right.
[18:33] <GrueMaster> And http://cdimage.ubuntu.com/releases/oneiric/beta-2/ has manifests for everything but armel atm.
[18:33] <infinity> Hrm.
[18:33] <cjwatson> ah, but publish-release is more conditional about it
[18:33] <infinity> p-r only does it for certain exts?
[18:33] <cjwatson> notice they're on http://cdimage.ubuntu.com/daily-preinstalled/current/
[18:33] <cjwatson>         if [ "$TYPE" = live ] || [ "$TYPE" = desktop ] || \
[18:33] <cjwatson>            [ "$TYPE" = netbook ] || [ "$TYPE" = mid ] || \
[18:33] <cjwatson>            [ "$TYPE" = moblin-remix ] || [ "$TYPE" = uec ] || \
[18:33] <cjwatson>            [ "$TYPE" = server-uec ] || \
[18:33] <cjwatson>            ([ "$TYPE" = dvd ] && [ -e "$base.manifest" ]); then
[18:33] <cjwatson> (feel free to vomit)
[18:33] <infinity> Vomiting, sir.
[18:33] <cjwatson> let me turn that into a case statement...
[18:34] <infinity> Why the test at all?
[18:34] <infinity> manifests only exist if produced, and if produced, we want them?
[18:34] <cjwatson> I wanted to error if they should be there but weren't
[18:34] <infinity> Ah.
[18:35] <infinity> Still ew, but at least understood now. :P
[18:35] <GrueMaster> personally, I can't think of a reason not to have manifests with the images (except netinstall...maybe).  They are a very convenient way of determining what package version is in an image.
[18:36]  * infinity still wonders what he was once looking at that led him to believe we have no manifests in simple/releases.
[18:36] <infinity> Maybe I just glanced at alternates, and wasn't awake.
[18:36] <infinity> GrueMaster: No, I agree, they're quite handy.
[18:37] <skaet> hmm..   after scanning the files,   went to accept the package and got a FAILED: thunderbird-couchdb (The source thunderbird-couchdb - 0.0.1-0ubuntu1 is already accepted in ubuntu/oneiric and you cannot upload the same version within the same distribution. You have to modify the source version and re-upload.)
[18:37] <cjwatson> GrueMaster: you don't need to persuade us :)
[18:37] <infinity> skaet: Maybe Colin beat you to it. :)
[18:37] <cjwatson> I did not
[18:37] <cjwatson> maybe it was uploaded twice?
[18:38] <skaet> I'm not seeing if from the bot....   maybe.   I'll go check what's in the archive.
[18:38] <cjwatson> the bot wouldn't say
[18:38] <cjwatson> I don't think
[18:38] <infinity> https://launchpad.net/ubuntu/+source/thunderbird-couchdb/0.0.1-0ubuntu1
[18:38] <cjwatson> pretty sure it shoves everything into a hash or some such
[18:38] <cjwatson> you need to look at the actual records in LP
[18:38] <infinity> Already built, with binaries in NEW.
[18:39] <infinity> Though that was only a few minutes ago.
[18:39] <infinity> So, maybe your ACCEPT onthe web form just triggered twice.
[18:39] <infinity> And the second (rightly) failed.
[18:40] <skaet> infinity,  weirdness, but that seems to explain what I'm seeing.
[18:40] <infinity> (The publishing record was created 6.5 minutes ago)
[18:40] <cjwatson> GrueMaster: future preinstalled-* releases will have manifests
[18:40] <GrueMaster> ok
[18:40] <GrueMaster> thanks
[18:40]  * skaet needs to watch how hard she presseses down on key board it seems. :P
[18:41]  * GrueMaster goes and retrives them from prior daily image dirs for now.
[18:41] <skaet> thanks for the help infinity, cjwatson, ScottK
[18:41] <cjwatson> GrueMaster: some images don't have .manifest files but have listings in other formats due to not being live filesystems; I like to use different extensions when the file format is different
[18:42] <infinity> Do we have anything other than .list and .manifest?
[18:42] <GrueMaster> hrm.  Not really a good idea.  The manifest should just list packages and versions contained in an image, regardless of image type.
[18:42]  * skaet heads for lunch
[18:42] <GrueMaster> Doesn't make much sense for different names.
[18:43] <infinity> GrueMaster: .list is actually a file list (think alternate ISOs)
[18:43] <infinity> Though having a manifest of the debs in an alternate ISO wouldn't be an awful idea.  *shrug*
[18:44] <GrueMaster> If it boots and runs something, it should have a manifest of the stuff used to make it boot and run stuff.  Even if it just boots and installs debs from a pool somewhere.
[18:45] <infinity> diff from 7.0.9-0.0.ubuntu1 (in Ubuntu) to 9.4.2.0-0oneiric1 <-- Welcome to things I don't want to read.
[18:45] <GrueMaster> Makes debugging boot issues a little easier, especially when trying to determine what file may have caused an issue.
[18:45] <cjwatson> GrueMaster: there really are differences relevant to me
[18:46] <cjwatson> GrueMaster: d-i images don't have anything preinstalled, and the set of packages and versions you get out of them is highly variable and not easily computable by cdimage; furthermore the .list file, which contains a list of all files in the image, is useful in its own right and supplies that information
[18:47] <GrueMaster> fair enough.
[18:48] <cjwatson> I suppose infinity's right, there would be worse things than having bits of .list extracted into .manifest
[18:48] <cjwatson> it seems redundant to me but if people find it useful it's possible
[18:48] <cjwatson> but it should be everything, not an attempt to define which bits are needed to boot and run stuff, IMO
[18:49] <cjwatson> well, all debs
[18:51] <infinity> Yeah, I would envision it as a manifest of every *deb in the image, munged to match the dpkg -l output format in the live manifests.
[18:51] <infinity> Then you could diff alternate and live for package differences, say.
[18:52] <infinity> That might be vaguely handy to someone.
[18:54] <cjwatson> yeah, true
[18:59]  * infinity opts out of reviewing acroread today, and hopes someone else does it.
[19:01] <ScottK> infinity: You could just say "Meh, partner" and accept.
[19:01] <infinity> I at least like to give partner stuff a once-over to make sure it's not full of maintainer script fail.
[19:02] <infinity> But yes, there's a certain element of "plug my nose and accept".
[19:04] <infinity> Now, a binary package with no maintainer scripts, and shipping one file.  That, I'm happy to review. :P
[19:04] <infinity> (Yay, tb-couchdb)
[19:06] <seb128> thanks to whoever newed it
[19:06] <seb128> tb-couchdb
[19:06] <infinity> It was a group effort.
[19:06] <seb128> there is also caribou in NEW if somebody wants to get to it ;-)
[19:06] <infinity> Yeah, I saw that...
[19:06] <jbicha> caribou was ffe bug 845300
[19:07] <seb128> it has a ffe approved and got sponsored by pitti before but it had an issue, I just sponsored a hopefully fixed version from jbicha
[19:07] <seb128> who just just commented while I was typing ;-)
[19:07] <infinity> Heh.
[19:07] <infinity> I don't suppose there's a diff somewhere between the rejected one and this?
[19:07] <seb128> it's needed to fix gnome-shell which is not installable and build-deping on caribou
[19:07] <infinity> So I don't have to review from scratch. :P
[19:08] <seb128> jbicha, ^ ;-)
[19:09] <ScottK> Or just take the current package, add one really awful thing at random, diff that and hand it in ....
[19:10] <infinity> ScottK: You're in rare form today. ;)
[19:11] <cjwatson> echo 'Just ask infinity' >debian/copyright
[19:11] <jbicha> infinity: http://bazaar.launchpad.net/~jbicha/+junk/caribou/revision/2
[19:11] <infinity> jbicha: Does that include whatever it was Martin "fixed" before the last upload?
[19:11] <infinity> (I'm assuming the two DEP fields)
[19:12] <cjwatson> echo '#! /bin/sleep 2147483647' >debian/rules
[19:12] <infinity> jbicha: Also, why was the first rejected? :P
[19:12] <jbicha> infinity: he fixed debian/copyright
[19:13] <jbicha> we rejected it because Debian wanted to change some things first to avoid having to mess with Conflicts/Replaces fun
[19:13] <infinity> Ahh, so it wasn't on grounds of incompetence, just to avoid version rev mess.
[19:13] <infinity> Check.
[19:13]  * infinity goes about kicking the tires.
[19:15] <jbicha> infinity: it works in Unity or Fallback, I can't figure out how to get it to run in gshell though :(
[19:16] <jbicha> maybe it's conflicting with onboard
[19:17] <infinity> jbicha: I'm kicking the tires on the packaging, not the upstream source.  If it's buggy, that's your problem. :P
[19:17] <jbicha> :)
[19:17] <seb128> ^ nm-applet, I rejected it on cyphermox's request
[19:18] <seb128> he will upload it again with a replaces fix
[19:26] <infinity> jbicha / seb128: Seems sane (and it was good that you waited on the module split, that would have been gross to fix), accepted.
[19:26] <infinity> jbicha: If it procceds to FTBFS, I expect you'll fix it yesterday? ;)
[19:26] <seb128> thanks
[19:29] <jbicha> infinity: yes, thanks
[19:48] <jbicha> infinity: can we get the NEW caribou packages pushed too?
[19:52] <seb128> infinity, can we get the other packages in the queue reviewed?! ;-)
[19:52] <infinity> Yes, yes.
[19:53] <infinity> My laptop is busy dying a painful death, I'm working at half capacity here on an ARM netbook with a UK keyboard. :P
[19:56] <cjwatson> I'll attack it shortly
[19:57] <cjwatson> just trying to finish with the three independent Xen-installation blockers I've been fixing today
[19:57] <infinity> I'm already on it.
[19:58] <infinity> And accepted.
[20:32] <skaet> cjwatson, infinity - accepted a couple of the ones that looked fairly straightforward.
[20:39] <cjwatson> grub-installer is a fairly large diff, but it halves the delta against Debian, most of the changes are me deliberately upstreaming stuff to Debian in somewhat different ways, I figured the translation improvements would be good, and we want the preseeding fix from 1.68
[20:39] <cjwatson> on balance it looked better to merge than to cherry-pick
[20:41] <cjwatson> the only actual new feature is mipsel/loongson-2f support, which is irrelevant for us :)
[20:44] <cjwatson> ah, slight tweak though ...
[20:54] <infinity> cjwatson: Is there any chance that anything in d-i might turn on binfmt_misc support, ever?
[20:54] <infinity> cjwatson: Or, I guess, while grub-installer is running, which seems less likely. :P
[20:54] <cjwatson> infinity: I wouldn't like to rule it out I suppose, but I haven't thought of a reason for it
[20:54] <infinity> cjwatson: (Just pondering if your umount might fail)
[20:54] <cjwatson> Why?
[20:55] <cjwatson> Would it go wrong if binfmt_misc were enabled before grub-installer runs?
[20:55] <cjwatson> Seems not, it would have to be specifically enabled in the target system for that to go wrong, wouldn't it?
[20:56] <cjwatson> This code does run in ubiquity as well, so binfmt_misc might well be enabled in the primary system, but surely not in the /target chroot
[20:57] <infinity> Yeah, seems pretty unlikely.
[20:57] <infinity> I think I'm still chafing from binfmt_misc hatred on the buildds recently. ;)
[20:57] <cjwatson> Yeah, thought that might be the case ...
[20:57]  * cjwatson gives grub a second go, and starts working on the SRU bits of that
[20:59]  * infinity raises an eyebrow at the pedantic sentence-spacing fixes. 
[20:59] <infinity> Nice to know someone cares deeply about that. :P
[21:00] <infinity> And clever abuse of shell-quoting with the ensure-active call.  That almost seems too clever.
[21:00] <infinity> (THank god it's commented)
[21:01] <cjwatson> Heh, what happened there was that I wrote the original Ubuntu-specific code years ago, and did the Debian code (where I finally got round to doing it right, using libparted) this year
[21:01] <infinity> Looks good to me, though, from the POV of how unreviewable a change that large is.
[21:01] <cjwatson> and in between, I changed my personal style to be two-spaces-after-full-stop
[21:01] <cjwatson> so yeah, pedantry
[21:01]  * slangasek goes through the archive adding half-width non-breaking spaces
[21:02] <infinity> ...
[21:02] <cjwatson> ensure-active> actually that probably doesn't matter since ensure-active.c tests *argv[2]
[21:02] <cjwatson> I think it may have mattered in an earlier version of the code
[21:02] <infinity> Oh balls, I just accepted grub instead of grub-installer.  Fat fingers ahoy.
[21:02] <slangasek> infinity: you know you envy the French !
[21:02] <infinity> cjwatson: Reassure me that the grub upload was mvo's + your changes in the last one? :)
[21:03] <cjwatson> infinity: better review it quick!
[21:03] <cjwatson> yes, I checked that this time
[21:03] <cjwatson> http://paste.ubuntu.com/695834/
[21:04] <infinity> cjwatson: Lovely.
[21:05] <cjwatson> I'm not sure any GRUB Legacy change counts as lovely, but
[21:05] <slangasek> the "full deletion" one does :)
[21:05] <infinity> The diff was what I expected it to be this time, and readable to boot.  Lovely enough for a Friday afternoon.
[21:05] <infinity> All will be erased with beer soon enough.
[21:05] <cjwatson> slangasek: Xen :-/
[21:06] <slangasek> pshaw
[21:06] <cjwatson> Give me a solid month without distractions to port GRUB 2 to Xen ...
[21:06] <slangasek> heh
[21:06] <infinity> Will pv-grub2 really be that much work?
[21:06] <cjwatson> (Actually it's probably not quite that bad, but the "distractions" bit killed me this cycle)
[21:07] <cjwatson> I have a complete design for it now and I think it's straightforward, there's just a tedious bit of writing a xenstore client at the start
[21:07] <cjwatson> It's probably actually a week of uninterrupted coding timee
[21:07] <infinity> Can't cargo-cult bits from the current pv-grub?
[21:07] <infinity> Or is it vile?
[21:08] <cjwatson> It's vile, and upstream would prefer one that's absolutely definitely licence-clean anyway
[21:08] <cjwatson> And the design has to be entirely different really
[21:08] <cjwatson> We actually get better security properties from the new design
[21:08] <cjwatson> No parsing *at all* in the host
[21:09] <cjwatson> (It's marginal, but still)
[21:11] <infinity> Oh filterdiff, marry me and have my babies.  Thanks in advance.
[21:11] <cjwatson> Anyway, it goes: xenstore client, block driver, (optionally network driver if you can be bothered), boot shim, and then some utility code to chainload itself - you keep one grub2 image in the host filesystem and one in each guest, so that the host doesn't have to read the guest filesystem and the grub2 image in the guest that parses its grub.cfg can be precisely in sync with it
[21:13] <infinity> TImeouts in +queue really need to stop...
[21:14]  * infinity goes back to doing this the pleasant way until IS takes away our shell access.
[21:14] <cjwatson> I've asked them for an API client
[22:11] <slangasek> gdm there is part of a fix for plymouth corruption on shutdown
[22:11] <slangasek> (needs a corresponding lightdm change, and a plymouth upload that's blocked on both)
[22:14] <charlie-tca> Need approval on bug 857718 for Xubuntu to get the latest version of garcon
[22:15] <charlie-tca> http://pad.lv/857718
[22:17] <slangasek> Hmm, Xubuntu team isn't authorized to approve its own FFes this cycle?
[22:17] <charlie-tca> Not to my knowledge
[22:17] <charlie-tca> Is mr_pouit on the approval list?
[22:18] <slangasek> well, I guess I didn't see any discussion on ubuntu-release this cycle of delegating FFe approvals... so no
[22:18] <charlie-tca> Then we can't do it ourselves
[22:20] <slangasek> yeah... that definitely seems like a bug, though; if he's done all this testing, who am I to say no (and why should he need to ask)
[22:20] <infinity> ^
[22:20] <infinity> Politics aside, though, it looks good to me.
[22:20] <charlie-tca> Thank you both.
[22:23] <micahg> even with FFe delegations, one was not supposed to approve one's own FFe
[22:26] <infinity> micahg: No, hence the mention of team delegation.
[22:26] <infinity> Either way, long discussion, not relevant this instant.
[22:28] <infinity> slangasek: Accepted.
[22:28] <slangasek> ta