[20:06] <thomi> barry: Got a second?
[20:06] <barry> thomi: yep
[20:06] <thomi> barry: yesterday I managed to fix all the failing tests in python3-openid!
[20:07] <thomi> I made a pull request, and it was merged last night \o/
[20:07] <barry> thomi: awesome!
[20:07] <thomi> the upstream dev also mentioned that they'll do another release soon, so that's nice
[20:07] <thomi> right, that's the good news :)
[20:07] <thomi> the bad news is that...
[20:07] <thomi> During a package build, I still get a failure:
[20:08] <thomi> http://pastebin.ubuntu.com/8091792/
[20:08] <barry> thomi: how are you building the package?
[20:08] <thomi> 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] <thomi> barry: with sbuild
[20:09] <thomi> 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] <barry> 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] <barry> *really schroot environment
[20:09] <thomi> barry: that's odd though, is that the traceback doesn't match the source code
[20:10] <thomi> when it complains about this:
[20:10] <thomi>   File "/«PKGBUILDDIR»/openid/test/trustroot.py", line 76, in pyUnitTests
[20:10] <thomi>     test_data = test_data_file.read()
[20:10] <thomi> the upstream line is actually:
[20:10] <thomi> oh wait
[20:10] <thomi> OK, it *does* match
[20:10] <barry> :)
[20:10] <thomi> but the complete code is this:
[20:10] <thomi> test_data_file_name = os.path.join(here, 'data', 'trustroot.txt')
[20:10] <thomi>     test_data_file = open(test_data_file_name, encoding='utf-8')
[20:11] <thomi> I thought that since it was specifying an encoding in the open call, we should be good?
[20:11] <barry> yes, should be!
[20:11] <thomi> hmmmm
[20:12] <thomi> OK, that traceback really *doesn't* matcht he source code - it's off by one line, which is what confused me
[20:12] <barry> any possibility there's a quilt patch mucking things up?
[20:13] <thomi> 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] <thomi> barry: perhaps you could try? lp:~thomir/+junk/python3-openid is the packaging branch...
[20:14]  * barry tries
[20:17] <barry> reproducible.  entering chroot
[20:18] <thomi> I realise now that I should have made sure I could build the package before submirring the PR. ahh well
[20:21] <barry> hang on
[20:21] <barry> in the chroot, i see:
[20:21] <barry>     test_data_file = open(test_data_file_name)
[20:21] <barry>  
[20:21] <barry> no encoding
[20:22] <barry> do you perhaps have a quilt patch that isn't included in the branch?
[20:22] <thomi> wha?
[20:22] <barry> yep
[20:22] <thomi> no, there's only the one patch
[20:22] <barry> 3.0.2
[20:22] <thomi> oooooh
[20:22] <thomi> wait
[20:23] <thomi> I bet it's in upstream, but not in the release
[20:23] <barry> that would explain it!
[20:23] <thomi> let's see...
[20:24] <thomi> hmmm, nope, that works
[20:24] <thomi> oh wait
[20:25] <thomi> yeah, that's it :)
[20:25] <thomi> barry: so I guess I just make tmy quilt patch include that line, until upstream does a new release?
[20:26] <barry> 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] <barry> *quilt
[20:26] <thomi> hmmm
[20:26] <thomi> ok
[20:27] <barry> 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] <thomi> barry: how's your git fu?
[20:28] <thomi> using git annotate, I can see that that line was introduced in a separate commit, which is hopeful
[20:28] <barry> thomi: so-so but improving :)
[20:28] <thomi> the commit revno looks like 9770cb66 ?
[20:28] <thomi> or is that something else?
[20:29] <thomi> but I'm not sure how to ask diff to show me what was introduced in that commit
[20:29] <barry> 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] <barry> thomi: yeah, this is why i "love" git :(
[20:30] <thomi> it looks like I can do: git diff <commit> <commit>
[20:30] <thomi> but I'm not sure how to say "<commit> +1"
[20:30] <barry> there are ^ and ~ involved i think
[20:31] <barry> let me see if i have a git repo handy
[20:31] <thomi> barry: got it:
[20:32] <thomi> git diff 9770cb66..9770cb66~1
[20:32] <barry> i think you can always just do `git diff -c <revision>`
[20:32] <barry> yeah, that's it
[20:52] <thomi> 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] <thomi> where 'patch' == 'the ouput from git diff'
[20:53] <barry> thomi: you can append them.  the file is basically patch(1) compatible
[20:53] <barry> usually i group them logically, i.e. here's all the stuff that fixes bug #12345
[20:53] <barry> oops :)
[20:53] <thomi> heh
[20:53] <thomi> cool
[20:54] <thomi> wow, isdn... blast from the past
[20:54] <barry> 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] <barry> i.e. when they fix bug #1
[20:54] <barry> \o/
[20:54] <thomi> :)
[20:55] <thomi> I love that the Ubuntu Malaysia LoCo team has taken it upon themselves to fix the bug
[20:56] <thomi> hmmm
[20:56] <thomi> that doesn't work
[23:35] <thomi> barry: still around?