[02:27] <jdstrand> man that took a while. first of 2 jobs done. I am going to let the publisher have a run then do the 2nd job
[02:31] <jdstrand> ok, publisher started and I disabled the cronjob again
[03:30] <jdstrand> ok, publisher run finished, starting command 2 of 2. it will take about 3 hours
[07:01] <jdstrand> publisher back online
[07:01]  * jdstrand heads out
[08:14] <tumbleweed> Laney: probably not around tonight (up to my ears in scaleconf)
[08:16] <pitti> jdstrand: ah, saw your publisher comment too late -- that explains a bit :)
[08:16] <pitti> jdstrand: I just released the corresponding langpacks, they need to go along with the firefox bits
[08:53] <Laney> tumbleweed: I thought that said scalaconf and got excited
[08:53] <Laney> also ack
[09:03] <tumbleweed> hah
[09:30] <highvoltage> that actually deserved an appluase :)
[13:46] <jdstrand> pitti: which langpacks did I miss? I did all the langpacks in -proposed and saw when I copied firefox that it had several as well
[13:47] <pitti> jdstrand: hm, I didn't see any of them, but maybe that was also just a victim of the publisher delay
[13:48] <pitti> jdstrand: at least "6 hours ago" corresponds to the time when I moved them over
[13:48] <jdstrand> pitti: probably-- I did maverick + langpacks, ran the publisher then lucid + langpacks. when I ran the publisher in between I think it took an hour and a half
[13:48] <jdstrand> you came on about 1 and 15 minutes after I reenabled the publisher
[13:49] <pitti> jdstrand: so, maybe we just both copied them over then
[13:49] <pitti> (which doesn't hurt)
[13:49]  * jdstrand nods
[13:50] <jdstrand> it takes a while to copy those :)
[13:50] <pitti> yeah, some 10 minutes
[13:50] <jdstrand> oh-- how do you do it?
[13:50] <pitti> sru-release --pattern lucid language-pack-
[13:51] <jdstrand> hmm, I used copy-package on each individually. that was painful
[13:51] <pitti> urgh, yes
[13:51]  * jdstrand jots down sru-release
[13:51] <pitti> jdstrand: that's in ubuntu-archive-tools; there's also an sru-release script on cocoplum, but it's deprecated
[13:52] <pitti> we just need it for kernels and big SRUs these days, which make sru-release LP-timeout
[13:53] <jdstrand> cool. I learned something :)
[13:55] <cjwatson> I'm going to try http://paste.ubuntu.com/818818/ next time I have occasion to do this kind of thing
[14:03]  * jdstrand notes sru-release is not mentioned on ArchiveAdministration. I've made note of it and will document once I've used it once
[14:03] <jdstrand> (if no onw else does before me)
[14:06] <jdstrand> well, I'm off tody so I better get out of here. have a nice day :)
[14:13] <Riddell> why does backport-helper.py not find bug 922601 ?
[14:13] <ubot4`> Launchpad bug 922601 in oneiric-backports "Please backport 0.9.0~rc4-0ubuntu1 from precise to oneiric (affects: 1) (heat: 6)" [Undecided,Confirmed] https://launchpad.net/bugs/922601
[14:13] <cjwatson> no package name
[14:13] <Riddell> mm
[14:13] <cjwatson>     PACKAGE_RE = re.compile(r'Please backport ([a-z0-9][-a-z0-9+.]+)', re.I)
[14:14] <Riddell> yeah I saw I needed to add a "Please" :)
[14:14] <cjwatson> also ubuntu-archive not subscribed
[14:15] <Laney> I don't see a backporters ack
[14:15] <cjwatson> and that
[14:16] <Riddell> Laney: does the script enforce that? (don't worry I'm going to get scottk to check it over)
[14:16] <Laney> no, it just sounded like you were processing it without one
[14:16] <Laney> well, s/no/I don't know/
[14:17] <cjwatson> I don't think so, though arguably it should
[14:20] <Riddell> it's still not being picked up by backport-helper.py :(
[14:20] <Laney> Wouldn't be that hard to check that ubuntu-archive was subscribed by a backporter, as a first approximation. Otherwise, iterating bug_activity collections isn't the nicest thing.
[15:45] <micahg> Riddell: you still need approval from the backports team
[15:49] <Riddell> micahg: what sort?  something that stops the backport-helper.py script seeing the bug?
[15:49] <micahg> Riddell: BTW, is the current version in oneiric broke?
[15:49] <micahg> Riddell: to backport anything
[15:50] <Riddell> micahg: but I'm trying to understand what stops the script seeing it
[15:51] <Riddell> micahg: it's not broke but upstream wants a way to point people with problems to a newer version
[15:51] <micahg> it shouldn't see it if a backporter hasn't approved it
[15:54] <Riddell> micahg: that's not what I'm asking, I'm asking what is the technical change that a member of ~ubuntu-backporters needs to do to get the script to see it
[15:55] <Riddell> just a comment?
[15:56] <micahg> I think a backporter setting to IN PROGRESS
[15:57] <ScottK> Point me at the bug and I'll approve it.
[15:58] <Riddell> ScottK: bug 922601
[15:58] <ubot4`> Launchpad bug 922601 in oneiric-backports "Please backport networkmanagement 0.9.0~rc4-0ubuntu1 from precise to oneiric (affects: 1) (heat: 8)" [Undecided,Confirmed] https://launchpad.net/bugs/922601
[15:59] <Laney> it searches for bugs which are In Progress
[15:59] <ScottK> Done
[15:59] <Laney> (and that the archive is subscribed to)
[16:00] <Laney> backport-helper.py:202
[16:00] <Laney> Riddell: ^^^
[16:00] <Riddell> Laney: ah hah, thanks
[16:01] <Laney> and it actually /does/ walk the history to find out who to credit the backport too
[16:06] <Riddell> hmm now I'm getting no output from ./mass-sync.py --flush-backports  should I?
[16:07] <cjwatson> yes
[16:07] <cjwatson> you probably forgot to run mass-sync on the output of backport-helper
[16:13] <Riddell> cjwatson: hmm it didn't like that either http://paste.kde.org/194042/
[16:14] <cjwatson> dunno sorry
[16:14] <cjwatson> meeting
[16:15] <cjwatson> oh maybe you need to set your cocoplum username
[16:15] <cjwatson> ideally configure it in ~/.ssh/config
[16:16] <cjwatson> or set UBUNTU_ARCHIVE_HOST in the environment if you don't normally ssh to "cocoplum.canonical.com" - see synclib.py
[16:16] <cjwatson> this annoyance will go away once we convert to backportpackage ...
[16:21] <Riddell> awesome thanks
[23:20] <cjwatson> Could somebody process multipath-tools through NEW for me, please?  I have a dmraid upload pending which will require it
[23:20] <cjwatson> the new kpartx-udeb binary wants to go to main