[06:18] <micahg> Daviey: any chance that you were planning on updating to the latest asterisk?  gmime2.4 depends on it and 4 other packages
[06:18] <micahg> Daviey: err..I meant that the other way, it's a reverse dependency of gmime2.4
[06:20] <ScottK> micahg: I think he confessed to it on -release a few hours ago.
[06:22] <micahg> ScottK: I assumed that was just to fix the RC bug :)
[06:23] <ScottK> Oh.  Yes.  Probably.
[06:23]  * micahg is trying to get rid of gmime, but might run out of time, need to do seamonkey as well
[06:24] <micahg> *gmime2.4
[06:54] <micahg> any objections to removing google-glog? (removed in Debian)
[06:55] <micahg> FTBFS on armhf
[08:12] <Laney> micahg: ScottK: I think the path being considered to fix that bug is a wholesale update.
[08:13] <Laney> removing stuff removed in debian> no, all's the better as far as I'm concerned
[08:13] <Laney> modulo the unlikely situation that someone is actively maintaining it
[08:27] <micahg> broder: ISTR you have a script to close the bugs for EOL backports, could you run that for maverick-backports when you get a chance?
[08:38] <Laney> can reverse-depends output source packages as well as take them on input?
[09:28] <tumbleweed> Laney: no. We don't have good ways of mapping source<->binary
[09:29] <Laney> tumbleweed: does your web service look at Sources already? It's in there
[09:29] <tumbleweed> no, it gets the source->binary mappings from LP, but that's buggy (it breaks on build failures)
[09:30] <Laney> also, got any nice lists of issues for a -devel mail?
[09:30]  * Laney has FTBFS and rcbugs
[09:30] <tumbleweed> source->binary and binary->source is probably best done as a separate service
[09:31] <tumbleweed> there's also debcheck, but practicall,y FTBFS and rcbugs probably matter more right now
[09:31] <Laney> ye
[09:41] <ltaveras> im looking for some advice on how to reactivate dominican republic loco team
[09:41] <ltaveras> any help will be appreciate
[09:43] <ltaveras> my email lisander.reyes@claro.net.do
 thanks
[09:44] <Laney> ltaveras: You'll probably get better help in #ubuntu-locoteams
[09:45] <ltaveras> i was there but no one answer
[09:45] <Laney> I'm afraid this channel isn't going to be much help — it's not really anything to do with loco teams.
[09:46] <Laney> try and mail the loco council's mailing list.
[09:46] <tumbleweed> MOTU hasn't been particularly effective at reactivating itself, never mind courting non-developers :P
[09:46] <ltaveras> do you have council emails addres
[09:47] <Laney> loco-council@lists.ubuntu.com
[09:47] <ltaveras> thanks a lot laney, you so kind
[09:48] <Laney> np, good luck
[09:48] <tumbleweed> Laney: thanks for the mail. There's been so much stuff I intended to do before release... :/
[09:48] <Laney> yeah, I know the feeling
[09:49] <Laney> I stayed in my corner(s) a bit much
[09:49] <Laney> ho hum
[09:49] <tumbleweed> copious amounts of free time, lol :)
[12:00] <cjwatson> Rhonda,micahg: https://bugs.launchpad.net/ubuntu/+source/wesnoth-1.8/+bug/982534/comments/5 FYI
[15:48] <porthose_spider> Would a release team member please comment on bug #983300 thx :)
[15:50] <tumbleweed> porthose_spider: looks like stgraber just did
[16:52] <tumbleweed> bdrung_: why does distro-info suggest shunit2?
[17:01] <tumbleweed> re the last minute django FFe, I see a whole bunch of django FTBFSs filed in Debian last week (behind on my e-mail). I can't say I'm very suprised.
[17:03] <jtaylor> universe is not frozen yet or?
[17:04] <tumbleweed> not yet. We have ~24 hours left
[17:05] <jtaylor> is there a need for builders in the next hours? I wanted to fix a minor scipy issue but it builds quite long
[17:05] <tumbleweed> we just got a bunch of new builders, so I wouldn't worry
[17:05] <Laney> ftbfs after the upgrade?
[17:05] <tumbleweed> Laney: there was no coordinated transition in Debian, just an upload
[17:05] <Laney> hoho
[17:06] <jtaylor> Laney: directed at me?
[17:06] <Laney> no
[17:29] <valleslezards> salut
[17:34] <jtaylor> hm maybe I should still update matplotlib to git head it does add a couple for medium bugs and is probably simplifies the sru
[17:34] <jtaylor> *bugfixes
[17:42] <jtaylor> on the other hand I have no idea how to generate the orig tar :/
[17:44] <tumbleweed> does setup.py sdist not do the right thing?
[17:45] <tumbleweed> they have a MANIFEST.in, so I'd assume someone uses it
[17:45] <jtaylor> there is an extra sample data tarball, but from the mailing list it seems its the same as 1.1.0
[17:45] <jtaylor> so I can probably reuse that
[17:46] <tumbleweed> https://github.com/matplotlib/matplotlib/blob/master/Makefile#L22
[17:49] <jtaylor> so you don't think its a bad idea to still do that?
[17:51] <tumbleweed> I haven't reviewed the diff
[17:52] <jtaylor> its only a couple hundred lines
[17:53] <tumbleweed> what's the plan? Any link to an FFe bug?
[17:54] <jtaylor> its bugfix only
[17:54] <tumbleweed> go for it :)
[17:55] <tumbleweed> you are talking about an SRU, though?
[17:55] <tumbleweed> are we expecting some major bugfixes?
[17:55] <jtaylor> no
[17:55] <jtaylor> I currently talking about updating to git branch head now to make a potential sru simpler
[17:56] <jtaylor> because when we sru we might as well go to 1.1.1 final (which is bugfix only)
[17:56] <tumbleweed> oh, right, we are currently on an rc
[17:56] <tumbleweed> yeah, sneak some updates in
[17:57] <jtaylor> head as also aged almost a week since the last commit to it, should be safe
[18:35] <bdrung_> tumbleweed: because it's needed to run the test cases
[18:36] <tumbleweed> bdrung_: but that's at build time
[18:37] <bdrung> tumbleweed: the tests are installed too
[18:37] <tumbleweed> I don't Suggest nose when I install a python unit test
[18:38] <tumbleweed> bdrung: btw, prepared all the distro-info updates, but I can't do the precise upload, it's in main. Would you mind?
[18:41] <jtaylor> ok now  have the problem how to upload a 33mb package with a 12kb/s connection
[18:41] <highvoltage> eek
[18:42] <jtaylor> I can't use alioth as I need the full b-d for a full sdist :/
[18:42] <tumbleweed> copy a pristine-tar delta and rebuild on alioth?
[18:43] <jtaylor> thats a good option
[18:44] <jtaylor> or xdelta might be simpler
[18:44] <jtaylor> not installed on ali :(
[18:45] <jtaylor> tumbleweed: can I send you a delta, you apply and upload it to ali wher eI can read it?
[18:45] <tumbleweed> jtaylor: sure :)
[18:53] <ScottK> jtaylor: around?
[18:53] <jtaylor> ScottK: yes
[18:53] <ScottK> jtaylor: Please upload python-scipy again without the wrap-and-sort.  It makes the diff very hard to review and doesn't really add anything.
[18:54] <ScottK> At this point you should be going for minimal diffs to affect needed changes.
[18:54] <jtaylor> ScottK: that was for easier merge after P
[18:54] <jtaylor> debian has added the sorting
[18:54] <ScottK> If you change it both in Debian and Ubuntu you'll get a merge conflict.
[18:55] <jtaylor> but I can do it without a sync will probably work anyway
[18:55] <ScottK> Thanks.
[18:55] <tumbleweed> ScottK: thoughts on matploblib? ^^
[18:57] <ScottK> matplotlib bug fixes sound good.
[18:57] <bdrung> tumbleweed: done
[18:58] <tumbleweed> bdrung: great. I should have given the debian upload a higher urgency. Only realised later. We should ask for an early migration...
[18:59]  * bdrung nods.
[19:02] <jtaylor> more problems, xdelta3 does not create the same md5sum as it uses gzip without -n ._.
[19:03] <ScottK> Alternately, take the upstream commits and cherry pick them as patches.
[19:03] <ScottK> That gets the fixes in and no worry about tarball recreation or uploading.
[19:03] <tumbleweed> that's how doko handles python2.X
[19:05] <jtaylor> hm the diff contains binary, though they are probably rebuilt from source
[19:10] <jtaylor> or someone creates a orig.tar for me which I can download, download is much faster
[19:11] <jtaylor> its just python setup.py sdist --formats=gztar with all b-d installed
[19:14] <ockham> i've downloaded a library package from Debian experimental, built it for precise, and am now trying to follow https://wiki.ubuntu.com/PbuilderHowto#Building_With_Local_Packages so i can dget another package from experimental that depends on the lib, and build that for precise, too . unfortunately, the library package ends up in /var/cache/archive/experimental -- as its target is of course set to experimental in the changelog. how can i work around
[19:14] <ockham>  this? i don't need to bump the changelog, do i?
[19:15] <ockham> i should probably say this is on oneiric; building is done using cowbuilder
[19:17] <jtaylor> lets see if bzr works
[19:17] <tumbleweed> jtaylor: http://corelli.tumbleweed.org.za/stefanor/matplotlib-1.2.x.tar.gz
[19:18] <jtaylor> tumbleweed: I need the 1.1.x branch :/
[19:18] <tumbleweed> ah
[19:19] <tumbleweed> http://corelli.tumbleweed.org.za/stefanor/matplotlib-1.1.1rc.tar.gz
[19:40] <jtaylor> thx thats perfect
[19:56] <jtaylor> great it apparently does not build
[19:57] <tumbleweed> that would be too easy :P
[20:00] <jtaylor> it just hangs with no error, the best type of error ._.
[20:13] <ockham> anyone? ^
[20:14] <tumbleweed> ockham: copy it to precise?
[20:14] <ScottK> jtaylor: Much easier.  Thanks.  http://launchpadlibrarian.net/102923884/python-scipy_0.9.0%2Bdfsg1-1ubuntu1_0.9.0%2Bdfsg1-1ubuntu2.diff.gz is my kind of diff to review.
[20:14] <jtaylor> ^^
[20:17] <jtaylor> well I don't have time to debug this matplotlib issue
[20:17] <jtaylor> if someone does go ahead
[20:22] <ockham> tumbleweed: and that's enough? no messing with Sources.gz etc?
[20:22] <tumbleweed> ockham: what is your /var/cache/archive ?
[20:22] <tumbleweed> if it has a Sources.gz that sounds like it's maintained by reprepro / mini-dinstall / something
[20:27] <ockham> yes, mini-dinstall. as suggested by that wiki page
[20:27] <tumbleweed> can you not override mini-dinstall to install it into precise?
[20:28] <tumbleweed> if you can't, just edit teh changes file (syncpackage --no-lp should make that easy)
[20:29] <ockham> i'm new to mini-dinstall -- any clue how to override it? otherwise, i guess i'll just try the latter idea.
[20:31]  * tumbleweed doesn't know it either
[20:31] <tumbleweed> but presumably it has documentation :P
[20:40] <bregma> its documentation in regards to overrides ranges from sorely lacking to bad
[20:41] <ockham> yup, that's what i thought, too, after skimming over the manpage
[21:10] <tumbleweed> broder: am I ever going to get a stripe tshirt? :) (no sign of it yet, but a local friend get his a few weeks back)
[21:34] <broder> tumbleweed: you should have gotten it already. give me a sec - i'll look into it
[21:34] <broder> (they should have all been sent out >3 weeks ago by now)
[21:53] <tumbleweed> thanks
[21:56]  * Laney directs broder towards bug #985981
[21:56] <Laney> :P
[21:56]  * Laney eyes remaining bugs in the queue
[21:58] <broder> Laney: i don't really know ufw, but seems fine from my context-free reading
[21:58] <Laney> I thought you had a relationship with the maintainer, perhaps he would take it (Debian has ufw)
[21:59] <broder> i do, and i'm happy to bounce it to him
[21:59] <Laney> does it really need all of those ports open?
[21:59] <broder> it chooses one randomly
[21:59] <Laney> hrm
[22:01] <tumbleweed> for the firewall, it would probably be preferable to use a *far* smaler range
[22:02] <broder> ftr, this is a step up from the original implementation, which picked a completely random port :)
[22:03] <broder> (you can also specify a single port to use manually)
[22:06] <broder> anyway, i can do some quick testing of the patch and sponsor it in...probably a few hours, if that's not too late for unseeded FF. or i can not, if you guys think the port range is too sketchy
[22:06] <broder> and i can forward it onto upstream in either case
[22:07] <broder> (along with your concerns)
[22:08] <Laney> I would leave it for P and see what we can do later on
[22:08] <broder> k
[22:08] <StevenK> Laney: Q, even?
[22:08] <Laney> leave it until Q
[22:08] <Laney> :P
[22:08] <broder> well, we're leaving it [as is] for P :)
[22:08] <StevenK> Right
[22:08] <ScottK> Quantal.
[22:09] <ScottK> Start getting used to it.
[22:09]  * Laney didn't learn how to spell Oneiric for about 6 weeks
[22:09] <StevenK> Haha
[22:09] <EvilResistance> o.O  Laney, that's just...
[22:09] <EvilResistance> sad i think is the word...
[22:09] <Laney> erm.
[22:10] <ScottK> I'm glad I was at UDS O.  If it wasn't for the One Eye Rick bit in the keynote, I don't know that I'd have ever gotten it.
[22:10] <jtaylor> thank good for vim syntax highlight :)
[22:10] <broder> Haha. That was a pretty great keynote
[22:11]  * jtaylor wants pypy powered sphinx, bisecting matplotlib is so slow ...
[22:12] <jtaylor> great scipy build failure
[22:12] <tumbleweed> have you seen how pypy upstream recommends using matplotlib?
[22:12] <jtaylor> embeding cpython in it or?
[22:12] <tumbleweed> yeah, crazy shit
[22:12] <tumbleweed> http://morepypy.blogspot.com/2011/12/plotting-using-matplotlib-from-pypy.html
[22:13] <jtaylor> is arm broken shortly before release?
[22:13] <jtaylor> the scipy diff cannot have caused a failure ...
[22:16] <jtaylor> hurray found the bad commit
[22:16] <jtaylor> some threading thing who would ahve guessed ...
[22:17] <tumbleweed> and the scipy failure?
[22:19] <jtaylor> no idea
[22:20]  * tumbleweed pokes at it
[22:23] <jtaylor> someone got a working arm chroot?
[22:24] <jtaylor> the last build succeeded, so its either an regression in some low level library or a last minute new feature
[22:24] <jtaylor> not to critical the bugfix is minor and we can just probably just poke the build when the issue has been found
[22:25]  * tumbleweed has a worknig chroot, but don't know if it'll build scipy. Finding out...
[22:25] <jtaylor> I'd like to see the content of that stat.h
[22:27] <jtaylor> tumbleweed: you can probably just execute that one failing line instead of the full build
[22:28] <jtaylor> maybe also try with the dpkg from 5 days ago
[22:28] <tumbleweed> jtaylor: http://paste.ubuntu.com/943267/
[22:28] <tumbleweed> jtaylor: I'm waiting for 100MB of build deps...
[22:28] <jtaylor> oo
[22:28] <tumbleweed> but yes, I'll try that
[22:37] <jtaylor> hm no change since ubuntu6 in libc
[22:48] <tumbleweed> hrm, gcc happily builds that file for me
[22:48] <jtaylor> nice
[22:49] <tumbleweed> not really
[22:49] <tumbleweed> lets see if a complete build succeeds
[22:50] <SpamapS> tumbleweed: btw, thanks for wrapping up the virtualenv thing :)
[22:50] <tumbleweed> SpamapS: np
[22:51] <tumbleweed> jtaylor: is the C regenerated during the build?
[22:51] <jtaylor> well at least I got matplotlib to build now
[22:51] <jtaylor> not sure
[22:52] <tumbleweed> no, looks hand-written
[22:55] <jtaylor> I guess I have a patch for matplotlib but its probably to late to get upstream reply :/
[22:55] <tumbleweed> they can be quite responsive. poke them on IRC
[23:16] <tumbleweed> whee, ICE
[23:16] <tumbleweed> *** glibc detected *** /usr/lib/gcc/arm-linux-gnueabi/4.6/f951: free(): invalid pointer: 0x008c38f8 ***
[23:17]  * tumbleweed leaves that one for people crazier than me (or with real arm hardware) and goes to bed
[23:19] <jtaylor> thanks for checking
[23:20] <jtaylor> I'll still upload matplotlib and go too, if my patch is wrong that at least gives me a reason to sru to final ;)
[23:51] <ajmitch> Laney: so when will the unseeded universe freeze be?