[01:37] <wallyworld> babbageclunk: a few small comments
[01:38] <babbageclunk> wallyworld: thanks
[07:50] <frankban> wallyworld: hey, do you have time for taking a look at https://github.com/juju/juju/pull/8427 ?\
[07:52] <wallyworld> frankban: sure, but it's not an area i know much about
[07:53] <frankban> wallyworld: ty I already got suggestions from roger in the apiserver area
[07:53] <wallyworld> i need to make dinner etc first but will look as soon as ai can
[07:57] <frankban> wallyworld: ty!
[10:11] <rogpeppe> anyone know what Go version is being used for Juju CI tests?
[10:42] <externalreality> Question: I am using go version 1.9.4 - I pulled develop - gofmt was beside itself with grief (or just sad) when I ran it. What version of Go is Juju being built with now (Github says 1.9)?
[10:43] <rogpeppe> externalreality: are you using a recent version of gofmt?
[11:19] <externalreality> rogpeppe: which gofmt yields '/snap/bin/gofmt'
[11:20] <rogpeppe> externalreality: what does "which go" print?
[11:20] <externalreality> rogpeppe: the snap - it yields /snap/bin/go
[11:21] <rogpeppe> externalreality: hmm, so they *should* be consistent :)
[11:23] <externalreality> I get:
[11:23] <externalreality> gofmt is sad:
[11:23] <externalreality>   cmd/juju/commands/helptool.go
[11:23] <externalreality> error: failed to push some refs to
[11:23] <externalreality> rogpeppe so it is just the one file
[11:25] <rogpeppe> externalreality: looks like that file is just wrong
[11:26] <rogpeppe> externalreality: it's got an extra newline at the end
[11:26] <rogpeppe> externalreality: i wonder how that got through CI
[11:28] <rogpeppe> externalreality: looks like https://github.com/juju/juju/pull/8428 is at fault
[11:28] <rogpeppe> externalreality: maybe CI is no longer checking for gofmt exact output
[11:28] <rogpeppe> externalreality: (which would be sensible, tbh, as the output can vary between go releases)
[11:28] <rogpeppe> externalreality: it's changed a fair number of files in go1.10 for example
[11:29] <rogpeppe> externalreality: BTW the -l (list files that would be changed) and the -d (show diffs) flags to gofmt can be useful
[11:30] <externalreality> Wondeful! Thank you rogpeppe.
[11:30] <rogpeppe> externalreality: np :)
[11:31] <rogpeppe> externalreality: will see you at the budapest sprint, i hope :)
[11:31] <rogpeppe> assuming my airport hasn't closed from all the snow...
[11:36] <externalreality> rogpeppe, :-D
[17:01] <kwmonroe> hey anastasiamac, do we have a point-person for the juju vsphere provider? i'm looking for a triage on bug 1751858.
[17:01] <mup> Bug #1751858: support vsphere disk.enableUUID model config <juju:New> <https://launchpad.net/bugs/1751858>
[17:35] <mup> Bug #1752662 opened: ssh-proxy does not work as expected on AWS <juju-core:New> <https://launchpad.net/bugs/1752662>
[17:41] <mup> Bug #1752662 changed: ssh-proxy does not work as expected on AWS <juju-core:New> <https://launchpad.net/bugs/1752662>
[17:50] <mup> Bug #1752662 opened: ssh-proxy does not work as expected on AWS <juju-core:New> <https://launchpad.net/bugs/1752662>
[23:10] <anastasiamac> kwmonroe: afaik, no (sorry for delay in answering - was 3am my time) but m following it up to ensure u get answers re vsphere :D
[23:11] <kwmonroe> np anastasiamac - thanks for the followup!
[23:19] <hml> exit
[23:19] <hml> :-) wrong window
[23:35] <wallyworld> babbageclunk: sometime today if i could land this would be most awesome. a bit of boilerplate as is usual when adding a facade https://github.com/juju/juju/pull/8441
[23:41] <babbageclunk> wallyworld: ok, will take a look after the meeting
[23:42] <wallyworld> yay
[23:47] <rick_h> thumper: how did the webinar go?


[03:05] <bazhang> @mark #ubuntu+1 smallfoot-  usual serial complaining as opposed to helping out filing bugs


[01:16] <lifeless> maxb: thats probably because the maintainer script to clean them up is not present in the new package
[15:56] <jelmer> maxb: hmm, I'm not sure I follow
[15:57] <jelmer> maxb: some sort of shim?
[17:27] <jelmer> hmm, odd
[17:27] <jelmer> Bad Gateway error during recipe build :_/
[17:52] <beuno> hi vila!
[17:52] <beuno> any bzr devs around?
[17:52] <vila> beuno: hey. No, I'm not really there, just relaunched xchat
[17:53] <beuno> :)
[18:07] <jelmer> hey beuno
[18:08] <beuno> hey jelmer!  happen to be bored?  :)
[18:08] <beuno> I'm working on a branch to add downloading tarballs to loggerhead
[18:09] <beuno> lifeless pointed out that saving them to a dir to serve them isn't super optimal, but it seems I don't really have an (easy) choice with the way things are set up in bzr
[18:09] <beuno> wanted some smarter eyes to confirm
[18:10] <beuno> *download tarballs of revisions _from_ loggerhead
[18:10] <beuno> bzrlib.export.export only takes a path
[18:11] <jelmer> yeah, it seems like we should be able to improve on that
[18:11] <jelmer> though we should watch out for keeping lp:linux tarballs in memory, too
[18:12] <beuno> right
[18:13] <beuno> I started digging in bzrlib, and it's not trivial to change this
[18:13] <jelmer> it looks like there already is some support for writing to stdout
[18:13] <beuno> oh?
[18:14] <jelmer> '-' is treated specially
[18:14] <jelmer> in bzrlib.export.tar_exporter
[18:14] <beuno> ah
[18:15] <beuno> interesting, I missed that
[18:16] <jelmer> this might also be a good moment to fix some other related issues
[18:16] <jelmer> bug 513752 and bug 711226
[18:17] <jelmer> (also cases where it would help if the exporters could write to an arbitrary stream rather than a specific file)
[18:17] <beuno> hm, if I specify -, it creates a dir called -   :/
[18:17]  * beuno nods
[18:17] <jelmer> you need to specify the format I think
[18:19] <beuno> right, that seems to work
[18:19] <beuno> well, "work", now I need to capture stdout and stream that
[18:20] <beuno> I suspect this may be harder to actually deploy on launchpad, though
[18:20] <jelmer> beuno: urgh
[18:23] <jelmer> beuno: we should just factor the relevant code out of bzrlib.export.tar_exporter
[18:24]  * beuno nods
[18:24] <beuno> doesn't seem too hard, it's just quickly getting out of hand  :)
[18:24] <lifeless> beuno: a temp *file* would be ok
[18:25] <lifeless> beuno: its a persistent temp dir I was whining about
[18:25] <beuno> lifeless, ah, hi lifeless   :)
[18:25] <beuno> lifeless, well, that makes things much simpler
[18:26] <lifeless> a temp file will clean up when its closed
[18:28] <beuno> lifeless, ok, so I'll fiddle with this stdout approach for a bit so at least I have it handy, and then change it to use a tmp path
[18:29] <lifeless> beuno: tmp *file* specifically - tempfile.TemporaryFile
[18:30] <beuno> lifeless, ack
[18:33] <maxb> jelmer: So, what I was thinking was either a straight backport of dh_python2, or a fake dh_python2 executable or debhelper sequence file that would run pycentral instead
[18:34] <maxb> Either way, a solution which does not require modifications to each package's packaging
[18:49] <jelmer> maxb: sounds reasonable
[18:51] <beuno> lifeless, so, since bzrlib.export only really takes a path, it seems I'd need to poke at bzrlib in order to use a TemporaryFile
[18:52] <beuno> or capture stdout and write to this new tempfile
[18:52] <beuno> or...  maybe this temp file has a path, which I guess it would
[18:53] <beuno> of course it does
[18:56] <lifeless> beuno: you may need to change bzrlib.export
[18:56] <lifeless> beuno: TemporaryFile doesn't have a name
[18:56] <lifeless> NamedTemporaryFile is not crash proof
[18:56] <beuno> lifeless, no, but NamedTemporartFile... ah
[18:56] <lifeless> NTF depends on __del__
[18:57] <lifeless> if we kill the process - not unheard of :P - it will leak and slowly mess up /tmp
[18:57] <jelmer> beuno: fwiw I've got a branch which should let you do what you need
[18:57] <beuno> hmeland_, w00t!  that's great
[18:57] <beuno> er
[18:57] <beuno> jelmer, I meant  :)
[18:58] <beuno> although, it kinda sucks for this feature to depend on a future bzr
[18:58] <jelmer> it factors out the bit of bzrlib.export.tar_exporter that writes to the tarball, so it requires you to pass in a tarfile.tarfile object and a tree
[18:59] <beuno> I guess I could hack in using stdout for older bzr versions, and the cleaner one for newer ones
[19:06] <maxb> jelmer: Hi. Shall I file bugs to have the ftpmasters update the overrides for qbzr and wikkid, both of which got override disparity emails on their most recent uploads, or is that on your todo list?
[19:23] <jelmer> maxb: Oh, I don't think I have seen those.
[19:53] <maxb> jelmer: they went to<EMAIL_ADDRESS>and<EMAIL_ADDRESS>[19:55] <jelmer> maxb: wikkid probably should be web
[19:55] <maxb> I think in both cases the package has it right
[19:56] <jelmer> maxb: yeah
[19:57] <maxb> i.e. wikkid s/vcs/web/ because its defining characteristic is being a wiki
[19:57] <jelmer> maxb: if you can file bugs that'd be great
[19:57] <maxb> will do
[21:19] <jelmer> beuno: https://code.launchpad.net/~jelmer/bzr/export-tgz-711226/+merge/53183
[21:36] <jelmer> hmm, like Launchpad Bazaar has an interesting definition of "easy" when it comes to bugs
[21:54] <beuno> jelmer, \o/   thanks, I'll take a peak in a little while
[21:58] <lifeless> beuno: 'peek'
[23:15] <spiv> Morning folks
[23:28] <arjenAU> mm-mysql: hey mark!
[23:28] <jelmer> spiv: mørning!
[23:30] <spiv> jelmer: hï :P
[23:54] <maxb> jelmer: btw, I've just committed "Take 02_external_configobj out of debian/patches/series because it causes tests to fail." to the daily-ppa branch. Any thoughts on what we do about that for Debian?
[23:54] <jelmer> maxb: submitting the fix to the python-configobj package
[23:56] <jelmer> it's on my todo list but I haven't had time to do it yet


[03:19] <Burgundavia> can someone tell me why the following link looks different from the 2nd link?
[03:20] <Burgundavia> https://launchpad.ubuntu.com/distros/ubuntu/hoary/+translations
[03:20] <Burgundavia> https://launchpad.ubuntu.com/rosetta
[03:26] <mdke> Burgundavia, you mean the content is different?
[03:26] <mdke> the second link shows everything that can be translated in rosetta, not just the ubuntu stuff
[03:29] <Burgundavia> yes, but the 2nd link has much less stuff in it
[03:30] <mdke> Burgundavia, the second link goes by category, the first link is everything is one of those categories (Ubuntu hoary)
[03:30] <mdke> if i understand correctly
[03:30] <Burgundavia> oh
[03:30] <Burgundavia> my thought is the first link is some auto importer
[03:31] <Burgundavia> and the 2nd link is the manually added stuff to rosetta
[03:32] <mdke> the first link shows the packages in hoary, which are auto imported. The second link shows ubuntu hoary, and a number of other upstream programs which have chosen to use rosetta to translate upstream
[03:44] <HiddenWolf> I have to say, this is too much. I just registered on launchpad, and look at the top menu bar -> " Launchpad  distros  ubuntu  hoary  +sources  ubuntu-docs  +pots  aboutubuntu  nl  +translate  +login"
[03:44] <HiddenWolf> bit of an overload!
[03:46] <carlos> HiddenWolf, ?
[03:47] <HiddenWolf> it takes up 2 lines on this screen, lol
[03:48] <HiddenWolf> all the navigation tabs listed out like that is just confusing
[03:49] <carlos> HiddenWolf, oh, that!
[03:49] <carlos> yeah, we are aware of it, but it's not a priority to fix it atm
[03:50] <HiddenWolf> some serious navigational tree issues, if you ask me =)
[03:51] <HiddenWolf> Suddenly becomes annoying on a monitor 5" smaller than my own. ;)
[03:54] <carlos> HiddenWolf, yeah, that's true


[21:31] <tuchkata> anyone tried
[21:31] <tuchkata> 15.04 with Gnome 3.16?
[21:39] <Noskcaj> darkxst, Do we want the packaged extra gnome shell extensions in the staging PPA? most need upstream patches for 3.16