[00:04] 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] 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] 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] barry: --^ maybe you'd have some pythonic insight here too [00:48] 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] 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:04] bugzilla.redhat.com bug 1373737 in evolution-data-server "Evolution reports quota exeeded for Google calendars every morning" [High,Closed: nextrelease] [01:11] 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] wrt getting git-describe into some place where you're running not from git, i ended up giving up in cloud-init. [01:11] 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] and gbp didn't like that, and i decided rather than fighting it i'd accept it. [01:14] smoser: yeah it feels non-trivial all of a sudden; what i have works i think if running from git [01:14] smoser: and we'd just add something to extract it from a file if that fails for released/snap'd versions? [01:14] yeah, i just gave up [01:14] i think its not really worth it. [01:14] i dont think you can trust anything other than an official importer honestly. [01:15] or dont think the effort is worth the gain. [01:15] 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] yeah [01:15] just don't let someone else run. [01:15] in cloud-init's source, it only now says '0.7.8' [01:15] the 'make tarball' used to append to that the full git describe version [01:15] which was nice, and then when running from package, you'd get that [01:15] you'd get that info in a log [01:15] but i just gave up. [01:16] yeah, it seems like most people use release processes to do this [01:16] and even then, seems like a half-solution [01:16] ok, i'll stop trying any harder at this, then :) [01:16] smoser: thanks, have a good night! [01:19] 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] which was just obnoxious both as a "cleanliness" thing and also from other tools like gpb that cried foul. [05:03] nacc: yeah I think that's fine [05:36] Good morning [06:35] good morning [06:50] err, " format '3.0 (quilt)' is not permitted in zesty."? (PPA upload) [06:50] well, "zesty" does not exist yet in the first place? https://launchpad.net/ubuntu/ [06:51] oh, right, I didn't check it anymore since bileto enabled zesty :) robert was too fast. [06:53] not exactly the most obvious error message too :) === _salem is now known as salem_ [07:18] 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 === salem_ is now known as _salem [08:17] heh, zesty now created, the next obvious error message on PPA uploads is "Cannot build any of the architectures requested: any all [08:17] but 3.0 (quilt) source format is fine now! :) [08:39] Mirv: haha === _salem is now known as salem_ === salem_ is now known as _salem === _salem is now known as salem_ === doko_ is now known as doko === salem_ is now known as _salem [10:26] http://community.ubuntu.com/release-widget/ may require some maintenance [10:29] highvoltage: You tried py3 speedtest-cli, btw? [10:32] 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] 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] highvoltage: Well that's crappy.. Yeah I tested a "port" of the packaging, only noticed a little oddity in the output. [10:42] Interesting about being closer though. [10:44] 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 :) === _salem is now known as salem_ [13:04] 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:04] bug 1580740 in Snappy "[SRU] Cannot open a browser link from a snap that provides a link" [High,Triaged] https://launchpad.net/bugs/1580740 [13:05] yakkety is fine [13:12] seb128: thanks, I've released it [13:12] bdmurray, thanks === salem_ is now known as _salem === BrAsS_mOnKeY is now known as g2` [15:40] slangasek, you reverted xenial for bug 1621507. i think you should revert yakkety also. [15:40] bug 1621507 in initramfs-tools (Ubuntu Yakkety) "initramfs-tools configure_networking() fails to dhcp ipv6 addresses" [High,In progress] https://launchpad.net/bugs/1621507 [15:40] cyphermox: ^^ [15:42] yes, I am aware, working on it [16:07] cyphermox, you'll revert it? or you're planning on just adding another fix first [16:08] i think yakkety should be reverted, and fix should go first to zesty [16:17] infinity: Are you aware that Lubuntu Xenial Daily is FTBFS due to a kernel dep issue? [16:18] tsimonq2: It's transient. [16:18] Whoops, meant to put that in -release. [16:19] infinity: Ok thanks [16:36] smoser: I'll revert it [16:43] 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] i have no experience with type hinting. [16:46] smoser: ok, i was just looking at it -- might ensure some things get caught earlier, and it seems like good documetnation [16:53] 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] jgrimm: nice [16:55] jgrimm: yeah, our code isn't complicated, but i think adding the hints will simplify maintenance [16:56] adn usd-* seems like small enough project to try out even. [17:04] jgrimm: 100% ack [17:05] 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] :) === Beret- is now known as Beret === _salem is now known as salem_ === salem_ is now known as _salem