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