[00:01] <igc> moldy: where did the branches come from?
[00:02] <igc> moldy: iiuic, no common ancestor implies they have no history in common
[00:07] <moldy> igc: they come from a converted svn repository
[00:08] <igc> moldy: converted via bzr-svn or bzr-fastimport?
[00:08] <moldy> igc: bzr-svn
[00:09] <igc> moldy: I don't know much about bzr-svn sorry
[00:09] <igc> jelmer: still around today?
[00:09] <moldy> igc: as a last resort, i could manually create another branch off of branch a, apply the differences to branch b, and use that one as the new branch b (i don't desperately need all the history), but i am wondering if there is a better way
[00:09] <igc> moldy: see if jelmer or anyone else has a better idea first
[00:10] <igc> moldy: if not, that sounds ok to me
[00:19] <lifeless> moldy: were the branches in the svn repo created by doing 'cp', or by separate imports?
[00:20] <moldy> lifeless: i have no idea :)
[00:20] <moldy> lifeless: hm, now that i thinj about it, probably by "cp", but i cannot vouch for it :)
[00:21] <lifeless> if they were, I would expect bzr-svn to have joined them
[00:21] <lifeless> uhm, I suggest filing a bug on bzr-svn, if they have common ancestry in svn
[00:22] <moldy> hm, they have common history in svn
[00:23] <moldy> i ran bzr-svn on the whole repository
[00:24] <S11001001> is it kosher to use 2a repo format for all new repos if you only care about 1.17+ support?
[00:24] <moldy> but i also changed the layout a bit, so i joined stuff into the branches that had their own svn modules before, maybe that was the problem
[00:34] <lifeless> S11001001: yes, thats fine.
[00:34] <lifeless> 2a is usable [but not ideal] from 1.16 on
[00:34] <lifeless> S11001001: we will be strongly recommending 2.0 and above everywhere
[00:40] <bob2> probably silly question, but was the 2a upgrade issue fixed before trunk switched?
[01:08] <poolie> igc, hi
[01:08] <igc> hi poolie
[01:08] <poolie> so if putting sphinx onto hardy is hard, um
[01:09] <SamB> dangit, bzr help needs some sort of close-match spell checking when the edit distance is just a few characters between the user entry and what they actually wanted help on ...
[01:09] <poolie> SamB: i don't think bzr-guess does this but it would be an easy extension
[01:09] <SamB> say, "help revision-specs" instead of "help revisionspec"
[01:09] <SamB> poolie: heck, I think this is important enough to be in core!
[01:09] <poolie> igc, did it turn out you can't run it from source
[01:10] <igc> poolie: yet to try
[01:10] <SamB> especially for the non-command topics
[01:10] <SamB> which have rather arbitrary names
[01:10] <igc> poolie: I might get to it today
[01:10] <poolie> i just wondered
[01:10] <igc> polie: need to upgrade to 2a first
[01:10] <poolie> the issues lamont mentions may block it running from source too
[01:10] <poolie> in which case we might
[01:10] <igc> poolie: maybe
[01:10] <poolie> hm, i guess we could ask for a karmic chroot there
[01:11] <igc> poolie: let me try from source first
[01:12] <igc> poolie: karmic may be out before they get to it either way :-(
[01:12] <poolie> igc, from recent mail it looks like karmic may not be LTS
[01:13] <igc> poolie: I thought 10.4 was LTS
[01:13] <poolie> you also get into the problem that slightly exotic server hardware may not be supported by newer kernels
[01:13] <poolie> at least i think i recall that happening in going to hardy
[01:13] <poolie> right but karmic is not 10.4
[01:13] <poolie> it will be 9.10
[01:13] <igc> right
[01:14] <SamB> hmm ... my "bzr log" is silly and only looks in the current branch for revisions even when they're in the same repo, it seems :-(
[01:14] <poolie> so the earliest they'll probably want to upgrade the base os there is may 2010
[01:19] <lamont> poolie: it shouldn't be _hard_ to put sphinx in hardy
[01:20] <lamont> it just needs to not be self-build-depending...
[01:20] <lamont> for a round
[01:20] <poolie> i'm not sure what that means
[01:20] <poolie> is it getting rid of the circular dependency?
[01:20] <fullermd> SamB: Well, if they're not in the current branch, it's tough to get the revno...
[01:21] <SamB> bah!
[01:21] <lamont> poolie: I expect that the reason jinja2 build-depends sphinx is for its own docs?  is it possible to strip the sphinx-needs from jinja enough to build and have it work enough to build sphinx enough to build jinja-with-sphinx to build sphinx-with-full-jinja?
[01:21] <SamB> why can't it just skip that?
[01:21] <fullermd> I think the typical answer to things like that is "because your patch for it hasn't been merged'   :p
[01:21] <poolie> lamont: i expect that's true too, and that it is possible
[01:22] <SamB> or at least give a less scary-looking error that explains what went wrong a bit better ...
[01:22] <poolie> but i haven't looked at the source at all
[01:22] <lamont> poolie: it has to be.. it's just a question of how far back in history one has to go
[01:22] <fullermd> (note that the error you get is a NoSuchRevision, but it doesn't come from looking up the rev, it comes from branch.revision_id_to_dotted_revno()
[01:22] <poolie> oh, because it was not circular at the time it originally went into debian or ubuntu?
[01:22] <SamB> of course, I'm on an old build atm because I was hoping to figure out how to look at the changelog ...
[01:22] <poolie> Samb, i agree, file or dupe a bug
[01:22] <lamont> I admit I haven't been watching, but I expect that the decision on next-LTS won't be made until at least the next UDS, so it'll either be 10.04 or 10.10
[01:24] <igc> hi sidnei
[01:25] <sidnei> igc: oi
[01:25] <igc> sidnei: a questions fro you ...
[01:25] <lifeless> circular deps are sadness
[01:25] <sidnei> igc: shoot
[01:25] <igc> can I use/test the buildout stuff on linux
[01:25] <igc> I'm thinking of getting the image right ...
[01:25] <poolie> lifeless: did you see bialix's comments about 'apport's dependencies are so hard on windows'?
[01:26] <igc> then worrying about how the installer does something with it
[01:26] <lifeless> poolie: yes
[01:26] <lamont> poolie: and the real issue is that it needs a file that isn't even delivered by python in hardy... :(
[01:27] <lifeless> jml: poolie: 12 for lunch?
[01:27] <sidnei> igc: uhm. if i recall correctly, you should be able to run bootstrap.py then bin/buildout on linux
[01:27] <sidnei> igc: but after that it invokes a batch file
[01:27] <poolie> lifeless: sure, where?
[01:28] <lifeless> you had two restaurants you wanted to revisit
[01:28] <lifeless> so lets hunt down the second
[01:28] <poolie> wfm, i think you'll like it
[01:28] <sidnei> igc: that won't give you much other than fetching the dependencies though
[01:28] <igc> sidnei: and do you know how it packages python, qt and pyqt?
[01:29] <sidnei> igc: pyqt needs to be installed manually using the .exe installer into your global python interpreter, and so does a few other dependencies.
[01:29] <igc> sidnei: my xp partition is only a few G so I want to do as much work as I can elsewhere
[01:30] <sidnei> igc: and finally it uses py2exe which is basically black magic to me to pull all the dlls and dependent libs into library.zip
[01:30] <igc> sidnei: ah - so the qt stuff ends up in there?
[01:31] <sidnei> igc: i'm pretty confident that it does. haven't paid close attention.
[01:31] <sidnei> igc: the final step is just packaging it up with innosetup
[01:31] <igc> sidnei: and that's the bit I had planned to improve but ...
[01:31] <igc> it seems that's about 10% of the job
[01:32] <sidnei> igc: correct
[01:32] <igc> vs gathering everything, compiling it, etc.
[01:32] <SamB> jelmer: how come bzr-rebase is so outdated?
[01:33] <igc> sidnei: so adding more plugins basically comes down to editing the buildout.cfg file and build-installer.bat.in file right?
[01:33] <sidnei> igc: yes
[01:35] <igc> sidnei: I don't want to install cygwin. I have make installed. Does that sound ok?
[01:35] <sidnei> igc: yup, that's how i have it here
[01:35] <sidnei> igc: i actually install cygwin but don't use bash. i only put c:\cygwin\bin in %PATH%
[01:37] <sidnei> igc: i believe that a different way of achieving what you wanted would be to not use py2exe, but instead build a custom python install
[01:37] <sidnei> igc: i have code for doing that which we could possibly borrow
[01:38] <sidnei> igc: in fact, i think that would make things a lot easier for everyone including people building plugins
[01:38] <igc> bbiab
[01:39] <sidnei> me too. *wink*
[01:40] <jelmer> SamB: outdated in what sense?
[01:46] <jelmer> SamB_XP: outdated in what sense?
[01:50] <lifeless> poolie: so where should I meet thou?
[01:50] <AfC> lifeless: ping? [personal]
[01:54] <lifeless> spm: procedure change:
[01:55] <lifeless> new pqm branches need:
[01:55] <lifeless>  - bzr-core set as reviewer
[01:55] <lifeless>  - bzr-core subscribed to the branch
[01:55] <lifeless> because *reviewers are not notified*
[01:56] <spm> lifeless: oki; will add to docco. I assume the new branch we did last night needs this asap?
[01:56] <lifeless> done it
[01:56] <spm> awesome, ta.
[01:56] <lifeless> for 2.0 and bzr.dev
[01:56] <lifeless> only cause I'm in bzr-core and can thus do it
[01:56] <spm> :-)
[01:57] <spm> so..... what I'm hearing is you've got the tools to do this yourself; therefore our update needs are minimised? :-P
[01:58]  * spm looks forward in great anticipation to the response to that unsubtle troll
[02:01] <poolie> lifeless: i guess here
[02:02] <lifeless> poolie: ok, I'll drift your way
[02:02] <lifeless> jml: ^
[02:18] <jml> lifeless, I just got off the phone :)
[02:18] <jml> poolie, I'll probably be a little later than 12
[02:22] <poolie> np
[02:58] <moldy> bzr does not work directly over ssh, without a bzr server?
[02:59] <spiv> moldy: you can use sftp
[03:00] <spiv> moldy: but having bzr installed on the remote side and using bzr+ssh will be faster.
[03:00] <moldy> spiv: is it enough to have bzr installed, or do i need to have a server running?
[03:01] <spiv> It simply needs to be installed.
[03:01] <moldy> hm, does not seem to work for me
[03:01] <spiv> (And on PATH)
[03:02] <moldy> which bzr versions are compatible?
[03:02] <spiv> Does "ssh yourhost bzr --version" work?
[03:02] <moldy> yes
[03:02] <spiv> Basically all of them.
[03:02] <spiv> What specifically does "not seem to work" mean?
[03:02] <moldy> well, i have 1.15.1 against 0.11.0
[03:02] <spiv> Oh, ok.
[03:03] <moldy> Server does not understand Bazaar network protocol 3, reconnecting.  (Upgrade the server to avoid this.)
[03:03] <spiv> 0.11 is pretty ancient, probably 1.15.1 won't work with that.
[03:03] <moldy> Server does not understand Bazaar network protocol 2, reconnecting.  (Upgrade the server to avoid this.)
[03:03] <moldy> bzr: ERROR: Generic bzr smart protocol error: Server is not a Bazaar server: Received bad protocol version marker: "error\x01Generic bzr smart protocol error: bad request u'bzr request 2'\
[03:03] <spiv> 0.11 was the very first version to have any sort of "bzr serve" support.
[03:03] <spiv> And it was basically just a glorified sftp, you may as well just use sftp :)
[03:03] <moldy> unfortunately, sftp doesn't work either :)
[03:03] <spiv> Oh?
[03:04] <spiv> That's pretty weird.
[03:04] <spiv> The error message is correct though, that upgrading the bzr on the server would fix your problem.
[03:04] <moldy> i think i will look for a backport of a more recent bzr version to debian etch
[03:05] <spiv> It's very unusual for sftp not to work.  Is that an intentional server configuration I wonder?
[03:06] <spiv> (0.11 is almost 3 years old, btw)
[03:06] <moldy> might be that my local bzr is broken, sftp itself works
[03:06] <spiv> What error do you get?
[03:07] <moldy> ah, it seems to be related to the svn plugin
[03:07] <moldy> i'm not sure why it uses that plugin when trying sftp, though
[03:07] <spiv> Ah.  You can try "bzr --no-plugins ..."
[03:10] <poolie> hello spiv
[03:11] <poolie> igc, did you file a bug or talk to someone about packaging explorer on ubuntu?
[03:11] <poolie> it'd be nice to have it
[03:12] <moldy> spm: thanks for your help. with a recent bzr on the remote side, it works
[03:12] <spiv> moldy: great!
[03:12] <spiv> poolie: good afternoon
[03:13] <poolie> oh so it is
[03:13] <poolie> how's stuff?
[03:13] <spiv> Well, my local repo passed "bzr check" so now it's in the throes of upgrade --2a.
[03:14] <xnox> Can I unshelve a change from branch a/ onto branch b/
[03:14] <xnox> if it was shelved inside branch a/
[03:14] <spiv> xnox: unshelve in a/ and then do "bzr merge --uncommitted ../a/" in b/ is probably simplest.
[03:15] <spiv> Otherwise all I can think of is copying the .bzr/checkout/shelf directory.
[03:16] <poolie> would be nice if you could
[03:17] <spiv> poolie: and I'm wondering what happened to my merge request yesterday, and wondering what the most painless way to resend it is when I'm in the middle of an upgrade...
[03:18] <xnox> spiv: thanks
[03:18] <thumper> whoever came up with merge --uncommitted was a genius
[03:22] <igc> poolie: it was with james_w I believe - I can't recall raising a bug, only emailing
[03:22] <igc> thumper: yes, I use it a lot (and no it wasn't me)
[04:10] <xnox> One more questions =) I've started to use bzr-svn to push to an svn repo. Is there a way to remember push login & password?
[04:47] <poolie> xnox: in auth.conf i think?
[04:48] <xnox> poolie: ok thanks I'll look into that
[05:13] <SamB> ... is there a way to commit in the style of "darcs record", which has a slightly better interface than "bzr shelve" to select what to inclue in the patch?
[05:13] <S11001001> SamB: interactive plugin
[05:14] <SamB> why does searchiong for "bzr darcs commit" (sans quotes) not seem to help me find that?
[05:14] <S11001001> branch http://bazaar.launchpad.net/~asabil/bzr-interactive/trunk as interactive into your plugins directory
[05:14] <SamB> S11001001: I know how to install a plugin
[05:14] <S11001001> just in case :)
[05:14] <SamB> and if I was having trouble finding it now that you told me the name, I would have asked ;-)
[05:16]  * igc lunch
[05:16] <S11001001> take care, because it doesn't work in dumb terminals (like emacs shell)
[05:17] <SamB> that's fine
[05:17] <SamB> I wasn't really going to use it there
[05:17] <SamB> and I don't think darcs really likes that either ;-)
[05:17] <S11001001> I have used it for some time now with darcs just fine
[05:17] <S11001001> also, the hunk finder is more eager in bzr-interactive
[05:18] <S11001001> whereas I think if hunks are separated by 1 line of context in darcs they will be treated separately, this is not so in interactive
[05:18] <SamB> oh, really?
[05:18] <SamB> doesn't the red highlighting confuse emacs?
[05:18] <SamB> S11001001: hmm, I don't remember darcs being that smart
[05:18] <S11001001> what highlighting?
[05:19] <SamB> well, usually of either things that darcs didn't get (non-ascii bytes) or a $ to mark the end of a line with trailing whitespace
[05:19] <SamB> (instead of the actual byte, it prints a red escape sequence)
[05:20] <S11001001> hmm, possibly I've never recorded any such things
[05:20] <SamB> (really annoying when you're writing programs using UTF-8 operators!)
[05:21] <SamB> well, I guess it would at worst look just slightly more horrible and less eyecatching than in a real terminal ;-)
[05:21] <SamB> ... and of course you can always use the Emacs terminal *emulator*
[05:21] <S11001001> icky, I like moving around my shell history like a text buffer
[05:21] <SamB> it can't do that?
[05:21] <SamB> aww :-(
[05:22] <SamB> well, I guess you'd have to switch modes first if it could
[05:22] <SamB> I mean, toggle something
[05:22] <SamB> to change the key bindings
[05:22] <SamB> so that they wouldn't go to the app
[05:25] <spiv> Less than 500 revisions left to upgrade.  Oof.
[05:26]  * SamB wonders how to get emacs to describe a keymap in an intelligable manner -- wishes it had more types :-(
[05:29] <SamB> S11001001: hmm, needs abit of work ...
[05:30] <S11001001> the developer is open to bundles :)
[05:30] <SamB> is it you?
[05:30] <SamB> anyway, was just pondering it ;-)
[05:30] <S11001001> not at all, I merely contributed -F support
[05:31] <SamB> ah
[05:31] <SamB> what's that for?
[05:32] <S11001001> it's supported by built-in commit, just was broken in the wrapper commit that interactive provides
[05:32] <SamB> ah
[05:32] <SamB> is that the one that takes the commit message from a file?
[05:32] <S11001001> I name my log files ++log in honor of arch
[05:33] <SamB> you ... honor ... arch ?!?  :-(
[05:34] <S11001001> I liked arch, kept using it until about the time bazaar-ng 1.5 was released
[05:36] <spiv> S11001001: and you call temp files ,,foo? :)
[05:36] <SamB> I can't like arch
[05:36] <S11001001> just 1 , actually
[05:36] <SamB> it has too many damn pointless concepts!
[05:36] <spiv> Heh.
[05:36] <S11001001> , is garbage that tla promises not to delete
[05:36] <SamB> or, at least, too many damn pointless components in a name
[05:37] <spiv> S11001001: <gollum>my precioussss</gollum>
[05:37] <S11001001> well I don't name my log files ++log instead of ++log.myproject--mainline--0.1.scompall@nocandysw.com--2009-ddi for nothing
[05:41] <SamB> I guess the thing is that I never tried arch until I was already hooked on darcs for the time being
[05:41] <SamB> now I'm not so much hooked on darcs, but still use it as one of my VCS yardsticks
[05:42] <S11001001> I don't think darcs existed back in 2004
[05:43] <SamB> not sure
[05:43] <SamB> I don't remember exactly when #haskell got me hooked
[05:43] <S11001001> hmm, actually it seems to have, but I didn't hear about it until 2007 anyway
[05:44] <SamB> yeah, I was pretty sure it was older than that ;-)
[05:44] <S11001001> it was the community standard for common lisp projects until recently
[05:47] <SamB> darcs?
[05:47] <SamB> or arch?
[05:48] <S11001001> darcs
[05:49] <SamB> did they start using git too or something?
[05:49] <SamB> or git, bzr. & hg too?
[05:49] <SamB> oops, s/./,/
[05:49] <S11001001> git, hg, and svn have all insinuated themselves
[05:49] <SamB> what the?
[05:49] <SamB> why svn?
[05:49] <SamB> ... is it because of google code?
[05:50] <S11001001> bknr.net svn is the new host for Edi Weitz's popular libraries, and clozure (an implementation increasing in popularity) also uses svn for source and binary distribution
[05:50] <SamB> oh, is clozure JVM-based?
[05:50] <S11001001> you're thinking of clojure :)
[05:50] <SamB> oh.
[05:50] <SamB> okay.
[05:51] <SamB> I was just trying to find an excuse for brain-deadedness
[05:51] <SamB> hmm ... how would I use emacs to search for a line that has $(HIDE) on it and isn't immediately preceded by one with $(SHOW) in it?
[05:52] <S11001001> Clozure was once OpenMCL, but MCL went and changed its license, and Clozure added GNU/Linux and Windows support, then x64 and x86
[05:53] <S11001001> surprisingly, porting to platforms other than OS X/PPC was a surefire way to increase popularity
[05:53] <SamB> no duh
[05:54] <SamB> especially with the PPC macs being discontinued
[05:54] <SamB> hmm, so they ... added support for PPC Windows before support for x86 anything?
[05:55] <SamB> was there even an MS Windows for PPC?
[05:55] <S11001001> it's a little weird, they added linux/x64, then windows/x64, then similarly for the x86
[05:56] <S11001001> IIRC, porting to the register-starved x86 was harder than amd64 support
[05:56] <mneptok> SamB: yes
[05:56] <SamB> ... I mean, I know arty in #reactos was working on porting that to PPC, but I forgot about whether there was an MS predecessor ;-)
[05:56] <mneptok> SamB: NT 3.5 was released for PPC. there may have been others.
[05:57] <mneptok> anyhow, such discussions are not really on-topic for #bzr
[05:58] <SamB> mneptok: yeah, but, was anyone asking a bzr question?
[05:58] <SamB> oh, I've got one!
[05:58] <mneptok> SamB: that's not really the point.
[05:58] <SamB> does bzr work on NT 3.5 PPC?
[05:59] <mneptok> SamB: walk into a police station at 3am and do a striptease. when they tell you that it's not a strip club, ask "well, was anyone being arrested?!"
[05:59] <SamB> mneptok: that's a bit different
[05:59] <SamB> I think they'd be arresting you for indecent exposure
[06:00] <mneptok> SamB: so please don't risk the same here.
[06:00] <SamB> or because they didn't want to see your dick
[06:01] <mneptok> SamB: such language *definitely* is not welcome in #bzr
[06:01] <SamB> oh, sorry.
[06:01] <SamB> should I have said "penis"?
[06:02] <mneptok> you should probably keep your mouth shut and be thought a fool, rather than open it and remove all doubt.
[06:04] <SamB> fine, fine, #haskell-blah, here I come ...
[06:04] <SamB> I should be fine there as long as I remember not to talk about Haskell ;-)
[06:24] <spiv> jml: regarding your comment about the puller from about 7:30pm yesterday: bug #424136
[06:24] <jml> oh yes?
[06:25] <spiv> jml: the problem appears to be that the assumption that "Branch.open" succeeds in tha face of rich-root mismatch in stacked-on/stackee is wrong.
[06:25]  * jml tries to parse that for the third time
[06:25] <spiv> jml: stacked-on: just changed from 1.9->2a
[06:26] <spiv> jml: my branch: just changed from 1.9->2a the hosted area, still 1.9 in the mirrored area
[06:27] <spiv> jml: puller: tries Branch.open(mirrored-my-branch), fails because 1.9 can't stack on 2a because 1.9 and 2a have different rich-root support.
[06:27] <spiv> jml: puller therefore gives an error rather than propagating the upgrade that would fix the error.
[06:27] <jml> spiv, I see.
[06:28] <jml> spiv, so we ought to catch those errors and upgrade as if we detected a format change?
[06:28] <spiv> jml: or open in a way that doesn't fail if stacking won't work.
[06:28] <jml> spiv, you're bringing back bad memories
[06:28] <jml> spiv, is that even possible?
[06:28] <spiv> e.g. BzrDir.open(...).open_repository()
[06:28] <jml> hmm
[06:29] <spiv> (because stacking is configured by the branch)
[06:29] <spiv> Or perhaps BzrDir.open(...).open_branch(ignore_fallbacks=True).
[06:29] <jml> perhaps.
[06:29] <spiv> Or potentially just catch the relevant exception.
[06:29] <jml> catching the exception seems like the most robust to me.
[06:30] <spiv> bzrlib.errors.IncompatibleRepositories I believe.
[06:31] <spiv> Well, not making inspecting the format of object A dependent on details like "A's config says stack on B, but B is not compatible" seems more robust to me :)
[06:31] <jml> spiv, yeah, fix bzr
[06:32] <jml> spiv, in the meantime the integration team will integrate :)
[06:32] <spiv> But I can understand that having a separate "check formats" and "now open it for actual use" phases might be awkward in your code.
[06:32] <jml> spiv, we already do something like that... icbw
[06:32] <spiv> bzr is working fine: it's refusing to do Branch.open because it can't be opened.
[06:33]  * jml actually dials up the code
[06:33] <spiv> The problem is your code says "give me a full branch object with fallbacks and everything" when (at this point) it just wants "give me the branch and repository formats"
[06:34] <jml> and what's the bzr API for that?
[06:35] <mwhudson> pretty sure there isn't one, or at least wasn't back when we wrote this
[06:37] <spiv> the_bzrdir.find_branch_format() / RepositoryFormat.find_format(the_bzrdir)
[06:38] <spiv> Or I suppose you could use BranchFormat.find_format(the_bzrdir) for consistency.
[06:49] <mtaylor> lifeless: I find the motu process/system quite frustrating
[06:50] <mtaylor> lifeless: not that you can do anything about it - I'm just complaining :)
[06:55] <jml> spiv, how do they interact with RemoteRepository
[06:55] <jml> et al
[07:00] <spiv> jml: IIRC you'd probably get back a RemoteRepository, still.
[07:01] <spiv> jml: anyway, catching IncompatibleRepositories would work fine for this case, and would probably be the most minimal change.
[07:01] <spiv> I don't really mind what you do so long as it works ;)
[07:08] <igc> spiv: can I request a 30 second review ...
[07:08] <igc> spiv: https://code.edge.launchpad.net/~ian-clatworthy/bzr/422533/+merge/10976
[07:09] <bialix> hello igc
[07:13] <vila> hi all
[07:13] <spiv> igc: heh
[07:14] <spiv> igc: 30 seconds was perhaps pessimistic :)
[07:14] <vila> igc: Can I request a 30 secs test for that one-liner since you obviously found a hole in the coverage ? :)
[07:15] <vila> igc: at least don't close the bug until you had that test...
[07:17] <igc> vila: it's a formatting issue of very low priority - I don't feel a test is necessary sorry
[07:19] <vila> it's untested code for which you had the test almost written since you encounter it, anybody else will spend more time on it
[07:20] <spiv> vila: I don't think a test is worth it.
[07:22] <spiv> It would be a test for the contents an error string; it's unlikely to regress, but adding a test would likely add needless friction if anyone *does* tweak the wording.
[07:24] <spiv> It's a different case I feel to what we test in test_errors (which are generally worthwhile tests).
[07:30] <vila> A test about an invalid property value is not worth it ?
[07:30] <vila> right, I'm still dreaming, let's reboot
[07:30] <vila> hi all, have a good day
[07:30] <igc> vila: w.r.t. bzr-upload, what version should I include in the Windows installer?
[07:30] <igc> vila: and in terms of help for it, all you need to do is ...
[07:31] <igc> add whatever text makes sense to the module docstring
[07:31] <igc> and the plugin guide generator will find it
[07:31] <vila> igc: thanks ! Time to move the README there
[07:31] <igc> vila: the Plugin Guide has one chapter per plugin
[07:32] <igc> the first section for each is the plugin help, then one section per command provided by the plugin
[07:32] <vila> igc: I intend to release 1.0 before bzr-2.0 so I'd like to have 1.0 there
[07:33] <igc> vila: if required, I guess plugins could have extra help topics, e.g. upload-tips
[07:33] <igc> vila: but if they do, I don't currently go looking for them ..,
[07:33] <igc> and I'm not sure how hard or otherwise it would be
[07:33] <vila> module doc string if perfect
[07:34] <vila> at least to address the problem of giving more exposure to the doc :)
[07:34] <igc> so for now, it's in the plugin top-level help or it's in help on a plugin command (or it doesn't make it into the Plugin Guide)
[08:20] <lifeless> mtaylor: tell me more later :)
[08:21] <mtaylor> lifeless: I will :)
[08:22] <jml> Conflict: can't delete lib/lazr because it is not empty.  Not deleting.
[08:22] <jml> 1 conflicts encountered.
[08:22] <jml> rm -rf lib/lazr
[08:22] <jml> bzr resolve lib/lazr
[08:22] <jml> (guess how many times I've had to do that this week!)
[08:25] <lifeless> poolie: I've done the bug status tweak I was mentioning earlier :)
[08:25]  * lifeless waves ciao
[08:25] <jml> lifeless, ciao
[08:43]  * quicksilver tries running bzr pull over GPRS. should be fun.
[08:44]  * quicksilver reflects that bzr+ssh would have been a better choice for a high latency link.
[08:58] <NET||abuse> hey guys, trying to use the upload command here,,
[08:58] <NET||abuse> the documentation is a little vague,
[08:58] <NET||abuse> however i've done bzr help upload.
[08:58] <vila> NET||abuse: did you read the README ?
[08:58] <NET||abuse> now what do i do to point it at a location?
[08:58] <NET||abuse> oh, it's in bzr by default on jaunty it looks like.
[08:58] <NET||abuse> didn't load the plugin files into my ~/.bazzar
[09:01]  * igc dinner
[09:02] <vila> NET||abuse: http://paste.ubuntu.com/264826/
[09:03] <NET||abuse> vila, yeh, i pulled down the source into my projects folder, have a copy of it now and am reading the README
[09:03] <NET||abuse> much appreciated,
[09:03] <NET||abuse> just trying to figure out,
[09:03] <NET||abuse> how do i upload a subdirectory of the main branch?
[09:04] <NET||abuse> i have other configurations for local testing and things in directories here, so i was just going to upload parts
[09:04] <NET||abuse> and i have an extra directory layer that isn't on the live server
[09:04] <vila> NET||abuse: You can't do that yet
[09:05] <NET||abuse> means i should be able to just upload the src/server directory, it holds my www application system and etc directories.
[09:05] <NET||abuse> arrg
[09:05] <vila> You can only upload a full branch working tree
[09:05] <NET||abuse> that's annoying.
[09:05] <NET||abuse> that's pretty much useless then.
[09:05] <NET||abuse> just have to do big scp transfers then
[09:05] <vila> there are various ways to address it, none available yet
[09:05] <NET||abuse> overwriting the whole site
[09:06] <vila> one way is to create a dedicated branch as a fork of your trunk and delete all unwanted stuff there
[09:06] <vila> you can then merge in that reduced branch and upload that
[09:08] <vila> NET||abuse: filing a bug report explaining your use case can only help defining the feature
[09:09] <vila> NET||abuse: or add your case description in bug #212677
[09:12] <NET||abuse> vila, ok, i'll add some description to that bug, bookmarked it.
[09:20] <vila> poolie, lifeless, spiv, igc: data point: I upgradeb ~200 branches in a shared repo over NFS without trouble (~400MB of data processed there)
[09:20] <vila> upgraded even
[09:21] <vila> funnily enough, the first 'bzr info' after that whined about a NFS stale on a FoRmAt file, once and never again :)
[09:29] <poolie> hello vila
[09:29] <poolie> vila, i wonder if they had a flaky network card or switch or something
[09:30] <vila> something weirder than that since the file disappear after several days, NFS is excluded as cause (IMHO)
[10:05] <Lo-lan-do> Hi all
[10:06] <Lo-lan-do> Is anyone in particular linked to Loggerhead?
[10:07] <Lo-lan-do> I guess it's jelmer again :-)
[10:09] <Lo-lan-do> jelmer: Any plans on uploading a recent Loggerhead to Debian?
[10:11] <poolie> Lo-lan-do: or mwh, but he's not a dd
[10:11] <Lo-lan-do> I'm going to need it for a client. I can do the required work (updating the packages and providing backports for Lenny) if needed, I'd just like to know in advance so it doesn't come as a surprise to them when I bill for my time.
[10:12] <Lo-lan-do> This could be said to be an offer for help, but I don't want to step on anyone's toes.
[10:21] <jelmer> Lo-lan-do: Hi!
[10:22] <jelmer> Lo-lan-do: You're more than welcome to help out with the loggerhead packaging
[10:22] <jml> g'night poolie
[10:22] <poolie> night!
[10:22] <jelmer> Lo-lan-do: I was going to update your patch to fix the use of libyui-js, but have been away since debconf9 so haven't had much time for that
[10:25] <poolie> nothing like a good night's sleep :)
[10:25] <jelmer> (-:
[10:29] <james_w> I put the latest loggerhead release in karmic the other day
[10:29] <james_w> it's on bzr.debian.org
[10:33] <jelmer> ah, great
[10:35] <AfC> Has there been a 2.0-rc2 release as yet?
[10:35]  * AfC is scared about the upgrade bug, and 2.0-rc1 is what Gentoo is shipping as ~arch right now
[10:38] <vila> AfC: not yet
[10:53] <luks> why do they ship release candidates?
[10:57] <AfC> luks: they never used to package Bazaar's rc's, but I guess someone was listening to the fact that the lead up to 2.0 is a bit different.
[10:58] <AfC> After all, we want people testing.
[11:01] <luks> yeah, but making ever Gentoo user a tester is probably not such a good idea :)
[11:02] <luks> +y
[11:09] <jelmer> james_w: did you manage to keep the yui stuff in loggerhead working?
[11:10] <james_w> was the patch not complete?
[11:12] <jelmer> james_w: it was complete but last time I attempted to merge a new upstream I had trouble keeping the yui-js patch applied and loggerhead working
[11:15] <james_w> hmm
[11:15] <james_w> there were no conflicts, but I don't understand why
[11:38] <lifeless> igc: something going south on this import :(
[11:38] <lifeless> 10:10:27 64000/133780 commits processed at 263/minute (:64000)
[11:38] <lifeless> 11:19:34 65000/133780 commits processed at 208/minute (:65000)
[11:38] <lifeless> still working on the next 1000
[11:38] <lifeless>  4847 robertc   20   0 6153m 4.8g 1208 D    0 83.8 375:11.54 python
[11:38] <lifeless>    PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
[12:05] <vila> bialix, bialix, where are you :-/
[12:06] <vila> naoki: ping
[12:06] <vila> naoki: You're the one I need ! revno 171 broke the test farm installer build
[12:07] <vila> naoki: revno 171 of tortoisebzr I meant
[12:07] <vila> naoki: http://paste.ubuntu.com/264900/
[12:25] <Lo-lan-do> jelmer: Okay, thanks.  I'll keep in touch however things work out.
[12:54] <jelmer> hmm, bzr-stats seems to think that lifeless, jam, igc and vila are the same person
[12:56] <vila> jelmer: hehe, I mentioned that some weeks ago :)
[12:57] <vila> I don't know when it occured, I wonder if --authors may have tricked it but that should have occurred months ago when we landed bbc
[12:58] <Lo-lan-do> It's all a cabal anyway.
[12:58] <vila> jelmer: Where did you run it ?
[13:02] <jelmer> vila: bzr.dev
[13:03] <vila> wow, just ran it on an upgraded bzr.dev, snappy :)
[13:04] <vila> jelmer: so, that's really weird becase jam and vila survive but steal from each other anyway :D
[13:04] <vila> lifeless and igc disappear completely though, shame
[13:05] <vila> given only those four are involved, I'd say --author tricked bzr-stats, 90% sure :)
[13:08] <jelmer> I'll have a look at it when I find some time
[13:08] <jelmer> Yeah, 2a is teh awesome
[13:09] <jelmer> I know I'm repeating myself, but I'm really looking forward to 2.0 !
[13:09] <vila> :)
[13:18] <jelmer> lifeless: how would a test have multiple statusses?
[13:19] <bialix> vila: are you summon me up?
[13:20] <vila> wow, magic bialix ! How did you know ? 8-)
[13:21] <vila> I wanted to tell you to tell naoki about: http://paste.ubuntu.com/264900/, but I'm sure you already know that, did it, and I've just to pull tbzr again for the fix...
[13:23] <mortehu> I get this on commit: bzr: ERROR: Cannot commit to branch BzrBranch6('file:///me/app/'). It is bound to BzrBranch6('file:///other/app/'), which is bound to file:///other/app/.
[13:23] <vila> mortehu: no more than one level of binding
[13:24] <mortehu> I see.  I'll have to read up on how this works.
[13:24] <bialix> vila: ?
[13:25] <vila> bialix: yes ?
[13:25] <vila> bialix: I wanted to tell you to tell naoki about: http://paste.ubuntu.com/264900/, but I'm sure you already know that, did it, and I've just to pull tbzr again for the fix...
[13:25] <bialix> I don't understand
[13:25] <bialix> https://bugs.launchpad.net/tortoisebzr/
[13:25] <bialix> you need this I guess
[13:26] <vila> k
[13:27] <mortehu> vila: You did notice that the last two paths in the error message were identical?
[13:27] <vila> mortehu: no
[13:27] <vila> that;s weird
[13:30] <bialix> vila: naoki said something about removing some dependencies from tbzr build so he can build with other compiler or sdk
[13:30] <bialix> vila: so maybe there is difference in build environment between him and your slave
[13:30] <vila> I filed a bug
[13:31] <vila> bu g#424303
[13:31] <vila> bug #424303
[13:33] <bialix> ok
[13:35] <vila> mortehu: what is your setup ? Can you issue 'bzr info' in each branch involved /
[13:35] <vila> ?
[13:36] <mortehu> Checkout (format: pack-0.92) Location: branch root
[13:37] <vila> mortehu: don't spam the channel, use a paste service instead and copy the whole output
[13:37] <mortehu> That was the whole output.
[13:38] <vila> >-/
[13:38] <vila> bzr version
[13:38] <mortehu> 1.5
[13:38] <vila> ouch, what os are you using ?
[13:38] <mortehu> It's some other dude's repository (I normally use something else).  He went to sleep. :)
[13:39] <mortehu> Debian
[13:40] <vila> 1.5 is... more than year old... but I'm surprised we can't get more info... try 'bzr info -v' ?
[13:40] <mortehu> I'll just put the files in his working copy and have him commit in the morning.
[13:41] <mortehu> Thanks for your time, by the way.
[13:41] <vila> mmmm, branch6... did we even support that in 1.5 ?
[13:42] <vila> yes we did
[14:51] <mthaddon> not sure if anyone's around who can help here, but I'm testing the upgrade of the bzr PQM instance and running into problems because the existing format is pack-0.92 but current lp:pqm is 1.14-rich-root or 1.9-rich-root - can I convert the current branch to the right format?
[14:54] <jelmer> mthaddon: I think so
[14:54] <jelmer> mthaddon: At least, can't think of any reason why that would be a bad idea
[14:55] <mthaddon> jelmer: so how would I do that? bzr upgrade --1.14-rich-root ?
[14:55] <jelmer> mthaddon: yep
[14:56]  * mthaddon gives it a go
[14:56] <mthaddon> jelmer: cool, worked a treat, thx
[14:59] <jam> jelmer: that would be a rather prolific person, then
[15:00] <jam> jelmer: Unittest doesn't declare that you can't call both addError and addSuccess from the same test
[15:00] <jam> I've seen it getting a successful run, and then an error during cleanup
[15:00] <jam> or even 2 errors :)
[15:00] <jam> morning vila
[15:01] <vila> morning jam
[15:26] <Kobaz> bzr: ERROR: Server sent an unexpected error: ('error', "An attempt to access a url outside the server jail was         made: 'chroot-163675084:///project/base/'.")
[15:26] <Kobaz> i upgraded bzr on my server and now i get that
[15:26] <Kobaz> i'm using bzr+https://
[15:26] <Kobaz> with the bzr-smart thingee
[15:34] <jelmer> did the submit branch for bzr change recently?
[15:34] <jam> Kobaz: known bug, I'll try to track it down for you
[15:34] <jam> jelmer: yes
[15:34] <jam> it is now on LP
[15:35] <Kobaz> jam: yeah i found the bug, it poped up in 1.16
[15:35] <jelmer> Should I just be using lp:bzr?
[15:35] <jam> http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev
[15:35] <jelmer> jam: thanks!
[15:35] <Kobaz> supposidly was fixed in 1.17
[15:35] <Kobaz> but it's still happening in 1.17
[15:35] <Kobaz> https://bugs.launchpad.net/bzr/+bug/400535
[15:35] <Kobaz> looks like a regression
[15:35] <jam> Kobaz: actually 348308
[15:35] <jam> bug 348308
[15:35] <jam> there is a workaround in that bug report
[15:37] <Kobaz> hm
[15:38] <Kobaz> is there anything obviously bad about using the workaround?
[15:38] <Kobaz> or should i stick with what i've been using: 1.13
[15:39] <jam> Kobaz: generally I would recommend newer bzr's for a variety of reasons
[15:39] <jam> I don't think the workaround is that bad
[15:39] <jam> we really need to get something like that into a real fix
[15:40] <Kobaz> what's major between 1.13 and 1.17?
[15:41] <jam> Kobaz: significantly better streaming + stacking support, support for the 2a format repository which is the default in 2.0 (to be released in the next week or two)
[15:41] <jam> I can point you to NEWS if you want details
[15:42] <Kobaz> k sure
[15:42] <Kobaz> hmm
[15:43] <jam> Kobaz: http://doc.bazaar-vcs.org/bzr.dev/en/release-notes/NEWS.html
[15:43] <Kobaz> okay, the workaround appears to be working
[15:44] <rockstar> jam, hi
[15:44] <jam> hey rockstar
[15:44] <rockstar> jam, I seem to have a brokenness in my tarmac trunk that is preventing me from merging a branch.
[15:45] <rockstar> (I originally thought it was a tarmac bug, but bzr reports the same error, hiding the spectacular traceback)
[15:46] <rockstar> jam, pastebin -> https://pastebin.canonical.com/21836/
[15:46] <rockstar> Shoot, that probably should have gone to p.u.c
[15:46] <jam> rockstar: we use p.c.c fairly often here
[15:47]  * rockstar is still getting used to working on Free Software every day.
[15:48] <jam> rockstar: so I *think* that xml 5 is non-rich-root
[15:49] <jam> which means it shouldn't be existing in your rich-root format repo
[15:49] <jam> trying to do 'bzr pull' I'm getting the same error
[15:49] <rockstar> jam, target branch for merge is 2a
[15:50] <rockstar> jam, also, it's possible that your branch is pre-upgrade, so pulling in gets the same error.
[15:50] <jam> that isn't what I see here: https://code.edge.launchpad.net/~rockstar/tarmac/main
[15:50] <rockstar> jam, chk inventories == 2a, right?
[15:50] <jam> rockstar: yes
[15:50] <rockstar> abentley, ^^
[15:50] <jam> ah...
[15:51] <jam> Development repository format
[15:51] <jam> which would be... --dev6 or so
[15:51] <jam> certainly something weird going on...
[15:51] <jam> I wonder if you merged a broken bundle but had it successfully merge
[15:52] <rockstar> How do I find that out?
[15:52] <abentley> rockstar: looking...
[15:52] <jam> rockstar: I'm trying to lftp mirror it to check
[15:52] <rockstar> abentley, for background, it looks like tarmac trunk is broken.
[15:52] <jam> also, there should be 0 xml inventories in chk inventory land
[15:53] <rockstar> jam, I thought I remembered you talking about that at AllHands.
[15:54] <jam> rockstar: downloading now
[15:55] <abentley> jam: if you need an exact mirror, you can use "hitchhiker mirror . $LOCAL_PATH"
[15:56] <jam> abentley: thanks
[15:56] <jam> so... once I did the mirror using lftp, it doesn't seem broken on this end... :(
[15:56] <jam> hm... I wonder about bzr 1.17 on lp versus bzr.dev locally
[15:57] <jam> ah, or cross-format issues
[15:57] <jam> checking a few things
[15:58] <jam> rockstar: so your trunk is in --dev6-rich-root and not --2a
[15:58] <jam> which might be a problm
[15:58] <jam> I'm guessing bzr 1.17 is trying to send the revisions using the generic streaming code
[15:58] <jam> which was broken until recently fixed (prob bzr 1.18 required)
[15:58] <rockstar> Hm, how'd that happen?  I specified --2a on the upgrade.
[15:58] <jam> rockstar: bzr info sftp://bazaar.launchpad.net/~rockstar/tarmac/main/
[15:59] <jam> Repository branch (format: development6-rich-root)
[15:59] <rockstar> :/
[15:59] <jam> so 1.17 is probably trying to cross-format stream by casting to XML inventories, and newer bzr's don't like it
[15:59] <jam> and they shouldn't, because xml5 wasn't actually compatible with --dev6, we just didn't realize it in time
[16:00] <jam> rockstar: can you do a similar 'bzr info' check?
[16:00] <jam> I'm wondering about a problem between the hosted side
[16:00] <jam> and the mirrored side
[16:00] <jam> as I'm pretty sure *my* sftp access gives me the mirror
[16:00] <rockstar> repository: Development repository format - rich roots, group compression and chk inventories
[16:00] <jam> rockstar: that would be --dev6
[16:00] <jam> so my suggesstion...
[16:00] <jam> 'bzr upgrade --2a'
[16:01] <jam> possibly prefixed with
[16:01] <jam> hitchhiker lp:tarmac rmtree backup.bzr
[16:02] <rockstar> Also, if I upgrade my branch locally, and push, the pushed version won't get upgraded, so I need to rmtree .bzr as well, right?
[16:02] <jam> rockstar: when you push, we preserve
[16:03] <jam> I was actually meaning "bzr upgrade --2a lp:tarmac"
[16:03] <jam> so upgrade the remote
[16:03] <jam> but yeah, you could do it the other way as well
[16:03] <jam> bzr push --use-existing, etc.
[16:03] <rockstar> Okay, great.
[16:05] <nealmcb> Sometimes I clone an individual file in a project and then it evolves on its own.  is there any way to track that in bzr?
[16:06] <nealmcb> e.g. so I could go to the clone, ask for a history, and find out that earlier history was in the file it was cloned from?
[16:08] <rockstar> nealmcb, how are you cloning the individual file?
[16:08] <awilkins> nealmcb: No, Bazaar has no model for copying files as yet
[16:08] <nealmcb> rockstar: now I 'clone it' with cp....
[16:08] <nealmcb> awilkins: do you know of others that do?
[16:09] <nealmcb> not a big deal, but I like meta information :)
[16:09] <awilkins> Subversion will let you do it. I don't know about Mercurial or git, but I suspect git might by dint of the way it works internally
[16:09] <luks> svn does :)
[16:10] <nealmcb> thanks
[16:14] <rockstar> jam, I just did an upgrade and a fresh branch, and I still get: Development repository format - rich roots, group compression and chk inventories
[16:14] <michaelforrest> bzr: ERROR: exceptions.AttributeError: 'module' object has no attribute 'ProgressBarStack'
[16:15] <rockstar> jam, this is a new shared repo as well, created with bzr init-repo --2a
[16:15] <vila> jam: hurrah ! #412930 approved :-D
[16:15] <vila> michaelforrest: out-of-date bzr-gtk plugin ?
[16:15] <bialix> vila: oho
[16:15] <jam> rockstar: unfortunately it looks like RepositoryFormat2a doesn't have its own get_format_string
[16:15] <rockstar> jam, but it merges this time...  O_o
[16:16] <jam> so it is re-using the old one
[16:16] <rockstar> jam, is that a bug?
[16:16] <bialix> vila: can you kick the build of tbzr as of revno.171?
[16:16] <jam> sorry, it is get_format_description( that we need
[16:16] <jam> anyway, yeah, I'm reporting it as a bug
[16:16] <jam> should be easy to fix
[16:16] <vila> bialix: kicked
[16:16] <bialix> vila: I think revno.172 introduced that problem with build
[16:17] <vila> ha 171, no, I don't have that level of detail, I thought it wsa a new revision, sorry
[16:17] <michaelforrest> hurray! thanks vila.
[16:18] <vila> I used qlog and searched for the last revision that modified the file and got the revision I indicated
[16:19] <bialix> vila: in revno 172 naoki removed definition of ARGB typedef, I think this is root of problem
[16:19] <vila> bialix: ohh, I see what you mean,
[16:19] <vila> I just run qlog again
[16:20] <vila> bialix: I think you're right but the way the build works today, I can only use the tip of the branch
[16:21] <bialix> well, I'm not sure it will be good idea to commit there just to check this idea
[16:21] <vila> let's wait for naoki input then
[16:23] <bialix> vila: oki
[16:24] <bialix> what is "square dancing"?
[16:24] <bialix> emmajane: ^
[16:24] <vila> bialix: not sure, I think it north american folk dance :)
[16:25] <vila> bialix: not sure, I think it's a north american folk dance :)
[16:25] <emmajane> vila, aye :)
[16:25] <emmajane> bialix, google for "square dance tutorials" :)
[16:26] <vila> emmajane: clicking images for that search gives.... suprising results :)
[16:26] <emmajane> vila, lots of poofy skirts?
[16:28] <vila> not exactly... nothing wrong either, just not really related
[16:28] <emmajane> heh
[16:28] <emmajane> maybe google.ca gives different results.
[16:29] <bialix> not sure about google results.
[16:29] <bialix> it's a dancing on the streets?
[16:30] <abentley> bialix: The "square" means that people are arranged in a square, facing each other.  It doesn't refer to city squares.
[16:30] <emmajane> bialix, did you look at the slides?
[16:30] <vila> argh, grrr, google.fr ! I hate that, how many times should I bang google on the head so that it understand I want google.com and nothing else *by default*. I can go to localized version when *I* want thank you very much
[16:30] <emmajane> bialix, there are actually pictures and links in the slides.
[16:30] <bialix> which slides?
[16:30] <emmajane> bialix, that I dented
[16:30] <emmajane> bialix, I assume that's what you're referring to?
[16:31] <bialix> I'm not sure
[16:31] <awilkins> Bah, being back at work sucks
[16:31] <vila> awilkins: go back to vacations
[16:31] <awilkins> Just got my reminder to do my pointless weekly blog
[16:31] <bialix> ok, nm
[16:32] <awilkins> My manager wants me to set up 15 user profiles that take 10 minutes each and I'll also have to badger people for their passwords to do it. Which is silly.
[16:32] <awilkins> And now i'll stop whining
[16:33]  * emmajane blinks.
[16:38] <jam> awilkins: script it :)
[16:39] <jam> make sure the script includes a poorly written email asking users for their passwords
[16:39] <vila> jam: ROTFL
[16:39] <awilkins> jam: It's a fricking GUI :-(  I have the sources :-)  They are horrible :-(
[16:39] <vila> go directly to jail don't get the 20.000 FF :)
[16:40] <awilkins> Freedom Fries? I'd be one FF if I ate 20,000 Freedom Fries :-p
[16:41] <Lo-lan-do> FusionForge!
[16:41] <vila> awilkins: close but no cigar :) Very close: French Francs, I didn't play monopoly since more than... the time we switch to Euro :)
[16:42] <Lo-lan-do> (Note that FusionForge now supports Bazaar, although the pluginisn't quite complete yet)
[16:42]  * awilkins knew it was French Francs, which is why the joke about Freedom Fries was funny. ish.
[16:42] <Lo-lan-do> (But it will be soonish, see above for my reasons)
[16:42] <jelmer> Lo-lan-do: w00t!
[16:42] <jelmer> Lo-lan-do: Any idea when that sort of stuff would end up on alioth?
[16:43] <Lo-lan-do> jelmer: It's *already* on alioth :-)
[16:43] <vila> awilkins: I thought you were british and that the fries joke was north-american only :)
[16:43] <Lo-lan-do> But the incompleteness shows: no commit stats and no Loggerhead.
[16:44] <awilkins> I am British, but we hear enough of the American news to know the phrase "Cheese-eating Surrender Monkey"
[16:44] <Lo-lan-do> I recently completed/fixed the git plugin for another customer. bzr is next.
[16:45] <vila> Never went to war myself, I can speak about the surrender part, but I like cheese and I'm a monkey :)
[16:45]  * Lo-lan-do fills up the Channel Tunnel
[16:45] <awilkins> There's a bloke who wants to open a British restaurant in Italy... partly to show case our cheeses (which are different, but good too)
[16:46] <vila> british cheese ? I thought you eat only dutch cheese :D
[16:46] <awilkins> vila: Edam is like plastic
[16:46] <Lo-lan-do> If I ever go on a month-long tour of Europe, I'll be sure to taste stuff besides the typical.
[16:46] <vila> let's start some european civil war to start the week-end :D
[16:47] <awilkins> vila: We have some of the greats, like cheddar, stilton, stinking bishop
[16:47] <awilkins> I do like Jarlsberg
[16:47] <Lo-lan-do> English cheese, German wine, Greek beer, and so on.
[16:48] <awilkins> I was shocked to find myself liking _Amercian_ beer
[16:48] <awilkins> But only the local stuff from microbreweries
[16:48] <vila> ..and counting ? I went to visit some friend last week-end and he said: "See, we do some wine and some cheese here", to which I replied: "Funny, nearly every french can say that, whaterver region they are from, they do some local wine and cheese !" :-D
[16:48] <Lo-lan-do> The only beer I managed to like is (kill me now) Kriek.
[16:49] <vila> Lo-lan-do: Belge une fois ?
[16:49] <Lo-lan-do> I am not!
[16:50] <awilkins> I like kriek. And framboise
[16:50] <vila> No offence meant :)
[16:50]  * Lo-lan-do is a garlic-stinking, pastis-drinking, smelly-cheese-eating Frenchman
[16:50] <Lo-lan-do> No moustache though, sorry.  It itches.
[16:57] <tbradshaw> hmmm
[16:57] <tbradshaw> so I'm getting a bzr error on the creation of a fresh local repo?
[16:57] <luks> are you?
[16:58] <tbradshaw> indeed, but it seems so unlikely. :/
[16:58] <tbradshaw> http://pastebin.projects.quakecon.org/67
[16:59] <luks> you are misunderstanding bzr concepts
[16:59] <luks> http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#core-concepts
[17:00] <tbradshaw> what am I misunderstanding?
[17:00] <tbradshaw> is it just that "status" doesn't operate on a repostory?
[17:00] <luks> yes
[17:00] <tbradshaw> which would make sense, of course, but I wouldn't expect an error in that case
[17:00] <luks> why not?
[17:01] <luks> it's like running "cat" on a directory
[17:01] <tbradshaw> because a command with unfulfilled prerequisites shouldn't execute?
[17:01] <luks> it doesn't, and it tells you why
[17:01] <tbradshaw> cat on a directory gives a very reasonable response. :)
[17:02] <tbradshaw> but, anyway, I don't mean to get into a critique on software behavior
[17:02] <tbradshaw> I'm satisfied knowing that bzr doesn't work on repositories and I was just misusing it
[17:02] <luks> bzr st tells you that there is no working tree
[17:02] <luks> so it can't operate
[17:02] <tbradshaw> indeed
[17:03] <tbradshaw> the curiousity was that it gives an error on an nonexistent directory
[17:03] <tbradshaw> which lead me to believe an error during construction, rather than a simple misuse
[17:03] <tbradshaw> but, that's okay, it's still just a user error. :D
[17:03] <luks> that's where it would expect the working tree to be defined
[17:03] <luks> I agree the error message should be nicer
[17:04] <luks> if you want to "work" with bzr, you need to create a branch
[17:04] <tbradshaw> thanks for pointing out the difference, however.
[17:04] <luks> which is done using: bzr init
[17:04] <luks> bzr init-repo just creates a container for revisions
[17:04] <tbradshaw> yes, my intention was to create a local repository, such that I could store some related branches
[17:04] <tbradshaw> I had just been using bzr status liberally as a "sanity check"
[17:04] <luks> yep, then you need bzr init inside that directory
[17:05] <luks> you can run bzr info as a sanity check
[17:05] <tbradshaw> and so when my "sanity check" failed, I ran for help
[17:05] <tbradshaw> ah!
[17:05] <luks> it will tell you what is in the current directory
[17:05] <luks> but status is strictly a working tree operation
[17:05] <tbradshaw> so I should also bzr init?  Or would I go right to branching?
[17:05] <tbradshaw> my hope is to set up my local repository
[17:06] <tbradshaw> such that I have ./trunk
[17:06] <tbradshaw> and ./username/branches
[17:06] <luks> if you already have a branch somewhere, you can use bzr branch
[17:06] <tbradshaw> if that sounds reasonable
[17:06] <luks> I thought you are creating a new project
[17:06] <tbradshaw> no sir, launchpad stuff
[17:06] <tbradshaw> I just haven't done the local repository before
[17:06] <luks> ah, bzr branch is it then
[17:07] <tbradshaw> is it necessary for additional branches to be directly in the local repository?
[17:07] <tbradshaw> or can the local repository have some directory structure of it's own?
[17:08] <tbradshaw> ala, is it okay to mkdir branches, then branch other things from launchpad into that directory?
[17:08] <luks> no, you can have subdirectories there
[17:08] <luks> bzr will look for the repository in all parent directories until it finds one
[17:08] <Lo-lan-do> You can have branches separately.  Read about "lightweight checkouts".
[17:08] <Lo-lan-do> Hm.  Maybe I'm replying to the wrong question.  Ignore me please :-)
[17:09] <tbradshaw> :)
[17:10] <tbradshaw> yeah, that looks exactly how I had hoped it when when done
[17:10] <tbradshaw> thanks for setting me straight luks
[17:10] <tbradshaw> I appreciate the time and instruction. :)
[17:10] <luks> sorry about the first reaction :)
[17:10] <luks> I thought you are a git user trying to use bzr as git :P
[17:10] <luks> withuot reading the documentation
[17:11] <tbradshaw> ha ha!  Nope.  Just a longtime svn user, still trying to wrap my head around distributed version control.  I'm about 85% of the way there. :)
[17:11] <tbradshaw> but I make some poor assumptions sometimes, as you noticed.
[17:12] <tbradshaw> anyway, thanks again. :)
[17:14] <garyvdm> Hi igc
[17:15] <igc> hi
[17:17] <igc> night all
[17:34] <mthaddon> about to update PQM after the current run, if anyone's interested
[17:34] <michaelforrest> is bzr viz supposed to support viewing differences between multiple branches?
[17:35] <michaelforrest> I don't know how collaboration is supposed to work if I can't get a project overview like the github network graph..
[17:35] <garyvdm> michaelforrest: It can do it if the first branch has all the revisions that are in the second branch
[17:35] <michaelforrest> yeah that doesn't really help me
[17:35] <garyvdm> michaelforrest: If not, it fails silently.
[17:35] <michaelforrest> I want to see everything everyone's done
[17:35] <garyvdm> michaelforrest: qlog is much better at that
[17:35] <michaelforrest> so I can see if there's anything worth taking
[17:35] <michaelforrest> what is qlog?
[17:36] <michaelforrest> a plugin?
[17:36] <garyvdm> michaelforrest: simialar to viz, but better, found in qbzr plugin.
[17:36] <michaelforrest> ok
[17:36] <michaelforrest> I'll try that
[17:36] <michaelforrest> thanks
[17:36] <michaelforrest> oh, except... I'm on a Mac!
[17:37] <garyvdm> :-( - I believe that it is possible to run qbzr on a mac, but the installation is difficult.
[17:38] <garyvdm> michaelforrest: specifically the pyqt install.
[17:38] <michaelforrest> I'll see if macports does the job
[17:39] <luks> it seems there is a py25-pyqt4 port
[17:39] <luks> so it should work, it will just take some time
[17:39] <michaelforrest> ah ,thanks luks
[17:39] <garyvdm> Hi luks
[17:40] <luks> hi garyvdm
[17:40] <garyvdm> luks: I'm working on: http://bazaar-vcs.org/qbzr/Blueprint/BrowseRedesign
[17:40] <garyvdm> bbl - Dinner
[17:41] <luks> the mockup looks good
[17:41] <luks> but implementing it will be harder, as it's not exactly standard UI
[18:49] <naoki_> I'm sorry. I fixed tbzr build error.
[18:50] <naoki_> I can't build trunk directly because I don't have VC++2008 Std.
[18:52] <naoki_> I don't know autobuild environment. Is it build another branch?
[18:52] <jam> naoki_: we have buildbot running on a win2k3 machine
[18:53] <jam> http://babune.ladeuil.net:26862/waterfall
[18:53] <vila> naoki_: still no good, but I'm not sure the bot got your last revision
[18:53] <naoki_> For example, (1) push to lp:tortoisebzr/pre-trunk, (2) autobuild (3) push to lp:tortoisebzr
[18:53] <jam> specifically something like: http://babune.ladeuil.net:26862/builders/installer-dev-plugin-dev
[18:53] <vila> jam: it looks like my pqm submission go in a black hole... no feedback mail :-/
[18:54] <jam> vila: are you using the right submit branch?
[18:54] <jam> blackholes suck, though...
[18:54] <jam> it seems to happen often with pqm
[18:54] <vila> I used bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev, should I use http instead ?
[18:55] <vila> trying, will pass around later, dinner time
[19:00] <jam> vila: yes, http
[19:37] <vila> jam: even more obscure, I have mail in bazaar-commits for my submissions !
[19:41] <vila> jam: that is, the mails are accurate, but the revisions are nowhere to be seen, neither in the old trunk nor the new one...
[19:43] <vila> finally, the submission to http came back as failure: nothing to merge
[20:15] <BasicOSX> Great job on 2a, love it!
[20:26] <jam> vila: so... when you submit to pqm it does the merge and commit locally, and the pushes that to lp
[20:26] <jam> it is *possible* for that push to fail
[20:26] <jam> in the past we had problems with redundant packs after autopack, etc
[20:26] <jam> and that tends to kill pqm but give it 'nothing to do'
[20:27] <jam> because its local branch has the revisions merged
[20:27] <jam> thanks BasicOSX
[20:27] <jam> yeah, I just branched 'bzr.dev' from scratch in about 3m30s
[20:27] <jam> down from 12m+ last I used it
[20:27] <BasicOSX> yeah, same here. Amazing speed increase
[20:27] <vila> jam: yup, I came to the same conclusion, the merge went fine, the push failed, no idea how to track that further though without a LOSA :-/
[20:28] <jam> vila: Not possible, as far as I know
[20:28] <jam> mthaddon ,or spm ?
[20:28] <mthaddon> vila: how can I help?
[20:28] <vila> ho !
[20:28] <jam> mthaddon: it would seem that pqm successfully merged something but failed to push it to lp
[20:28] <vila> mthaddon: it seems that pqm can't push to lp
[20:28] <jam> can you check pqm's logs?
[20:29] <mthaddon> jam: sure - when did this (not) happen
[20:29] <jam> vila knows for sure
[20:29] <jam> maybe 3 hours ago
[20:29] <vila> I think I did the submission 2h30 ago
[20:30] <jam> vila: yeah, and the email is sent post push, not post commit
[20:30] <jam> so that also would fit the symptoms
[20:30] <mthaddon> jam, vila: https://pastebin.canonical.com/21854/
[20:30] <jam> mthaddon, vila: looks like a direct bug in pqm
[20:31] <jam> something got a string pointing to a branch, and thought it was getting a Branch object
[20:31] <jam> perhaps aliasing of a variable?
[20:31] <mthaddon> jam: possibly not - https://pastebin.canonical.com/21856/
[20:32] <jam> mthaddon: well, that could be a factor too, but certainly pqm shouldn't be treating a string as a Branch object :)
[20:32] <vila> damn it, can you check the authentication.conf file
[20:32] <jam> the latter may have triggered the former, though
[20:33] <vila> mthaddon: if auth.conf exists in ~/.bazaar and user is not bzr-pqm... that will explain why spm called auth.conf with poetic names
[20:33] <vila> mthaddon, jam : that's in addition to the direct pqm bug of course
[20:35] <mthaddon> https://pastebin.canonical.com/21858/ is from .ssh/config and the public key seems to match https://edge.launchpad.net/~bzr-pqm/+sshkeys
[20:35] <vila> mthaddon: at worse, you should check with spm about auth.conf, my memory of the discussion is that you shouldn't use lp: on pqm only bzr+ssh urls
[20:35] <mthaddon> vila: I tried it again with bzr+ssh urls - got the same
[20:35] <vila> mthaddon: but what appear in ~/.bazaar/authentication.conf ?
[20:35] <mthaddon> although for some reason auth.conf has launchpad-pqm user :(
[20:35] <vila> mthaddon: if you don't specify a user in the url, auth.conf will provide it
[20:36] <vila> here we are....
[20:36] <nxvl_> hi! i was wondering about the "--fixes" option, in the docs it says i can close multiple bugs, but it doesn't say how the parameters need to be passed
[20:36] <mthaddon> was updated 2009-09-04 14:47
[20:36] <vila> so,  the solution is to remove auth.conf
[20:36] <nxvl_> as in space separated, comma separated, a --fixes option for each
[20:36] <vila> but we need to understand how and whem it came back
[20:36] <mthaddon> vila: why would that have been created?
[20:36] <vila> mthaddon: *you* tell me :-D
[20:37] <vila> my 8-ball can't read the logs there :)
[20:37] <mthaddon> vila: which logs?
[20:37] <vila> mthaddon: It was a joke, I have no idea where to look :-/
[20:37] <vila> .bzr.log certainly, but for what command ?
[20:37] <mthaddon> yeah, me neither :(
[20:38] <vila> Some command that use lp: certainly since that is the one that trigger the creation of the [launchpad] section in auth.conf,
[20:38] <mthaddon> vila: should I just remove that file for the moment?
[20:39] <vila> but I don't know precisely which... lp-login ? What did bazaar.conf says ?
[20:39] <vila> mthaddon: yes
[20:39] <mthaddon> vila: oh, hang on a sec...
[20:39] <vila> err
[20:39] <vila> hang on
[20:39] <mthaddon> so I did an upgrade of PQM earlier
[20:39] <vila> what hour ?
[20:39] <mthaddon> let me confirm
[20:39] <vila> in pqm time so we can relate to 'was updated 2009-09-04 14:47'
[20:40] <mthaddon> about three hours ago...
[20:40] <mthaddon> so this is sounding promising - if we just remove this file we should be good
[20:40] <mthaddon> which I've now done
[20:41] <vila> in bzr trunk you should now be able to try: 'bzr missing :push' and it should tell you about 2 missing revisions
[20:42] <mthaddon> I'm not really sure what directory that'd be from, locally - let me see if I can find anything
[20:42] <vila> ,bzr.log should give you some hints
[20:44] <mthaddon> vila: https://pastebin.canonical.com/21859/ <-- gah!
[20:45] <vila> mthaddon: 'bzr info' ?
[20:45]  * vila wonders what escudero maps to...
[20:46] <mthaddon> https://pastebin.canonical.com/21860/
[20:47] <vila> mthaddon: 8-( I'm lost
[20:48] <vila> lifeless, jam: wrong setup on escudero ?
[20:49] <jam> nxvl: --fixes A --fixes B --fixes C I believe
[20:49] <nxvl> jam: thnk you!
[20:50] <vila> nxvl: I confirm, I used it last today (sry missed the question)
[20:50] <jam> vila: pqm shouldn't be pushing to escudero directly
[20:50] <jam> I believe it pushes based on the submit branch
[20:50] <jam> and its internal config
[20:50] <mthaddon> well at least bzr ls bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev is working now
[20:50] <jam> whatever maps http://bazaar.lp.net/... => bzr+ssh://...
[20:50] <nxvl> vila: :D
[20:51] <mthaddon> vila: I see two revnos diff between that dir locally and bzr+ssh://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev - should I just push to there?
[20:52] <jam> mthaddon: sure
[20:52] <vila> mthaddon: that's what I want yes, thanks :)
[20:52] <mthaddon> jam, vila: ok, done
[20:52] <mthaddon> now up to revno 4674
[20:52] <vila> mthaddon: what I hope though, is that you won't have to do it for every submission :)
[20:52] <mthaddon> :)
[20:53] <vila> mthaddon: thanks a ton !
[20:53] <mthaddon> sure - I'll keep my fingers crossed
[20:55] <vila> mthaddon: we should check with spm about that authentication.conf mess, there is a bug waiting to be fixed there :)
[20:57] <vila> may be even some in pqm, no feedback is really bad in these circumstances
[20:57]  * vila EODing SWEing :)
[21:00]  * fullermd SBI NRZ's to vila.
[21:01] <jam> well, I think someone like lifeless gets an email when pqm crashes like this
[21:01] <jam> but it doesn't help the submitter much
[21:01] <jam> until he wakes up and notices :)
[21:21] <kfogel> LarstiQ: https://code.edge.launchpad.net/~kfogel/bzr-hookless-email/byte-limit/+merge/11233  :-)
[21:39] <lifeless> jam: crashes how?
[21:40] <lifeless> jam: also, how to get a memory trace from a running bzr process?
[21:40] <lifeless>  4847 robertc   20   0 6284m 4.8g 1200 D    0 84.1 379:17.46 python
[21:40] <jam> lifeless: pqm was crashing by failing to push to lp:bzr
[21:40] <jam> it seems that ~/.bazaar/auth.conf  got set
[21:40] <jam> and so it was trying to login as someone like spm
[21:40] <jam> in doing so
[21:40] <jam> it failed to send a message to vila about his merge
[21:41] <jam> it would successfully merge, run the tests, commit, push would fail
[21:41] <jam> no email
[21:41] <lifeless>  fixed in pqm trunk
[21:41] <lifeless> I think
[21:41] <jam> also, there was a bug about "parent_branch" being a string
[21:41] <lifeless> theres an RT ticket for deployment alreadyt
[21:41] <jam> when it thought it should be a Branch object
[21:41] <jam> for memory trace
[21:41] <jam> bzr branch lp:~jameinel/+junk/py_memory_dump
[21:41] <jam> setup.py install (needs pyrex)
[21:41] <jam> then
[21:42] <jam> SIQUIT
[21:42] <jam> from memory_dump import scanner
[21:42] <jam> scanner.dump_gc_objects('foo.json')
[21:42] <jam> though right now I'm making decent use of
[21:42] <jam> trace.debug_memory()
[21:42] <jam> which just uses /proc/PID/status
[21:43] <lifeless> this is the netbeans import
[21:43] <lifeless> its now 6:42
[21:43] <lifeless> 11:19:34 65000/133780 commits processed at 208/minute (:65000)
[21:43] <lifeless> was the last output
[21:43] <lifeless> its been thrashing for 19 hours
[21:47] <jam> lifeless: well, IIRC from igc, if you just do 'bzr fast-import foo.fi' the fast-import code caches all texts in memory
[21:47] <jam> there was something about doing a 2-pass system
[21:47] <jam> which allows the code to know what texts will be referenced again
[21:47] <jam> which has been implemented, I believe
[21:47] <lifeless> jam: I think it caches refs to them; its a 129G .fi file:
[21:47] <jam> but igc knows better
[21:47] <jam> lifeless: no, it caches the texts
[21:48] <jam> see igc's recent comments about how fast-import isn't ready to scale to really-big-imports
[21:48] <jam> at least, that is what I understood from various threads
[21:48] <lifeless> hes being doing kernel and openoffice
[21:48] <jam> lifeless: with 2 passes
[21:48] <jam> I would assume
[21:48] <jam> 1 pass generates a map
[21:48] <jam> used in the second pass
[21:48] <lifeless> anyhow, I'm going to get a trace, file a bug, and zerg it :P
[21:54] <RenatoSilva> hey what's this? http://pastie.org/606334
[21:55] <Xavura> It's a URI.
[21:55] <Xavura> :x
[21:59] <RenatoSilva> how to solve that error? is it a bzr bug?
[22:01] <jam> so lifeless on my networking issues
[22:01] <jam> I came back late at night from my slower Linux server, and branched all of bzr.dev in 3.5min
[22:01] <jam> which was great
[22:01] <jam> though my last time on the Windows box was 14min
[22:01] <jam> (both post-pack)
[22:02] <jam> Unfortunately I didn't try again to see if it was time of day, versus windows/linux
[22:02] <jam> I did test right now, and I can get about 1.5MB/s (byte not bit) on my wireless network from a local server
[22:02] <jam> on windows (using rsync)
[22:03] <jam> I wonder if maybe our code that does some cpu processing while reading is causing problems on windows
[22:04] <lifeless> that would show up with the window being full
[22:05] <lifeless> we can tell the os we want it to be bigger
[22:05] <lifeless> uhm
[22:05] <lifeless> rephrase
[22:05] <lifeless> 'it might be paramiko'
[22:05] <lifeless> I suggest trying paramiko on linux, from the same machine
[22:05] <lifeless> [as few variables changed as we can]
[22:06] <fullermd> RenatoSilva: It's some plugin being out of sync with your bzr.
[22:06] <fullermd> RenatoSilva: rebase, maybe?
[22:11] <mthaddon> lifeless: PQM upgrade seems to be busted
[22:11] <mthaddon> for U1 at least
[22:12] <mthaddon> lifeless: https://pastebin.canonical.com/21864/
[22:12] <lifeless> mthaddon: did the new dep get installed?
[22:12] <mthaddon> lifeless: it did, yep
[22:12] <lifeless> oh fnar fnar that looks like a bug
[22:12] <lifeless> gimme a sec I'll check trunk
[22:13] <mthaddon> thx
[22:14] <lifeless> ok just delete the parameter on that line
[22:14] <lifeless> it passed tests. Clearly that line isn't tested :(
[22:15] <mthaddon> lifeless: erm, which parameter on which line?
[22:15] <statik> mthaddon: the same patch I already pasted :)
[22:15] <mthaddon> ah!
[22:17] <lifeless> pushing rev with it in it anyhow
[22:17] <lifeless> statik: mthaddon: sorry about that
[22:17] <statik> no worries
[22:17] <lifeless> gimme a week with nothing else queued, I could really sort pqm out
[22:18] <mthaddon> lifeless: I think we can fit one of those in around about April 2035
[22:18] <lifeless> that soon? :)
[22:19] <mthaddon> yeah, I'm being optimistic
[22:20] <lifeless> jam: ok, dumping that json; whats the easiest tool to use to answer 'where did 6G of ram go' ?
[22:20] <RenatoSilva> fullermd: what's rebase and out of sync with bzr?
[22:21] <jam> lifeless: cat foo.json | sort | uniq | sort [something to sort on the size column] > sorted.json
[22:21] <jam> there is also
[22:21] <jam> memory_dump.loader
[22:22] <jam> om = memory_dump.loader.load('dumpfile.json')
[22:22] <jam> s = om.summarize()
[22:22] <jam> print s
[22:22] <jam> print s.summaries[0]
[22:22] <jam> the introspection stuff could certainly use more work
[22:22] <jam> but it may be a start
[22:23] <jam> I also have a branch of runsnakerun that can load them an compute square maps, etc
[22:23] <jam> but at 6GB, rsr is pretty useless
[22:23] <jam> there are probably enough objects that just loading the dump is going to be a couple G
[22:27] <fullermd> RenatoSilva: Well, it's on your list of plugins.  The erroring function sounds like something I think is in rebase.
[22:27] <RenatoSilva> what's rebase?
[22:27] <fullermd> The plugin.
[22:28] <RenatoSilva> bzr pull -----> not a branch
[22:28] <RenatoSilva> how to solve this
[22:28] <RenatoSilva> I just want to make it work
[22:29] <fullermd> Well, presumably it's installed from a release, so it would need one in sync with your bzr.  I don't really know details; I don't use rebase.
[22:29] <fullermd> (I don't know for sure rebase is what's causing your problem either, but I know I've heard that error before related to plugins, and rebase seems the most likely suspect)
[22:30] <bialix> I've got error in tests in my plugin:   File "bzrlib\commands.pyo", line 212, in get_cmd_object --> BzrCommandError: unknown command "init"
[22:30] <RenatoSilva> I don't use rebase either, I did not even know that thing ever exist
[22:30] <bialix> what I should do?
[22:30] <jam> RenatoSilva: the error is a known bug in bzr's 1.17 win32 installer because it bundled a version of bzr-rebase that caused 'bzr help commands' to fail.
[22:30] <jam> use a different installer
[22:30] <jam> 1.18rc1
[22:30] <jam> etc.
[22:30] <bialix> invoke install_bzr_command_hooks for those tests?
[22:31] <jam> RenatoSilva: note that there are no known real problems with 1.17, just that 'bzr help commands' is unhappy
[22:31] <bialix> dear core devs, can you give me advice?
[22:31] <RenatoSilva> jam: official release is still 1.17? Ok at least I know the cause, I guess I'll wait for the fix in official release or so
[22:31] <jam> RenatoSilva: 'bzr pull ==> not a branch' probably means you don't have a branch... either the source or the target
[22:31] <RenatoSilva> jam: rebase is not a branch
[22:32] <RenatoSilva> btw, I'd run bzr help commands to know how to see/change my user name that go into commits
[22:32] <RenatoSilva> since I won't install RCs, I ask here, how? :)
[22:33] <bialix> lifeless: should I run install_bzr_command_hooks for my tests if I need get_cmd_object to work?
[22:33] <jam> RenatoSilva: bzr help commands --no-plugnis
[22:33] <jam> bzr help commands --no-plugins
[22:33] <jam> bzr whoami
[22:35] <lifeless> bialix: the main one in bzrlib? no
[22:35] <RenatoSilva> yeah, whoami!!!!!
[22:35] <RenatoSilva> jam: thanks!
[22:36] <bialix> lifeless: so why my test failed on get_cmd_object then?
[22:36] <lifeless> bialix: I'm not here today - if jam can't give you a hand perhaps post to the  list?
[22:36] <bialix> ok
[22:36] <bialix> jam: can you give me advice about get_cmd_object?
[22:36] <RenatoSilva> the whoami is stored for each OS user in his profile right?
[22:38] <lifeless> bialix: I would guess though that you've overridden setUp()
[22:38] <lifeless> and not called the base class setUp
[22:38] <lifeless> or something like that
[22:38] <bialix> lifeless: no
[22:39] <jam> RenatoSilva: yes
[22:39] <jam> bialix: I don't know much about it, without having a bit more background of how the test is failing
[22:39] <jam> however, I'm also done for the weekend...
[22:40] <bialix> ok, thanks guys for making bzrlib api harder to use
[22:40] <RenatoSilva> ok tahnks
[22:41] <lifeless> bialix: that makes me sad, that you say that
[22:41] <lifeless> bialix: I'm sorry its giving you trouble; if you mail the list I'll be happy to help figure it out, but I can't today.
[22:41] <bialix> lifeless: I found that you invoke install_hook in the test_commands.py
[22:41] <lifeless> I'm doing breakfast then out finding stuff for my brothers birthday
[22:42] <lifeless> bialix: yes, but thats to test that the hooks work
[22:42] <bialix> it's not the part of TestCase setUp()
[22:42] <lifeless> all normal bzrlib tests have the commands registered by default
[22:42] <bialix> perhaps when I run selftest -s bp.scmproj it won't
[22:44] <lifeless> bialix: the hooks are setup by doing run_bzr_command
[22:45] <bialix> and I'm using run_bzr()
[22:45] <lifeless> bialix: if you don't call run_bzr_catch_errors or run_bzr_catch_user_errors at all, they won't be registered
[22:45] <lifeless> bialix: why?
[22:46] <bialix> because it works for my plugin
[22:47] <lifeless> well, if you want to call it directly, yes then you will need to install the hooks manually.
[22:47] <bialix> yep, explicit call to install_hook helps
[22:47] <bialix> thanks
[22:47] <lifeless> calling it directly will mean you don't get error formatting
[22:47] <lifeless> its better to call one of the run_bzr_catch variants
[22:49] <bialix> lifeless: no, I need only run_bzr()
[22:50] <lifeless> bialix: why?
[22:51] <bialix> because I run bzr commands as in-process
[22:51] <lifeless> in the test suite or your ui?
[22:52] <bialix> in my backend
[22:53] <lifeless> sounds like you have an implementation of run_bzr_catch_user_errors
[22:53] <lifeless> can you not just use it directly?
[22:54] <bialix> lifeless: you said you're busy ;-) I'm just want to release my plugin and make its test suite pass again after 7 months of not running it
[22:55] <bialix> even if it ugly inside
[22:55] <lifeless> kk
[22:56] <bialix> it working in the end
[22:59] <bialix> all tests passed, everybody happy
[22:59] <RenatoSilva> How to delete the latest revision from Launchpad branch?
[23:01] <RenatoSilva> Anything better than branch+uncommit+revert+delete+push?
[23:01] <bialix> uncommit lp:xxx ?
[23:02] <RenatoSilva> bialix: it will uncommit directly in the lp copy?
[23:02] <bialix> it should
[23:03] <RenatoSilva> cool, but I won't get uncommited stuff when I branch it, or will I?
[23:03] <bialix> but I'm not sure what is lp copy for you
[23:03] <bialix> no, you don't get
[23:04] <RenatoSilva> launchpad's copy of the branch, not local copy
[23:04] <bialix> I'd rather to not use term "copy"
[23:05] <RenatoSilva> why
[23:06] <bialix> because they are different branches
[23:06] <bialix> you're working with dvcs in the end
[23:08] <bialix> RenatoSilva: those branches like twins: they seems similar but have different wives
[23:16] <RenatoSilva> bialix: ok got it, but with copy I meant same revisions, non-diverged
[23:17] <bialix> is the wall of white house still white when you to trun round the corner?