[01:03] <axw> morning all
[01:06] <waigani> morning axw :)
[01:06] <perrito666> well github is rather verbose
[01:06] <waigani> how's bug land?
[01:07] <axw> not bad, since I haven't been looking at the horrible mongo-related bugs lately
[01:13] <perrito666> ok guys, EOD
[01:26] <axw> wallyworld: got time to chat?
[01:27] <wallyworld> sure
[01:27] <axw> wallyworld: https://plus.google.com/hangouts/_/gw7us4q4lhcyws5ksu7ipthn6ia?hl=en
[02:13] <axw> wallyworld: there is already a canonistack slave
[02:13] <wallyworld> oh
[02:13] <axw> but... running tests on there may interfere with CI
[02:14] <wallyworld> yeah
[02:16] <axw> I'm going to try adding another one in that we can use
[02:21] <wallyworld> axw: the current script used by jenkins for the github landing fails with an unexpected EOF. i can't spot the issue, here's a pastebin - it's the last bit that's bad. can you see the error? http://pastebin.ubuntu.com/7577197/
[02:23] <axw> wallyworld: nothing jumps out
[02:24] <wallyworld> ok, ta
[02:26] <axw> wallyworld: the "}" needs to be preceded by a newline or semicolon
[02:26] <wallyworld> ok, will try that
[02:27] <wallyworld> \o/ thanks, that was it
[02:29] <axw> nps
[02:38] <sinzui> wallyworld, mgz, canonistack is under resources, our aws account is reaching saturation. joyent and hp cloud have lots of cpus/instances for us to test/build with
[02:39]  * sinzui will look to move some function tests and series tests to hp this week
[02:39] <wallyworld> sinzui: ok, we may need to try hp cloud. i'm testing now with a nailed up ec2 instance i was using for mongo testing in order to save time
[02:39] <sinzui> wallyworld, mgz, will the lander be running unit tests for more than 1 series
[02:39] <sinzui> ?
[02:40] <wallyworld> sinzui: not initially since we are just going trunk at first, but it will
[02:40] <sinzui> wallyworld, I need to teach the default run-unit-tests about nova. At this time we can run ec2 or any existing host. Teaching the setup about joyen would be goos too
[02:41] <sinzui> oh, and azure was saturated last December, not that you wanted to wait 25 minutes to bring up a instance
[02:41] <wallyworld> sinzui: at the moment, the unit tests the lander runs fail every time using an ephemeral ec2 instance
[02:42] <wallyworld> using a nailed up instance seems better
[02:42] <sinzui> wallyworld, bad script, unbound variable
[02:42] <wallyworld> i have a couple of tests fail due to build errors but everything else passes
[02:43] <sinzui> thats the problem with cargo culting a script, you loose the context of what the required setup is
[02:43] <sinzui> wallyworld, I am adding set -eux to make it easier to debug
[02:44] <wallyworld> ok
[02:46] <sinzui> wallyworld, I think you are going to get a pass this round
[02:46] <wallyworld> i hope so
[02:47] <wallyworld> well, except for the build error
[02:47] <wallyworld> sinzui: did you change the test-merge-git script?
[02:48] <sinzui> wallyworld, no, I think someone fixed the unbound var from run #2
[02:48] <sinzui> wallyworld, sorry, a failure
[02:49] <sinzui> oh, is this trusty?
[02:49] <wallyworld> yeah but at least it was due to a build failure
[02:49] <wallyworld> i think so
[02:50] <sinzui> this is one of the common intermittent bugs.
[02:50] <wallyworld> oh, i just saw the replicaset failure also
[02:50] <sinzui> maybe we want to call make check a few times to replay intermittent faules
[02:51] <sinzui> make check || make check || make check
[02:51] <sinzui> ^ three tries
[02:51] <wallyworld> on canonistack with tarmac, we seem to have eliminated most of the failures
[02:51] <wallyworld> seems more flakey on ec2
[02:51] <wallyworld> but yes, i guess we can do 3 retries
[02:51] <sinzui> wallyworld, This test always gets current packages before starting
[02:52] <sinzui> and I think you were using precise which had fewer changes
[02:52] <sinzui> wallyworld, may, I make some quick changes to remove the unsed parts of the script and make it retry?
[02:52] <wallyworld> yes please
[02:53] <wallyworld> we only have a small window left to get this working
[02:53] <wallyworld> it will still fail due to the build errors though
[02:54] <wallyworld> looks like the import pulled in a deleted package
[02:54] <wallyworld> cmd/jujuc
[02:59] <wallyworld> sinzui: those obsolete files which cause the compile errors are now gone.
[02:59] <sinzui> okay
[02:59] <wallyworld> are you finished with the script?
[02:59] <wallyworld> can we start another run?
[03:01] <waigani> thumper: ping
[03:02] <thumper> waigani: in the middle of something right now
[03:02] <waigani> thumper: okay, np
[03:12] <sinzui> wallyworld, I see this script was restarted. I just save my changes. I removed the non-ephemeral conditions because this use is always ephemeral. I removed the lines that built tools. I need to do the same to the real scripts because we now do a proper isolated build for each test deb and tool
[03:13] <wallyworld> sinzui: i restarted just to get a ahead start on whether my build fixes were ok, i'll re-run wth your changes also
[03:14] <sinzui> okay
[03:14] <wallyworld> sinzui: my main concern is that now the landing process takes a fair bit longer
[03:14] <sinzui> I just discovered that I cannot build juju packages and run unit tests on the same machine
[03:14] <sinzui> wallyworld, yep
[03:15] <wallyworld> so i'm thinking we do want to move to a nailed up instance at some point post cutover
[03:16] <sinzui> you can make it go much faster with provisioned instance or one that you start and stop. The deps phases of the script are essentially skipped
[03:17] <wallyworld> yep
[03:17] <wallyworld> i think having one that we start and stop will be best
[03:17] <sinzui> I am pondering  having a jenkins slave for each crucial series+arch, and using the instance as a dedicated builder and running of local-provider tests
[03:18] <wallyworld> sounds reasonable
[03:25] <wallyworld> sinzui: yay, that run worked
[03:25] <wallyworld> i'll try another with your changed script active
[03:26] <sinzui> excellent, now we get to see if I can hack a bash script without syntax highlighting
[03:28] <axw> wallyworld: it says #18 passed, but in the logs the replicaset package's tests failed
[03:28] <axw> oops
[03:28] <axw> wrong tab :)
[03:28] <wallyworld> phew
[03:28] <axw> wallyworld: why did the PR not get updated?
[03:29] <wallyworld> it should have i think, not sure
[03:44]  * thumper grumbles
[03:51]  * thumper makes unpleasent noises
[03:51] <thumper> I've worked out why this test is failing
[03:52] <thumper> it is because JujuConnSuite bootstraps the environment for you
[03:52] <thumper> and I've changed the base test suite for this test
[03:52] <thumper> to something much simpler,
[03:52] <thumper> hence, broken test
[03:52] <thumper> now how to just write out some jenv stuff...
[03:53] <axw> wallyworld: I was waiting for a LGTM, then I would do $$merge$$ - that's still the protocol right?
[03:53] <wallyworld> axw: yeah, i'm experimenting trying to get the bot to pick it up
[03:53] <wallyworld> the current core will be blown away and replaced with the trunk snapshot
[03:53] <axw> ok
[03:53] <waigani> axw, wallyworld: will we use codereview at all anymore?
[03:54] <axw> waigani: no
[03:54] <wallyworld> nope :-D
[03:54] <wallyworld> and good riddence
[03:54] <waigani> big changes, okay
[03:54] <axw> wallyworld: the lander didn't pick up the $$merge$$ on your other PR?
[03:55] <wallyworld> axw: nope :-(
[03:55] <wallyworld> there's something wrong clearly
[03:55] <waigani> man git is spamming my inbox!
[03:55] <wallyworld> there's a cron job, but i also ran it by hand
[03:55] <axw> wallyworld: are you running it on your machine now?
[03:55] <axw> mk
[03:55] <wallyworld> axw: nope, i've sshed into jenkins
[03:59] <axw> wallyworld: your membership in the juju org needs to be made public
[03:59] <wallyworld> ok, i didn't realise it wasn't
[04:01] <wallyworld> ah, that has fixed it
[04:01] <axw> wallyworld: I'll reply to the list about that
[04:01] <wallyworld> axw: that's a good pickup because a bunch of others are also private
[04:01] <axw> yup
[04:08] <wallyworld> axw: so now with the ephemeral instances we waste about 6-7m getting everything set up to run the tests. not great, but not a show stopper for cut over
[04:09] <axw> wallyworld: yeah doesn't seem too terrible for a first cut
[04:09] <wallyworld> axw: the thing now is the extra occurrences of these fraking timeout errors etc which break the tests
[04:10] <axw> yep... :/
[04:10] <wallyworld> just got one now in the current run
[04:10] <wallyworld> i could have sworn that it's worse on ec2
[04:13] <axw> wallyworld: I wonder if pre-warming the disk would be of benefit
[04:13]  * axw looks into what we can do there
[04:13] <wallyworld> axw: yeah, i was wondering that also
[04:18] <thumper> nailed it!
[04:22] <thumper> coffee time
[04:29] <thumper> WTF...
[04:29] <thumper> lbox still trying to work out the diff
[04:29]  * thumper goes to make the coffee
[04:30] <axw> wallyworld: one option is to try using the ephemeral storage, in /mnt
[04:31] <axw> wallyworld: I think that should be considerably faster
[04:31] <axw> and we don't need the persistence...
[04:31] <thumper> omg, that grew a bit... https://code.launchpad.net/~thumper/juju-core/user-display-name/+merge/221823
[04:31] <wallyworld> axw: can't hurt, looks like the current job will pass second time through. can you tweak the script to use/mnt?
[04:31] <axw> wallyworld: even just putting TMPDIR in there
[04:31] <axw> wallyworld: I'll give it a shot
[04:32] <wallyworld> ok, ta
[04:32] <wallyworld> TMPDIR sounds sensible also
[04:32] <thumper> menn0:  https://codereview.appspot.com/102970043 - it grew more than expected
[04:32]  * thumper -> coffee
[04:33] <menn0> thumper: looking
[04:53] <thumper> menn0: I suggest that you, me and waigani chat tomorrow about it
[04:53] <thumper> as there are a number of things I want to talk through
[04:53]  * thumper heads out to local code craft meeting
[04:54] <menn0> thumper: ok. I'm almost done though and I think I understand most of the things you're going to talk about
[04:54] <thumper> :)
[04:56] <menn0> thumper: thanks for cleaning up some of my --password changes. Much better.
[05:09] <wallyworld> axw: that last one took all 3 attempts to merge. different error each time. the watcher / session closed issue seems to be more prevalent of late
[05:11] <axw> wallyworld: I put in the $TMPDIR change, hopefully that makes a difference
[05:12] <wallyworld> axw: i'll trigger another merge and we'll see how it goes
[05:12] <axw> ok
[05:14] <wallyworld> axw: is it work setting up a dir in /mnt and setting GOPATH to that?
[05:14] <wallyworld> worth
[05:14] <wallyworld> before i do another run
[05:15] <axw> wallyworld: I don't think so, that's just for building the code
[05:15] <axw> it might make building the code a bit quicker, I guess, but I don't think it's a bottleneck by a long shot
[05:19] <wallyworld> ok
[05:24] <axw> wallyworld: https://github.com/juju/core/pull/4
[05:26] <wallyworld> axw: looks like it's off and running
[05:26] <axw> goodo
[05:26] <axw> wallyworld: we should probably run that script before tests too
[05:26] <wallyworld> yeah
[05:27] <wallyworld> i think i mentioned that to martin but we never wrote it down
[05:27] <axw> I'll add it in the job now
[05:28] <wallyworld> ok, ta
[06:07] <wallyworld> axw: a random thought - would running the tests with say "-p 4" help, since that may cut down on the thrashing of resources etc
[06:08] <axw> wallyworld: umm, I think it's going to be 2 as it is
[06:08] <axw> it's running on a dual core isn't it?
[06:08] <axw> -p defaults to #CPU
[06:08] <wallyworld> not sure, i had thought it was higher
[06:08] <wallyworld> you may be right
[06:08] <axw> wallyworld: I'll check, but I don't think it's higher than 4
[06:09] <wallyworld> if it is 4, then may -p 2
[06:09] <axw> wallyworld: it has 4
[06:09] <wallyworld> yeah, m1.xlarge
[06:10] <axw> wallyworld: doesn't hurt to try
[06:10] <wallyworld> the latest run failed twice
[06:10] <axw> yeah :/
[07:03] <wallyworld> axw: sigh. latest builds not happy
[07:03] <wallyworld> go tool: no such tool "vet"; to install:
[07:03] <wallyworld> 	go get code.google.com/p/go.tools/cmd/vet
[07:04] <wallyworld> i have to head to soccer, are you able to have a look and i'll check later?
[07:09] <axw> wallyworld: sorry, will fix
[07:56] <rogpeppe> so... one hour to github D Day... how's it looking?
[08:13] <voidspace> morning all
[08:22] <TheMue> voidspace: morning
[08:22] <voidspace> TheMue: o/
[08:44] <jam> wow, it took me 3 hours to actually get a bootable USB stick that works…. so hard, why is it so hard...
[08:45] <voidspace> jam: I've always found it difficult too
[08:45] <voidspace> jam: and I think in the end I discovered I could only make it work with *one* of my USB sticks
[08:45] <jam> voidspace: yeah, there are 4 different master partition table types, and various flags that have to be set, and ....
[08:45] <jam> and tools that you try to use that just blow up unless everything is already set up correctly
[08:46] <jam> voidspace: so I formatted with MBR form on my Mac, took it over to Ubuntu and used fdisk to create 1 partition dos compatible, set it active and bootable, set the type to 0x0C, mkfs.fat -F 32, and then use Startup Disk Creator to copy the ISO onto the stick.
[08:46] <jam> now *maybe* msdos formatting from gparted would have also worked (maybe)
[08:47] <voidspace> heh, ouch
[08:47] <jam> I tried a lot of other permutations in there
[08:47] <jam> but it seems like a streamlined "here is an ISO, and do what you want to this stick to make it boot"
[08:48] <jam> would be such a better experience
[08:48] <lifeless> jam: dd usually works, no ?
[08:49] <voidspace> I always used to use unetbootin on the Mac - it didn't work for me on Ubuntu last time I tried it
[08:49] <voidspace> lifeless: morning
[08:49] <jam> lifeless: so the Mac instructions have you convert the ISO into a DMG and then dd it, which worked once
[08:49] <jam> but I accidentally used the 64 bit version for an old machine
[08:49] <jam> so I had to fix it for 32 bit
[08:49] <jam> and … yeah, a lot of stuff didn't work
[08:49] <jam> I think the key was finding a way to get MSDos compatibility enough
[08:51] <jam> lifeless: dd doesn't set the bootable or partition table, does it?
[08:51] <lifeless> jam: it includes a partition table
[08:51] <lifeless> jam: dd of=/deb/sdb
[08:56] <jam> lifeless: the biggest problem I had was having the old machine find the USB device as bootable, I'm not sure if I tried just dd from the .iso
[08:56] <voidspace> axw: ping
[08:56] <jam> it wasn't in any of the recommended guides
[08:56] <jam> all that just to run shred sanely on all my old hard drives before getting rid of old equipment
[08:57] <axw> voidspace: pong
[08:57] <jam> I'll try that once the shredding is done :)
[08:59] <jam> lifeless: good to see you around, btw, haven't said hi in a while
[08:59] <lifeless> jam: hi :)
[08:59] <lifeless> jam: did you consider netbooting ?
[09:00] <lifeless> jam: e.g. with maas and run shred from there?
[09:01] <lifeless> or even perhaps maas should have a decommission-hardware facility, to make removing old content easy
[09:05] <jam> lifeless: interesting thought, I had not considered it. The main idea was to not have / on the physical disks so that I could nuke everything without worrying about mounts. Because I *could* just boot the thing directly, though it was running Hardy
[09:06] <jam> and I think the other machine is/was running Fedora Core *3*
[09:06] <voidspace> axw: so we made a change to Initiate yesterday on the suspicion that the CI machine was just slow
[09:06] <voidspace> axw: this is the bootstrap problem on precise amd64
[09:06] <axw> voidspace: I saw
[09:06] <voidspace> axw: it did not fix the issue - but it made the problem a bit clearer
[09:07] <axw> oh?
[09:07] <jam> lifeless: one funny thing working here, is that I'm now the most senior person in all of Juju. Tim is here, but I predate him by a couple of months (since he actually originally applied for the Bazaar dev role)
[09:07] <voidspace> axw: immediately after calling replSetInitiate we poll until CurrentStatus returns successfully
[09:07] <voidspace> axw: on the failing machine that fails immediately (and persistently) with a "Closed explicitly" error
[09:07] <voidspace> axw: that specific error seems to come from the mgo library when socket.Close() is called
[09:08] <axw> yep
[09:08] <voidspace> axw: I've read through the code from MaybeInitiate  (I probably need to go further back in the code but we're running out of time) to see if I can find a race condition
[09:08] <axw> on the other machines it comes back saying "it'll be ready soon" or something?
[09:08] <voidspace> axw: yep
[09:08] <voidspace> I thought that we just weren't waiting long enough before giving up on this machine
[09:09] <voidspace> but that appears not to be the case
[09:09] <voidspace> axw: I do have one question
[09:09] <voidspace> inside replicaset/replicaset.Initiate
[09:09] <lifeless> jam: wow, sounds like there was quite some turnover?
[09:10] <voidspace> we call monotonicSession.SetMode(mgo.Monotonic, true)
[09:10] <jam> lifeless: well, this is just Juju, there are still people at Canonical that predate me.
[09:10] <jam> plus, I'm like #70 or so
[09:10] <jam> so not a huge gap in front, and 600 people now at Canonical
[09:10] <jam> so, I was in top 10% to start
[09:10] <voidspace> axw: session.SetMode - the second parameter is for "refresh", which if true calls session.unsetSocket()
[09:11] <voidspace> axw: do you know why it does this?
[09:11] <axw> voidspace: I think the refresh is to ensure restarting of the consistency guarantee
[09:11] <axw> I don't know any more than that
[09:12] <axw> voidspace: rogpeppe or natefinch may know more about it
[09:12] <lifeless> jam: sure, I was meaning in the juju context
[09:12] <voidspace> axw: as far as I could tell this *doesn't* close the socket - although it does set a couple of sockets to nil
[09:12] <voidspace> axw: but there's no finalizer that I could find
[09:12] <lifeless> jam: like, I'd have thougt kapil or mramm joined juju before you
[09:12]  * axw looks
[09:12] <jam> lifeless: I mean joined Canonical, where I predate mramm, but maybe not kapil
[09:13] <voidspace> axw: and it calls socket.Unlock() - which I think comes from the fact that mgo.socket embeds sync.Mutex
[09:13] <jam> he doesn't directly report on the same chain
[09:13] <voidspace> axw: which also wouldn't call Close
[09:13] <jam> for Juju proper, lots of people still working on the project longer than me
[09:13] <jam> fwereade, mramm, rogpeppe, etc.
[09:13] <axw> voidspace: unsetSocket does a socket.Release
[09:13] <voidspace> lifeless: jam: mramm is relatively new - I predate him
[09:14] <jam> voidspace: yeah, he's only about 2 years or so
[09:14] <jam> but he's been working as part of Juju longer than me
[09:14] <voidspace> axw: right, which does an Unlock() followed by a LogoutAll()
[09:15] <voidspace> axw: none of which *seems* to call Close()
[09:15] <voidspace> I guess that isn't it - it was just suspicious
[09:16] <voidspace> axw:  and I wondered if we *needed* that refresh
[09:16] <axw> voidspace: hmm yeah, I think it just puts it back into a pool to be reused.
[09:16] <axw> voidspace: that I do not know
[09:17] <voidspace> axw: something is closing the socket the session is using - causing all further operations to fail
[09:17] <voidspace> axw: but only on the CI build machine...
[09:18] <voidspace> axw: I think this morning is the deadline though, we can't leave trunk broken any longer
[09:18] <voidspace> even if it's just on one machine...
[09:18] <voidspace> so we'll have to backout my changes and switch to a different strategy for setting the Mongo WMode (which was the purpose of enabling replica sets for local provider)
[09:19] <axw> voidspace: bugger :(
[09:19] <voidspace> not having direct access to the machine to try things on doesn't help
[09:20] <voidspace> coffee
[09:20] <axw> voidspace: it's the closing of the "Server" object that closes all the sockets
[09:35] <jam> wow, driving it at 73MB/s sustained will still take 4 hours to do 1 pass over 1TB of data, and I have it set to do 3, guess I just come back tomorrow :)
[09:37] <lifeless> jam: doing some map-reduce ?
[09:37] <lifeless> jam: oh shred ;)
[09:37] <jam> lifeless: shredding old disks before giving them away
[09:38] <lifeless> well, gnight :)
[09:38] <jam> lifeless: gnight
[09:50] <stub> github.com/ju/ju/core
[09:52] <voidspace> stub: hah, nice
[09:52] <voidspace> we should do that
[10:04] <voidspace> natefinch: morning
[10:04] <natefinch> voidspace:  morning
[10:05] <jam> fwereade: quick poke about CodeNotFound vs CodeUnauthorized here. If you pass an environ we don't recognize, what code should we get?
[10:05] <jam> We are still getting the error during Login, because of how round trips work, so Unauthed is somewhat reasonable
[10:27] <perrito666> good morning
[10:32] <wallyworld> rogpeppe: jam: natefinch: you guys ok with githib.com/juju/juju-core ? seems to be the least hated option
[10:32] <jam> wallyworld: omg, wtf,,, how could you say such a thing
[10:32] <jam> wallyworld: I'm pretty easy going here.
[10:32] <wallyworld> me too
[10:32] <wallyworld> just trying to get consensus, whatever that means
[10:33] <jam> I'd actually like to get rid of the "-core" part, because it feels like it is just baggage because there was a pyjuju that took 'juju' over for too long
[10:33] <wallyworld> yeah
[10:33] <natefinch> that was my thought of why it should just be juju
[10:33] <jam> if you "apt-get install juju" you get juju-core
[10:33] <wallyworld> so github.com/juju/juju then?
[10:33] <jam> I agree that github.com/juju/juju/juju and github.com/juju/juju/cmd/juju.Juju are a bit silly, but the -core doesn't actually add any information.
[10:34] <natefinch> yeah, it's the same stuttering, just with some garbage in the middle
[10:34] <wallyworld> i thought core because it distinguishes from logging testting etc
[10:34] <jam> wallyworld: github.com/juju/juju is my #1, with github.com/juju/juju-core being #2, I guess
[10:34] <jam> fair point, though I'd rather prefer we had libjuju and juju the cmdline tool :)
[10:34] <natefinch> for the record, I still don't know what the juju-core/juju package is for, maybe we just need to rename that
[10:34] <wallyworld> or rename juju the team to juju-team :-)
[10:35] <wallyworld> github/juju-team/juju
[10:35] <wallyworld> +1 to renaming juju-core/juju
[10:35] <natefinch> wallyworld: I actually don't like the testing package name, it's not descriptive on its own, and it should be, if it's in its own repo
[10:35] <natefinch> s/package/repo/
[10:36] <wallyworld> yeah, i haven't thought about that one, since i didn't set it up
[10:36] <jam> natefinch: it is the entry point, AIUI, so juju/api.go etc. "juju.NewAPIClientFromName()"
[10:36] <jam> natefinch: arguably we could have that at the top level
[10:37] <jam> github.com/juju/juju.NewAPIClient()
[10:37] <natefinch> jam: having something at the top level would be nice.  I'd love to have cmd/juju at the top level, since that's what you'd normally "go get"  even though we sadly don't support that
[10:38] <jam> natefinch: IMO that is a clear use case for having 2 separate things, a 'libjuju' and a 'juju command line client"
[10:38] <wallyworld> that makes sense
[10:39] <voidspace> perrito666: morning
[10:39] <wallyworld> what do other github team based projects do?
[10:39] <wallyworld> is team name normally = product name?
[10:39] <natefinch> often times, yes
[10:40] <wallyworld> so i guess we should go with github/juju/juju
[10:40] <wallyworld> can we all live with that?
[10:41] <natefinch> the only other person I heard respond was axw, who said he moderately preferred /juju/juju, I think
[10:42] <voidspace> I prefer juju/juju
[10:42] <voidspace> fwiw :-)
[10:42] <wallyworld> ok, the people have spoken :-)
[10:42] <natefinch> Actually, rogpeppe responded, but sort of vaguely
[10:42] <rogpeppe> i'm not that keen on juju/juju actually
[10:43] <rogpeppe> because then we have a package github.com/juju/juju/juju
[10:43] <rogpeppe> which seems like overkill
[10:43] <rogpeppe> i actually think that core isn't too bad
[10:43] <rogpeppe> but i'd be happy with juju/juju-core too
[10:43] <natefinch> rogpeppe: we can just rename that package
[10:44] <rogpeppe> as it distinguishes the genuinely juju-specific parts of github.com/juju
[10:44] <rogpeppe> because actually most packages under github.com/juju are *not* juju specific
[10:44] <rogpeppe> so having a juju- prefix to the name makes sense
[10:44] <natefinch> that's why I like calling this repo juju :)
[10:44] <rogpeppe> natefinch: yeah, but see above :-)
[10:45] <rogpeppe> jujujujujuju
[10:45] <voidspace> natefinch: my absolutely last ditch attempt to fix locl-deploy-precise-amd64
[10:45] <voidspace> natefinch: https://code.launchpad.net/~mfoord/juju-core/refresh-session/+merge/221857
[10:45] <natefinch> see above.... we should rename that package anyway
[10:46] <voidspace> natefinch: just running all tests here to check it doesn't break anything
[10:46] <voidspace> natefinch: should I propose it/
[10:46] <voidspace> ?
[10:46] <rogpeppe> natefinch: well, the original intent of that package was that we'd have a "juju" package which would be the "face" of juju to external Go code
[10:47] <rogpeppe> natefinch: i still think that's a reasonable intent
[10:47] <voidspace> yay for bike-sheds
[10:48] <natefinch> rogpeppe: rename it to libjuju, since juju is the command line client
[10:48] <rogpeppe> natefinch: and if we were to export versioned APIs, maybe it might make sense to have a separate (versioned) repo named "juju" which would import juju-core
[10:48] <rogpeppe> natefinch: libjuju?
[10:48] <dimitern> vladk|offline, standup?
[10:50] <natefinch> rogpeppe: maybe github/juju-team is better?
[10:50] <rogpeppe> natefinch: probably
[10:50] <rogpeppe> natefinch: but github/juju is fine too
[10:50] <rogpeppe> natefinch: and github/juju/juju-core works pretty well, i think.
[10:50] <rogpeppe> natefinch: and leaves the path open for other juju- packages
[10:52] <natefinch> rogpeppe: juju-core was my second choice, I just don't think core adds much... and using /juju doesn't stop someone else from using juju-foo
[10:53]  * natefinch wants to make a juju-fu package now
[10:55] <rogpeppe> natefinch: if the top level of the juju-core repo was a usable package, i'd agree that juju was a better name (it makes for a more guessable identifier) but as it is, i think i'm in favour of juju-core, or just core and people can rename it. tbh i don't care too much.
[10:55] <natefinch> well, I'd love to put cmd/juju in the root so that the CLI client is the top level "thing that gets built"... but that's probably asking too much ;)
[10:57] <wallyworld> so do we want juju-core then?
[10:58] <natefinch> It sounds like we have 4 votes for /juju and one for juju-core ....  so I don't know where that puts us
[10:58] <wallyworld> i originally was +1 for juju-core if core were not suitabke
[10:58] <voidspace> I'd have thought it was fairly clear where it puts us...
[10:58] <natefinch> wallyworld: so 2 for juju-core.
[10:59] <natefinch> voidspace: I'm actually not trying to make it a popularity contest
[10:59] <voidspace> heh
[10:59] <mgz> I have decided we're going to use github.com/juju/justsomedamncode
[10:59] <natefinch> lol
[10:59] <wallyworld> i just wish our team was called juju-team
[10:59] <voidspace> it should be justsomedamnedcode
[10:59] <wallyworld> that would remove a lot of the stuttering
[10:59] <natefinch> https://github.com/rails/rails
[11:00] <voidspace> team and project name the same is a pretty common convention I would expect
[11:00] <natefinch> for things that are actually worked on by outsiders, yes... there's github.com/dotcloud/docker  for example
[11:01] <natefinch> (for things that are more primarily worked on by the company)
[11:37] <voidspace> natefinch: ping
[11:51] <voidspace> natefinch: I'm going on lunch
[11:51] <voidspace> natefinch: can you take a look at https://codereview.appspot.com/102980043/
[11:52] <voidspace> natefinch: and see if you think it's worth one last try, or if you have a better idea / modifications
[11:52] <voidspace> natefinch: or just think it's a bad idea...
[12:00] <natefinch> voidspace: I looked, it's worth a try.  We should really get on the CI machine... sinzui tells me we can do that now.  I forget exactly what he said but I can find it on the traceback
[12:16] <perrito666> oh man, I missed the bikeshed
[12:17] <perrito666> say guys, I have something to submit, but I am not sure were we stand since today is go to github day
[12:18] <jam> perrito666: well they haven't said "we are on github now" so I think we're still on launchpad
[12:18] <perrito666> jam: as far as we are not in between
[12:19] <jam> perrito666: until they say stop, we might as well land where we land
[12:19] <jam> well, until they say go, I guess
[12:19] <perrito666> jam: ack
[12:19] <perrito666> jam: btw https://codereview.appspot.com/103820044/ if you want to take a look
[12:20] <jam> perrito666: do we need to concern ourselves about getting <IP_ADDRESS> or ::1 instead of "localhost" ?
[12:20] <perrito666> for the moment I am getting spammed by gh I need to create a few new filters it seems
[12:21] <jam> perrito666: fortunately, they are "lists" so gmail filters them ok, but yes, every inline comment = new email
[12:21] <wallyworld> jam: perrito666: there will be 30 minute's notice, so land away till then
[12:21] <wallyworld> a few prereq things are being finalised
[12:22] <perrito666> jam: you mean why I actually look for localhost in the test?
[12:23] <jam> perrito666: 		if strings.HasPrefix(addr, "localhost:") {
[12:23] <jam> <IP_ADDRESS> is *also* localhost
[12:23] <jam> as is ::1
[12:23] <jam> as is the actual public IP of the local machine
[12:25] <mgz> pre-forward notice, bzr landings will be stopping today
[12:25] <mgz> be aware if you have a branch currently up for review
[12:29] <perrito666> jam: well we are trying to force it to go trough localhost, if the list already has <IP_ADDRESS> we should do no harm
[12:30] <jam> perrito666: well, 127 is pretty specific (vs 123 :)
[12:30] <perrito666> jam: oh
[12:30] <jam> mgz: you could do something evil and commit a change to 'lp:juju-core' that just always breaks the test suite :)
[12:30]  * perrito666 moves the irc to the screen with a reazonable resolution
[12:31] <jam> well, actually, just change go-bot to run "&& false"
[12:31] <jam> mgz: then the MP's get rejected
[12:31] <jam> echo "no longer merging on launchpad
[12:31] <mgz> jam, I think I just take the lock when ready
[12:31] <jam> " && falsee
[12:31] <jam> mgz: well, I mean someone submits, have them get the "not here" feedback
[12:31] <jam> so leave tarmac running, just have it running and rejecting all requests.
[13:09] <voidspace> natefinch: ok, if you can get those instructions I'll try it out
[13:13] <natefinch> looking
[13:13] <bodie_> morning all
[13:13] <perrito666> bodie_: hi
[13:32] <voidspace> natefinch: any luck?
[13:32] <voidspace> natefinch: we could land it - it if it doesn't fix the problem we'll be reverting the lot anyway
[13:33] <alexisb> natefinch, ping
[13:34] <wwitzel3> fwereade: https://codereview.appspot.com/103770044/
[13:35] <frankban> mgz: is it ok to start working on the git project, or do we need to wait until the migration is done?
[13:36] <alexisb> natefinch, cloudbase call
[13:44] <mgz> frankban: you need to wait
[13:44] <mgz> but please feel free to try out the test repo
[13:45] <rogpeppe1> mgz: are changes to launchpad.net/juju-core frozen?
[13:45] <mgz> you'll just need to patch any changes you want to keep onto the new one when it's out
[13:45] <wwitzel3> mgz: did you pull the trigger on disabling lp?
[13:45] <mgz> just about to
[13:46] <perrito666> mgz: good luck
[13:47] <mgz> test git landing disabled
[13:49] <fwereade> wwitzel3, might not get to that for a bit today
[13:49] <sinzui> jam: the job doesn't set GOROOT. The test is very bare in fact. It sets GOPATH just before it calls make.  I add GOROOT. Or maybe this bytes issue with trusty packaging problem
[13:49] <wwitzel3> fwereade: sure, np :)
[13:50] <fwereade> wwitzel3, encourage cmars to take a look now; wallyworld or I will surely take a look tonight/tomorrow though
[13:51]  * cmars takes a look
[13:51]  * wallyworld will look tomorrow
[13:52] <natefinch> alexisb: crap, sorry, I thought that was Wednesday... got pulled away from my desk for a while
[13:53] <wwitzel3> fwereade: I am moving it to GH anyway, so will ping people with the new review, thanks
[13:53] <alexisb> natefinch, no worries
[13:53] <alexisb> we are still on
[13:53] <natefinch> alexisb: jumping on
[13:55] <alexisb> hi  gsamfira and alexpilotti
[13:55] <alexisb> kadams54, hi
[13:55] <bodie_> looking for some guidance serializing this map[interface{}]interface{} -- I know that the values are either lists, maps, or other things that are OK.  if the values are maps, I know that the keys will be strings
[13:55] <bodie_> however, bson is grumpy because it doesn't know that the keys will be strings, it sees interface{}s
[13:55] <kadams54> alexisb: hi!
[13:56] <bodie_> o/
[13:57] <bodie_> I'm thinking the right answer is to recurse on a type switch and then serialize leaves to bson
[13:57] <bodie_> but not totally sure and want to get some confirmation
[13:57] <bodie_> also, there could potentially be maps or lists as values inside lists, I suppose, I mean it's just JSON so I don't know why it doesn't want to play nice
[13:58] <bodie_> I deserialized into the datastructure using goyaml and I think that might be the issue
[13:58] <voidspace> natefinch: perrito666: wwitzel3: I assume we're delaying standup until natefinch is free
[13:59] <perrito666> voidspace: ok by me
[13:59] <alexisb> hi trobert2
[13:59] <natefinch> voidspace: free now
[13:59] <voidspace> cool
[13:59] <alexisb> trobert2, if you have specific questions regarding unit tests this would be a good place to ask them
[14:00] <alexisb> I am sure that natefinch and team would be willing get you pointed in the right direction
[14:10] <wwitzel3> how do I get bzr to produce a patch with bzr diff so I can apply it to my gh branch? .. bzr diff --old co:trunk isn't doing anything useful
[14:11] <voidspace> wwitzel3: create a merge proposal on launchpad and download the diff :-)
[14:11] <wwitzel3> voidspace: hah, good point
[14:13] <natefinch> ug, stupid hangouts crashed, brb
[14:15] <jam1> voidspace: wwitzel3: bzr diff -r ancestor:trunk
[14:15] <jam1> or bzr diff -r submit: if you have that configured
[14:15] <mgz> starting the bzr import
[14:15] <jam1> cd ../trunk
[14:15] <jam1> bzr merge —preview $MYBRANCH; is the contents of the launchpad MP
[14:15] <mgz> wwitzel3: my email should have included a working command
[14:16] <mgz> ..at least for the pople who use my way, I forgot to mention that cobzr people need to work out how to address trunk themselves
[14:21] <trobert2> ok. thank you very much guys :)
[14:22] <wwitzel3> mgz: yeah, downloading the diff from lp worked out well enough :)
[14:23] <wwitzel3> mgz: also, I hadn't seen your email yet. It would of also solved it for me.
[14:26] <mgz> jenkins job cloned and updated
[14:27] <alexisb> mgz, I will be a few minutes late to our 1x1, will ping you when I am back at the keyboard
[14:27] <mgz> I'm so tempted to make the github description `juju is`
[14:29] <mgz> alexisb: no problem
[14:29] <mgz> first revs pushed, everyone please still wait before poking
[14:30] <mgz> I'll send an all clear when I'm done
[14:30] <wwitzel3> so I should stop my automated poking script?
[14:30]  * wwitzel3 kicks the dirt
[14:30] <mgz> :D
[14:31]  * bodie_ pokes wwitzel3
[14:38] <perrito666> wwitzel3: if you need a hand with what you are doing poke me, I might be of help there
[14:42] <mgz> import changes thus far, a little oddness, some files have been resurrected, including some testing charm bits: http://paste.ubuntu.com/7580793
[14:44] <natefinch> mgz: nice work
[14:45] <natefinch> mgz: odd that some things are getting resurrected.... do you think it's just a buggy import?  (I presume you're using some bzr to git importer)
[14:45] <mgz> yeah, just some import oddness I presume
[14:45] <mgz> seems limited from eyeballing that
[14:47] <natefinch> we're gonna have to update the readme
[14:47] <mgz> yeah, I have various modifications to land befre this is live
[14:47] <natefinch> cool
[14:47]  * natefinch will stop bugging the person actually getting the work done.
[14:48] <trobert2> Hey guys, I have a question: anyone know how to expand a short path? ex: "C:\\Users\\ADMINI~1" to "C:\\Users\\Administrator\\"
[14:49] <natefinch> trobert2: http://msdn.microsoft.com/en-us/library/windows/desktop/aa364980(v=vs.85).aspx
[14:50] <natefinch> trobert2: which it looks like is in windows' syscall library
[14:52] <natefinch> trobert2: do you know about running godoc locally so you can see the windows version of the syscall package?
[14:56] <trobert2> no, I do not
[14:57] <trobert2> I`ll give syscall.toLong a try. Thanks for the response
[14:58] <natefinch> trobert2: oh, wow, glad I thought to ask.  depending on how you installed Go, you should have an executable called godoc, which you can run to get a copy of the docs that exist at golang.org.  run godoc -http=:8080  and then you can open a browser to localhost:8080/pkg to see the docs for all packages on your system, including the standard library... which is the only way to see the windows version of the syscall package (
[14:58] <natefinch> since it is OS specific)
[14:59] <natefinch> trobert2: it should be syscall.GetLongPathName ... toLong is a private function that you won't be able to reference (note the lowercase first letter)
[15:00] <natefinch> trobert2: but you can use toLong as a guide for how to call GetLongPathName
[15:01] <natefinch> trobert2: it's probably good to just copy toLong entirely to your own package
[15:04] <trobert2> natefinch: thank you. Having the docs locally will be quite helpful
[15:05] <natefinch> trobert2: welcome.  Hugely important when doing windows work, since the windows syscall stuff isn't on golang.org  (I really wish they'd put the non-linux syscall docs online... I realize why they're not on the default doc site, because Google isn't running Windows or OSX, but still....)
[15:05] <mgz> seriously?
[15:05] <mgz> I appear to have screwd the repo already somehow
[15:05] <natefinch> lol
[15:06] <natefinch> just rebase
[15:06] <natefinch> ;)
[15:06] <perrito666> mgz: you are a fast kid
[15:06] <natefinch> that's the git way, right?
[15:06] <mgz> as in, I have a corrupt pack
[15:23] <mgz> github trunk should be ready for forking
[15:24] <mgz> doing test merge
[15:24] <mgz> I'll send a note to the list when things are actually confirmed usable, but the adventurous can start experimenting now
[15:26] <mgz> ...I've confused github about who's the bot and who is me
[15:28] <sinzui> mgz :)
[15:28] <sinzui> mgz, do you bleed?
[15:28] <mgz> maybe I should have used a mailinator account
[15:28] <sinzui> oh, hay, I don't think I closed the bugs, or...I forgot to be the juju-qa-bot
[15:29] <mgz> everyone: can I have a review? github.com/juju/juju/pull/1
[15:32] <mgz> sinzui: have you got an alt caonical email address I can use for the bot?
[15:32] <mgz> I want to reclaim mine for my github account
[15:32] <sinzui> hmm
[15:33] <mgz> something like<EMAIL_ADDRESS>would be grand, but that means talking to IS...
[15:33] <mgz> sod it
[15:33] <sinzui> mgz, I don't, but the bots abentley created alway have + in the user
[15:33] <mgz> cunning
[15:33] <sinzui> mgz https://launchpad.net/~juju-qa-bot
[15:34] <sinzui> bugger, I did forget to be the bot. sorry jam
[15:35]  * sinzui updated the release log to ensure the bot credentials are passed
[15:36] <mgz> perrito666: can you review my branch plz?
[15:38] <sinzui> mgz, will you be adding a 1.18 branch? I tagged the Lp branch a few hours ago, but postponed the 1.18.5 increment until github was ready
[15:38] <mgz> nope
[15:38] <mgz> I wasn't planning on it
[15:38] <mgz> I left the bzr bits up for 1.18 for now
[15:39] <sinzui> mgz, oh, that is right, 1.18 doesn't to to github. 1.20 will be the first stable in github
[15:39] <mgz> keeping it like that would make backports more annoying, but importing multiple branches with fastimport is kinda borked
[15:40] <sinzui> mgz, fast export to fast import? Does that preserve tags?
[15:40] <perrito666> mgz: diff says much more than your merge proposal comment :p
[15:40] <sinzui> I guess not
[15:44] <perrito666> mgz: reviewed
[15:45] <jam1> mgz: sinzui: worse case it generates a mapping and we should be able to find the tags, but I think it does at least try to tag revs
[15:45] <jam1> mgz: if we don't have the release tags, can you make sure to get them put in manually?
[15:46] <jam1> I feel it is important to keep them
[15:46] <sinzui> +1. I was going to add them once mgz frees his identity from the bot
[15:47] <mgz> jam, hm, urk, the instructions I was following stripped varioius things
[15:47] <mgz> but retagging should be fine, right?
[15:47] <jam1> mgz: stripping revs makes me pretty sad
[15:48] <mgz> the revs should all be there, plus or minus weirdness, of which there was some
[15:48] <jam1> mgz: as long as you can match the contents, we can do new tags
[15:48] <mgz> but I didn't generate a marks file or anything
[15:48] <jam1> I don't really want to have "the mainline commit that sort of looks something like 1.18.1"
[15:48] <jam1> I really want us to have the "tree that was released as 1.18.1"
[15:48] <mgz> jam1: I don't see a way around it for old minor versions,
[15:48] <jam1> mgz: create them
[15:48] <sinzui> perrito666, do you have a minute to review https://codereview.appspot.com/93710043
[15:49] <jam1> mgz: these are actually precious artifacts, we *can* go back to the bzr codebase, but that gets pretty clumsy
[15:50] <jam1> mgz: but really, why would we chose a lossy conversion?
[15:50] <sinzui> jam1, mgz, we don't have stable tags in th lp's trunk aka git's master. If we want the stable tags, we need to recreate the stable branches
[15:50]  * jam1 goes off for a while
[15:51]  * perrito666 isnot sure if lgtm sinzui 's version number changes after seeing how they break builds :p
[15:52] <perrito666> sinzui: done
[15:52] <sinzui> perrito666, good point. 1.18 doesn't have a "var switchOverVersion = MustParse("1.19.9")"
[15:53] <sinzui> perrito666, ^ that number was set to 1.19.3 in devel, telling juju to reject 1.19.4 as a devel lrease
[15:53] <perrito666> yeah, I thought that as long as we dont get near 1.19 its all fine :)
[15:53] <perrito666> mgz: jujubot has your face as avatar that is mildly disturbing
[15:53] <mgz> perrito666: it is.
[15:54] <mgz> I am trying to fix that by getting a new account from IS
[15:56] <perrito666> there is certain dr who sense in the fact that our bot is a british man with a canonical logo for a face
[15:57] <natefinch> haha
[15:58] <sinzui> yeah, the flat colour looks like the logo from the 4th Doctor era
[15:58] <natefinch> github.com/juju/juju builds for me after running godeps -u dependencies.tsv
[15:58] <natefinch> nice work everyone
[16:00] <mgz> evil time coming
[16:00] <mgz> ...actually, I won't be evil.
[16:01] <natefinch> anyone opposed to making the readme markdown?
[16:01] <perrito666> natefinch: not at all
[16:01] <voidspace> wow, 20:54 minutes to scp a juju tarball to the CI machine
[16:01] <mgz> natefinch: see the pending merge proposal
[16:02] <natefinch> mgz: you mean the pull request? ;)
[16:02] <mgz> watevar
[16:02] <natefinch> :D
[16:03] <perrito666> voidspace: welcome to southamerica (?)
[16:03] <voidspace> perrito666: hehe
[16:03] <voidspace> perrito666: or rural England
[16:04] <voidspace> natefinch: sinzui: so logged into CI machine as jenkins and running the juju that CI did, a local bootstrap fails
[16:04] <voidspace> natefinch: sinzui: a local build that I scp'd up (as ubuntu user) succeeds
[16:04] <sinzui> hmm
[16:04] <voidspace> natefinch: sinzui: that one refreshes the session before asking for status
[16:04] <voidspace> sinzui: that's with changes
[16:04] <natefinch> oooh
[16:05] <sinzui> voidspace, very intersting
[16:05] <voidspace> sinzui: natefinch: that Refresh is to avoid the "Closed explicitly" problem
[16:05] <natefinch> I hope that means it's fixed, not just that where it's built matters
[16:05] <voidspace> natefinch: well, yes
[16:05] <voidspace> sinzui: natefinch: so current hypothesis is that this "fix" is worth landing and trying
[16:05] <sinzui> voidspace, We know that jenkins strips the env of personal var that we often assume to be there
[16:06] <sinzui> voidspace, oh, I misunderstood, please land.
[16:06] <voidspace> sinzui: natefinch: if it doesn't *actually* fix the problem then we will revert the changes that caused this and workaround it some other way to achieve what we want
[16:06] <voidspace> so one way or another it will be the end of it
[16:06] <voidspace> (well, of this particular problem)
[16:06] <sinzui> voidspace, We explicitly define USER=jenkins in the local tests because that var was stripped by jenkins. if local tests, juju, mongo need a missing var, I need to find it and put it back
[16:07] <voidspace> right
[16:07] <voidspace> ok, so now all I need to do is work out how to land a branch in the new wild and wonderful world of git
[16:07] <natefinch> haha
[16:07] <voidspace> which can mean only one thing
[16:07] <voidspace> it's time for more coffee
[16:08] <natefinch> voidspace: http://blog.natefinch.com/2014/03/go-and-github.html
[16:08] <natefinch> (and anyone else)
[16:10] <perrito666> natefinch: thank you
[16:10] <jcw4> natefinch: great tip, thanks!
[16:10] <perrito666> although we should all use the doc on the repo, so we have better chances of finding errors
[16:11] <sinzui> Anyone have an idea why the ppc64el (ggcgo) doesn't have anything like "go/src/pkg" installed. It may have been, but was removed?  I cannot think os a reason why not
[16:29] <mgz> hopefully that's the last of the fallout from the name change
[16:30] <mgz> sinzui: please do, I did master as I need that for a clean run
[16:30] <sinzui> We still need to tell CI to poll the git branch for changes
[16:30] <mgz> I do that
[16:30] <mgz> it's in the ubuntu user's crontab, which is I'm not sure how you want it
[16:31] <mgz> I also need to write all the pokings I did on the jenkins machine in your doc
[16:31] <mgz> or you mean for the other jobs?
[16:35] <sinzui> mgz, jenkins has a crontab that lists the branches to check. abentley or I will change it shortly. I am kicking the stable 1.18.5 test run to complete
[16:36] <abentley> sinzui: I was off IRC for a bit.  Missing context.
[16:36] <sinzui> mgz, The publish step is too brittle now that it it builds a lot and publishes even more.  We want to replace lp:juju-core with "gitbranch:master:github.com/juju/juju" I think
[16:37]  * sinzui typed that from memory
[16:37] <abentley> sinzui: Yes, I agree.
[16:40] <abentley> sinzui: I want to run it by hand first, but we won't see the full effect until these tests are done: publish-revision, run-unit-tests-precise-amd64, run-unit-tests-trusty-amd64, walk-unit-tests-amd64-trusty
[16:40] <mgz> okay, all done but the waiting
[16:40] <mgz> actually, checklist
[16:40] <sinzui> abentley, +1
[16:41] <sinzui> abentley, mgz, it would be nice to pick a known good revision, but trunk has been broken for 9 days
[16:42] <natefinch> switching version control providers while the tests were passing would have been too boring
[16:43] <sinzui> :)
[16:43] <sinzui> natefinch, the brittle publish step always adds a risk to every test
[16:44] <natefinch> that just makes it more exciting
[16:44] <sinzui> abentley, do you have a few minutes to discuss a revised process to run unit tests, build, and publish
[16:44] <abentley> sinzui: sure thing.
[16:45] <sinzui> abentley, https://plus.google.com/hangouts/_/calendar/Y3VydGlzQGNhbm9uaWNhbC5jb20.lmdv7d975raqphi9pf38tm7juo?authuser=1
[16:47] <abentley> sinzui: I am in the hangout, but I don't see you.
[16:47] <sinzui> oh so am i
[16:54] <perrito666> mgz: natefinch do any of you know where "check" is?
[16:54] <rogpeppe> perrito666: "check" ?
[16:55] <perrito666> rogpeppe: in the goint go git docs there is a reference to
[16:55] <perrito666> ln -s ../../check .git/hooks/pre-push
[16:55] <mgz> perrito666: it got moved, the new contributing has the updated location
[16:55] <perrito666> mgz: did that got merged?
[16:55] <rogpeppe> perrito666: it's probably renamed from lbox.check
[16:58] <mgz> perrito666: it's being chewed on
[16:58]  * perrito666 does coffee to ease the wait
[16:58] <mgz> we have issues with tests witch -p > 1
[17:09] <voidspace> mgz: I have a branch with a 1 line change in it
[17:09] <voidspace> mgz: bzr diff -rancestor:co:trunk > ~/initiate-refresh.patch
[17:09] <voidspace> mgz: produces a 27k patch file
[17:09] <voidspace> mgz: my bazaar branch has trunk merged into it, so it's up to date
[17:10] <mgz> odd
[17:10] <perrito666> voidspace: bzr diff between your commit and the previous one
[17:10] <voidspace> that's what I thought :-)
[17:10] <perrito666> I had to do that
[17:10] <voidspace> perrito666: ok
[17:10] <perrito666> bzr diff between my branch and trunk produced a very verbose thing
[17:11] <mgz> I might have the spelling wrong, what did jam say earlier...
[17:11] <mgz> (worked for the branches I tested though...)
[17:12] <mgz> hm, jam said the same
[17:14] <perrito666> mgz: the same?
[17:14] <mgz> merge -r ancestor:trunk
[17:15] <voidspace> picking the specific revision worked fine
[17:22] <voidspace> sooo, I created a branch added-committed-pushed (origin master)
[17:22] <voidspace> I can't see my branch on github though
[17:22] <voidspace> https://github.com/voidspace/juju/branches
[17:23] <voidspace> hmmm... although: https://github.com/voidspace/juju/tree/initiate-refresh
[17:23] <voidspace> but "This branch is 0 commits ahead and 0 commits behind master"
[17:24] <Egoist> Hello
[17:24] <Egoist> I have to instances and want to connect them. The problem is that first instance want to connect with second but second has not finished configuration so refsed connection, and by that i have Error in *-relation-changed hook
[17:24] <mgz> sinzui: can you keep an eye on github-merge-juju? we're still not having miuch joy with these tests
[17:24] <Egoist> someone know how to handle with this?
[17:25] <natefinch> marcoceppi: ^^
[17:25] <sinzui> mgz I wish
[17:25] <sinzui> mhgz, I will
[17:25] <voidspace> ah, I pushed to the wrong branch it seems
[17:25] <marcoceppi> Egoist: is it configuring in the background?
[17:26] <marcoceppi> Egoist: how is it not finished configuring?
[17:26] <voidspace> natefinch: https://github.com/juju/juju/pull/3
[17:26] <natefinch> voidspace: looking
[17:27] <natefinch> haha contributing still mentions cobzr
[17:27] <voidspace> yeah, I just saw that
[17:27] <perrito666> natefinch: https://github.com/bz2/core/blob/contributing_updates/CONTRIBUTING
[17:27] <perrito666> slightly newer
[17:27] <voidspace> the repo names have been updated though
[17:28] <perrito666> so, so, juju/juju or juju/core, I am not sure what did we settle with
[17:28] <natefinch> juju/juju is where stuff it
[17:28] <marcoceppi> \o.
[17:28] <natefinch> s/is/it/
[17:28] <marcoceppi> \o/*
[17:28] <marcoceppi> juju/juju makes much more sense, think of those who clone something, suddenly what is marcoceppi/core ?
[17:28] <natefinch> exactly what I said
[17:29] <natefinch> the other option was juju/juju-core .... but the argument there is that we only called it juju-core before because on launchpad, juju was taken by pyjuju
[17:29] <marcoceppi> natefinch: we're going to be moving juju/docs to juju/juju-docs soon as well
[17:29] <natefinch> marcoceppi: that's good.  It's good to have the repo names able to stand on their own
[17:30] <bodie_> YES!  got my funky nested map[interface{}]'s coerced properly
[17:30] <bodie_> if this doesn't fix the bson marshaling issue around that, i'll be a monkey's uncle
[17:30] <natefinch> mgz, sinzui: where's the new contributing doc for how we work this thing?  Is there a formal "Approve this PR"? Or is it more informal?
[17:31] <natefinch> bodie_: awesome
[17:32] <natefinch> oh, I missed perrito666
[17:32] <natefinch> 's link
[17:32] <sinzui> natefinch, sorry. I don't know that yet
[17:33] <natefinch> Sounds like informal, which is fine.  It was effectively the same thing before.
[17:33] <perrito666> natefinch: that has been approved for landing
[17:33] <voidspace> natefinch:
[17:33] <voidspace> After a proposal has recieved an LGTM, the landing must be notified to test and merge
[17:33] <voidspace> the code into master. This is done by a member of the juju project adding the magic
[17:33] <voidspace> string $$merge$$ in a comment.
[17:33] <perrito666> but mgz-faced bot is not being able to merge it
[17:34] <voidspace> natefinch: cool, I have to EOD
[17:34] <voidspace> natefinch: hopefully this lands and hopefully it fixes the build :-)
[17:34] <natefinch> voidspace: np.  Good work on that.
[17:34] <voidspace> if not, tomorrow is the big revert day :-(
[17:34] <voidspace> heh
[17:34] <voidspace> we'll see
[17:34] <voidspace> g'night
[17:34] <natefinch> I'm optimistic
[17:34] <natefinch> see ya
[17:35] <perrito666> mm, reverting something merged with bzr in git, that should be somehow fun
[17:36] <natefinch> I think the commits are all there, so it's just a matter of pretending they were always in git.
[17:37] <perrito666> natefinch: nice
[17:40] <rogpeppe> g'night all
[17:41] <perrito666> rogpeppe: o/
[17:48] <bodie_> I'm getting thrown off by state/conn_test.go line 74 AddTestingCharm
[17:49] <bodie_> it's in the state package, yet it calls state.AddTestingCharm with additional arguments
[17:49] <bodie_> the only other AddTestingCharm definition I see is in juju/testing/conn.go
[17:49] <bodie_> and its arity doesn't match, either
[17:50] <bodie_> does anyone know where to track that down?  I must not be grepping just right
[17:50] <bodie_> er, it's in the state_test package
[17:51] <natefinch> that's the thing
[17:51] <natefinch> state_test is a different package
[17:51] <natefinch> so in order to call AddTestingCharm, it has to qualify it by the package name
[17:51] <bodie_> here we go
[17:51] <bodie_> found it
[17:51] <bodie_> yeah, I think I got thrown off since I somehow forgot I was in the testing package :)
[17:51] <bodie_> s/testing/state_test
[17:53] <natefinch> yeah, it can be a little confusing, especially since that's the only time you can be in the same directory, but a different package
[18:01] <natefinch> man, I wish env would sort alphabetically
[18:37] <natefinch> mgz: why do we tell people to do go get -v?
[18:37] <perrito666> ouch, I forgot a dentist appointment
[18:37] <natefinch> oops
[18:38]  * perrito666 runs
[18:38] <perrito666> Ill ba back later most likely
[18:38] <perrito666> I also got my git juju working, altough I am not sure what is the new name for check
[18:39] <natefinch> perrito666: I'll see if I can figure it out
[18:39] <perrito666> well, contributing/readme patch just landed
[18:39] <perrito666> so perhaps docs are fixed
[18:39] <natefinch> they look much improved
[18:39]  * perrito666 maps the dentist office and notices it is perhaps the hardest place to get in driving in the universe...
[18:40] <natefinch> doh
[18:41] <perrito666> well I better run then, let me know if you find out what the name of check is :)
[18:41] <perrito666> cheers guys
[18:49] <natefinch> such a beautiful URL  https://canonicalhr--fhcm2.eu2.visual.force.com/apex/fHCM2__FairsailProfile
[18:55] <mgz> woho! landed.
[18:55] <mgz> I'll send email a bit later, but consider the git repo live
[18:55] <natefinch> yay!
[18:55] <sinzui> mgz, Did you add a rule to try -p 1 when the first effort fails?
[18:56] <mgz> I made it just use -p1 twice in the end, it's the only one that seems to reliably work
[18:56] <sinzui> and you select xlarge too
[18:56] <sinzui> this is very worying
[18:57] <mgz> I think we just use a smaller machine for now as well, it's not like we're getting benefit from extra cores...
[18:57] <sinzui> mgz, I am building slaves next week. think about the resources you need. I may be able to provide a dedicated slave for gobot
[18:58] <sinzui> mgz, those tests do make a difference to the test suite
[18:58] <sinzui> the cores are used
[18:58] <mgz> sinzui: ace, thanks
[18:58] <mgz> sinzui: they would be for -p > 1 much better...
[19:05] <abentley> sinzui: I have tried building the git branch, but so far, breakage: http://juju-ci.vapour.ws:8080/job/build-revision/1436/console
[19:13] <natefinch> what's wrong with git clone https://github.com/juju/juju  ?
[19:15] <natefinch> abentley, sinzui: ^^
[19:16] <abentley> natefinch: That is too vague.
[19:16] <jcw4> natefinch: works for me?
[19:16] <natefinch> abentley: eh?
[19:17] <abentley> natefinch: We want a specific tree, not whatever happens to be the tip revision.
[19:17] <natefinch> abentley: that'll get the master branch
[19:17] <natefinch> or rather, whatever is defined as the default branch, which is currently master
[19:17] <abentley> natefinch: Right.
[19:17] <jcw4> natefinch: n/m misunderstood your comment :-)
[19:18] <natefinch> which is what gitbranch:master seems to indicate you want?
[19:20] <abentley> natefinch: We don't want something that always grabs master.  We want something that grabs what we tell it to grab.
[19:24] <natefinch> abentley: ok, sorry, I was just looking at what that code seemd to be doing.  Stack Overflow says to do this:
[19:24] <natefinch> git init
[19:24] <natefinch> git remote add -t $BRANCH -f origin https://github.com/juju/juju
[19:24] <natefinch> git checkout $BRANCH
[19:26] <natefinch> the wacky stuff in the middle is to prevent git from getting the whole repo.... which I presume is what we want. Otherwise you can just do
[19:26] <natefinch> git clone https://github.com/juju/juju && git checkout $BRANCH
[19:26] <natefinch> (clone gets all branches in the repo)
[19:29] <natefinch> this also seems to work:   git clone -b $branch https://github.com/juju/juju
[19:30] <abentley> natefinch: Good to know how to avoid retrieving other junk.  But we're fine with doing a clone for now.
[19:34] <bodie_> I'm not totally following this bit -- $ ln -s ../../scripts/pre-push.bash .git/hooks/pre-push
[19:34] <bodie_> where's that assuming your working directory is?
[19:34] <natefinch> relative directories are never a good idea in instructions
[19:36] <natefinch> bodie_: I have no idea where it expects you'll be when you run that command.
[19:36] <bodie_> also, I'm assuming none of our bzr branches and such have been preserved, so I need to push --force to a forked branch in my user account, right?
[19:37] <bodie_> if an email went out with all this info, I don't think I saw it -- did I miss that?
[19:37] <natefinch> bodie_: the email is still in the works
[19:38] <natefinch> bodie_: yes, none of the bzr branches will exist. You'll need to move your code over... I'm not sure exactly how to do that, honestly.
[19:38] <bodie_> I think forking it and pushing to our personal forks will suffice for now, but merging might get finicky, unless I'm not thinking through this clearly
[19:39] <bodie_> the way we worked at DigitalOcean was to push to user branches in the core repo, then open PR's against the branches rather than against user repos
[19:40] <abentley> sinzui: looks like the packaging is hardcoded for launchpad.net: http://juju-ci.vapour.ws:8080/job/publish-revision/454/console
[19:40] <sinzui> abentley, natefinch : the make-release-tarball script does something similar
[19:40] <abentley> sinzui: Yes, that's what I think we were discussing.
[19:40] <sinzui> abentley, natefinch : git clone $JUJU_CORE_REPO $WORK/src/$PACKAGE
[19:40] <sinzui>     if git ls-remote ./  | grep origin/$REVISION; then
[19:40] <sinzui>         git checkout origin/$REVISION
[19:40] <sinzui>     else
[19:40] <sinzui>         git checkout $REVISION
[19:40] <sinzui>     fi
[19:42] <natefinch> bodie_: any experience you can share with git/github would be much appreciated.  We're all pretty new to it (I have used github for personal projects quite a bit, but not for anything big)
[19:42] <bodie_> I'll see what I can dig out of my head -- personal forking and PR's are probably not a bad way to do it really
[19:43] <bodie_> there are a lot of ways to do it
[19:44] <bodie_> since we were on Github Enterprise w/ a private repo I think it was different since all users were easily able to have push access (although we didn't have push to master)
[19:47] <sinzui> abentley, I think a step got skipped, The script might be getting the wrong args
[19:47] <sinzui> abentley, https://code.launchpad.net/~sinzui/juju-release-tools/make-from-git/+merge/221307
[19:48] <sinzui> make-release-tarball.bash 0ededa1f3e7cd8a50f1c94f6abbb3355735069a6 https://github.com/juju/juju.git would be the expected args
[19:49] <sinzui> abentley, I will look into this when I get back from school
[19:49] <abentley> sinzui: I've fixed that issue already.  See http://juju-ci.vapour.ws:8080/job/build-revision/1440/console
[19:49] <bodie_> natefinch, if there's anything specific in question or that I can help with, feel free to grab my attention any time -- I'm probably not qualified to make positive claims about best practices though :)
[19:51] <natefinch> bodie_: haha, no problem.  I'm sure there will be things you know that we don't, and things none of us know. It'll be fun.
[19:52] <bodie_> I'm definitely a huge fan of it.  there are a couple of fundamental schools of thought.  I lean towards the "branch thoughtfully and prodigiously" school
[19:54] <bodie_> I like to have a master, a beta, a testing, and a dev branch, then user branches, and then grant push access on user branches; merge finished features to dev; merge finished dev sprints to testing; merge greenlit code to beta; merge major completed features to master
[19:54] <bodie_> then you don't have to worry about what's going into master
[19:55] <bodie_> but, most people just like to PR against master, I'm just kinda more process oriented
[19:56] <bodie_> if you're not comfortable with git the branching, rebasing, merging stuff can be kinda high drag / breakage prone
[19:56] <bodie_> so, I think most people don't like the branch heavy approach
[20:01] <natefinch> bodie_: the nice thing about forks is that you don't have to grant anyone access, they can just do it.  But yeah, might be the difference between enterprise and github proper
[20:01] <bodie_> right, but the question is kind of whether you want people opening PRs against master or, what branch
[20:11] <natefinch> bodie_: yeah.... my feeling is that eventually the code makes it into master anyway, and as long as tests and CI pass, go for it
[20:13] <menn0> waigani: ~\0/~
[20:14] <natefinch> I'm trying to decide if that's a guy shrugging, or a guy with really big shoulder pads.... probably neither
[20:14] <menn0> it's not great is it?
[20:15] <menn0> kinda looks like superman flying, head on
[20:15] <bodie_> natefinch, lol
[20:15] <menn0> officially it's: waving hello/goodbye
[20:16]  * natefinch is terrible at these things
[20:19] <bodie_> it's doing the sine dance
[20:19] <bodie_> :P
[20:33] <menn0> nice ;-]
[20:34] <mgz> I have made jumbalia and am watching irc again if people have migration issues
[20:35] <menn0> mgz: so far so good for me
[20:36] <menn0> is anyone having trouble with their canonical gmail? I've just been logged out and it's asking me for a password instead of 2FA...
[20:36] <menn0> nevermind
[20:36] <mgz> I always get asked, just leave blank and it forwards
[20:36] <alexisb> mgz, dude! what time is it for you?
[20:36] <mgz> 21:38
[20:37] <alexisb> mgz is getting sleepy ... ;)
[20:37] <menn0> mgz: I tried that first but I got "wrong username/password"
[20:37] <natefinch> omg, I want jambalaya
[20:38] <menn0> mgz: entering the token from my phone worked (even though it was asking for a password not a token, weird)
[20:56] <alexisb> alrighty all, I am off to town for some outreach work and won't be online again until tomorrow morning, if you need me urgently feel free to call my cell
[20:56] <natefinch> alexisb: have fun!
[21:36] <thumper> waigani, menn0: morning, care for a hangout to talk through the user display name work?
[21:37] <menn0> thumper: sure, give me 1 min
[21:38] <thumper> menn0, waigani: https://plus.google.com/hangouts/_/g5vgmsdpkfpsgdxsxsw3dbvfpqa?hl=en
[21:41] <sinzui> abentley, wallyworld, CI is broken because the source package branch (also under test) looks for launchpad.net/juju-core. the winbuildtest.py script does something similar
[21:41] <sinzui> I will fix them though I am a little tired. I wont rush
[21:42] <abentley> sinzui: Yes, I mentioned this two hours ago: " sinzui: looks like the packaging is hardcoded for launchpad.net: http://juju-ci.vapour.ws:8080/job/publish-revision/454/console"
[21:43] <sinzui> abentley, sorry I have been in meetings. I know how to do the fix.
[21:46] <abentley> sinzui: On a happier note, I have preliminary numbers for published revisions: https://chinstrap.canonical.com/~abentley/published-revisions.png
[21:47] <sinzui> lovely.
[21:47] <sinzui> thank you abentley
[21:48] <abentley> sinzui: win-client-build-installer also seems to depend on launchpad.net in the path.
[21:48] <sinzui> I am fixing that right now
[21:53] <bodie_> hmmmm.... I just noticed that I'm having dependency issues because all my deps are from juju/juju, but I've changed a bunch of files in my personal repo.
[21:54] <bodie_> so, I could go into my code and edit it to use my own deps
[21:54] <bodie_> but then if I merge that, Juju would be using my code as deps
[21:54] <bodie_> is there an established way to deal with this?
[21:55] <bodie_> it seems like this is a good argument against using user forks, but there is probably a way
[21:55] <bodie_> maybe we could have a script that symlinks github/juju/juju to the user's workspace
 voidspace: http://blog.natefinch.com/2014/03/go-and-github.html
 (and anyone else)
[21:55] <jcw4> bodie_: ^^^
[21:55] <bodie_> s/Juju would be using my code/Juju would be using my repositories/
[21:56] <bodie_> I don't think that answers the question, but I'll look again
[21:56] <bodie_> okay, so step 4 overwrites the local copy of the repository in-place
[21:56] <bodie_> that makes sense :)
[21:57] <jcw4> right, so you're using your repo, but at the gopath location for juju/juju
[21:58] <bodie_> I don't like that but it works
[22:00] <jcw4> there's a couple variations in the comments, but nate's original suggestion makes the most sense to me
[22:01] <bodie_> I guess the only alternative would be to symlink the repo to the user's repo
[22:01] <bodie_> or, the only one that comes to mind for m
[22:01] <bodie_> e
[22:02] <jcw4> A close contender for me was the suggestion in the comments to clone gh:juju/juju in the expected place and then add your personal repo as an upstream repo and then branch from there
[22:02] <jcw4> but I liked the simpler approach of just cloning your personal repo in the gh:juju/juju gopath location
[22:02] <jcw4> (and adding gh:juju/juju as an upstream repo)
[22:04] <perrito666> hello again everyone
[22:04] <bodie_> if anyone gets a chance (jcw4?) I could use a glance at https://github.com/binary132/juju branch charm-interface-actions
[22:04] <bodie_> not quite sure what's going on with my tests
[22:05] <bodie_> http://paste.ubuntu.com/7583269/
[22:07] <jcw4> bodie_: looks like you're getting a nil ActionSpec instead of an empty one...
[22:07] <bodie_> hm
[22:09] <jcw4> (technically its the map[string]charm.ActionSpec that's nil)
[22:09] <perrito666> bodie_: where exactly is that test?
[22:09] <jcw4> perrito666: state/state_test.go
[22:09] <jcw4> perrito666: in bodie_ 's branch
[22:10] <bodie_> https://github.com/binary132/juju/blob/charm-interface-actions/state/state_test.go#L2032
[22:16] <thumper> cmars: sorry for being late, can I put you off a day?
[22:16] <jcw4> bodie_: I think just checking for nil unmarshaledActions.ActionSpecs and assigning an empty map if its nil will get you past that error...
[22:17] <jcw4> bodie_: I assume we want to always return an empty ActionSpecs if the Charm doesn't declare one?
[22:19] <jcw4> bodie_: hmm, no - even with that check it's still getting the error.  Maybe the map isn't getting serialized to mongo, and then when it gets read back out it's nil?
[22:20] <bodie_> that's possible, yes
[22:25] <jcw4> bodie_: my hypothesis is that AddTestingCharm returns a Charm with an empty Actions, but when that same charm is read from mongo the Actions is nil
[22:26] <jcw4> bodie_: whether it's the Actions() or the Actions().ActionSpecs that is nil, I'm not sure... I think the latter actually
[22:26] <bodie_> hmm
[22:29] <jcw4> bodie_: no, AddTestingCharm returns the Charm *from* mongo after adding it
[22:30] <jcw4> bodie_: so you're getting a Charm with an empty charm.Actions().ActionSpecs when you initially add it, but then when you retrieve it the second time the charm2.Actions().ActionSpecs is nil
[22:31] <perrito666> aghh, my juju computer lacks all my github config
[22:32] <jcw4> bodie_: ahhh... no.  In your Assert on line 2032, you're putting the expected charm in the obtained spot
[22:32] <bodie_> am i?  *looks*
[22:32] <jcw4> bodie_: so the error message is backwards...
[22:33] <jcw4> bodie_: the Assert call expects the obtained result first, and the expected result later in the params list
[22:34] <jcw4> bodie_: so.. AddTestingCharm is returning a charm where Actions().ActionSpecs is nil
[22:34] <bodie_> I'm not certain about that, based on the previous check in that file
[22:35] <jcw4> bodie_: however the subsequent call to state.Charm() is returning a charm where Actions().ActionSpecs is empty
[22:36] <jcw4> bodie_: that's what the source for Assert says... gocheck/helpers.go:165
[22:36] <bodie_> okay, well that must be where we're seeing the problem
[22:36] <bodie_> wordpress is *supposed* to have an empty Actions
[22:37] <bodie_> I was thinking we should return Actions{} rather than Actions{ActionSpecs: Charm.ActionSpec{}}
[22:37] <bodie_> okay, I think I understand, thank you
[22:39] <bodie_> they're both using newCharm(st, cdoc)
[22:40] <bodie_> I suspect that since the Actions struct is empty it's simply omitting it from the document entirely
[22:40] <bodie_> whereas after the Insert, it's still just an empty Actions{}
[22:43] <jcw4> bodie_: I bet if we add a `yaml:",omitempty` to ActionSpecs it'll work as expected
[22:43] <jcw4> bodie_: testing....
[22:45] <bodie_> or maybe a bson
[22:45] <jcw4> bodie_: yeah, trying bson but that's just guessing on my part now
[22:47] <bodie_> I think perhaps omitempty is the opposite of what we want?
[22:47] <bodie_> or...
[22:47] <jcw4> bodie_: do we want nil or empty?
[22:47] <bodie_> well if we use omitempty I think it will omit the field from the doc
[22:47] <bodie_> therefore, when deserialized, will come back nil
[22:47] <bodie_> right?
[22:48] <jcw4> bodie_: hmm bson:",omitempty" made the test pass...
[22:48] <jcw4> bodie_: right
[22:48] <bodie_> okay, cool
[22:49] <bodie_> I'm still not fully getting the annotations
[22:49] <bodie_> what did you do with that?
[22:49] <bodie_> e.g. ActionSpecs map[string]ActionSpec `yaml:"actions"bson:",omitempty"
[22:52] <jcw4> bodie_: http://paste.ubuntu.com/7583486/
[22:52] <jcw4> bodie_: yeah, pretty close
[22:53] <bodie_> ah, I see
[22:55] <waigani> menn0: I think you just merged that branch by saying "$$merge$$"
[22:55] <waigani> menn0: maybe you just need to retry a few times
[22:58] <bodie_> now I'm getting this: http://paste.ubuntu.com/7583514/
[23:00] <thumper> wallyworld: ping?
[23:00] <jcw4> bodie_: hmm, do you have any orphaned mongo processes or some other environmental issues?
[23:00] <wallyworld> thumper: hiya
[23:00] <bodie_> I do have my own mongod running in the background -- I checked for that though.  maybe I'll have a sweep through /tmp
[23:00] <wallyworld> coming
[23:06] <bodie_> welp, I'm gonna have to set this down for tonight, hopefully a reboot will clear away the stormclouds ;)
[23:06] <jcw4> bodie_: o/
[23:08] <waigani> menn0: ping?
[23:19] <menn0> waigani: pong
[23:19] <waigani> menn0: ah, never mind. Dave turned up for standup.
[23:43]  * perrito666 makes a pr that is 10 times longer in description that the actual patch


[11:18] <ananta> Hey cjwatson I was trying to upload a package to launchpad but getting the issue: Rejected: Mismatch in binaryfulness. (arch) False != (files) True
[11:40] <cjwatson> ananta_: Possibly https://bugs.launchpad.net/launchpad/+bug/1699763?
[11:40] <cjwatson> (contains workarounds, if so)
[11:46] <ananta_> OK, Thanks for the reply cjwatson , I will try those fixes then.
[22:19] <RikMills> cjwatson or other LP admin: can you do anything with the riscv64 builders? they do not look happy
[23:21] <cjwatson> RikMills: My bad, I started reflashing them and got distracted.  Will try to make a bit more progress before bed


[08:38] <kraut> moin
[11:21] <BenC> Good morning kernel folks
[11:27] <cking> Morning BenC
[11:27] <amitk> Morning BenC
[12:06] <tjaalton> BenC: hey, could you drop the commit mentioned on bug 197929?
[12:06] <ubotu> Launchpad bug 197929 in linux "Backlight adjustment no longer works on Thinkpad X61s" [Medium,Triaged] https://launchpad.net/bugs/197929
[12:08] <BenC> tjaalton: We have a fix in git for that, I believe
[12:08] <tjaalton> BenC: oh cool
[12:09] <BenC> mjg59: The backlight patch you sent to kernel-team@ a few days ago, does it fix 197929?
[12:11] <mjg59> No
[12:12] <mjg59> Completey unrelated. The one mentioned in 197929 should be reverted.
[12:13] <BenC> mjg59: Ok, thanks
[13:16] <mjg59> BenC: Based on the comment that #201591 is causing freezes when changing to X, I think we want that for hardy
[13:29] <mjg59> BenC: If another l-u-m upload is going to happen, #147087 would be nice to fix instead of having to direct people to some wiki page
[13:32] <BenC> mjg59: 201591 is already milestoned for release
[13:32] <buttterz> morning
[13:33] <BenC> mjg59: Added 147087
[13:33] <mjg59> BenC: Thanks
[13:36] <BenC> amitk, smb: These are the bugs we should be looking at (filter to the ones assigned to kernel team) https://launchpad.net/ubuntu/+milestone/ubuntu-8.04
[13:37] <smb> BenC: ok
[13:40] <buttterz> hello, i am interested in helping on the kernel side of the house -- i'm new to ubuntu and have read some of your documentation concerning contributions -- any recommendations
[13:41] <BenC> buttterz: The URL I pasted above is most interesting at this point
[13:41] <buttterz> BenC , i figured as much :) so i was going to look into that anyways for giggles
[13:43] <BenC> hmm, I'm not sure what to do with this ralink driver problem
[13:44] <BenC> disabling the in-kernel drivers and moving the serial monkey stuff to lum seems like the right approach
[13:47] <buttterz> BenC , there has also been a few rumblings about wireless in +1
[13:47] <buttterz> i was considering looking into that today -- i'm off for the week so i have some time
[13:48] <BenC> in +1?
[13:48] <buttterz> the testing channel
[13:48] <buttterz> for heron
[14:55] <tjaalton> hmm, something between -8 -> -10 broke hibernate on thinkpad X61, the laptop is not powered off
[14:58] <buttterz> tjaalton , i heard that too -- my buddy has been working on that because he has one i have a toughbook though so its not been an issue
[14:59] <tjaalton> buttterz: cool.. the hibernation itself works, ie. it resumes correctly etc
[14:59] <buttterz> but you are referring to the physical state of the machine correct?
[15:00] <tjaalton> yes
[15:01] <mjg59> tjaalton: And it works if you revert to -8?
[15:01] <tjaalton> mjg59: yes. I wonder if the drm changes broke it
[15:02] <tjaalton> I don't have -9 around
[15:02] <mjg59> Hm. Possible. Easiest way to tell would be to move i915 out of the way
[15:02] <tjaalton> cool, I'll try
[15:02] <mjg59> X will start without it, and that avoids DRM being an issue
[15:08] <tjaalton> yep, that did it
[15:09] <mjg59> Ok, cool
[15:09] <mjg59> Can you boot with the kernel option no_console_suspend
[15:09] <mjg59> And without quiet
[15:10] <mjg59> And see whether you get any interesting kernel output when it hangs?
[15:10] <smb> BenC: call?
[15:11] <tjaalton> mjg59: sure, one sec
[15:18] <tjaalton> mjg59: 2x "[ xxx ] drm_sysfs_suspend" is all I see
[15:20] <tjaalton> hmm, seems that bug 197064 is related
[15:20] <ubotu> Launchpad bug 197064 in linux "Hibernate fails on Centrino-laptop" [Medium,Triaged] https://launchpad.net/bugs/197064
[15:29] <mjg59> tjaalton: Hm. Ok, interesting. Is the machine hard frozen at that point?
[15:30] <tjaalton> yep, feels like it
[15:31] <mjg59> tjaalton: Ah, hang on. Might have something
[15:31] <tjaalton> also, there's a patch upstream: http://lkml.org/lkml/2008/2/23/269
[15:31] <mjg59> Yeah, that's what I was just looking at
[15:33] <mjg59> Could you give it a go with that?
[15:33] <tjaalton> yeah, I'll build a new kernel from git
[15:33] <mjg59> Sweet
[15:34] <BenC> tjaalton, mjg59: if that works, I'll target it for release
[15:35] <johanbr> Is there any chance the one-line patch from bug #39414 could be applied? Without it, headsets will be unusable for many people.
[15:35] <ubotu> Launchpad bug 39414 in linux-source-2.6.15 "syslog is flooded with messages after connecting bluetooth usb dongle" [High,Fix released] https://launchpad.net/bugs/39414
[15:36] <BenC> johanbr: For dapper or hardy?
[15:36] <johanbr> Hardy.
[15:36] <alex_joni> sounds assigned wrong (2.6.15..)
[15:37] <BenC> johanbr: That patch looks a little scary
[15:37] <BenC> johanbr: Is that in upstream kernel?
[15:37] <johanbr> Really? It's just a one-liner that turns off eSCO.
[15:38] <BenC> johanbr: it hardcodes SCO_LINK for everything, which to me is pretty scary :)
[15:38] <johanbr> No, it's not upstream yet. Marcel Holtmann had a patch, but the fix is buggy. No proper fix exists.
[15:38] <BenC> if there isn't a proper fix, I don't want to apply one that may be buggier than the original code
[15:39] <mjg59> BenC: It's disabling a feature which is buggy
[15:39] <johanbr> Right now, SCO does not work at all when talking to devices without eSCO support. I can't see how the patch could be buggier than that.
[15:39] <BenC> mayeb I'd feel better if I knew the difference between SCO/ESCO
[15:39] <mjg59> So the choice is really whether we support the buggy feature, or disable it
[15:40] <BenC> do ESCO devices support being used as SCO-only?
[15:40] <johanbr> Basically, eSCO allows retransmission of lost packets.
[15:40] <mjg59> Yes, esco is supposed to be backwards compatible
[15:40] <BenC> ah, then that's less scary
[15:40] <johanbr> BenC: There is also another patch in the bug that reverts the state to exactly what was there before, if you prefer that.
[15:41] <BenC> the one-liner is preferred at this point (beta/release)
[15:41] <johanbr> See also http://bugzilla.kernel.org/show_bug.cgi?id=9871
[15:41] <ubotu> bugzilla.kernel.org bug 9871 in Network "hci0 SCO packet for unknown connection handle 1" [Normal,New]
[15:41] <BenC> marked for release now
[15:42] <johanbr> Wonderful. Thank you.
[15:54] <elmargol> Hi, BenC do you have a minute?
[15:55] <elmargol> You changes bug #183928 to fix commited... somehow I don't see how you fixed this :/
[15:55] <ubotu> Launchpad bug 183928 in network-manager "update iwlwifi to latest version" [Medium,Confirmed] https://launchpad.net/bugs/183928
[15:59] <BenC> elmargol: How do you now see how I updated iwlwifi to the latest version?
[15:59] <BenC> *not
[16:00] <elmargol> BenC: last version is from 03/11
[16:01] <BenC> elmargol: Latest iwlwifi is 1.2.25 from 02/04
[16:12] <BenC> amitk, cking, smb: ping
[16:12] <smb> BenC: ack
[16:15] <amitk> ack
[16:19] <BenC> Well, let's get started
[16:19] <smb> ok
[16:19] <BenC> Not much to discuss other than wanted to make sure we focus on release milestoned bugs at https://launchpad.net/ubuntu/+milestone/ubuntu-8.04
[16:21] <BenC> Final kernel upload is scheduled for 4-7/4-10, but I think we want to make sure to hit that on the early side (that's the latest)
[16:21] <BenC> smb, amitk: Anything you've come across that you think is extremely important for release?
[16:22] <BenC> mjg59: Same question for you ^^
[16:22] <mjg59> Nothing further I'm aware of
[16:22] <BenC> So far, all the bugs I've seen are "let's try to get it fixed for release", but none should really hold up the release
[16:22] <smb> BenC: Nothing in that category.
[16:22] <amitk> BenC: bug 197929, haven't had a chance to revert the patch though
[16:22] <ubotu> Launchpad bug 197929 in linux "Backlight adjustment no longer works on Thinkpad X61s" [Medium,Triaged] https://launchpad.net/bugs/197929
[16:23] <BenC> amitk: Right, that one is milestoned for release, so should be on the list
[16:24] <BenC> 197929 seems to be the most important
[16:24] <BenC> anyone had a chance to look at ralink wireless drivers yet?
[16:24] <smb> The fix (but thats sauce) to 140511 might be "nice to have" and it should not be intrusive
[16:24] <smb> no not yet
[16:25] <BenC> bug #140511
[16:25] <ubotu> Launchpad bug 140511 in linux "Belkin USB bluetooth device loads wrong module" [Medium,In progress] https://launchpad.net/bugs/140511
[16:26] <BenC> smb: If you think it's could be done for release, and is warranted, milestone it
[16:27] <smb> BenC: ok
[16:27] <BenC> Ok, anything else from anyone?
[16:29] <BenC> Great, thanks everyone
[18:58] <tjaalton> BenC, mjg59: the patch worked fine, my laptop powers down again when hibernating :)
[19:07] <tjaalton> I wanted to try the wlan-led patch as well, but that should be applied on top of lum?
[19:16] <mjg59> tjaalton: Sweet. Can you attach it to the bug if it's not there already?
[19:17] <tjaalton> mjg59: sure
[19:19] <mjg59> tjaalton: Winning, thanks
[19:21] <tjaalton> that commit was already mentioned, but it needs a patch to fix a compile error
[22:00] <JanC> hm, do I understand correctly that Ralink wireless is finally supposed to be fixed after 4 years ?  or will it only be "less bad" in hardy ?
[22:06] <buttterz> hey all, is there a real reason we don't supply seperatly patched kernels? say prepatches and andrew morton patches -- i know this is a release base OS but as an option?
[22:10] <adinc> is someone involved to the bug 185470 regarding the iwl3945 kernel module for intels wireless 3945 device ?
[22:10] <ubotu> Launchpad bug 185470 in linux "iwl3945 not functioning : microcode error" [Unknown,In progress] https://launchpad.net/bugs/185470
[22:12] <adinc> there are many some people using this device, specially with notebooks, since hardy comes with this kernel module and has problems with microcode SW error i would like to ask if this can be expected to be solved with the release of hardy?
[22:14] <tjaalton> adinc: you mentioned that you are willing to test any fixes if needed, so add those upstream patches to the current version and build it. the wiki-page has all the instructions
[22:14] <adinc> yes
[22:15] <adinc> i'm new to ubuntu, if you can point me to the said wiki page i can do the testing
[22:16] <adinc> and which patches are we talking about?
[22:16] <tjaalton> adinc: https://wiki.ubuntu.com/KernelTeam/GitKernelBuild
[22:16] <tjaalton> adinc: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/185470/comments/25
[22:16] <ubotu> Launchpad bug 185470 in linux "iwl3945 not functioning : microcode error" [Unknown,In progress]
[22:17] <adinc> tjaalton: i see, but i'm not familiar with the term upstream patch
[22:17] <tjaalton> adinc: ok, in that case just wait for someone to test it
[22:18] <adinc> tjaalton: but this can not be that complicated, aren't there patches available? applying the patches and compiling it is not that difficult
[22:19] <tjaalton> adinc: you'd need to dig them up from git.kernel.org
[22:19] <adinc> ok
[22:20] <adinc> with upstream patch, you were trying to say patches from the developer below ubuntu, the kernel patches
[22:20] <adinc> ok, thank you very much so far
[22:21] <tjaalton> ah, right


[12:33] <scout1340793703> ciao a tutti!!!!!!!!!!!!!!!!!
[20:23] <qwebirc94327> I was wanting to know if its possible to have the display coming from one graphics card and the sound from another. I have been trying to get it to work but with no luck. Before I try further I thought I might ask if its even possible with mythbuntu
[20:24] <qwebirc94327> The display is DVI monitor (HDCP compatible) connected to ATI card and I wanted the integrated nvidia card to provide the sound via hdmi
[20:24] <qwebirc94327> Is it theoretically possible? Or am  wasting my time?
[20:26] <rhpot1991> qwebirc94327: most likely depends on your tv/receiver
[20:26] <rhpot1991> and if it can take sound from one and video from another
[20:32] <qwebirc94327> I have a seperate receiver I'm using for surround sound. And I have a monitor connected for the picture.
[20:33] <qwebirc94327> The monitor only has DVI input. So is connected to ATI discrete graphics card
[20:33] <qwebirc94327> (HD6450)
[20:33] <qwebirc94327> the chipset of motherboard has 9400m integrated graphics with nvidia hdmi output
[20:34] <qwebirc94327> Having messed around with it for half a day I get the feeling that it is something to do with X
[20:34] <qwebirc94327> and the xorg.conf
[20:36] <rhpot1991> qwebirc94327: should be able to do your x out of the dvi
[20:36] <rhpot1991> and then in mythtv you'll need to setup the audio device
[20:36] <rhpot1991> and figure out which one corresponds with your onboard hdmi
[20:36] <rhpot1991> and just run your wires accordingly
[20:37] <rhpot1991> with hdmi you want to make sure the device isn't muted in alsa-mixer too
[20:39] <qwebirc94327> I can get a picture fine from the dvi (amd HD6450) connection
[20:39] <qwebirc94327> I can also get sound from the optical cable
[20:39] <qwebirc94327> in the alsa mixer everything is unmuted and turned high
[20:40] <qwebirc94327> I think it is something to do with the fact that the x server is running the fglrx driver. So even if nvidia,hdmi (hw0,3) is chosen in mythtv no sound comes outd
[20:41] <rhpot1991> ya not sure how ati sound works
[20:42] <qwebirc94327> How to enable fglrx and nvidia in xorg.conf? I think this will be the answer
[20:44] <qwebirc94327> If it is at all possible!
[20:44] <tgm4883> qwebirc94327, I've heard of people doing it
[20:44] <tgm4883> I've not done it though
[20:44] <rhpot1991> in theory is feasable
[20:44] <rhpot1991> your mixing of ati and nvidia is prob gonna be rough
[20:45] <qwebirc94327> yeah not good plan eh?
[20:46] <qwebirc94327> Well if you think its still possible I'm gonna keep trying. I refuse to resort to windows!
[20:48] <rhpot1991> qwebirc94327: I'd question why you are using ati at all
[20:48] <qwebirc94327> Been reading loads online and I think even mixing nvidia and ati in windows is causing people headaches
[20:49] <qwebirc94327> Is there anyway to seperate the nvidia audio drivers?


[02:32] <wallyworld> hpidcock: kelvinliu_: i wouldn't mind a chat about the jujud operator tag stuff if you have a moment
[02:33] <kelvinliu_> wallyworld: yep, im free
[02:33] <wallyworld> ok, we can jump in standup if harry is free also
[02:33] <hpidcock> yep
[02:34] <hpidcock> wallyworld: we are ready
[02:56] <thumper> hpidcock: what is in juju/cmd.v2 that differs from the v1 package?
[02:56] <thumper> can we not just make github.com/juju/cmd work for us?
[02:56] <hpidcock> thumper: https://github.com/juju/cmd/pull/63
[02:58] <thumper> why couldn't we do the change without an API break?
[02:58] <thumper> ... we don't need to talk in depth, I'm just curious
[02:58] <thumper> I don't want to waste your time
[02:59] <thumper> I guess the PR comment doesn't illustrate the benefits enough to me to grok the work
[03:00] <hpidcock> ahh right yeah, sorry about that, I'll try to add more detail in future. Essentially this is the first formatter that can take it's own arguments.
[03:01] <hpidcock> It was just a quality-of-life feature that wallyworld liked
[03:01] <hpidcock> but it's pretty useful for scripts using juju commands
[03:10] <thumper> I still don't get the use case
[12:46] <achilleasa> can I get a quick CR on https://github.com/juju/charm/pull/288?
[16:26] <stickupkid> rick_h, updated the offer pr https://github.com/juju/python-libjuju/pull/326
[16:29] <rick_h> stickupkid:  awesome