[00:04] <nacc> smoser: would you happen to have a guide/info on ensuring that when the annotated tag says 'imported using v1.0' where 1.0 is in our source tree, that it actually is 1.0? I mean, I could use a version file generator, but then that's a static file in the git tree. Presuming one is always running from the git tree, I coudl use `git describe`, but that won't work if running from, e.g., the snap. Or if
[00:04] <nacc> someone (maliciously or accidentally) were to use a released tarball (if we had them) and edited the version file. Or made changes from the released version, and we wouldn't want to indicate it's actually 1.0
[00:06] <nacc> smoser: or really, i'm looking for advice for how to include the importer's version (which itself would be an annotated tag in the importer's repository) in the tag
[00:06] <nacc> barry: --^ maybe you'd have some pythonic insight here too
[00:48] <nacc> smoser: barry: http://paste.ubuntu.com/23341473/ this is what i did locally, and you can see i've tagged (to test) it as 1.0. So then the importer invocation picks up the version from `usd-import`'s git repository. But not sure if that always will work? But I think it might be an appropriate way to feed the version in if we rework the various usd- into usd/ modules
[01:04] <Bluefoxicy> Does anyone know if this is what's causing the issues with Evolution and Google Calendar on 16.10?  https://bugzilla.redhat.com/show_bug.cgi?id=1373737
[01:11] <smoser> nacc, i dont know that there is really any ay to do what you're asking.  I think what you're asking equates to drm or trusted computing.
[01:11] <smoser> wrt getting git-describe into some place where you're running not from git, i ended up giving up in cloud-init.
[01:11] <smoser> i had a way to do it, but then my source tarballs differed from the git code that they represented (by one having 'git describe' in a file and one not).
[01:12] <smoser> and gbp didn't like that, and i decided rather than fighting it i'd accept it.
[01:14] <nacc> smoser: yeah it feels non-trivial all of a sudden; what i have works i think if running from git
[01:14] <nacc> smoser: and we'd just add something to extract it from a file if that fails for released/snap'd versions?
[01:14] <smoser> yeah, i just gave up
[01:14] <smoser> i think its not really worth it.
[01:14] <smoser> i dont think you can trust anything other than an official importer honestly.
[01:15] <smoser> or dont think the effort is worth the gain.
[01:15] <nacc> smoser: ack, it might not be -- so is cloud-init's version hardcoded in the source? and if someone uses a hacked version, you'd not notice?
[01:15] <nacc> yeah
[01:15] <smoser> just don't let someone else run.
[01:15] <smoser> in cloud-init's source, it only now says '0.7.8'
[01:15] <smoser> the 'make tarball' used to append to that the full git describe version
[01:15] <smoser> which was nice, and then when running from package, you'd get that
[01:15] <smoser> you'd get that info in a log
[01:15] <smoser> but i just gave up.
[01:16] <nacc> yeah, it seems like most people use release processes to do this
[01:16] <nacc> and even then, seems like a half-solution
[01:16] <nacc> ok, i'll stop trying any harder at this, then :)
[01:16] <nacc> smoser: thanks, have a good night!
[01:19] <smoser> the thing that i just didn't like... was that the source tarball had different data than the git checkout of the tag.
[01:20] <smoser> which was just obnoxious both as a "cleanliness" thing and also from other tools like gpb that cried foul.
[05:03] <rbasak> nacc: yeah I think that's fine
[05:36] <pitti> Good morning
[06:35] <cpaelzer> good morning
[06:50] <Mirv> err, " format '3.0 (quilt)' is not permitted in zesty."? (PPA upload)
[06:50] <pitti> well, "zesty" does not exist yet in the first place? https://launchpad.net/ubuntu/
[06:51] <Mirv> oh, right, I didn't check it anymore since bileto enabled zesty :) robert was too fast.
[06:53] <pitti> not exactly the most obvious error message too :)
[07:18] <sarnold> nacc: normally I'd say pass the bug number along to whoever did the update, but this week email to security@ubuntu.com is probably more reliable
[08:17] <Mirv> heh, zesty now created, the next obvious error message on PPA uploads is "Cannot build any of the architectures requested: any all
[08:17] <Mirv> but 3.0 (quilt) source format is fine now! :)
[08:39] <pitti> Mirv: haha
[10:26] <highvoltage> http://community.ubuntu.com/release-widget/ may require some maintenance
[10:29] <Unit193> highvoltage: You tried py3 speedtest-cli, btw?
[10:32] <highvoltage> Unit193: funny you should mention that, I spent a few minutes this morning trying to figure out some speedtest-cli performance related problems. I think it might stem from speedtest moving all their primary clients to just using sockets and they don't care about the http clients anymore
[10:38] <highvoltage> Unit193: speedtest-cli does work in python3 though, and doing some quick tests it seems to be giving me closer results to the official client
[10:42] <Unit193> highvoltage: Well that's crappy..  Yeah I tested a "port" of the packaging, only noticed a little oddity in the output.
[10:42] <Unit193> Interesting about being closer though.
[10:44] <highvoltage> Unit193: yep, ideally there would be a free speedtest community with its own servers and clients, but we're getting firmly into the off-topic zone for this channel :)
[13:04] <seb128> bdmurray, pitti, rbasak, commented back on bug #1580740 the static version included in the xenial upload is noise, the makefile generates that file at buildtime
[13:05] <seb128> yakkety is fine
[13:12] <bdmurray> seb128: thanks, I've released it
[13:12] <seb128> bdmurray, thanks
[15:40] <smoser> slangasek, you reverted xenial for bug 1621507. i think you should revert yakkety also.
[15:40] <slangasek> cyphermox: ^^
[15:42] <cyphermox> yes, I am aware, working on it
[16:07] <smoser> cyphermox, you'll revert it? or you're planning on just adding another fix first
[16:08] <smoser> i think yakkety should be reverted, and fix should go first to zesty
[16:17] <tsimonq2> infinity: Are you aware that Lubuntu Xenial Daily is FTBFS due to a kernel dep issue?
[16:18] <infinity> tsimonq2: It's transient.
[16:18] <tsimonq2> Whoops, meant to put that in -release.
[16:19] <tsimonq2> infinity: Ok thanks
[16:36] <cyphermox> smoser: I'll revert it
[16:43] <nacc> smoser: would you say if the importer was going to be python3 only (which it is), it's worth going through and putting in type-hinting?
[16:46] <smoser> i have no experience with type hinting.
[16:46] <nacc> smoser: ok, i was just looking at it -- might ensure some things get caught earlier, and it seems like good documetnation
[16:53] <jgrimm> nacc, oh.. i read a good artice on that last week.. apparently some python 2 support for it too via mypy  ->  http://blog.zulip.org/2016/10/13/static-types-in-python-oh-mypy/
[16:54] <nacc> jgrimm: nice
[16:55] <nacc> jgrimm: yeah, our code isn't complicated, but i think adding the hints will simplify maintenance
[16:56] <jgrimm> adn usd-* seems like small enough project to try out even.
[17:04] <nacc> jgrimm: 100% ack
[17:05] <nacc> jgrimm: esp. as i'm looking at seeing if we can organize the code a bit better before 1.0, just to make it easier to read :)
[17:05] <jgrimm> :)