[02:00] <wemeetagain> is there any documentation/information about how ubuntu is handling the transiion to the c++11 abi?
[02:02] <wemeetagain> are packages in 16.04 being compiled with dual abi/ c++11 abi support?
[04:56] <RAOF> wemeetagain: Nope; it's all new ABI.
[08:11] <xnox> PHLin, new launchpadlib should be in yakkety now - could you please test if that's all good now?
[08:12] <PHLin> xnox, ok let me try
[09:25] <PHLin> xnox, hey there, launchpadlib tested with Yakkety dailylive image, and it works, thanks!
[09:30] <xnox> PHLin, whoop whoop.
[09:30] <xnox> PHLin, I see that in your repository you have a port to python3 for this helper lptk library or some such. It's packaged in the distribution as well, are you planning to upload python3 version of it into Yakkety too?
[09:41] <cjwatson> xnox: Maybe you should wait for review ... your launchpadlib r152 will crash if you pass unicode to that method on Python 2
[09:42] <cjwatson> oh, wait, will it
[09:42] <cjwatson> Yeah, it will if it's unicode and contains non-ASCII characters
[09:42] <PHLin> xnox, need to ask bjf, that port exists before I took part in this :D
[09:43] <cjwatson> xnox: why not "if isinstance(query_string, bytes)"?
[09:52] <xnox> bah, at the moment it bail on me in different way now.
[09:52] <xnox> http://paste.ubuntu.com/23057847/ -> even in python3
[09:54]  * xnox thinks i've screwed up multiple times
[09:54] <cjwatson> no, that one is my fault, will fix
[09:56] <cjwatson> fixed in r153, was a regression in r146
[09:57] <xnox> cjwatson, ack. I rolled back to 145, applied my credentials file fix, and it works correctly.
[09:57] <xnox> cjwatson, as far as understand in python2 the query_string is unicode object, not string.
[09:58] <xnox> no that's wrong.
[09:59] <cjwatson> Don't care what it is; my point is that you can't necessarily decode a unicode object.
[10:00] <xnox> true.
[10:00] <cjwatson> >>> sys.version
[10:00] <cjwatson> '2.7.12 (default, Jul  1 2016, 15:12:24) \n[GCC 5.4.0 20160609]'
[10:00] <cjwatson> >>> u'é'.decode('utf-8')
[10:00] <cjwatson> ...
[10:00] <cjwatson> UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 0: ordinal not in range(128)
[10:00] <xnox> but i only need to decode in python3. And "if isinstance(query_string, bytes)" breaks in python2 for this case
[10:01] <cjwatson> Why does it break?
[10:01] <xnox> as str & bytes are the same in python, and decoding code path is triggered.
[10:01]  * xnox checks my previous py3 macros in that file
[10:01] <cjwatson> And why does that break?
[10:02] <cjwatson> In one of my previous comments I noted that it should work fine with unicode on Python 2.
[10:02] <xnox> in other places we do
[10:02] <xnox> 153        if not isinstance(value, unicode_type):
[10:02] <xnox> 154            value = value.decode('utf-8')
[10:03] <xnox> which is correct, as we correctly set unicode_type to be the right thing for python2 and python3.
[10:04] <cjwatson> I think either your approach or mine would work.
[10:04] <xnox> horum yes.
[10:04] <xnox> $ python2 -c "if isinstance('string', bytes): 'string'.decode('utf-8')"
[10:04] <xnox> does not explode.
[10:12] <xnox> cjwatson, changed to use "if isinstance(query_string, binary_type)" which is actually the same as "if isinstance(query_string, bytes)" given the macros at the start of the file.
[10:12] <xnox> and i guess i'll need both of these commits uploaded now.
[10:14] <cjwatson> what?
[10:14] <cjwatson> if you mean "if isinstance(query_string, bytes)" then just write that.
[10:14] <cjwatson> no reason to use binary_type.
[10:16] <cjwatson> in fact binary_type should not exist; it's only for compatibility with pre-2.6 and we don't care about that any more.
[10:16] <cjwatson> xnox: ^-
[10:18] <xnox> what was special about pre-2.6 that warranted that. I'm pretty sure binary-type was cargo-culted from six / write py2&3 compatible code guides.
[10:18] <cjwatson> xnox: pre-2.6 didn't have "bytes"
[10:18] <xnox> oh
[10:18] <xnox> quite, don't care about that.
[10:19] <cjwatson> six was designed to support quite old versions of Python, but launchpadlib has no good reason to care
[10:19] <cjwatson> even six probably doesn't particularly any more, but inertia
[10:20] <xnox> yeap.
[10:21] <cjwatson> now, my approach does mean that AccessToken will be constructed with unicode attributes
[10:21] <cjwatson> so actually perhaps "if not isinstance(value, unicode_type)" is safer
[10:24] <xnox> cjwatson, python3 -c "from launchpadlib import launchpad as lp; lp.Launchpad.login_with('foobar', credentials_file='foobar.txt')" still explodes in both python2 & 3.
[10:24] <xnox> in a different spot now.
[10:24] <xnox> cjwatson, http://paste.ubuntu.com/23058020/
[10:25] <xnox> correct because i shall not copy & paste bad things
[10:25] <cjwatson> your code is broken :)
[10:26] <cjwatson> so yeah, s/content/query_string/g in that bit and may as well make it the slightly more conservative not unicode_type test while you're there.
[10:27] <xnox> yeah credentials is conservative like that: if unicode_type to serialise; if not unicode_type to decode.
[10:51] <RAOF> Hm. What's the way we get new CI'd projects into the archive?
[11:21] <ginggs> doko: libixion and liborcus need updated symbols for the gcc6/boost1.61 transition, do they need a soname bump as well?
[11:23] <sitter> juliank: hey. any thoughts on the os-release mess? I am thinking only using it for is_like right now as to preserve capitalization from lsb_release, but long-term this really needs an API behavior break and coerce the Distribution attributes id, codename and release to lower case so we have normalized expectations both internally and externally
[11:24] <juliank> I don't think anyone is relying on the casing of the distro names?
[11:25] <sitter> juliank: I am always wary of breaking behavior, regardless of whether I know it is used :)
[11:25] <juliank> But I'm probably wrong.
[11:25] <juliank> s/'m probably/might be/
[12:26] <Riddell> bdmurray: ping?
[14:59] <Odd_Bloke> infinity: Where are we on getting sagari's kernel upgraded to something that can handle metadata_csum?
[15:11] <dobey> hmm
[15:11] <dobey> how do seeds handle conditional dependencies when building the ISOs for example?
[15:14] <doko> ginggs, libixion is in NEW
[15:24] <zul> can someone please promote python-ws4py please https://bugs.launchpad.net/ubuntu/+source/python-ws4py/+bug/1590425
[15:33] <ogra_> dobey, depends on the flavour ... some use tasks and some use metapackages ... both resolve slightly different
[15:37] <dobey> ogra_: right, but say i need to support both snaps and clicks, and so i want to have "snapd | click" as a dependency, what happens?
[15:38] <ogra_> well, you seed both or one ... and hope for the best :P
[15:47] <ginggs> doko: yup i see 0.12 experimental there, i uploaded 0.11 with updated symbols in the meantime
[15:49] <cjwatson> dobey: seeds don't have conditional dependencies; you have to pick one
[15:49] <cjwatson> dobey: they exist to be opinionated
[15:50] <cjwatson> dobey: but are you in fact talking about what happens if something that is seeded itself has alternative dependencies?
[15:50] <cjwatson> dobey: rather than trying to put alternatives in the seeds themselves?
[15:50] <dobey> cjwatson: yes
[15:51] <dobey> cjwatson: so if my package, which is seeded, has a conditional dep, and both are in main, does first get picked?
[15:55] <cjwatson> dobey: in most cases yes, though it's a little bit more complicated than that.  the algorithm is as follows: (1) are any of the alternatives explicitly (i.e. not just via deps) listed in this seed?  if so, pick the first.  (2) is the first alternative explicitly listed in a seed that inherits from this seed?  if so pick that.  (3) are any of the other alternatives explicitly listed in a "close-by" s
[15:55] <cjwatson> eed (i.e. one that generates the same ...
[15:55] <cjwatson> ... task, as defined by Task-Seeds headers)?  if so, pick the first.  (4) pick the first of the alternatives that exists.
[15:55] <cjwatson> dobey: the point of all this palaver is to make it possible for flavours to pick different versions of things by explicitly seeding them, but to use sensible defaults.
[15:57] <cjwatson> dobey: it is not relevant whether any of the dependencies are in main; seeds are used to define what's in main, so we don't circularly use what's in main to define how seeds expand.
[15:58] <dobey> hmm, ok
[17:18] <wemeetagain> RAOF: are packages built with the --std=c++11 option set as well?
[17:20] <wemeetagain> RAOF: from https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html , it appears that the ABI can be set independently of the --std option
[18:31] <mterry> bdmurray: so about unity-api-bugs vs -team...  Does the -bugs team even seem useful if it's just two people?
[18:31] <mterry> bdmurray: the -team team is already subscribed to most of their packages, it doesn't seem like they are looking to avoid bugmail
[18:34] <bdmurray> mterry: The number of the people related to the team doesn't really matter. The team is just an entity for scripts which create reports like http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-y-tracking-bug-tasks.html. I'm fine with switching the team though, iirc I just created teams in some cases as the quickest way to get the reports up and running.
[18:35] <mterry> bdmurray: but I thought one point was that somewhere someone was reading the bugmail
[18:37] <bdmurray> mterry: yes, for new MIRs that's true.
[18:39] <mterry> bdmurray: if you don't care, I'd just as soon use the LP team that the actual maintainers are using
[18:39] <bdmurray> mterry: That makes sense to me