[00:00] <lifeless> I hope so :P
[00:05] <jml> hello
[00:05] <jml> I'm going to actually try to reproduce the problem with the steps I outlined.
[00:06] <jml> and then probably re-assign the bug to launchpad-code, and then trace what init_ex does on the server side.
[00:08] <lifeless> so
[00:09] <lifeless> init_ex is designed to do as much initialisation as the current logic then in bzr.dev permitted to be made unconditional or conditional on constant parameters
[00:09] <lifeless> and returns many results
[00:11] <mwhudson> jml: cool
[00:11] <lifeless> one way to do this would be to write an acceptance test for pushing to default stacked
[00:12] <jml> lifeless: that's definitely something we plan to do.
[00:15] <mwhudson> i thought we had such a thing
[00:15] <jml> mwhudson: I don't think we do.
[00:15] <mwhudson> oh right
[00:15] <mwhudson> we have puller tests to do with stacking
[00:15] <lifeless> I think if you did, it would have broken
[00:16] <mwhudson> "oops"
[00:16] <lifeless> or is itself broken
[00:16] <mwhudson> lifeless: right, i was going on the "we have a broken test" theory
[00:16] <mwhudson> i was wrong
[00:19] <vxnick> hi guys - I'm trying to push an update to launchpad but bzr is saying I need to merge then push (which I do) but to no avail
[00:20] <spiv> vxnick: did you commit the merge?
[00:20] <vxnick> yep
[00:20] <vxnick> I uncommitted the previous revision however
[00:20] <vxnick> because I put some bits in the wrong place so wanted to have them show under that revision
[00:20] <vxnick> rahter than a new one
[00:21] <spiv> vxnick: hmm.  Are you sure you've merged from the branch you are trying to push to?
[00:21] <vxnick> 100% sure
[00:21] <lifeless> vxnick: then you have to push --overwrite, because uncommit doesn't propogate automatically
[00:21] <vxnick> ah thanks
[00:21] <lifeless> vxnick: because its a form of history editing
[00:21] <vxnick> so I guess uncommit isn't ideal for push/pull scenarios?
[00:21] <lifeless> note that if you're pushing to a branch other people can push to, you may end up removing their changes by doing this
[00:21] <lifeless> vxnick: rule of thumb - never uncommit after you have pushed
[00:21] <vxnick> noted, it's just me at the moment
[00:22] <vxnick> thanks
[00:22] <lifeless> vxnick: you can if you need to, but understand the mechanics ;)
[00:22] <vxnick> yeah, I'll double-check next time :)
[00:23] <vxnick> push --overwrite did the trick, many thanks guys
[00:24] <vxnick> another one to add to my repertoire ;)
[00:33] <pygi> mwhudson: thanks for the response
[00:33] <pygi> I pretty much think that locations.conf should be ok, yes
[00:37] <mwhudson> pygi: cool
[00:37] <poolie> lifeless: wrt rich-root and similar changes, will people be able to bzr branch their existing launchpad un-landed branches into an upgraded repo?
[00:38] <poolie> or will they need to upgrade all of them individually?
[00:38] <jml> james_w: I notice the bzr-nightly-ppa for hardy doesn't have 1.16dev
[00:38] <lifeless> poolie: I think it is important that they check and reconcile all their revisions
[00:38] <jml> lifeless: wait, pebkac
[00:38] <jml> double pebkac!
[00:38] <lifeless> its possible for revisions in different branches to interact badly with some combinations of ghsots
[00:39] <lifeless> I'd *like* to be able to say 'run check -r submit:' and if that is clean branch it into your shared repo
[00:39] <lifeless> but current check can't do that because it checks everything
[00:39] <lifeless> poolie: certainly they can run the commands to branch it into an upgraded repo, but that says nothing about data integrity
[00:40] <lifeless> poolie: did you want me to pop over [say around lunch till 5ish] ?
[00:43] <poolie> lifeless: ok, i have to go out to a movie at about 5 though
[00:43] <lifeless> I have this meeting in the city @6 so that suites me fine
[00:43] <lifeless> I'll tell him to bring it forward a bit
[00:54] <poolie> lifeless: you asked yesterday if i'd read some advisory
[00:54] <poolie> which one was that?
[00:54] <lifeless> the one I drafted about the smart server problems. I wasn't asking if you'd read it, but if you had any more edits to make before we sent it to bzr-announce
[00:58] <jml> Errors were encountered while processing:
[00:58] <jml>  /var/cache/apt/archives/bzr_1.15+4422+116~08.04_i386.deb
[00:58] <jml> E: Sub-process /usr/bin/dpkg returned an error code (1)
[00:58] <jml> :(
[00:59] <lifeless> \o/
[01:01] <poolie> lifeless: no more changes, please send it
[01:01] <poolie> jml, did you get an actual error?
[01:02] <poolie> lifeless: could you send a draft advice on how launchpad devs should upgrade?
[01:02] <poolie> spiv, pushing a new branch to launchpad was HPSS calls: 61 (23 vfs) SmartSSHClientMedium(connected=False, username=u'mbp', host='bazaar.launchpad.net', port=None)
[01:02] <poolie> seems surprisingly bad
[01:02] <jml> poolie: no.
[01:02] <jml> that's it.
[01:02] <lifeless> poolie: [lp devs] I've been working towards that prior to allhands
[01:03] <lifeless> poolie: my opinion is that its not ready for lp devs. Its still way to fragile a process and I think all we'd learn is the fragility.
[01:03] <lifeless> poolie: I will refresh the doc though
[01:03] <lifeless> poolie: and we can discuss further after that
[01:03] <mwhudson> poolie: launchpad is still 1.14
[01:04] <lifeless> poolie: with 1.15 and no tags it should be 0 vfs
[01:04] <lifeless> poolie: wth 1.14 and tags, 9 vfs calls.
[01:04] <lifeless> sorry, with 1.15 and tags, 9 vfs calls
[01:04] <poolie> k
[01:04] <lifeless> but as mwhudson says, its still 1.14 on the server
[01:05] <lifeless> jml is looking into a critical upgrade bug for going to 1.15
[01:05] <spiv> poolie: what lifeless said
[01:07] <spiv> I think it might be good if the -Dhpss output mentioned if any UnknownSmartMethod were seen, to make the new client/older server case less alarming.
[01:08] <poolie> spiv, good point
[01:08] <SamB> I think you guys should make the bzr-announce list more prominent
[01:08] <vxnick> I think I know the answer to this, but is there anyway I can branch (or checkout) a single file from a repo? The repo itself only contains this one file
[01:08] <lifeless> bzr cat
[01:08] <lifeless> to get the contents
[01:08] <lifeless> or bzr branch to branch the branch
[01:09] <SamB> I barely managed to find the URL to sign up when I was *looking* for it just now
[01:09] <SamB> and that was only because I heard you talking about sending something to it!
[01:13] <poolie> jml: installing that package worked for me
[01:13] <jml> poolie: on hardy?
[01:14] <poolie> on jaunty
[01:14] <jml> ok.
[01:16] <jml> I'll install from source then.
[01:23] <jml> ok, now I'm perplexed.
[01:23] <jml> http://paste.ubuntu.com/192055/
[01:24] <jml> ahhh. plugins.
[01:27] <poolie> the traceback should say
[01:28] <poolie> it's kind of a bug that the message didn't
[01:31] <jml> yeah.
[01:31] <jml> Anyway, I've now successfully reproduced bug 385132 without involving Launchpad.
[01:37] <jml> lifeless: you said there were tests for this in bzrlib -- where might I find them?
[01:37] <lifeless> for the specific behaviour of honouring default policy
[01:37] <lifeless> bzrlib.tests.blackbox.test_push.*acceptance has one
[01:38] <lifeless> jml: ok, thanks for showing it w/out lp
[01:38] <poolie> lifeless: quick call?
[01:38] <jml> np.
[01:38] <lifeless> poolie: sure
[02:05] <jml> grrr. bzrtools out of date :(
[02:10] <jml> lifeless: I've just added a patch & linked a branch that add tests that reproduce the bug.
[02:12] <jml> Launchpad bug mail is being slow today. :(
[02:19] <lifeless> bug 385132?
[02:23] <jml> yeah.
[02:41] <jml> lifeless: are you planning on fixing bug 385132 today?
[02:41] <lifeless> jml: maybe
[02:41] <lifeless> jml: its clearly very important
[02:41] <lifeless> jml: however I have nothing on my plate that isn't.
[02:43] <jml> lifeless: should I ask someone else? (spiv? myself?)
[02:48] <spiv> jml: I'd be happy to look at that after I'm done with bug 380314
[02:48] <jml> spiv: cool, thanks.
[02:48] <spiv> jml: which realistically means "tomorrow"
[02:48] <jml> spiv: :(
[02:49] <spiv> (I might be wrong, but I'd rather surprise than disappoint)
[02:50] <lifeless> jml: I suggest digging into it yourself
[02:52] <jml> yeah, that sounds like a winner. I'll do some RM work first though.
[02:53] <mwhudson> do we have any idea which change introduced the regression?
[02:53] <lifeless> ping or ring at anypoint if you need assistance understandin the intent vs actuality
[02:54] <lifeless> mwhudson: bugger, I was slack in the docstring, didn't mention the version
[02:55] <mwhudson> lifeless: ?
[02:55] <lifeless> I think its just the new verb not being completely correct rather than a regression
[02:56] <lifeless> type object 'EventsCodes' has no attribute 'IN_MOVED_TO'
[02:56] <lifeless> funky
[02:56] <mwhudson> ah
[02:56] <mwhudson> i guess that's good
[02:58] <lifeless> landed in 4304
[03:19] <lifeless> -> poolies
[03:26] <poolie> lifeless: i don't find your rfc about log very compelling either way
[03:26] <poolie> lifeless: want a lift? i wouldn't mind leaving the house...
[04:36] <igc> hi all
[04:39] <jml> igc: hello
[04:39]  * jml dons the trousers of release management
[04:40] <jml> igc: how's bug 362030 looking?
[04:41] <poolie> jml nethack mode on :)
[04:41] <igc> jml: I'm completing the tests now
[04:41]  * poolie heads to the couch
[04:41] <poolie> hello igc
[04:41] <igc> hi poolie
[04:41] <igc> poolie: late start today sorry - needed some sleep
[04:41] <jml> igc: cool. :)
[04:42] <jml> poolie: you still planning on doing bug 385191 for 1.16?
[04:43] <fullermd> igc: With that fix done, is all the filtering stuff "expected" to DTRT?
[04:46] <poolie> igc, no problem
[04:47] <poolie> jml, iirc vila said that it's purely a bzr-gtk bug because it's been deprecated for a while
[04:47] <poolie> so i wasn't going to do anything else on it
[04:47] <jml> poolie: ok, I'll mark it as Invalid then?
[04:48] <poolie> oh i thought he did
[04:48] <jml> sounds like a "yes" to me :)
[04:51] <igc> fullermd: branch-specific rules are still outstanding. Otherwise, yes.
[04:52] <jml> bzr's policy is still to say "fix released" when a fix lands on trunk, right?
[04:52] <poolie> yes
[04:56] <fullermd> igc: 'k.  Last time I fiddled with it, I ran into so many oh-but's that I just gave up, but it seemed like most of them were at least known and at best in-progress.
[04:56] <fullermd> igc: So, cool.  I'll try fiddling with it again as soon as I get out from under the deluge currently innundating me.  Expect an email from me in, I dunno, 50 years or so  ;)
[04:57] <igc> fullermd: thanks. I wouldn't bother too much before 1.16
[04:57] <fullermd> Well, I'd never bother with a release.  That's what bzr.dev is for  ;p
[04:58] <lifeless> jml: is it the value for final_stack or final_stack_pwd that are wrong?
[04:59] <jml> lifeless: wrt bug 385132? Whatever the second-last value in the returned tuple is, that's the one that's wrong.
[05:01] <lifeless> thats final_stack_pwd
[05:01] <lifeless> it should be a relpath, I think, for our cases
[05:02] <lifeless> there are unit tests for this api
[05:02] <lifeless> in bzrlib.tests.bzrdir_implementations (or perhaps per_bzrdir).test_bzrdir
[05:03] <jml> lifeless: thanks, that helps.
[05:08] <jml> I'm looking at http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Ch06a8r%24v7c%241%40ger.gmane.org%3E
[05:08] <jml> and http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Ch06a8r%24v7c%241%40ger.gmane.org%3E
[05:09] <jml> they look like the same patch to me -- should I merge the first one into bzr.dev?
[05:23] <BasicOSX> Could someone QA the 1.15.1 tar and zip at ftp://ftp.real-time.com/pub/bzr/? I am gun-shy and want 2nd set of eyes making sure the pyrex-ified files are in there.
[05:23] <jml> poolie: sorry, I think there's been some bug collision on bug 385191.
[05:23] <jml> BasicOSX: sure, I'll get to that now
[05:28] <poolie> jml, ok, but it looks like violent agreement? :)
[05:29] <jml> poolie: ok, so you just accidentally assigned it to yourself & the 1.16 milestone?
[05:29] <jml> poolie: if so, great. :)
[05:29] <jml> BasicOSX: in the tarball, there's no C file corresponding to ./bzrlib/_walkdirs_win32.pyx
[05:30] <poolie> jml, i don't know how that happened
[05:30] <poolie> i did not click it
[05:30] <poolie> is launchpad bug i think
[05:30] <BasicOSX> I followed the release procedure to the letter -and- a make does it's all built
[05:31] <jml> BasicOSX: same in the zip.
[05:31] <BasicOSX> but I do see ./bzrlib/_walkdirs_win32.pyx
[05:31] <fullermd> That file isn't pyrexified for me either on the standard make.
[05:31] <BasicOSX> bug in make disst?
[05:31] <jml> BasicOSX: I'm bumping hard against the walls of my ignorance here.
[05:32] <fullermd> Never been built on any previous releases that I can see either.
[05:32] <fullermd> (so it's not a regression, but or not)
[05:32] <fullermd> Presumably it would only matter for somebody building for win32 directly from the tarball...
[05:32] <BasicOSX> make dist does not build it
[05:33] <BasicOSX> ie, make dist on linux
[05:33] <mwhudson> i think it would only get c-ified on win32
[05:33] <mwhudson> looking at setup.py
 "your RM thinks..." <-- nice one
[05:34] <poolie> in expression and sentiment
[05:34] <BasicOSX> I was under the impression that things goe pyrex-ified on install, but the last release went out with none and it caused problem
[05:34] <BasicOSX> engrish spoken here also
[05:34] <jml> BasicOSX: I think it's perfectly OK for a 1.15.1 release.
[05:35] <poolie> BasicOSX: the thing is we'd rather assume the RM has pyrex even if the installer doesn't
[05:35] <BasicOSX> poolie:  _walkdirs_win32.pyx not in tar or zip when build in linux ok?
[05:35] <jml> BasicOSX: given that it's not a regression.
[05:35] <jml> (but poolie has the say here, I think)
[05:35] <poolie> the .pyx file is the original source, it must be present
[05:35] <poolie> um
[05:35] <jml> BasicOSX: it's the C file that's missing.
[05:36] <BasicOSX> oh, sorry miss understood
[05:36] <poolie> mwhudson: you may be right, but i thought we could generate the C files regardless of platform
[05:36] <poolie> however i think it's more ok if they're missing
[05:36] <poolie> on windows
[05:36] <mwhudson> poolie: you probably _can_
[05:36] <poolie> um
[05:37] <mwhudson> poolie: but in this case, we certainly don'
[05:37] <mwhudson> t
[05:37] <poolie> my impression is that on unix there will be many people with compilers but not necessarily pyrex
[05:37] <poolie> on windows, probably only hardcore people will be compiling and it's reasonable for them to have it
[05:37] <BasicOSX> poolie:  does RMS always send a condolences  on a regression release?
[05:37] <poolie> but better just to ship it all
[05:37] <poolie> yes :)
[05:37] <poolie> it worried me too :)
[05:38] <jml> poolie: so we ought to be including the C for all of the .pyx files. we haven't so far, which means that it's ok for 1.15.1, but we should fix it for some unspecified future release?
[05:38] <jml> possibly 1.16, given that bug 385453 is already filed against it.
[05:38] <fullermd> I note, for the record, that for 1.15 (and the last time we lacked the built .c files in a release.... 1.12?), I just added pyrex as a build dependancy to the port.
[05:38] <fullermd> And I'm seriously considering just leaving the dependancy in place for the future, Just In Case.  It's _tiny_.
[05:39] <BasicOSX> what the heck, some how a title of 1.15.1 is 1.15.1 "" but I cannot remove the ""
[05:39] <fullermd> (I mean, seriously, it took like 10 seconds to download, build, and install, on my old hardware)
[05:39] <BasicOSX> nm, control-E killed line and it's gone
[05:45] <lifeless> so
[05:45] <lifeless> we should be versioning the pyx files now
[05:45] <lifeless> its on my todo
[05:45] <lifeless> but anyone can do it
[05:46] <poolie> jml; i thought that fixing this was the purpose of doing the .1 release?
[05:47] <jml> poolie: oh.
[05:47] <jml> poolie: I thought the purpose was fixing the smartserver error regression.
[05:48] <spiv> The build error was the original reason, the error regression just piggy-backed on that IIRC.
[05:48] <jml> ahh ok.
[05:49] <spiv> There was also hope for a while that the gc-stacking fixes would be suitable for a 1.15.1, but they became too large.
[05:54]  * jml writes out his revised understanding:
[05:55] <poolie> BasicOSX: so does 1.15.1 actually include the C files?
[05:55] <jml> poolie: no.
 BasicOSX: in the tarball, there's no C file corresponding to ./bzrlib/_walkdirs_win32.pyx
[05:56] <spiv> Most Windows users will use the pre-built installer though, so that's possibly not such a big deal.
[05:57] <poolie> but for the other ones?
[05:57] <lifeless> spiv: it borks nearly every linux distro
[05:58] <lifeless> spiv: as they have been depending on the C files
[05:58] <BasicOSX> I see the .c in the zip file.  http://pastebin.com/d7ff67cf
[05:58] <jml> poolie: all of the other ones are there.
[05:58] <spiv> lifeless: linux distros have been depending on building _walkdirs_win32?
[05:59] <BasicOSX> but I do -not- see them in the tar
[05:59] <lifeless> spiv: no, they run setup.py, setup.py builds or not, and depending on the exact distro we either end up with .so's or not.
[05:59] <BasicOSX> and the bad news is I sent the announce email
[05:59] <lifeless> spiv: and as they don't consistently fail when there are no .so's, users get slow bzr
[05:59] <jml> BasicOSX: http://pastebin.com/m3d0b70e0
[05:59] <lifeless> as in fact our ppa was doing for a bit
[06:00] <jml> BasicOSX: I see the C files in the tar.
[06:00] <BasicOSX> correct, I forgot the '$'
[06:00] <spiv> lifeless: the only missing .c file is _walkdirs_win32.c, if I'm understanding the situation correctly.
[06:00] <BasicOSX> my apologies
[06:00] <jml> spiv: you are.
[06:01] <jml> at least in that respect :)
[06:01] <spiv> BasicOSX: congrats on another release.
[06:01] <jml> BasicOSX: thanks :)
[06:02] <BasicOSX> Transition of RM roll on a "pffft" on my part
[06:02] <jml> :D
[06:03] <lifeless> spiv: we're talking at different levells
[06:04] <jml> while everyone is talking about pyrex :)
[06:04] <jml> http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Ch00992%24d67%241%40ger.gmane.org%3E <-- am I ok to land that?
[06:05] <lifeless> jml: poolie said he would land it
[06:05] <lifeless> jml:  if its not landed its certainly approved to land
[06:05] <jml> cool.
[06:06] <lifeless> spm: ping
[06:07] <lifeless> spm: meet spiv. spiv makes pqm break with lp branches.
[06:07] <lifeless> spiv: meet spm. spm makes pqm work with lp branches.
[06:07] <lifeless> Now, will you both talk to yeach other please!
[06:53] <bialix> jml: hi
[06:53] <jml> bialix: hello
[06:53] <bialix> hello. I'd like to say you about Russain translation patch, because you're RM for 1.16
[06:54] <bialix> I'd like to have this patch merged and released as part of 1.16, so more russian-spoken people will use it and review it
[06:54] <bialix> what should I do to help you?
[06:55] <bialix> http://bundlebuggy.aaronbentley.com/project/bzr/request/%3Ch0ld7v%24jjb%241%40ger.gmane.org%3E
[06:55] <jml> bialix: you should find someone to review it for you, I think.
[06:56] <bialix> poolie, igc: hi
[06:56] <igc> hi bialix
[06:57] <bialix> igc, can you help me with review of Russian translation patch?
[06:57] <igc> bialix: sorry that I haven't got to all your emails yet - flat out on an important eol patch
[06:57] <igc> bialix: not just now sorry
[06:57] <bialix> ok
[06:58] <bialix> 2 all: if anybody can review the patch (only the part related to Makefile changes) -- I'll be very  grateful
[06:59] <jml> bialix: btw, is there a bug associated with this patch?
[06:59] <bialix> not yet, but I can file if this is best way
[06:59] <jml> bialix: please do, & assign it to the 1.16 milestone.
[07:00] <bialix> I can't assign to milestone. I'm not part of bzr devs LP group
[07:01] <jml> bialix: ok, I'll assign for you, on the assumption that this change is easy enough for the 1.16 release
[07:13] <bialix> jml: https://bugs.launchpad.net/bzr/+bug/385464
[07:14] <vila> hi all
[07:15] <bialix> vila: hi!
[07:15] <bialix> vila: can I resuade you to look at my russian translation patch, I need to find reviewer for Makefile changes
[07:15] <bialix> s/resuade/persuade/
[07:17] <vila> bialix: ok
[07:17] <jml> poolie: you available for a fairly quick call?
[07:18] <bialix> vila: btw, thanks for your hint about SavedCommitMessageManager in bzr-gtk
[07:18] <bialix> I have many questions about that class. Who is designed it?
[07:19] <vila> bialix: but I thought your submission was a bit strange (empty bundle), can you make a merge-proposal instead. Even if the diff is huge, we'll be sure the real stuff is up for review
[07:19] <bialix> the branch is  lp:~ru-bzr/bzr/doc-ru
[07:20] <bialix> this is merge directive, it's not empty
[07:20] <bialix> do you want full preview diff?
[07:20] <bialix> I can make it without bundle part
[07:20] <vila> bialix: oh, merge directive without diff silly me, of course
[07:21] <vila> bialix: no forget it, I'll mirror that locally to review
[07:21] <bialix> resulting htmls available at my site
[07:22] <bialix> for preview
[07:22] <vila> bialix: I'll generate them locally as part of the review anyway
[07:22] <bialix> ok, that's fine
[07:22] <jml> vila: hello
[07:23] <jml> vila: when you get a chance, can you please take a look at https://edge.launchpad.net/bzr/+milestone/1.16 and tell me if you think we need anything else for the 1.16 release
[07:25] <vila> jml: you mean on a general point of view, right ?
[07:25] <jml> vila: yeah. any things that are critical to a good 1.16 release & aren't on that list.
[07:26] <fullermd> What about fairings?
[07:26] <vila> ok, so nothing on my radar yet (bug #385453 can be fixed by adding the C files though)
[07:27] <jml> vila: cool.
[07:27] <jml> fullermd: fairings?
[07:27] <jml> fullermd: what are they?
[07:28] <spm> hi spiv :-)
[07:28] <fullermd> jml: Well, that's the real question, ain't it?  ;>
[07:28] <jml> vila: jam seems to be against adding C files right now. since we are close to release, I figure we should adopt a simpler solution for 1.16.
[07:29] <vila> jml: ha, ok, I haven't read his mail yet, but on the principle I trust him :)
[07:30] <spm> spiv: so aiui, your lp:spivs-awesome-code branches to bzr aren't getting thru PQM?
[07:30] <jml> vila: cool. :) I'll be around for a while longer, so feel free to ping me if you think of something.
[07:31] <vila> jml: ok
[07:32] <spiv> spm: well, they get through, but when they reach the top of the queue they silently fail (i.e. no email reply)
[07:32] <spm> spiv: do you think it's possible the sheer awesomeness of the code overwhelms PQM?
[07:33] <spiv> spm: my guess would be that something has broken pqm's ability to authenticate to bzr+ssh://bazaar.launchpad.net/, actually :)
[07:33] <spm> heh. lets not interject real data/facts here!
[07:34] <spiv> spm: I wasn't, that really is just speculation :)
[07:34]  * jml afk for a bit
[07:35] <spm> spiv: ok. this is really weird. rob and myself fixed this the other day - the *same* fault/broken config file is back. argh.
[07:35] <spiv> spm: was that for the lp pqm, though?
[07:35] <spm> bzr
[07:35] <spiv> spm: wacky!
[07:35] <fullermd> Well, he didn't specify a _direction_...  "the other day" could well be tomorrow  :p
[07:36] <spm> :-)
[07:37] <spm> spiv: oki, give it a whirl now?
[07:38] <vila> urgh, http://paste.ubuntu.com/192236/
[07:38] <vila> spiv: does the above rings a bell ?
[07:39] <vila> bialix: what format did you use for lp:~ru-bzr/bzr/doc-ru ? I can't branch it nor pull fom it :-(
[07:40] <bialix> Branch format 7
[07:41] <bialix> Repository format:  	Packs 6 (uses btree indexes, requires bzr 1.9)
[07:41] <bialix> I can send you complete patch with bundle
[07:41] <spiv> spm: I don't have a pending branch handy, I'll let you know tomorrow most likely if that's ok.
[07:42] <spiv> vila: you can usually work around that bug in the branch by using nosmart or sftp
[07:42] <spm> spiv: np
[07:42] <bialix> spiv: thx for the fix of Connection reset by peer. I'm ought to test it properly
[07:42] <spiv> bialix: that's ok, it was just something that jam pointed out at the sprint and it looked like a quick fix to do between test runs :)
[07:43] <bialix> glad it finally fixed
[07:45] <vila> spiv: 8-} adding nosmart works, even if the progress bar reports bzr+ssh... meh. Anyway, I thought that symptom was fixed in several different ways already, there are still more ?
[07:46] <poolie> jml, hi
[07:46] <poolie> am talking to robert, you can call if it's urgent
[07:46] <spiv> vila: the damaged branches are still damaged.
[07:47] <vila> spiv: ha yes ! Sorry
[07:47] <spiv> vila: https://launchpad.net/bugs/354036 's description has the gory details :P
[07:47] <spiv> "Undecided,Confirmed"?
[07:47] <spiv> ubottu: wha?
[07:48] <spiv> Oh, the "bzr (Ubuntu)" bug.  Learn some context about the channel you're in :P
[07:48] <bialix> vila: entire bundle sent to you
[07:49] <spiv> bialix: (you may want to run the fix script attached to 354036 to repair your doc-ru branch)
[07:49] <vila> bialix: it's ok, spiv reminded me that my memory is suffering... what's the name of the disease ?
[07:49] <fullermd> "ghost memories"  ;)
[07:49] <bialix> spiv: should I? it works for me and other ru-bzr people
[07:50] <jml> poolie: it's not. I'll survive :)
[07:51] <bialix> spiv: is not http:// URL is workaround?
[07:52] <spiv> bialix: the bug description on 354036 gives the precise details of the issue.  People that don't already have those revisions will probably encounter that error if they use bzr+ssh or lp: URLs.
[07:52] <spiv> bialix: http:// (and sftp:// and nosmart+bzr+ssh://) URLs do workaround the problem, yes.
[07:53] <bialix> spiv: the bug description and comments is scary long
[07:53] <spiv> bialix: don't worry about the comments, the description is fully up-to-date.
[07:54] <bialix> you know this patch does not work with bzr.exe?
[07:55] <spiv> Which patch?  The fix-branch.py script?
[07:56] <bialix> running with bzr.dev
[08:01] <bialix> spiv: should I run this script from my source branch?
[08:01] <bialix> i.e. what is working dir expected>
[08:01] <bialix> ?
[08:01] <vila> huh, pushing to a local branch with a WT updates the WT *including* uncommitted changes ? Is it really the desired behaviour or a bug ?
[08:02] <bialix> the script just prints: Missing inventories: set([('pqm@pqm.ubuntu.com-20090423015537-xfgqsbjj9ctpcd3o',)]) and hangs
[08:02] <bialix> spiv: ^
[08:02] <jml> poolie: the main thing I want to know is, for 1.16, should I be concerned with landing the many "Approved" patches listed on bundlebuggy?
[08:06] <bialix> running from local source branch gives me different message: Missing inventories: set([])
[08:07] <vila> jml: *I* will be concerned if I was you and will (well, *I* won't, but we're talking about you :) at least target bzr.dev *after* cutting a 1.16 branch...
[08:08] <jml> vila:
[08:08] <vila> jml: I will just PING (note capitals) the authors :)
[08:08] <jml> vila: :)
[08:08]  * vila adds more smileys everywhere just in case 
[08:10] <AfC> ping: Verb. To throw an electronic message at someone. Ping: Verb. To throw a "ping-pong" ball at someone. PING: Verb. To throw a large bowling ball at someone. :)
[08:10] <bialix> spiv: I'm not sure if this script is working. It just print message and then nothing happens. I don't see big network activity or something similar. It looks like it just hangs
[08:10] <vila> AfC: is that from a real source or did you just made it ? :-D
[08:10] <AfC> Just made it up
[08:10] <AfC> vila: feel free to use it :)
[08:13]  * bialix can keep it running for all day, of course. But not sure it makes sense
[08:15] <vila> AfC: here you are: http://bazaar-vcs.org/Quotes
[08:17] <spiv> bialix: hmm, it shouldn't hang.  If there are missing inventories, it will fetch them from the stacked-on repository then exit.  If there are none ("set([])") it will simply exit immediately.
[08:18] <AfC> vila: There are some very funny passages on that page
[08:18] <bialix> so, it definitely hangs
[08:18] <vila> AfC: :-)
[08:18] <spiv> If it hangs it might be something odd like the SSH subprocess/thread not exiting perhaps?
[08:18] <bialix> you ask me?
[08:19] <bialix> I don't know
[08:19] <spiv> I ask the world in general :)
[08:19] <spiv> I don't expect anyone to know the answer...
[08:19] <bialix> entire mind of universe, I guess
[08:19] <vila> well *I* expect someone knows the answer about:
[08:19] <vila> huh, pushing to a local branch with a WT updates the WT *including* uncommitted changes ? Is it really the desired behaviour or a bug ?
[08:19] <vila> :-/
[08:20] <spiv> Anyway, it should have done the fix.  If you interrupt it and re-run you'll probably see that it's fixed it (i.e. it will report "set([])").
[08:20] <vila> Or should I just test against old bzr releases ?
[08:20] <spiv> Or, it really has hung while trying to fetch the missing bits, which would be odd!  But maybe a traceback would show something.
[08:21] <spiv> vila: I would expect push to a WT would keep the uncommitted changes (and apply them against the new base tree, if necessary)
[08:22]  * bialix asking ubuntu guy (Dima Vasiliev) to run this script one more time
[08:22] <vila> and fail if they conflict with already present uncommitted changes ?
[08:22] <vila> and not be propagated if I branch from where I just pulled ?
[08:22] <spiv> vila: well, produce conflicts anyway.  Not precisely what you mean by "fail" here.
[08:22] <vila> and not be propagated if I branch from where I just pushed ?
[08:23] <bialix> spiv: if you say so, I guess it's fixed
[08:23] <vila> spiv: yes, conflicts sorry
[08:23] <bialix> but it was not broken for me anyway, so I can't check this
[08:23] <spiv> bialix: *nod*
[08:24] <vila> bialix: you can try branching in a standalone branch (i.e. outside your shared repo)
[08:25] <poolie> jml: not necessarily
[08:25] <poolie> you should be concerned about any ones that are marked 1.16
[08:25] <vila> bialix, spiv: not fixed from here, nosmart+ still needed
[08:25] <jml> poolie: ok, thanks.
[08:26] <poolie> and you should help me guilt everyone into landing them
[08:26] <poolie> but not necessarily for 1.16
[08:26] <poolie> i landed a couple of mine today
[08:26] <jml> poolie: I'm happy to do that post-1.16 :)
[08:27] <bialix> spiv, vila: Dima said it just prints: Missing inventories: set([]) and then exit
[08:30] <bialix> vila: just running bzr get in temp dir outside any shred repo with bzr.exe 1.15. Still don't see error
[08:30] <bialix> 50% done
[08:35] <bialix> vila: Dima just branching on Ubuntu with official bzr 1.15 without errors
[08:35] <bialix> it smells like regression in bzr.dev
[08:36]  * bialix assumes vila runs bzr.dev
[08:37] <fullermd> Fails for me with both.
[08:38]  * vila assumes bialix runs a magic version :)
[08:39] <vila> bialix: just to be sure, can you run bzr info -v in your temp dir and check which repo is used /
[08:39] <vila> bialix: just to be sure, can you run bzr info -v in your temp dir and check which repo is used ?
[08:39]  * bialix thinks about the fact he and Dima have write privileges to this branch, and other people are not :-P
[08:39] <fullermd> Well, python tracebacks might as well be Russian to _me_...   so maybe his bzr just understands it while ours don't?  ;)
[08:40] <bialix> fullermd: you're incredible right
[08:40] <bialix> hdime: hi
[08:40] <bialix> hdima
[08:40] <bialix> hdima: hi
[08:40] <hdima> hi
[08:40] <bialix> vila, fullermd: here is Dima
[08:40] <bialix> ask him
[08:41] <bialix> my branch command still working
[08:41] <bialix> it seems my i-net channel little than yours
[08:41] <hdima> bzr branch work fine for me, I don't see any errors
[08:44] <bialix> hdima: show here output of `bzr info -v` please
[08:45] <hdima> bialix: wait a sec
[08:45] <bialix> or pastebin it
[08:45] <vila> hdima: the bug (AFAIUI) should only be triggered if you don't have some revisions locally, so using a shared repo masks the bug
[08:45] <poolie> vila, hello, goodbye! :)
[08:46] <vila> poolie: have a nice evening ! ;)
[08:46] <poolie> let's try to talk tomorrow, if S will let me :)
[08:46] <vila> poolie: cough, Friday instead, I'm not there tomorrow
[08:46] <hdima> vila: I've create fresh branch in empty directory so I don't think it was masked
[08:46] <poolie> ok
[08:46] <vila> hdima: bzr info -v will tell us for sure
[08:47] <hdima> And I've ran fix_branch.py which returns: Missing inventories: set([])
[08:48] <hdima> vila: Ok, but I've just deleted the branch and branch it again :-)
[08:48] <vila> hdima: argh ;)
[08:49] <jml> "bzr: ERROR: No module named bencode" -- what do I install?
[08:49] <bialix> my branching still in progress: [#########-          ] bzr+ssh > 141913KB   122KB/s | Fetching revisions:Inserting stream
[08:49] <vila> jml: use --no-plugins or BZR_PDB=1, it's bzr-gtk and bencode related
[08:49] <bialix> jml: some plugin is not updated yet, I guess
[08:49] <jml> vila, bialix: thanks.
[08:50]  * jml considers aliasing ./bzr to './bzr --no-plugins'
[08:50] <vila> jml:  you just said jam fix has landed somewhere what bzr version are you using ?
[08:50] <hdima> Ok, here it is: http://paste.pocoo.org/show/122163/
[08:51] <vila> jml: put your RM hat on and repeat: "I should not use --no-plugins when wearing my RM hat" :)
[08:51] <jml> vila: I'm fixing https://bugs.edge.launchpad.net/bzr/+bug/385132
[08:51] <jml> vila: I'm wearing my Launchpadder hat.
[08:51] <jml> vila: *and* my RM trousers.
[08:51] <bialix> vila: http://paste.pocoo.org/show/122163/
[08:51] <vila> jml: oh, np then ! Go ! Use --no-plugins !!!
[08:52] <vila> bialix, hdima: I'm lost :-/
[08:52] <hdima> bialix: the same output :-)
[08:52] <bialix> no, it's your output
[08:52] <hdima> bialix: =))))
[08:52]  * bialix just pointing it for vila
[08:52] <vila> bialix: rats ! I thought it was yours and was comparing both ! :-D
[08:53] <hdima> I thought it was yours :-)
[08:53] <bialix> vila: wait a sec
[08:53] <bialix> my branching just finished without errors
[08:53] <jml> glyph: hello :)
[08:54] <bialix> here is mine: http://paste.pocoo.org/show/122164/
[08:54] <jml> vila: re: your previous question: http://paste.ubuntu.com/192280/
[08:54] <bialix> vila: they both looks suspiciously similar :-D
[08:55] <hdima> bialix: except the first line ;-))
[08:55] <bialix> yeah
[08:55] <hdima> So it works
[08:55] <bialix> vila, spiv: so what now?
[08:55] <bialix> it works for us
[08:56] <bialix> and we both using official bzr 1.15 and we both have write privileges for this branch
[08:56] <vila> write privileges shouldn't have an impact here
[08:56] <bialix> as you wish
[08:56] <vila> apart from that, no idea
[08:57] <vila> trying with 1.15.1 from here
[08:57] <bialix> I don;t have 1.15.1 yet
[08:57] <vila> fails in the same way
[08:58] <vila> as is 1.14.1
[08:58] <bialix> hdima: we just discovered Russian-only feature in LP. Yay!
[08:59] <bialix> I guess this is because Mark was in Russian
[08:59] <hdima> It's I18N feature ;-)
[08:59] <vila> also fails with 1.15
[09:00] <hdima> Now I'm branching read-only with http://...
[09:00] <vila> I wonder if windows has some... thing... that has the same effect as adding nosmart+...
[09:01] <bialix> vila: hdima using ubuntu
[09:01] <hdima> vila: Maybe you need to run it in some sort of sandbox?
[09:01] <bialix> with --no-plugins flag may be?
[09:01] <vila> bialix: yeah --no-plugins and a lp: URL, I love that combo :-)
[09:02] <bialix> :-DDDDDD
[09:02] <hdima> :-)
[09:02] <bialix> you have bzr+ssh URL ;-)
[09:03] <hdima> bialix: Maybe we just need to branch it to a different site for vila?
[09:03] <glyph> hello!  I have a question about branch etiquette.
[09:03] <bialix> no, http:// or nosmart+ prefix works
[09:04] <bialix> cool
[09:04] <bialix> yesterday I've asked about another etiquette
[09:04] <vila> hdima: Don't worry, I have been able to branch by adding nosmart+, I'm just trying to better diagnose the problem, but really I should leave it to spiv as obviously I'm going nowhere
[09:04] <bialix> it seems bzr users is very noble people
[09:04] <hdima> vila: Ah, OK
[09:05] <bialix> glyph: please, ask
[09:05] <glyph> If you're working on a feature in a branch, and it takes a long time, sometimes you have to integrate changes from trunk.
[09:06] <jml> yep.
[09:06] <glyph> It seems like the convention is to do 'bzr merge trunk' in your branch, and just keep working.
[09:07] <bialix> yes
[09:07] <jml> glyph: yes. that's what most people I know do.
[09:07] <glyph> If a lot of work has gone into trunk, that seems to create something I find confusing as a reviewer.
[09:08] <glyph> the revision has a giant diff of unrelated changes, which may involve some changes to resolve conflicts
[09:08] <glyph> the changes which resolve conflicts are relevant to the branch, but all the other stuff from trunk (which can be a lot) isn't
[09:08] <vila> glyph: time to use 'bzr diff -rsubmit:' ?
[09:08] <bialix> glyph: you can use `bzr merge --preview` or `bzr send -o-` to preview actual changes
[09:09] <jml> glyph: why is the diff in that revision relevant to the review?
[09:09] <glyph> jml: well, this is one of the things that I like about bzr as opposed to svn
[09:09] <BasicOSX> This cuz I'm using bzr.dev? KnitPackRepository('lp-hosted:///~tanner/mactrek/trunk/.bzr/repository') is not compatible with KnitPackRepository('lp-hosted:///~tanner/mactrek/osxtrek.1.4.0/.bzr/repository') different rich-root support
[09:09] <jml> bialix: 'send -o-' is equivalent to 'diff -rsubmit:', isn't it?
[09:10] <bialix> I never think about this
[09:10] <bialix> may be
[09:10] <glyph> jml: If I look at the revision history, I can see how the branch came to be much more easily
[09:10] <vila> jml: 85% sure yes
[09:11] <glyph> jml: If people integrate changes from trunk, it's easier to read if they do the re-branch thing
[09:11] <glyph> jml: If I'm just reading the end-of-branch diff, the experience isn't much different from svn :)
[09:11] <jml> glyph: except that the re-branch thing loses all changes from before then.
[09:11] <bialix> re-branch? I guess you need rebase
[09:11] <glyph> jml: it does?
[09:11] <vila> BasicOSX: lp-hosted ?
[09:12] <BasicOSX> yes
[09:12] <jml> glyph: the history of those changes, yes.
[09:12] <vila> BasicOSX: you scare me there is is 3h11 AM your time ?
[09:12] <bialix> jml: not if you're using rebase
[09:12] <vila> s/is is/is it/
[09:12] <BasicOSX> vila:  I need to keep up with you
[09:12] <glyph> jml: if you do re-branching by 'bzr branch trunk my-branch-2; cd my-branch-2; bzr merge ../my-branch', what history is lost?
[09:13] <vila> BasicOSX: what is lp-hosted ? (was my badly expressed question)
[09:13] <jml> glyph: oh, right. none.
[09:13] <jml> glyph: it's just weird :)
[09:13] <jml> glyph: I was thinking of Combinator-style "merging forward"
[09:13] <jml> my mistake.
[09:13] <glyph> jml: well, the thing I just said is the bzr non-history-losing translation of that idiom ;)
[09:14] <BasicOSX> vila:  https://code.launchpad.net/mactrek I just took some upstream code, gotten via bzr svn-import and push to LP (bzr push lp:~tanner)
[09:14] <jml> glyph: a lot of the time when I do reviews, I look at the mainline history of that branch.
[09:14] <jml> glyph: not diff-by-diff, just the log messages.
[09:14]  * igc dinner
[09:16] <glyph> jml: so yeah
[09:16] <glyph> jml: what I want to know is, why is it weird?
[09:16] <vila> BasicOSX: I think jml may know better about which branch stacks on which and what formats are used in thoses branches. Especially since some vcs-imports are involved and I don't know if you used that or did your ow import 8-}
[09:17] <BasicOSX> k
[09:17] <BasicOSX> I think it's cuz I locally did a bzr branch --stacked upstream my-branch
[09:17] <vila> BasicOSX: but https://code.edge.launchpad.net/mactrek also show branches with "This branch has not been pushed to yet. " warnings which may indicate yet another kind of problem
[09:17] <BasicOSX> then did a bzr push lp:~tanner/my-branch
[09:17] <jml> glyph: have a look at https://code.edge.launchpad.net/~ian-clatworthy/bzr/eol-st-ci-fix/+merge/7269 for an example
[09:17] <jml> (sorry I couldn't find one of my own)
[09:18] <jml> glyph: I look at something like that almost every time I review a branch.
[09:18] <jml> glyph: I get to see the history, but rarely look at the line
[09:19] <jml> at the diff for each revision.
[09:19] <jml> glyph: doing the re-branching thing you describe is weird because it disrupts the idea of a branch as a line of development.
[09:20] <jml> glyph: also, the initial commit that merges in your changes isn't particularly meaningful.
[09:20] <jml> glyph: at least to me, the operation I'm performing is "integrate changes from trunk with my work"
[09:22] <jml> not "start a new line of work and bring in everything from my last try at it"
[09:23] <jml> glyph: I guess that's not such a compelling answer.
[09:23] <BasicOSX> isn't the bug that was fixed in 1.15.1?
[09:23] <BasicOSX> Source format does not support stacking, using format: '1.6.1-rich-root'
[09:23] <BasicOSX>   Packs 5 rich-root (adds stacking support, requires bzr 1.6.1)
[09:24] <jml> BasicOSX: don't think so.
[09:24] <BasicOSX> ok, I'll stop the panic attack and re-read bug report
[09:24] <jml> BasicOSX: the issue is that one branch is 1.6.1-rich-root and the other is 1.6.1, I think.
[09:24] <jml> BasicOSX: you can't stack rich-root on non-rich-root & vice verse
[09:24] <jml> versa, rather.
[09:25] <jml> *so* glad that mess is going away
[09:25] <bialix> vila, spiv: so outcome of the problem with doc-ru branch should be filed as bug?
[09:25] <jml> wish emacs had annotate integration.
[09:26] <jml> mwhudson: pls rewrite loggerhead in elisp kthxbye.
[09:26] <vila> bialix: I think so yes
[09:26] <glyph> jml: Well, it might not be super compelling, but it makes sense
[09:27] <jml> glyph: the other reason is that most merges really are boring.
[09:27] <bialix> vila: my gut feeling -- it's related to write permissions. but I have no facts
[09:27] <jml> glyph: even most of the ones that resolve conflicts.
[09:28] <vila> bialix: There is a way to check that: give me the write permissions (and remove them after the test)
[09:28] <bialix> join ru-bzr group then
[09:28] <glyph> jml: it does make the history more readable as a list of changes, rather than as a tree of diffs
[09:29] <hdima> bialix: maybe you remove write permission for me and give it back after the test?
[09:29] <glyph> I think I still prefer my way of doing it, but it explains why that isn't the default way
[09:29] <vila> bialix: done
[09:29] <bialix> hdima, vila: I do both
[09:30] <hdima> bialix: Don't forget to give it back ;-))
[09:30] <bialix> you know how to PING me :-)
[09:31] <jml> glyph: as long as you don't make it compulsory for Twisted development, let's leave it there :)
[09:31] <hdima> bialix: yeah :-)
[09:31] <bialix> vila, hdima: done
[09:31]  * hdima test branching
[09:32] <vila> bialix: you were right ! I can branch with 1.15 !
[09:32] <bialix> wait for hdima
[09:32] <vila> bialix: well, still in progress with 1.15, will try bzr.dev then
[09:33] <hdima> bialix: you are right: I see the error :-))
[09:33] <bialix> yahoo!
[09:33] <hdima> But what about fix_branch.py then?
[09:33] <bialix> vila: ^
[09:34] <hdima> It seems it doesn't fix anything? :-)
[09:34] <vila> there is a bug there, I suspect spiv didn't test with such a config, I don't know off-hand what difference write privileges imply, but obviously something :) jml ? Any idea about what lp does differently here ?
[09:35] <jml> yes.
[09:35] <jml> (nyah-ah-ah)
[09:35] <vila> great, I'm so relieved :)
[09:35] <hdima> bialix: give me my rights back! :-))
[09:35] <jml> Launchpad has two different branch storage areas.
[09:36] <jml> an upload area and the mirrored area
[09:36] <bialix> ok :-P
[09:36] <bialix> done
[09:36] <jml> via the SSH server, if you get a branch that you've got write access to, you always get the version in the upload area
[09:37] <jml> that gets pulled to the mirrored area with bzrlib, so the version in the mirrored area (which you get if you don't have write access) is always a working bzr branch.
[09:37] <hdima> bialix: thanks :-)
[09:37] <bialix> vila: you can leave the group yourself, I guess?
[09:37] <vila> bialix: branch ok with bzr.dev, you can toss my rights :)
[09:37] <vila> bialix: I'll try, wait
[09:38]  * fullermd tosses vila a left, just when he wasn't expecting it.
[09:38] <bialix> happy to help
[09:38]  * vila watch the wreckage on the floor....
[09:39] <jml> spiv: you still around?
[09:39]  * hdima happy to help catch the bug
[09:39] <vila> bialix: done
[09:40] <vila> jml: you mean the branch in the mirrored aread is *not* working
[09:40] <hdima> vila: now you're lost a chance to help with the translation :-)
[09:40] <jml> vila: working as far as bzrlib can tell :)
[09:41] <vila> jml: but exhibiting the bug right ? Oooooh, the script has fixed the uploaded branch, but the puller didn't realize it should update the mirrored one because the tip didn't change right ?
[09:42] <jml> spiv: in r4126.1.1, you add a test that doesn't have an assertion, test_default_stacking_with_stackable_branch_unstackable_repo -- is this deliberate.
[09:42] <jml> vila: bingo
[09:42] <vila> pfew... thanks bialix, that one could have stay hidden for a looooong time
[09:43] <bialix> vila: so now you can finally look at the patch :-)
[09:43] <vila> bialix: If you didn't interrupt me that much the review will have been finished at least 1h30 ago :-D
[09:43] <vila> bialix: nearly done
[09:44]  * hdima thinks the patch need to be approved at least
[09:44]  * bialix shuts up and hides somewhere
[09:47] <vila> bialix: doe
[09:48] <vila> bialix: done
[09:49] <vila> I only ask for a minor tweak: adding a comment, other than that, congrats for that work
[09:53] <glyph> jml: so do you think you'd ever have call to do my backwards-trunk-merge thing?
[09:54] <hdima> bialix: Agreed with vila. I think we need to write something like this: "The following docs was translated to Russian: ..."
[09:54] <jml> glyph: I don't think so.
[09:55] <jml> glyph: two possible circumstances that I can think of --
[09:56] <jml> glyph: first, if I was resuming a long-dormant branch, then in a sense I am starting a whole new line of work. I might do that sort of thing (then again, I might not)
[09:56] <jml> glyph: the other case, when I have a really interesting conflict, I think I would instead do my normal thing and put in a detailed commit message.
[09:59] <glyph> jml: if you found a branch where someone (me) had done it a bunch of times, would it annoy you?
[10:00] <jml> glyph: I don't know -- it's never happened that I've noticed :)
[10:01] <jml> glyph: probably not. (I wonder what it would look like in bzr viz or bzr qlog)
[10:02] <bialix> hdima: can you adjust it, please?
[10:03] <bialix> vila: many thanks
[10:04] <hdima> bialix: yes
[10:04] <vila> bialix: thanks to you and your mates for doing that ! For so long (first revisions are from last August right ?)
[10:05] <bialix> yes, it was started by Alexey Shtokalo actually. But even before there was another attempt that failed
[10:05] <bialix> it's not easy job to do
[10:05] <hdima> vila: I believe we'll address duplication in the Makefile in the next patch because I don't like it too
[10:05] <vila> hdima: great !
[10:06] <hdima> Yes, and now we want to do it more officially :-)
[10:06] <vila> hdima, bialix : that's one more reason to land that patch quickly :)
[10:06] <jml> but let's not forget the other reason: if it's not in soon, it misses 1.16 :)
[10:06] <bialix> vila: I know it's too much for one day, but.. can you help us with PQM?
[10:07]  * jml admires the shine on the RM trousers.
[10:07] <hdima> Actually I have some thoughts about i18n but I think it's too early for now
[10:07] <bialix> hdima: please! not now
[10:07] <jml> lifeless: you around?
[10:08]  * bialix envies to jml
[10:08] <hdima> bialix: it's only thoughts :-)))
[10:08] <vila> bialix: no problem, I was thinking about that, but you'll need to push a new branch in lp:~bialix/bzr/whatever-as-long-as-you-tell-me so we avoid the bug
[10:09] <fullermd> jml: That's dried blood sweat and tears from previous RM's.  No cleaner in the world has managed to get it out...
[10:09] <vila> err lp:~bzr/bzr/whatever even
[10:09] <jml> fullermd: heh :)
[10:09] <vila> jml: did you get the updated notes from BasicOSX ?
[10:09] <bialix> vila: I have no access to ~bzr
[10:09] <bialix> perhaps hdima has?
[10:10] <vila> bialix: bah, use lp:~bialix then, that should be fine as long as you do that with a recent enough bzr (1.15 should be fine)
[10:10] <hdima> bialix: no I'm not
[10:10] <bialix> vila: perhaps we should get you to ru-bzr group back :-)
[10:11] <vila> bialix: :-) Naah, no time to learn Russian :-)
[10:11] <jml> vila: no, not yet.
[10:11] <bialix> vila: we can teach you some love words in russian...
[10:12] <vila> :-D
[10:12] <bialix> :-D
[10:12] <hdima> and some slang of course ;-)
[10:28] <bialix> vila: new branch with the tweak: lp:~ru-bzr/bzr/doc-ru-1.16
[10:28] <jml> В огоро́де бузина́, а в Ки́еве дя́дька.
[10:28] <bialix> :-D
[10:29] <jml> (from http://en.wikiquote.org/wiki/Russian_proverbs -- I speak no Russian)
[10:29] <hdima> Looks like unreadable UTF-8 for me :-)
[10:29] <bialix> hdima: I see it right
[10:29] <bialix> v ogorode buzina a v kieve dyadka
[10:30] <hdima> bialix: Other guys still use KOI8-R on IRC :-)
[10:31] <vila> looks like perfect cyrillic for me :-)
[10:31] <hdima> Wow, Russian day on #bzr :-)))
[10:37] <jml> I can't figure out where this test is supposed to go.
[10:37] <jml> also, I suspect that TestSmartServerRequestBzrDirInitializeEx's docstring lies.
[11:20] <lifeless> jml: yes
[11:25] <jml> lifeless: hi
[11:25] <mwhudson> jml: no
[11:25] <jml> lifeless: I can't figure out which tests I'm supposed to be looking at here.
[11:25] <jml> mwhudson: awwwwwww, c'mon, be a sport.
[11:25] <lifeless> ok
[11:25] <lifeless> lets make a date; tomorrow say, and I'll look deeply with you
[11:25] <lifeless> I'm wellpast EOD
[11:25] <jml> lifeless: sounds like a plan.
[11:26] <mwhudson> jml: no
[11:30] <aquarius> I bzr branched a launchpad project, using my access credentials (it's a project that I can write to). Since then, I've changed my launchpad username, so "bzr pull" says "Using saved parent location: bzr+ssh://OLDUSERNAME@bazaar.launchpad.net/" and then "No such Launchpad account". Can I tell bzr to change the saved location?
[11:34] <james_w> aquarius: bzr pull --remember URL
[11:36] <aquarius> james_w: and lo it works. Good shout, fella
[11:38] <jml> gosh, it's been a while since I've seen 'fella' used colloquially.
[11:38] <aquarius> it's due for a revival, I think. Like "codswallop"
[11:39] <jml> codswallop I can see.
[11:39] <jml> aquarius: are you going to EuroPython?
[11:41] <aquarius> jml: probably not, but since I'm only 10 miles away I may drop in for an evening or two of beer
[11:42] <jml> aquarius: cool. I'll be attending -- would be cool to catch up.
[11:43] <jml> aquarius: also, there's a Bazaar sprint on the Fri & Sat, which you're welcome to gatecrash. (See http://wiki.europython.eu/Sprints)
[11:45] <aquarius> I might be able to do that, I'm not sure
[11:54] <vila> bialix, hdima: landed
[11:55] <igc> bialix: I've resubmited that patch for qversion as requested
[12:04] <hdima> vila-lunch: Cool! Thank you!
[12:11] <spiv> jml: hmm, regarding that test, probably was intentional, but that was *ages* ago ;)
[12:12] <spiv> jml: It looks rather like a test that is of the "...and then this last step doesn't blow up" variety.
[12:13] <spiv> jml: although it doesn't seem like it would be hard to sprinkle some assertions afterwards, for clarity.
[12:14] <spiv> Also, I've got "bzr pull -r N" from a stacked repo (into an empty repo), where "N" is in the stacked-on repo, down to 18 RPCs, none VFS.
[12:18] <spiv> glyph: so, what you describe generates a nearly identical history to the standard "bzr merge trunk".  The only difference is that the order of the parents of the merge revision is swapped.
[12:19] <spiv> glyph: so one thought that occurs to me is that there's probably an easier way do that than actually constructing a new branch on disk ;)
[12:20] <spiv> glyph: but more importantly, I don't see why that makes the history any clearer.  Either way there's a big honking merge in the middle of your feature development history that you want to land.
[12:55] <rocky> hey the release notes url linked on the main page for 1.15.1 is 404
[13:07] <poolie> hi rocky
[13:07] <rocky> hello
[13:09] <poolie> fixed
[13:17] <poolie> rocky: thanks for reporting it
[13:18] <rocky> np
[14:45] <Milo-> hey, is there a way of setting up 'default' permissions for newly created branches and uploaded files using bzr?
[14:46] <Milo-> my vsftp server's settings are completely ignored, and all new branches are created with 700 permissions, even though I want 755
[14:51] <Spabby> hi folks, can anyone give me some advice what model is best for me to use for collaborative working using bzr please?
[14:51] <Spabby> We will be working on a zf based php project as a duo, with the development being done on a central LAMP server
[14:52] <Spabby> I'm not sure how and if we can achieve this with bzr
[14:52] <sevenseeker> ping vila
[14:52] <vila> sevenseeker: pong ?
[14:53] <sevenseeker> good morning, I was told you were knowledgeable about bzr+ssh
[14:53] <vila> sevenseeker: who said that ? :-)
[14:53] <sevenseeker> I want to use a pub key to connect to a machine but it is not named in the default way (I have many)
[14:53] <sevenseeker> ummm, lemme check
[14:53] <sevenseeker> bueno :)
[14:54] <vila> sevenseeker: what os are you using ?
[14:54] <sevenseeker> client is mac 10.5 and server is ubuntu 9.04
[14:55] <vila> good, we are in civilized world then :)
[14:55] <vila> man sshd_config
[14:55] <sevenseeker> hahaha
[14:55] <sevenseeker> well I have ssh working fine
[14:55] <LarstiQ> sevenseeker: is ssh-add feasible?
[14:55] <sevenseeker> how do I make bzr use a specific key?
[14:56] <LarstiQ> sevenseeker: if not, you could specify the key to use in ~/.ssh/config
[14:56] <sevenseeker> oh, well... lemme check
[14:56] <sevenseeker> oh, I see... never done that (LarstiQ)
[14:56] <vila> sevenseeker: As Larstiq said, no need to involve bzr hence: man sshd_config, I thought the variable was Identity but I can't find it anymore :-/
[14:57] <LarstiQ> vila: think so
[14:57] <vila> IdentifyFile ! man ssh_config not sshd you id...entity seeker :)
[14:58] <sevenseeker> vila: I see, lemme check... had no idea that would help me until you mentioned it :)
[14:58] <vila> sevenseeker: so the idea is that you define IdentifyFile in some host section (I tested that weeks ago but I did it manually :-/ Time to start TDA test driven administration :-D)
[14:59] <sevenseeker> sweet
[15:07] <visik7> ok I used bazaar for 1 year alone :)
[15:07] <visik7> now I'm using it in a team
[15:07] <visik7> few questions:
[15:17] <Milo-> he's been writing those questions for 10 minutes
[15:17] <Milo-> I bet it's something huge
[15:31] <visik7> this is my workflow A and B has rev1 and A commit and push (rev2) to a shared branch, now B commit and push too (its own rev2) and got a diverged error it, B runs merge and a commit and push
[15:32] <visik7> Milo-: no I'm working and chatting and surfing and calling to the phone and a bunch of other things
[15:33] <sevenseeker> howdy again, thanks everyone for your help and feedback
[15:35] <sevenseeker> using ssh-agent I am able to push and branch remotely but I can't seem to get it working right, both push and branch TO the remote location only result in a dir with .bzr in it, and when I try and run 'bzr update' on it, it complains that it is NOT a working copy :(
[15:36] <LarstiQ> sevenseeker: that is intended behaviour
[15:36] <Peng_> sevenseeker: Why do you want a working copy?
[15:37] <LarstiQ> visik7: go on :)
[15:37] <sevenseeker> well all I want to do is push a branch to the remote server for development, the constraint is that my dev box I am pushing from is not reachable by the remote servers
[15:38] <LarstiQ> sevenseeker: develpment in what sense? The .bzr control directory is everything bzr needs for publishing purposes
[15:38] <LarstiQ> Peng_: I vote for inclusion of this question in http://bazaar-vcs.org/FAQ
[15:39] <sevenseeker> so say locally I branch foo to bar, make my changes and commit, now I want to push 'bar' to actually work on it in my test envrionment remotely
[15:40] <sevenseeker> yes, a FAQ on this would rock!
[15:41] <visik7> LarstiQ: so the question is before the push of B
[15:41] <Peng_> LarstiQ: That's a good idea. I'm not gonna write it, though. I'm a terrible writer.
[15:41] <visik7> how to handle the if A had push something ?
[15:41]  * LarstiQ nods at Peng_ 
[15:42] <sevenseeker> right now I am tarballing it all up and throwing it on the remote location, but I figured there was a better way
[15:42] <LarstiQ> sevenseeker: usually, one pushes a branch to a remote location, to then bzr pull/branch/merge from that location somewhere else
[15:42] <visik7> B -> 1 pull -> 2 on error-> merge ->3 commit ->4pull (goto 2)-> push ?
[15:42] <LarstiQ> sevenseeker: is the remote location actually a workstation of yours, and not a central server?
[15:43] <sevenseeker> yes, it is a test machine (or dev on our production environment --> EC2)
[15:43] <j_baker> I'm having a bit of trouble downloading anything at https://launchpad.net/bzr/+download ... Is it just my network connection, or is anyone else having the same problem?
[15:43] <sevenseeker> so no, not central server
[15:43] <sevenseeker> although I will need that soon
[15:43] <LarstiQ> sevenseeker: you can create a working tree by using `bzr co`
[15:43] <sevenseeker> just for using Trac
[15:43] <LarstiQ> sevenseeker: and then `bzr update` to update the working tree
[15:44] <LarstiQ> (after subsequent pushes)
[15:44] <sevenseeker> oic, I wrongly thought co would 'pull' from another location, not use what is in the .bzr info
[15:44] <sevenseeker> dang, you guys rock
[15:44] <visik7> is my workflow complete ? or did I miss somethng ?
[15:44] <sevenseeker> I really appreciate it
[15:45] <LarstiQ> sevenseeker: to see that clearer `bzr co .`
[15:45] <sevenseeker> I am still coming from svn, so used to that way, lol
[15:46] <LarstiQ> visik7: I'd do: `cd trunk; bzr pull; bzr pull ../feature-branch; (if that failed, bzr merge ../feature-branch); bzr commit; bzr push`
[15:47] <LarstiQ> visik7: alternatively, you could make use of checkouts and their lock-step development mode
[15:48] <luks> sevenseeker: hm, I wonder what are you used to with svn
[15:48] <luks> sevenseeker: because svn doesn't allow creating and managing working copies on remote servers
[15:48] <LarstiQ> luks: `svn co` vs `bzr co .`
[15:48] <visik7> but on the last 2 commands between commit and push do you check if new changes are in ?
[15:48] <sevenseeker> I know, I meant that svn co pulled data from a remote source
[15:48] <sevenseeker> not pushing :)
[15:48] <luks> ah
[15:49] <LarstiQ> visik7: no, because you had already pulled trunk to mirror remote
[15:49] <visik7> but how could you know if someone update the remote ?
[15:50] <LarstiQ> visik7: you would know if push said they diverged
[15:50] <visik7> oh ok
[15:51] <visik7> thanks
[15:51] <LarstiQ> visik7: as I said, checkout with it's check at commit time might suit you better
[15:53] <visik7> what's the difference between push/pull and checkout/commit a part that the branch is bound ?
[15:54] <LarstiQ> visik7: ehm, that's not the relevant grouping
[15:54] <visik7> ok I miss something
[15:57] <visik7> could you explain me please ?
[15:58] <LarstiQ> visik7: push/pull/checkout/commit are useable in both situations
[15:58] <LarstiQ> visik7: in fully distributed mode, making a new revision (commit) and publishin that revision (push) are decoupled
[15:59] <LarstiQ> visik7: in a central style (bound branch), commit will also make your revision available in the branch you are bound to.
[15:59] <LarstiQ> visik7: however, that doesn't diminish the use of push to publish revisions in other locations.
[16:00] <LarstiQ> visik7: commit will also check that you're not diverged, and suggest you run update if you are.
[16:01] <LarstiQ> visik7: in the fully distributed mode, update is used to bring the working tree at the same revision as the branch, as seen in sevenseeker's situation
[16:01] <visik7> so I don't understand how to use what you call "checkouts and their lock-step development mode"?
[16:01] <LarstiQ> visik7: for bound, update will bring the working tree (and local branch) up to date with the master branch
[16:02] <LarstiQ> visik7: if you're more familiar with a bound branch, use that term instead of a checkout
[16:02] <visik7> I suggest my team to unbound their own branck
[16:02] <LarstiQ> visik7: in that case, B can not commit to a state where he'd diverge from the shared trunk
[16:02] <visik7> I don't really like bounded branches
[16:02] <visik7> oh for that
[16:02] <LarstiQ> yes
[16:02] <stbuehler> I'm having fun with bzr-svn again... bzr push takes ages (discovering branches [...]), bzr dpush doesn't work, and i still don't get the svn rev ids for the commits i pushed in the bzr log
[16:02] <LarstiQ> visik7: if you don't want to use them, that's fine.
[16:03] <LarstiQ> visik7: you'll get diverged branches from time to time, and you'll have to merge
[16:03] <LarstiQ> visik7: if trunk is diverged yet again after you do that, you'll have to merge again
[16:03] <visik7> LarstiQ: I like unbound but I think that for other developers bounded branches are better
[16:03] <LarstiQ> visik7: depends on what they're comfortable with
[16:04] <visik7> they have never used VCS nor DVCS
[16:04] <Milo-> I don't want to run "bzr serve" as root, what kind of permissions do I have to set for my server's users in order to my 'bazaar' -user to have access to the branches?
[16:05] <Peng_> Milo-: That depends entirely on the permissions on your branches...
[16:05] <Milo-> the branches are automatically created with 700, which I can't seem to change
[16:05] <LarstiQ> visik7: that can mean they'll accept any new way of thinking :)
[16:06] <Milo-> haven't found a way to create them with some other permissions instead
[16:06] <LarstiQ> Milo-: how are they created?
[16:06] <Milo-> when running bzr init ftp://my-ftp.my-domain.myTLD/branch
[16:06] <visik7> LarstiQ: yes but it's already difficult to explain a VCS I can't afford to explain DVCS they probably starts to running around screaming
[16:06] <LarstiQ> Milo-: I'll mention `setfacl` and POSIX acls before I know what the situation is
[16:06] <LarstiQ> Milo-: if you can, using something that is not ftp will be better
[16:07] <visik7> LarstiQ: so for B -> update -> merge if errors -> commit ->merge if errors ?
[16:07] <LarstiQ> visik7: right, then checkouts might be better for them
[16:07] <Milo-> ssh would be create, but chrooting it is harder
[16:07] <Milo-> erm
[16:07] <Milo-> great*
[16:07] <Milo-> not create, hah
[16:07] <visik7> B is my fellow developer :)
[16:07] <LarstiQ> visik7: commit -> update if mentions -> commit -> update if mentions, etc
[16:08] <visik7> so no steps before starts coding ?
[16:09] <LarstiQ> visik7: `bzr checkout url/to/master; cd new-checkout; *hack*; bzr diff; bzr commit;`
[16:09] <Milo-> setfacl -m u:myBazaarUser:rx hmm, I'll try that
[16:10] <LarstiQ> Milo-: either I mistunderstand your question, or you're looking for group instead
[16:10] <Milo-> the users are in the bazaar group
[16:11] <Milo-> but the dedicated bazaar-user still can't access the files :/
[16:11] <visik7> LarstiQ: yes the checkout part is already done, I mean ... in the morning ... before everything take place a bzr update is suggested right ?
[16:11] <Milo-> and I need to find a way for bazaar to set up permissions for the group when ever it creates new files.
[16:11] <LarstiQ> Milo-: paste from my situation:
[16:11] <LarstiQ> setfacl -m group:developer:rwx /bzr
[16:11] <Milo-> I don't want to setup dedicated bazaar server as root
[16:12] <LarstiQ> setfacl -m default:group:developer:rwx /bzr
[16:12] <LarstiQ> visik7: not needed, but doesn't hurt to get new revisions before you start working
[16:12] <Milo-> LarstiQ I get "operation not supported" when I run that
[16:13] <LarstiQ> Milo-: feh, then your fs doesn't have POSIX acl support (turned on)
[16:13] <Milo-> ah
[16:13] <LarstiQ> Milo-: in that case, you'll need to fall back to plain old unix permissions
[16:13] <LarstiQ> Milo-: with setgid
[16:13] <Milo->   ? ?    [*]     Ext3 POSIX Access Control Lists                           ? ?
[16:13] <LarstiQ> Milo-: and appropriate umasks
[16:13] <Milo-> it's definitely there
[16:14] <LarstiQ> Milo-: and the fs in question is ext3? :)
[16:14] <Milo-> indeed
[16:14] <LarstiQ> mkay
[16:14] <LarstiQ> Milo-: they really are the most convenient way of solving this problem
[16:14] <LarstiQ> Milo-: could you pastebin the exact sequence?
[16:15] <Milo-> exact sequence?
[16:15] <Milo-> I rather ask something stupid than paste something stupid
[16:15] <LarstiQ> Milo-: a transcript of the commands you typed in and their output
[16:15] <LarstiQ> Milo-: the one that gave ris to 'operation not supported'
[16:16] <Milo-> http://codepad.org/9L366Wmt
[16:17] <LarstiQ> Milo-: ok, and `mount | grep home` just to make sure?
[16:17]  * LarstiQ googles the error
[16:17] <Milo-> /dev/sda2 on /usr type ext3 (rw,noatime)
[16:18] <Milo-> no 'home'
[16:18] <LarstiQ> Milo-: ah, you might be missing some user-land utilities
[16:18] <visik7> thanks LarstiQ
[16:18] <LarstiQ> Milo-: got libacl1 ?
[16:18] <visik7> see you later
[16:19] <Milo-> no such thing in the portage :o
[16:19] <LarstiQ> Milo-: luckily you did a human grep for the information I was after anyway ;)
[16:19] <Milo-> I do have sys-apps/acl
[16:19] <LarstiQ> Milo-: sounds about right
[16:19] <Milo-> which has access control list utilities, libraries and headers
[16:20] <Milo-> well, I do know around my setup
[16:21] <Milo-> but creating this dedicated user for bzr server is giving me a lot of trouble
[16:22] <LarstiQ> Milo-: a dedicated user doesn't sound too sensible
[16:22] <Milo-> well, I don't want to run the server as root
[16:22] <LarstiQ> that sounds even less sensible :)
[16:22] <Milo-> not wanting, or running it as root?
[16:22] <LarstiQ> running it as root
[16:23] <LarstiQ> it has no business near root
[16:23] <Milo-> that's what I thought
[16:23] <LarstiQ> Milo-: maybe we should take a step back and discuss what your desired outcome is?
[16:23] <Milo-> I've plenty of users on my server, which are there to use bzr, share their projects and such
[16:23] <LarstiQ> right
[16:23] <Milo-> the users have their own accounts to do the changes, commits, etc
[16:24] <Milo-> and the bzr serve is there to let them share their projects as readonly (bzr branch bzr://..../branch
[16:24] <Milo-> )
[16:24] <LarstiQ> ok
[16:25] <Milo-> first I tried to do that with anonymous ftp user, but it hit the brick wall since bzr kept creating all the .bzr folders with 700 permissions
[16:25] <Milo-> and now I think this one is hitting the same brick wall as well.
[16:26] <LarstiQ> Milo-: you don't want to provide readonly access via http?
[16:26] <LarstiQ> Milo-: or even bzr+ssh:// to other users branches?
[16:26] <Milo-> that should also have the same issue, no permissions to the folders.
[16:27] <LarstiQ> because they're using ftp to push their branches, and that results in 700 permissions?
[16:27] <Milo-> bzr+ssh would be okay, but that'd require a lot of configuring for my ssh settings and ensuring that ssh is still chrooted (for which, I haven't found a working tutorial yet)
[16:27] <LarstiQ> Milo-: what umask is the ftpd employing?
[16:27] <Milo-> 0022
[16:28] <LarstiQ> hmmm
[16:28] <LarstiQ> Milo-: could you try a push with bzr+ssh:// or sftp:// to see if it has the same permissions?
[16:28] <Milo-> I don't want those users to have actual shell-access
[16:29] <Milo-> sftp:// only seems to work with default port
[16:30] <LarstiQ> Milo-: regardeless of that, I'd like for you to test out and see what happens
[16:30] <Milo-> oh and sftp doesn't work if I'm blocking them from logging in
[16:30] <LarstiQ> Milo-: if those _also_ get to 700, we have a problem somewhere else
[16:31] <Milo-> bzr: ERROR: No such file: '/test': [Errno 2] No such file
[16:31] <Milo-> that was with bzr init
[16:32] <Milo-> oh yeah
[16:32] <Milo-> sftp takes absolute path
[16:32] <Milo-> sftp created the repo with the right mask
[16:32] <Milo-> so it's an ftp issue
[16:33] <LarstiQ> yeah
[16:33]  * LarstiQ hates hates ftp
[16:33] <Milo-> But I can't let my users to use sftp, since I don't want to use default ssh port and I don't want them to be able to have ssh login rights
[16:34] <LarstiQ> Milo-: that's fixable, but let's see what we can do with ftp
[16:34] <Peng_> I thought OpenSSH's sftp is known for screwing up masks.
[16:34] <Peng_> Or maybe it's group ownership. Anyway, it's something!
[16:34] <LarstiQ> Peng_: fixed in a 5.x release
[16:34] <Peng_> LarstiQ: Oh, cool.
[16:34] <LarstiQ> afaik istr
[16:35] <Peng_> ...I'm pretty sure I'm not crazy enough to build my own OpenSSH, though. :D
[16:35] <LarstiQ> Peng_: 5.1 is in sid and testing
[16:36] <Milo-> bzr+ssh:// also worked well
[16:36] <Peng_> LarstiQ: Well, I don't run sid and testing.
[16:36] <Milo-> so how to fix ftp
[16:38] <LarstiQ> Milo-: if you could provide more debugging information on https://bugs.edge.launchpad.net/bzr/+bug/326543 that might help
[16:39] <LarstiQ> Milo-: maybe run bzr with -Dtransport
[16:39] <LarstiQ> Milo-: ie, `bzr -Dtransport push/init foo` etc
[16:39] <Milo-> -Dtransport does what?
[16:39] <LarstiQ> Milo-: server logs of your ftpd might also help debug this
[16:39] <LarstiQ> Milo-: add verbose prints for transport (sftp/ftp/ssh/http) activity to .bzr.log
[16:39] <Milo-> ok
[16:40] <LarstiQ> Milo-: as well as information on which ftp server you're using
[16:40] <Milo-> vsftpd
[16:40] <LarstiQ> standard enough at least
[16:41] <Milo-> oh forgot, I never received my launchpad confirmation
[16:41] <Milo-> something wrong with my mail-box. It decides to ignore some weird places
[16:41] <Milo-> probably something wrong with my own domain settings
[16:42] <jseabold> Was wondering if someone could help me out.  I've found some help here on this problem a few weeks ago, but it persists.
[16:42] <jseabold> I work on one branch on launchpad from two computers and even though I've committed and pushed visible changes to lp from one computer.
[16:42] <LarstiQ> Milo-: if you do the debugging work, I can attach it to the bugreport :)
[16:42] <jseabold> When I run bzr status on my other computer it says up to date with revision 1728 when the newest revision on the branch is 1730.
[16:43] <LarstiQ> jseabold: `bzr status` compares your working tree with your local branch data. It does not check remotely.
[16:43] <jseabold> sorry bzr update gives tree is up to date
[16:43] <Milo-> LarstiQ could you tell me exactly what you want for that report?
[16:44] <jseabold> but what it reports as up to date and what is on launchpad as the newest revisions is different
[16:45] <LarstiQ> Milo-: sure. `bzr init ftp://` goes wrong, right? I'd like to see results of `bzr -Dtransport init ftp://` from ~/.bzr.log
[16:46] <Milo-> ok
[16:46] <LarstiQ> jseabold: what does `bzr info` say your branch type is?
[16:47] <jseabold> Standalone tree (format: pack-0.92)
[16:47] <jseabold> Location:
[16:47] <jseabold>   branch root: .
[16:47] <Milo-> woah currently I just keep getting this with all ftp-operations. http://codepad.org/1LhPZobe
[16:47] <Milo-> I might have broken my ftp
[16:47] <LarstiQ> jseabold: right, standalone tree, not a checkout.
[16:47] <LarstiQ> jseabold: you want `bzr pull`, not `bzr update`
[16:48] <jseabold> LarstiQ: that was my next question.  thanks! So I should only use update on a checkout and pull on a standalone tree?
[16:49] <LarstiQ> jseabold: for this usecase, yes
[16:50] <jseabold> LarstiQ: wonderful thank you very much
[16:50] <eydaimon> bzr serve seems to not give me anything good when I run it. and by not good, I mean "erroreneric bzr smart protocol error: bad request 'GET / HTTP/1.1\r'".   I'm starting with `bzr serve`. Am I doing something wrong?
[16:50] <eydaimon> oh, it's not an http serve :/
[16:50] <eydaimon> is there a webserver type thing?
[16:50] <LarstiQ> eydaimon: if you have a recent loggerhead installed, you can `bzr serve --http`
[16:51] <eydaimon> loggerhead?
[16:51] <Milo-> LarstiQ interestingly, everything else but the ".bzr" is created with the right permissions :/
[16:51] <Milo-> everything else but .bzr (and lock) is created with 755
[16:51] <LarstiQ> Milo-: you mean, other uses of ftp besides bzr?
[16:51] <Milo-> no, when doing bzr init
[16:51] <LarstiQ> Milo-: or, do you mean .bzr/repository is fine, but .bzr/ is not?
[16:52] <eydaimon> LarstiQ: is it sufficient just to get the latest bzr ?
[16:52] <Milo-> yes
[16:52] <LarstiQ> Milo-: now that is weird
[16:52] <LarstiQ> eydaimon: no, loggerhead is a seperate project
[16:52] <Milo-> but 'other' needs to have access to the .bzr if 'other' wants to checkout or create its own branch out of it
[16:52] <LarstiQ> eydaimon: ie, as a loggerhead package in your distribution, or launchpad.net/loggerhead
[16:52] <eydaimon> ok
[16:52] <eydaimon> thanks
[16:53] <eydaimon> no such option --httlp so I have to upgrade bzr anyway
[16:53] <LarstiQ> Milo-: I'll note it on the bug, it seems relevant
[16:53] <LarstiQ> eydaimon: no, you have to install loggerhead :)
[16:53] <LarstiQ> eydaimon: the --http option is provided by loggerhead, not by bzr
[16:53] <LarstiQ> eydaimon: have a look at the `bzr plugins` output
[16:54] <LarstiQ> eydaimon: loggerhead 1.11    Loggerhead web viewer for Bazaar branches.
[16:54] <eydaimon> got it :)
[16:54] <LarstiQ> eydaimon: that is included in my output
[16:54] <eydaimon> thanks much
[16:54] <LarstiQ> Milo-: ah, a previous reporter also mentioned it
[16:55] <eydaimon> would be nice if plugins were integrated in bzr like packages.. bzr plugin install loggerhead
[16:55] <Milo-> so there is hardly anything new coming from me
[16:55] <Milo-> I'm also using bzr 1.14.1
[16:55] <Milo-> with python 2.5.4
[16:55] <LarstiQ> Milo-: can you try older versions to see if we can pinpoint when this change happened?
[16:55] <eydaimon> no port for loggerhead. hm
[16:56] <Milo-> I can only go back to 1.9
[16:56] <Milo-> but I'll try 1.9, 1.10, 1.11, 1.12, 1.13.2 and the latest 1.15
[16:56] <LarstiQ> Milo-: I'm hoping it's more recent than 1.9
[16:57] <LarstiQ> Milo-: updated the bug
[16:57] <eydaimon> LarstiQ: where would I make such a suggestion for feature besides here?
[16:57] <LarstiQ> eydaimon: talk to bialix, iirc he did something like that in the past
[16:58] <LarstiQ> eydaimon: I just do `cd ~/.bazaar/plugins; bzr branch lp:loggerhead loggerhead`
[16:59] <eydaimon> good advise, thank you
[17:00] <Milo-> bzr-1.9 inited .bzr with 700 :/ but it also created everything else with 700 permissions
[17:07] <Milo-> same result with 1.10, 1.11, 1.12 (.bzr and its subfolders and files are created with 700 permissions)
[17:07] <LarstiQ> Milo-: ok
[17:07] <LarstiQ> Milo-: it did change between 1.9 and 1.10 though?
[17:07] <Milo-> no
[17:08] <LarstiQ> the subfolders permissions?
[17:08] <Milo-> 19:01:02   Milo- >> bzr-1.9 inited .bzr with 700 :/ but it also created everything else with 700 permissions
[17:08] <Milo-> so they're same as 1.10, 1.11, 1.12
[17:08] <LarstiQ> vila: ^^ do you have an idea why ftp permissions on .bzr might be broken since at least 1.9? bug 326543
[17:08] <Milo-> and 1.13.2
[17:09] <LarstiQ> Milo-: doh, didn't look at the correct end of the interval
[17:09] <Milo-> I'll try the 1.15 as well
[17:09] <LarstiQ> Milo-: 1.9 through 1.13.2 differ from 1.14.1 in the permissions of the subfolders?
[17:09] <Milo-> yes
[17:09] <LarstiQ> ok
[17:09] <Milo-> 1.14.1 created subfolders and files with right permissions
[17:11] <vila> LarstiQ: hmm, strange, all file/directories should have the same permission, that bug wasn't on my radar, I'm sure there was at least one bug, but I was convinced it has been fixed
[17:11] <Milo-> hmm
[17:11] <LarstiQ> vila: note, ftp, not sftp
[17:11] <Milo-> actually
[17:11] <Milo-> I
[17:11] <Milo-> nope
[17:11] <vila> yes ftp
[17:11] <LarstiQ> ok
[17:11] <Milo-> I'll paste you the permissions
[17:11] <vila> oh wait !
[17:11] <Milo-> I re-did my tests :/
[17:11] <vila> ftp need server side support !
[17:12] <vila> isn't there an option for that in vsftpd ?
[17:12]  * vila refreshing memory a bit
[17:12] <Milo-> http://codepad.org/2WQbwSQp there you have it :/
[17:13] <Milo-> and those actually applies to all versions between 1.9 - 1.5 :/
[17:13] <Milo-> erm
[17:13] <Milo-> 1.9 - 1.15
[17:14] <Milo-> so LarstiQ no, there wasn't any changes between 1.9 and 1.14.1, except I made a bad test.
[17:14] <vila> chmod on ftp is implemented via the SITE CHMOD command
[17:14] <vila> Milo-: Do you have *one* bzr version that produces the right permissions ?
[17:14] <Milo-> no
[17:14] <Milo-> portage only goes down to version 1.9
[17:15] <Milo-> file_open_mode=0777
[17:15] <Milo-> local_umask=0022
[17:15] <Milo-> those are my vsftpd.conf's settings
[17:15] <vila> Milo-: Ha, ok, then I'd say vsftpd may not respect our commands, can do a single test and look at your .bzr.log
[17:16] <vila> all _setmode commands should display the permissions asked
[17:16]  * LarstiQ heads to jitsu training
[17:16] <Milo-> 1.826  FTP site chmod: setting permissions to 0600 on /test06/.bzr/README
[17:16] <Milo-> :o
[17:16] <Milo-> that's from the logs
[17:17] <vila> weird
[17:17] <Milo-> I'll paste it
[17:17] <vila> Milo-: to the bug report ?
[17:17] <Milo-> http://codepad.org/yZ9Q8HYs
[17:18] <Milo-> I'm not receiving the confirmation mail :/
[17:18] <Milo-> so I can't create a bug-report
[17:18] <Milo-> something wrong with my email-configs
[17:21] <vila> Milo-: ok, I've marked the bug as confirmed so we'll better track it from there
[17:22] <vila> beuno: whoohoo, first time I update a tag in place :0)
[17:22] <Milo-> something weird is happening with my domain's email settings, launchpad is the second confirmed host that doesn't send mails through my domain, microsoft is the first one.
[17:28] <jam> hey vila, what are you still doing around :)
[17:28] <vila> jam: hey jam ! Fixing bzr-gtk pb :-)
[17:31] <jam> vila: I was curious if you had a chance to peek at the 'better_heads' code
[17:31] <jam> I'm guessing not
[17:31] <jam> anyway, I did an interesting check today
[17:31] <jam> about how many nodes we "access" to determine heads()
[17:31] <jam> and it seems that GDFO isn't helping a lot there.
[17:31] <jam> It helps a little
[17:32] <vila> jam: :-/ But I will spend ~4hours in the train tomorrow, your nudge came at the right momemnt :)
[17:32] <jam> as we access ~86% the total nodes
[17:32] <jam> (well the same number of nodes = _nodes[key] versus get_parent_map([keys]) sort of thing)
[17:32] <jam> on the flip side, w/ "linear dominator"
[17:32] <jam> we access only 57%,
[17:32] <vadi2> Is it ok to have to commit after you do bzr merge each time?
[17:33] <vila> which graph ? bzr ?
[17:33] <jam> vila: right bzr.dev
[17:33] <jam> when doing a "heads()" check
[17:33] <jam> at merge revisions
[17:33] <jam> (comparing the two merge parents
[17:33] <jam> )
[17:33] <jam> I'd be interested to see the effect for stuff like per-file graphs, etc
[17:33] <jam> But I figured this was a reasonable start at a real-world case
[17:34] <jam> I would guess that per-file graphs will be even more linear, and 'linear-dominator' will have a larger effect
[17:36] <jam> vila: what happened to your patch to change GC.annotate() to use a graph on the parent_map() rather than the VF itself?
[17:36] <jam> It doesn't seem to be present in my bzr.dev
[17:37] <vila> huh
[17:37] <jam> vila: actually, it could just be an old branch
[17:37] <jam> let me check
[17:38] <jam> vila: old branch, sorry
[17:42] <jam> vila: anyway, linear_dominators is probably even harder to cache than GDFO
[17:42] <jam> inserting a new merge child needs to invalidate any entries that were referencing the parents, etc.
[17:43] <vila> jam: same complexity I'd say, and I think we need *both* anyway
[17:43] <jam> vila: not at all. GDFO is only mutated by ghosts
[17:43] <jam> 'linear dominator' can be invalidated by a new child
[17:44] <jam> http://paste.ubuntu.com/192751/
[17:44] <vila> jam: oops. yes of course, too many eggs at once
[17:45] <jam> anyway, I won't distract you more
[17:45] <vila> jam: let me finish my submission for bug #385191
[17:53] <vila> jam: as a side note, either you should start writing your graphs upside-down or we should ask qlog and bzr-gtk to write theirs upside-down :-D
[17:53] <jam> vila: time always flows down for me. "bzr log --forward"
[17:53] <jam> I don't really care what qlog does :)
[17:53] <jam> it is also a heck of a lot easier to write by adding more text below
[17:53] <vila> --forward.... vade retro performance satanas !
[17:54] <jam> bzr log --short --forward -r -10..-1 is perfectly fast
[17:54] <vila> jam: I know your rationale :-) Just mentioning the fact that I sometimes mix things when switching my wet parser :)
[17:57] <jam> vila: I suppose we just need to teach vim how to 'invert' a graph :)
[17:57] <jam>  / => \ etc
[17:57] <jam> and swaps the lines around
[17:58] <vila> ctrl-w is not cut under xchat...ctrl-w is not cut under xchat...ctrl-w is not cut under xchat...ctrl-w is not cut under xchat...
[17:58] <jam> :)
[17:58] <jam> I had the same problem with ^L for a while
[17:59] <jam> On my Ubuntu machine, Vim had problems displaying all the text, and ^L was refresh
[17:59] <vila> jam: or find the right way to inject your ascii art in dot
[17:59] <jam> but in Pidgin, ^L is "clear history"
[17:59] <jam> which... is painful when talking
[17:59] <vila> I'm pretty at swapping ctrl and apple when switching from ubuntu to OSX but sometimes...
[18:00] <vila> At least I don't mixup ctrl-backspace with ctrl-alt-backspace anymore....
[18:00] <jam> :0
[18:13] <vila> so, what I had in mind is caching the first children with more than one children for each revision, and yes, this may have to be updated differently, but it will also help a lot for loading graph chunks
[18:13] <vila> or avoid loading them
[18:16] <jam> vila: do you mean "first ancestor with more than one child"?
[18:16] <vila> jam: gee, time to stop, obviously I can't think or write clearly anymore :-/
[18:16] <jam> for my work, I'm tracking "oldest ancestor with only one parent and one child"
[18:17] <jam> which is slightly different
[18:17] <jam> but fairly important for what I'm doing
[18:17] <jam> for http://paste.ubuntu.com/192784/
[18:17] <jam> yours would have all of them point to A
[18:17] <jam> mine has the left point to B, and the right point to C
[18:18] <jam> Because heads(B, C) == heads(F, G)
[18:18] <jam> (sort of)
[18:18] <jam> but if you went back to A, you don't know enough
[18:20] <jam> anyway, I'm willing to be flexible if we find things that work better
[18:20] <jam> that seems to be working for me
[18:21] <jam> I think your version could also be interesting
[18:21] <jam> I would just need to think more about the implications
[18:34] <vila> jam: same here (about flexibility), I need to play a bit with a couple of ideas to better *feel* the implications :-)
[18:34] <vila> jam: EOD for me I need still ned to pack for tomorrow
[18:35] <jam> vila: interestingly, caching the heads() for linear dominators seems to make "bzr annotate" about 38=>28s
[18:35] <vila> a ga bo zu even still need to pack damn :)
[18:35] <vila> in the OOo case ?
[18:35] <jam> vila: in the "time bzr annotate NEWS" case
[18:36] <jam> I'm sure it depends on the structure of the file
[18:36] <jam> but NEWS has a lot of history, and a lot of "common introduced" lines to resolve
[18:36] <jam> I'm getting 2.3M calls to heads()
[19:10] <jam> hmm... only because I was accidentally combining the number of heads() calls with the number of parents stepped...
[19:11] <jam> so out of 135k calls to heads(), 126k are exact repeats (calls to revisions we've already resolved), and 7.8k are calls where we already know the dominator resolution
[19:12] <jam> leaving only 1.4k times that we actually need to walk the graph
[19:13] <jam> which then takes 5s out of 28.5s total time...
[19:53] <vadi2> How do I resolve a conflict where a file with the same name was moved into a folder with another file with the same name? content-wise, they're similar, so I merged content from one into another manually, and deleted the .moved file. however bzr still thinks there is an issue
[19:55] <LarstiQ> vadi2: have you called `bzr resolve <file in question>`?
[19:55] <vadi2> Think that did it. Thanks, was just using bzr resolve before
[20:31] <AnAnt> Hello, I got a question
[20:31] <hmeland> Are anyone else seeing "bzr pull" output like "http://bazaar.launchpad.net/%7Eabentley/bzrtools/bzrtools.dev/ is permanently redirected to file:///home/hmeland/.bazaar/plugins/bzrtools/" when using the current development version og bzr-svn?
[20:31] <AnAnt> let's say I want to make changes to some branch lp:~user1/project
[20:31] <AnAnt> so I do bzr branch lp:~user1/project
[20:32] <AnAnt> which say downloads 60 MB
[20:32] <AnAnt> then I do my little changes, and commit, then I want to push to my own branch: bzr push lp:~me/project
[20:32] <AnAnt> will that push 60 MB to launchpad ?!
[20:33] <Peng_> AnAnt: With a recent version of bzr and (maybe) a recent branch format, no.
[20:33] <AnAnt> Peng_: is 1.13.1 recent ?
[20:34] <AnAnt> Peng_: and what format is recent ?
[20:34] <AnAnt> Peng_: is pack-0.92 a recent format ?
[20:35] <AnAnt> hmmm
[20:37] <Peng_> AnAnt: The feature is called stacking, and it has been supported since bzr 1.6, and the 1.6 disk formats. Newer versions will automatically upgrade the disk format. I don't know if 1.13.1 is new enough.
[20:37] <Peng_> AnAnt: It probably is. Try it and see!
[20:37] <AnAnt> ok
[20:39] <AnAnt> thanks
[20:46] <The_User> Hi!
[20:48] <The_User> I think my repository is broken: bzr co file:///myrepo/mybranch
[20:48] <The_User> Message:
[20:48] <The_User> bzr: ERROR: Revision {<email>-<date>-<charsequence>} not present in "<file or folder>-<date>-<other charsequence>".
[20:48] <The_User> When I create a new repository it works.
[20:48] <The_User> The error occures in 1.14 and 1.16 (bzr snapshot)
[20:48] <The_User> What could I do?
[20:56] <Peng_> The_User: The developers may be able to help you, if you provide them with non-anonymized information. :P
[20:57] <jelmer> mwhudson: hi
[20:58] <garyvdm> Can a file id contain unicode chars - or will it all ways be ascii?
[21:00] <jelmer> garyvdm: they should always be plain string objects, and afaiu they can only contain ascii characters
[21:01] <jelmer> but I'm not entirely sure about that last bit
[21:01] <garyvdm> jelmer - so if I have to cast from a QString - I can use str()?
[21:01] <garyvdm> or should I use unicode()?
[21:02] <jelmer> garyvdm: you'd want str()
[21:02] <garyvdm> jelmer: Ok thanks
[21:02] <jelmer> there shouldn't be a reason for file ids to ever be in a unicode object
[21:03] <LarstiQ> garyvdm: you might even need to encode from a QString
[21:03] <garyvdm> jelmer: I did test adding a file with unicode chars in its name - and it excluded all the unicode chars from the file-id.
[21:04] <garyvdm> no - str(QString) works fine.
[21:05] <LarstiQ> garyvdm: hmmm
[21:06] <abentley> jelmer, garyvdm: file-ids may have unicode characters in them.
[21:06] <garyvdm> abentley - oh
[21:06] <jelmer> abentley: ah, ok
[21:06] <The_User> @Peng_ I could provide any information but I don't think that you could read the char-sequences, it's the same with different branches but with different filenames and charsequences
[21:06] <abentley> garyvdm: If you want to test what's *possible*, rather than default behaviour, use bzrlib.
[21:06] <LarstiQ> garyvdm: ah, it seems str(QString) will already encode
[21:07] <jelmer> abentley: but always utf8 then?
[21:07] <abentley> jelmer: No, unicode.
[21:07] <jelmer> abentley: I can't remember ever running across actual unicode objects for file ids in Bazaar API's
[21:07] <LarstiQ> garyvdm: str(QString(u"tähti")) → UnicodeEncodeError: 'ascii' codec can't encode characters in position 1-2: ordinal not in range(128)
[21:07] <jelmer> abentley: where is that used?
[21:08] <garyvdm> LarstiQ: yes
[21:08] <The_User> Peng_: bzr log crashes, should I print the backtrace?
[21:08] <abentley> jelmer, garyvdm: http://paste.ubuntu.com/192914/
[21:08] <LarstiQ> The_User: pastebin it please
[21:09] <The_User> okay
[21:09] <abentley> jelmer: I don't claim it's used anywhere.
[21:12] <jelmer> abentley: \u doesn't get expanded in a plain string afaik
[21:12] <mwhudson> jelmer: yo
[21:13] <jelmer> abentley: if I use a unicode object I get an exception about it not being a utf8 string
[21:13] <jelmer> mwhudson: you were looking for me earlier, or was that about the qemu-kvm git repo?
[21:13] <abentley> jelmer: Cool.  I guess they're utf-8 strings these days.
[21:14] <mwhudson> jelmer: the ping was before i started sending you email
[21:15] <jelmer> mwhudson: ah
[21:15] <The_User> LarstiQ: Peng_: I've just removed the email, http://config.fsf.org/trac/public/pastebin/26
[21:16] <LarstiQ> The_User: you missed it at the bottom of the backtrace
[21:18] <The_User> LarstiQ: No, it ends with "were doing when the error eccurred"
[21:19] <The_User> LarstiQ: Oh sorry, unimportant
[21:19] <LarstiQ> The_User: check the KeyError
[21:20] <LarstiQ> The_User: you sniped off the actual command, was it a plain `bzr log`, no other arguments?
[21:20] <The_User> LarstiQ: No other arguments
[21:20] <LarstiQ> ok
[21:21] <The_User> all information is displayed correctly
[21:21] <LarstiQ> The_User: and if you `bzr log -r revid:<that revision>` ?
[21:21] <The_User> but then there is the crash
[21:21] <The_User> also the checkout is executed (files get copied) but then it aborts
[21:22] <The_User> same error with -r revid:
[21:24] <The_User> okay the checkout just creates a .bzr directory with some empty files and directories
[21:27] <The_User> I think that's interesting: bzr log -p: "bzr: ERROR: bzrlib.errors.NoSuchRevision: KnitPackRepository('file:///repo/.bzr/repository') has no revision"
[21:28] <The_User> what could be broken?
[21:36] <The_User> it's exactly the same with bzr branch
[21:36] <LarstiQ> The_User: I'm a bit low on energy after training, sorry. Could you try `bzr reconcile`?
[21:36] <The_User> what does this do?
[21:36] <The_User> should I create a backup?
[21:38] <The_User> reconcile works in the repo but not in the branch
[21:39] <The_User> same keyerror with reconcile, check and log
[21:40] <The_User> after reconcile there is only one pack-file in repository/packs
[21:42] <The_User> add and commit work without any problems
[21:43] <LarstiQ> The_User: meh
[21:44] <LarstiQ> The_User: reconcile fixes some inconsistencies and problems like such, but apparently not this one
[21:44] <The_User> :(
[21:44] <The_User> thanks
[21:45] <The_User> learned a new command :D
[21:46] <The_User> could bzr updates be a problem?
[21:50] <The_User> i mean 1.16 instead of 1.14 or something like that
[21:54] <LarstiQ> The_User: shouldn't be
[21:54] <LarstiQ> The_User: does it look like https://bugs.edge.launchpad.net/bzr/+bug/355951 ?
[21:55] <LarstiQ> The_User: part of the backtrace looks similar
[22:03] <poolie> good morning
[22:05] <LarstiQ> hello poolie
[22:05] <LarstiQ> poolie: do you maybe have time to help The_User with  http://config.fsf.org/trac/public/pastebin/26 (perhaps bug 355951 ?)
[22:06] <LarstiQ> getting things rolling atleast
[22:25] <poolie> The_User: I think it is a dupe of bug 355951
[22:25] <poolie> or rather you are hitting that bug
[22:25] <poolie> The_User: could you please paste your traceback onto that bug
[22:25] <poolie> and probably subscribe yourself
[22:25] <poolie> and then also the output from 'bzr info' on that branch
[23:39] <poolie> jml: today it's all about https://bugs.edge.launchpad.net/bzr/+milestone/1.16
[23:39] <poolie>           June, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ |
[23:39] <poolie>           http://planet.bazaar-vcs.org/
[23:39] <jml> poolie: yes. :)
[23:39] <poolie>           June, 2009 | http://bazaar-vcs.org | http://irclogs.ubuntu.com/ | today's focus: https://bugs.edge.launchpad.net/bzr/+milestone/1.16
[23:39] <poolie> silly irssi
[23:39] <jml> poolie: once I get out of Launchpad meetings :)
[23:39] <poolie> and i filed bug 385719 :)
[23:41] <jml> hard. pshaw.
[23:41] <jml> I do it all the time :)
[23:46]  * mwhudson does it by editing the url :/
[23:46] <poolie> by typing?
[23:47] <mwhudson> yeah
[23:47] <mwhudson> well, for launchpad-code, i have lots of launchpad-code milestones in the history
[23:47] <mwhudson> so find one and change the version
[23:47] <poolie> jam, are you still around? just wanted to say hi
[23:47] <poolie> oh i was asking jml
[23:48] <jml> poolie: front page of project -> click the link
[23:48] <jml> poolie: but also URL hacking
[23:50] <poolie> yeah, it's actually fairly obvious from the project homepage, but i tend to think of it as an aspect of bugs
[23:51] <poolie> and from bug pages it's hard to reach
[23:55] <jml> poolie: so, I'm out of LP meetings now :)
[23:56] <jml> poolie: maybe we should have a call in an hour or so?
[23:56] <jml> (gives me a chance to handle email etc)