[00:06] <Daviey> cyphermox: tracker, build1 and this build2 - both No change rebuild against libcamel-1.2-29?
[00:44] <ScottK> doko: Looks like they're all retried.
[00:44] <infinity> Did someone really go do that manually?
[00:44] <infinity> I was about to just do it as a batch. :P
[00:48] <ScottK> I did the ones that weren't done already.
[00:48] <ScottK> LP is pretty fast tonight, so it didn't take very long.
[00:48] <infinity> You really shouldn't have said that.
[00:48] <infinity> You'll jinx it.
[00:49] <ScottK> (mindless work while supervising youngest child's violin practice)
[00:49] <ScottK> You're assuming I care.
[00:49] <ScottK> My work is done ....
[00:49] <infinity> Anything to take your mind off the screeching?
[00:49] <ScottK> ;-)
[00:49] <ScottK> It was plucking, but yeah.
[00:51]  * micahg would've piped the ubuntu-desktop packageset list to ubuntu-build for powerpc
[00:52] <slangasek> I was sure that sentence was going to end "to /dev/audio"
[01:28] <infinity> The only thing being piped to /dev/audio right now is Master of Puppets.
[01:39] <slangasek> infinity: could you review the dpkg in the queue?  it should be as easy as it looks
[01:41] <infinity> slangasek: And as long as the hash of the installer-created files is the same (ie: they have those exact contents), we get no prompts on hijack, right?
[01:41] <slangasek> that's my experience, yes
[01:41] <infinity> It's been a while since I've dealt with hijacking.
[01:41] <slangasek> (tests clean here... so unless I screwed up the conffile contents, we should be good)
[01:42] <infinity> Kay.  Assuming you installed it over a pre-existing file, and it didn't asplode, yay.
[01:42] <slangasek> i.e., unless I screwed up my local file prior to unpacking dpkg over it
[01:42] <infinity> Heh.
[01:42] <infinity> Accepted, and back to wishing I still had hair.
[01:43] <slangasek> ...
[01:43] <slangasek> ... thanks? :)
[01:43] <infinity> Those were two reasonably unrelated thoughts.
[02:09] <cyphermox> Daviey: yes
[04:13] <pitti> Daviey: postgresql-8.4-postgis is NBS, so it shouldn't be an alternative dependency
[04:13] <pitti> Daviey: that's why the uploads were necessary in the first place
[04:14] <pitti> now just waiting for powerpc to finally catch up
[05:51] <ScottK> FYI, those ^^^ are my uploads, so I need someone to review.  They're just a straight pull from upstream, no fanciness.
[05:51] <infinity> I only review fancy uploads.
[05:51] <ScottK> It did involve using git, so it's kind of fancy ...
[05:53] <pitti> ScottK: I'm watching the queue anyway between builds and sponsors, will get to them, too
[05:53] <ScottK> pitti: Thanks.
[05:55] <infinity> Looks sane to me.
[06:23] <Daviey> pitti: ah!  Makes sense :)
[08:42] <lool> slangasek: ca-certificates needs to run the fixed c_rehash; a Depends would be fine I guess
[08:52] <micahg> pitti: I take your request to upload blueman as an ACK?
[08:55] <pitti> micahg: ah, it was meant to be; I thought Stefano already acked it
[08:55] <micahg> pitti: he wanted more info
[08:55] <pitti> but as this now is more or less a Xubuntu specific thing, if you and charlie-tca are happy with it, that's fine
[08:55] <micahg> and testing
[08:56] <micahg> pitti: ok, thanks, will upload in a bit, still trying to get some updates out ATM
[09:06] <pitti> can someone please review my gobject-introspection and apport uploads?
[09:07] <pitti> cjwatson maybe?
[09:09] <pitti> thanks!
[09:12] <cjwatson> ... too slow
[09:12] <cjwatson> (wasn't me)
[09:13] <cjwatson> apport's fine, accepted
[09:16] <lool> cjwatson: would you kick ca-certificates?  I'll reupload it with a bumped Depends instead of a Conflicts
[09:17] <cjwatson> lool: no ca-certificates in the queue
[09:17] <lool> 01:22 -queuebot:#ubuntu-release- Removed package: ca-certificates
[09:17] <lool> sorry, missed that in the log
[09:19] <lool> reuploaded
[09:32] <tjaalton> guess this is a better place to ask for a FFE. bug 860297
[09:32] <ubot4> Launchpad bug 860297 in sssd (Ubuntu) "FFE: sssd 1.5.8 -> 1.5.13 (affects: 2) (heat: 14)" [Wishlist,New] https://launchpad.net/bugs/860297
[09:57] <infinity> tjaalton: Upload away, the upstream changelog and justifications seem sane.
[09:57] <Daviey> didrocks: Am i being crazy?  sni-qt - - build-dep on debhelper 9 (fix lintian warning as debian/compat is 9) .. Is 9 in oneiric?
[09:57] <infinity> tjaalton: I'll leave it to someone else to review, though, it's 4am here, and I need sleep. :P
[09:58] <infinity> Daviey: It sure isn't.
[09:58] <tjaalton> infinity: ok, thanks!
[09:58] <didrocks> Daviey: no, I am crazy, sorry, I wanted to change debian/compat, reject it :)
[09:59] <Daviey> heh.
[09:59] <didrocks> Daviey: shouldn't do things while on the phone I guess :)
[10:00] <pitti> didrocks, Daviey: compat level 9 is in natty or even earlier
[10:00] <pitti> it's mainly for multiarch compat
[10:00] <cjwatson> yes, it just isn't final yet
[10:00] <pitti> ^ that's why it's still dh 8.x
[10:00] <cjwatson> but you don't actually have version 9
[10:00] <pitti> but yeah, we shouldn't bump it for no reason
[10:00] <cjwatson> as the lintian-info for that note says, if you're using a non-final version of debhelper, you should override lintian, not add a build-dep on a nonexistent version
[10:03] <micahg> pitti: can you copy firefox 3.6.23+build1+nobinonly-0ubuntu0.10.04.1 from ubuntu-mozilla-security to lucid-security?
[10:03] <Daviey> pitti: was i wrong?
[10:03] <pitti> Daviey: haven't seen the patch; but a >= 9 build dep is of course wrong
[10:04] <pitti> Daviey: I thought you meant bumping compat to 9
[10:04] <Daviey> ah, no - i don't care about that.
[10:04] <Daviey> pitti: sorry, i thought you were correcting me :)
[10:12] <cjwatson> ngg, d-i ftbfs
[10:18] <pitti> moved our etherpad to pad.ubuntu.com, which is hopefully  more stable
[10:18] <pitti> and left a pointer in the old one
[10:25] <Daviey> The old one was run by a plonker aiui.
[10:32] <didrocks> Daviey: pushe a new sni-qt, sorry for the oversight
[10:32] <didrocks> pushed*
[10:32] <micahg> is another archive admin available for a copy?
[10:33] <pitti> micahg: sorry, was in a meeting and then stuck in the chinese image fix
[10:33] <pitti> micahg: can do now
[10:34] <micahg> pitti: no problem, just didn't want to miss the next publisher :) (I know I have a half hour)
[10:34] <pitti> cjwatson: so, above live-build fixes --package with local .deb; I used that to build a new chinese iso with the new defualts package which also just landed in the queue, and it built a nicely sized and working iso
[10:36] <cjwatson> ok, reviewing
[10:37] <cjwatson> I wish queue diff generation were instant and magic
[10:37] <pitti> micahg: done
[10:37] <micahg> pitti: thanks!
[10:37] <pitti> cjwatson: not that urgent, fine to do it in an hour or two even; just wanted to give some context how I tested
[10:38] <pitti> cjwatson: once it's in, I'll re-spin another chinese build to double-check the size
[10:39] <cjwatson> s'ok, accepted now
[10:39] <pitti> thanks
[10:39] <pitti> +1 on magic queuediff, though
[10:39] <pitti> sometimes it's weird, I see the diff in the webui, but queuediff doesn't yet
[10:39] <pitti> ten minutes later it works
[10:39] <cjwatson> I think that's just random HTTP failure
[10:39] <pitti> must be some difference between logged in and unauthenticated
[10:40] <cjwatson> in such cases retrying queuediff a few times often works
[10:40] <pitti> ah, interesting
[10:40] <cjwatson> or maybe depends which appserver you hit or something
[10:40] <cjwatson> I wish launchpadlib had better automatic backoff/retry support
[10:40] <pitti> I got so used to it that I'm getting grumpy with logging into cocoplum, fetching, and mdebdiff'ing
[11:32] <didrocks> FYI, bug #732016, I'm emailing the documentation team now
[11:32] <ubot4> Launchpad bug 732016 in unity-2d (Ubuntu) (and 4 other projects) "UIFe: Desktop should be titled (affects: 8) (dups: 4) (heat: 64)" [Low,New] https://launchpad.net/bugs/732016
[12:24] <pitti> cjwatson: oh, seems http://china-images.ubuntu.com/oneiric/daily-live/ is not covered by auto-cleaning old images? I don't see where these images are hosted on antimony
[12:26] <cjwatson> no, I've just been pruning by hand for now
[12:26] <cjwatson> I'll go and do that
[12:26] <cjwatson> cdimage/www/china-images/
[12:26] <pitti> oh, thanks; can cleanup myself, too, but I was looking in /full
[12:27] <cjwatson> I've nuked a batch
[12:36] <pitti> http://china-images.ubuntu.com/oneiric/daily-live/20110928/
[12:36] <pitti> hmm
[12:36] <pitti> so i386 got smaller, but amd64 actually grew
[12:36] <pitti> my own local build was 691 MB (amd64)
[12:36] <pitti> will investigate in a few
[12:48] <jdstrand> Daviey: fyi, patch acked
[12:48] <jdstrand> Daviey: (the libvirt one you asked about)
[12:48] <Daviey> jdstrand: rocking!
[13:35] <ev> I'd appreciate comment from someone on the release team as to whether I can upload the changes noted in bug 861410
[13:35] <ubot4> Launchpad bug 861410 in ubiquity-slideshow-ubuntu (Ubuntu) "Ubuntu screenshots need to be updated to reflect the lastest UI iteration (affects: 1) (heat: 8)" [High,Fix committed] https://launchpad.net/bugs/861410
[13:35] <ev> cheers
[14:03] <lool> cjwatson: Thanks for bringing attention to that other ca-certificates bug; indeed my upload fixed that one, but because it might reappear after oneiric we don't nuke the original cause of the issue (plain c_rehash in postinst), I've opted to do another upload to cleanup postinst ^
[14:03] <ScottK> ev: I'd imagine you pretty much have to.
[14:03] <lool> s/we don't nuke/if we don't nuke
[14:04] <ev> ScottK: I just wanted to make sure I ran it past you guys first, to be sure I wasn't stepping on toes
[14:04] <ev> thanks
[14:04] <ev> will do
[14:04] <skaet> hi ev,  why were all the properties properties changed: -x to +x)
[14:04] <ev> skaet: I fixed that in the merge
[14:04] <ev> it was because Christian had his branch on a vfat filesystem
[14:04] <ev> but trunk to the previous uploaded version is free of that noise
[14:05] <skaet> ev,  coolio.   thanks.     getting the updates in now is good by me.
[14:05] <ev> great, thanks!
[14:18] <pitti> ev: just answered to the UIFE, sorry for delay
[14:18] <pitti> (it's really just a bug fix)
[14:19] <pitti> hey skaet
[14:19] <skaet> heya pitti
[14:26] <ara> skaet, hello, what time is the Final Freeze? :)
[14:26] <skaet> ara, 2100 UTC
[14:26] <pitti> 2100 UTC
[14:26] <skaet> :)
[14:27] <ara> skaet, tomorrow, 21:00UTC, isn't it?
[14:27] <skaet> yup.
[14:27] <ara> awesome, thanks!
[14:38] <pitti> skaet: so, LangpackTranslationDeadline is October 6th
[14:38] <pitti> skaet: so I'd request a full export on October 6th evening, so that on Friday, Oct 7 I can build/upload the final langpacks
[14:38] <pitti> skaet: that's right after RC (if we have an RC)
[14:38] <pitti> does that sound alright?
[14:38] <pitti> (same procedure as every year)
[14:39] <skaet> pitti, yes that sounds right.   RC is going to be more like we did in Natty.
[14:40] <skaet> release candidate process checklists need to be modified into LTS and non,  I suspect.
[14:40] <pitti> skaet: is that the full story, with releases.u.c., announcement, etc, or just an internal testing round with QA and tracker?
[14:40] <skaet> pitti,  internal testing round with QA and tracker.
[14:40] <pitti> ok, as I thought
[14:40] <pitti> so if we have delta langpacks for these, it's no biggie
[14:41] <skaet> pitti,   I'll make a point of clarifying this at the release meeting, and take a pass at the checklist.
[14:43] <jdstrand> Daviey: I see that glance got promoted. this was conditional on documentation being updated to reflect that it assumes a trusted network. is this captured in a bug somewhere? was this already done?
[14:43] <pitti> ^ behold! last package for GNOME 3.2 final
[14:44] <pitti> and it's trivial, just updated Thai translations
[14:44] <pitti> we reviewed the other stuff on http://people.canonical.com/~platform/desktop/versions.html, and this was the only one left
[14:44] <skaet> :)
[14:44] <pitti> there might be some .1 post-release bug fix upstream updates before we release,of course
[14:48] <ScottK> For RC, we just have to remember that when we say an image is a release candidate image, we actually mean that now.
[14:48] <pitti> for that we'd need to adjust the langpack translation deadline
[14:48] <pitti> if we put it 7 days before final release, we can't make a true RC
[14:49] <pitti> at least not 7 days before
[14:51] <ScottK> I had expected that to be when we started working on getting final images.  It normally takes a few days to beat down RC bugs.
[14:53] <Laney> are we having a separate unseeded universe final freeze again?
[14:53] <ScottK> skaet and tumbleweed: Historically final freeze for unseeded Universe/Multiverse packages has been much later (release week).  I didn't see any discussion of that this time?
[14:53] <Laney> oh
[14:53] <Laney> snap!
[14:53] <ScottK> Laney: ^^^ I was already typing that ...
[14:54] <skaet> ScottK,  Laney,   yes,  that was an oversite.   We need to come up with a process page, so it can get added and tracked.
[14:55] <Laney> FinalFreeze already says it
[14:55]  * skaet goes back to staring at pages. :)
[14:55] <Laney> maybe add an "until [some date]" to the end of the last sentence there.
[14:56] <ScottK> My recommendation would be 1200UTC on the 11th.
[14:57] <Laney> don't we usually reserve the last couple of days for RC fixes only even in *verse?
[14:57] <ScottK> That leaves 36 hours for OMG WTF BBQ situations and mirror sync.
[14:58] <tumbleweed> seems reasonable
[14:59] <skaet> ScottK,  given the number of images that need to be respun if its an kitten killer situation,  would actually like a little more margin.   What would it hurt to make it 72 hours?
[14:59] <tumbleweed> surely we're talking about things that aren't seeded
[14:59] <Laney> like: FeatureFreeze up until the 6th, FinalFreeze until the 11th, OMG WTF Freeze thereafter
[14:59] <ScottK> This is for non-seeded stuff?
[14:59] <Laney> yes
[14:59] <ScottK> skaet: Images aren't relevant.
[15:01] <skaet> ScottK,  its more in the lines of one more thing to track and double check.
[15:01] <ScottK> We've done it this way for years.
[15:02] <skaet> while doing the images, to make sure no interaction with any of the flavors.
[15:03] <ScottK> skaet: I'm not aware of there ever being an actual problem from that.
[15:03] <ScottK> This is too much like work and fighting with management of idiocy.
[15:07] <Laney> I put a couple of words into FinalFreeze, just needs a date on the schedule
[15:07]  * skaet figures to wait for ScottK to rejoin channel before continuing discussion. 
[15:08] <Laney> oh, he left?
[15:08] <skaet> Thanks Laney
[15:08] <skaet> yeah,  at 10.03, looks like he left all the channels,  so unfortunate bit of timing.
[15:08]  * Laney has parts hidden
[15:08]  * skaet notes that 10.03 was her time zone.... sorry.
[15:09] <Laney> http://qa.ubuntuwire.com/bugs/rcbugs/ I figure we should have a few days looking at RC bugs
[15:09] <Laney> so release - 5 days or so for Unseeded Universe Final Freeze
[15:10] <skaet> seems reasonable to me.   Possibly we should turn this into a thread topic on u-release mail list though,  so others can weigh in, and we can get some clarity.
[15:10] <skaet> ?
[15:12] <Laney> if you like
[15:19]  * pitti accepts unity-lens-musicstore and holds his breath
[15:23] <Daviey> jdstrand: I will make sure it is documented today.
[15:23] <Daviey> (glance ssl)
[15:23] <jdstrand> Daviey: thanks
[15:32] <pitti> good night everyone
[15:33] <skaet> good night pitti!
[16:22] <lamont> ogra_: around?
[16:22] <ogra_> how do you know i need t lose weight ? :)
[16:22]  * ogra_ checks his webcam if its on :P
[16:23] <lamont> heh
[16:42] <Daviey> Hey.. I've just put a sync in for ruby-rails-2.3.. The current version will not install due ruby being too new.  This sync should fix it, new upstream version of rails.
[16:43] <Daviey> bug 861524
[16:43] <ubot4> Launchpad bug 861524 in rails (Ubuntu Oneiric) (and 1 other project) "[oneiric] rails is not installable (affects: 1) (heat: 6)" [Critical,Confirmed] https://launchpad.net/bugs/861524
[16:43] <Daviey> As the current one cannot be used, it seems safer to just go with what is in Debian.
[16:43] <Daviey> Thoughts?
[16:45] <Daviey> (just goes to show nobody tested rails until today.)
[16:56] <Daviey> Oh crap, it's worse than i thought
[17:13] <bdmurray> cjwatson: could you approve the kerneloops upload (disabling it) now?
[17:15] <micahg> skaet: I'd like to chat with you about nss/nspr when you have a chance
[17:16] <skaet> micahg,  nss/nspr?   education please,  not parsing that acronym.
[17:16] <skaet> :)
[17:16] <micahg> skaet: the mozilla security library and portable runtime
[17:16] <skaet> thanks micahg.
[17:17] <micahg> skaet: nss contains the trusted root certs and it would be nice to update before release
[17:17] <micahg> err, trusted root certs for some programs
[17:17] <skaet> micahg,  when would the changes land?
[17:18] <micahg> skaet: that's the problem, I don't think I can land it today, plus I'm off tomorrow and Friday, I was thinking to land Sunday if that would be ok?  This is something that we push out at times as security updates as well and I can do some testing before pushing it out
[17:22] <skaet> micahg,  is the only thing being updated the certs, or are there some code updates happening too?
[17:23] <micahg> skaet: unfortunately code updates, but NSS has a good record of not breaking binary compatibility with updates
[17:25] <Daviey> micahg: What sort of SRU cadence do you do for these usually?
[17:25] <skaet> micahg,  suggest prepare it up,  and then lets discuss in the channel early next monday.   we'll have a better idea how things are looking overall then,  i'm leaning to including but would like to get others on the release team's opinions.
[17:25] <micahg> Daviey: usually it's been as needed to fix security issues
[17:26] <micahg> or keep Firefox/Thunderbird working
[17:27] <micahg> skaet: will do, thanks
[17:39] <SpamapS> juju has been uploaded to oneiric's NEW queue
[18:04] <SpamapS> slangasek: Hi, just an FYI,  the ensemble -> juju rename we discussed on Monday is now in the NEW queue
[18:18] <micahg> skaet: we've got a potential issue that could possibly affect thunderbird upgrades from natty -> oneiric (firefox will be fixed with the Firefox 7 update for natty later this week), should I file a tracking bug? (mozilla Bug 680802)
[18:18] <ubot4> Mozilla bug 680802 in Add-ons Manager "Upgrade Firefox when there is an add-on update waiting to be installed uninstalls the add-on" [Major,Assigned: ] http://bugzilla.mozilla.org/show_bug.cgi?id=680802
[18:18] <skaet> micahg,  yes please.
[18:19] <micahg> skaet: eta on upload would be sunday
[18:20] <skaet> micahg,   understood.   Let me know the LP bug number when you have it.
[18:23] <micahg> skaet: Bug #861664
[18:23] <ubot4> Launchpad bug 861664 in thunderbird (Ubuntu Oneiric) (and 1 other project) "Upgrading Firefox/Thunderbird when an add-on update is waiting to be installed hides the add-on (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/861664
[18:24] <skaet> Thanks micahg !
[18:25] <micahg> skaet: even though it's temporary, perceived impact is high, so I'm marking it high
[18:25] <skaet> micahg:  ok.
[18:27] <micahg> skaet: actually, I should probably update Firefox as well for those who don't fully update before jumping to the next Ubuntu release
[18:29] <skaet> yes.  seems prudent, as that may well happen. sigh.
[19:09]  * tumbleweed wonders why barry didn't just sync python-peak.rules
[19:23] <tumbleweed> barry: any reason you didn't sync python-peak.rules? We'll now have another tarball mismatch (not that this is particularly serious, I just rushed reviewing it in Debian, so we could sync)
[19:25] <barry> tumbleweed: i'm sorry, i didn't realize you were doing that.  yeah, we should definitely sync then.  is .rules ready to sync?  .util got rejected (rightly so) so i should request a sync for that one too
[19:25] <tumbleweed> no, it can't be synced now, there's a tarball mismatch :)
[19:26]  * tumbleweed should have told you, I guess :P
[19:27] <barry> tumbleweed: dang.  what can we do about it now?
[19:27] <barry> tumbleweed: at least .util can be syncd
[19:28] <tumbleweed> ah it has to be fake-synced, until there's a new upstream version
[19:28] <tumbleweed> util can still be synced
[19:30] <barry> tumbleweed: okay, i'll request a sync for util
[19:30] <tumbleweed> thanks
[19:33] <barry> tumbleweed: please confirm: i should use syncpackage to request a fake sync for .rules?  and for .util?
[19:34] <cyphermox> could someone please ack network-manager? fixing the wired+wireless routing bug (bug 856333) :)
[19:34] <ubot4> Launchpad bug 856333 in network-manager (Ubuntu) (and 2 other projects) "(oneiric) wired connection unnaturally slow (affects: 2) (dups: 1) (heat: 20)" [High,In progress] https://launchpad.net/bugs/856333
[19:34]  * micahg hugs cyphermox
[19:35] <cyphermox> micahg: heh, took way longer to figure that one out than it should have ;)
[19:35] <tumbleweed> barry: you can syncpackage .util yourself, or requist an archive-admin sync, no faksync required, we don't have a tarball mismatch there
[19:35]  * micahg wonders if that will also fix his own wireless routing issue
[19:36] <tumbleweed> barry: .rules will need fakesyncs in the future, but it's mostly in sync now, so no need to touch it
[19:36] <cyphermox> micahg: what wireless routing issue ?
[19:36] <micahg> cyphermox: will have to chat later...too much to do
[19:37] <barry> tumbleweed: ack, thanks.  will do .util now and we can clean up .rules for P
[19:37] <cyphermox> sure, just ping me if you need me to look at it
[19:37] <tumbleweed> cyphermox: if it's what I was experiencing, I was getting ethernet loops when connected by wireless and wifi at the same time (but that was a week or two ago)
[19:37] <cyphermox> tumbleweed: yup
[19:38] <cyphermox> traffic coming out eth0 and in wlan0 (and trouble coming in both sides)
[20:04] <barry> tumbleweed: .util syncpackage'd
[20:05] <tumbleweed> in that case, \o/, one less ftbfs package
[20:05] <Daviey> bjf: bdmurray asked that kerneloops be disabled now, happy with that/
[20:05] <Daviey> ?
[20:05] <bjf> Daviey, that's ogasawara's call
[20:05] <Daviey> bjf: thanks
[20:05] <ogasawara> Daviey: yes, I'm fine with that
[20:05] <barry> tumbleweed: well, actually not quite yet :).  we need to get .util and .rules landed and then do a rebuild of turbojson (the original ftbs).  but i've tested this locally and think it will work
[20:06] <tumbleweed> barry: heh. .rules alreday landed. Yeah Itested it locally too
[20:06] <Daviey> ogasawara: super
[20:06] <barry> cool.  just waiting for .util and then i'll hit the big button
[20:10] <infinity> bjf / Daviey / ogasawara: bdmurray has had a kerneloops upload in the unapproved queue for over a week that disables it, I've just been waiting on Final Freeze to accept it.
[20:11] <Daviey> infinity: Yeah, saw it there - and bdmurray pinged about it earlier.
[20:11] <infinity> Kay.
[20:11] <Daviey> Seemed a good idea to check ;)
[20:12] <infinity> Man, I hate how uninformative the queue UI is about syncs. :/
[20:12] <Daviey> infinity: Try to get praise/blame history.
[20:12] <Daviey> seems they are not attributed to anymore anymore.
[20:12] <Daviey> anyone anymore*
[20:13] <infinity> Really?
[20:13] <infinity> That's the only info I *do* see. :P
[20:13] <infinity> You get curren version, source archive, and requestor.
[20:14] <infinity> But no previous version, no diffs, nothing to review, really.
[20:14] <infinity> s/current/requested/
[20:14] <Daviey> infinity: no, i mean once accepted
[20:15] <tumbleweed> Daviey: I opened a bug for that earlier today
[20:15] <tumbleweed> (err not for teh queue, for the package's page)
[20:15] <infinity> Daviey: Ahh.
[20:15] <tumbleweed> but yes, they should be more reviewable in the queue too. /me files a bug
[20:16] <Daviey> why can't the world be perfect today..
[20:16] <tumbleweed> oh, bug 851562
[20:16] <ubot4> Launchpad bug 851562 in launchpad "Diff's not available for sync's on +queue page like for regular uploads (affects: 1) (heat: 22)" [High,Triaged] https://launchpad.net/bugs/851562
[20:16] <infinity> Even having the previous version would be a huge help.  I can't tell if someone's trying to force over an XubuntuX version, etc.
[20:17]  * tumbleweed can assure you that both of the current sync proposals are OK :)
[20:17] <infinity> I'm a naturally untrusting person. :P
[21:19] <cjwatson> ogra_ and other ARM folks: merry Christmas, rmadison now lists all architectures
[21:50] <infinity> cjwatson: \o/
[21:50] <infinity> cjwatson: (Can I be a powerpc folk instead?)
[21:51] <slangasek> infinity: yes, you can be a 604e
[21:52] <kirkland> can I get someone to accept that keystone upload?
[21:52] <infinity> slangasek: Hrmph.  Then you get to be an ev4.
[21:52] <slangasek> ow
[21:53] <slangasek> kirkland: looking
[21:53]  * micahg hugs cjwatson
[22:00] <kirkland> slangasek: one-line bug fix, forwarded upstream;  grabbed two missing source/configuration files from upstream
[22:01] <slangasek> kirkland: why does debian/copyright on this package claim that it's called "glance"?  Is the rest of the copyright information here correct?
[22:01] <kirkland> slangasek: i'm guessing zul copied glance's packaging
[22:02] <kirkland> slangasek: zul did the original packaging ... we're just fixing two bugs to get it functional
[22:02] <slangasek> yes
[22:02] <slangasek> I was just curious why these missing files were added as patches, wondering if we were upstream for it - seems not :)
[22:02] <slangasek> and the copyright file is... not illegal.  So accepting.
[22:02] <kirkland> slangasek: right
[22:03] <kirkland> slangasek: thanks;  i'll open a bug on the copyright file now
[22:03] <infinity> slangasek: "Not illegal" is a pretty high bar.
[22:03] <slangasek> it's not illegal to list extra people as having copyright when they don't
[22:04] <slangasek> for instance, it's not illegal to claim that the US Government holds copyright on glance even though it probably doesn't :)
[22:05] <slangasek> (but upstream themselves make this claim, so anyway)
[22:08]  * infinity is puzzled by oem-config-slideshow-ubuntu, which appears to be identical to ubiquity-slideshow-ubuntu, except for one stanza.
[22:11]  * slangasek writes dh_slideshow
[22:11] <kirkland> slangasek: fixed copyright issue in a branch and sent to the upstream packagers
[22:16] <slangasek> infinity: can you remind me where it's defined what seeds get pulled onto the ISOs?
[22:16] <slangasek> kirkland: ok, cheers :)
[22:17] <infinity> slangasek: In what sense?  You mean, where people document it after the fact and pretend it's true, or the code that does the work?
[22:17] <slangasek> infinity: the code that does the work :)
[22:18] <infinity> slangasek: livecd-rootfs/live-buid/auto/config for anything livefs-based.
[22:18] <infinity> slangasek: debian-cd/*mumble* for alternates and the tiny /pool/ on some livecds.
[22:18] <slangasek> infinity: ah, I meant specifically the ISO part
[22:18] <slangasek> yeah, I'm coming up empty on the *mumble*
[22:18] <slangasek> oh, I see
[22:18] <slangasek> I'm looking at an upstream debian-cd branch, wtf
[22:19] <infinity> I'm looking for the mumble bit myself now. :P
[22:19] <slangasek> there, *now* I see it
[22:19] <cjwatson> I think you want cdimage/bin/list-seeds
[22:20] <infinity> Hey look, it's the inheritance code again.
[22:20] <slangasek> cjwatson: ah, got there, scratched my head, went looking again for something more declarative :)  ok, thanks
[22:20] <infinity> That's 3 places that I know that lives.
[22:21]  * infinity reminds himself to put that in germinate as a helper instead.
[22:26] <micahg> can I get someone to copy from a PPA to archive please?
[22:33]  * cjwatson almost finishes moving NBS generation entirely off cocoplum and stalls on an RT ticket
[22:52] <micahg> cancel my AA request...
[22:57] <infinity> micahg: Okay!
[23:10] <slangasek> cjwatson: did you have thoughts on getting improved handling on bug #759545?  Is the ucf comparison being done at the wrong point?
[23:10] <ubot4> Launchpad bug 759545 in grub2 (Ubuntu Oneiric) (and 3 other projects) "user prompted to update unmodified grub configuration during Ubuntu server upgrade (affects: 3) (heat: 27)" [Medium,Triaged] https://launchpad.net/bugs/759545
[23:30] <slangasek> SpamapS: juju accepted
[23:31] <SpamapS> slangasek: !! Thanks!
[23:31] <SpamapS> all juju ever wanted was to be accepted.. to be one of the packages.
[23:31] <slangasek> y/w :)
[23:32] <slangasek> man, quit anthropomorphising the software, it really hates that
[23:35] <SpamapS> :)
[23:44] <infinity> slangasek: Any chance I can get a once-over on jasper-initramfs, flash-kernel, and livecd-rootfs?
[23:45] <slangasek> looking
[23:47] <infinity> slangasek: Before you ask, removing mkdosfs from jasper was cleaning up after code that was removed several versions ago.  I missed noting that in the changelog.
[23:48] <slangasek> k
[23:49] <slangasek> infinity: what's the jasper-initramfs change in partition type check?
[23:49] <slangasek> oh, n/m
[23:49] <slangasek> that's an addition, not a change
[23:49] <slangasek> have confidence in my review
[23:50] <infinity> Hey, you caught your mistake, that's close enough to perfection where I come from.
[23:50] <slangasek> I thought you were from Canada
[23:50] <slangasek> is that all the higher the standards are there?
[23:51] <infinity> Well, if you caught your mistakes while covered in maple syrup, THAT would be perfection.
[23:51] <slangasek> infinity: I don't understand the flash-kernel change, how is umount racy without -l?
[23:51] <slangasek> is this a workaround for a buggy umount?  (hopefully not the util-linux one?)
[23:52] <infinity> It's util-linux, it's not a umount bug (I don't think), but something's keep a file on that filesystem open for just a split second, long enough to make umount refuse to umount it.
[23:52] <infinity> The fun part?
[23:52] <infinity> Any debug code added to attempt to trace it adds just enough delay to make it go away.
[23:53] <infinity> So, not really sure what's keeping something open.  But -l makes it happy, and can't really do any harm.
[23:54] <infinity> The bug that I helpfully forgot to mention in the changelog is #779410
[23:57] <slangasek> ah, so it's a race with the fs being in use, not a race with umount returning success before it's unmounted - got it
[23:57] <infinity> Right.
[23:58] <infinity> I ran flash-kernel in a loop of 1000 tries with -l and it always DTRT and cleans up properly, so I call it a success.
[23:58] <infinity> A success, and possibly a dead SD card.