[03:03] <sladen> asdf
[03:05] <Fujitsu> ghjkl;
[03:51] <bddebian> Howdy
[04:02] <bddebian> Any idea why gdl wasn't merged/synced?
[06:20] <irvin> hello! is there a command line equivalent of Synaptic's `generate download script` ?
[01:20] <sivang> re all
[01:21] <ajmitch> hi sivang
[01:21] <sivang> hey ajmitch
[01:21] <sivang> hey lfittl :)
[01:22] <lfittl> hi sivang :)
[01:23] <jsgotangco> hi
[01:26] <Hobbsee> hi all
[01:28] <sivang> lfittl: not YET :-)
[01:28] <lfittl> sivang: right :D
[01:34] <sivang> hey Hobbsee
[01:35] <Hobbsee> hi sivang
[03:06] <slomo> doko_: what happened to python-gdbm?
[03:21] <slomo> doko_: oh nevermind... it's just python-stdlib-extensions that is missing in ubuntu, probably in NEW ;)
[03:39] <bddebian> Hello
[04:22] <Whoopie> Hi, who could acknowledge crimsun's upload to dapper-updates for bug 38272? Thanks a lot!
[04:22] <Ubugtu> Malone bug 38272 in xserver-xorg-input-mouse "option EmulateWheelTimeout not working" [Medium,Fix released]  http://launchpad.net/bugs/38272
[04:42] <sivang> slomo: I also noticed these packages were missing dependencies :)
[05:31] <asac> iwj: ping ... I need a patch :)
[06:06] <shadeofgrey> hi guys..  i have a non supportr related question...
[06:07] <shadeofgrey> has anybody addressed the fact that theres a new version of openoffice that updates the entire thing from ver 2.0.2 to 2.0.3? i ask because the update is huge -- it addresses a lot oif critical problems and needs to be added to the update system ASAP.  whos the best person to talk to about an official request?
[06:15] <BenC> shadeofgrey: Saying the update "is huge" is a sure way of keeping out of updates :)
[06:17] <shadeofgrey> BenC:  whats the most effective means of getting the new version installed?
[06:18] <fabbione> shadeofgrey: in edgy it will probably be a natural update
[06:18] <BenC> in dapper, it probably wont happen
[06:18] <fabbione> in dapper, it needs a lot of work.
[06:18] <fabbione> as BenC says
[06:19] <shadeofgrey> BenC:  the rewason its so important to me is because im physically handicapped and the new versionm adds some really key accessibility options notr available in any of the older versions and finally allows for external use of other accessibility applications that would increase my overall productivity
[06:19] <bddebian> Doesn't ltmain.sh determine the libtool libraries?
[06:19] <shadeofgrey> see this is something i dont understand. why do i have to wait for an entirely new version of ubuntu before upgrades of key applications are made possible?
[06:19] <fabbione> shadeofgrey: the correct procedure is to file a bug in LP.
[06:20] <gnomefreak> build it ;)
[06:20] <BenC> shadeofgrey: because if we didn't have such restrictions there would never be a "released" ubuntu
[06:20] <fabbione> shadeofgrey: because a stable release is not developed anylonger.
[06:20] <shadeofgrey> certainly it cant be that hard to build debs that update the version by a single revision numberr
[06:20] <fabbione> shadeofgrey: otherwise it wouldn't be stable
[06:20] <fabbione> shadeofgrey: it involves much more work than you think
[06:21] <fabbione> shadeofgrey: anyway do as i said and file a bug asking for backport
[06:21] <gnomefreak> shadeofgrey: i think the biggest thing is aadding something unstable to a stable release
[06:21] <fabbione> shadeofgrey: otherwise absolutely nothing will happen
[06:21] <BenC> shadeofgrey: the version number isn't an issue, it's the amount of testing that needs to be done to make sure we don't break things for everybody
[06:22] <shadeofgrey> aleight then how about this...  what if i volunteered to be a dedicated tester of the new release by offering my machine up for the necessary tresting.  when i find bugs then i report them to you guys...
[06:23] <shadeofgrey> id actually really like to do that if its possible.  it'd be a great way for me to give back to the ubuntu community as a whole
[06:23] <shadeofgrey> is there siomeone here that would be able to talk me through how to manually do the update ifd i download the appropriate archives and decompress them?
[06:24] <gnomefreak> shadeofgrey: i would say id build it but i cant build it against dapper
[06:24] <fabbione> shadeofgrey: the point is you will never be able to cover all test cases that a large userbse does. In any case the problem remain. IF you need a new version (independently from the reason) you need to start filing a bug in LP
[06:24] <shadeofgrey> what is LP by the way?
[06:24] <gnomefreak> launchpad
[06:24] <gnomefreak> launchpad.net
[06:24] <shadeofgrey> okay..  how does one file a bug through launchpad?
[06:25] <fabbione> shadeofgrey: open LP and follow the links
[06:25] <gnomefreak> shadeofgrey: in systemtools ther eis a bug report tool
[06:25] <mdke> https://help.ubuntu.com/community/ReportingBugs
[06:25] <mdke> that should have everything
[06:26] <shadeofgrey> okay and by the way...
[06:27] <shadeofgrey> i wasnt kidding when i said that im willing to be a guinea pig for new versions of the applications i use most.
[06:27] <shadeofgrey> and im very anal retentive and meticulolus with documenting problems...
[06:27] <fabbione> shadeofgrey: we do understand and appreciate. The problem doesn't change. You just can't cover all test cases.
[06:27] <gnomefreak> shadeofgrey: easiest way to do that is in a few weeks test edgy ;)
[06:27] <fabbione> shadeofgrey: including testing the suite on all supported architectures
[06:27] <shadeofgrey> okay that was  ging to be my next questiuon
[06:28] <shadeofgrey> i have a 3rd harddisk that i was using to test dapper
[06:29] <shadeofgrey> and when my primary drive with winxp on it got majorlyt fubared by a trojan i threw the newest version of dapper into my CD drive and created a new installation on my primary disk - wiping out windows...  how do i completely dump the test version of dapper i have on that thirdf disk and replace it with edgy?
[06:29] <shadeofgrey> because wheni installed dapper on my porimary disk grub failed to create a listing for the other installation of the tesst releSE of dapper onm my third disk
[06:29] <gnomefreak> shadeofgrey: upgrade it by changign the sources.list to point to edgy and upgrade
[06:30] <shadeofgrey> but  i cant boot into the version of dapper onm my third disk becausde grub didnt create a link to it in the bootloader i put into the mbr of my primary disk
[06:30] <shadeofgrey> can i just download an iso of edgy and install it via CD?
[06:30] <gnomefreak> not yet
[06:31] <gnomefreak> unless ben is hiding them ;)
[06:31] <shadeofgrey> okay then  i guess ill wait until the first ISO comes out
[06:32] <shadeofgrey> well then heres my next question..  when i go to install edgy how do i keep it from creating another version of grub in the mbr of the third diskj where i intend to install the test release of edgy when its available?
[06:32] <gnomefreak> thats better asked in #ubuntu
[06:32] <gnomefreak> or ubuntu+1
[06:32] <shadeofgrey> okay well
[06:33] <shadeofgrey> i guess the answer doesnt matter until theres sdomething to install... though i suppose i could just install dapper AGAIN on the third disk and then just ereplace the sources.list file with edgy sources
[06:33] <shadeofgrey> thats probably the easiest way huh
[06:33] <shadeofgrey> ...yeah
[06:34] <shadeofgrey> okayt thanks for your time guys
[06:34] <shadeofgrey> ill get the hell out of youre way now
[07:28] <Gman> anyone know how i can easily debug a sound problem on dapper?
[07:30] <sivang> Gman: https://help.ubuntu.com/community/DebuggingSoundProblems
[07:30] <Gman> thanks
[07:30] <sivang> Gman: hope this helps :)
[07:31] <Gman> i'm sure it will
[07:31] <Gman> just need a rough idea of where i need to go
[07:31] <sivang> cool
[07:33] <Gman> sivang, sweet, works now, thanks heaps
[07:33] <Rinchen> Greetings Devs:  New spec in the wild: Enable CFQ by Default.  Details here:  https://launchpad.net/distros/ubuntu/+spec/cfq-by-default
[07:33] <Gman> was the master surround that needed to be unmuted
[07:38] <licio> I have one question, ubuntu resize ntfs partition?
[07:38] <mjg59> Yes
[07:38] <licio> right
[07:38] <sivang> Gman: cool!
[07:39] <licio> mjg59, desktop-cd?
[07:39] <licio> or alternate?
[07:39] <licio> both?
[07:39] <licio> :)
[07:40] <robitaille> both should do it  (but I have only done it with the alternate)
[07:41] <mjg59> Both
[07:41] <sivang> licio: I have done it over a T43p with the desktop-cd
[07:42] <sivang> licio: worked nicely, only stopping the Access IBM stuff from working, and for this as well there is a bug report and a workaround somewhere
[07:43] <sivang> anyway, going off for some time
[07:43] <sivang> latersall
[07:43] <sivang> laters all, eve
[07:44] <sivang> even
[07:44] <sivang> err
[07:44] <sivang> :-)
[07:44] <licio> sivang, yes.. :)
[07:45] <licio> I'm write one article for linux-magazine brazil
[07:45] <licio> :)
[07:46] <hunger> licio: nick.
[07:47] <hunger> s/nick/nice/.
[07:48] <sivang> licio: oh cool!
[07:49] <sivang> licio: You can always mentione there were a bunch of nice people on #ubuntu-devel willing to help you on your questions :)
[07:49] <sivang> anyway, I'm really off now.
[07:49] <hunger> sivang: Now that is nice: "people will help you... aehm... I got to run";-)
[07:50] <sivang> hunger: hehe, sorry
[07:50] <sivang> hunger: workrave is already shouting at me for having too much machine time :)
[07:51] <licio> sivang, right.. but I had just one question.. I don't have partitions ntfs... :)
[07:51] <licio> sivang, hugs
[07:52] <licio> and thanks ;)
[08:18] <Chipzz> hrrrm I know this is probably more of a #ubuntu kind of question, but can I install ubuntu-server with the ubuntu-desktop install (not live) cd too?
[08:25] <neuralis> Chipzz: yes.
[08:52] <Chipzz> neuralis: thx
[11:32] <tseng> pitti: can you please re-review MainInclusionReportXsp?
[11:33] <tseng> pitti: ReportXSP that is


[18:49] <greppy> just an observation, http://www.ubuntu-wisconsin.org/ appears to be broken.
[19:24] <mikeputnam> h00k: ^^^
[20:50] <douglasawh_> h00k: are you still having trouble getting natty to upgrade to the alpha?


[01:37] <rogpeppe1> davecheney: ping
[01:37] <davecheney> hey
[01:37] <davecheney> sorry, is it too late ?
[01:49] <rogpeppe1> davecheney: no, it's good
[06:23] <jam> hi rogpeppe2
[06:27] <jam> wallyworld: poke
[06:48] <wallyworld> jam: hi
[06:48] <jam> wallyworld: looks like you accidentally broke a test when your generate-config patch landed
[06:48] <wallyworld> oh :-(
[06:48] <jam> cmd/juju/main_test.go
[06:48] <jam> tests what commands are listed by 'juju help'
[06:48] <jam> and you added one.
[06:49] <wallyworld> ah bugger. ok, i'll fix it
[06:49] <jam> Pretty easy to fix, but you'll want to make sure you run "go test ./..." when landing to juju-core. (No bot to help us there)
[06:49] <wallyworld> i tried to but it hung
[06:49] <wallyworld> so i ran stuff by hand
[06:49] <jam> wallyworld: because of the mongo stuff?
[06:49] <wallyworld> yeah
[06:49] <jam> wallyworld: https://code.launchpad.net/~jameinel/juju-core/main-test/+merge/147023
[06:49] <jam> (I still can't get lbox to work without giving unsupported protocol)
[06:50] <jam> wallyworld: do you have bigjools's ppa ?
[06:50] <wallyworld> no
[06:50] <jam> (I personally just put the mongo files into $GOPATH/bin, but the ppa is a good idea too)
[06:51] <jam> technically, it doesn't hang forever, it just takes 5min to timeout and FAIL :)
[06:51] <wallyworld> ok, i'll have to get all that working i think
[06:51] <jam> but that is for each test package that uses mongo, which is about 5-6, so it takes a pretty long time to run the whole suite.
[06:58] <jam> wallyworld: anyway, it is clear that dimitern didn't run the full test suite after merging either, since he landed code after you did. But it is something we need to remember as long as we are manual gatekeepers.
[06:58] <wallyworld> yeah
[06:58] <jam> (lbox submit *doesn't* run the test suite as near as I can see, which might be a reasonable way around it?)
[06:59] <wallyworld> if they didn't hang i would have
[06:59] <jam> wallyworld: install newer mongo :)
[06:59] <jam> then it won't hang
[06:59] <wallyworld> i'll have to get mongo sorted
[07:01] <jam> wallyworld: on the list bigjools mentioned how to disable it (echoing the right disable into a file in /etc), but it isn't something I know offhand.
[07:01] <jam> I'm personally happier not installing mongo and just having the binary in my $PATH
[07:02] <wallyworld> i'll search for it
[07:02] <jam> but I can appreciate the chain-of-authentication stuff
[07:02] <bigjools> echo ENABLE_MONGODB=no | sudo tee -a /etc/default/mongodb
[07:02] <wallyworld> thanks
[07:03] <bigjools> part payment for the cricket tickets to Australia C on Weds
[07:08] <jam> wallyworld: "Mongo packaging" is the thread on juju-dev if you need any of his other bits of wisdom.
[07:09] <wallyworld> ok, thanks
[07:09] <bigjools> how are you managing package versions?
[07:09] <jam> bigjools: how do we package juju-core? dave cheney :)
[07:10] <jam> He mentioned he just set up a daily build of juju-core
[07:10] <jam> I don't know much more than that for his final releases.
[07:10] <bigjools> well, I was thinking of go get
[07:10] <jam> bigjools: have you seen mythreads on it? Poorly
[07:10] <bigjools> I read them but that was before I starting understanding Go :)
[07:10] <bigjools> I got the impression it was bad
[07:11] <jam> bigjools: essentially "trunk always passes because we manage the race condition of updating the dependency and the master project at the same time"
[07:11] <jam> but old versions of trunk aren't guaranteed to pass (are expected not to build because we can't trivially rollback the version of the deps)
[07:11] <jam> once we are stable, we will probably go with a version number in the import string
[07:12] <jam> with the cost that if we have to bump stability, the branch we land on will change location.
[07:12] <bigjools> yeah, I was thinking about how to handle rollbacks etc
[07:12] <bigjools> I guess it will come when the language matures
[07:12] <jam> bigjools: essentially, we cannot do it easily, the tools don't support it, the powers that be don't want to write new tools.
[07:13] <jam> though I might be jaded in my interpretation of the situation.
[07:13] <jam> https://docs.google.com/a/canonical.com/document/d/1HaVHWyERiPOJgcIQ2W2jc9I7MZQ5OAVNB7m0nMr0oPw/edit#heading=h.dez8xb2t49nj was my attempt at trying to document it all
[07:13] <jam> I petered out a bit rather than just living with the status quo
[07:13] <bigjools> that's a recipe to have other tools reinvent the wheel and do it
[07:13] <bigjools> yeah I can understand
[07:14] <jam> bigjools: "Handling Active Dependencies in Go" is the rather large thread about it. https://groups.google.com/d/topic/golang-nuts/0avuiWURSQk/discussion is the only link I could find on golang-nuts
[07:14] <bigjools> thanks
[07:14] <jam> which is still "we could put the version in the import string"
[07:14] <jam> which breaks lots of other bits
[07:15] <jam> bigjools: specifically, the big problem with the import string, is that the *library* needs to also use the same import string
[07:15] <jam> otherwise they are 2 different packages
[07:15] <bigjools> yeah
[07:15] <jam> so when you do a release, you now have a different URL, and different library source code.
[07:15] <jam> and different place in your local dir
[07:15] <jam> so all your tools need to move over there, etc.
[07:15] <jam> so doing it for *every* bump of a lib that lands in juju-core
[07:15] <bigjools> this is the price for putting it in the import
[07:15] <jam> is too painful for devs
[07:16] <jam> bigjools: right, and there isn't an abstraction point in go
[07:16] <jam> They conflated them with probably some good intent (try not to repeat yourself)
[07:16] <jam> but then end up mixing essentially runtime information with build time information.
[07:16] <bigjools> yes
[07:17] <bigjools> but it's great if you want to work on trunk :)
[07:17] <jam> One proposal I mentioned was a tool that does the build-time information, and configures GOPATH (which is close to how LP does it with eggs and site.py)
[07:17] <bigjools> right
[07:17] <jam> bigjools: except for landing change to goose's trunk breaks juju-core from building.
[07:17] <jam> unless you land patches "simultaneously"
[07:17] <jam> we need to add 2-phase-commit to bzr :)
[07:18] <bigjools> incompatible goose changes or some other reason?
[07:18] <jam> bigjools: change anything that isn't directly source compatible.
[07:18] <jam> 'go get' always grabs the latest tip of both branches.
[07:18] <jam> so, rename a public variable, etc.
[07:18] <bigjools> right - I was wondering if it was some language internal to do with compiling it
[07:19] <jam> which truly isn't "stable"
[07:19] <jam> but is very much in the "we don't know what the ideal API is yet, so let us not have cruft *before* we hit 1.0"
[07:19] <bigjools> do we know how Google manages this problem?
[07:20] <jam> bigjools: the thread above mentions 'goven' which is the CVS "vendor" model.
[07:20] <jam> Track an upstream branch in your own repository
[07:20] <jam> and use a tool to rename all of your "import launchpad.net/goose" code to be "import launchpad.net/juju-core/launchpad.net/goose"
[07:20] <bigjools> I guess repository revnos become super important
[07:21] <jam> bigjools: not quite sure I follow
[07:21] <jam> Essentially you just put all possibly-unstable dependencies into your source tree.
[07:21] <bigjools> if the packages don't have inherent versioning, you need to rely on repo versions to know what you have
[07:21] <jam> with some tool helpers to make it a bit easier to update them to newer versions when you choose.
[07:21] <bigjools> or am I missing something?
[07:22] <jam> bigjools: go get doesn't have repo versions, it has repo locations.
[07:22] <jam> So while *I* would have a tool more like launchpad's sourcedeps which lets you say "use launchpad.net/foobar@1234"
[07:22] <bigjools> yes, but can you not fix the revno?
[07:22] <jam> bigjools: you cannot put the revno into go get
[07:22] <bigjools> yes, I mean pulling manually
[07:23] <jam> bigjools: you can do your branches manually and not use 'go get -u'
[07:23] <bigjools> or does it always refresh the branches?
[07:23] <jam> bigjools: -u always refreshes the branches, but you could do all the work yourself
[07:23] <bigjools> ok
[07:23] <jam> with the major caveat that nobody else would do that until everything broke
[07:23] <bigjools> this is messy :(
[07:23] <jam> so you certainly can make your local development "work"
[07:23] <jam> if I grab your code, it will break until I find your magic sauce.
[07:23] <jam> which was the objection to writing a tool that did it
[07:24] <jam> because then you need this new tool.
[07:24] <jam> So version numbers in the import paths is sort of the way to go, except we aren't stable enough to pay the cost of creating a new branch for every change we want to land in juju-core.
[07:24] <bigjools> right
[07:25] <wallyworld> but even with version numbers in imports, you still pull from tip :-(
[07:25] <bigjools> ok, EOD here. Bye all.
[07:26] <jam> wallyworld: which is why you have to only use 1 branch per version you want to land
[07:26] <jam> essentially, make a full release for anything you want to pull into juju-core
[07:26] <wallyworld> which sucks :-(
[07:26] <jam> Which is heavyweight but feasible once we are stable.
[07:26] <wallyworld> but anyway, we've had that discussion
[07:27]  * wallyworld late for soccer, back later
[07:27] <jam> wallyworld: good luck!
[09:38] <TheMue> fwereade_: Hiya and thx for the review. Regarding the non-existing path my solution creates nothing, so maybe less cost. But your is more elegant so that I'll take it.
[09:39] <fwereade_> note also that your solution doesn't address the possibility that a file might be created after you check but before you run the test
[09:39] <fwereade_> TheMue, thanks :)
[09:43] <TheMue> fwereade_: Yeah, the little rest risk would exist, you're right. Even if the chance would be very low. ;)
[09:43] <fwereade_> TheMue, million-to-one chances come up most days ;)
[09:44] <TheMue> fwereade_: If one is running the tests each day and every minute, yes. :D
[09:44] <fwereade_> TheMue, forgive my professional paranoia ;)
[09:46] <TheMue> fwereade_: I appreciate it.
[09:47] <TheMue> fwereade_: So I will now take your feedback and submit afterwards, so that we don't have those two parallel branches.
[09:48] <fwereade_> TheMue, great -- tyvm, and thank you for bearing with me on these
[09:51] <TheMue> fwereade_: I've got to thank you, great results need good reviews.
[09:51]  * fwereade_ blushes
[09:51] <TheMue> :D
[10:04] <fwereade_> TheMue, rogpeppe2, jam, mgz: is juju-core also failing to build for you? I think I have the latest goose; it's complaining about identity.AuthMode and fip.InstanceId
[10:12] <jam> fwereade_: the failure wasn't related to that. I'm pretty sure you need to cd ../goose; bzr pull --remember lp:goose
[10:12] <jam> We moved where trunk was, so refreshing it should get you the latest goose.
[10:12] <jam> "lp:goose" didn't change
[10:12] <jam> but the exact branch it mapped to did, and "go get" expands the branch (I think)
[10:13] <fwereade_> jam, thanks, that seems to have sorted it; I did try a go get -u, (and also tried a bzr update) then came complaining here
[11:09] <wallyworld> jam: what problem were you having with reitveld - for some reason it all of a sudden won't authorise me anymore when I use lbox. is this what you saw?
[11:09] <dimitern> wallyworld: the authorization expires after 30 days I think - it happened to me before
[11:09] <wallyworld> i typed in my password and user id
[11:10] <dimitern> wallyworld: just sign in in rietveld again and authorize your google account to use it
[11:10] <dimitern> wallyworld: and then use lbox again
[11:10] <wallyworld> i signed in via the command line but didn;'t authorise google
[11:10] <wallyworld> i'll try that thanks
[11:34] <dimitern> jam, mgz: standup?
[11:35] <mgz> ne\rly there...
[11:45] <TheMue> lunchtime
[12:38] <rogpeppe2> fwereade_: does this error just imply that the charm isn't in the charm store?
[12:38] <rogpeppe2> 2013/02/07 12:37:35 JUJU juju deploy command failed: cannot get latest charm revision: charm info errors for "cs:precise/logall-subordinate": entry not found
[12:44] <rogpeppe> fwereade_: hmm, scratch that, i'm not using the right url.
[12:45] <rogpeppe> fwereade_: it's interesting, the charm store doesn't print urls that are acceptable to go juju
[12:45] <rogpeppe> go juju rejects this as invalid:  ~ju-jistics-hackers:precise/logall-subordinate
[12:45] <rogpeppe> it also rejects  cs:~ju-jistics-hackers:precise/logall-subordinate
[12:51] <niemeyer> Hello world!
[12:51] <rogpeppe> niemeyer: yo!
[12:52] <rogpeppe> niemeyer: i just discovered that the charm URLs printed by the charm store aren't valid for use with go juju. is that a problem on our side or theirs?
[13:08] <niemeyer> rogpeppe: Slightly hard to tell given that summary :-)
[13:08] <rogpeppe> niemeyer: here's an example of a URL shown by the charm store web site: ~ju-jistics-hackers:precise/logall-subordinate
[13:09] <niemeyer> rogpeppe: That's not a valid URL
[13:09] <rogpeppe> niemeyer: that's what i thought
[13:10] <rogpeppe> niemeyer: i wonder if py juju is accepting it though
[13:10] <niemeyer> rogpeppe: I don't think so
[13:10] <niemeyer> rogpeppe: This is unlikely anything else we've ever talked about
[13:10] <niemeyer> rogpeppe: URLs are prefixed by lp:
[13:10] <niemeyer> Erm, sorry
[13:10] <niemeyer> cs:
[13:10] <rogpeppe> niemeyer: yeah, but it's invalid even when prefixed by cs:
[13:11] <niemeyer> rogpeppe: Yeah, the : there should be /
[13:11] <rogpeppe> niemeyer: yup
[13:11] <rogpeppe> niemeyer: i'll try to find the appropriate place to raise an issue
[13:12] <niemeyer> rogpeppe: Thanks
[13:12] <niemeyer> rogpeppe: Good catch
[13:13] <jam> wallyworld: note that the types will now have methods on them that they didn't before, so it isn't that much 'less' poluted (imo). If I could, I would make them private, but then JSON couldn't unmarshal into them.
[13:13] <jam> I wasn't worried about pollution, because I thought these were supposed to be the types-for-json objects not the public-api objects.
[13:13] <wallyworld> jam: the state that the user can access though is cleaner
[13:15] <wallyworld> at  the moment, the objects eg Entity, ServerDetail etc are used in juju-core
[13:16] <wallyworld> so they are being used as the public api objects for better or worse
[13:17] <rogpeppe> niemeyer: https://bugs.launchpad.net/charmworld/+bug/1118351
[13:17] <_mup_> Bug #1118351: Charm URLs shown with invalid URLs in search <charmworld:New> < https://launchpad.net/bugs/1118351 >
[14:46] <Pavel_> Hi guys. Is there a way that I can add a local repository to juju-gui so I will be able to deploy my local charms directly from it?
[14:58] <hazmat> Pavel_, not yet
[14:59] <hazmat> Pavel_, we've been thinking to support local charms, we'll have the user run a program on their machine to expose the local repo via api on localhost that the gui can connect back to
[15:01] <Pavel_> Can't it just accept e.g. git repo as an setting and fetch it to it's own instance and then look through it?
[15:06] <hazmat> Pavel_, that's much less generic.. we'd have to support arbitrary numbers of arbitrary vcs, and authenticated access to those..
[15:07] <hazmat> to get to equiv functionality
[15:12] <Pavel_> yeah seems like it's not best option
[15:14] <Pavel_> but still if you want to run juju on the same node as juju bootstrap, then you already have this local repo available
[15:14] <Pavel_> *juju gui
[15:14] <Pavel_> but of course it's not common case
[15:16] <mramm> oops, lost track of time writing
[15:17] <Pavel_> And isn't "juju scp" an another option? Can't you copy local repo from juju bootstrap node to juju GUI node?
[15:18] <Pavel_> Sorry if I get something wrong
[15:33] <hazmat> Pavel_, there isn't a local repo per se on disk for either the bootstrap or gui node. the gui is searching through rest api endpoints of a charm store frontend, which is what we should replicate in the locally run program. the env has a cache of deployed service charms, but those are in provider storage, not on any given machine. ie there is no repo on disk to simply copy files to.
[15:40] <Pavel_> Yes, I understand. But do you think that replicating API is easier then reading repo from a local storage?
[15:48] <hazmat> Pavel_, simple answer yes.. what's local storage in a  multi-node ha system?
[15:48] <Pavel_> but juju bootstrap is always one node, isn't it?
[15:48] <hazmat> Pavel_, that's being worked on
[15:49] <Pavel_> hazmat, hot it
[15:49] <Pavel_> *got )
[15:51] <hazmat> i agree though at some point we'll have to explore answering questions from what local charms the environment has deployed .. but even then wouldn't be answering questions from disk. its not simply reading the charms on disk.. not just because there not on disk, but because its quite a rich search interface.. ie you can do full text and fielded queries like requires:mysql and conjunctions.
[15:52] <hazmat> speaking of which i was looking around for full text solutions for golang.. i found some n-gram/codesearch content.. but afaics there isn't any equivalent to xapian/lucene in golang.. best i could find was sqlite fts.
[15:57] <Pavel_> hazmat, I think that usually all you want is just to run more instances of existing services or deploy one which name you already know.
[16:00] <hazmat> Pavel_, that's fair.. but the search also helps drive richer ui interfaces, suggested relations, discovery, etc.
[16:01] <Pavel_> hazmat, but for local repo you could have simplier version of this
[16:01] <Pavel_> hazmat, actually you already know what is there and what you want to deploy
[16:02] <Pavel_> Generally I'm newbie in using juju, but my vision is that it can really play well for deploying domain based charms written for particular service.
[16:08] <hazmat> Pavel_, yes it could be simpler and likely will be, but local doesn't mean the deployer wrote it  or that the repo doesn't contain lots of charms, ie. search is still useful. hmmm.. i think i see what your saying for the use case though and why the local program for local charms doesn't suffice for it
[16:08] <hazmat> effectively you want to put local charms to the env, and have them available for deploy in the gui
[16:09] <Pavel_> yep
[16:33] <hazmat> Pavel_, sounds good
[16:36] <Pavel_> I really miss this feature
[16:38] <Pavel_> one more question, is there a way to set user name when run juju debug-hooks ?
[16:38] <Pavel_> I get ssh error when try doing this
[16:46] <hazmat> Pavel_, no.. it should be using the same key used to populate the env.. default it sniffs and injects the public key, but it can be specificied explicitly in environments.yaml as well .. it always goes to the ubuntu user which juju injects the public key as authorized key.. also this sort of question is better on #juju
[16:47] <Pavel_> ah, ok
[17:27] <rogpeppe> afk for a little
[17:42] <rogpeppe> back
[18:14] <dimitern> rogpeppe: quick question?
[18:15] <rogpeppe> dimitern: ask away!
[18:15] <dimitern> rogpeppe: what do I need to support for := range over my own type?
[18:15] <rogpeppe> dimitern: you can't do that
[18:15] <rogpeppe> dimitern: range always ranges over maps, slices or channels
[18:15] <dimitern> rogpeppe: really? damn..
[18:16] <rogpeppe> dimitern: what kind of type is it?
[18:16] <dimitern> rogpeppe: so I need something like a while loop with Next()
[18:16] <rogpeppe> dimitern: there are various possibilities for iteration
[18:16] <rogpeppe> dimitern: it totally depends what the semantics of your type are
[18:17] <dimitern> rogpeppe: well I'm trying to replace an embedded url.Values and provide the same interface - Add, Del, Set, Encode, etc. and still be able to iterate over
[18:17] <rogpeppe> dimitern: do you know in advance how many elements there are?
[18:17] <rogpeppe> dimitern: what semantics do you want to add?
[18:17] <dimitern> rogpeppe: because I need range to iterate in the order added and url.Values is map[string][]string
[18:18] <rogpeppe> dimitern: why not just provide a method that returns a sorted slice of all the entries in the map?
[18:18] <dimitern> rogpeppe: i.e. f.Add(x, ..); f.Add(y, ..) -> range x, then y
[18:18] <dimitern> rogpeppe: hmm yeah, that could work
[18:19] <rogpeppe> dimitern: you could just return the keys
[18:19] <rogpeppe> dimitern: and leave your type as a map
[18:19] <dimitern> rogpeppe: but not good enough - I don't need them sorted, but in the order added
[18:19] <rogpeppe> dimitern: out of interest, what's this to be used for?
[18:20] <dimitern> rogpeppe: maybe leave the embedded and override Add to keep ordered slice of keys aside and a method Keys() to return them in proper order
[18:20] <dimitern> rogpeppe: because openstack is sensitive with the order in which you specify multiple value filters
[18:21] <dimitern> rogpeppe: so status=A&status=B is not the same as status=B&status=A
[18:21] <rogpeppe> dimitern: ah
[18:21] <rogpeppe> dimitern: so it's not like ec2 that numbers all attributes sequentially?
[18:22] <dimitern> rogpeppe: no, it's a weird lax url encoded stuff with duplicates, but some logic to parse them in order
[18:22] <rogpeppe> dimitern: hmm, so for the double you won't be able to use any of the stock form parsing stuff
[18:23] <rogpeppe> dimitern: that's quite bad
[18:23] <rogpeppe> dimitern: what a shitty interface
[18:24] <rogpeppe> dimitern: so what *is* the difference between status=A&status=B and status=B&status=A ?
[18:27] <dimitern> wow, my machine died on me
[18:27] <rogpeppe> dimitern: :-|
[18:28] <rogpeppe> dimitern: what was the last message you saw from me?
[18:28] <dimitern> rogpeppe: can't see - had to cold boot
[18:28] <rogpeppe> dimitern: you need a better irc client :-)
[18:29] <rogpeppe> here are the last few things is said
[18:29] <rogpeppe> i said!
[18:29] <rogpeppe> 18:22:37] <rogpeppe> dimitern: hmm, so for the double you won't be able to use any of the stock form parsing stuff
[18:29] <rogpeppe> [18:23:36] <rogpeppe> dimitern: that's quite bad
[18:29] <rogpeppe> [18:23:49] <rogpeppe> dimitern: what a shitty interface
[18:29] <rogpeppe> [18:24:46] <rogpeppe> dimitern: so what *is* the difference between status=A&status=B and status=B&status=A ?
[18:29] <dimitern> rogpeppe: right, so the difference is this
[18:29] <dimitern> rogpeppe: I'll paste my code to see
[18:30] <dimitern> rogpeppe: http://paste.ubuntu.com/1621741/
[18:30] <rogpeppe> dimitern: oh BTW, there shouldn't be a problem with status=A&status=B - the same attribute is used both times
[18:31] <dimitern> rogpeppe: the problem is they are combined
[18:31] <dimitern> rogpeppe: oh... you know what, I think you're right - it's simpler
[18:31] <rogpeppe> dimitern: yeah, i don't think you're ranging over a map there
[18:32] <dimitern> rogpeppe: I managed to debug the name gets replaced by the last value specified, but for status wasn't that obvious
[18:32] <rogpeppe> dimitern: all the names are still available
[18:32] <rogpeppe> dimitern: that's why it's map[string][]string
[18:32] <dimitern> rogpeppe: my original thought was specifying status twice will get me both statuses
[18:32] <rogpeppe> dimitern: (note the []string)
[18:32] <rogpeppe> dimitern: it should do, yes
[18:33] <dimitern> rogpeppe: but my tests so far show:
[18:33] <rogpeppe> dimitern: i mean... what?
[18:33] <rogpeppe> dimitern: it depends what level you're talking about
[18:33] <dimitern> rogpeppe: S=A&S=B -> 0 (assuming 3 servers in A)
[18:34] <dimitern> rogpeppe: S=B&S=A -> 3; S=X&S=Y&S=A -> 3; S=X&S=A&S=Y -> 0
[18:34] <rogpeppe> dimitern: those are the semantics that openstack gives you?
[18:34] <dimitern> rogpeppe: it's very frustrating to actually create several machines with different status to test this properly
[18:35] <dimitern> rogpeppe: those are my findings after running a lot of queries with filters against canonistack
[18:35] <rogpeppe> dimitern: so it's just ignoring all but the last value for a given attribute, right?
[18:35] <dimitern> rogpeppe: and the problem is, in juju you'd like to get all machines in either build or active, but this seems impossible with as single API call
[18:36] <dimitern> rogpeppe: seems so yes
[18:36] <rogpeppe> dimitern: they could've learned something from ec2's filtering semantics
[18:36] <dimitern> rogpeppe: i tried to replicate ec2 way, but i guess we'll have to get only active machines and until the status changes from build to active, Instances() won't return anything
[18:36] <rogpeppe> dimitern: yeah, sounds like you need two queries
[18:37] <rogpeppe> dimitern: and combine the results of both
[18:37] <rogpeppe> dimitern: you can run 'em both concurrently though, so it shouldn't be much slower
[18:37] <dimitern> rogpeppe: yes, unless getting only active suffices
[18:37] <rogpeppe> dimitern: so... i don't see that there's any particular difficulty here
[18:38] <rogpeppe> dimitern: we don't care about map ordering
[18:38] <dimitern> rogpeppe: yeah
[18:38] <dimitern> rogpeppe: I wish I could've seen that yesterday more clearly :)
[18:39] <dimitern> rogpeppe: and to actually test whether in fact multiple status filters work at all
[18:39] <rogpeppe> dimitern: to implement the double you can just have a function: func GetLastValue(v url.Values, attr string) string {x := v[attr]; if len(x) > 0 {return x[len(x)-1]}; return ""}
[18:39] <dimitern> rogpeppe: is it important to get pending machines from the provider as well? even with the eventual consistency attempts/retries?
[18:40] <rogpeppe> dimitern: yes
[18:40] <dimitern> rogpeppe: why?
[18:40] <rogpeppe> dimitern: because we assume that if we've called StartInstance we can retrieve information about it soon afterwards
[18:41] <rogpeppe> dimitern: if openstack is anything like ec2, pending machines can remain pending for quite a long time
[18:42] <dimitern> rogpeppe: if it's only about getting result out of StartInstance, you always get this
[18:42] <rogpeppe> dimitern: what's the significance of "build" and "active" with regard to juju, BTW?
[18:42] <dimitern> rogpeppe: and it's correct, the problem could be if you want to list them later
[18:42] <rogpeppe> dimitern: exactly
[18:42] <rogpeppe> dimitern: or get an Instance
[18:42] <rogpeppe> dimitern: from the instance id
[18:43] <rogpeppe> dimitern: what's the issue you have with returning pending instances?
[18:43] <dimitern> rogpeppe: build means basically booting, setting up network, etc., which becomes available shortly before the machine switches to active
[18:43] <dimitern> rogpeppe: getting instance by id is again not a problem
[18:44] <dimitern> rogpeppe: only Instances() and AllInstances() are affected
[18:45] <dimitern> rogpeppe: which will use the filtering and ideally do it with a single API call, filtering by inst name (environment) and active status
[18:45] <dimitern> rogpeppe: if you need a specific instance and you know it's id you can get it directly, no filtering involved
[18:46] <rogpeppe> dimitern: i think only AllInstances is affected
[18:47] <dimitern> rogpeppe: the idea of filtering arose from the need to get only this environment's machines (by name) - so both Instances() and AllInstances() use it
[18:48] <rogpeppe> dimitern: Instances only does it so it doesn't return machines which have been stopped
[18:49] <dimitern> rogpeppe: but how about the ones about to become active?
[18:49] <rogpeppe> dimitern: yeah, it needs to return those
[18:49] <rogpeppe> dimitern: as far as juju is concerned, they're active already, just not ready.
[18:50] <dimitern> rogpeppe: ok I can do it in 2 goroutines then, fetching both active and build and returning the merged
[18:50] <dimitern> rogpeppe: the thing is, machines in build state cannot be tackled the same as active ones
[18:50] <rogpeppe> dimitern: yup. or, even better, just don't filter by status at all
[18:50] <rogpeppe> dimitern: and filter that client side
[18:51] <dimitern> rogpeppe: some things fail (like assigning a floating IP)
[18:51] <dimitern> rogpeppe: that's even better actually - I'll just filter out the ones with bad status
[18:51] <rogpeppe> dimitern: yup
[18:51] <dimitern> rogpeppe: the problem is you can have 100K machines to process there
[18:51] <rogpeppe> dimitern: we only do the filtering server-side in ec2 'cos it's easy to do
[18:52] <rogpeppe> dimitern: that's true of AllInstances in general
[18:52] <rogpeppe> dimitern: i don't think returning dead machines is going to add too much load
[18:53] <dimitern> rogpeppe: actually the machines that need filtering will be a lot less than the active ones
[18:53] <rogpeppe> dimitern: exactly
[18:53] <dimitern> rogpeppe: ok then, I'll filter client-side for status
[18:53] <rogpeppe> dimitern: +1
[18:54] <dimitern> rogpeppe: thanks :) it really helped me clear it up for myself
[18:54] <rogpeppe> dimitern: then you can ignore the whole url.Values thing :-)
[18:54] <rogpeppe> dimitern: np, it's a pleasure to help
[18:54] <dimitern> rogpeppe: yeah, or at least make it much simpler


[10:31] <tg90nor> hi
[10:31] <tg90nor> what would cause cloud-init to regenerate ssh host keys upon rebooting my ubuntu trusty server?
[10:38] <Odd_Bloke> tg90nor: If cloud-init were to think that it were on a new host, it would regenerate them.  What environment are you seeing this in?
[10:39] <tg90nor> Odd_Bloke: my server is running in an openstack cloud. the logs indicate there may have been a problem reaching the metadata server
[10:40] <Odd_Bloke> tg90nor: cloud-init stores the data about instances it thinks it has run on in /var/lib/cloud/instances; is there more than one directory in there?
[10:40] <tg90nor> yes, there are two directories
[10:41] <Odd_Bloke> tg90nor: OK, so that's probably the issue you're seeing.
[10:44] <tg90nor> Odd_Bloke: thanks! seems cloud-init detected it as an ec2 instance, probably after some temporary failure to talk to the metadata server
[10:44] <Odd_Bloke> tg90nor: Ah, right; yeah, the assumption is that the metadata server will always be there. :)
[16:25] <esierrap> hi, is it possible set gid of group?