[01:00] jtaylor: No idea. Maybe I screwed up. In any case, an update would be welcome. [01:00] Let me know if you won't have time to do it. [05:58] good morning === udienz_ is now known as udienz [10:55] jtaylor: what's up with all the breaks in numpy? === cjohnston_ is now known as cjohnston === hggdh_ is now known as hggdh [17:09] Laney: the previous version moved a file from one package to another [17:10] with incomplete breaks, I added them to make it easier to sync with debian when they do it properly [17:10] did you file it? [17:10] yes [17:12] unfortunately I'm not positive they'll do it at all ._. [17:12] well, i need to go to the bike shop now i'm afraid [17:12] morph is not exactly known to make live for ubuntu easier [17:12] maybe you can convince someone else to upload it before FF ... [17:29] barry: ^ [17:56] jtaylor: what's the package and context? [17:56] bug 1168652 [17:56] bug 1168652 in python-numpy (Ubuntu) "merge python-numpy 1.7.1-1 from debian experimental" [Undecided,New] https://launchpad.net/bugs/1168652 [17:58] jtaylor: i'll look at it [18:01] jtaylor: do you have an ffe for that? [18:01] it is bugfix only [18:01] k [18:10] jtaylor: the debdiff doesn't look right. d/changelog is adding a bunch of versions back that already exist in the changelog [18:10] its a debdiff on ubuntus version [18:10] debians [18:11] so its not cluttered with upstream changes [18:13] jtaylor: i'll try to do a udd merge and see if that makes sense [18:55] jtaylor: i have a 1.7.1-1ubuntu1 that i bzr merged from the experimental branch into the raring branch. afaict, it looks good, so unless you object or want to review it first, i'm going to upload it [18:56] barry: is there a diff to my debdiff? [18:58] jtaylor: against raring: http://paste.ubuntu.com/5716750/ [18:58] jtaylor: against experimental: http://paste.ubuntu.com/5716751/ [18:58] barry: I mean against my debdiff [18:58] jtaylor: not so easy to generate [18:59] apt-get source python-nump; cd ....; patch -p1 jtaylor: hang on [19:00] I can create a branch if thats what you want [19:00] jtaylor: a branch against ubuntu:raring would be fantastic [19:01] *ubuntu:python-numpy [19:01] * jtaylor is a bit annoyed that I have to adapt my method for each sponsor [19:01] I expected doko to merge this time :/ [19:06] Yeah, a debdiff on top of Debian is a pretty standard way to submit a merge ... [19:06] jtaylor: yeah, we do that just to test you and keep you on your toes :) [19:10] barry: lp:~jtaylor/ubuntu/raring/python-numpy/1.7.1-merge should be it [19:11] * barry looks [19:14] jtaylor: looks good, thanks. i'll do a local build/test and if goes okay, i'll sponsor it for you [19:16] jtaylor: oops, i just need to add LP: #1168652 to d/changelog [19:16] Launchpad bug 1168652 in python-numpy (Ubuntu) "merge python-numpy 1.7.1-1 from debian experimental" [Undecided,New] https://launchpad.net/bugs/1168652 [19:16] hm I'm not closing the merge bug in the changekog [19:17] right, i'll fix that [19:17] thx [19:18] hm I guess I should still update matplotlib too [19:19] why do the pyscience stack package always have to release a few weeks before ubuntu releases :( [19:30] oO a new gdb upstream built with py3 a week before release? o_O [19:31] is aarch64 that important? [19:33] I guess I should not fell so bad to add so late bugfix only software then [19:35] jtaylor: uploaded [19:35] barry: thx [19:36] daman rejected [19:48] barry: judging by the time you did it you probably did not run the autopkgtests? [20:09] jtaylor: correct. i really need to get those integrated with my sbuild environment so they run automatically [20:10] barry: I have a runner which prepares for pbuilder [20:10] should also work with sbuild if it has a --execute equivalent [20:11] jtaylor: nice. i've seen something about autopkgtest + sbuild, but i haven't had time to try it out (can't remember where right now) [20:14] barry: http://paste.ubuntu.com/5716940/ that would be mine, very ugly code but works quite ok [20:15] takes a dsc and a changes file as argument [20:16] jtaylor: nice [20:18] would probably simpler and faster to run each test in its own chroot instead of doing the dependency juggling, on the other hand that tends to find installation/removal bugs quite nicely :) [20:28] hm python3-pyparsing is an empty package in raring? oo [20:30] hm its main, main freezes tomorrow or? [20:36] jtaylor: broke in the last upload [20:36] yes reported a bug [20:36] bug 1170107 [20:36] bug 1170107 in pyparsing (Ubuntu) "python3-pyparsing is an empty package" [High,New] https://launchpad.net/bugs/1170107 [20:37] jtaylor, Laney ouch [20:38] indeed [20:39] jtaylor: are you going to look at that? [20:40] hm I wanted to do matplotlib [20:40] but as this is a deps I guess I must [20:40] might want to subscribe zul so that he's made aware [20:41] too many users with zul in the name in lp :( [20:41] zulcss? [20:42] found it [20:50] I see why it could happen, the pyparsing rules file is weird [20:52] it deletes pyparsing in the clean target and after setup.py install, but it does not seem to be a generated file [20:52] I guess it works in debian because of binary uploads [20:53] this thing needs a autopkgtest bad [20:54] how did it previously work in ubuntu? [20:54] good question [20:54] ah [20:54] it was generated in 1.5.6 [20:55] generated = mv pyparsing_py2.py pyparsing.py [20:55] Ill fix the package, barry Laney willl you sponsor? [20:59] jtaylor: yep, give me a branch and i will [21:00] hm it fails its own test [21:04] hm ok it seems to be more an example named test() instead of a test [21:21] ok its a bit weirder [21:21] from what I can tell upstream intentionally dropped py3 support [21:21] while listing fixed bugs for python3 in the changelog [21:22] I'll just through 2to3 over it and see what happens with the examples, I don'T really have time for more :/ [21:35] ok 2to3 does not work [21:50] barry: lp:~jtaylor/ubuntu/raring/pyparsing/fix-py3-package [21:51] jtaylor: cool, looking [21:51] I'll forward my changes to debian tomorrow [21:53] back to what I actually wanted to do today ._. [21:54] ffs ImportError: matplotlib requires pyparsing >= 2.0.0 on Python 3 [21:54] (git head that is, wanted to verify a test failure ...) [21:55] so probably the fixed package is not better than the empty one :/ [22:00] hm the changes does not list anything special, so maybe its ok, it passes its examples [22:01] jtaylor: how quickly can you get an ffe approved? ;) [22:01] 2.0 version drops support for py2 [22:01] lovely [22:01] maybe it works with 2.7 though [22:01] I don't think its a good idea [22:01] the changelog actualyl does not list any changes besides that [22:01] no, agreed not at this late date [22:02] I'll check with matplotlib upstream why they need 2.0 and not 1.5.7 [22:02] jtaylor: still seems worth getting a non-empty pyparsing in though, yeah? [22:02] yes [22:02] the examples run [22:02] also its mini testsuite [22:03] jtaylor: re those seds in d/rules. not now, but probably the right way to do those is with custom fixers [22:09] jtaylor: pyparsing looks good me me, sponsoring [22:09] thx [22:10] hm [22:10] actually the python-all addition does not do anything [22:10] but it doesn'T matter for raring [22:10] I'll fix that when I forward it to debian [22:10] +1 [22:10] (forgotten the loops in debian/rules) [22:12] and the autopkgtest will remind us to fix it for raring+1,as there I added them .. [22:12] its to late, I probably should not upload matplotlib anymore :( === hggdh_ is now known as hggdh [22:19] uh the multiarching of tk subtly breaks matplotlib too :/ [22:20] bug 752647 revisited [22:20] bug 752647 in matplotlib (Ubuntu Natty) ""import pylab" in a python console flags error "No module named _tkagg"" [High,Fix released] https://launchpad.net/bugs/752647 [22:20] funny enough probably one of the first bugs I ever worked on in ubuntu :) [22:24] dig the retro 6 digit bug number!