[00:02] <mgz> gra, this is more of a mess than I thought
[00:03] <mgz> we have bug 485601 and one against bzr-svn
[00:04] <mgz> and dupes of each of those from both glyph and exarkun
[00:10] <mgz> sorry for the tag spam, should save searching by bug filer in future
[00:12] <mgz> the good news is we've fixed about half the found by twisted bugs
[00:13] <mgz> the bad news is the other half still has a lot of scary bugs in it
[00:54] <jelmer> https://bugs.launchpad.net/bazaar/+bugs?field.tag=affects-twisted
[03:40] <jdobrien> hello all. I am trying to use colo and pipelines together, I have a branch with a few pipelines and I would like to push on of them to launchpad and propose it for merging, but I'm missing something... my typical bzr push is not working with this scenario
[07:04] <jo-erlend_> what am I doing wrong? bzr branch bzr+ssh:jo-erlend@desktop.local:/devel/project
[07:04] <jo-erlend_> bzr: ERROR: Unsupported protocol for url "bzr+ssh:jo-erlend@desktop.local:/home/jo-erlend/devel/project"
[07:34] <vila> jo-erlend_: bzr+ssh://user@host/path , check your '/' and ':'
[07:34] <vila> mailto:bzr+ssh:jo-erlend@desktop.local:/devel/project
[07:34] <vila> grrr
[07:35] <vila> bzr+ssh://jo-erlend@desktop.local/devel/project is probably what you want
[07:36] <vila> hey guys, I encounter wm issues there bbiab
[07:57] <mgz> morning!
[07:57] <vila> mgz: pool time !
[07:57] <vila> err, sry wrong time frame ;)
[07:58] <mgz> :)
[08:35] <mgz> what's that tool jam and others were using to simulate a slow network for testing?
[08:35] <jam> mgz: the command is 'tc' let me poke at it, just a sec
[08:36] <jam> mgz: doc/developers/testing.txt
[08:36] <vila> mgz: see testing.txt in doc/developers
[08:36] <jam> "simulating slow networks"
[08:36] <vila> :)
[08:37] <mgz> ta.
[08:57] <vila> mgz, jelmer: standup ?
[08:59] <mgz> tis time.
[09:03] <vila> jelmer: pingeling
[10:24] <mgz> precise babune eh.
[10:33] <vila> hpmf, no way to prepare surprises :)
[10:33] <vila> started on the wrong foot but successful at the second run, not that bad
[10:39] <mgz> okay, woho, with the right bits installed I can reproduce some of these failures
[10:40] <vila> for which value of 'these' ?
[10:41] <mgz> the url normalisation regressions that broke the windows buildbot
[10:41] <vila> \o/
[10:41] <mgz> ...and the sftp tests leak threads
[10:42] <mgz> the isolation failure ones are drive name specific
[10:42] <mgz> but the tilde handling is a general issue
[10:42] <vila> ouch, for these ones, reproducing is far away from fixing (IIRC paramiko just won't let you wrap the thread creations)
[10:42] <mgz> Gio also fails some tests
[10:42] <vila> gio ? on windows ?
[10:42] <mgz> no, I haven't got windows here
[10:43] <mgz> which is a bit daft, because three of the things I need to finish from last week could do with being tested there
[10:43] <vila> o.O
[10:44] <mgz> anyway, this:
[10:45] <mgz> `mkdir /tmp/tilde~ && TEMP=/tmp/tilde~ ./bzr selftest -s bt.per_transport SFTP`
[10:45] <mgz> works to get 4 of the failures from babune
[10:46] <vila> oooh
[10:46] <vila> urgh
[10:47] <mgz> regression from r6079 see bug 842223
[10:48] <vila> yeah, but I haven't realized it could be triggered that easily..
[10:50] <mgz> I can probably write a specific test here now, which will mean I can fix (or at least fiddle with till that test passes) the handling
[10:50] <mgz> the url code makes me unhappy
[10:51] <mgz> we still have the other windows babune issue, which is the failure to remove shell script thing
[10:52] <vila> forget about that one, too obscure to diagnose and probably involve both vbox and jenkins and the phase of the moon
[10:53] <vila> well, it may also just be a hang :)
[10:53] <vila> ... that leads to a vm being killed which itself forbids jenkins to remove a file from a dead host
[10:55] <mgz> yeah.
[11:28] <hrw> hi
[11:29] <hrw> how to commit 2 lines from file with other changes? 'bzr commit --interactive' operates on diff hunks which are too big in this case
[11:37] <mgz> hrw: shelve everything you don't want to commit right now
[11:38] <hrw> mgz: ok, so other option then revert edits
[11:39] <mgz> if you set a change editor, you can pick out which parts to shelve on a sub-hunk basis
[12:01] <samebchase> Hi, I'm unable to do: bzr launchpad-login
[12:01] <samebchase> I am behind a proxy
[12:02] <samebchase> The error message I get is: bzr: ERROR: Connection error: Couldn't resolve host 'launchpad.net' [Errno -2] Name or service not known
[12:02] <samebchase> Can someone please advise me as to what I should be doing?
[12:12] <mgz> samebchase: can you ssh to arbitrary servers?
[12:12] <samebchase> mgz: yeah
[12:12] <samebchase> In the meantime, however
[12:13] <samebchase> I've been able to bzr branch a repo
[12:14] <mgz> then you can do everything you really need, just set launchpad_username by editing ~/.bazaar/bazaar.conf
[12:14] <samebchase> mgz: oh. let me try that
[12:15] <samebchase> Did what was told here:  http://www.omappedia.org/wiki/Using_bzr_and_launchpad_behind_a_proxy
[12:15] <mgz> otherwise you'll be able to branch (anonymously) over http, but not push
[12:15] <samebchase> hmm
[12:16] <mgz> okay, if you followed that you'll be okay
[12:16] <mgz> just need to set username, and give launchpad your public key if you've not already
[12:17] <mgz> then can try pushing something to lp:~/+junk/testbranch
[12:17] <mgz> may need ~yourusername if you've got an older bzr version
[12:21] <samebchase> I've added launchpad_username = samebchase
[12:21] <samebchase> I've already added my public key
[12:23] <mgz> if your test branch was using bzr+ssh: as per that page rather than lp: then you're probably all done
[12:23] <samebchase> mgz: Thanks a lot for your help. I've got to go out now, sorry!
[12:23] <samebchase> mgz: will have to figure out the rest later tonight
[12:24] <samebchase> mgz: thanks!
[13:09] <jelmer> grmbl, clearly this is not my day
[13:10]  * mgz gives jelmer a cupcake
[13:10]  * jelmer has been fighting with bzr-builddeb code all morning
[13:11] <jelmer> thanks mgz :)
[13:16]  * vila offers a coffee ;)
[13:17] <vila> jelmer, mgz: should we do the standup now ?
[13:21] <jelmer> vila: might as well
[13:21] <jelmer> vila, mgz: 13:30 UTC ?
[13:21] <vila> jelmer: cool, feel free to vent if it helps ;)
[13:21] <vila> 10 mins from now is good for me
[13:27] <mgz> there was talk of lunch heree, but I have a feeling it's still a way off
[13:29] <mgz> lets do it, I can eat later
[13:36] <jo-erlend> where does bazaar explorer store its bookmarks?
[15:34] <webm0nk3y> I'm having trouble in a colocated branch. I started a new branch and now I have a bunch of conflicts from work in another branch
[15:36] <jelmer> jo-erlend: my guess is somewhere in .bzr/branch/branch.conf ?
[15:36] <jelmer> webm0nk3y: hi
[15:37] <webm0nk3y> jelmer: hi
[15:40] <psusi> bzr doesn't have any cherry pick tracking?  Is that a feature that is coming any time soon? ;)
[15:41] <jelmer> webm0nk3y: can you provide a bit more background?
[15:41] <webm0nk3y> jelmer: sure
[15:41] <webm0nk3y> jelmer: actually I think I goofed up
[15:41] <webm0nk3y> jelmer: I did bzr colo-branch <new branch>
[15:41] <webm0nk3y> jelmer: then started hacking
[15:42] <jelmer> psusi: no, there is no cherry picking tracking at the moment. we have some ideas about it, but it's hard to implement cherrypicking tracking in a way that doesn't impact merge
[15:42] <jelmer> psusi: *merge performance
[15:44] <psusi> drat... I'm trying to find a way to give two branches a common ancestor that don't already have one ( because one is built from tarball release )... was hoping cherry picking could do it... oh well...
[15:45] <jelmer> psusi: you can do that without cherrypicking
[15:45] <jelmer> psusi: "bzr merge -r0..-1 <other-branch>"
[15:46] <psusi> revision -1?
[15:46] <jelmer> psusi: it works like in python. -1 is the last revision
[15:46] <jelmer> "bzr merge-r0.. <other-branch>" would work too
[15:47] <psusi> won't that result in all kinds of conflicts as merge tries to pull in changes that already exist here?
[15:48] <jelmer> psusi: you can revert the changes afterwards ("bzr revert .") to only add the new parent
[15:49] <psusi> hrm... so in other words, it will make a mess, but I can just sweep it all under the rug, and when I commit the merge, the history will be knit together?
[15:50] <jelmer> psusi: sortof :)
[15:50] <psusi> as long as the rev I'm merging from actually is common between the two branches then it should work out... hrm...
[15:52] <psusi> so let me see if I've got this... what I'm trying to solve is that the ubuntu package merges from the debian package... the debian package merges from what it calls 'upstream' but is really just a branch they unpack the upstream release tarball into...
[15:52] <jelmer> ah
[15:53] <jelmer> I'm not really sure if the "merge -r0..-1" trick will really be useful in that case
[15:53] <jelmer> you can stitch the history together but the file ids will still be different
[15:53] <psusi> if I find the correct upstream revision that the tarball came from, I can take the debian branch, and do a full merge from that upstream revision, revert the conflicts, and after commit, the debian branch will have a common ancestor with upstream, allowing merge from upstream into the debian branch, or the ubuntu branch ( after it merges from debian )
[15:54] <psusi> so that should be ok as long as debian starts merging from upstream instead of tarballing it, but if they keep tarballing, it will make for messy conflicts?
[15:55] <jelmer> what is upstream in?
[15:55] <psusi> ultimately, git.kernel.org... but lp is auto importing that into a bzr branch
[15:55] <jelmer> ah, hmm
[15:56] <jelmer> this is the "parallel import" use case
[15:57] <psusi> I guess so?  debian pulls from upstream but via tarball... I'd like to pull from upstream properly... two paths for upstream to get into our repository...
[16:01] <jelmer> psusi: in order for bzr to be able to deal with that properly it has to somehow know that a particular upstream revision and a particular revision from debian should be considered the same
[16:01] <jelmer> psusi: we don't have a mechanism that does that yet
[16:02] <psusi> jelmer: isn't that what you would get by doing that merge, revert conflicts, commit dance?
[16:03] <jelmer> psusi: no, that will stitch the history together but won't actually make bzr consider two revisions the same
[16:05] <psusi> jelmer: isn't that enough?  why does it need to consider them to be the same?
[16:20] <Noldorin> why do the windows releases for bzr beta always come latest?
[16:21] <vila> Noldorin: hear hear ! We have a new volunteer to build the installers :)
[16:21] <Noldorin> you guys do know windows has far many more bzr users than Mac? :-P
[16:21] <Noldorin> and probably most linux distros
[16:21] <Noldorin> ha
[16:22] <Noldorin> vila, nah just questioning priorities. it's too hard for me ;-)
[16:22] <vila> ... but far less volunteers, yeah, that's the key :-/
[16:22] <Noldorin> vila, i tried before and failed miserably.
[16:22] <vila> :-(
[16:22] <Noldorin> vila, if you want to help me get the installer building here, i would consider it though.
[16:23] <vila> Noldorin: try pinging jam and/or mgz, windows is out of my league (not to mention my plate ;)
[16:23] <Noldorin> hah ok
[16:23] <Noldorin> vila, you're a core dev eh?
[16:23] <Noldorin> jam, mgz hi
[16:23]  * vila nods
[16:24] <Noldorin> vila, while you're hear...will co-located branches make it into bzr-core for 2.5 final?
[16:24] <vila> there are strong hopes for that yes
[16:25] <Noldorin> cool
[16:25] <jelmer> psusi: it needs to stitch the individual file histories together for that as well
[16:26] <mgz> jelmer: updates to info-empty-controlir and verify-remote-signatures look good, but have conflicts to sort out before landing
[16:26] <Noldorin> vila, and will the URL format improve? i mean something more like url,colo-branch instead of url,branch=colo-branch
[16:27] <vila> It is still planned AIUI
[16:27] <mgz> Noldorin: yes, the setup needed for windows installers is a little out of most people's reach currently
[16:27] <Noldorin> hmm
[16:28] <Noldorin> mgz, don't you guys have a build server? :-)
[16:28] <Noldorin> vila, AIUI?
[16:28] <vila> As I Understand It
[16:28] <Noldorin> ok
[16:28] <Noldorin> vila, so posibly by final release...
[16:28] <vila> yup
[16:28] <mgz> there are a lot of manual things to do, that aren't easy to automate
[16:28] <Noldorin> :-)
[16:29] <Noldorin> vila, good work on all the rest, i do say. very happy with the beta so far
[16:29] <vila> thanks, very much appreciated, will repeat it to responsible parties ;)
[16:29] <Noldorin> vila, it makes me glad because i can still resist the Git movement heh ;-)
[16:30] <jelmer> mgz: thanks
[16:30] <vila> resistance is not futile :)
[16:30] <Noldorin> mgz, ah okay. just thought the bzr guys, being such proponents of agile/iterative dev and all, would have a CI server up. but fair enough
[16:30] <Noldorin> what sort of environment does it require?
[16:31] <vila> there *is* a CI server, it's used for tests so far ;)
[16:31] <vila> http://babune.ladeuil.net:24842/
[16:31] <Noldorin> vila, indeed. my minimalist attitude won't let me use git. bzr if i can, hg if i have to
[16:31] <Noldorin> vila, oh ok :-)
[16:31] <Noldorin> that's a good start
[16:32] <Noldorin> Jenkins looks pretty nice. plan on using it for my own projs
[16:35] <Noldorin> vila, mgz in fact i will be setting up my personal bulid server later this week. perhaps we can talk about setting up a Windows installer build then
[16:35] <Noldorin> brb
[16:35] <vila> Noldorin: that would rock !
[16:54] <Noldorin> vila, yeah, will get back to you soon about it i hope :-)
[16:59] <jelmer> mgz: any chance of an update to the MPs?
[17:30] <mgz> jelmer: done
[17:30] <jelmer> mgz: thanks!
[17:50] <mgz> okay, confusing bug state again.
[17:50] <mgz> fullermd's bug is actually fixed, and is basically the cause of the current complaint.
[17:50] <mgz> so in other words, it's his fault.
[18:00] <vila> mgz: and ? You're surprised ???
[18:00] <vila> :-D
[18:01]  * vila is not even here
[18:04] <Noldorin> back
[18:05] <mgz> Noldorin: your step one should be just running `bzr selftest` locally and seing if you have any issues.
[18:08] <fullermd> Hmmwhut?  I didn't do it.  I was never even in that warehouse, and where would I get that much napalm anyway?
[18:09] <Noldorin> mgz, once i get the build server up and running you mean? :-)
[18:09] <mgz> bug 148030 fullermd :)
[18:10] <mgz> Noldorin: well, I imagine those tasks could be parallelised if you're using bzr on your local machine too :)
[18:10] <fullermd> Oh.  I didn't _want_ to file that.  vila made me do it.  So it's really his fault.
[18:11] <Noldorin> mgz, yeah, although i'm using the exe rather than py version on my laptop so that i get tortoisebzr support
[18:11] <fullermd> That's probably why he's trying so hard to pin it on me above.  The very nerve!
[19:24] <vila> fullermd: me ? I don't even know what a lightweight checkout is ! You're the #1 on the list of people talking the most about them  !
[19:27] <fullermd> You sure do seem to know a lot about who talks about them.  SUSPICIOUSLY a lot, one might say...
[19:27] <mgz> vila: did anyone send the standup notes to the list?
[19:27] <mgz> and can you tell me what bugs I said I was working on this week...
[19:35] <mgz> okay, bug 842223 is this one
[20:15] <mgz> I'll post the standup notes for today to the list.
[21:48] <glyph> jelmer: hey
[21:48] <glyph> jelmer: are you around?
[21:49] <glyph> I'd like to fix Twisted's broken revisions
[21:49] <glyph> My understanding is that if we update the official Bazaar mirror to bzr-svn 1.1.1, then delete and re-generate everything, and tell everyone to stop pulling from svn and pull only from bzr-svn
[21:49] <glyph> that we will be okay
[21:50] <glyph> I am starting to think that the reason we were seeing that problem recently is that Launchpad's mirror has effectively done this already, so maybe we can save some time and pull from Launchpad's mirror rather than from svn
[23:44] <jelmer> 'evening
[23:44] <jelmer> glyph: hi
[23:50] <poolie> hi jelmer
[23:50] <Noldorin> hi jelmer
[23:50] <Noldorin> hmm...why does bzr not like symlink dirs in sitepackages?
[23:51] <jelmer> hi poolie, Noldorin
[23:51] <peitschie> hi jelmer :)
[23:51] <peitschie> and the rest :D
[23:51] <poolie> Noldorin, what do you mean?
[23:51] <jelmer> Noldorin: I think we just rely on Python there
[23:52] <jelmer> poolie: it looks like launchpad-buildd 95 worked, but 97 broke all recipe builds because it no longer installs apt_pkg
[23:52] <Noldorin> poolie, jelmer a symlink dir (on windows) in site-packages doesn't get picked up
[23:52] <Noldorin> whereas a real dir does
[23:52] <jelmer> poolie: oh, I see you're already talking in #-ops
[23:53] <poolie> yep
[23:53] <poolie> i'm uploading a fix now
[23:55] <jelmer> cool
[23:57] <Noldorin> jelmer, poolie not sure what bzr is doing to miss it
[23:57] <Noldorin> using the bundled win32 dist here
[23:57] <Noldorin> win7, x64
[23:58] <jelmer> Noldorin: does python work with a symlink dir?
[23:59] <Noldorin> jelmer, apparently so
[23:59] <Noldorin> jelmer, was just enquiring about that, but it seems it does