[00:05] <poolie> lifeless: i really think we need to work out what's happening with pqm runtimes?
[00:05] <poolie> :s/?//
[01:08] <mtaylor> hey all - I need some help with bzr internals...
[01:08] <mtaylor> I'm working on a post_push hook to send mail similar to a post_commit email
[01:09] <mtaylor> the problem I'm having is getting the approrpiate starting revision to send to log.show_log and show_diff_trees
[01:09] <lifeless> mtaylor: why not adapt the email plugin ?
[01:09] <mtaylor> lifeless: I did
[01:10] <lifeless> mtaylor: I'd be happy to review patches to make it do both/be configurable
[01:11] <mtaylor> lifeless: actually - I'd love to send in the patches... although I might have diverged a bit much at this point (need to go back and break things up into patches I can send in)
[01:11] <lifeless> mtaylor: there is result.old_revid and old_revno, and result.new_revid and new_revno
[01:11] <mtaylor> lifeless: if I remember correctly the problem I started out trying to solve, if I use result.old_revno, the log is one revision short
[01:13] <lifeless> mtaylor: so x..y is half open
[01:13] <lifeless> 0..1 includes 1 but not 0
[01:13] <mtaylor> yes
[01:14] <mtaylor> so that sent me down the trail of trying to find the -1 given 0
[01:14] <lifeless> mtaylor: do you want to show 0 tho  ?
[01:14] <mtaylor> yes
[01:14] <mtaylor> since it's the first rev that is being pushed
[01:15] <lifeless> mtaylor: no, its the first rev before what is being pushed
[01:15] <lifeless> mtaylor: I think you might be seeing left-hand-history pivoting
[01:15] <mtaylor> what's that?
[01:15] <lifeless> say your current master branch is ABC
[01:16] <lifeless> and your local branch is AD
[01:16] <lifeless> (D is local work)
[01:16] <lifeless> you can't push
[01:16] <lifeless> so you merge, getting
[01:16] <lifeless> ADE
[01:16] <lifeless> E is a merge of BC
[01:16] <lifeless> now when you push to the master branch the master becomes
[01:16] <lifeless> ADE
[01:16] <mtaylor> right
[01:16] <lifeless> and the old_revno == 3
[01:16] <lifeless> new_revno == 3
[01:17] <lifeless> because the old_revno is not the old revision number of the old revid in *your branch*, its the old revno of the old revid in the untouched target
[01:17] <mtaylor> ok. makes sense
[01:18] <lifeless> this is one of the reasons that I recommend centralised branches be mutated via checkouts rather than pushing
[01:18] <lifeless> because checkouts help manage the workflow to avoid this
[01:18] <lifeless> there is also a branch flag you can set to tell bzr to error if this would happen
[01:18] <lifeless> the left hand history is privileged in a number of ways, its what log --line shows
[01:19] <lifeless> its usually the representative list of 'what a project has merged'
[01:19] <mtaylor> so what I need in this case is really a pre-push hook that gathers info in the same way as bzr send does
[01:19] <lifeless> well, if you *want* such pivots in your workflow, yes.
[01:20] <lifeless> but anyhow - the first thing I would do is examine your test case to see if this is what is happening
[01:21] <mtaylor> bzr push -r50 /tmp/mysqltest
[01:21] <mtaylor>  bzr push -r52 /tmp/mysqltest
[01:21] <mtaylor> (I was backwards in what I said earlier)
[01:21] <mtaylor> that produced:
[01:22] <mtaylor> bzr push into plugins tree (mtaylor:50 to 52)
[01:22] <mtaylor> of course, what I was really pushing was 51 to 52
[01:22] <mtaylor> and in the log, I get 50 as well
[01:23] <mtaylor> doing log.show_log(self.branch, lf, verbose=True,direction='reverse',start_revision=self.old_revno,end_revision=self.new_revno)
[01:23] <lifeless> so
[01:24] <lifeless> sounds like something somewhere is not treating the interval as half_open correctly
[01:25] <mtaylor> what I did to try to work around it was:
[01:25] <mtaylor> new_graph = self.branch.repository.get_revision_graph(self.new_revid)
[01:25] <mtaylor> start_rev = get_parent(self.old_revid,self.new_revid,new_graph)
[01:26] <mtaylor> where get_parent was a recursive thing kept trying to walk the tree
[01:27] <mtaylor> but it seems really wrong (and the function breaks on some merges)
[01:28] <lifeless> mtaylor: just add one
[01:28] <lifeless> mtaylor: the docstring says clearly that its not a half open interval
[01:29] <mtaylor> wow. really?
[01:29]  * mtaylor punches himself in the face
[01:29] <lifeless> pydoc bzrlib.log.show_log
[01:29] <lifeless>     start_revision
[01:29] <lifeless>         If not None, only show revisions >= start_revision
[01:29] <lifeless>     end_revision
[01:29] <lifeless>         If not None, only show revisions <= end_revision
[01:39] <mtaylor> lifeless: ok. I honestly don't know what crack I was originally smoking.
[01:39] <mtaylor> lifeless: but just adding 1 rather than trying to walk the tree sure does work perfectly
[01:40] <mtaylor> lifeless: so, have you seen the code that's in bzr-build for adding config info to the branch in a .bzr-builddeb/default.conf file?
[01:41] <mtaylor> bzr-builddeb I mean
[01:42] <poolie> hello mtaylor
[01:42] <mtaylor> hi poolie
[01:42] <poolie> lifeless: thanks for the RT request, i bumped it to joey
[01:51] <lifeless> mtaylor: I haven't looked at it, no.
[02:03] <AfC> A two week release cycle?
[02:05] <lifeless> no, 1.4 was late
[02:05] <AfC> {shrug}
[02:05] <AfC> so, that doesn't change the fact that it only just come out.
[02:06] <AfC> came*
[02:08]  * igc lunch
[02:08] <AfC> I wouldn't dream of quibbling with "a good amount of code has landed" but you are jerking the chain of the people who do packaging
[02:12] <poolie> AfC: so the closest way to keep a precise cycle would be to do the rc1 now and have a longer lag til the release
[02:12] <poolie> is this an undue burden on packagers?
[02:16] <Odd_Bloke> AfC: I think jerking the chain of packagers is preferable to jerking the chain of users in general.  Especially as a lot of bzr packagers are within the community (or are poolie), so are aware of what's going on.
[02:34] <AfC> Odd_Bloke: true
[02:36] <AfC> Odd_Bloke: and I should also concede that at the scale of third digit minor releases (in the sense of era.major.minor even though everyone insists on calling it major.minor.whatever) people are pretty used to doing bumps with no big deal
[02:37] <AfC> poolie, Odd_Bloke: but I have noted an enormous amount of dismay expressed by people that people writing plugins (and thence packages for those plugins) across the Bazaar space as a whole have seemed to have a hard time staying abreast.
[02:37] <fullermd> I don't feel jerked by the fairly fast release cycle.  I feel a little flailing-in-the-dark on delayed releases, though.
[02:38] <AfC> Perhaps it would be less evident if the coupling between (say) {bzr-svn, bzr-gtk} and bzr was looser.
[02:38] <jelmer> AfC: bzr-gtk isn't coupled with particular bzr releases
[02:39] <AfC> jelmer: I'm glad to hear that
[02:39] <AfC> jelmer: though I must say that I seem to have a fairly strong recollection of frequently battling "this version imcompatible with installed bzr" warnings|errors in the not too distant past
[02:40] <jelmer> AfC, That was < 1.0
[02:40] <AfC> Ah
[02:40] <jelmer> bzr-svn still has version warnings in place and so does bzrtools
[03:15] <lifeless> spiv: have you any immediate thoughts on:
[03:15] <lifeless> ERROR: test_add_lines_return (bzrlib.tests.test_versionedfile.TestVersionedFiles)
[03:15] <lifeless> vvvv[log from bzrlib.tests.test_versionedfile.TestVersionedFiles.test_add_lines_return(named-knit)]
[03:15] <lifeless> bzr: ERROR: [Errno 2] No such file or directory: '/tmp/testbzrrIvkG0.log'
[03:16] <spiv> lifeless: huh
[03:16] <spiv> lifeless: just "that shouldn't happen",
[03:16] <spiv> :)
[03:17] <lifeless> I have two things of concern here
[03:17] <spiv> lifeless: well, that and I would suspect the __dict__ clearing code that bit you yesterday might again be the culprit
[03:17] <lifeless> one is is: "test_add_lines_return (bzrlib.tests.test_versionedfile.TestVersionedFiles)"
[03:17] <lifeless> that id is the pyunit stock one, and wrong
[03:17] <lifeless> the other is the mithing log
[03:18] <spiv> Which is pretty worrying if true, it's meant to make testing faster and easier, not harder!
[03:19] <spiv> Ideally, we'd only clear tests that fail (hmm, which might be part of the reason I put it in run, you can't figure that out from tearDown/cleanup that I know of)
[03:21] <lifeless> well
[03:21] <lifeless> I think the problem here is in the approach
[03:22] <lifeless> reporting is done from objects to a stream
[03:22] <lifeless> the size issue you were trying to address is due to keeping objects around
[03:22] <lifeless> rather than cleaning up tests I suggest simply reporting to a stream at the time of failure
[03:22] <lifeless> then delete the entire test object
[03:22] <spiv> Right, but keeping the test cases around is potentially useful.
[03:22] <spiv> e.g. with a graphical runner.
[03:23] <lifeless> a graphical runner has different needs
[03:23] <spiv> I don't want to fight for hypothetical cases very hard, of course.
[03:24] <lifeless> well I'm just aying that the graphical runner can set a flag/fail to set a flag that controls this
[03:24] <lifeless> and in fact doesn't need to do either
[03:24] <lifeless> its conceptually simple:
[03:24] <lifeless> addError reports immediate
[03:24] <lifeless> thats in the Result object, which the runner provides
[03:24] <lifeless> the suite object deletes tests after running them
[03:24] <lifeless> so rather than for test in tests: run()
[03:24] <lifeless> its run(); del
[03:25] <spiv> Twisted has a suite that does that, IIRC.
[03:25] <lifeless> a graphical test runner that wants to keep the objects just has addError keep a reference to the test object
[03:25] <spiv> I suppose an alternative spelling more like what I tried is "test.run(); test.cleanThyself()"
[03:26] <lifeless> indeed; thats what I'm saying doesn't fit that well
[03:26] <spiv> (with smarts to only call cleanThyself on test objects that have that method, and only call it if the test passed...)
[03:26] <lifeless> it makes the object interface more complex, because now you need a 'clean' concept added, rather than just 'you are not needed anymore'
[03:26] <spiv> I guess I'm a bit reluctant to rely on the gc here.
[03:27] <lifeless> One useful way to think about this
[03:27] <jamesh> the twisted stuff also wants to do evil things like run a test multiple times
[03:27] <lifeless> is to consider subunit
[03:27] <spiv> jamesh: evil, but useful
[03:27] <lifeless> you can instantiate the test twice to do that
[03:27] <lifeless> thats simpler
[03:27] <jamesh> spiv: a reload() type interface would be better for that
[03:27] <spiv> jamesh: I've certainly wished for that feature in other runners when trying to debug intermittently failing tests
[03:27] <lifeless> spiv: so imagine all tests run under subunit - report *everything relevant* at failure time, and the object goes away.
[03:28] <spiv> I don't have any disagreement with instantiating a test twice to run it twice.
[03:28] <lifeless> spiv: I really think this would be simpler and less prone to errors/race conditions
[03:28] <spiv> The only reason I see for keeping a test object around after running it is for debugging and reporting (and the reporting really ought to be all done by the time run() returns)
[03:28] <jamesh> lifeless: I know you're busy, but if you have a chance to look at my bzr-dbus patches at some point it'd be appreciated
[03:29] <spiv> But it's relatively easy to accidentally hang on to objects, so rather than hoping that "del test" is releasing the last reference to the test case in the face of complicated test suite infrastructure, I thought that just resetting the test case object's state to the minimum possible would be more reliable.
[03:30] <spiv> Twisted has certainly found that trying to release all references is hard to do.
[03:30] <jamesh> weak references can help catch that sort of bug
[03:31] <spiv> So, I'm completely happy to remove the reference, but it just seems prone to not actually having any effect unless we're always very careful.
[03:31] <lifeless> jam: still around ?
[03:32] <lifeless> spiv: so, can we tell how many references an object has ?
[03:32] <spiv> sys.getrefcount in CPython
[03:32] <lifeless> spiv: so we can write tests that the test framework is wellbehaved
[03:32] <spiv> Although it's easy to get confused because you need a reference to it to ask how many references there are :)
[03:32] <lifeless> for addCleanup etc
[03:33] <lifeless> and if an individual test happens to leak; so beit - its much better than leaking 11111 tests
[03:34] <lifeless> anyhow, late lunch for me
[03:38] <jamesh> lifeless: it'd be clearer to do something like: ref = weakref.ref(test); del test; assert ref() is None
[03:38] <jamesh> if you want to check for leaks
[03:40]  * spiv wonders why lifeless is noticing bugs here all of a sudden
[03:40]  * spiv -> food
[04:03] <lifeless> spiv: well, the id() one had been annoying me for a bit, but I generally had only one variant failing, when I had 6 it become important
[04:04] <lifeless> jamesh: re testing, yes, thats how to tell if its leaked; but you need to run the test framework in the middle there
[05:38] <poolie> lifeless, a word in your shell-like ear?
[05:39] <poolie> spiv and i are working on finishing the smart protocol changes
[05:39] <poolie> if the server is too old to understand the new request, we'll drop the connection and restart
[05:40] <poolie> unfortunately the previous logic for understanding the response to the 'hello' rpc is wrong; the client is upset if the server says it's newer
[05:40] <poolie> as i recall you thought this was a good move when we had another similar situation
[05:43] <poolie> so it looks like we will stop sending the explicit 'hello' from new clients, and instead just see what the server says about the first command
[05:43]  * igc pick up kids - bbiab
[05:44] <poolie> bye
[06:06] <lifeless> poolie: uhm, I've never liked hello. If you are proposing to stop using hello's then great.
[06:06] <lifeless> poolie: otherwise I think I don't understand your word
[06:07] <poolie> so, basically: just send a call in the latest version
[06:07] <poolie> if the server doesn't understand it, disconnect and try again
[06:08] <poolie> i think the only contentious part of this is: is it ok to drop the connection and restart if the server doesn't understand?
[06:08] <poolie> it's undesirable but avoiding it seems complex
[06:08] <poolie> so i think it's acceptable
[06:08] <poolie> hopefully this will be the last such transition
[06:09] <lifeless> we already have the compromise of dropping the connection
[06:09] <lifeless> so I think its fine
[06:09] <poolie> right
[06:09] <poolie> me too
[06:10] <lifeless> I think it would be nice
[06:10] <lifeless> if we could figure out the ssh magic to drop the ssh channel but keep the ssh session
[06:10] <poolie> full stop?
[06:10] <poolie> yes, spiv said that too
[06:10] <lifeless> greats minds
[06:11] <poolie> mm
[06:11] <poolie> given all the different ssh situations i think that may be hard
[06:12] <lifeless> without more ssh protocol knowledge I have no idea
[06:12] <poolie> if we really want to avoid dropping it i think we'd do better to start by sending a command in an old encoding which old servers will understand, but give an error without losing the connection
[06:12] <poolie> well, we use putty, paramiko, openssh and ssh.com ssh
[06:12] <poolie> and i think there is no standard way to get it...
[06:13] <poolie> it would probably be good to have some documentation about "hey you should turn this feature on" as it's generally useful
[06:20] <lifeless> poolie: I'm not talking about master session stuff
[06:22] <poolie> i know, but it's similar, is it not?
[06:25] <lifeless> I think the underlying mechanism is reused
[06:29] <lifeless> yay, add_lines -nearly- done
[06:29] <lifeless> deep depdency:)
[06:30] <lifeless> well, I'm past 8 hours now, so gnight!
[08:28]  * igc dinner
[08:39] <spiv> poolie: Hmm, I've hit a surprise bug, so I won't get this patch to the list until tomorrow morning.
[08:40] <spiv> (it turns out I was forgetting to send the protocol version marker string on v3 responses!)
[12:00] <Winterstream> I realize that this channel isn't exactly aimed at bzr-svn, but hopefully someone can help me. The problem is that bzr-svn changes SVN properties every time I do check-ins. SourceForge reports these changes and they seem to get longer every time. I don't ever do merging (I always rebase), so it seems as if bzr-svn doesn't really need the info it stores in the properties. Any idea whether bzr-svn can work without the property changes?
[12:10] <james_w> Winterstream: I don't know if bzr-svn could possibly work without them, but I don't think there is currently a way to turn it off at least.
[12:27] <jelmer> Winterstream: there's no way to do that at the moment, but please file a bug and I'll have a look at implementing it for the next release
[12:28] <jelmer> Winterstream: Not setting the properties will have to consequence that you can no longer pull from svn into the branch you pushed to
[12:47] <gabees> hello all, running Gutsy server, added the intrepid main to my sources, ran update, checked bzr and it is still showing the old version. Is any one able to give me some help with this please?
[13:00] <RAOF> gabees: By 'update' you mean 'apt-get update' or 'apt-get upgrade', or both?  (1) You need both - update then upgrade (or dist-upgrade), and (2) I hope that gutsy server doesn't need to work.
[13:02] <RAOF> gabees: Intrepid will break, and break hard, many times over the next month.
[13:04] <Winterstream> jelmer - I figured as much. Thanks :)
[13:09] <gabees> no look, I followed the instructions on the bzr site for upgrading it: https://launchpad.net/~bzr/+archive
[13:09] <gabees> it says to added these intrepid repo
[13:09] <gabees> but the repo only contains bzr and bzr-tools
[13:09] <gabees> I did update, and then upgrade
[13:09] <gabees> but it won't recognise the new version in the intrepid repo
[13:09] <gabees> hehe
[13:10] <gabees> i'm now trying to upgrade the entire server to hardy
[13:10] <gabees> that include 1.3
[13:16] <_paneb> is a repository usually created for each project?
[13:16] <_paneb> or is there one repository for all projects (and their branches)?
[13:29] <gabees> _paneb: one repo for all
[13:30] <fullermd> Depends on who created it and what they wanted to do.
[13:31] <_paneb> i will be creating it, and i just want to control several projects
[13:31] <fullermd> I tend to not mix projects in one repo.
[13:34] <_paneb> when working "solo" do i create my repositories with trees?
[13:41] <_paneb> nevermind, i understand now what --no-trees is for
[13:42] <fullermd> Well, again, it depends on what you need.  tree/no-trees is just a default; you can always create a tree on a branch without one, and remove a tree from a branch with one.
[13:43] <_paneb> right
[13:43] <fullermd> Some things I tend to create branches only to use right off, so they tend to be trees.  Others a lot of branches sit around a while, so they're no-trees.
[13:43] <fullermd> And then there are the work styles where you use lightweight checkouts somewhere other than the repo, in which case you want no-trees.
[13:53] <igc> night all
[14:02] <gabees> upgraded to hardy heron now
[14:03] <gabees> that's got a newer version of bzr
[14:21] <fbond> lifeless: I'll be adding to that quilt/loom wiki page further when I can.
[14:22] <fbond> lifeless: It must be emphasized more strongly that carrying live changes in the working tree across threads (up-thread, down-thread, etc.) can be rather terrible.
[14:23] <fbond> lifeless: If conflicts occur, you are left in the unpleasant situation of having to extricate your valuable changes from a variety of potentially conflicting files.
[14:23] <fbond> I guess if your instinct is correct (restore from backups), things can go okay.
[14:23] <fbond> But my instinct in the past has been to quickly move back to the thread that I came from.
[14:24] <fbond> Which creates more conflicts. :)
[14:24] <fbond> Perhaps it would be good to refuse to switch threads when live changes are present?
[14:25] <fbond> (Or at least if arriving at destination thread will result in merges or conflicts)
[14:25] <fbond> s/merges/new merges requiring commits/
[14:26] <bob2> live = uncommited?
[14:27] <fbond> bob2: yep
[14:28] <jam> fbond: it is a design goal to allow you to switch with uncommitted changes
[14:28] <krow> statik: ?
[14:29] <jam> so you can make a change that should be on a different thread
[14:29] <jam> realize it
[14:29] <jam> switch threads
[14:29] <jam> and then commit
[14:29] <fbond> jam: I'd like to believe that :)
[14:29] <jam> fbond: conflicts are probably different
[14:29] <fbond> jam: But the reality of the situation is that the user experience is a bit jarring.
[14:30] <jam> lifeless: I'll need you to create the bzr-1.5 branch when you get some pqm time. i'll try sending an email in case you miss this
[14:30] <fbond> jam: Both of those situations are an immediate headache (new merges, conflicts)
[14:30] <fbond> The only good way I know to deal with it is `bzr shelve', `bzr switch', [resolve,commit,etc], `bzr unshelve', [carry on with life]
[14:31] <fbond> But that requires some pretty good foresight.
[14:32] <jam> fbond: I don't have much personal experience with the loom plugin, I just follow along :)
[14:33] <jam> fbond: so what is causing the conflicts that you are trying to roll back to the earlier thread
[14:33] <jam> I'm just trying to follow a little bit closer so I might give suggestions
[14:33] <fbond> jam: I hope this is not too harsh: loom is to what it should be as git's UI is to bzr's.
[14:33] <fbond> jam: There are a few different ways conflicts can happen.
[14:34] <fbond> Each thread switch is an implicit merge.
[14:34] <fbond> If I do:
[14:34] <fbond> bzr commit ...
[14:34] <fbond> bzr up-thread
[14:34] <fbond> I get a new merge that now needs to be committed.
[14:34] <fbond> (in the higher thread)
[14:34] <fbond> This merge can conflict.
[14:34] <fbond> Further, I can also have working tree conflicts.
[14:35] <jam> How is "this merge can conflict" separate from "working tree conflicts"
[14:35] <fbond> The merge can conflict with the branch.
[14:35] <jam> I guess I'm not understanding how the merge can conflict
[14:35] <fbond> So you get branch-branch conflicts as well as working tree-branch conflicts.
[14:36] <fbond> Threads are nearly branches.
[14:36] <fbond> I guess in the end the conflicts are all sitting in your WT, but they originate differently.
[14:36] <jam> fbond: ok, so the files on disk get conflicted, but if you have live (uncommitted) changes they can also conflict
[14:36] <jam> fbond: I was just confused by your terms
[14:36] <fbond> jam: Sorry, I don't know bzr's internal concepts as well as you do.
[14:36] <fbond> So I probably use bad language.
[14:37] <jam> I wouldn't claim that
[14:37] <fbond> jam: I would :)
[14:38] <jam> fbond: so the issue is that switching trees might conflict
[14:38] <fbond> Anyway, the end result is that switching threads can't be done as casually as you'd like.
[14:38] <jam> and then after that you have an implicit merge
[14:38] <jam> which might conflict *on top* of that
[14:38] <fbond> Right, conflicts aren't the only issue, though.
[14:39] <fbond> If I have uncommitted changes in the WT and I switch to a higher thread, causing an implicit merge (with no conflicts) my WT now contains my new changes, but it also contains a merge that needs to be committed.
[14:39] <fbond> So I have to extricate the changes that I was carrying around in the WT from the merge itself.
[14:39] <jam> fbond: sure, I think the "switch with uncommitted changes" is meant more for down-thread, not up-thread
[14:39] <fbond> jam: Okay, possible.
[14:39] <jam> and I see your point about difficulties
[14:40] <jam> so.... what would be my resolution
[14:40] <fbond> jam: Yeah, I like using loom, but when I forget to shelve before these critical thread switches, it's pretty frustrating.
[14:40] <jam> fbond: would it be easier if up-thread refused with uncommitted changes
[14:40] <jam> or if you could at least set a flag for that
[14:40] <jam>  or require --force, etc
[14:41] <fbond> jam: Right.  You could be a little more granular and say "up-thread refuses if the switch would result in uncommitted merges and/or working tree conflicts"
[14:41] <jam> it would, unfortunately, make up-thread a bit slower, as it would have to check for changes before moving
[14:41] <fbond> But that might not be as predictable.
[14:41] <jam> fbond: doesn't up-thread always result in an uncommitted merge
[14:41] <krow> Hi!  I just had bzr puke on commit on me:
[14:41] <krow> http://pastie.caboo.se/192356
[14:41] <jam> I thought that was part of the design
[14:41] <fbond> jam: Nope.
[14:41] <jam> well, I suppose it might already be merged
[14:41] <fbond> Exactly.
[14:41] <fbond> (And that is more often than not)
[14:42] <jam> krow: have you been doing something interesting with the "plugin/daemon_example" directory?
[14:42] <jam> It is at least claiming that you have a file inside it, but the actual directory is not present
[14:44] <jam> krow: any chance you could paste "bzr log -r -10..-1 --short --verbose" ?
[14:45] <jam> krow: this is bug #150438, btw
[14:47] <krow> jam: Yeah... I did an rm without a bzr
[14:47] <jam> hmm... sounds like an auto-detect error
[14:47] <jam> we detect that the directory is removed
[14:48] <jam> but don't propagate that to all the children properly.
[14:48] <jam> krow: is this during "bzr commit "?
[14:48] <krow> jam: Yes
[14:49] <jam> krow: so you did something like
[14:49] <jam> rm -rf plugin/daemon_example
[14:49] <jam> bzr commit -m 'xxxx'
[14:49] <jam> and it blows up like this?
[14:49] <jam> or you did that a while ago
[14:49] <jam> and now it is complaining
[14:49] <krow> jam: Dd the rm and then did the commit
[14:50] <krow> jam: Currently stuck at the commit... :*
[14:50] <krow> jam: Currently stuck at the commit... :(
[14:50] <krow> jam: http://pastie.caboo.se/192357  That is from the command you asked me to run
[14:50] <jam> krow: you've been doing a lot of housekeeping :)
[14:51] <krow> jam: Yes :)
[14:51] <krow> jam: So thoughts on how to get out of this?
[14:51] <jam> krow: well, there are certainly ways to reset things
[14:52] <jam> I'm not sure what is best righ tnow
[14:52] <jam> is the only change removing some directories
[14:52] <jam> (aka easily redone)
[14:52] <jam> or is there more complex stuff
[14:52] <jam> krow: for example, you could do
[14:52] <jam> cd ..
[14:53] <jam> bzr checkout --lightweight plugin alt_plugin
[14:53] <jam> rm plugin/.bzr/checkout
[14:53] <jam> mv alt_plugin/.bzr/checkout plugin/checkout
[14:53] <jam> krow: don't do it until we've sorted things out, though
[14:53] <jam> that will reset bazaar into thinking you haven't done anything to your tree
[14:53] <jam> So simple changes like removing directories should be fine
[14:53] <krow> jam: Ok...
[14:54] <jam> as should modified files, etc
[14:54] <jam> renames will be lost
[14:54] <jam> but you can use "bzr move --after"
[14:54] <jam> krow: I would *really* like to understand how it got into this situation, thoguh
[14:55] <krow> jam: All there is, is modified files and rm'ed stuff. No moving.
[14:55] <krow> jam: I can save a copy of the tree.
[14:55] <jam> krow: if you could, that would be nice
[14:55] <jam> my concern is that it was the steps leading up to this that caused the problem
[14:55] <jam> and a post-mortem isn't going to reveal the secrets
[14:55] <jam> but it is better than nothing
[14:56] <jam> fbond: it is pretty easy to detect if we would need to merge, would that UI suit you?
[14:56] <jam> fbond: just to finish the conversation :)
[14:59] <jsled> I'm trying to make sure I understand something about bzr history and merging.  In a situation with multiple developers having a centralized/remote shared repo (bzr+ssh access) and each having local shared repos with a branch from the remote trunk … is <http://paste.lisp.org/display/60340> accurate?
[15:00] <jsled> I might be wrong on the version numbering in the merge commit.  It probably makes more sense if the two developers both branch from (and "share") commit 1.
[15:00] <beuno> jsled, looks exactly like what I'm using  :)
[15:00] <krow> jam: Well, this thing is 596M tarred/compressed
[15:00] <krow> jam: Is there a way to permanently snip history?
[15:01] <beuno> jsled, is there a specific concern for this workflow, or are you just making sure?
[15:01] <jam> krow: well, you could rm .bzr/repository/packs/...
[15:01] <jam> I'm mostly interested in the WT
[15:01] <jam> also, a 'make clean' or equivalent is usually good
[15:01] <jsled> beuno:
[15:01] <krow> jam: Problem:
[15:01] <jam> so I'm not getting .o files
[15:01] <krow> [brian@localhost plugin]$ bzr checkout --lightweight plugin alt_plugin
[15:01] <krow> bzr: ERROR: Not a branch: "/home/brian/Other/mysql-6.0-brian/plugin/plugin/".
[15:02] <jsled> er.  beuno: It's wicked confusing, as the revision numbers keep jumping around.
[15:02] <jam> krow: did you miss the "cd .." ?
[15:02] <jsled> As well, trying to use the revision number as a build number becomes impossible.
[15:02] <jsled> It makes the history really hard to search for changes.
[15:02] <jam> jsled: there is a recommended workflow which gets around that
[15:02] <fbond> jam: Yes, I'd be happier with the UI if it didn't help me shoot myself in the foot.
[15:03] <krow> jam: Is the command from the root of the repository, or from outside of it?
[15:03] <jam> and a flag you can set so that the second 'bzr push' won't let the mainline revno jump around
[15:03] <jam> krow: you have "$repo/plugin" right?
[15:03] <jam> where "plugin" is the branch?
[15:03] <jam> so you want to be above the branch
[15:03] <jsled> jam: I've love to hear/read about it.  I've thought baout trying to encourage the use of "rebase", but the workflow is already pretty complicated.
[15:03] <jam> so that you can do "bzr co --lightweight a_branch other_branch"
[15:04] <jam> jsled: so, #1 is to use a checkout for your mainline, which people then merge into and "bzr commit" to update the tip
[15:04] <jam> let me check #2 real quick
[15:04] <jam> #2 "echo 'append_revisions_only = True' >> .bzr/branch/branch.conf
[15:04] <vigneswari> hello all...
[15:05] <beuno> jsled, rebase is stronly disencouraged as it breaks history, and leaves branches unmergeable
[15:05] <vigneswari> we have one distro based on debian
[15:05] <beuno> jam, do you know what adding appen_revisions_only does?
[15:05] <vigneswari> planned to maintain source using bzr
[15:05] <jam> beuno: if it would change your mainline revisions it refuses the push
[15:05] <krow> jam: http://pastie.caboo.se/192366
[15:06] <beuno> jam, does it force #1 or similar, or just create new revs instead of subrevs?
[15:06] <vigneswari> currently we have the bzr repo in local machine and our team is using locally using ssh authentication
[15:06] <beuno> jam, ah, that's what I thought, thanks  :)
[15:06] <jsled> beuno: breaks history?  To be clear, by "rebase" I mean the process of moving a sequence of commits to the tip after each pull … basically so there are no merge commits.
[15:06] <vigneswari> but i dont know how to make it public
[15:06] <jam> krow: interesting.... I think I know why, but trying to figure it out for a second
[15:07] <vigneswari> bzr+ssh is better or ftp?
[15:07] <jam> krow: I believe what is happening is that "bzr checkout" is trying to copy files from your source checkout, and failing
[15:07] <vigneswari> want to know hoe to configure this
[15:07] <jam> krow: so we need to tell it that there isn't actually a checkout there
[15:07] <jam> krow: so do "mv mysql-6.0-brian/.bzr/checkout mysql-6.0-brian/.bzr/checkout-old"
[15:07] <vigneswari> plz someone help me to do this
[15:07] <jam> krow: and then try the same "checkout --lightweight"
[15:07] <vigneswari> any suggestions?
[15:08] <jam> krow: and then you should be able to mv 'alt/.bzr/checkout mysql-6.0-brian/.bzr/checkout'
[15:09] <beuno> jsled, yes, I understand. But rebase removes many references, so it makes it impossible to use continuosly
[15:09] <bob2> vigneswari: you can make it publically available just by letting anonymous users have read only access via ftp or http
[15:09] <beuno> vigneswari, bzr+ssh is much faster as it uses the bzr smart server
[15:09] <beuno> vigneswari, if you want to make it public, http is probably the best way to go
[15:10] <bob2> really?  at least bzr:// was slower for some operations.
[15:10] <vigneswari> bob2, beuno , readonly? if they want to edit the source and to contribute..
[15:10] <beuno> vigneswari, well, bzr+ssh is fine then
[15:10] <bob2> vigneswari: then give them ssh access so they can use bzr+ssh or sftp
[15:11] <jsled> beuno: Just curious, what sort of references?   Or does it get into bzr internals?  I mean, abstractly, one could create a diff for each commit, uncommit+revert them, pull, then re-apply the merges + commits in sequence.  I'm not sure what references would be lost.
[15:11] <vigneswari> bob2, any doc for using sftp?
[15:11] <beuno> bob2, well, there are some things to fix with the smart server so it's faster in every operation. But i think in general, it's faster
[15:11] <bob2> vigneswari: same way they would use sftp for anything else - it doesn't require any special bzr-specific configuration
[15:12] <jam> fbond: bug #227339
[15:12] <fbond> jam: thanks
[15:12] <beuno> jsled, I really don't know many specifics. I believe mainly what was merged from where, thus, making it impossible for people merging in changes done in different points of the timeline
[15:13] <vigneswari> bob2, is it adviceable to give write permission to others...
[15:13] <jsled> fbond: hey. :)
[15:13] <jam> beuno, bob2: bzr+ssh is generally much faster than sftp, atm it is on par with http, but getting better
[15:13] <fbond> jsled: Hi :)
[15:13] <bob2> vigneswari: sorry, I don't understand the question...
[15:13] <fullermd> It's much slower than http for write operations.  Writes over http get done real quick   :p
[15:13] <beuno> jam, I recall a few discussions during the sprint where the smart server was slower than http, was that solved?  I know it's always faster than sftp
[15:13] <jam> jsled: the big difference with "rebase" is that you don't actually record that you merged the other person's changes
[15:14] <beuno> fullermd, lol
[15:14] <bob2> hey I think the http cgi write thing does work nowadays
[15:14] <jam> beuno: I don't believe it has all been solved
[15:14] <jam> it is something spiv is working on
[15:14] <jsled> jam: those numbered points from earlier … are they from a particular list (a FAQ that I should have searched for first, maybe? :)
[15:15] <vigneswari> bob2, that means ssh authentication to whoever wants..
[15:15] <jam> jsled: I don't think "append_revisions_only" is well documented, it only seems to be exposed via "bzr init"
[15:15] <fbond> jsled: In bzr, revisions are a tree snapshot (although they may not be stored as such) and a parent revision.  Rebase rewrites history, thus destroying historical correlation with branches whose parent revision is in the rebased branch. (Somebody correct me if I'm wrong)
[15:15] <jam> jsled: the workflow is: http://bazaar-vcs.org/Workflows?highlight=%28workflow%29#head-ca3ccf73574776b36453b2213789731549e54167
[15:15] <jam> But that doc doesn't get into enough detail about *why* you would want that way
[15:15] <krow> jam: Thanks! I believe that got me working again.
[15:15] <bob2> vigneswari: don't give people ssh access unless you want them to be able to modify your bzr repository
[15:15] <jam> It just says it exists
[15:16] <bob2> vigneswari: you can make it available, read-only, via ftp, http, bzr://, etc
[15:16] <beuno> vigneswari, you could use something like bundlebuggy if you want something intermediate
[15:16] <beuno> and work with patches
[15:16] <beuno> although it might be an overkill
[15:17] <vigneswari> bob2, thanks
[15:17] <jam> jsled: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#decentralized-with-shared-mainline
[15:17] <Lo-lan-do> Hi there
[15:17] <jam> is the same thing in a different document
[15:17] <jam> and is the more "canonical" location for that documentation
[15:17] <bob2> boomtish
[15:18] <Lo-lan-do> Is there a simple way to know from a heavy checkout whether I'm missing some revisions from the master branch?
[15:18] <bob2> bzr missing?
[15:19] <jam> krow: also, bzr 1.4 has been released, any chance you could upgrade to it?
[15:19] <Lo-lan-do> bob2: That will get me the revisions I'm missing from the parent branch, which is not necessarily the master branch.
[15:19] <bob2> ah
[15:20] <jam> Lo-lan-do: well 'bzr missing http://path/to/maste/branch" will
[15:20] <jsled> jam: Is it me, but is there a `bzr push` missing from that workflow, though?  I mean, a) that's very similar to the workflow we have, and b) I don't see how one can issue a commit to a remote branch.
[15:20] <jam> but certainly is a bit to type
[15:20] <jam> jsled: the checkout
[15:20] <Lo-lan-do> jam: Yeah, hence my request for a "simple" way :-)
[15:20] <jam> does the push for you
[15:20] <jsled> jam: What checkout?
[15:20] <krow> jam: I tend to stick to whatever the distribution provides (though sometimes I will use the python (forget the name of it) tool to upgrade python bits)
[15:21] <jam> krow: you are probably thinking "easy_setup/easy_install"
[15:21] <jam> krow: what distribution are you on? Hardy or debian
[15:21] <Lo-lan-do> jam: Could there be a new revisionspec for that?  Like "bzr missing -rmaster:"?
[15:21] <jam> (since you have 1.3.1)
[15:21] <krow> jam: FC :)
[15:21] <jam> Lo-lan-do: I suppose it could, if 'missing' took a revision id
[15:22] <Lo-lan-do> Ah, yeah, I'm confused.
[15:22] <jam> krow: hm.... I wonder why they have an rc1 as their official version
[15:22] <krow> jam: Who knows... RH has shipped alphas as well.
[15:22] <Lo-lan-do> Maybe a "bzr update --mising" then?
[15:23] <jam> Lo-lan-do: well, 'bzr status' could also check if this is a bound branch and if the remote tip == this tip
[15:23] <jam> it already does it for normal checkouts
[15:23] <Lo-lan-do> or --show-missing, or something
[15:23] <jam> jsled: let me put up a patch to the document, which might help you understand a bit more
[15:23] <jam> jsled: I might as well get it written down
[15:23] <fbond> jam: #227339 doesn't cover the case where there are no new pending merges, but there are plain WT conflicts.
[15:24] <fbond> Shall I create a new bug to cover that case?
[15:24] <jam> bug #227339
[15:24] <fbond> Or piggy back on that one?
[15:24] <jsled> jam: That'd be awesome.  I just don't see a "bzr checkout" in that section, is all. :/
[15:24] <jam> fbond: feel free to post that as well
[15:24] <jam> they *might* be different issues
[15:25] <jam> conflicts would be considered an uncommitted change
[15:25] <fbond> jam: They are obviously related, but are different cases (although they can overlap).
[15:25] <fbond> jam: I'll create a new bug.
[15:25] <jam> fbond: you can always say "see also bug #227339" in your comment, so people can easily jump between them
[15:29] <jam> jsled: does this clarify it a bit: http://pastie.caboo.se/192384
[15:32] <jsled> jam: it does, for the example.
[15:35] <fbond> jam: bug #227339
[15:35] <fbond> jam: eh, I mean bug #227349
[15:37] <jam> fbond: I'm not sure that refusing to switch because of a conflict is the correct solution
[15:37] <jam> because you will always get conflicts when people change similar parts of code
[15:38] <fbond> jam: I guess I make a distinction between what I call "branch conflicts" and "working tree conflicts"
[15:38] <jam> fbond: I'll clarify on the bug
[15:38] <fbond> jam: thanks
[15:39] <fbond> (to be clear: I say "WT conflict" when I mean "a conflict between an uncomitted change and the branch")
[15:39] <fbond> jam: BTW, I'm open to suggestions WRT wording :)
[15:40] <jam> fbond: wouldn't this be handled by bug #227339?
[15:40] <jam> fbond: because you can't switch if it is going to merge and you have uncommitted changse
[15:40] <jam> thus it can't conflict
[15:41] <fbond> jam: No, I'm not talking about a situation where there are uncommitted merges.
[15:41] <fbond> jam: Here's the scenario:
[15:41] <fbond> I'm in thread A
[15:41] <fbond> I make some changes to source files.
[15:41] <fbond> I switch to thread B.
[15:41] <fbond> My current WT can conflict with the previously committed state of thread B.
[15:41] <fbond> Thus, a WT conflict arises.
[15:42] <fbond> (And there are no pending merges)
[15:42] <jam> fbond: ok, I think I follow
[15:44] <_paneb> when working with the SVN-style repository layout (http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#choosing-a-shared-repository-layout), day-to-day work is performed on the feature branches, and then once a feature is ready to be commited, the feature-branch is merged with trunk?
[15:46] <jam> fbond: ok, check the updated text on bug #227339, let me know if it captures your ide
[15:46] <jam> idea
[15:46] <jam> For the example I was able to put together
[15:47] <jam> I have to say, you sort of have to handle that conflict in that situation
[15:47] <jam> so i'd like to have another example that would make it more obvious that you don't want to switch
[15:47] <jam> _paneb: the feature is merged *into* trunk
[15:47] <_paneb> ok
[15:48] <fbond> jam: Well, switching threads is typically done pretty casually.
[15:48] <jam> _paneb: generally you only merge trunk => feature_branch if there is something potentially conflicting, etc being done by trunk
[15:48] <_paneb> i used the wrong word :)
[15:48] <_paneb> i meant branch => trunk
[15:48] <fbond> jam: Sometimes, I pass through one thread on my way to another (I guess I could use bzr switch...)
[15:48] <jam> fbond:  I think it still has to go through the intermediate threads
[15:48] <_paneb> and while the feature is not quite complete yet, it is only committed to the feature-branch, right?
[15:48] <jam> fbond: anyway, it would be nice to have a clearer example of why this is necessary
[15:49] <jam> _paneb: correct
[15:49] <jam> (for some values of incomplete)
[15:49] <_paneb> non-working
[15:49] <jam> _paneb: having worked on projects with distributed development, you still want to merge your changes in fairly often to avoid drift
[15:50] <jam> _paneb: but yes, while your branch is not at a point it can be used, you leave it in the feature branch
[15:50] <_paneb> right ok
[15:50] <jam> my point is more about project management
[15:50] <jam> having someone work for 2 years on their own branch before merging
[15:50] <jam> is not recommended :)
[15:50] <_paneb> heh indeed
[15:51] <fbond> jam: Hmm.  Your example is correct, but you seem to be marginalizing the issue :)
[15:51] <jam> fbond: I felt the example was marginal, which is why I asked for a better example
[15:51] <fbond> jam: For me atleast, it is not uncommon to carry uncommitted changes around in my loom for a fair bit while I sort out which changes should be committed where.
[15:52] <fbond> jam: In other words, I occasionally go wild implementing features/fixes and then sort out after the fact where those should actually be committed.
[15:52] <jam> fbond: your organizational issues are up to you :)
[15:52] <jam> I don't use looms, and instead rely on 200+ feature branches
[15:52] <jam> so when I get an unrelated change
[15:52] <jam> it tends to be
[15:52] <jam> cd ..
[15:52] <fbond> jam: Well, sometimes I start out looking at one thing and find other things that should be tweaked.
[15:52] <jam> bzr branch feature_foo bugfix_bar
[15:52] <jam> cd bugfix_bar
[15:52] <fbond> jam: Yeah, I considered using many branches instead of loom.
[15:53] <jam> bzr merge --uncommitted ../feature_foo
[15:53] <fbond> jam: I guess this is why some people have pushed for faster git-style switch ...
[15:54] <fbond> jam: Anyway, so assume that I might end up collecting several different changes in my WT simultaenously and then look for places to commit them afterwards.
[15:54] <fbond> jam: Surely, you can see how I might carry a good size diff around the loom for a while, and in my frequent loom commands, every now and again I get an undesired WT conflict.
[15:55] <fbond> jam: That conflict could have been avoided in some circumstances.
[15:55] <fbond> jam: If loom says "won't merge as it would cause a WT conflict"
[15:55] <fbond> I'll skip over that thread and switch directly to the thread where I want to merge the conflicting change.
[15:55] <fbond> Then I only have to resolve necessary conflicts, and never have to resolve conflicts just to regain mobility on the loom.
[15:56] <fbond> jam: Is my expectation unreasonable?
[15:58] <jam> fbond: I think you are using "loom" as a replacement for git-style branches
[15:58] <jam> which it is *not* intended fro
[15:58] <jam> for
[15:58] <jam> it is meant as building up a series of patches
[15:58] <jam> I can't say we have a great answer for multiple non-related branches
[15:58] <jam> in the same WT
[15:58] <jam> I believe that was discussed at the last sprint
[15:59] <_paneb> and when i first start working on a new feature, i create the new branch and push it to the central location?
[15:59] <jam> _paneb: your choice as to whether you push it or not, depends on whether you want it visible to others
[16:00] <jam> while you are working on it
[16:00] <fbond> jam: Well, my intention is rarely to create a cluster-f****d working tree.  Rather, I set out to create a sane series of patches, but sometimes I end up with scattered changes that need homes.
[16:00] <_paneb> jam, ok
[16:00] <jam> fbond: and I think that is reasonable, I think an answer is to make it easier to do that sort of thing as unrelated branches with switch, etc.
[16:01] <jam> I don't honestly know how switch works with looms
[16:01] <jam> my understanding is that it would have to 'up-thread/down-thread' between all of them
[16:01] <jam> but maybe it allows you to jump directly
[16:01] <fbond> jam: it does
[16:06] <fbond> jam: I'm editing the bug description to cover this situation.
[16:06] <jam> fbond: see the followuup on #227349
[16:06] <jam> fbond: you might look at it before you change the description
[16:07] <colophon> Is there a way to have files ignored in some branches but not others which share the same repository. I have a project that includes some sample data that shouldn't be updated during the normal course of development but I would like to have it versioned
[16:07] <jam> colophon: well, each branch has its own .bzrigore
[16:07] <jam> though when you merge the changes to other files, it will pull along the .bzrignore files
[16:07] <jam> *howeve8
[16:07] <jam> *however*
[16:08] <jam> if you have a file versioned, we don't pay attention to the ignore file
[16:08] <jam> so you could have all branches claim that the files are ignored
[16:08] <jam> and they just happen to be versioned in the one tree
[16:08] <jam> colophon: though it sounds like you may be asking for them to be versioned, but changes ignored in the other branches
[16:08] <jam> which isn't something we support yet
[16:09] <colophon> OK, I'll try to figure out how to split everything into two then
[16:09] <colophon> Thanks
[16:09] <fbond> jam: oops :)
[16:10] <fbond> jam: I'll fix it.
[16:11] <fbond> jam: Foo, launchpad doesn't seem to track intermediate changes to the description...?
[16:11] <fbond> Ah, I have it in an e-mail.
[16:12] <jam> fbond: I think it might, but i'm don't believe it exposes it
[16:14] <fbond> jam: bug #227349
[16:14] <fbond> My comment is mostly superfluous.
[16:15] <jam> fbond: seems reasonable
[17:44] <arj> hi
[17:46] <arj> I have two branches, one which is head and one that is stable. Mostly stable is == head, unless in release mode, in which, stable cherry picks patches from head. Now a release I want to sync these two branches again, but merging in stable from head creates conflicts. Why doesn't this just work? There was no changes to stable, other than the cherry picked patches
[17:54] <Vadi> How can I find out what revision is a branch at? I looked around the commands list but none report it
[17:55] <LeoNerd> bzr revno
[17:55] <Vadi> Thank you!
[17:56] <fullermd> arj: Because of the cherrypicks.
[17:57] <arj> fullermd: but that doesn't make sense
[17:57] <fullermd> Sense?  This is the Internet!
[17:58] <arj> say I have 10 revisions in head. Stable is rev 4. I cherry pick 6 and 7
[17:58] <arj> then I do, merge with head later
[17:58] <fullermd> Cherrypicks don't bring along any metadata; it's roughly equivalent to a diff | patch.  So bzr doesn't know you cherrypicked anything; it's indistinguishable from making the changes manually.
[17:58] <arj> so it should just unroll 6 and 7 and do a full update
[17:59] <arj> oh :(
[17:59] <arj> that sucks, when will it be fixed? :)
[17:59] <fullermd> Not soon, I expect.  It's a Moderately Hard Problem.
[18:00] <fullermd> AFAIK, the only systems that properly handle it are those like darcs, which tracks sets of patches rather than series of states.
[18:01] <arj> getting the full range of situations right might be moderately hard. But the case I just mentioned should be rather easy. And I don't this is a quite common case.
[18:01] <arj> s/don't/think/
[18:02] <arj> the problem is that I have already mirrored the stable branch somewhere. So what is the easiest way to fix my stable branch?
[18:02] <fullermd> Well, if you have one small block of contiguous cherrypicks, it's not TOO hard.
[18:03] <fullermd> You can merge up to the rev before the cherrypicks, commit, merge the revs you cherrypicked, revert [since you already have the changes] and commit (which records the revs in your history), then merge the rest.
[18:03] <fullermd> (the same mechanism could work for bunches of noncontiguous cherrypicks, of course, but it gets REAL annoying quickly)
[18:04] <fullermd> Or you could just manually resolve the conflicts.  If they're small, that can be quicker.
[18:04] <arj> hmm
[18:04] <arj> maybe a wrapper around bzr would be easier in the future
[18:04] <fullermd> I guess a third option would be to merge all the changes, and use revert to force the files to the way they are in the last rev of head.
[18:04] <fullermd> If you don't have any local changes in stable, that's probably the simplest.
[18:05] <fullermd> (or you do have local changes, but don't want to keep them)
[18:05] <arj> how do I do the last force thingy?
[18:05] <fullermd> Look up the revid of that rev in head, do the merge, then `bzr revert -rrevid:whateveritwas .` (in the root dir of the branch)
[18:05] <fullermd> You need the '.', otherwise revert will throw away the merge info.
[18:06] <fullermd> This way it just forces all the files to how they are in that rev, and blows away conflict stuff.
[18:07] <arj> hmm
[18:07] <arj> it seems like it looks for the revid in stable
[18:07] <arj> bzr: ERROR: Requested revision: u'revid:1608' does not exist in branch: BzrBranch5('file:///home/arj/bzr/mms-1.1.0-stable/')
[18:07] <fullermd> No, you want the revid<EMAIL_ADDRESS>or whatever), not the revno.
[18:07] <arj> 1608 is the revision of head I merged
[18:08] <fullermd> See `bzr revision-info`, or `bzr log --show-ids`
[18:08] <fullermd> The revision number will be different in stable than it is in head.  And it won't have any revno in stable until after you've committed.
[18:09] <fullermd> But it should be accessible by the revid any time it's in the repo, which is is after you do the 'merge' even before you commit.
[18:09] <arj> ah that works
[18:09] <arj> thanks a lot!
[18:10] <dacresni> hey, does the bzr smart server have permissions?
[18:14] <MattCampbell> When using the bzr smart server over SSH (the only method I'm familiar with), it runs under whatever Unix account you tell bzr to log into via SSH.  So it's subject to Unix file permissions.
[18:15] <dacresni> what about if windows users are loging into it?
[18:15] <MattCampbell> Is the server itself running Unix or Windows?
[18:15] <dacresni> windows
[18:15] <MattCampbell> Hmm, I'll have to let someone else answer.
[18:15] <dacresni> k
[18:17] <fullermd> The system itself provides no permission management or control at all (excepting that it may be run in read-only or read-write mode).
[18:17] <fullermd> So whatever limitations are provided by the OS environment around it are what you have.
[18:17] <dacresni> so i must use http auth on that directory on IIS
[18:18] <dacresni> ?
[18:18] <dacresni> (i wonder if mercurial can do better)
[18:18] <fullermd> Well, if you're working over ssh, http auth doesn't come into play.
[18:18] <dacresni> but if I don't want to isntall ssh on the server,
[18:19] <fullermd> But if you're using the HTTP smart server, yeah, whatever auth Apache provides is what you're running with.
[18:19] <dacresni> IIS
[18:19] <fullermd> And whatever permissions/restrictions are applied to CGI scripts are the limits of what you can do post-auth.
[18:19] <dacresni> post-auth?
[18:21] <fullermd> "Can I access this" vs. "What can I do once allowed to access"
[18:21] <dacresni> ah
[18:21] <fullermd> HTTP auth provides authentication.  OS permissions (unix perms, ACL's, chroot's, blah blah blah) determine authorization.
[18:21] <dacresni> ah, ok that helps
[18:22] <MattCampbell> My suggestion, if you must run the server on a Windows box, would be to set up Linux of some kind in a VM on that box, maybe using VMware Server (free of charge), and use bzr+ssh inside the VM.
[18:22] <fullermd> Now, over a dumb server (plain HTTP), you can use the web server config to manage [some] authorization too.
[18:22] <fullermd> But with the smart server, every request shows up as a POST to a specific URL, so you can't get any finer-grained.
[18:23] <dacresni> AH, Neat
[18:23] <nysin> I maintain a modification to a program which switched from svn to bzr and now I'm left with a near-copy of that repository (I have both bzr and svn forms around, since I did a repository conversion on my end too) with its own revision history. I could (1) sacrifice that history, start fresh with a bzr branch/get/etc clone of the main repository, generate a big patch (or multiple little patches corresponding to the history wi
[18:23] <nysin> th synthetic timestamps? eh.) representing the entire delta, apply it to the new clone, and continue on and take advantage of bzr's merging abilities. Or (2) basically do bzr diff's on changes to remote repository and give up lots of good things, but keep revision history. Is this accurate and am I missing something?
[18:24] <fullermd> You may be able to use rebase to automate doing (1) but keeping the individual commits/timestamps/etc.
[18:25] <nysin> hm
[18:25]  * fullermd wanders off.
[18:26] <dacresni> fullermd: sweet! everyone here that writes for the web has windows domain access to the webserver
[18:42] <Vadi> There's a typo in the bzr user guide (http://doc.bazaar-vcs.org/latest/en/user-guide/index.html), it says "Linix" near the bottom.
[19:11] <_paneb> bzr merge the.main.branch: does this merge the.main.branch into my local branch?
[19:13] <arj> yes
[19:30] <_paneb> then i would do commit to update the.main.branch?
[19:30] <arj> you merge
[19:31] <luks> what do you mean by 'to update'?
[19:31] <arj> and if you're happy with the merge, you commit in your local branch
[19:32] <_paneb> ok, suppose there is a main branch somewhere. i created a checkout from it and added some changes. then i want to commit those changes to the main branch
[19:33] <luks> then you just commit
[19:34] <awilkins> Yes, checkouts are bound to their parent branch
[19:34] <_paneb> ah yea right
[19:35] <_paneb> now, if i weren't using a checkout, how would it go? i would have to merge the main branch into my local one and then push the local one?
[19:35] <luks> commit and then push
[19:35] <_paneb> ok
[19:35] <luks> commit+push in a standalone branch is basically the same as commit in a checkout
[19:36] <_paneb> ok
[19:36] <luks> you only need to merge if the main branch has changed since you branched it
[19:36] <luks> and in that case, 'bzr push' would complain
[19:37] <_paneb> ah
[19:37] <_paneb> thank you
[20:16] <pbor> after a rebase, how can I turn all my locally committed changesets in a single changeset?
[20:29] <MattCampbell> What's the recommended way to install a recent version of bzr on Debian Etch?
[20:55] <MattCampbell> If I create branches from several existing directories, can I later combine those into a single branch containing those directories?
[20:55] <fullermd> Yes.
[20:58] <MattCampbell> So I suppose if I'm not sure about how to organize files and directories under version control, I should start off with several small branches and then combine later if that seems better.
[20:59] <fullermd> Yeah.  Combining them is easier than splitting them up [without losing history].
[23:47] <poolie> hello all
[23:47] <beuno> mornin' poolie
[23:52] <igc> morning all
[23:52] <igc> morning beuno
[23:54] <beuno> mornin' igc
[23:58] <Peng> So it seems going to the bzr+http smart server in a browser, doing a GET, returns a 404. I wish I had known that before
[23:59] <Peng> I spent ten minutes figuring out why it was broken, when I just wasn't accessing it right. :P
[23:59] <Peng> How'd I hit Enter in the middle of that? Shift, I guess.


[00:09] <waigani> thumper: http://reviews.vapour.ws/r/955/, thanks
[00:42] <katco> wallyworld_: fyi i plan on attending the stand up tonight
[00:42] <wallyworld_> wot? it's the weekend :-)
[00:43] <katco> wallyworld_: WHAT! no one told me! ;p
[01:14] <thumper> anastasiamac_: review done on your mega branch
[01:15] <thumper> anastasiamac_: I didn't go through all of it as I wanted some response on what I had suggested first
[01:17] <axw> katco: we lost you
[01:17] <katco> axw: doh
[01:34] <anastasiamac_> thumper: it's amazing! thnx :D i wasn't expecting u to have a chance to look but really appreciate u did!
[02:17] <anastasiamac_> thumper: sendError() on httpHandler only takes an error message
[02:18] <thumper> I know
[02:18] <anastasiamac_> thumper: i need both coe and message :D hence an additional sendError method that taeks and error instead of string
[02:18] <thumper> anastasiamac_: read my answer again, and if you still have questions, we should talk
[02:18] <thumper> but OTP right now
[02:27] <axw> wallyworld_: I forget if I already sent you this link before, this is my WIP for the storage provisioner: https://github.com/axw/juju/tree/worker-storage
[02:28] <wallyworld_> thanks, will look after i finishing looking at the storage lifecycle branch
[02:28] <axw> wallyworld_: thanks. it doesn't need review, just an FYI
[02:29] <wallyworld_> kk
[03:46] <wallyworld_> axw: in type VolumeParams struct, should the Attachment field be of type *VolumeAttachmentParams rather than *AttachmentParams?
[03:46] <axw> wallyworld_: yeah, I think so
[03:46] <wallyworld_> ta, will fix
[03:46] <axw> I was thinking not before, but there may be volume-specific attachment params
[03:47] <wallyworld_> yeah
[03:57] <wallyworld_> axw: the path == "" check in rootfs createfilesystem - you say that the path value in FilesystemAttachmentParams should be set by the caller - that would imply it's up to the storage provisioner to set it. But the storage provisioner would then need to keep track of the ConfigStorageDir param. It is not easier to keep the code as is and let rootfs provider use a default path?
[03:57] <axw> wallyworld_: hold up, need to refresh my memory
[03:57] <wallyworld_> http://reviews.vapour.ws/r/956/
[03:58] <axw> wallyworld_: do you mean location==""?
[03:58] <wallyworld_> axw: i've change location to path
[04:00] <axw> wallyworld_: hmmm. so, this is a provider-independent thing. I think it's unnecessarily onerous to make it the responsibility of the provider to come up with a unique path to mount at
[04:00] <axw> wallyworld_: I think I'
[04:01] <axw> d prefer if we just had the storage provider set location to /var/lib/juju/storage/<source>/tag
[04:01] <wallyworld_> axw: that's what storageDir is for
[04:01] <wallyworld_> it's the only thing it is used for atm
[04:01] <wallyworld_> i guess it can be the absoluet tpath
[04:02] <wallyworld_> but then we'd not need the attachment params path attr
[04:02] <axw> wallyworld_: I don't see why the provisioner having to track ConfigStorageDir is a problem. in fact, it doesn't track it, it specifies it based on the agent's data-dir
[04:02] <axw> wallyworld_: yes we do, because the user can specify path
[04:03] <axw> wallyworld_: this storage-dir path should only be used if the user didn't specify one
[04:03] <axw> s/user/charm author/
[04:03] <wallyworld_> right, ok. then perhaps the config attr should be called DefaultStorageDir
[04:04] <axw> wallyworld_: actually I don't think that config attr should come into it
[04:05] <axw> wallyworld_: that directory was meant to be for storing info about volumes and filesystems
[04:05] <axw> wallyworld_: not for where the mount points end up
[04:05] <axw> wallyworld_: e.g. in the loop provider, we should create the file in ConfigStorageDir, but then mount it at "location"
[04:07] <wallyworld_> ok, so we need to ensure then that Path is always set, and the provider needs to choose a sensible location if the user doesn't specify one
[04:07] <wallyworld_> provisioner
[04:07] <axw> right
[04:08] <wallyworld_> np. the way i've had it till now is how we had id in the feature branch
[04:08] <wallyworld_> but that was all done for the demo
[04:39] <menn0> axw: hiya. in environs/cloudinit/cloudinit.go:AddAptCommands, do you know why required packages aren't being installed when enable-os-refresh-update is false
[04:39] <menn0> ?
[04:39] <menn0> axw: it means that rsyslogd is completely broken when enable-os-refresh-update is turned off.
[04:40] <axw> menn0: I think it's because some of the packages may not be found, because they're in cloud-tools
[04:41] <menn0> axw: i feared that there might be some complication like that.
[04:41] <axw> menn0: rsyslogd-gnutls should always be found I think ... we could be more selective there
[04:41] <menn0> axw: yeah rsyslog-gnutls is needed in order for logging to work
[04:46] <axw> wallyworld_: were there specific tests you found missing in my branch, apart from the existing tests you mentioned?
[04:46] <axw> wallyworld_: I've identified a problem with the RemoteStorageInstance test, and I ended up removing that method
[04:47] <axw> since I don't think it should be possible to remove a storage instance directly, only destroy & remove attachments which will do the job
[04:47] <wallyworld_> axw: mainly just tests to check that the business logic rules that cause the txns to retry when things are done concurrently
[04:47] <axw> wallyworld_: ok
[04:47] <wallyworld_> do you know the bits i mean?
[04:48] <wallyworld_> around checking for attachment count > 0 (or = 0) etc
[04:48] <wallyworld_> can't recall specifics
[04:48] <axw> wallyworld_: yup
[04:49] <wallyworld_> menn0: if you set refresh to false, you are promising to juju that your image has everything needed
[04:49] <wallyworld_> that's why it's true by default
[04:50] <menn0> wallyworld_: i'm doing scale tests with just the ubuntu charm so I figured it would be safe to turn off to speed things up
[04:50] <menn0> wallyworld_: i'll turn it back on for now
[04:50] <wallyworld_> ah, i see
[04:51] <wallyworld_> menn0: what series are you using? precise? trusty?
[04:51] <menn0> wallyworld_: this is trusty on EC2
[04:51] <wallyworld_> hmmm, i would have hoped trusty would be ok with false
[04:51] <wallyworld_> :-(
[04:52] <menn0> wallyworld_: i'm not convinced the logic in juju is quite right. as axw also indicates, there are probably some package that should always get installed even if an apt-get update isn't being done.
[04:53] <wallyworld_> yeah, that is true
[04:53] <wallyworld_> it's a blunt instrument right at the moment
[04:56] <axw> wallyworld_: most of these tests can't be done concurrently, because of lack of support for shared storage. e.g. in theory you could add unit, then concurrently add another unit and remove the first one's attachment, ensuring the instance isn't removed
[04:56] <axw> but we can't do the in theory bit yet
[04:56] <axw> I'll do what I can, but I don't think it's much
[04:56] <wallyworld_> ok, just wanted to be really sure that if itwere possible to test the bad cases, we could
[04:57] <wallyworld_> axw: there's 2 choices with the Path passed to rootfs provider already existing - 1. be really paranoid and assume that another storage is already using that path and return an error (will revisit later when shared storage supported), or 2. see if dir is empty and return an error if not
[04:58] <wallyworld_> or 3. - something else?
[04:58] <wallyworld_> eg just let it slide, but i don't think we should do that
[04:58] <axw> wallyworld_: we should be guaranteeing #1 is not a possibility, I think
[04:59] <axw> in which case, #2
[04:59] <wallyworld_> axw: that's the provisioner's job yeah
[04:59] <wallyworld_> hence i was also leaning to#2
[04:59] <axw> wallyworld_: partially, we also need to prevent multiple storage instances with the same path
[04:59] <axw> storage attachments*
[05:00] <axw> i.e. explicitly specified path in the charm metadata
[05:00] <wallyworld_> yes, but not inside rootfs
[05:00] <axw> yep
[05:00] <axw> I mean at a level higher than the provisioner, and also in the provisioner
[05:00] <wallyworld_> yeah
[05:00] <wallyworld_> i'll add the empty check to rootfs
[05:01] <wallyworld_> axw: you going to land the disktag rename pr?
[05:01] <axw> wallyworld_: I'll do it later, I'd like to get the state one fixed first
[05:02] <wallyworld_> ok
[05:02] <axw> wallyworld_: it's just a sed to fix up
[05:02] <wallyworld_> my rootfs one depends on it also, but it can wait
[05:03] <axw> wallyworld_: it depends on my branch?
[05:04] <axw> wallyworld_: can you just land using DiskTag, and I'll fix up later?
[05:04] <wallyworld_> axw: i added filesystemtag on top of your volumetag branch in juju/names
[05:04] <axw> ah, right
[05:04] <axw> wallyworld_: I'll land it now then
[05:04] <wallyworld_> it's no biggies, i can wait
[05:04] <wallyworld_> i'm still fixing the rootfs branch
[05:24] <axw> wallyworld_: merged
[05:24] <wallyworld_> axw: awesome, ty
[05:58] <wallyworld_> axw: http://reviews.vapour.ws/r/956/ has been updated; once you are free from your other stuff, would be great if you could look. i have to duck out to do school pickup, so bbiab
[05:58] <axw> wallyworld_: thanks, just pushing changes to http://reviews.vapour.ws/r/969/ too
[05:58] <wallyworld_> ok, will look as soon as i'm back
[06:25] <jam> thumper: did you manage to get the rework from executive summary through the rest of the JES CLI document?
[06:25] <thumper> jam: yes
[06:25]  * thumper shouldn't be here
[06:53] <axw> wallyworld_: ;) I can rename it to "TestCDSIRSARI" ? ;)
[06:53] <wallyworld_> yeah, why not :-)   .... kidding :-)
[07:09] <dimitern> hey wallyworld_, thanks for that cloud-image-utils fix for precise
[07:10] <wallyworld_> dimitern: hi there, and thanks for landing
[07:10] <wallyworld_> dimitern: did you see the little govet issue in provisioner.gp?
[07:10] <dimitern> wallyworld_, np
[07:10] <dimitern> wallyworld_, mm no?
[07:10] <wallyworld_> checking: go vet ...
[07:10] <wallyworld_> apiserver/provisioner/provisioner.go:1028: arg addr for printf verb %q of wrong type: *github.com/juju/juju/state.IPAddress
[07:11] <wallyworld_> was introduced yesterday i think
[07:11] <dimitern> wallyworld_, cheers, I'll have a look
[07:11] <wallyworld_> there's about 6 of them
[07:11] <jam> wallyworld_: sabdfl just gave a +1 on storage CLI
[07:11] <jam> and liked your layout
[07:11] <wallyworld_> i hope we can release 1.22 finally :-)
[07:11] <wallyworld_> jam: that's awesome news, ty
[07:12] <wallyworld_> none of us liked the CLI n the spec
[07:12] <jam> he really liked using the "juju status --help" syntax to understand how it all looks
[07:12] <wallyworld_> yeah, that approach was done with the juju metadata stuff for tools and images
[07:13] <jam> wallyworld_: can you do the edits to the actual Storage Spec ?
[07:13] <wallyworld_> jam: yep, can do, just need to check i have dit permissions
[07:13] <wallyworld_> edit
[07:14] <jam> I think I gave you edit for the last round
[07:14] <wallyworld_> yep, just checked
[07:17] <dimitern> wallyworld_, where have you seen these go vet warnings? I've run go vet ./... on trunk now and 99% of what I get is "using unkeyed fields"
[07:18] <anastasiamac> jam, wallyworld_: thnx for nice storage CLI approval :D
[07:18] <wallyworld_> dimitern: i basically saw it when i pushed my branch, after rebasing. it is a legit error - %q expects a string
[07:18] <jam> anastasiamac: wallyworld_: thanks for a nice proposal :)
[07:18] <dimitern> wallyworld_, and in that case you've mentioned "%q" for a *state.IPAddress is fine, because it has String() method
[07:19] <anastasiamac> jam: wallyworld_and axw proposed:D i just had fun with 3 level commands :)
[07:19] <dimitern> so it's not a string but it's a Stringer
[07:19] <wallyworld_> dimitern: so, it's the pre push hook that is invoking go vet - perhaps there's a warning level that's different?
[07:20] <dimitern> wallyworld_, I'm not sure I have that pre-push hook configured locally - what should I do?
[07:20] <wallyworld_> dimitern: the pre-push hook should be in VCS
[07:21] <wallyworld_> in the scripts dir
[07:21] <dimitern> wallyworld_, ok, but do you enabled it somehow?
[07:21] <dimitern> enable*
[07:21] <axw> anastasiamac: cool :)
[07:22] <jam> dimitern: you have to edit .git/config
[07:22] <wallyworld_> yeah, i can't remember exactly - it should be on the contributing page
[07:22] <anastasiamac> wallyworld_: u know how i could not get my PR to have RB request?
[07:22] <dimitern> jam, wallyworld_ , ok, will do
[07:22] <anastasiamac> wallyworld_: and i had to resolve conflicts and re-propose?
[07:22] <wallyworld_> which branch?
[07:23] <anastasiamac> wallyworld_: well, i have just pushed to the same PR and found that there are conflicts again... The RB is not updated tho :(
[07:23] <anastasiamac> wallyworld_: block-cmd-update...
[07:23] <wallyworld_> 967?
[07:23] <anastasiamac> wallyworld_: https://github.com/juju/juju/pull/1638
[07:23] <anastasiamac> yes
[07:24] <wallyworld_> if rb isnot updating, let eric know and he might be able to help fix it
[07:24] <anastasiamac> wallyworld_: and btw, u r no longer on PM
[07:24] <wallyworld_> i am on free node
[07:25] <wallyworld_> i can also see channels on canonical server
[07:25] <anastasiamac> wallyworld_: couple of minutes ago, i was told u were not ;D
[07:26] <axw> jam: thanks for fixing my blunder in liveSource
[07:26] <wallyworld_> anastasiamac: go figure, i have no idea wtf is happening with my stupid network
[07:27] <anastasiamac> wallyworld_: u r putting it under a lot of pressure? :D
[07:28] <wallyworld_> not that i know of :-)
[07:33] <wallyworld_> anastasiamac: so i'd fix your merge conflicts and repush to GH and see if that then allows rb to updates
[07:34] <anastasiamac> wallyworld_: thnx :D will try, just one more push... :D
[08:15] <jam> menn0: scale testing sometime ?
[08:19] <TheMue> morning
[08:27] <menn0> jam: i've been doing exactly that
[08:27] <jam> menn0: k, I don't think I'd seen anything back from you, so just figured I'd give you a poke and see how its goin
[08:28] <menn0> jam: i
[08:29] <menn0> jam: i was going to contact you when I had some numbers. I have numbers for the logging to mongodb case but logging via rsyslog has been giving me problems.
[09:49] <perrito666> restore is finally landed
[09:49]  * perrito666 cries
[09:50] <dimitern> perrito666, \o/
[09:51] <perrito666> now its no longer just my problem :p
[10:16] <axw> perrito666: epic :)
[11:18] <anastasiamac> dimitern: o/
[11:19] <dimitern> anastasiamac, hey there
[11:19] <anastasiamac> dimitern: got trunk to resolve my conflicts and am getting test failures in apiserver/provisioner/prepare_test.go
[11:19] <anastasiamac> dimitern: how r u?
[11:20] <dimitern> anastasiamac, oh, let me have a look?
[11:20] <dimitern> anastasiamac, I'm better than last week :) - no blockers
[11:20] <anastasiamac> dimitern: ""cannot allocate addresses: dummy.NetworkInterfaces is broken"
[11:20] <anastasiamac> line138/288
[11:20] <anastasiamac> :D
[11:21] <dimitern> anastasiamac, hmm I mean can you paste the failures?
[11:21] <dimitern> anastasiamac, to see the context
[11:22] <anastasiamac> dimitern: http://pastebin.ubuntu.com/10370778/
[11:22] <anastasiamac> dimitern: really appreiate ur help :D
[11:22] <anastasiamac> appreciate even
[11:22] <dimitern> anastasiamac, right, have you merged the changes to the dummy provider?
[11:23] <anastasiamac> dimitern: ?
[11:23] <anastasiamac> dimitern: i got the trunk, created my branch and applied my changes
[11:23] <anastasiamac> dimitern: running tests, gives me this error :D
[11:23] <anastasiamac> dimitern: what m i missing?
[11:23] <anastasiamac> dimitern: :)
[11:23] <dimitern> anastasiamac, let me have a look..
[11:24] <anastasiamac> dimitern: do u want the link to PR?
[11:24] <dimitern> anastasiamac, my tests on trunk are passing, so maybe you haven't merged all changes?
[11:24] <dimitern> anastasiamac, yes please
[11:24] <anastasiamac> dimitern: https://github.com/juju/juju/pull/1652
[11:24] <anastasiamac> dimitern: RB http://reviews.vapour.ws/r/979/
[11:26] <dimitern> anastasiamac, looking
[11:26] <anastasiamac> dimitern: tyvm
[11:27] <TheMue> dimitern: ping
[11:27] <dimitern> anastasiamac, well, istm you haven't pulled everything in there from master - e.g. the apiserver/provisioner changes I made recently (#1646) require some changes in state (#1631) and the dummy provider (#1632)
[11:28] <dimitern> anastasiamac, these are probably missing (the last one for sure), hence the error
[11:28] <dimitern> TheMue, pong
[11:28] <anastasiamac> dimitern: k. thnx :D i'll double check!
[11:30] <dimitern> anastasiamac, i suspect you've merged master partially
[11:30] <TheMue> dimitern: stumbled over the usage of network.Address in state. once we use it directly, so w/o any tags, the other time we have already a local substitute with a tag giving the Scope field the name networkscope
[11:30] <dimitern> TheMue, can you give me examples?
[11:31] <dooferlad> dimitern: hangout?
[11:31] <dimitern> dooferlad, in 5m pls
[11:32] <TheMue> dimitern: yep, look at addmachine.go:45 and address.go:183
[11:32] <dooferlad> dimitern: sure.
[11:32] <TheMue> dimitern: similar with hostPort in address.go few line later too
[11:33] <dimitern> TheMue, I'll get back to you after my 1:1 with dooferlad, if that's ok
[11:34] <TheMue> dimitern: sure, thx
[11:54] <anastasiamac> dimitern: contacted on PM
[11:57] <dimitern> anastasiamac, sure, in a meeting will get back to you shortly
[12:16]  * TheMue is out for lunch
[13:09] <jam> dimitern: have you seen fwereade today?
[13:10] <dimitern> jam, no, but I've heard he's having connection issues
[13:10] <jam> k
[14:23] <jw4> OCR PTAL http://reviews.vapour.ws/r/981/  <-- fixes ./scripts/verify.bash pre-push hook warnings when using newer versions of go
[14:27] <perrito666> jw4: I would have expected the formatting function to call strig
[14:27] <perrito666> string
[14:28] <jw4> perrito666: agreed, but it seems %q isn't handled quite the same as %s
[14:29] <perrito666> jw4: wellI would assume it is, since the output of calling that actually works
[14:29] <jw4> perrito666: and I think it works, it's just that newer versions of go vet warn about it
[14:29] <perrito666> It sounds to me that govet is broken
[14:29] <jw4> perrito666: possibly
[14:29] <perrito666> ma windows takes a lot to download
[14:29] <perrito666> man*
[14:31] <perrito666> sinzui: ping me when you have a moment :) I am about to make you the happiest QA person in the world
[14:33] <sinzui> perrito666, really? you can tell me my our maas 1.5, 1.7, and 1.8  hate juju 1.22 and 1.23
[14:34] <perrito666> sinzui: no but, I just merged the last bit of restore :)
[14:34] <sinzui> perrito666, NOoooooo......
[14:35] <sinzui> perrito666, the restore tests have been very reliable this year. Why complete a feature to risk a failure?
[14:35] <sinzui> perrito666, sorry about the sarcasm
[14:35] <perrito666> sinzui: I have not nuked the old restore
[14:35] <perrito666> :p
[14:37] <dimitern> jw4, ping
[14:37] <perrito666> sinzui: I need to discuss with you how to do this, I could just make the old restore call the new one with parameters that make it do the same, but output might change
[14:38] <dimitern> jw4, yeah - go vet seems amiss here
[14:38] <jw4> dimitern: pong
[14:38] <sinzui> perrito666, we do need old restore to call new restore because enterprises may have scripted juju 1.18 restore.
[14:39] <jw4> dimitern: from previous experience I doubt we'll get go vet fixed if it is a bug in go vet, and anyone using go1.4+ won't be able to get past the pre-push hook
[14:39] <sinzui> perrito666, as for the output change, I don't think there is a contract for the output.
[14:39] <perrito666> sinzui: ack, btw, there are a couple of new test cases to add :p sorry
[14:39] <sinzui> perrito666, if CI fails because it scanned output, then we will change ci
[14:39] <jw4> dimitern: fwiw I'm about to propose a tweak to verify.bash that allows ignoring go vet with an envar
[14:40] <sinzui> perrito666, old restore only need to work its way. New cases can require the new restore
[14:41] <perrito666> sinzui: yes, the new cases are for the new restore, just sending a heads up
[14:41] <perrito666> will send you an email with details
[14:42] <dimitern> jw4, sure, sgtm, I'll have a look at your PR as well
[14:42] <jw4> dimitern: ta
[14:42]  * dimitern needs to start using go1.4
[14:42] <perrito666> dimitern: I am
[14:42] <sinzui> thank you very much perrito666 . the email will be helpful as I am not fully caffeinated.
[14:43] <perrito666> sinzui: I am on that process, I assisted a wedding on saturday and my liver seems to be off for repairs
[14:43] <sinzui> :)
[14:45] <jw4> dimitern: http://reviews.vapour.ws/r/982/ <-- allows environment variable to bypass go vet failing the pre-push hook
[14:45] <jw4> perrito666, OCR ^
[14:45] <dimitern> jw4, already approved :)
[14:46] <jw4> dimitern: thanks!
[14:46] <jw4> :)
[14:47] <dimitern> jw4, hmmm you know what? looking at your last PR gave me an idea
[14:47] <jw4> dimitern: yeah?
[14:48] <dimitern> jw4, it seems we're not adding Logf to the list of printfuncs in verify.bash, and it does seem 1.4 go vet reports only them, but not e.g. logger.Tracef one, which have %q as well
[14:48] <jw4> dimitern: I think Logf is automatically included and we have to explicitly add the others...
[14:49] <dimitern> jw4, ah, no - my mistake, go vet did report logger.Infof("assigned address %q to container %q", addr, container) for example
[14:49] <dimitern> jw4, so it's that
[14:49] <dimitern> it's not that even
[14:52] <dimitern> jw4, LGTM on the other one
[14:55] <jw4> tx dimitern
[14:56] <dimitern> np
[15:02] <sinzui> dimitern, natefinch can you find someone to look into a gccgo problem in bug 1424669
[15:02] <mup> Bug #1424669: ppc64el fail multiple definitions of juju_juju_api_networker.NewState <ci> <gccgo> <ppc64el> <regression> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1424669>
[15:02] <dimitern> sinzui, I was looking at this since saturday
[15:02] <dimitern> sinzui, it's another random ppc64 gccgo compiler issue
[15:02] <dimitern> sinzui, like the last blocker
[15:03] <dimitern> sinzui, I've requested access to a ppc64 machine to all me to run tests and analyze whether building a more recent version of gccgo will resolve this
[15:03] <sinzui> dimitern, It is consistent since those the commits, the ppc suite are not unreliable
[15:04] <sinzui> dimitern, I will get you access to stilson-09 in a few minutes
[15:04] <dimitern> sinzui, yes, but it only happens on ppc64, right?
[15:04] <dimitern> sinzui, ah, great!
[15:05] <sinzui> dimitern, yes, but the duplicate definition issue was identified to be a gccgo problem. Test need to be written a certain way to ensure the real impl isn't seen by the compiler
[15:05] <dimitern> sinzui, I can usually reproduce such gccgo issues easily on my trusty amd64 machine with gccgo, but not this one
[15:06] <dimitern> sinzui, hmm is there some document or instructions on this?
[15:07] <sinzui> dimitern, I don't know, jam and wallyworld fixed the bugs in the past
[15:08] <sinzui> dimitern, I think the issue related to passing interfaces vs passing strings
[15:08] <dimitern> sinzui, ok, I'll look into that
[15:16] <aisrael> natefinch: Have you had a chance to look more into bug 1424069?
[15:16] <mup> Bug #1424069: juju resolve doesn't recognize error state <juju-core:New> <https://launchpad.net/bugs/1424069>
[15:18] <natefinch> aisrael: no, sorry, haven't put any more time into it.  I'll spend some time trying to figure it out today.
[15:18] <aisrael> natefinch: much appreciated. It's a bit of a blocker for me, unfortunately
[15:55] <sinzui> natefinch, dimitern : The QA team are looking for advice regarding bug 1424695. We don't know if this issue is juju or CI. We are happy to change CI to make juju pass
[15:55] <mup> Bug #1424695: cloud-init cannot download agent from state-server <ci> <maas-provider> <network> <regression> <trusty> <juju-core:Triaged> <https://launchpad.net/bugs/1424695>
[15:56] <dimitern> sinzui, I'll look into it
[15:56] <sinzui> dimitern, we are working on getting logs, so the bug is reported from my memory
[15:57] <dimitern> sinzui, yeah logs will be good to have - I've been monitoring those failing maas jobs on 1.22 for a few days
[15:58] <sinzui> dimitern, if John's fix isn't ready for the next run, we will intercept machine-1 before it is destroyed
[15:58] <dimitern> sinzui, great, please let me know
[16:15] <alexisb> natefinch, do you think that https://bugs.launchpad.net/juju-core/+bug/1424069 may be a result of current LE work?
[16:15] <mup> Bug #1424069: juju resolve doesn't recognize error state <juju-core:New> <https://launchpad.net/bugs/1424069>
[16:16] <ericsnow> wwitzel3: http://reviews.vapour.ws/r/983/
[16:26] <natefinch> alexisb: no idea, I'm working on investigating it now.  At least it's easily reproducible
[16:26] <alexisb> natefinch, ack
[16:29] <wwitzel3> ericsnow: will take a look
[16:29] <ericsnow> wwitzel3: ta
[16:37] <TheMue> dimitern: beside the types to move we also have methods on State responsible those types (would be nice to move them too) and which use the package private network related docs, like ipaddressDoc
[16:44] <dimitern> TheMue, that sounds like a good idea, but can it be done?
[16:44] <dimitern> TheMue, i.e. state.State can't have methods defined on it in a subpackage
[16:45] <TheMue> dimitern: I'm currently checking, many depending places
[16:46] <TheMue> dimitern: yes, otherwise the new sub-package has to provide functionality used by those functions
[16:46] <TheMue> dimitern: like e.g. State.AddIPAddress()
[16:46] <TheMue> dimitern: a wonderful candidate
[16:46] <TheMue> :)
[16:47] <dimitern> TheMue, yeah :)
[16:48] <TheMue> dimitern: thinking of a NetworkState type in the network package, returned by State and containing all needed data
[16:48] <TheMue> dimitern: and then move the methods to this type
[16:49] <dimitern> TheMue, experiment a bit and I'll see what you've pushed later
[16:49] <TheMue> dimitern: so nwst := st.NetworkState() and nwst.AddIPAddress()
[16:49] <TheMue> dimitern: will do
[17:44] <dimitern> TheMue, can I get an LGTM on this fix for the blocker bug please? http://reviews.vapour.ws/r/986/
[17:46] <dimitern> natefinch, perrito666, ^^
[17:48] <dimitern> katco, ^^
[17:48] <dooferlad> TheMue / dimitern: could you take a look at this monster diff? https://github.com/juju/juju/pull/1657 Two whole lines!
[17:49] <dimitern> dooferlad, looking :)
[17:51] <dimitern> dooferlad, reviewed
[17:52] <dooferlad> dimitern: thanks!
[17:52] <dooferlad> dimitern: Doh! Good point!
[17:53] <dimitern> dooferlad, ;) np
[17:53] <dimitern> ericsnow, ping
[17:53] <ericsnow> dimitern: hey
[17:54] <dimitern> ericsnow, hey :) I'm glad someone is around - can I get an LGTM on this fix for the blocker bug please? http://reviews.vapour.ws/r/986/
[17:54]  * ericsnow takes a look
[17:54] <dimitern> ericsnow, thanks!
[17:57] <ericsnow> dimitern: done
[17:57] <dimitern> ericsnow, cheers
[18:03] <mbruzek> ahoy abentley!  We are seeing an error on the automated testing system.  Can you take a look?  http://juju-ci.vapour.ws:8080/job/charm-bundle-test-azure/46/console
[18:04] <mbruzek> abentley: I see a few error messages in there that I don't know how to resolve.
[18:04] <mbruzek> ERROR cannot assign unit "kubernetes/0" to machine 2: unit placement is not supported with availability-sets-enabled
[18:08] <dimitern> mbruzek, AFAIK azure does not support --to for deployments
[18:08] <mbruzek> dimitern: OK I thought it was just a setting in the azure setup that we could change.
[18:08] <dimitern> mbruzek, when you have "availabiliy-sets-enabled: true" set
[18:09] <mbruzek> dimitern: could we set that to false?
[18:09] <mbruzek> or do we need that?
[18:09] <dimitern> mbruzek, I suppose if you haven't heard of it you don't need it :)
[18:09] <dimitern> mbruzek, it's an env.yaml setting
[18:10] <dimitern> mbruzek, but it's enabled by default for azure
[18:11] <mbruzek> dimitern: We want to be able to pass on Azure, and our bundle needs some co-located charms for it to work.
[18:12] <mbruzek> dimitern: So are you saying that if we set that to false, Azure will not honor the --to command?
[18:12] <dimitern> mbruzek, so then try adding "availability-sets-enabled: false" in your env.yaml for that environment and bootstrap again (it can't be changed after bootstrap)
[18:12] <dimitern> mbruzek, I'm saying the opposite :)
[18:13] <mbruzek> dimitern: OK.  This is the automated CI system I need abentley or sinzui to help with that.
[18:13] <dimitern> mbruzek, if it's false --to is supported
[18:13] <dimitern> mbruzek, +1
[18:13] <mbruzek> dimitern: thanks for your help
[18:14] <dimitern> mbruzek, np
[18:18] <dimitern> sinzui, one blocker down, one to go - but I'm at eod for some time now, so somebody else perhaps; getting logs from the machine (1,2) will definitely help there
[18:24] <sinzui> dimitern, I am almost to it.
[18:24] <dimitern> sinzui, great! I hope it works
[19:15] <sinzui> natefinch, abentley : we need to discuss bug 1424777
[19:15] <mup> Bug #1424777: local-provider precise failed to upgrade <ci> <local-provider> <precise> <regression> <upgrade-juju> <juju-ci-tools:New> <juju-core:Triaged> <https://launchpad.net/bugs/1424777>
[19:16] <abentley> sinzui: sure thing.  The usual hangout?
[19:16] <sinzui> abentley, sure
[19:18] <natefinch> sinzui: sure, the release meeting hangout?
[21:19] <thumper> rick_h_: around?
[21:19] <rick_h_> thumper: yep
[21:19] <rick_h_> for a bit, what's up?
[23:14] <alexisb> wallyworld, I will be back after bed time if you need to talk with me re releases
[23:38] <wallyworld> thumper: got 5?
[23:44] <wallyworld> sinzui: apt fix merged into 1.22
[23:50] <beisner> curious - is juju bootstrapping an enviro with   default-series:  vivid   defined in the environments.yaml expected to work at this point in the cycle?  i keep getting bootstrap timeouts attempting to do so.
[23:50] <sinzui> thank you wallyworld
[23:53] <beisner> ^ ERROR failed to bootstrap environment: waited for 10m0s without being able to connect: Permission denied (publickey).
[23:53] <beisner> ^ setting to default-series:  utopic   or  trusty succeeds.
[23:54] <beisner> if it's a no-op atm, please tell me to stop trying for now  ;-)
[23:55] <wallyworld> beisner: i thought it worked. sinzui, you have seen vivid work?
[23:56] <sinzui> beisner, it certainly work in our local provider tests.
[23:57] <beisner> sinzui, wallyworld - fyi that's using the openstack provider and the maas provider.
[23:57] <sinzui> beisner, are you using ppc openstack and vivid?
[23:58] <beisner> all amd64 here
[23:58] <beisner> for this one
[23:59] <sinzui> beisner, from my experience new ubuntu series do work, but you make need to create the images. We have built and published the agents (except for ppc64el)