=== fginther is now known as fginther` === om26er is now known as om26er|away === om26er|away is now known as om26er [20:06] barry: Got a second? [20:06] thomi: yep [20:06] barry: yesterday I managed to fix all the failing tests in python3-openid! [20:07] I made a pull request, and it was merged last night \o/ [20:07] thomi: awesome! [20:07] the upstream dev also mentioned that they'll do another release soon, so that's nice [20:07] right, that's the good news :) [20:07] the bad news is that... [20:07] During a package build, I still get a failure: [20:08] http://pastebin.ubuntu.com/8091792/ [20:08] thomi: how are you building the package? [20:08] barry: which looks to me like it's related the the encvironment the package is built in not having some env var that sets the default codec or something [20:08] barry: with sbuild [20:09] I make a src package with 'bzr bd -S' then build it with 'sbuild -Ad utopic python3-openid_3.0.2-1.dsc' [20:09] thomi: yep, that's it. there's a file that's expecting a default system encoding, which on your desktop is probably some UTF-8 encoding. there's no default encoding in sbuild [20:09] *really schroot environment [20:09] barry: that's odd though, is that the traceback doesn't match the source code [20:10] when it complains about this: [20:10] File "/«PKGBUILDDIR»/openid/test/trustroot.py", line 76, in pyUnitTests [20:10] test_data = test_data_file.read() [20:10] the upstream line is actually: [20:10] oh wait [20:10] OK, it *does* match [20:10] :) [20:10] but the complete code is this: [20:10] test_data_file_name = os.path.join(here, 'data', 'trustroot.txt') [20:10] test_data_file = open(test_data_file_name, encoding='utf-8') [20:11] I thought that since it was specifying an encoding in the open call, we should be good? [20:11] yes, should be! [20:11] hmmmm [20:12] OK, that traceback really *doesn't* matcht he source code - it's off by one line, which is what confused me [20:12] any possibility there's a quilt patch mucking things up? [20:13] there is a quilt patch, which is the changes I made to make the tests pass, but that should be applied when the tests are run, right? [20:13] barry: perhaps you could try? lp:~thomir/+junk/python3-openid is the packaging branch... [20:14] * barry tries [20:17] reproducible. entering chroot [20:18] I realise now that I should have made sure I could build the package before submirring the PR. ahh well [20:21] hang on [20:21] in the chroot, i see: [20:21] test_data_file = open(test_data_file_name) [20:21] [20:21] no encoding [20:22] do you perhaps have a quilt patch that isn't included in the branch? [20:22] wha? [20:22] yep [20:22] no, there's only the one patch [20:22] 3.0.2 [20:22] oooooh [20:22] wait [20:23] I bet it's in upstream, but not in the release [20:23] that would explain it! [20:23] let's see... [20:24] hmmm, nope, that works [20:24] oh wait [20:25] yeah, that's it :) [20:25] barry: so I guess I just make tmy quilt patch include that line, until upstream does a new release? [20:26] thomi: yes. take a look and see if they have a revision that matches just this change. often you can just import upstream's changeset as the quit patch [20:26] *quilt [20:26] hmmm [20:26] ok [20:27] if not, just make sure the description or other patch headers indicate that it can be dropped when upstream makes a new release [20:28] barry: how's your git fu? [20:28] using git annotate, I can see that that line was introduced in a separate commit, which is hopeful [20:28] thomi: so-so but improving :) [20:28] the commit revno looks like 9770cb66 ? [20:28] or is that something else? [20:29] but I'm not sure how to ask diff to show me what was introduced in that commit [20:29] git doesn't have monotonic revnos like bzr, it has sha (1? 256?) hashes. the above is a shorthand for the full hash [20:30] thomi: yeah, this is why i "love" git :( [20:30] it looks like I can do: git diff [20:30] but I'm not sure how to say " +1" [20:30] there are ^ and ~ involved i think [20:31] let me see if i have a git repo handy [20:31] barry: got it: [20:32] git diff 9770cb66..9770cb66~1 [20:32] i think you can always just do `git diff -c ` [20:32] yeah, that's it [20:52] barry: can I blindly append one patch to another? or are there headers that can only happen at the top of the patch file? [20:52] where 'patch' == 'the ouput from git diff' [20:53] thomi: you can append them. the file is basically patch(1) compatible [20:53] usually i group them logically, i.e. here's all the stuff that fixes bug #12345 [20:53] bug 12345 in isdnutils (Ubuntu) "isdn does not work, fritz avm (pnp?)" [Medium,Fix released] https://launchpad.net/bugs/12345 [20:53] oops :) [20:53] heh [20:53] cool [20:54] wow, isdn... blast from the past [20:54] thomi: the point being you want to make it easy for you later to just delete the patch when upstream releases a fix [20:54] i.e. when they fix bug #1 [20:54] bug 1 in Ubuntu Malaysia LoCo Team "Microsoft has a majority market share" [Critical,In progress] https://launchpad.net/bugs/1 [20:54] \o/ [20:54] :) [20:55] I love that the Ubuntu Malaysia LoCo team has taken it upon themselves to fix the bug [20:56] hmmm [20:56] that doesn't work [23:35] barry: still around?