[02:53] <vipzrx> hello
[03:25] <vipzrx> hello ,everyone
[06:31] <Noskcaj> if kirkland or andreseal is online, get them to ping me please
[11:37] <jamespage> jodh, around? have you seen upstart doing something like this before: http://paste.ubuntu.com/5683425/
[11:47] <cjohnston> cjwatson: I believe /7
[11:48] <cjohnston> sorry. I believe I have an email pending on ubuntu-devel.. when you get a chance, could you please ack it
[11:53] <cjwatson> cjohnston: done
[11:53] <cjohnston> ty cjwatson
[12:51] <jodh> jamespage: it looks correct based on what the somewhat elaborate .confs specify. I've never used ceph though :)
[12:52] <jamespage> jodh, the ceph processes are OK - I just wondered why there are not proc 1 owned (the sh wrapper is)
[12:53] <jamespage> i.e. init -> sh -> ceph-mon for example
[12:53] <jodh> jamespage: because the job doesn't specify "exec" in the script stanza so upstart spawns ad shell to run what is in that stanza.
[12:53] <jamespage> jodh, "exec /usr/bin/ceph-mon --cluster="${cluster:-ceph}" -i "$id" -f"
[12:53] <jamespage> looks OK to me
[12:55] <jamespage> jodh, full listing - http://paste.ubuntu.com/5683597/
[12:55] <cjwatson> ${cluster:-ceph} requires a shell to evaluate it
[12:55] <jodh> jamespage: ah - well, upstart cleverly detects that the exec line specifies shell syntax, and so passes the arguments through /bin/sh for you (otherwise, it wouldn't work :)
[12:55] <cjwatson> See init(5) - "Any special characters, e.g. quotes or `$' specified will result in the entire command being passed to a shell for expansion."
[12:55] <jamespage> cjwatson, jodh: ah! right - I thought it might be something like that
[12:55] <jamespage> thanks
[12:56] <jodh> jamespage: in your case, "$" is used, which causes the shell to be spawned.
[14:27] <cjwatson> Any MIR folks want to have a look at graphite2?  It's a bit inconvenient for texlive to be uninstallable in saucy-proposed.
[14:29] <infinity> cjwatson: It has no bug filed.
[14:30] <infinity> cjwatson: (Also, I'm about to go nap, yay long weekend, but if someone like jdstrand or mterry doesn't beat me to it, I'll look at it when I wake up)
[14:30] <ogra_> oh, canada too ?
[14:31] <cjwatson> Yeah, I was tracking down the version of texlive-bin that introduced the build-dep before filing a bug
[14:31] <cjwatson> But it's not in the changelog so that's involving a bit of downloading
[14:31] <infinity> Hrm.  If graphite2 is a simple evolution of silgraphite2.0, you can just promote it without an MIR.  You might want to poke the sources and see if it's just a renaming of the upstream project.
[14:31] <cjwatson> Oh, hadn't twigged to silgraphite2.0
[14:32] <cjwatson> I'll see if the build-dep changes bear that out
[14:33] <cjwatson> Looks like libgraphite-dev (>= 1:2.3.1) -> libgraphite2-dev
[14:34] <cjwatson> -  --with-system-graphite  use installed silgraphite headers and library
[14:34] <cjwatson> +  --with-system-graphite2 use installed graphite2 headers and library
[14:34] <infinity> cjwatson: Yeah, I was more curious if it really is basically just a new version of the same source.
[14:34] <infinity> Or if it's an entirely new and differently sketchy version of a similar library.
[14:35] <cjwatson> Also would be nice if we could only have one in main
[14:36] <infinity> Yeah, that's probably easily solved.  libgraphite3 has almost no rdeps.
[14:37] <cjwatson> Hmm.  If it's the same thing, it's laid out very differently.
[14:37] <infinity> *&%! tarball-in-tarball packaging of silgraphite2.0 makes diffing a bit of a pain. :P
[14:37]  * infinity unpacks.
[14:37] <cjwatson> Though graphite2's debian/copyright says http://sf.net/projects/silgraphite
[14:38] <cjwatson> Which says "Graphite2, a new version of the Graphite engine"
[14:38] <tumbleweed> tarball-in-tarball isn't dead yet? :/
[14:39] <tumbleweed> infinity: are there any significant differences between PPA and primary archive chroots / environment? I'm trying to figure out why pypy PPA builds are hanging on a particular test
[14:39] <infinity> cjwatson: The layout's completely different, but if the upstream's the same, I'm all for screaming "la la la", and swapping them.
[14:39] <cjwatson> There seems to be a kind of spiritual ancestry here but I'm getting more of a rewrite-from-scratch sense
[14:39] <infinity> cjwatson: texlive is the only thing in main that depends on it.
[14:41] <infinity> tumbleweed: The chroots are identical, installed packages could differ if you haven't let your PPA depend on -proposed (it's a twiddle), and kernels could be different (virtual PPAs are hardy kernels on Xen, non-virt builders are precise kernels on bare metal)
[14:41] <cjwatson> http://projects.palaso.org/projects/graphitedev/wiki
[14:41] <cjwatson> Oh, I guess c-m-proposed doesn't want to drop silgraphite2.0 yet because binary deps aren't yet up to date
[14:41] <tumbleweed> infinity: ok, that gives me some things to play with. thanks
[14:42] <cjwatson> infinity: OK, sounds like "swap it", then - I'll make that happen today
[14:43] <cjwatson> I have a bit of a chain of stuff on top of this.
[14:43] <infinity> cjwatson: Bonus points if we could ditch the old one entirely, but who knows if pango-graphite is ported.
[14:44] <cjwatson> infinity: Probably have to wait for Debian there
[14:45] <infinity> cjwatson: We didn't end up breaking the world with a tex transition this time at least, I hope?  Just this component oops?
[14:45]  * infinity has nightmares about having to rebootstrap tex* crap yet again.
[14:45] <cjwatson> Hope not, but can't tell yet.
[14:46] <cjwatson> texlive-bin doesn't seem to have tight build-deps.
[14:46] <infinity> Well, the killer used to be that we carried a delta on exactly one tex* package, and if we let autosync sync the rest, it would skew and none of it would build anymore.
[14:46] <cjwatson> Or indeed to build-dep on anything texish.
[14:47] <cjwatson> I *think* we got rid of that delta ...
[14:47] <cjwatson> Wasn't that tex-common?
[14:47] <infinity> Yeah, that delta was in texlive-bin, I think.
[14:48] <cjwatson> I've spent the best part of a day cleaning up bits in -proposed.  I should probably do some actual work at some point ...
[14:48] <infinity> Heh.  At least it was your work day.
[14:48] <cjwatson> https://launchpad.net/builders/ - are the armhf builders a bit sad?
[14:48] <cjwatson> 47 minute queue, allegedly 7 builders idle.  I suspect porkies.
[14:48] <infinity> cjwatson: They lost track of a PDU that happened to be the only way to stab a bunch of the Pandas, so as they've been dying for other reasons, they've been unrecoverable.
[14:49] <infinity> I'm told this is in progress.
[14:49] <cjwatson> Oh dear
[14:49] <infinity> The idle buildds are suspicious, though.
[14:49] <cjwatson> Yeah, sounds more like buildd-manager fail.
[14:49] <infinity> That could be a Network Event causing a mass Right to Choose exercise.
[14:51] <NikTh> Hello everybody.
[14:52] <infinity> Anyhow, I'm going to go enjoy my freedom to not be tied to a laptop for a day.
[14:52] <NikTh> QUESTION: Do I have to do something special in order for debuild to sign a .dsc file when I want to upload a custom kernel on a PPA of mine ?
[14:53] <infinity> NikTh: Just run "debsign foo.changes" on the changes file that you plan to upload.
[14:53] <NikTh> I uploaded without problems a custom package of unity-tweak-tool in my PPA ..
[14:54] <NikTh> But I'm not able to debuild correctly a custom kernel. Deubild does not product a .dsc file (only source.changes is not enough)
[14:55] <NikTh> infinity: Thanks I will try that immediately
[14:56] <NikTh> I will describe here step by step what I'm doing right now.. (anyone who wants to help.. welcome)
[14:56] <NikTh> 1) I'm downloading the source code of linux-image-3.8.0-21-generic
[14:58] <NikTh> I'm patching the kernel.. "patch -p1 < ~/foo.patch
[14:59] <NikTh> 3) Now editing the changelog file (dch -i)
[15:00] <NikTh> Ok, what is the next command ?
[15:01] <NikTh> debuild -S -sd -k<keyid> , is that correct ?
[15:06] <NikTh> The results are "Successfully signed changes file" (but not .dsc file created)
[15:15] <cjwatson> NikTh: You're making life hard for yourself by passing -sd.  Why?
[15:16] <cjwatson> I never use -sd.
[15:16] <cjwatson> NikTh: But as for the rest of it, debuild -S should be sufficient to create a .dsc.  Post the whole output on a pastebin.
[15:17] <NikTh> cjwatson: because the source code already exist in Ubuntu repositories. Despite that I used debuild -S -k (without -sd) but the results were the same.
[15:18] <infinity> NikTh: Also, due to the hilarious way the kernel is packaged, dch -i won't do what you think it will.
[15:18] <infinity> NikTh: It's going to update debian/changelog, and then when the clean target runs, debian.master/changelog will get copied over debian/changelog. :P
[15:20] <NikTh> Full terminal results here: http://pastebin.com/mKbn2ggu
[15:21] <NikTh> Yes, yes, yes you have right about this infinity . Overrides my debian/changelog. But how can I fix that ? So I told before that MY source.changes file is exactly the same as the original :P  LoL
[15:22] <infinity> NikTh: "dpkg-source: info: building linux in linux_3.8.0-21.32.dsc"
[15:22] <infinity> NikTh: It built just fine, just with the old changelog.
[15:22] <NikTh> Hahahaha
[15:22] <infinity> NikTh: So, do your 'dch -i', then "cp debian/changelog debian.master/changelog", then do your debuild.
[15:23] <NikTh> hmm.. lets see
[15:23] <cjwatson> NikTh: already exists> -sd is not as necessary for that as you think it is.
[15:25] <NikTh> cjwatson: I've read the instructions here> https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage (see the "options when building" paragraph)
[15:25] <cjwatson> -sd only makes any difference if you are packaging a *new upstream version* and have some specific reason not to include the upstream tarball in the upload.  Which is basically never the case - I haven't needed -sd in 14 years of development.
[15:25] <cjwatson> Yeah, that advice is, well, maybe not wrong as such but pointless.
[15:26] <cjwatson> You can quote me on that.
[15:26] <cjwatson> Anyway, it's not actually the problem here, just a confusing red herring.
[15:27] <cjwatson> -sa *is* sometimes needed because, unlike Debian, our versioning for new upstream versions isn't nearly-always predictable by dpkg-genchanges.
[15:27] <NikTh> Thanks cjwatson . I have no reason to doubt about your development skills. I'm a newbie in ubuntu-devel and just followed the instructions there :-)
[15:28] <cjwatson> Yeah, I appreciate that it's often easiest to just follow the docs.  I didn't realise we were recommending -sd to people.
[15:31] <NikTh> OK, now I did what infinity suggested (cp debian/changelog ...etc) . What is the most correct command for debuild ? debuild -S -k<keyid> (correct cjwatson ? )
[15:32] <cjwatson> Yep, that should be fine.  You can put DEBSIGN_KEYID=<keyid> in ~/.devscripts so you don't have to type it all the time.
[15:32] <cjwatson> So most of the time for ordinary uploads I just use 'debuild -S'.
[15:32] <NikTh> Thanks !
[15:34] <iBelieve> I sent a message to the ubuntu-devel mailing list about a week ago with an idea for Click Packages, but I don't think it ever got posted (I checked the archives, and it isn't in there). Is there a way to see if it got sent to the list, or should I just resend it?
[15:35] <cjwatson> it's probably in the mod queue
[15:35] <cjwatson> I've flushed the remaining click-package-related things out of there now
[15:38] <iBelieve> cjwatson, thanks, that is what I thought, but it just seemed a long time
[15:38] <cjwatson> yours was in there
[15:39] <iBelieve> cjwatson, good, that's nice to know that it actually did send.
[15:40] <NikTh> Victory !!!
[15:40] <NikTh> infinity, cjwatson  !! Thanks a lot. :-)
[15:40] <rbasak> infinity: I've redone the facter merge and included SRU debdiffs for precise, quantal and raring in bug 1173265 - also including a fixes for bug 1170325. Could you have a look when you get in, please?
[15:42] <infinity> rbasak: Long weekend here (I'm both asleep and not at my computer, and possibly also partying and drunk right now), but if you poke me tomorrow, I'd be happy to review and sponsor the lot. :)
[15:47] <rbasak> infinity: will do - thanks!
[15:50] <NikTh> And the e-mail just arrived " Accepted: " :-) :-)
[16:40] <sil2100> Hello, is there anyone from the SRU team here right now?
[16:50] <zequence> I'd like some help with targetting this bug to releases quantal and precise https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1163638, anyone?
[16:52] <bdmurray> kirkland: do you have any plans to SRU bug 1173209?  If not I'll work on it today.
[16:52] <kirkland> bdmurray: go for it
[16:52] <kirkland> bdmurray: I'll verify it for you, if you like
[16:52] <bdmurray> kirkland: I'll let you know thanks
[16:53] <kirkland> bdmurray: thank you!
[17:25] <psusi> shouldn't /etc/os-release identify the specific ubuntu flavor installed?  i.e. Ubuntu Studio or kubuntu?
[17:26] <Riddell> psusi: they're all the same os
[17:30] <psusi> hrm... I guess so..
[17:57] <iBelieve> I've reinstalled Ubuntu several times for various reasons (switching derivatives, etc) so now I have 3 OpenPGP keys (a new one and 2 old ones). Do I need the old ones, or can I delete them?
[17:57] <iBelieve> ^^ OpenPGP keys in my Launchpad account.
[18:12] <tumbleweed> iBelieve: if you aren't going to be signing things with the old ones, you don't need them
[18:14] <iBelieve> tumbleweed, since I don't have them on my computer, no I won't be. Will deleting them affect things that I've already signed, like the Code of Conduct or projects I've contributed to?
[18:14] <tumbleweed> no
[18:15] <tumbleweed> in future, I recommend revoking keys before you lose control of them (or just back them up)
[18:17] <iBelieve> tumbleweed, Okay, thanks for the help and advice.
[18:27] <stgraber> @pilot in
[18:50] <lifeless> barry: so, you suggested we could arrange a chat about image upgrades
[18:50] <barry> lifeless: yep.  stgraber ^^
[18:52] <stgraber> yep, can definitely find some time this week. Today's a public holiday here though so trying to minimize work-related time ;)
[18:53] <lifeless> fair enough
[18:53] <lifeless> what tz's are you both in?
[18:55] <stgraber> we're both on EDT (US/Canada eastern)
[18:56] <lifeless> stgraber: current local time for you?
[18:56] <stgraber> 3pm
[18:59] <lifeless> how about my thursday, your wednesday, at your 1600 ?
[19:01] <barry> lifeless: that would work for me
[19:02] <lifeless> I'd only have 30-45m then, but that's enough to have a solid chat.
[19:02] <stgraber> works for me
[19:04] <slangasek> stgraber: this is officially my worst dpkg hack ever (ifupdown)
[19:04]  * Laney is excited to see it
[19:05] <stgraber> slangasek: haha, yeah, I figured it'd have to be pretty ugly after I read your comment on the cause of the problem ;)
[19:06] <slangasek> Laney: uploaded, enjoy ;P
[19:07] <slangasek> (tested for precise conffile state -> 0.7.5ubuntu4; precise conffile state -> 0.7.5ubuntu3 w/ "no" response -> 0.7.5ubuntu4; precise conffile state -> 0.7.5ubuntu3 w/ "yes" response -> 0.7.5ubuntu4; raring conffile state -> 0.7.5ubuntu3 -> 0.7.5ubuntu4; raring conffile state -> 0.7.5ubuntu4)
[19:08] <slangasek> the only case this doesn't test for is the possibility that in the *next* version of ifupdown the user installs, the md5sum of the conffile changes again
[19:08] <slangasek> in that case, we probably get another conffile prompt :/
[19:09] <slangasek> (only for the precise -> 0.7.5ubuntu4 -> somethingelse case, fwiw)
[19:12] <slangasek> stgraber: ^^ so that means that if you have any reason to change /etc/init.d/networking for saucy+1, we'll need some additional maintainer script handling at that point ;)
[19:13] <stgraber> slangasek: I don't plan on changing it myself, can't speak for Andrew though, he loves changing things ;)
[19:14] <slangasek> stgraber: yeah ;)  but if you *merge* a change, too :)
[19:17] <lifeless> stgraber: whats your ubuntu email ?
[19:17] <stgraber> lifeless<EMAIL_ADDRESS>[19:19] <lifeless> stgraber: barry: invity thing sent
[19:20] <barry> lifeless: cool
[19:21] <catbus1> Anyone know when kernel freeze will be for 12.04.3? No such info on https://wiki.ubuntu.com/PrecisePangolin/ReleaseSchedule
[19:27] <mlankhorst> catbus1: raring kernel is used
[19:30] <catbus1> mlankhorst: the kernel freeze date for LTS point release is for new hardware support, right? raring kernel is already frozen, only critical patches/fixes can go in as SRU.
[20:53] <cjwatson> Laney: Could you merge (ish) the new fonts-dejavu package from Debian?  It's needed to make texlive-fonts-extra installable again.
[20:54] <cjwatson> And you're touched-it-last and ttf-dejavu
[20:54] <cjwatson> s/and/on/  # how did that happen?
[20:54] <geser> spell-checker? :)
[20:54] <cjwatson> Evil things (so no)
[21:14] <mwhudson> doko__: hey, are you around?
[21:48] <Laney> cjwatson: a renamed source package?
[21:48] <Laney> I'm sure I can manage that
[21:50] <cjwatson> Yep, the usual ttf -> fonts dance.  Thanks


[09:26] <rodarvus> hi there
[09:26] <rodarvus> any hints on why this build failure happened? -> http://librarian.launchpad.net/3573913/buildlog_ubuntu-edgy-sparc.xorg-server_1%3A1.1.1-0ubuntu1_FAILEDTOBUILD.txt.gz
[09:27] <rodarvus> I attempted to connect to faure to reproduce this myself, but my account can't connect there (even though faure is listed as a porter machine)
[09:27] <rodarvus> this package builts successfully on i386 and amd64 at least (building on other platforms right now)
[09:31] <rodarvus> (just for reference) asm/kbio.h is not found. This file is included on sparc only
[09:31] <Keybuk> rodarvus: kernel-headers bug, I'd guess
[09:31] <rodarvus> Keybuk, yeah, my guess too
[09:33] <doko> $ dpkg -S kbio.h
[09:33] <doko> dpkg: *kbio.h* not found.
[09:33] <doko> looks so ...
[09:34] <jbailey> rodarvus: faure falls over dead on a regular basis, I think.
[09:34] <jbailey> rodarvus: Best to file an RT ticket to get it reset.
[09:34] <doko> rodarvus: time to join #ubuntu-kernel ;-P
[09:34] <rodarvus> :)
[09:34] <doko> jbailey: now it's up and running
[09:34] <jbailey> rodarvus: But it's entirely possible that some headers and such are still missing from the transition to the kernel taking over allof that.
[09:35] <rodarvus> ah, faure is back, indeed - thanks jbailey!
[09:35] <rodarvus> doko, I'll ask on #ubuntu-kernel, thanks for the help :)


[00:03] <wallyworld> thumper: you around?
[00:07] <bradm> anyone know much about neutron?  having issues with a juju deployed openstack
[00:14] <wallyworld> bradm, mgz knows most about neutron but he's probably asleep
[00:15] <bradm> wallyworld: I seem to be on the wrong side of the world to be dealing with neutron, everyone who seems to know it is asleep
[00:16] <wallyworld> yeah :-(
[00:25] <thumper> wallyworld: hi
[00:25] <wallyworld> gday
[00:25] <wallyworld> got time for a chat?
[00:26] <thumper> yup
[00:26] <thumper> ish
[00:27] <wallyworld> it will be quick, just a heads up from the standup last night
[00:28] <wallyworld> https://plus.google.com/hangouts/_/calendar/bWFyay5yYW1tLWNocmlzdGVuc2VuQGNhbm9uaWNhbC5jb20.sbtpoheo4q7i7atbvk9gtnb3cc?authuser=1
[01:12] <davecheney> 2014-02-26 01:11:42 ERROR juju runner.go:220 worker: exited "environ-provisioner": failed to process updated machines: error executing "lxc-ls": wait: no child processes
[01:12] <davecheney> 2014-02-26 01:11:43 ERROR juju.container.lxc lxc.go:166 failed getting all instances: error executing "lxc-ls": wait: no child processes
[01:12] <davecheney> ^ local provider peeps
[01:12] <davecheney> any ideas ?
[01:14] <axw> can't say I've seen that. busted packages again? :(
[01:17] <davecheney> is lxc-ls bailing before the wait occurs ?
[01:19] <axw> ah, I read it as an error coming back from lxc-ls
[01:19] <davecheney> ubuntu@winton-02:~$ lxc-ls
[01:19] <davecheney> ubuntu@winton-02:~$ echo $?
[01:19] <davecheney> 0
[01:19] <axw> not sure.
[01:19] <davecheney> weird
[01:19] <axw> try lxc-ls -1
[01:19] <axw> (one, not ell)
[01:20] <axw> and again as root
[01:20] <davecheney> ubuntu@winton-02:~$ sudo lxc-ls
[01:20] <davecheney> dave  foo   ken   ryu
[01:20] <davecheney> interesting
[01:20] <davecheney> ubuntu@winton-02:~$ ps auxww | grep jujud
[01:20] <davecheney> root     24736  3.0  7.5 8262756 621576 ?      Ssl  Feb22 174:19 /home/ubuntu/.juju/local/tools/machine-0/jujud machine --data-dir /home/ubuntu/.juju/local --machine-id 0 --debug
[01:20] <davecheney> but the machine agent is running as root
[01:21] <axw> does "sudo lxc-ls -1" do anything different?
[01:21] <axw> doubtful..
[01:23] <axw> davecheney: the golxc code is just doing exec.Command("lxc-ls", "-1").CombinedOutput()
[01:23] <axw> so... *shrug*
[01:23] <davecheney> ubuntu@winton-02:~$ sudo lxc-ls -1
[01:23] <davecheney> dave
[01:23] <davecheney> foo
[01:23] <davecheney> ken
[01:23] <davecheney> ryu
[01:23] <davecheney> same, but different
[01:23] <davecheney> screw it
[01:24] <axw> yeah -1 just means one per line, didn't think it'd matter
[01:24] <davecheney> gonna destroy and start again
[01:31] <thumper> waigani: ping - standup
[01:50] <davecheney> + /home/ubuntu/bin/juju destroy-environment -y local
[01:50] <davecheney> + /home/ubuntu/bin/juju bootstrap
[01:50] <davecheney> ERROR cannot use 37017 as state port, already in use
[01:50] <davecheney> sigh
[01:51] <davecheney> bloody hell
[01:51] <davecheney> what ?
[01:51] <davecheney> there is nothing listening on that port ....
[01:52] <davecheney> ERROR cannot use 37017 as state port, already in use
[01:52] <davecheney> ubuntu@winton-02:~$ ss | grep 37017
[01:52] <davecheney> ubuntu@winton-02:~$
[01:54] <mwhudson> davecheney: i don't think that's a good way to check
[01:54] <mwhudson> you want ss -nl i think?
[01:59] <davecheney> oh
[01:59] <davecheney> serves me right for using hipster tools
[01:59] <davecheney> i'll go back netstat -anp next time
[01:59] <davecheney> ubuntu@winton-02:~$ sudo !!
[01:59] <davecheney> sudo netstat -anp | grep 37
[01:59] <davecheney> tcp        0      0 <IP_ADDRESS>:37017           <IP_ADDRESS>:*               LISTEN      24711/mongod
[02:00] <davecheney> intersting
[02:00] <davecheney> i wonder why it didn't die
[02:29] <thumper> axw, wallyworld, waigani: we'll just use this one... https://plus.google.com/hangouts/_/calendar/dGltLnBlbmhleUBjYW5vbmljYWwuY29t.kieq2g96khnegtjsretb0l4clo
[02:31] <wallyworld> thumper: says not allowed to join
[02:31] <thumper> pfft
[02:31] <axw> same
[02:31]  * thumper sighs
[02:31] <thumper> this was the one from the package review
[02:32] <thumper> you are now invited
[03:03] <jam> thumper: poke, are you still online?
[03:03] <thumper> jam: yes, am with the team talking timings :)
[03:06] <jam> thumper: I'm available for video chat for a bit if you want
[03:20] <thumper> jam: available now
[03:31] <jam> thumper: starting up G+ hangout now
[03:31] <thumper> kk
[03:31] <jam> thumper: https://plus.google.com/hangouts/_/7ecpikfgr7oi6hsg74ds6jdcl0
[04:45] <bigjools> thumper: seriously lol-ing at your twitter conversation this morning
[06:23] <axw> oh wtf
[06:25]  * axw stops wtf'ing
[06:25] <axw> the bot marked the wrong MP as merged
[07:01] <jam> axw: where?
[07:02] <jam> I can't say that I've seen that before
[07:02] <jam> the bot doesn't actually do it
[07:02] <jam> Launchpad detects when the tip revision has been merged into trunk
[07:02] <jam> so it is generally accurate
[07:02] <axw> jam: https://code.launchpad.net/~axwalk/juju-core/lp1281071-rsyslog-tls/+merge/207889
[07:02] <axw> what I did was I created another branch, merged that one in but removed all the stuff I didn't care about
[07:03] <axw> so LP saw the merged revisions
[07:03] <jam> axw: the above branch is<EMAIL_ADDRESS>which is rev 2349.2.5 in trunk
[07:03] <jam> so that MP was *merged*, just from something else
[07:05] <axw> yeah, makes sense - I just haven't done that before and was a bit surprised
[07:05] <jam> be careful when clicking near tabs :)
[07:06] <axw> :)
 yeah, makes sense - I just haven't done that before and was a bit surprised
[07:06] <axw> jam: yes, the rev is there, I just took out most of what's in that MP
[09:25] <dimitern> fwereade, wrtp, i'd appreciate a review and some direction on https://codereview.appspot.com/66540044
[09:29] <wrtp> dimitern: looking
[09:51] <wrtp> dimitern: reviewed
[09:52] <dimitern> wrtp, ta!
[09:56] <mattyw> dimitern, your review here: https://codereview.appspot.com/67870043/ do you mean I need to implement the new status code in FullStatus only - and not in Status?
[09:58] <dimitern> mattyw, FullStatus only - Status uses FS internally, when needed (1.16 compat mode)
[09:59] <dimitern> fwereade, wrtp, so, it seems we'll need to define the next agent conf version - should it be 1.17 or 1.18? I'm thinking of adding Version, DataDir, LogDir, possibly Jobs as fields
[10:00] <rogpeppe> dimitern: i don't think it makes sense to define formats for dev versions
[10:00] <mattyw> dimitern, ok thanks
[10:00] <rogpeppe> dimitern: so i'd suggest 1.18
[10:02] <dimitern> rogpeppe, ok, and in that version we'll use a single file + version, no format separately
[10:02] <rogpeppe> dimitern: yeah
[10:02] <dimitern> rogpeppe, can you think of any other fields we might need to define except the ones above?
[10:03] <rogpeppe> dimitern: what is "Version" there? the agent configuration version?
[10:05] <dimitern> rogpeppe, ok Format then
[10:05] <rogpeppe> dimitern: what does it hold?
[10:07] <dimitern> rogpeppe, the agent conf format version
[10:10] <rogpeppe> dimitern: i'm not sure we want to expose that outside of the agent package
[10:10] <rogpeppe> dimitern: and i don't think it should be a regular field
[10:10] <rogpeppe> dimitern: i suggest that we store the version on a line of its own before any of the other conf data
[10:10] <dimitern> rogpeppe, expand?
[10:11] <rogpeppe> dimitern: then we can read the version and use it to decide how to parse the rest of the config data
[10:11] <rogpeppe> dimitern: which gives us freedom to change file formats in the future if we want (for example to move away from YAML)
[10:12]  * rogpeppe has just got his laptop back through the post
[10:12] <rogpeppe> and they've cleaned it all up - it doesn't look like my scruffy laptop any more :-)
[10:13] <rogpeppe> let's see if it works...
[10:13] <rogpeppe> ha, they replaced the keyboard!
[10:17] <jam> rogpeppe: I'm glad you got it back in time, congrats
[10:18] <dimitern> rogpeppe, \o/
[10:18] <dimitern> rogpeppe, ok, that sgtm
[10:20] <rogpeppe1> jam: yay! back on the thinkpad!
[10:46] <jam> rogpeppe: fwereade, dimitern: standup?
[10:50] <jam> fwereade: poke ?
[10:51] <fwereade> jam, sorry, couple of mins
[10:58] <jam> mgz: poke ?
[10:59] <mgz> jam: ta
[11:08] <jam> fwereade: one more quick standup ping?
[11:48] <rogpeppe> fwereade: https://codereview.appspot.com/68650044
[11:51] <jam> rogpeppe: https://bugs.launchpad.net/juju-core/+bug/1254577 is still marked Critical and not Fix Committed. I thought you landed code related to that?
[11:52] <rogpeppe> jam: marked as "fix committed"
[11:52] <jam> rogpeppe: do you know if that got released in 1.17.3
[11:52] <jam> ?
[11:53] <rogpeppe> jam: i certainly hope so. let me check.
[11:55] <rogpeppe> jam: well, the fix was merged 3 weeks ago, so i should certainly hope so
[11:57] <jam> does anyone have the link to the current CI runs? I seem to have an old IP address that is no longer valid
[11:57] <jam> sinzui: ^^
[12:13] <natefinch> jam: FYI I have an old IP too, not sure what happened.  Sinzui is likely still asleep, but when he responds, I'll email out the new IP.
[12:21] <fwereade> frankban, dimitern: does charm get handle symlinks at all?
[12:22] <dimitern> fwereade, because it uses a zip reader internally, i guess it should
[12:22] <fwereade> frankban, dimitern: it looks like it's just sending the target path and I'm not convinced that's useful
[12:23] <frankban> fwereade: I guess it depends on how they are handled by zip.ReadCloser
[12:24] <dimitern> frankban, fwereade, but a test with a zip + symlinks is definitely useful
[12:24] <fwereade> frankban, dimitern: ok, what do you think we should be doing? sending the actual content of the target?
[12:25] <frankban> fwereade: makes sense
[12:25] <dimitern> fwereade, frankban, that sounds reasonable
[12:25] <frankban> fwereade, dimitern: trying with a symlink
[12:25] <fwereade> dimitern, frankban: ok, cheers, I'll see what I can do
[12:28] <fwereade> dimitern, frankban: also, would it be *really* annoying if I changed the filelist stuff to return directories as well? I freely admit this is more rooted in convenience than any solid design principles
[12:29] <fwereade> dimitern, frankban: hmm, I think we may need special handling for the revision file too
[12:29] <frankban> fwereade: not annoying for me
[12:30] <fwereade> frankban, cool, basically I'd like to just return the result of the imminently-available Bundle.Manifest method
[12:30] <frankban> fwereade: re: revision file, is it special?
[12:31] <fwereade> frankban, its presence is not guaranteed in the zip file, but it is always returned by Manifest because we do always write one out
[12:31] <frankban> fwereade: oh, so you'll instantiate a bundle and it will have a Manifest returning the file list?
[12:31] <fwereade> frankban, it'll *almost* certainly always be there, but it's that "almost" that's the issue ;)
[12:31] <fwereade> frankban, yeah, I think so -- is a ReadBundle unreasonable at that point?
[12:32] <frankban> fwereade: OIC, if it's not there there is no problem from our perspective, AFAICT we are not interested in the revision file for that API. but I agree, if it's in the list, we must also return its contents
[12:34] <frankban> fwereade: in my previous impl (before requirements changes) I used ReadBundle to and ExpandTo to extract the files, so, it makes sense. I wonder if at that point a bundle.GetFile would be reasonable too.
[12:36]  * fwereade starts wondering about a Content(path) method
[12:37] <fwereade> frankban, yeah, I'm just having trouble integrating the symlink-resolution stuff in my current model
[12:41] <fwereade> frankban, how do we currently behave if you ask for a path to a dir?
[12:41] <fwereade> frankban, ah 403 cool
[12:41] <frankban> fwereade: forbidden
[12:41] <frankban> yeah
[12:41] <fwereade> frankban, ok, I think that works for me
[12:42] <fwereade> frankban, dimitern: can we do a really quick hangout?
[12:43] <frankban> fwereade: sure
[12:43] <dimitern> fwereade, frankban, sure
[12:43] <fwereade> dimitern, frankban: https://plus.google.com/hangouts/_/7ecpjumv8629dqrig0jdegier8?hl=en
[13:19] <rogpeppe> fwereade: you've got a review: https://codereview.appspot.com/69110043/
[13:21] <sinzui> jam, natefinch http://<IP_ADDRESS>:8080/ and it appears ill (and we stood it up 2 days ago too)
[13:21] <sinzui> oh, no route to host
[13:21] <jam> sinzui: k, so that I can't get to it is probably because it isn't there :)
[13:22] <natefinch> heh
[14:12] <rogpeppe> dimitern: i've responded to your review
[14:13] <rogpeppe> dimitern: i'd appreciate the rest, if you have some time
[14:14] <dimitern> rogpeppe, thanks, i'll look into it a bit later
[14:14] <rogpeppe> dimitern: ta
[14:14] <rogpeppe> natefinch, fwereade: your reviews appreciated too
[14:51] <niemeyer> rogpeppe: Hey, just a ping to let you know your branch got merged, and the tests that were failing due to the panic formatting changes in recent Go versions have also been fixed
[14:52] <rogpeppe> niemeyer: great, thanks. i was planning to get around to merging it, but my laptop died which was a distraction
[14:52] <rogpeppe> niemeyer: i'll update the juju-core deps file
[14:52] <niemeyer> rogpeppe: Thanks
[14:59] <dimitern> rogpeppe, what are these cryptic 0v 1p in member definitions
[14:59] <rogpeppe> dimitern: see the definition of mkMembers and mkStatuses
[15:00] <dimitern> rogpeppe, right, thanks
[15:00] <niemeyer> mramm, fwereade: Are we having that call today?
[15:01] <mramm> I'm in the hangout
[15:01] <mramm> if you want to have it
[15:01] <mramm> but I don't have any items for today's agenda
[15:02] <mramm> so I am also fine with skipping today
[15:03] <niemeyer> mramm: I'm joining
[15:21] <natefinch> rogpeppe: resuming the review now
[15:21] <rogpeppe> natefinch: thanks!
[15:33] <rogpeppe> lunch
[15:46] <sinzui> natefinch, rogpeppe , is someone adding support to install juju-mongodb when it is available?
[15:46] <rogpeppe> sinzui: i think that's the plan, but i don't know its current status
[15:47] <sinzui> rogpeppe, thank you
[15:50] <dimitern> rogpeppe, reviewed
[15:50] <rogpeppe> dimitern: ta!
[15:50] <natefinch> sinzui: it is planned but I don't think anyone is assigned. I did the other part, but someone else should probably do this part, since I am way behind on HA stuff.
[15:51] <sinzui> natefinch, fab. I think I will work to release juju 1.17.4 as it is for people working on trusty and other archs
[16:03] <dimitern> rogpeppe, fwereade, so with the introduction of agent conf format 1.18 we should drop 1.12 format support, right?
[16:03] <fwereade> rogpeppe, would you explain the windows 022 thing a bit more?
[16:03] <rogpeppe> fwereade: i think so
[16:03] <rogpeppe> dimitern: i think so
[16:03] <dimitern> ok :)
[16:03] <fwereade> dimitern, hmm, I have a nasty feeling that 1.12 might try to upgrade arbitrarily far
[16:04] <rogpeppe> fwereade: so, i'm not convinced that we'll get sane-looking perms from windows-generated zip files
[16:04] <dimitern> fwereade, so?
[16:04] <dimitern> fwereade, it will fail
[16:04] <rogpeppe> fwereade: from previous experience with unix-like perms on windows
[16:04] <rogpeppe> fwereade: natefinch may know more of the expected behaviour
[16:04] <fwereade> dimitern, so I'm not sure that we can guarantee that 1.18 won't start up with a 1.12 conf
[16:05] <fwereade> dimitern, it may just be a matter of shouting about it in the release notes though
[16:06] <fwereade> rogpeppe, natefinch: in particular I don't quite get what `&=022` would do, maybe because I'm not sure where you mean me to apply it
[16:06] <dimitern> fwereade, well, we can't guarantee compatibility 16 releases back anyway, so it should just fail in some sensible way
[16:07] <rogpeppe> fwereade: it would clear group and other write permissions from all files and directories
[16:08] <rogpeppe> fwereade: sorry, it should have been &^022
[16:09] <rogpeppe> fwereade: another possibility is to use ((p&7) | (p&7)<<3 | (p&7)<<6)) & ^022
[16:10] <rogpeppe> fwereade: i.e. ignore group and other modes, don't allow any group/user write perms, and use r and x bits from user perms for group and other
[16:10] <rogpeppe> fwereade: but that means it's not possible to make a non-group or other -readable file
[16:26] <natefinch> fwereade, rogpeppe:  catching up....   perms on windows are way different.  Not 100% sure on how Go translates permission bits to windows
[16:26] <rogpeppe> natefinch: yeah.
[16:26] <rogpeppe> natefinch: what do you think windows-created zip files will report for permissions?
[16:27] <rogpeppe> natefinch: perhaps you could create a zip file under windows, with a variety of permissions, and we could find out
[16:28] <natefinch> rogpeppe: yeah, that';s what I was thinking.  I don't know what linux defaults to when it sees a windows file that doesn't have permissions like that set.  I'll try it out, easy enough
[16:28] <rogpeppe> fwereade: one thought is that if we're unpacking the charm under unix, it's pretty unlikely that the charm was zipped under windows
[16:28] <rogpeppe> natefinch: i did some of the go zip perms code, ages ago, but i can't remember much about it and it's probably changed since i did it
[16:28] <rogpeppe> natefinch: i think the trauma of reading the zip spec must've blanked my memory :-]
[16:29] <natefinch> rogpeppe: hahah
[16:34] <fwereade> natefinch, rogpeppe: sorry, multitasking fail
[16:36] <natefinch> rogpeppe: by default it's 0664
[16:36] <rogpeppe> natefinch: which default?
[16:36] <natefinch> -rw-rw-r--  for those of us less binarily inclined
[16:36] <natefinch> rogpeppe: if I just create a zip without specifying permissions
[16:36] <rogpeppe> natefinch: is that Go's behaviour or windows' ?
[16:37] <natefinch> rogpeppe: windows, sorry
[16:37] <rogpeppe> natefinch: have you tried unpacking that using Go, to make sure
[16:37] <natefinch> rogpeppe: not yet, I'll do that
[16:38] <natefinch> rogpeppe: unpacking on linux, I presume?
[16:39] <rogpeppe> natefinch: it shouldn't make any difference
[16:39] <rogpeppe> natefinch: you don't actually need to create the file
[16:39] <fwereade> rogpeppe, natefinch: fwiw we *do* make sure that hooks are executable when we unpack *anyway* and I suspect this hits most of the cases -- 644/744 should be enough for anyone, right?
[16:39] <rogpeppe> natefinch: just see what perms are reported
[16:39] <fwereade> rogpeppe, natefinch: indeed assuming that *is* what's reported
[16:40] <rogpeppe> fwereade: i'd go for 755 rather than 744
[16:40] <rogpeppe> fwereade: but yeah, i don't think there's a huge issue here
[16:40] <rogpeppe> fwereade: it's worth going into it with our eyes open though
[16:40] <rogpeppe> fwereade: (i have definitely hit problems in this area in a previous lifetime)
[16:41] <fwereade> rogpeppe, natefinch: I'm not *really* expecting we'll get a lot of people writing charms on windows anyway tbh
[16:42] <fwereade> rogpeppe, natefinch: drag a charm archive into a browser on windows? plausible
[16:42] <fwereade> rogpeppe, natefinch: zip up a subtly wrong dir and drag it into a browser on linux? also plausible
[16:43] <fwereade> rogpeppe, natefinch: "develop" a charm sight unseen on windows, and deploy it to a real ubuntu cloud straight off? seems less likely
[16:43] <rogpeppe> fwereade: it's possible but i think that the resulting issues probably won't be *too* bad
[16:43] <rogpeppe> fwereade: exactly
[16:45] <rogpeppe> fwereade:  one other thing occurs to me: the perms you'll get when creating a file with os.OpenFile may well be different from the perms you get when doing a chmod
[16:45] <rogpeppe> fwereade: because of umask
[16:46] <rogpeppe> fwereade: to be consistent, perhaps we should AND all the perms with the current umask before doing anything
[16:48] <fwereade> &^umask, right?
[16:50] <natefinch> rogpeppe, fwereade: btw the unzipped files w/ go are created with 0664, too.
[16:51] <rogpeppe> fwereade: yeah
[16:51] <rogpeppe> natefinch: that's not a great default, but umask should sort it out
[16:54] <fwereade> natefinch, ok, that seems probably good enough to me?
[16:54] <fwereade> rogpeppe, added v brief notes on https://codereview.appspot.com/68650044/ -- I'll be looking at it some more
[16:55] <fwereade> rogpeppe, but it is explicitly *not* nlgtmed, so please do not take my need to convince myself further as a roadblock
[16:59] <rogpeppe> fwereade: i'd be interested to know what kind of thing you're thinking about when you suggest a "simpler and dumber model"
[17:02] <rogpeppe> fwereade: i agree that the current mocking setup is somewhat experimental, but i *think* it beats trying to get the real State to jump through all those hoops
[17:03] <fwereade> rogpeppe, yeah, definitely agreed
[17:06] <rogpeppe> fwereade: the IsNotFound cases are the only place in the code we don't have 100% coverage. that's mainly because i haven't yet thought of a decent way to "wait for nothing to happen"
[17:07] <rogpeppe> fwereade: i'd also be interested to know where you found it difficult to follow the code, so i can add an appropriate comment or two
[17:23] <fwereade> rogpeppe, I'll hopefully have some better comments later today
[17:24] <rogpeppe> fwereade: i've just approved the MP BTW, but i'll take on board any further comments and integrate them into the next branch
[17:24] <fwereade> rogpeppe, I do find myself wondering whether we actually kinda want to unpack charms with the permissions in the zip file, umask be damned
[17:24] <fwereade> rogpeppe, thanks
[17:24] <rogpeppe> fwereade: i'm not sure
[17:24] <rogpeppe> fwereade: an easy way to do that is to set umask to 0
[17:25] <rogpeppe> fwereade: umask is kinda dumb anyway
[17:25] <rogpeppe> fwereade: i preferred the plan 9 way of doing things, where the default perms were taken from the parent dir
[17:25] <fwereade> rogpeppe, heh, but then we do want to keep using the default umask for hook execution I think
[17:25]  * fwereade rather agrees tere
[17:26] <rogpeppe> fwereade: i don't know. what do you think the expectation of umask is for charm authors?
[17:27] <fwereade> rogpeppe, there were bugs about it in the past
[17:27] <fwereade> rogpeppe, iirc the expectation is "execute hooks with the system umask"
[17:28] <rogpeppe> fwereade: the other thing that i didn't remark on in the review, is what happens if you have a directory with non-writable permissions, but it contains some files?
[17:28] <rogpeppe> fwereade: i *think* that in general it's a moot point because zip files don't usually mention directories explicitly
[17:28] <rogpeppe> fwereade: but it can be an issue
[17:32] <fwereade> rogpeppe, yeah, my thinking was mainly that unwritable things are unlikely to come up in practice, and when they do we have ErrConflict
[17:32] <fwereade> rogpeppe, because I certainly don't know what the point of having such things would be
[17:32] <rogpeppe> fwereade: alternatively, make sure that all directories are at least 700
[17:33] <rogpeppe> fwereade: me neither, but it's difficult to pre-guess
[17:33] <fwereade> rogpeppe, and thus am unqualified to impose expectations
[17:35] <ev> hiya. Is ssh forwarding broken? http://paste.ubuntu.com/7000920/
[17:35] <ev> that's on 1.17.3-saucy-amd64
[17:37] <rogpeppe> ev: hmm, it would be interesting to find out what actual command line is being executed there
[17:37] <ev> rogpeppe: hm? Isn't that in the pastebin?
[17:37] <mgz> is that just bug 1281577
[17:37] <_mup_> Bug #1281577: juju 1.17.2 doesn't pass command line options to ssh <docs> <landscape> <regression> <ui> <juju-core:Fix Committed by dimitern> <https://launchpad.net/bugs/1281577>
[17:37] <ev> ah, that's the badger
[17:37] <ev> thanks guys
[17:37] <rogpeppe> ev: no, sorry, i mean the ssh comment
[17:38] <rogpeppe> mgz: thanks
[17:38] <mgz> ev: sinzui is doing 11.17.4 today which has the fix
[17:38] <mgz> -1
[17:41] <ev> whoop!
[17:42] <natefinch> rogpeppe, fwereade: btw, it looks like zip files don't actually include the directory information, just implicitly through paths on files (at least the ones I created on windows 7).
[17:43] <fwereade> natefinch, would you mail me one please?
[17:43] <rogpeppe> natefinch: that's what i meant by "zip files don't usually mention directories explicitly"
[17:43] <rogpeppe> natefinch: i think it's possible for them to do so though
[17:44] <rogpeppe> natefinch: i *think* it's possible to have empty dirs in a zip file
[17:45] <natefinch> rogpeppe: windows won't let you do it : [Window Title]
[17:45] <natefinch> Compressed (zipped) Folders
[17:45] <natefinch> [Content]
[17:45] <natefinch> Windows was unable to add one or more empty directories to the Compressed (zipped) Folder.
[17:45] <natefinch> [OK]
[17:45] <rogpeppe> natefinch: ha ha
[17:45] <rogpeppe> natefinch: no one likes those poor empty directories
[17:45] <natefinch> rogpeppe: I'd just been testing that
[17:45] <rogpeppe> natefinch: apart from bzr, which is being phased out
[17:45] <natefinch> rogpeppe: yeah, it's kinda sad, because they can have value.
[17:46] <rogpeppe> natefinch: they're really important sometimes
[17:46] <natefinch> rogpeppe: if for nothing else than "here's where you should put X stuff"
[17:47] <mgz> natefinch: certainly tools *exist* on windows that let you add empty dirs to zips...
[17:47] <mgz> whether they're what people use is another matter
[17:47] <natefinch> mgz: yeah, probably 7zip etc would allow it.  Certainly we should support it if it's possible.
[17:47] <mgz> 7zip does, just tested
[17:50] <natefinch> mgz: good to know.
[17:54] <natefinch> rogpeppe: we should probably talk HA next steps before your EOD, or jam will have my head for not putting up some tasks on kanban
[17:55] <rogpeppe> natefinch: i'm just working on that, but let's have a chat about it
[17:55] <rogpeppe> natefinch: in fact, give me 10 mins to finish my thoughts here
[17:55] <natefinch> rogpeppe: sure thing'
[18:06] <sinzui> mgz, ev : I hope to do a 1.17.4 release tomorrow. nova/canonistack lost the ci machine abotu 12 hours. We had to stand up another one as our first priority
[18:07] <mgz> sinzui: eck... we need a less overcommitted region probably :0
[18:08] <sinzui> mgz, It happened last week too. We will move to another region or cloud
[18:12] <ev> sinzui: *nods* I've just sent instructions to my team on using juju from trunk for this
[18:12] <rogpeppe> natefinch: https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig?authuser=1
[18:12] <ev> HP has hilariously set really low limits on not only security groups, but security group rules
[18:12] <ev> so wooo tunnels
[18:13] <ev> I don't suppose I could convince someone to update the simplestreams stuff to use the new US/West HP Cloud region?
[18:13] <ev> we've uploaded the right thing to a public bucket on one of our HPCloud accounts for now
[18:14] <sinzui> ev, Juju-CI just built UNRELASED debs for trusty, saucy, and precise. This is the release candidate we are testing: http://<IP_ADDRESS>:8080/job/publish-revision/
[18:14] <sinzui> if ev, this is the actual release tarball we will use on success: http://<IP_ADDRESS>:8080/job/build-revision/
[18:15] <ev> ( https://region-a.geo-1.objects.hpcloudsvc.com/v1/11289530460295/images and https://region-a.geo-1.objects.hpcloudsvc.com/v1/11289530460295/tools )
[18:15] <ev> sinzui: *nods* thanks!
[19:20]  * rogpeppe is done for the day
[19:20] <rogpeppe> g'night all
[19:21] <rogpeppe> fwereade: there are now some kanban cards for HA, BTW
[19:51] <thumper> o/
[21:59] <thumper> waigani: https://bugs.launchpad.net/juju-core/+bug/1281394
[21:59] <_mup_> Bug #1281394: uniter failed to run non-existant config-changed hook <regression> <juju-core:Triaged by thumper> <https://launchpad.net/bugs/1281394>
[22:10] <thumper> wallyworld: just for you: http://pastebin.ubuntu.com/7002116/
[22:10] <wallyworld> looking
[22:11] <wallyworld> is this trunk?
[22:11] <thumper> aye
[22:11] <thumper> pulled trunk, started a local provider
[22:11] <wallyworld> hmmm. worked for me before :-(
[22:11] <wallyworld> and CI
[22:12] <wallyworld> ok, i'll have to look
[22:12] <thumper> and also deployed ubuntu charm
[22:12] <thumper> that is all
[22:12] <thumper> well, it is up and running
[22:12] <thumper> but the worker is bouncing
[22:12] <wallyworld> sigh, yeah will look
[22:12] <wallyworld> but i'm in a good mood - got support for IDE based debugging :-)
[22:13] <wallyworld> niiiiiice
[22:13] <wallyworld> no more fmt.Printf() to see wtf is going on
[22:21] <thumper> haha
[22:21] <thumper> nice
[22:21] <waigani> Tim just shot me
[22:22] <thumper> nerf
[22:34] <wallyworld> thumper: what juju version were you upgrading local provider env from?
[22:34] <thumper> I wasn't upgrading
[22:34] <thumper> I was just starting it
[22:35] <wallyworld> hmmm. ok
[22:38] <wallyworld> thumper: since you're ocr :-) could you +1 this one roger looked at - i've responded to changes but he didn't get to +1 yesterday. there's also https://codereview.appspot.com/68990043/ :-D
[22:38] <thumper> i'm ocr?
[22:38] <wallyworld> it says so on the calendar :-)
[22:38]  * thumper sighs
[22:38] <thumper> suppose I am then...
[22:38] <thumper> yes, I'll look soonish
[22:39] <wallyworld> yep :-)
[22:39] <wallyworld> no hurry
[22:39] <wallyworld> i have 4 branches stacked up i need to land
[22:39] <wallyworld> so just keen to clear the queue sometime today or whenever
[22:40] <thumper> yeah yeah
[22:41]  * thumper puts wallyworld on the TODO soonish stack
[22:45] <wallyworld> no hurry


[12:54] <ajmitch> Burgwork: filed any bugs yet?
[12:54] <Burgwork> ajmitch: on authtool, no
[12:54] <Burgwork> busy working ont he DS5 rlease notes
[12:57] <Burgwork> ajmitch: the first issue I see is that it doesn't dep on krb, pam or nss stuff, which it should
[12:58] <ajmitch> why should it?
[12:58] <ajmitch> it installs packages as needed
[12:58] <Burgwork> it fails to run for me
[12:58] <Burgwork> if I run it, it dies on needing krb5
[12:58] <ajmitch> explain
[12:59] <ajmitch> error message?
[12:59] <Burgwork> last line is debconf.DebconfError: (10, "krb5-config...
[12:59] <ajmitch> ok, so it's debconf stuff
[01:00] <Burgwork> that known?
[01:00] <ajmitch> yep
[01:00] <ajmitch> known & should be fixed locally
[01:00] <ajmitch> hence the need to upload :)
[01:00] <Burgwork> ah, good
[01:01] <Burgwork> are we pushing to get the ldap stuff installed by default, along with authtool?
[01:03] <ajmitch> a bit late for feisty, I think
[01:03] <ajmitch> way past feature freeze
[01:04] <ajmitch> ogra put in main inclusion reports for lib{nss,pam}-ldap, but they were deferred
[01:05] <ajmitch> I won't be at UDS in seville, and not likely to make it to boston either
[01:31] <ajmitch> Burgwork: getting too busy for moderation?
[01:33] <Burgwork> yep, for feisty+1
[01:33] <Burgwork> moderation is a boring task
[01:34] <Burgwork> I hope to make it to Seville and Edinburugh
[01:36] <ajmitch> edinburgh? what's announced for there?
[01:36] <Burgwork> guadec
[01:36] <ajmitch> ah right
[01:37] <ajmitch> never been to guadec yet
[01:38] <ajmitch> I doubt I'll really get to any more UDS events
[01:39] <Burgwork> ah
[01:39] <Burgwork> too bad
[01:41] <ajmitch> unless I found a very generous employer
[01:45] <Burgwork> Impi is hiring
[01:45] <ajmitch> that's .za
[01:45] <Burgwork> so?
[01:45] <Burgwork> you can only die once :)
[01:45] <ajmitch> heh
[01:45] <ajmitch> I don't really feel like moving there, and I don't think they're really hiring remote employees
[01:47] <ajmitch> I'm hoping to apply to a company in wellington
[01:47] <Burgwork> I am tired of using crap products
[01:48] <Burgwork> I want to work with LTSP and good stuff
[01:48] <ajmitch> one of the top guys there being in the nz loco irc channel quite often
[01:49] <Burgwork> what do they do?
[01:50] <ajmitch> various open source work, as well as plenty of web apps
[01:50] <ajmitch> it consulting, using debian & ubuntu
[01:50] <Burgwork> cool
[01:51] <Burgwork> have you played with zabbix at all?
[01:52] <ajmitch> nope
[01:54] <Burgwork> how about nagios?
[01:54] <ajmitch> yeah I use nagios
[01:55] <Burgwork> how much of a headache is to install?
[01:55] <ajmitch> moderately annoying, mostly just configuring the host templates & listing out all the hosts & services
[01:55] <ajmitch> it's not hard, just a bit tedious
[01:56] <Burgwork> right
[01:56] <Burgwork> and how good is the information you get out of it?
[01:57] <ajmitch> fairly useful, in getting a good overview of the status of everything
[01:57] <ajmitch> I can't remember what it has for history, etc
[01:58] <Burgwork> either in Ubuntu main?
[01:58] <ajmitch> nope
[01:58] <ajmitch> both universe
[01:58] <Burgwork> hmm, nagios used to be in main
[01:59] <Burgwork> I wonder if Canonical used to use it for monitoring
[02:00] <Burgwork> if a router/switch talks snmp, does that mean I can monitor it via nagios/zabbix?
[02:01] <ajmitch> yes
[02:01] <ajmitch> and you could get the traffic graphs into something like cacti
[02:02] <Burgwork> ok, rock
[02:02] <ajmitch> I've been meaning to set it up again at work, we just use cacti for watching load, etc at the moment
[02:02] <Burgwork> how does catci fit into the picture?
[02:02] <ajmitch> you know of mrtg?
[02:02] <Burgwork> no
[02:02] <ajmitch> traffic graphing
[02:03] <ajmitch> cacti does that & some more, like load, mem usage, basically anything else you can specify
[02:03] <Burgwork> ah, so I need to pair cacti with something like nagios
[02:03] <Burgwork> as one monitors and the other shows the information?
[02:03] <ajmitch> gives you a good overview of patterns over time
[02:03] <ajmitch> yeah
[02:03] <Burgwork> right
[02:04] <ajmitch> eg we had a nice regular pattern, and some code changes in the web app for work showed a good drop in system load
[02:04] <Burgwork> it appears zabbix is an all-singing, all-dancing solution
[02:04] <ajmitch> might be worth checking out then
[02:04] <Burgwork> probably
[02:04] <Burgwork> build myself a nice network monitoring tool
[02:05] <ajmitch> so work hasn't driven you mad yet?
[02:05] <Burgwork> sort of
[02:05] <Burgwork> I have shiny new toys to play with, like a brand new Linksys SRW224P
[02:05] <ajmitch> useful
[02:06] <Burgwork> a PoE and QoS switch
[02:06] <ajmitch> the only shiny toy I have is a new server running etch
[02:06] <ajmitch> setting up ldap stuff on it now
[02:06] <Burgwork> cool
[02:06] <ajmitch> basically copying all the data from our crm database for clients into ldap, so they can use it as an address book
[02:06] <Burgwork> however, I was told I need to migrate the whole infrastructure away from Ubuntu
[02:06] <ajmitch> uh
[02:06] <ajmitch> why?
[02:07] <Burgwork> because we ain't an Ubuntu company
[02:07] <ajmitch> oh I see
[02:07] <Burgwork> we are planning to use DS on our desktops
[02:07] <ajmitch> that's a rather stupid justiffication
[02:07] <Burgwork> which should be tonnes of fun
[02:07] <ajmitch> DS?
[02:07] <Burgwork> DisocverSTation
[02:07] <Burgwork> our primary product
[02:07] <ajmitch> ok..
[02:07] <ajmitch> based on fedora?
[02:07] <Burgwork> it has a nice flash login screen that eats 10m an hour until killed
[02:07] <Burgwork> yes, fedora
[02:07] <Burgwork> but then we need a server distro
[02:08] <ajmitch> that must be a bit painfil
[02:08] <Burgwork> at which point I said: no fedora
[02:08] <ajmitch> s/fil/ful/
[02:08] <Burgwork> I don't want to migrate 15 servers every bloody six months
[02:08] <ajmitch> standardising on debian
[02:08] <Burgwork> to what?
[02:08] <Burgwork> we are probably going debian
[02:08] <Burgwork> as the other office "doesn't think Ubuntu is a server distro"
[02:09] <ajmitch> it depends if you want anything from universe
[02:09] <ajmitch> I still like debian a lot
[02:09] <Burgwork> true
[02:10] <ajmitch> even sarge feels modern compared to this centos pile of crap
[02:10] <Burgwork> zabbix is the only thing I can see requiring from universe
[02:10] <Burgwork> given the rest is either totally custom or pretty standard
[02:11] <ajmitch> hopefully debian can pick up its release cycle a bit in the future
[02:11] <ajmitch> like every 18 months or 2 years
[02:12] <Burgwork> they need to throw out some people and throw out some packages for that to work, I suspect
[02:13] <Burgwork> anyway, I have to run and go to class
[02:13] <ajmitch> alright
[02:13] <ajmitch> see you later