[00:00] <lifeless> SamB: so yes, it would kill us.
[00:00] <SamB> lifeless: how does it move the data?
[00:00] <lifeless> we'd have to figure out a lot more structure than we do, which would push memory usage up, processing time up, and increase network traffic - in pathological cases by thousands of times.
[00:00] <SamB> tarball?
[00:01] <lifeless> we send the delta compressed data as-is
[00:01] <lifeless> with the minimum edits to its storage to meet user expectations about when data propogates
[00:01] <SamB> right.
[00:02] <SamB> is that how it works when pulling between formats?
[00:02] <lifeless> depends on the formats
[00:02] <SamB> examples?
[00:03] <lifeless> I don't mean to be rude, but I've a tonne of code to write
[00:04] <lifeless> unless this is more than academic, can I encourage you to look at the various formats in repoformats/
[00:04] <SamB> what code should I read, then?
[00:04] <SamB> oh, repoformats
[00:04] <lifeless> which define constraints like needing topological insertion, atomic transactions etc
[00:04] <poolie> lifeless: bug 390563 is marked in-progress, should it be marked assigned to you
[00:05] <lifeless> cross format fetching is parameterised by the RepositoryFormat objects + the stream behaviour / InterDifferingSerializer (streaming is for network, IDS for local)
[00:05] <lifeless> SamB: we try to do the least work at any time when copying data
[00:06] <lifeless> its the whole background theme to all this code
[00:06] <lifeless> poolie: no
[00:06] <SamB> mmmhmm.
[00:06] <lifeless> poolie: jam has a branch to land
[00:06] <poolie> thanks
[00:13]  * SamB settles for running bzr branch with -rsvn:1000, then bzr pull with -rsvn:2000 etc.
[00:15] <SamB> (for the moment)
[00:19]  * SamB keeps expecting "bzr revert" to ask him hunk-by-hunk for some reason ...
[00:25] <GungaDin> I installed bzr from the source... how do I uninstall it?
[00:33] <lifeless> delete it ;)
[00:35] <GungaDin> it installed like a million files in different directories
[00:38] <lifeless> it should have written the bzr script, and a single directory 'bzrlib' in your python site-packages directory
[00:45] <lifeless> jam: around?
[00:52] <GungaDin> I'm running bzr (1.16 or 1.17rc1) froma Fedora 11 installed inside VirtualBox, and it always hangs around 1054K or 1060K when checking out a branch...
[00:57] <GungaDin> any ideas why?
[00:57] <mwhudson> GungaDin: how long have you left it to conclude that it's hung?
[00:59] <GungaDin> hours?
[00:59] <GungaDin> It succeeds from other machines
[01:01] <poolie> SamB: i fully support getting better api docs, but filing bugs on every class without them, if that's where you're heading, is probably not the most efficient way to do it
[01:02] <poolie> how about if for instance you put up a branch containing your guesses at better descriptions or the answers people give to your questions about the api?
[01:03] <mwhudson> GungaDin: oh ok
[01:03] <mwhudson> GungaDin: no idea then really :(
[01:03] <poolie> hello mwhudson
[01:03] <mwhudson> hi poolie
[01:04] <GungaDin> yeah, weird.
[01:04] <MT-> Can somebody explain the correct way to merge two branches with the same ancestory?
[01:06] <GungaDin> are there any logs I can check?
[01:22] <garyvdm> MT-: bzr merge BRANCH-B
[01:23] <lifeless> GungaDin: you can look in ~/.bzr.log
[01:23] <lifeless> GungaDin: and/or use strace or lsof to see whats going on
[01:23] <MT-> garyvdm: I was confused because I would do that and then get a message when I tried to commit the merge about no changes having been made
[01:24] <MT-> garyvdm: I added --unchanged to the commit and it seems to have worked - thanks
[01:24] <fullermd> Er.  If commit said there were no changes, there probably were no changes...
[01:25] <fullermd> (and if there were, and commit wasn't seeing them, --unchanged probably didn't make it start)
[01:27] <MT-> fullermd: that's why I was so confused
[01:28] <fullermd> I suspect merge's output will be more enlightening.
[01:30] <MT-> http://bzr.pastebin.com/m1d9af2f9
[01:30] <MT-> exactly like I'd expect
[01:37] <SamB> poolie: I wasn't going to do it for every class, no
[01:37] <SamB> for starters, I'm skipping all the ones whose names begin with _ ;-P
[01:37] <poolie> there probably should be some better way to track this
[01:38] <poolie> it just doesn't map well to bugs
[01:38] <SamB> poolie: yeah
[01:38] <SamB> but I couldn't think of any other thing to do that wouldn't get completely lost
[01:39] <SamB> and honestly I don't really have any but the vaguest guesses what it's for ...
[01:39] <mwhudson> http://starship.python.net/crew/mwh/bzrlibapi/undoccedSummary.html
[01:39] <mwhudson> (not linked to or very useful though)
[01:40] <SamB> lots of things might be clearly-enough named/subclassed that a docstring would, in fact, be redundant
[01:40] <SamB> I'm not planning to file bugs against those
[01:40] <lifeless> I think its reasonable, when something confuses you, to ask for help on it
[01:41] <lifeless> if you write a docstring and submit a merge as a result of the help, a bug is kindof wasteful
[01:41] <lifeless> OTOH if you don't  plan to submit a patch yourself, a bug is accurate, but perhaps its unlikely anyone will work on it
[01:42] <poolie> agree
[01:42] <poolie> i think one can be kind of usefully provocative by asking the question and then turning it into the patch
[01:45] <SamB> lifeless: I agree, but to do that ... wouldn't I have to have understood what you said about InterDifferingSerializer ?
[01:46]  * SamB does a lastlog to see if he mentioned it more than once?
[01:47] <lifeless> jml: did my inventory checks stuff get into 1.17rc1?
[01:48] <jml> lifeless, I don't know.
[01:55] <SamB> jelmer: what the heck is a "native foreign revision"?
[02:01] <GungaDin> lifeless - how would lsof or strace help me to understand what's going on?
[02:04] <SamB> GungaDin: well, it might end up telling you that something was actually happening
[02:04] <SamB> or at least give you an idea where they go wrong
[02:08] <GungaDin> How can I uninstall a version installed from the source?
[02:09] <jelmer> SamB: where is that mentioned?
[02:10] <SamB> jelmer: bzrlib.foreign
[02:10] <lifeless> GungaDin: as I said before you need to delete it
[02:11] <SamB> GungaDin: one way would be to install it from the source again, and take note of all the files installed
[02:11] <SamB> and then delete them
[02:12] <GungaDin> why don't you supply an uninstall option??
[02:15] <spiv> GungaDin: python's distutils don't (currently) provide any mechanism to do that.
[02:15] <spiv> There's a proposal on python-dev atm that would address that, I think.
[02:15] <jelmer> SamB: revisions that were not roundtripped from bzr
[02:15] <GungaDin> alright.
[02:15] <GungaDin> thx
[02:16] <SamB> jelmer: yeah ... that was my eventual guess
[02:16] <spiv> GungaDin: if I'm installing something system-wide from source I usually use stow, mostly because it means I can always uninstall it later.
[02:17] <SamB> jelmer: now to figure out how to say that without using an oxymoron
[02:17] <GungaDin> hmmm... never used stow.
[02:17] <GungaDin> never even heard of it, to be honest.
[02:19] <spiv> GungaDin: http://www.gnu.org/software/stow/
[02:19] <spiv> Although it's probably packaged for Fedora, which I think you said you are using?
[02:20] <GungaDin> yeah, it is.
[02:20] <GungaDin> justed yummed it :P
[02:20] <SamB> GungaDin: tastey, is it?
[02:20] <GungaDin> missing a bit of salt.
[02:21] <SamB> hmm, what column should comments be wrapped at?
[02:21] <SamB> more or less
[02:22] <jml> 79
[02:25] <SamB> would it make sense to wrap a bit sooner if it puts a >40 char parenthetical on it's own line?
[02:26] <SamB> well, let me just paste ...
[02:40] <SamB> okay, here it is: http://paste.ubuntu.com/217434/
[02:40] <SamB> which of those comments is better wrapped?
[02:41] <lifeless> the first
[02:42] <SamB> okay, next question: does jelmer like the comment?
[02:58] <garyvdm> jml: why 79 and not 80? Does that apply for all code?
[02:59] <jml> garyvdm, 79 is what pep8 says for general code wrapping.
[02:59] <jml> garyvdm, I don't know whether it's binding on bzr (I suspect it isn't)
[03:00] <jml> garyvdm, but if someone asks a wrapping question about a Python project, you need a good reason to say anything other than 79 :)
[03:00] <jml> (pep 8 actually recommends 72 for comments & docstrings, but that's pretty silly, since none of the editors on my system will do that automatically)
[03:01] <garyvdm> jml: I was just under the impression that it was 80 not 79.
[03:01] <SamB> garyvdm: Emacs displays an \ and wraps if you go over that
[03:01] <jml> (under SamB's configuration)
[03:01] <SamB> (with an 80-character-wide terminal, or the default window size)
[03:01] <SamB> jml: not just mine
[03:02] <garyvdm> Ah - the -1 is for the \
[03:02] <SamB> that's, of course, the *default* default
[03:02] <SamB> garyvdm: yeah
[03:03] <fullermd> Historically, some terminals had Issues(tm) with drawing characters in the last column of the last line, which is one reason to go with 79 over 80.
[03:03] <fullermd> (probably none of them have been USED in a long count of years, but I probably have one in my closet   :P)
[03:04] <SamB> well, depends how you define issues
[03:04]  * garyvdm changes editors edge line from default of 80 to 79
[03:05] <SamB> there are some terminfo/termcap flags to specify standard "issues" terminal type has
[03:06] <SamB> jml: also, my editor seems to have somehow been given the impression that like 72 is good for comments in Python ...
[03:06] <SamB> +something
[03:06] <fullermd> I sometimes wonder how many of those flags still work with modern apps.
[03:07] <fullermd> I was looking through termcap the other week and reflecting that, "Gee, 'xterm' is used all the time, and 'vt100', and probably a few others like 'cons25', but I'll bet 98% of these entries haven't been used in 20 years."
[03:08] <SamB> fullermd: could be, but some of these flags *apply* to xterm and/or some of it's ilk
[03:09] <SamB> (oh, and better not forget "linux" and "screen")
[03:10] <fullermd> Yeah.  But then there are all these comments about "I don't know what this entry is for, there's no model number or attribution", with timestamps in the early 80's.
[03:11] <SamB> yeah, probably those ones aren't really used much ;-)
[03:11] <lifeless> jml: I routinely use all 80
[03:11] <lifeless> because the bottom right character works these days
[03:12] <SamB> lifeless: vi-using jerk!
[03:12] <lifeless> :P
[03:14] <fullermd> Yeah.  And all these entries for homebrew terminals...
[03:14] <fullermd> Including (at a spotcheck) some that call for tabset files the system doesn't even include   :p
[03:14] <SamB> what files ?
[03:15] <SamB> anyway, a lot of these flags are basically used by curses + screen
[03:15] <fullermd> Beats me.  I'm not insane enough to have learned termcap that deeply.
[03:15] <SamB> as far as I can tell
[03:16] <fullermd> I learned enough to trick screen into doing some insane things and mess with VT10x and such.  That was quite enough for me.
[03:17] <SamB> I only try to learn it when something isn't working right
[03:18] <jml> test_transport_implementations has been renamed to per_transport?
[03:21] <lifeless> jml: sounds plausible
[03:23] <mwhudson> jml: i have a branch fixing that
[03:24] <jml> mwhudson, oh cool. anything I can do to get it landed?
[03:25] <mwhudson> jml: i'll ask you to review it
[03:34] <GungaDin> my bzr always hangs on "Fetching revisions:Get stream source"
[03:34] <GungaDin> ....
[03:34] <GungaDin> any ideas why?
[03:35] <lifeless> look at it with strace or lsof
[03:35] <GungaDin> how do I look at it with lsof?
[03:35] <GungaDin> lsof just tells me what files are open.
[03:36] <lifeless> thats right
[03:36] <lifeless> its data about whats going on
[03:36] <lifeless> just as strace would b e
[03:45] <igc> back
[04:00]  * igc hits the review queue
[04:03] <GungaDin> when I do strace on the process, the output is: read(6,
[04:03] <GungaDin> what does that mean??
[04:05] <lifeless> it means its waiting for IO
[04:05] <lifeless> on fd 6
[04:06] <GungaDin> so why isn't any IO coming? :)
[04:07] <lifeless> well, I don't know
[04:07] <lifeless> lsof can tell you what fd 6 is
[04:11] <GungaDin> are there any open source projects that use bzr?
[04:12] <lifeless> yes, lots
[04:12] <GungaDin> such as?
[04:12] <lifeless> mysql
[04:12] <lifeless> I appreciate you're having some trouble, and I'd like to help
[04:12] <lifeless> you need to gather data though
[04:13] <GungaDin> I don't know how really...
[04:13] <GungaDin> I think fd 6 was just a pipe.
[04:13] <GungaDin> apart from that there's nothing much I can say...
[04:13] <GungaDin> checkout works on oher machines.
[04:13] <lifeless> what url scheme are you pulling from?
[04:13] <lifeless> (bzr+ssh? http? ...?)
[04:13] <GungaDin> bzr+ssh
[04:13] <lifeless> that should just work really
[04:13] <SamB> and you can SSH out from that VM fine?
[04:13] <lifeless> is it a very big project or some such?
[04:14] <GungaDin> yup
[04:14] <GungaDin> it's quite big
[04:14] <GungaDin> but it shouldn't hang like this
[04:14] <lifeless> so the client is waiting for data from the server
[04:14] <lifeless> do other clients work on the same project ok?
[04:15] <GungaDin> yup
[04:15] <GungaDin> that's what I said: the checkout works on other machines
[04:16] <lifeless> to answer your other question more fully - http://bazaar-vcs.org/WhoUsesBzr - lists /some/ of the open source projects using bzr
[04:16] <GungaDin> cool
[04:16] <lifeless> there are more (based on people asking for support)
[04:16] <GungaDin> I'll try checking out from one of those project
[04:16] <GungaDin> we'll see how it goes
[04:16] <lifeless> theres something like 20K projects on launchpad with branches
[04:16] <lifeless> all of ubuntu is imported, for instance
[04:17] <GungaDin> imported into bzr?
[04:17] <lifeless> yes
[04:17] <GungaDin> from cvs? svn?
[04:17] <lifeless> depends on the thing
[04:17] <lifeless> most of the ubuntu packaging branches are imported from the dpkg source packages
[04:17]  * wgrant points over to https://code.launchpad.net/ for lots of branches.
[04:17] <lifeless> there are also thousands of svn/cvs/git imports
[04:18] <lifeless> GungaDin: I also suggest you file a bug to provide a place we can gather systematic data about your problem
[04:19] <GungaDin> I don't know if it's a bug.
[04:20] <lifeless> something is wrong somewhere
[04:20] <lifeless> it may be system config
[04:20] <lifeless> or a bug
[04:21] <lifeless> either way, having a place to record notes about the problem is a good idea
[04:21] <lifeless> and we usually do that in our bug tracker
[04:22] <GungaDin> hmmm... seemed to work with https on alltray.
[04:55] <GungaDin> how can I checkout using bzr+ssh from an open source project on launchpad?
[04:55] <GungaDin> or somewhere else.
[04:55] <GungaDin> I'd like to see that the exact scheme works with a different project.
[04:58] <lifeless> setup your ssh keys in launchpad
[04:59] <garyvdm> GungaDin: you need a lp user name with a ssh key set to use bzr+ssh on lp
[04:59] <garyvdm> then bzr branch lp:PROJECTNAME
[04:59] <lifeless> then turn http:// into bzr+ssh://USERNAME@ in any of the http urls
[04:59] <GungaDin> *sigh*
[05:18] <GungaDin> doesn't seem like it's working
[05:18] <GungaDin> where do I check the branches of each project on lp?
[05:22] <spiv> The "code" link for a project will show the branches.  e.g. https://code.launchpad.net/bzr
[05:27] <poolie> i'd like to say just ssh://host...
[05:27] <GungaDin> well, if I bzr+ssh://myaccount@code.launchpad.net/bzr/trunk - it hangs forever...
[05:27] <poolie> i know there's a bug for it
[05:27] <lifeless> poolie: that still really squicks me
[05:27] <poolie> sorry but i think you'll just have to cope
[05:27] <poolie> you don't have to use it :)
[05:28] <lifeless> as long as we don't drop support for bzr+ssh I'll deal
[05:29] <lifeless> but I really think its liable to lead to trouble down the track
[05:29] <GungaDin> lifeless - I can't bzr+ssh the way you mentioned.
[05:29] <lifeless> GungaDin: what happens
[05:29] <GungaDin> nothing
[05:30] <lifeless> no error?
[05:30] <poolie> like the onion or someone said
[05:30] <GungaDin> I tried: bzr co bzr+ssh://myaccount@code.launchpad.net/bzr/trunk
[05:30] <poolie> "why don't we have _optional_ gay marriage?"
[05:30] <GungaDin> eventually I get a timeout error from ssh
[05:30] <spiv> GungaDin: branches are on bazaar.launchpad.net
[05:30] <lifeless> GungaDin: bzr+ssh://myaccount@bazaar.launchpad.net/bzr/trunk
[05:30] <poolie> does that really still time out?
[05:30] <poolie> that's lame
[05:30] <spiv> GungaDin: e.g. bzr+ssh://myaccount@bazaar.launchpad.net/~bzr.dev/bzr/trunk
[05:31] <poolie> i thought the firewall was changed a long time ago
[05:31] <lifeless> GungaDin: actually spiv has it right
[05:31] <poolie> maybe it regressed
[05:31] <lifeless> poolie: I don't follow the onion ref
[05:31] <spiv> GungaDin: if you use "bzr launchpad-login" you can just do "bzr co lp:bzr" and it will look up the right bzr+ssh URL for 'bzr' for you.
[05:31] <poolie> nm, it's a joke
[05:31] <lifeless> poolie: I'm concerned that url handlers in firefox are going to end up fighting with ssh: urls
[05:31] <lifeless> poolie: in a way that won't happen with what we do today
[05:31] <poolie> as if all the people objecting to gay marriage were afraid they personally would have to gay marry
[05:32] <poolie> i'm not saying you're being that silly
[05:32] <lifeless> poolie: and further that we're adding ambiguity that doesn't need to exist
[05:32] <poolie> or indeed that they are
[05:32] <lifeless> poolie: I could care less what individuals use as local scheme aliases; things that are liable to make the ecosystem more fragile are something I do care about.
[05:33] <GungaDin> spiv - I get an error saying it's not a trunk
[05:33] <poolie> we could possibly apply a kind of 'be strict in what you emit' here
[05:33] <poolie> and just treat them as a shortcut on input
[05:33] <GungaDin> sorry..
[05:33] <GungaDin> I mean "not a branch"
[05:33] <poolie> i think bzr rejecting somebody typing the url is too pedantic
[05:34] <spiv> GungaDin: oh sorry
[05:34] <spiv> GungaDin: .../~bzr/bzr/trunk
[05:34] <spiv> GungaDin: that's what I get for typing from memory!
[05:34] <spiv> GungaDin: like I say, I usually just use "lp:bzr"
[05:34] <lifeless> spiv: however that can use http
[05:34] <GungaDin> better
[05:34] <lifeless> spiv: and I don't think it tells the user
[05:34] <GungaDin> thx
[05:35] <lifeless> spiv: which is why I suggested explicitness here for debugging
[05:35] <spiv> lifeless: I'm not disagreeing :)
[05:35] <lifeless> ;)
[05:36] <lifeless> poolie: bzr does tell the user what url they should be using.
[05:37] <lifeless> poolie: if bzr were to nag that its altering the url to be bzr+ssh and translated, well that might be ok. But I think its pragmatically bad to start emitting ssh:// urls ourselves, or encouraging people to put them in app handles
[05:37] <poolie> ah
[05:38] <poolie> i'd forgotten it gave a suggestion in the message
[05:38] <poolie> let's discuss it if/when somebody actually starts on it
[05:39] <lifeless> I'd actually like to put this to bed permanently someday
[05:39] <lifeless> its a bit of a recurring nightmare
[05:39] <lifeless> unless we embed a terminal in bzr
[05:40] <poolie> it's a URL
[05:40] <poolie> it locates a resource
[05:40] <poolie> it doesn't need to say everything about what to do with the resource
[05:40] <lifeless> if you click on  a ssh url in a browser, what should happen?
[05:41] <poolie> presumably it'll go through the 'what app do you want to use for this' function?
[05:41] <poolie> of course at present: nothing happens afaict
[05:42] <poolie> to me this seems reasonable
[05:43] <poolie> what do you think should happen?
[05:43] <lifeless> As a user I'd expect the sshshell (there is a gui ssh shell colin walters has been working on - its really nice) to fire up by default
[05:43] <lifeless> with no questions
[05:44] <poolie> k, that sounds good then
[05:44] <poolie> what's not to like?
[05:44] <poolie> if the web page wants to say "open this in bzr" there should definitely be a syntax for that
[05:44] <poolie> hm
[05:45] <poolie> i mean really it should be something like handwavey ssh://example.com::bzr/some/dir
[05:45] <poolie> ssh there *and then what*?
[05:45] <poolie> just pointing to the directory on the host doesn't really mean a lot
[05:45] <poolie> maybe this is in the ssh url spec
[05:45] <poolie> if any
[05:45] <lifeless> this is a bit of a weakness in std66
[05:46] <lifeless> and AFAIK the only workaround at the moment is in the scheme
[05:46] <lifeless> I'll note that bzr+ is less letters than ::bzr :P
[05:46] <spiv> lifeless: you just need a keyboard with a :: key ;P
[05:47] <spiv> You could maybe adapt a keyboard with a -- key for tla ;)
[05:47]  * lifeless shudders
[05:47] <poolie> i shall treat that trolling with the respect it deserves
[05:48] <lifeless> pragmatically, web browsers dispatch off three things:
[05:49] <lifeless> embedded controls where a plugin is invoked
[05:49] <lifeless> the scheme
[05:49] <lifeless> and the mime type
[05:49] <GungaDin> How big is the the trunk of bzr?
[05:49] <GungaDin> around 68147K?
[05:49] <lifeless> GungaDin: about 70MB
[05:49] <GungaDin> seems like my bzr hangs again
[05:50] <GungaDin> strace shows the same thing
[05:50] <GungaDin> read(6,
[05:50] <spiv> GungaDin: and I guess if you strace the ssh subprocess it's stuck in a recv or a select on a socket?
[05:51] <GungaDin> yeah, select.
[05:51] <spiv> GungaDin: but it's managed to download 68147kB to .bzr ?
[05:52] <GungaDin> seems like it.
[05:52] <GungaDin> apparently it always hangs at the end.
[05:52] <GungaDin> like with my repo.
[05:52] <spiv> I wonder if you have a broken plugin installed?
[05:52] <spiv> Can you try sending SIGQUIT to your bzr process?
[05:52] <spiv> That will drop it into the Python debugger.
[05:52] <lifeless> or -Dhpss perhaps
[05:53] <spiv> Then type "bt" and pastebin the result.
[05:53] <GungaDin> kill -?
[05:53] <spiv> kill -QUIT
[05:53] <GungaDin> well.. I already stopped it with CTRL-C
[05:53] <spiv> Or hit Ctrl-\ in the terminal.
[05:53] <spiv> Ah.
[05:53] <GungaDin> any other smaller repo?
[05:53] <spiv> Did it give a backtrace (or did it leave one in ~/.bzr.log)?
[05:54] <lifeless> GungaDin: you can use the one you were having trouble with earlier, if thats smaller
[05:54] <spiv> ~jml/testtools/trunk on the same server is quite small.
[05:56] <GungaDin> ok
[05:56] <GungaDin> brb
[05:57] <spiv> GungaDin: another test to try would be to add --no-plugins to a command that hangs.
[05:57] <GungaDin> tried that already
[05:57] <GungaDin> it didn't help
[05:57] <spiv> Ok.
[06:01] <lifeless> igc: I have more inventory delta stuff
[06:02] <lifeless> igc: I'll be updating the merge request this avo
[06:02] <lifeless> igc: I'd love if if you could tell me if it sucks perf wise
[06:02] <igc> lifeless: shall do. I want to get through some more reviews then I'll make some measurements ...
[06:03] <GungaDin> I sent a SIGQUIT to bzr... what do you want to do now, spiv?
[06:03] <igc> lifeless: I'm all for safety first but ...
[06:03] <igc> lifeless: we need to be sure we don't throw away all the recent gains accidentally
[06:04] <lifeless> for sure
[06:04] <lifeless> the reason this has taken a week is I've been looking and thinking carefully about every change
[06:05] <lifeless> I'm sure there will be fallout, but I'm also sure it will be much less than the gains we've made by better disk structure
[06:09] <spiv> GungaDin: type "bt" and pastebin the traceback that makes
[06:10] <spiv> GungaDin: that will tell us where in bzr it is stuck, which might help diagnose what's going wrong.  (Even though it's almost certainly not bzr's fault)
[06:18] <lifeless> jml: so, can code auto update diffs please?:) at the moment, clicking superseded and aking a new review seems to me to be *more* work for lp...
[06:18] <jml> lifeless, you're asking the wrong person.
[06:18] <lifeless> thumper isoffline
[06:19] <jml> lifeless, well, I think Launchpad should auto-update diffs too
[06:19] <lifeless> ok cool
[06:21] <lifeless> speaking of which
[06:21] <lifeless> how does one do the superceded dance?
[06:22] <lifeless> I get an error about an existing proposal
[06:24] <lifeless> EOD (started at 6:30 :P)
[06:25] <lifeless> igc: updated thingy submitted
[06:25] <lifeless> poolie: I'll get to your patch early tomorrow
[06:25] <igc> lifeless: thanks
[06:27]  * spiv makes a late lunch
[06:27] <lifeless> igc: I think (I still have to do a careful audit) that I now have complete coverage of things that make deltas go wrong
[06:28] <lifeless> igc: which means that once I've done that audit I can get onto iter_changes again and be protected
[06:28] <igc> lifeless: and in theory, my patch will fail, right?
[06:28] <igc> i.e. be trapped by your new tests
[06:28] <lifeless> igc: your tests won't, but I can construct cases using the regular command line that will make it generate bad deltas
[06:29] <lifeless> and those would be caught
[06:29] <lifeless> anyway, as I promised I'm going to fix iter_changes itself
[06:29] <lifeless> theres no need to layer on it when iter_changes is, itself, broken
[06:30] <lifeless> for instance, a simple example is
[06:30] <igc> lifeless: thanks. I still never got why my stuff was wrong so I'm looking forward to understanding that soon
[06:30] <lifeless> init; mkdir a, touch a/b
[06:30] <lifeless> commit
[06:30] <lifeless> mv a c
[06:30] <lifeless> mkdir a touch a/b
[06:30] <lifeless> commit a/b
[06:31] <lifeless> this sort of situation would turn up after merging parallel imports, for instance.
[06:32] <lifeless> igc: the layering approach isn't /wrong/ in a correctness sense; its wrong in a performance sense because of the full-iteration being done under the hood. Thats tolerable.
[06:32] <lifeless> the correctness wrongness is that you have to spider out upwards just like we do downwards
[06:32] <lifeless> in what we include
[06:33] <lifeless> and that may have further implications (e.g. a spider down impact) that I haven't yet thought all the way through
[06:33] <lifeless> it was while I was thinking it through that I realised our delta sanity checks were totally insufficient to protect us against mistakes
[06:33] <lifeless> anyhow, I'm really done for today.
[06:33] <lifeless> see you all tomorrow
[06:33] <igc> lifeless: sure, seeya tomorrow
[06:51] <GungaDin> spiv: http://pastebin.com/d5fb72ec7
[06:53] <spiv> GungaDin: hmm, so it's stuck while waiting to receive a response to a get_stream request (i.e. the big request that fetches all the data)
[06:54] <GungaDin> but why????
[06:54] <spiv> Yeah, that's the question.
[06:55] <poolie> lifeless: let's talk more when it's a bit closer to the top of my stack
[06:55] <spiv> I mean, I can fetch branches from Launchpad via bzr+ssh just fine.
[06:55] <GungaDin> I tend to think it could be a problem with one of the VM drivers.
[06:55] <GungaDin> I can fetch it fine from other machines as well.
[06:55] <spiv> So if the response isn't making it through to you I'd guess at network weirdness, like a bad MTU setting or something.
[06:56] <spiv> I would have expected that to show up slightly differently, but perhaps not.
[06:56] <spiv> There's certainly nothing particularly special about get_stream, except that it tends to send lots of data fairly quickly...
[07:11] <GungaDin> well, svn works fine...
[07:19] <vila> hi all
[07:33] <poolie> hello vila
[07:33] <vila> hey poolie, I will on and off a bit today, it's national holiday here
[07:34] <poolie> oh right
[07:34] <poolie> bastille day?
[07:34] <vila> yes :) That one, heads on spikes and so on
[07:35] <Kamping_Kaiser> ah, happy days :p
[07:42]  * jml has eats some cake to celebrate it
[07:44] <loxs_> Folks, is there some easy way allow multiple (system) users to commit to the same repository?
[07:46] <spiv> loxs_: create a system group, and chown the repo to that group and set the perms to be group writeable.
[07:46] <spiv> oh, and set the perms to make sure that new directories/files in that repo are also group writeable.
[07:52] <loxs_> spiv, seems like I'll go with access control lists
[07:53] <fullermd> If those'll propogate correctly to new files, it would probably work.
[07:53] <fullermd> bzr will do the work of propogating g+w to new files/dirs; with ACL's, the system itself would have to do so.
[07:54] <fullermd> (and yes, 'propagate' is one of those words I ALWAYS misspell, even though I KNOW I misspell it...)
[08:12] <poolie> just reviewing aaron's merge -i patch, that's very nice
[08:20] <jml> fullermd, you can support a door, or you can prop a gate!
[08:20] <jml> (maybe that's terrible enough that you'll remember it forever)
[08:22] <poolie> eww
[08:23] <jml> I remember a sign or banner or something in my grade 1 classroom that said "Smell _a rat_ when you _separate_"
[08:24] <jml> never ever had a problem with smelling that word! :P
[08:24] <poolie> my favourites are "weird is weird" ie doesn't follow the weak "i before e" rule
[08:24] <poolie> and "its is like his" ie doesn't have an apostrophe
[08:25] <poolie> neither of them are particularly amusing though
[08:34] <igc> vila: happy "heads on stakes" day :-)
[08:35] <vila> Yeah, stakes, spikes, whatever, they were rather unsophisticated you know :-)
[08:36] <vila> It's raining like in November though so for fireworks.... :-D
[08:38] <jml> "Bastille Day was the day that France declared independence. It was a remarkable achievement, coming only ten days after America invented freedom."
[08:48] <RAOF> jml: Heh.  Link?
[08:49] <jml> RAOF, sadly that's all I've managed to make up so far.
[08:49] <RAOF> Boo!
[09:08] <lifeless> fullermd: lp:libcpuinfo has language bindings now
[09:09] <lifeless> fullermd: you might like to let us know if it builds still on BSD :P
[09:15] <fullermd> lifeless: In a quick test, autoreconf gets all uppity about AC_PROG_SWIG and AC_PYTHON_DEVEL and bails.  Don't have time to look more closely right now.
[09:29] <pfctdayelise> hi... is there a way to do a 'bzr branch' to an existing directory?
[09:30] <mwhudson> --use-existing-dir
[09:32] <pfctdayelise> bzr: ERROR: no such option: --use-existing-dir
[09:32] <fullermd> Don't think that'll be released 'till 1.17.
[09:32] <fullermd> (I think it's in 1.17, but I'm not actually sure)
[09:33] <pfctdayelise> hm, push has such an option
[09:33] <fullermd> Yeah, push has had it for ages.  branch just hasn't until very recently (like, last week recently, I think)
[09:34] <pfctdayelise> hm
[09:35] <pfctdayelise> i think i have version 1.5. 1.17 is the latest?
[09:36] <lifeless> fullermd: it needs autoconf-archive
[09:36] <fullermd> Not yet, no.  1.17 won't actually be released until late this week or early next, I believe is the plan.
[09:36] <lifeless> fullermd: and swig - both are doc'd in INSTALL.txt
[09:36] <fullermd> 1.16.1 is the current release.
[09:36] <fullermd> lifeless: Hm.  I thought I had swig installed...   maybe I didn't put it on this machine.
[09:37] <lifeless> its the autoconf-archive i bet though
[09:38] <pfctdayelise> gah. so I pretty much have no choice but to upgrade?
[09:38] <pfctdayelise> or if i move my existing dir, let bzr create it, and then move the other things back, might that work?
[09:38] <fullermd> Well, you always have choices   :)
[09:39] <fullermd> Well...   what's the use-case for having a dir with stuff already in it, and THEN branching?  --use-existing-dir is more aimed at existing _empty_ dirs, I tend to think...
[09:40] <spiv> pfctdayelise: what fullermd said... this sounds like a weird thing to want.
[09:40] <pfctdayelise> well I don't even know if I really want to branch, is the case any different with checkout? I just want to get a copy of the code, not necessarily develop on it
[09:41] <lifeless> you could just bzr branch <src> newdir
[09:41] <lifeless> mv newdir/.bzr ./
[09:41] <lifeless> bzr revert
[09:41] <lifeless> rm -rf newdir
[09:42] <fullermd> Leaving aside the existing dir/files bit, it's probably something like 6 of one, half a dozen of the other, whether you branch or co there, at least in isolation.
[09:42] <spiv> Either way, why do you want to get a copy of the code into an existing, non-empty directory?  Generally you'd do "bzr co URL somedir". (or "bzr branch ...")
[09:42] <pfctdayelise> I am working on a web app, and i didn't put the framework into my bzr source control
[09:42] <pfctdayelise> so i work on it on my home machine, pushed to lp, now trying to get a copy on my web host server
[09:43] <pfctdayelise> is it such a weird set up?
[09:43] <pfctdayelise> lifeless: i might try that :) ta
[09:43] <spiv> What makes it weird I guess is that it mixes unversioned and versioned data.
[09:44] <fullermd> If all the framework files are in their own dir, it's probably easier to "bzr branch lp:foo newdir ; cd newdir ; mv ../framework/dir ./framework" or the like.
[09:44] <pfctdayelise> hm, well the "unversioned" data is probably controlled by its own svn co
[09:44] <lifeless> pfctdayelise: for publishing it I recommend 'bzr upload'
[09:44] <lifeless> pfctdayelise: its designed for deploying web sites
[09:44] <spiv> The use case you just described doesn't sound weird, the part where it's apparently necessary for you to mix the bzr working tree with an existing tree of files still sounds weird to me :)
[09:44] <fullermd> (lifeless's solution would probable be simpler if there were a ton of files scattered all over the place.  But if there are existing dirs shared, be prepared for that to cause conflicts in the revert too)
[09:45] <pfctdayelise> lifeless: bzr: ERROR: No help could be found for 'upload'.
[09:45] <lifeless> pfctdayelise: its a plugin - bzr-upload
[09:45] <spiv> pfctdayelise: https://launchpad.net/bzr-upload
[09:45] <lifeless> ciao
[09:45] <spiv> lifeless: g'night
[09:46] <pfctdayelise> hm... looks interesting
[09:47] <pfctdayelise> so I install this on my 'dumb server'?
[09:47] <svqyqb> http://tinyurl.com/nkypfa
[09:47] <spiv> pfctdayelise: no, on the client, I believe.
[09:48] <pfctdayelise> spiv: as in, my web host? because surely I can't install it at LP. I can install it at my web host or my personal (dev) machine.
[09:49] <fullermd> pfctdayelise: The idea with upload is that you install it on your personal machine, and it takes care up uploading the files to the web host.
[09:49] <pfctdayelise> ah ok
[09:49] <spiv> pfctdayelise: the README might help: http://bazaar.launchpad.net/~bzr-upload-devs/bzr-upload/trunk/annotate/head%3A/README
[09:49] <fullermd> (just the working files, not VCS data like you'd copy up with 'push')
[09:49] <pfctdayelise> right
[09:51] <pfctdayelise> wow, this is perfect. thanks everyone
[09:51] <pfctdayelise> and i just went to the hassle of installing bzr on my web host. oh well, I am sure I'll use it another time :)
[09:52] <spiv> :)
[11:25] <GungaDin> The bzr problem I had earlier also happens in an Ubuntu guest os.
[12:51] <Keybuk> so, how do I use "bzr join" ?
[12:51] <Keybuk> every invocation I try produces errors
[12:57] <LarstiQ> Keybuk: bzr branch foo somebranch/subdir; bzr join somebranch/subdir ?
[12:57] <Keybuk> LarstiQ: "Cannot join somebranch/subdir.  Trees have the same root"
[12:57] <LarstiQ> Keybuk: aha.
[12:58] <LarstiQ> Keybuk: those branches were created before a rich-root format then. I don't know what the correct way to make their tree roots unique is.
[12:58]  * LarstiQ knows how to do it with bzrlib, but that might be breaky
[12:58] <Keybuk> can I not just use "merge" ?
[12:59] <Keybuk> no, apparently not due to file conflicts :-/
[13:00] <LarstiQ> Keybuk: pfoe, you could try that, if you `bzr init --something-rich-root ../newroot; bzr merge -r 0..-1 ../newroot`
[13:00] <LarstiQ> Keybuk: oh merge the two branches?
[13:00] <LarstiQ> Keybuk: yeah, you can do that, if you say in the the subdir branch move everything to be under subdir/ first
[13:01] <LarstiQ> provided they have a common ancestor
[13:01] <LarstiQ> which is sort of disjoint with the usecase for `bzr join`
[13:02] <Keybuk> I can just merge -r 0..-1 if they don't, right?
[13:05] <LarstiQ> Keybuk: yes
[13:07] <Keybuk> cool
[13:07] <Keybuk> I think have a branch that works ;)
[13:08] <LarstiQ> good :)
[13:09] <LarstiQ> Keybuk: I hear jml say that you've done some wicked things to test upstart, is there a writeup available about that, or should I look at the source?
[13:09] <Keybuk> I've done the odd talk about it
[13:10] <Keybuk> basically it's a set of C pre-processor macros that expand to common test constructs
[13:10] <Keybuk> and let me do things like "run a block of code, count the malloc() invocations, then loop over it that many more times failing each malloc() in turn"
[13:10] <Keybuk> as well as all the usual things like "TEST_EQ" and stuff
[13:15] <LarstiQ> maybe I'm just not good enough in C macros to see how to do some of that :)
[13:21] <spiv> LarstiQ: e.g. http://bazaar.launchpad.net/~scott/libnih/trunk/annotate/head%3A/nih/test_alloc.h
[14:29] <Elleo> Hi; is there anyway to completely remove a file from a bzr pack? We had a rather large file in our repository that has since been deleted; but we'd like to remove it completely
[14:30] <Elleo> otherwise our repository is about 50mb instead of 5 and makes branching a somewhat slow and bandwidth heavy operation
[14:34] <vila> Elleo: You can't. But even if you could, that would mean fixing all existing branches (that's what distribution is about, everybody has its own copy of the history)
[14:34] <vila> Elleo: May you want to look at stacked branches ?
[14:35] <Elleo> well we pretty much one have the one main branch at the moment (just shifted over from svn)
[14:36] <Elleo> s/one/just/
[14:36] <vila> Elleo: yet you want to keep the history ?
[14:37] <Elleo> yeah
[14:37] <vila> Elleo: the history includes that large file....
[14:39] <Elleo> yes and unfortunately it was commited right near the beginning of the project; sot here's a lot of commits after it
[14:40] <Elleo> oh well, we can work around it; it's just annoying
[14:41] <vila> Elleo: You may try looking at fast-import to re-create an history starting after the file has been deleted... I think recent versions allows that kind of thing (or it's planned, I don't know exactly, I' don't use it myself)
[14:41] <vila> Elleo: Another way is stacked branches and/or shared repositories so that you don't pay for the bandwidth each time
[14:42] <Elleo> right, I'll take a look; thanks
[14:43] <jam> ping jml, abentley
[14:43] <jam> morning vila
[14:43] <vila> hey jam !
[14:43] <abentley> jam: pong
[14:44] <jam> abentley: I just noticed that +activereviews doesn't seem to include Approved merge proposals anymore
[14:44] <jam> Where am I supposed to go to see what is ready for me to land?
[14:44] <jam> to be explicit, this page: https://code.edge.launchpad.net/bzr/+activereviews
[14:44] <jam> is no longer showing this merge request
[14:44] <jam> https://code.edge.launchpad.net/~jameinel/bzr/1.18-switch-branch/+merge/8469
[14:45] <jam> And I'm not sure what other proposals I have Approved
[14:45] <jam> so that I can make sure to land them all
[14:45] <abentley> jam: I'm not sure it ever did.  Marking them approved gets them out of the review queue.
[14:45] <jam> abentley: I'm sure I used to use it for that
[14:45] <jam> but regardless, it is something I need
[14:46] <jam> is it just not available?
[14:46] <abentley> jam: are you sure you don't mean the requested reviews?
[14:46] <jam> (it may just have been people marking the review as approved, but not the merge)
[14:46] <abentley> jam: https://edge.launchpad.net/~bzr-core/+requestedreviews for example
[14:47] <jam> abentley: well, I've never gone to +requestedreviews before :)
[14:47] <jam> anyway, it is possible that I used to see things that were "review approve" and *not* "merge approve"
[14:47] <jam> but regardless
[14:47] <jam> how can I find a list of things that have been submitted for review
[14:47] <jam> and have been approved
[14:48] <jam> so that I can go land them
[14:48] <jam> I see this: https://code.edge.launchpad.net/~jameinel/+approvedmerges
[14:48] <jam> for just me
[14:48] <jam> is there something for all bzr requests?
[14:48] <jam> I guess this: https://code.edge.launchpad.net/bzr/+approvedmerges
[14:49] <jam> though it seems to fit with the "these are reviews that need to be done, and these are reviews that are approved and need to land"
[14:49] <jam> I'm not sure why it has to be 2 pages
[14:49] <abentley> jam: I don't think there's anything that directly provides what you're asking for.  I've asked for similar things, too.
[14:52] <abentley> jam: I think "merges I need to work on" and "merges I should land" should also be included on that page.
[14:52] <jam> sure
[14:52] <jam> is there a bug for it?
[14:52] <abentley> jam: dunno.
[14:52] <jam> k
[14:52] <jam> I'll look into it
[15:10] <JNRowe> Hi guys, is there any way to figure out why my clone times are so slow.  I've tried wget'ing a dirstate file to test the network speed and I'm getting ~30k/s, but for a bzr get I appear to be averaging ~6k/s
[15:23] <jam> sidnei: ping (are you using kerguelen ?)
[15:26] <sidnei> jam: not ATM
[15:27] <jam> sidnei: k, I went to log in, and there are already 2 connections
[15:28] <jam> ATM they both seem to be Administrator
[15:28] <jam> and one had the buildbot stuff in a terminal and vim
[15:28] <jam> sidnei: do you always log off when you are done?
[15:28] <sidnei> jam: last i logged in was more than a week ago
[15:29] <jam> k
[15:29] <sidnei> jam: yes, unless the connection died at the time, i can't remember
[15:29] <jam> sidnei: so at some point, I'll need you to walk me through how to actually build things with the new layout :)
[15:29] <jam> for now, I'll do 1.17rc1 with the old way
[15:30] <sidnei> jam: ok. i saw ian's comment about adding some documentation
[15:31] <jam> sidnei: I'm a bit surprised he landed it without stuff like fixing the PYTHON26 issue...
[15:32] <sidnei> jam: but basically 'make installer-all' from the top-level
[15:33] <sidnei> jam: is it landed already? too bad then :( i will make a follow up branch with docs and fixing that
[15:33] <jam> sidnei: it is in bzr.dev
[15:33] <jam> It isn't in 1.17 AFAICT
[15:34] <jam> sidnei: I also wonder if we should build a newer svn, I think there is a 1.6 out somewhere
[15:34] <jam> looking forward to a patch :)
[15:36] <sidnei> jam: running 'make installer-all' from bzr.dev would work fine, it will checkout the version specified and build that, it doesn't build the current directory. in fact, i was thinking if all of this should be moved out of the tree and be managed separatedly.
[15:36] <jam> sidnei: potentially, but we still have to update lots of versions since you targeted 1.15 with your original buildout.cfg
[15:36] <sidnei> jam: thats how we do it for the Plone installers, since you usually have to make changes to the scripts that generate an installer after the final release is made.
[15:37] <jam> sidnei: sure. A goal of mine would be to have the change made in the rc1 release, and then *not* have to change it again for the final :)
[15:38] <sidnei> jam: thats a nice goal yeah. so if you build the installer the normal way, just let me know the versions you used (or I could look at the versions in kerguelen myself) and i will update to use those
[15:40] <jam> sidnei: I'll try to submit the change to build_release.py back to bzr.dev as well
[15:40] <sidnei> jam: awesome!
[15:42] <jam> sidnei: right now I'm working with: http://paste.ubuntu.com/217999/
[15:42] <jam> I'll update you if that has any problems
[15:44] <sidnei> jam: thank you
[15:44] <jam> I don't know that bzr-svn 0.6.3-win32-1 is officially in bzr-svn source, I had to do it manually as a workaround for a bug
[15:46] <jam> it was the follow up bug to bug #384813
[15:46] <jam> jelmer had fixed it in a way that broke in a different way
[15:56] <jam> sidnei: the installer is failing right now anyway
[15:56] <jam> We moved a script
[15:56] <jam> and then tried to make it work by updating an env variable
[15:56] <jam> but that variable is different on windows...
[15:56] <jam> PYTHONPATH=.:$PYTHONPATH
[15:56] <jam> versus
[15:56] <jam> PYTHONPATH=.;$PYTHONPATH
[15:56] <jam> (semicolon versus colon)
[15:56] <jam> anyway, I'll need to do something to get it working
[15:56] <jam> I'll let you know
[16:00] <sidnei> jam: ok
[16:01] <jam> sidnei: lp:~jameinel/bzr/1.17-build-updates
[16:01] <jam> wasn't terribly tricky (yet) :)
[17:40] <kenichi> hi, can one "switch" a branch?  it would seem, no...
[17:47] <kenichi> as i understand it, one just needs to create a new branch from the new desired parent.  is that correct?
[17:48] <Tak> you mean "switch" in the git sense, or in the svn sense?
[17:48] <kenichi> bzr has a switch command too, but it's only for COs.
[17:49] <kenichi> i suppose i mean in that sense, which is analogous to the svn sense.
[17:50] <Tak> yeah - it doesn't really make sense to switch unbound branches, because you can push to or pull/merge from anywhere you want
[17:52] <kenichi> that's what i thought, thanks for the confirmation though :)
[18:26] <SamB> okay, what does bundle buggy key off of to notice merge directives?
[18:28] <vila> SamB: Use lp merge proposals instead :D
[18:28] <RenatoSilva> bug 399398, bug 399392
[18:29] <SamB> vila: what's the command for that? ;-)
[18:29] <vila> SamB: bzr lp-open
[18:29] <vila> SamB: and then clicety-click
[18:30]  * SamB supposes this will involve creating a silly branch
[18:30] <vila> SamB: If it's worth merging, it's not silly
[18:31] <SamB> well, it just seems kind of silly since I probably won't use it ever again ...
[18:31] <mgedmin> can I view two closely-related branches at once with bzr vis?
[18:31] <mgedmin> apparently I can, awesome!
[18:31] <vila> SamB: no problem, it will be stacked by default so very small
[18:32] <mgedmin> uh, oh, no I can't, internal error blah blah blah: KeyError: 'svn-v4:866e43f7-fbfc-0310-8f2a-ec88d1da2979:trunk/Pyflakes:17692'
[18:32] <vila> SamB: But, yes, you may want to use a unique name (we tend to prefix with the bug number a lot :)
[18:32] <mgedmin> bummer
[18:32] <vila> mgedmin: sounds like a ghost problem, file a bug, in the mean time, try with qlog too
[18:33] <SamB> vila: there is no bug number
[18:33] <SamB> it's just a rewrite of a 2 line comment
[18:33] <vila> SamB: file one first ;-D
[18:36]  * SamB decides to just use the date
[18:37]  * mgedmin reports https://bugs.launchpad.net/ubuntu/+source/bzr-gtk/+bug/399405
[18:38] <vila> mgedmin: do you really need to make it private ?
[18:38] <vila> mgedmin: you are seriously limiting the number of people who can fix it....
[18:38] <SamB> vila: why did lp-open put me on edge?
[18:38] <mgedmin> it wasn't me, honest! it was apport! I didn't know :)
[18:39] <vila> mgedmin: :)
[18:39]  * mgedmin made it public as soon as ubbotu told him about the privateness thing
[18:39] <vila> SamB: because you can :)
[18:39] <SamB> because I can *what*?
[18:39] <vila> go on edge, can't you ?
[18:39] <SamB> can some people not?
[18:40] <vila> only lp-beta-testers can !
[18:40] <SamB> ... how did I get to be one of those ?
[18:40] <vila> SamB: ok, you lost me here, why did you ask in the first place ? :-D
[18:42] <vila> AIUI, if you're not a beta tester, edge.lp.net should redirect you to lp.net, so you shouldn't even know edge exist
[18:42] <SamB> well, maybe I am
[18:42] <SamB> but I don't know how I became one!
[18:42] <mgedmin> ok, thanks for the moral support, and bye!
[18:42] <vila> SamB: what is you lp ID ?
[18:42] <SamB> naesten
[18:44] <vila> Right, so you're not part https://edge.launchpad.net/~launchpad-beta-testers
[18:44] <vila> but if you click on the link above, where do you end up ?
[18:46] <SamB> https://edge.launchpad.net/~launchpad-beta-testers
[18:46] <SamB> and it says "This site is running pre-release code. Please report all bugs."
[18:47] <vila> Meh
[18:47]  * SamB suspects that vila may have gotten confused about which way the redirection goes
[18:47] <vila> Oh ! Yes, in the little grey bar, gee, I'm so used to it I don't see it anymore
[18:48] <vila> Anyway, may be things have changed...
[18:48] <SamB> where do you end up if you go to https://launchpad.net/~launchpad-beta-testers ?
[18:48] <vila> But I recently discussed lp-open and the edge/lp.net thing with jml (the lp-open author) so you may want to check with him
[18:49] <vila> https://edge.launchpad.net/~launchpad-beta-testers
[18:49] <SamB> ah, see, you get ridirected vanilla->edge
[18:49] <vila> and that's expected
[18:49] <SamB> I don't get redirected at all
[18:49] <vila> That's not expected :)
[18:49] <SamB> why not?
[18:50] <SamB> it doesn't say anything about the other direction on that page!
[18:50] <vila> And if you delete the edge in the url ?
[18:50] <SamB> jml: so ... why doesn't lp-open send you to vanilla?
[18:50] <SamB> vila: I still don't get redirected
[18:50] <SamB> I land on vanilla
[18:51] <SamB> no dark grey bar, no request to report all bugs
[18:51] <vila> jml told me that the redirection was fixed to avoid very bad errors for people pointed to edge... May be that was fixed and the redirection cancelled, in that case jml may have to revisit his heuristic...
[22:15] <lifeless> moin
[22:30] <kfogel> huh, why does bzr merge say "Contents conflict..." for some files and "Text conflict..." for others?
[22:32] <mwhudson> they're different kinds of conflict
[22:32] <mwhudson> though i admit, i never remember what a content conflict is
[22:32] <mwhudson> kfogel: 'bzr help conflicts'
[22:33] <mwhudson> content conflict == conflict in a file bzr doesn't think is text
[22:33] <kfogel> mwhudson: thanks
[23:11] <jml> poolie, we still good for squash tomorrow?
[23:26] <poolie> jml, hi, yes we are, at 5
[23:27] <jml> cool, thanks.
[23:30] <garyvdm> Hi all
[23:31] <poolie> hello gary
[23:46]  * poolie reads the build-updates patch
[23:46] <poolie> jml, did you see https://code.edge.launchpad.net/~jameinel/bzr/1.17-build-updates/+merge/8753
[23:47] <poolie> it wants to merge to 1.17
[23:47] <jml> poolie, no, I didn't.
[23:47] <poolie> just making you aware; you don't have to read it
[23:47] <jml> poolie, ok. thanks.