[00:00] <ali> bug reported, thanks. https://bugs.launchpad.net/bzr/+bug/637644
[00:01] <ovnicraft> hi folks, i branch a repo from lp in my VPS now i want to get it to my laptop i get this error: bzr: ERROR: Unable to connect to 173.230.141.58; [Errno 111] Connection refused
[00:01] <ovnicraft> trying: bzr clone ftp://XXX.XXX.XXX.XXX/home/myuser/openerp/stable/addons
[00:37] <ddaa> ah people...
[00:38] <ddaa> like free online support has to be instant
[00:43] <poolie> hello ddaa
[00:43] <ddaa> hello poolie, wassup?
[00:43] <poolie> mm i was going to answer but he just left
[00:44] <poolie> ah, things are pretty good here
[00:44] <ddaa> so, my bet was "missing username from URL" :-)
[00:44] <poolie> just going to close all my other windows in a bit and look at this Inter2And2Helper bug
[00:44] <poolie> i was going to guess firewalls around the vps
[00:44] <ddaa> oh right, missing username would be a different error
[00:49] <spiv> Good morning.
[00:53] <ddaa> gotta say, ropemacs is da bomb!
[00:54] <ddaa> when inlining a method that calls a function from another module, it adds the needed imports in the modules of the callsites
[01:04] <mwhudson> ah, i never managed to get it to work
[01:05] <ddaa> Mh... I did need some non-trivial .emacs hacking here.
[01:06] <ddaa> Here's what I did: http://pastebin.com/eiEVBJDJ
[01:07] <ddaa> the python-ropemacs-hook is personal preference
[01:09] <ddaa> I'm not sure why did this thing for on-startup loading, maybe on-demand loading was broken for me...
[01:17] <mwhudson> doesn't seem too bad
[01:17] <mwhudson> will have to try again at some point
[01:19] <spiv> poolie: huh, that Inter1And2Helper bug looks shallow, but also a bit depressing:
[01:19] <spiv>             # XXX: not covered by tests, should have a flag to always run
[01:19] <spiv>             # this. -- mbp 20100129
[01:20] <spiv> s/source_repo/source/ looks like the obvious fix.
[01:21] <spiv> Also, in a probably unrelated issue, _get_rich_root_heads_graph looks suspiciously useless.
[01:52] <poolie> hm, thanks spiv
[03:41] <poolie> so how should a --no-confirmations flag get down to the ui
[03:41] <spiv> poolie: via the context? ;)
[03:42] <poolie> hm, maybe :)
[03:42] <spiv> I've put up a patch for https://bugs.edge.launchpad.net/bzr/+bug/636930 btw, including test coverage.
[03:42] <poolie> should this be remembered in the uifactory, or in the context, or should it perhaps be somewhere else
[03:43] <poolie> extreme factoring would suggest there's a separate "user interaction policy" thing that is separate from the implementation of how to interact with the user
[03:43] <poolie> (legend)
[03:45] <poolie> and then that policy object would know whether to ask or not
[03:46] <spiv> Yes, I think that sounds about right.
[03:46] <spiv> I'd want to keep the policy object as simple as possible until more things use it.
[03:47] <spiv> But otherwise I think that sounds like a nice approach.
[03:53] <spiv> Hmm, maybe I should to fix http://bugs.python.org/issue9729 so that the test suite can pass on maverick.
[04:06] <poolie> could be good
[04:06] <poolie> there's another bug very slightly similar to that
[04:06] <poolie> just in bzr
[04:06] <poolie> which is something to do with socket.error being a bit odd
[04:06] <poolie> so not caught properly
[04:06] <poolie> perhaps because it's not a subclass of IOError or OSError
[05:58] <poolie> spiv, teddy bear?
[05:58] <poolie> i'm trying to decide if the user interaction policy layer should be a decorator layer on the uifactory
[05:59] <poolie> in some ways that's an easy way to intervene around all actions
[05:59]  * spiv listens
[06:00]  * spiv sits with arms sticking outwards a little bit, in his best imitation of a teddy bear ;)
[06:00] <poolie> :)
[06:00] <poolie> but it feels a bit wrong
[06:00] <spiv> Yeah, my initial reaction to that is it feels a bit weird.
[06:00] <poolie> if we do it, we could add a GenericDecorator that uses getattr to feed through to the underlying one
[06:00] <poolie> for instance you might like to look at the current state, or reset the state
[06:01] <spiv> So the decorator could intercept e.g. confirm_action and decide to ignore the decorated object and just return True if that was the policy?
[06:03] <spiv> So this is to save the individual uifactories from having to all implement the same "first, check the policy" logic?
[06:04] <poolie> right
[06:04] <rryan> how do you jump back a revision on a checkout?
[06:04] <poolie> and to make it easier to vary the policy
[06:04] <rryan> i can't believe i dont know how to do this
[06:04] <poolie> rryan 'bzr update -r -2'
[06:04] <poolie> for instance to have --confirmation=yes  or --force options
[06:04] <poolie> https://bugs.edge.launchpad.net/bzr/+bug/397315
[06:05] <rryan> facepalm, thanks!
[06:05] <spiv> So here's another use case that may or may not help to think about:
[06:06] <spiv> add the ability to selectively set a policy for just a specific question, e.g. "break_lock=yes/no/confirm"
[06:07] <spiv> I suppose the decorator would have to inspect the args passed to confirm_action (or whatever) to see if it matches the specific question.
[06:09] <spiv> (Hmm, I suppose a different variation is per-location or per-branch UI policy... I guess that's equally messy with the decorator or with every factory explicitly delegating to policy)
[06:23] <poolie> right, so we're going to want it somehow hooked up to the context, from which it can get the config object
[06:23] <poolie> i guess assigning a new object to ui.ui_factory feels like a very heavyweight action
[06:23] <poolie> to set the policy here
[06:25] <spiv> Yeah.
[06:26] <spiv> The decorator approach does sound like less code, which is a big plus.
[06:30] <lucidfox> What's the best way to maintain a changelog file with bzr?
[06:51] <poolie> lucidfox: well, there are two ways
[06:51] <poolie> you can do bzr log --format=gnuchangelog
[06:51] <poolie> or, you can manually commit to it and record those changes
[06:58] <lucidfox> Well, problem is
[06:59] <lucidfox> because of my "commit early, commit often" work style, automated log generation commits spams the log with one-line entries like "fix typo" or "add comments"
[06:59] <lucidfox> and the ChangeLog file is supposed to list *functional" changes, right?
[07:00] <poolie> right, so in that case i'd suggest probably maintaining it by hand, rather than automatically
[07:30] <spiv> Ok, patch submitted to http://bugs.python.org/issue9729.  If upstream likes it I'll propose it for backporting to Python 2.6 in maverick, which will make our test suite a tiny bit happier.
[07:32] <spiv> It's a bit disconcerting fixing bugs in the Python standard library... the test suite doesn't seem anywhere near as comprehensive as I'm used to with bzrlib.
[07:47] <poolie> heh
[07:47] <poolie> feedreader was fun
[07:47] <mneptok> "When the light of life has gone, no change for the meter. Then the king of spivs will come, selling blood by the litre."
[07:47] <poolie> they have a ton of tests but they're all sample data matched against the parsed form
[07:48] <poolie> indeed
[07:49] <poolie> so what do you think for a name? --yes? --jfdi? --no-confirmation?
[07:49] <mneptok> --make-it-so
[07:49] <mneptok> can't go wrong with Picard references
[07:49] <poolie> for bug 397315
[07:50] <poolie> --thats-an-order
[07:51] <mneptok> --crowbar
[07:51] <mneptok> (lock breaking and all)
[07:58] <spiv> --yes sounds ok to me, it reminds me of fsck -y
[08:05] <vila> hi all
[08:05] <mneptok> :( i like --crowbar
[08:07] <vila> poolie: why not a config var to define the ui itself ?
[08:10] <poolie> vila, how do you mean?
[08:10] <poolie> vila, istr that null output from script commands matches anything?
[08:10] <poolie> is that true?
[08:10] <poolie> it's just been confusing me
[08:11] <vila> poolie: a yes_ui
[08:12] <vila> null output matches anything... hmm, doesn't ring a bell, that would be quite a bug
[08:12] <poolie> mm it seems to be true though
[08:13] <poolie> vila, i agree, i think -O'ui=YesUI' should work
[08:13] <vila> oh, wait, if *no* output is specified, then, yes, I think it's defined as meaning: "I don't care about the output", but that's not the same as specifying an output and getting none
[08:13] <poolie> that needs just a little more buildup and it's a somewhat longwinded way to get it
[08:13] <poolie> yes, that's consistent with what i'm seeing, but i think it's a bug
[08:13] <poolie> i recall discussing it
[08:14] <poolie> i think if you don't care, you should say '...'
[08:14] <vila> poolie: but then you have to do it always, yeah may be we discussed that already
[08:15] <poolie> i should say i'm generally really super happy with scripts
[08:15] <vila> I don't know if we have already enough data for that (nor if can define >/dev/null)
[08:15] <poolie> that's why i'm hitting bugs
[08:15] <poolie> :)
[08:15] <vila> hehe
[08:15] <poolie> i think robert has a point they could create a pressure towards excessive blackbox testing
[08:16] <vila> I fully agreed and still agree with that. I consider them a first rough shot to reproduce a bug
[08:16] <vila> from there you drill down and write more precise tests
[08:16] <poolie> i think if you're going to write a blackbox test, you might as well write it this way
[08:16] <poolie> it's clearer and probably no slower
[08:17] <poolie> and when the bugs are shaken out, it should be no less precise
[08:17] <poolie> there's still the question of how we could test the command ui other than by full-stack tests
[08:17] <poolie> (how or whether)
[08:17] <poolie> https://bugs.edge.launchpad.net/bzr/+bug/637830
[08:17] <vila> oh, for blackbox tests yeah, I was thinking more generally
[08:17] <poolie> no point making it _hard_ to write bb tests as a way to make people write unit tests
[08:18] <vila> lol, no, that's not my point :)
[08:22] <poolie> vila, i think https://code.edge.launchpad.net/~mbp/bzr/ui-factory/+merge/34956 is now all ready to land
[08:25] <vila> poolie: didn't I approved it ??? ... looks like it... weird
[08:26] <vila> poolie: done
[08:35] <vila> hmm, that's cleanup day :) I like it, go submitters, go !
[08:38] <vila> poolie: Why bzrlib.ui.testsupport instead of bzrlib.tests.ui (or something, but under tests) ?
[08:45] <bialix> heya GaryvdM
[08:45] <GaryvdM> Hi bialix.
[08:46] <bialix> Gary, I've pushed small fix to lp:bzr-windows-installers branch, please, next time you'll build the installer use it
[08:46] <bialix> GaryvdM: btw, how's your own build host going?
[08:47] <GaryvdM> bialix: I installed a 32 host, so I was not able to build the tbzr 64bit shell ext. So I'm gonig to have to start from scratch
[08:47] <poolie> vila, i actually did originally put it somewhere like that but i think python was getting confused by multiple things called ui
[08:47] <poolie> or at leoast i was :)
[08:47] <poolie> cleanup day?
[08:48] <bialix> GaryvdM: oops :-(
[08:48] <poolie> hi bialix, garyvdm
[08:48] <bialix> heya poolie
[08:48] <GaryvdM> Hi poolie
[08:48] <vila> ueah, I thought about that :) So how about bzrlib.tests.ui_utils ?
[08:48] <GaryvdM> Hi vila
[08:48] <poolie> sure
[08:48] <vila> hey GaryvdM, bialix !
[08:48] <bialix> GaryvdM: which reminds me: why we still provides 32-bit bython version for 64-bit Windows?
[08:49] <bialix> vila: bonjour \o_
[08:49] <poolie> i wouldn't mind having a rule that code outside .tests shouldn't call things inside it
[08:49] <poolie> aside of course from cmd_selftest etc
[08:49] <poolie> and this would advance that
[08:49] <vila> poolie: yup, hence my remark about branchbuilder on the review comment
[08:49] <GaryvdM> I'll probably build the 2.2.1 installer on the ec2 instance, and then have another go after that is done. I'll have to ask jam to revert the pyqt version.
[08:50] <bialix> GaryvdM: how hard it would be to have both 32 and 64 bits hosts?
[08:50] <GaryvdM> bialix: Re 64bit python, -
[08:50] <vila> bialix: at least twice as hard ? :-P
[08:50] <bialix> vila: exactly!
[08:50] <GaryvdM> bialix: Re 64bit python, - I don't really know, I have not really looked at it
[08:51] <bialix> I have plans to get new computer soon, it should be 64-bit
[08:51] <GaryvdM> bialix: My knowledge of the installer build is still small. I'm just following the docs....
[08:52] <bialix> the only one question which bother me is: where to get the compiler for python extensions
[08:52] <vila> bialix: good timing, 10.10 is nearly out :-P
[08:52] <bialix> vila: yep, I'd like to have dual boot machne
[08:52] <bialix> GaryvdM: which compiler are you using?
[08:52] <GaryvdM> bialix: I was using VS C++ express, which is free beer, but not free speech.
[08:53] <vila> bialix: even better: install 10.10 and use vms... way to go... ;) You will need a bit more RAM, but then you'll have both 32bits and 64bits windows available...
[08:53] <bialix> vila: I already have 32-bit Windows XP and pretty happy with it
[08:53] <vila> bialix: you mean you'll get an *additional* computer ?
[08:54] <bialix> yes, new one
[08:54] <vila> nice, have a look at synergy then, 2 computers is a nice setup, 2 mice, 2 keyboards... less nice
[08:55]  * vila looks around and see 5 mice 3 keyboards <cough>
[08:55] <bialix> hehehe
[08:55] <bialix> who's talking
[08:56] <GaryvdM> I use synergy.
[08:56] <vila> well, I use 1 kbd 1 mouse 99% of the time though
[08:56] <vila> but there are cases were one PC needs a keyboard (boot, nasty problems) and 3 mices should just go in the attic :)
[08:57] <vila> mice
[09:01] <poolie> vila i just got a magic touchpad today
[09:02] <poolie> it's pretty sexy
[09:05] <vila> what's a magic touchpad ?
[09:05] <vila> Oh, the apple one ?
[09:05] <poolie> yes
[09:05] <bialix> Can it call spells of 80 level?
[09:06] <poolie> :)
[09:06] <poolie> it can scroll both downwards _and upwards_ which my worn out old mouse couldn't do :)
[09:07] <vila> poolie: yeah, I have a magic mouse (2 in fact :-p) it's a pity I had trouble configuring it properly for osx/vbox/lucid/synergys though :-/
[09:07] <vila> poolie: it works under maverick right /
[09:07] <poolie> spiv do you want to send your approved branches?
[09:07] <poolie> actually it's only on os x for now
[09:08] <vila> poolie: ha.
[09:08] <poolie> i might try it on maverick later but my desktop pc has no bt adapter
[09:08] <poolie> oh nm, you did
[09:17] <poolie> vila i moved the uifactory stuff to tests.testui and it seems happy there
[09:18] <vila> hehe, I thought about that too but didn't want you to say: oh, testui and test_ui are too close ;-p Please land !
[09:19] <poolie> urk
[09:19] <poolie> they kind of are, but i think it's ok
[09:21] <fargiolas> sorry if it is a faq, probably I'm searching wrong keywords and cannot find the answer, how do I checkout a specific revision with bzr?
[09:22] <GaryvdM> fargiolas: There are many ways to skin that cat
[09:22] <GaryvdM> fargiolas: If you don't allready have a branch: bzr branch -r x
[09:23] <GaryvdM> If you allready have a branch: bzr pull . -r x --overwrite
[09:23] <GaryvdM> or
[09:23] <GaryvdM> bzr revert -r x
[09:23] <GaryvdM> or bzr update -r x
[09:23] <fargiolas> don't know if I have a branch, I ran brz branch lp:project-name
[09:24] <fargiolas> I still have to better understand bzr lexicon
[09:24] <GaryvdM> I'm not sure what you want to do exactly. If you can tell me more, I can advise you better
[09:24] <poolie> you do
[09:24] <poolie> fargiolas: you want a copy of the tree as at a particular revision?
[09:24] <fargiolas> GaryvdM: I want to look at a project history looking at each commit changes
[09:25] <GaryvdM> fargiolas: You do have a branch. do cd project-name; ls
[09:25] <fargiolas> if you're familiar with git, I'd like something like git log -p
[09:25] <poolie> 'bzr log -p' :-)
[09:25] <fargiolas> really, cool :D
[09:26] <fargiolas> as I said I'm pretty new to bzr, sorry :-)
[09:26] <GaryvdM> fargiolas: no problem.
[09:27] <vila> fargiolas: if you prefer fancy GUI, try 'bzr qlog' you need the qbzr plugin for that but it's worth it
[09:27] <fargiolas> vila: I'll try it, thanks
[09:35] <poolie> vila did you see spiv's neat "testdoc"? in lp:testdoc
[09:36] <poolie> prints a summary of the contents of a test module
[09:36] <poolie> i like '-f shiny'
[09:36] <vila> poolie: yup, I need to use a dark backgrounf though or most of it is unreadble :)
[09:37] <vila> ga <- fix typos
[09:45] <spiv> poolie: yeah, I'll submit them.  I wanted to make sure the Inter1and2Helper fix got in because 2.2.1 is due quite soon.
[09:46] <RomanMoz> How to launch bzr-gtk or bzr-explorer on Windows systems?
[09:48] <GaryvdM> RomanMoz: If you installed with the windows installer, you should see a short cut in the start menu, and optionally on the desktop
[09:48] <GaryvdM> RomanMoz: How did you install?
[09:49] <GaryvdM> RomanMoz: From the console, you can run "bzr explorer"
[10:05] <hrw> hi
[10:06] <hrw> does someone here used bzr-git plugin?
[10:11] <maxb> hrw: sometimes
[10:12] <hrw> so far all my attempts ends with backtrace or other erros
[10:13] <hrw> bzr: ERROR: Invalid http response for https://github.com/hrw/linaro-armel-cross-toolchain.git/info/refs: Bad status line received
[10:14] <hrw> ok, found bug for it
[10:14] <hrw> bug 581933
[10:15] <jelmer> hrw: Hi
[10:15] <jelmer> hrw: "smart" http repositories aren't supported yet, but git:// should work for github repositories
[10:16] <hrw> 11:15 hrw@home:bzr-import$ bzr git-import git://github.com/hrw/linaro-armel-cross-toolchain.git
[10:16] <hrw> bzr: ERROR: exceptions.AttributeError: 'InterRemoteGitNonGitRepository' object has no attribute 'fetch_refs'
[10:18] <hrw> I prefer to create bzr branch with full git history but doing it by "git format-patch" + playing with bzr version of "git am" is what I do not want to play with
[10:19] <jelmer> hrw: What version of bzr-git is that? Trunk should work.
[10:20] <hrw>  *** 0.5.2-1 0
[10:20] <hrw>         650 http://pl.archive.ubuntu.com/ubuntu/ maverick/universe amd64 Packages
[10:20] <jelmer> hrw: Alternatively, you can have Launchpad do the import for you.
[10:21] <hrw> jelmer: where it is in LP?
[10:22] <jelmer> hrw: The "Import a branch" link on the Code page of a project.
[10:22] <jelmer> hrw: Or if you mean bzr-git itself, lp:bzr-git
[10:23] <hrw> ok, so time to create projects first
[10:24] <poolie> vila wow we're really going to need to see about giving better errors on failure
[10:24] <poolie> the assertionerror is not always super helpful
[10:25] <jelmer> 'morning poolie, vila
[10:25] <poolie> hi there jelmer
[10:26] <vila> poolie: ECONTEXT
[10:27] <vila> jelmer: hey !
[10:29] <mgz> morning all.
[10:30] <vila> mgz: _o/
[10:30] <poolie> vila there's not much explanation of which bit of the script it's unhappy about
[10:30] <poolie> but i just improved it slightly
[10:30] <mgz> I see pqm doesn't have news merge.
[10:31] <vila> poolie: ha, will lineno help ?
[10:31] <poolie> it looks like only a few tweaks are needed to make '' not be a wildcard
[10:31] <poolie> mm, or just giving the command line
[10:31] <spiv> mgz: hmm yeah, I should probably file an RT to get it turned on.  It only helps a bit, but that's still worth something.
[10:31] <poolie> that's not quite unambiguous
[10:31] <poolie> spiv you should
[10:32] <spiv> ok :)
[10:32] <mgz> spiv fixed bug 625574 during the night?
[10:33] <vila> mgz: ha, thanks, I mentioned you to spiv but couldn't find back the mp... :)
[10:35] <vila> spiv, mgz : I let you discuss it :-)
[10:35] <poolie> actually spiv i thought there was one already?
[10:38] <poolie> is this a known bug i sometimes get EBADF inside paramiko running parallel=fork?
[10:38] <mgz> adding a copy method was what Robert mentioned as well, just hadn't got as far as digging into what would need fixing where myself
[10:38] <poolie> probably thread leaks of some kind
[10:40] <hrw> thx
[10:48] <vila> poolie: I dunno it a bug ws filed for it, but yes, it's more apparent now that the leaks have been fixed but it's an old one
[10:49] <vila> poolie: the root cause is that when a client and server communicate via socket the events related to the socket being EOLed do not always occur in the same order
[10:50] <vila> poolie: we catch EBADF on both the client side and the server side, but paramiko use its own private thread, where EBADF, sometimes, occurs
[10:50] <vila> poolie: IIRC it doesn't make the test fail thoug, it's just annoying to have it in the output at all :-/
[10:53] <poolie> ah ok
[10:53] <poolie> vila ah i see the naughty test_conflicts blackbox tests, but not in that directory :)

[10:54] <poolie> hm
[10:54] <poolie> so they are nice and readable
[10:54] <poolie> they are kind of using the command line to do setup, which will tend to be slow
[10:54] <vila> poolie: yeah, I should rewrite them into more precise tests as hinted earlier :)
[10:54] <poolie> and i think was lifeless's objection to adding this facility
[10:55] <poolie> just thinking out loud, not trying to give you a hard time
[10:55] <vila> no no, np
[10:55] <vila> I was in exploratory mode when I wrote them so they fitted the bill: how to create such and such conflicts
[10:56] <poolie> some other things it's teaching me
[10:56] <vila> AFAIK there are the most complex setups we have and spiv and I weren't fully happy about the parametrization either
[10:56] <poolie> we're a bit inconsistent about stdout vs stderr (not totally news)
[10:57] <poolie> and also, a universally respected -q would be good for these tests
[10:57] <poolie> also apparently -1 doesn't work with --parallel
[10:58] <vila> no, at best it could stop one thread (well process)
[10:59] <vila> these tests are a good example of why I didn't care about command output... until the very end, so adding '...' for every line will make them *far* less readable
[10:59] <poolie> actually -q is pretty good
[10:59] <vila> on the other hand, they are not here to stay...
[11:00] <vila> adding it to every bzr invocation in the script ? wfm
[11:00] <poolie> to the ones you don't care about
[11:00] <vila> an alternative would be to add an option to the run_script method to keep the actual behavior
[11:01] <Glenjamin> hi guys, i'm trying to write a plugin to add credentials into gnome keyring in the format that bzr-gtk expects
[11:02] <Glenjamin> but i'm getting lost in the code somewhat - can anyone point me to how to get the credentials stuff from a URL?
[11:03] <vila> Glenjamin: look into bzrlib/transport/__init__.py split_url and unsplit_url
[11:03] <vila> Glenjamin: be aware that the credential stores doesn't provide any facility for storing new credentials
[11:04] <vila> Glenjamin: the rationale is that keyring, ssh-agents are best fitted for that
[11:04] <Glenjamin> the gnome-keyring bit in bzr-gtk uses a hash of attributes to store
[11:04] <Glenjamin> the gnome seahorse program doesn't let you set them
[11:06] <Glenjamin> so i can't see a way to non-programatically set the password
[11:07] <vila> I see, but still :)
[11:07]  * vila searches
[11:08] <poolie> so the good news is that -q does consistently suppress most stuff
[11:09] <poolie> i suspect there are still some where it's not correct
[11:11] <vila> Glenjamin: meh, seahorse let you create passwords or keyrings or ssh keys or pgp keys, what are you trying to create ?
[11:12] <Glenjamin> http://bazaar.launchpad.net/%7Ebzr-gtk/bzr-gtk/trunk/annotate/head%3A/keyring.py#L60
[11:13] <Glenjamin> you can create a named password, but you cant set the attrs dictionary from seahorse - although it will display it for existing passwords
[11:14] <vila> Glenjamin: did you look at oython-gnomekeyring ?
[11:15] <Glenjamin> yes, it has bindings to let me store a password
[11:15] <Glenjamin> i managed it manually
[11:15] <Glenjamin> but now i want to be able to do "bzr gpass some://url" and have it prompt me for username/password, and store it
[11:16] <Glenjamin> i'm struggling to convert the URL argument into the relevant bits however
[11:16] <vila> Glenjamin: haaa, ok, so you don't try to store them in authentication.conf ?
[11:17] <Glenjamin> as ideally i'd like to be able to plug in the same url that any other command would take - in this case it's a custom directory service which maps to bzr+https
[11:17] <Glenjamin> vila: nope, if the password is in the keyring it seems to pick it up
[11:17] <vila> Glenjamin: then look at bzrlib/transport/__init_.py
[11:17] <poolie> that would be a nice feature
[11:18] <Glenjamin> i'm intrigued as to how jelmer manages to get the passwords into keying - as he's the author of this bit of bzr-gtk
[11:18] <vila> Glenjamin: that's the trick, it doesn't, he just uses the ones that are there
[11:18] <vila> s/it/he/ sorry jelmer  :-/
[11:18] <Glenjamin> but they'd have to get there somehow, no?
[11:19] <jelmer> Glenjamin: other apps can add them
[11:19] <poolie> yay, done, and not too tedious to change
[11:19] <poolie> vila https://code.edge.launchpad.net/~mbp/bzr/scripts/+merge/35386 - no rush
[11:19] <vila> Glenjamin: circa line 1354 there is one example
[11:19] <poolie> thanks for the reviews!
[11:19] <vila> poolie: ok
[11:19] <vila> lunch time here, bbl
[11:28] <Glenjamin> annoyingly, parsing the url just gives me bzr+https. which isn't much use. Since this is only for one repo i'm just going to make a more specific command. :(
[11:51] <Glenjamin> i've run into a weird error. I've got an https smart server running, and http redirecting to https. if i try and do a command to bzr+https, i get an error about 401 being an invalid response. If i do bzr+http it redirects to https and prompts me for my password. :s
[11:56] <Glenjamin_> and it only happens with pycurl
[13:09] <knittl> hmm. how do i check if a revision is valid from a revision_dwim object?
[13:13] <vila> Glenjamin: what do you mean by 'only bzr+https' ? Care to paste some code demonstrating that ?
[13:13] <vila> !paste
[13:19] <vila> knittl: hmm, I don't think you can, the dwin processing is about trying various kind of revisions until one succeeds, see bzrlib.revisionspec circa line 325
[13:19] <knittl> vila: well, i want to test if it's 0
[13:19] <knittl> so -r0
[13:20] <knittl> and print revision outputs <revision_dwim 0>
[13:20] <vila> knittl: what's wrong with -rnull: ?
[13:20] <knittl> vila: it crashes
[13:20] <knittl> * <revisionspec_dwim 0>
[13:21] <vila> knittl: what crashes ?
[13:21] <knittl> bzr
[13:21] <vila> ok, doing what ?
[13:21] <knittl> inventory -r0
[13:21] <knittl> inventory -r0 . works (giving filelist)
[13:22] <vila> but it should output nothing right ?
[13:22] <knittl> yes
[13:22] <vila> file a bug, probably pretty shallow
[13:22] <knittl> or a warning 'r0 does not have an inventory' or something like that
[13:22] <knittl> vila: i try to fix it myself
[13:23] <vila> knittl: good, thanks !
[13:23] <knittl> that's why i asked how to check the revision ;)
[13:23] <vila> knittl: but once the bug is filed you can assign to yourself and everybody will know it's a know one if they encounter it
[13:24] <knittl> nobody is as stupid as i am and will try to show the inventory of r0 ^^
[13:24] <knittl> yada yada
[13:25] <vila> I'm surprised it didn't show up in other contexts... and that we don't have a test for that
[13:25] <knittl> if type(dir_ie) is type(None): return;
[13:26] <knittl> in inventory.py entries(self).descend(dir_ie, dir_path)
[13:26] <knittl> seems to fix it
[13:27] <vila> in descend ? yeah, I wsa there too (note that we use the 'if dir_ie is None' idiom instead
[13:27] <knittl> that did not work
[13:27] <knittl> but it was 4am when i tried last
[13:27] <knittl> :D
[13:27] <knittl> oh ok, works too :)
[13:29] <knittl> should this go inside descend or should i check self.root before calling descend?
[13:29] <knittl> checking root.self will be called only once instead of each subdirectory
[13:30] <vila> knittl: I think it's an old code path, http://paste.ubuntu.com/493618/ works
[13:30] <knittl> lol, ok
[13:31] <vila> knittl: well, you did the hard work :) Please send a merge proposal !
[13:32] <knittl> although entries(self) says "this may be faster than iter_entries"
[13:32] <vila> no, it's bogus, it breaks the test suite
[13:33] <knittl> ok, iter_entries works too
[13:33] <vila> knittl: no it's not, it breaks the test suite :)
[13:34] <knittl> what? entries()?
[13:34] <knittl> hu
[13:34] <knittl> what now? :D
[13:35] <vila> hmm, may be the test suite is wrong and you uncovered more than you thought :)
[13:38] <vila> knittl: told you :) File a bug, there are weird things there
[13:38] <knittl> meh, i wanted to patch!!
[13:38] <knittl> !bugs
[13:38] <knittl> !bugs bzr
[13:39] <knittl> stupid bot xD
[13:39] <vila> knittl: Please keep working on the patch ! :) You can then do a merge proposal and with that and the bug, we are sure to track the issue until it's fixed
[13:40] <knittl> well for me both iter_entries() and entries().descend() with the if dir is none works
[13:40] <knittl> i haven't run the testsuite though
[13:41] <vila> knittl: I did run it in a dirty bzr, cleaned now, re-running
[13:41] <vila> knittl: you could run of subset with 'bzr selftest -s bt.test_inventory
[13:43] <knittl> bzr: ERROR: No module named testtools?
[13:43] <vila> knittl: argh, yes, OS/version ?
[13:43] <knittl> maverick
[13:43] <vila> knittl: cool, so just apt-get or synaptic will do
[13:43]  * GaryvdM really really really would like to have shallow branches...
[13:44] <knittl> GaryvdM: hm?
[13:44] <vila> GaryvdM: even if your mirror updated your repo at night ?
[13:44] <knittl> thought bzr would already allow such a thing
[13:44] <knittl> vila: what's the package name?
[13:45] <vila> GaryvdM: or say, every hour (which should be fast enough)
[13:45] <knittl> python-testtools?
[13:45] <vila> knittl: let me check, but if this one exists, sure
[13:45] <vila> yes
[13:46] <vila> knittl: it's a bit old, (0.9.6 has been released) but it shouldn't matter (/me crosses fingers)
[13:46] <GaryvdM> vila: I'm branching a piece of code I don't normally work on
[13:46] <GaryvdM> lp:ubuntu/ubiquity
[13:46] <knittl> vila: http://paste2.org/p/987536
[13:47] <GaryvdM> and my internet line is being very slow, I'm only doing 2kB/s
[13:47] <vila> knittl: ok, now try: 'bzr selftest -s bt.test_inv -s bb.test_inv -s bb.test_non_ascii'
[13:48] <knittl> ok, running
[13:50] <maxb> testtools 0.9.4' is in ~bzr/proposed, ftr, though Martin gz said it may be more buggy than 0.9.2 in some areas
[13:51] <Lor> How does one copy an entire colo workspace and its branches? colo-sync-* requires that there already exists a mirror workspace.
[13:51] <Lor> Is one supposed to do a bzr colo-init followed immediately by a colo-sync-from?
[13:52] <knittl> vila: "ran 729 tests in 164.478s OK"
[13:54] <vila> knittl: sounds good, what's your patch ?
[13:54] <knittl> if self.root is not None: descend(self.root, u'')
[14:01] <Glenjamin> vila: http://paste.ubuntu.com/493632/
[14:01] <vila> knittl: hmm, there are valid cases where self.root is None while the inventory is not, this sounds like bad test coverage :-/
[14:02] <vila> Glenjamin: well, in that case user and password are None indeed
[14:02] <knittl> vila: meh…
[14:02] <knittl> vila: but no
[14:02] <knittl> self.root cannot be none in entries
[14:02] <Glenjamin> this is the bit where i'm trying to get the attributes of the URL to store against the keyring
[14:03] <knittl> because if it is None the .children call will fail
[14:03] <Glenjamin> which would be protocol = https, server = bzr.genesys-solutions.co.uk; I know i can just chop bzr+ off the front - but that kinda feels like cheating
[14:04] <vila> knittl: typed too fast, checking something (in this code path you're right, but the Inventory __init__ allows it to be None)
[14:05] <knittl> i'm only checking in descend
[14:05] <Glenjamin> ideally i want to try and access the url, and then where it would normally go hit the credential stores, just grab those attributes and prompt for a user/password that then gets saved.
[14:05] <Glenjamin> but i dont think the stack is really set up for that.
[14:05] <knittl> how can i set name and email locally for a branch?
[14:05] <knittl> and how can i amend the last commit? (override author information)
[14:06] <knittl> and what's the equivalent of git's format-patch?
[14:06] <vila> Glenjamin: indeed the stack is not setup for that yet (well, only in a rudimentary form which doesn't interact with credential stores IIRC)
[14:07] <vila> knittl: bzr whoami
[14:07] <vila> knittl: bzr uncommit; bzr whomai; bzr commit
[14:07] <knittl> vila: no, whoami is globally
[14:07] <knittl> uncommit will clear my message?
[14:08] <Glenjamin> in my particular case the repository is always the same, so i added a command which can store credentials for that repo. But my plan of making a generic "gpass" command is pretty much kaput
[14:08] <vila> knittl: bzr push lp:~knittl/bzr/bug#-fix-inv-r0 ; bzr lp-open
[14:08] <Glenjamin> whoami accepts a --branch option
[14:08] <GaryvdM> knittl: If you use qcommit, it will uncommit will remember it for you
[14:09] <vila> thanks for the support guys :-D
[14:10] <GaryvdM> knittl: I think to set whoami for a branch, you have to edit .bzr/branch/branch.conf  . I'm not sure if there is a ui for that.
[14:10] <GaryvdM> knittl: Not you can also do bzr commit --author
[14:10] <knittl> GaryvdM: whoami --branch works
[14:10] <GaryvdM> s/Not/Note
[14:11] <GaryvdM> knittl: Oh - learn something everyday :-)
[14:11] <Glenjamin> bzr help whoami revealed its secrets :)
[14:13] <knittl> ok, so i need to push to launchpad?
[14:13] <vila> knittl: that's where you will be able to create a merge proposal and where we will review it
[14:14] <knittl> bzr-pqm is correct 'parent'?
[14:15] <knittl> ugh, now for the reporting part
[14:15] <GaryvdM> knittl: Yes
[14:16] <knittl> https://bugs.edge.launchpad.net/bzr/+bug/379740
[14:16] <vila> knittl: yes, bzr-pqm is our automated gate keeper that ensures that all commits on the mainline pass the whole test suite
[14:16] <knittl> looks like the bug?
[14:17] <vila> knittl: nope, some command but different bug
[14:17] <vila> same ...
[14:17] <knittl> vila: but -r0 will also have no working tree?
[14:17] <vila> knittl: no, it can have an empty working tree
[14:18] <vila> knittl: this bug is about using 'inventory' on treeless branches
[14:18] <knittl> whatever. report a bug *click*
[14:18] <knittl> vila: ah ok. understood!
[14:23] <knittl> done: https://bugs.edge.launchpad.net/bzr/+bug/638034
[16:32] <knittl> what can i do with a file_id? is there a way to `bzr cat` it?
[16:33] <dobey> i'm trying to fix up the test suite in tarmac to use bzr's TestCaseInTempDir, and super() instead of direct calls up to the parent, but now i'm getting a weird error: http://pastebin.ubuntu.com/493658/
[16:33] <dobey> can anyone help me figure it out?
[16:39] <james_w> dobey: it's still going through TestCaseWithMemoryTransport, I didn't think TestCaseInTempDir was a subclass of that
[16:43] <dobey> james_w: nothing in my tarmac tre eis using TestCaseWithMemoryTransport though
[16:44] <jelmer> knittl: it's used internally in bazaar, not really exposed at the UI level. why would you want to ?
[16:45] <knittl> jelmer: showing an inventory -> displaying file contents
[16:45] <dobey> james_w: i guess super() just really hates multiple inheritence :(
[16:47] <mgz> class TestCaseInTempDir(TestCaseWithMemoryTransport):
[16:48] <jelmer> knittl: is there a particular reason for not doing that by file path though?
[16:48] <mgz> inheritance doesn't look wrong to me.
[16:48] <knittl> jelmer: file paths may change?
[16:48] <jelmer> knittl: Not in a particular inventory.
[16:49] <knittl> but between revisions
[16:49] <jelmer> knittl: But you just mentioned you wanted to lookup paths in an inventory
[16:49] <jelmer> s/paths/files?
[16:49] <jelmer> s/paths/files/
[16:50] <knittl> what's wrong with using file_ids?
[16:50] <mgz> dobey: a minimal test case that gets you that stack would be helpful
[16:50] <knittl> (god i hate bazaar)
[16:51] <knittl> when i want to know how to display contents of file ids i want to do that, i don't want to show contents of a normal file or use its filename …
[16:51] <knittl> (sorry, pet peeve)
[16:51] <jelmer> knittl: What are you trying to do exactly?
[16:52] <jelmer> knittl: You seem to be mixing storage-specific things with UI concepts.
[16:52] <knittl> i'm not interested in UI
[16:52] <knittl> but i'd prefer having a command in bzr which does what i want
[16:53] <Glenjamin> then that would be UI, no?
[16:53] <jelmer> knittl: can you give us some more context?
[16:53] <knittl> i'm analysing storage/object models of different dvcss
[16:53] <knittl> and bzr documentation is really awful
[16:54] <knittl> i'm reading pydoc of inventory classes
[16:54] <knittl> so bzr inventory -v --show-ids will give me names and their id
[16:54] <knittl> i guess bazaar tracks history per file (not easy to find either)
[16:54] <knittl> and a file_id identifies a specific file
[16:55] <knittl> so i should be able to show its content by using the file_id
[16:55] <jelmer> you would need both the file id and the revision id
[16:56] <knittl> ok, i don't care if i need revid as well
[16:56] <knittl> how can i display it? you can also link me to a page which describes the command (or tell me the command name)
[16:56] <jelmer> knittl: bzr cat
[16:57] <jelmer> knittl: though you specify the path and the revision
[16:57] <knittl> i don't want to use the path
[16:57] <knittl> i'm specfically asking for file_id
[16:57] <jelmer> knittl: Why not? the path is unambiguous if you also specify the revision
[16:58] <knittl> is there a *single* identifier of a file in a revision?
[16:58] <jelmer> knittl: yes, the path.
[16:58] <knittl> that's path+rev
[16:58] <knittl> that's two things, not a single one
[16:58] <jelmer> knittl: right
[16:58] <Glenjamin> you said "in a revision"
[16:59] <knittl> "of a certain revision of a file" <- better?
[16:59] <jelmer> knittl: a tuple of a revision and a path, or a tuple of a revision and a file id
[16:59] <roryy> i'm trying to find an easy bug to fix; 521452 looks doable, but I can't reproduce it with 2.1.0rc1 (where it was reported) or the tip.  Any hints?  I've tried on Ubuntu 9.10 and using Wine on the same system, but no luck
[17:00] <knittl> bzr cat -r5410 bzrignore-20050311232317-81f7b71efa2db11a
[17:00] <mgz> roryy: it may have been incidentally fixed by poolie
[17:00] <knittl> not working …
[17:00] <jelmer> knittl: Why would you prefer that to "bzr cat -r5410 .bzrignore" ?
[17:00] <mgz> rorry: do you want suggestions for starter bugs?
[17:00] <roryy> mgz: please
[17:00] <knittl> jelmer: because i say so -.-
[17:02] <jelmer> knittl: Anyway, the short answer is that there's no way to cat by file id from the UI.
[17:02] <mgz> rorry: first, if you'd like to test my theory on that you could try checking out a rev before poolie's change, and if the bug exists there but not now, closing that bug as fixed
[17:03] <knittl> jelmer: that sucks …
[17:03] <mgz> rorry: appears to have been merged in r5371, so try r5370
[17:03] <roryy> mgz: cool, thanks.  I'll try that
[17:06] <knittl> jelmer: hg has `hg debugdata` and `hg debugindex`
[17:06] <mgz> rorry: for bugs to work on, see https://bugs.launchpad.net/bzr/+bugs?field.tag=easy - but again some of these may have already been fixed, and some may not actually be easy at all, so feel free to ask questions
[17:07] <roryy> mgz: will do.  and some tagged "easy" definitely don't look that easy :-)
[17:08] <mgz> any luck repoing your first bug on an earlier bzr?
[17:08] <roryy> mgz: no.  still checking that i haven't made a mistake, tho
[17:09] <mgz> it might help to go back even earlier, to a rev from the same time when Gary filed the bug
[17:10] <roryy> i tried that by checking out tag 2.1.0rc1
[17:11] <roryy> sorry, that's for 515569, for which the other is marked as a dupe
[17:11] <mgz> was just about to ask that.
[17:11] <Glenjamin> https://bugs.launchpad.net/bzr/+bug/202374 looks like a nice first bug
[17:17] <mgz> or how about bug 417922
[17:17] <mgz> I know that code so can help you write a test and everything.
[17:21] <roryy> I probably need to be able to reproduce this simple bug before i try anything more ambitious
[17:21] <mgz> ...I'll try and repo here, it may well be you're doing nothing wrong
[17:22] <mgz> ...quick thought though, you are using ./bzr in the directory of the checkout right?
[17:22] <roryy> yeah
[17:26] <mgz> okay, I can't repo with either of those old revs either.
[17:28] <dobey> mgz: http://pastebin.ubuntu.com/493724/
[17:28] <knittl> can i use a hash instead of a revno?
[17:28] <knittl> and how do i find the hash of a revision
[17:28] <dobey> mgz: testing that with trial gives the same error
[17:28] <Glenjamin> knittl: bzr help revisionspec
[17:29] <knittl> ok. and how do i get the revid?
[17:29] <mgz> dobey: okay, yeah, that's you getting screwed by multiple inheritance
[17:30] <Glenjamin> bzr log -v -r<n> i guess
[17:30] <knittl> no, cannot see it
[17:30] <vila> --show-ids
[17:30] <dobey> mgz: so what can i do?
[17:30] <Glenjamin> ^^
[17:30] <Glenjamin> i think bzr qlog shows it
[17:30] <knittl> -v often does nothing
[17:30] <mgz> not create the tempdir in BaseTestCase I'd suggest
[17:30] <knittl> inventory -v: same as inventory
[17:31] <knittl> vila: thax
[17:31] <knittl> * thanks
[17:31] <vila> inventory is an hidden command, it get far less love than the exposed ones :)
[17:31] <knittl> it got a patch from me today …
[17:31] <vila> -v is not used coherently
[17:31] <knittl> that means a lot
[17:32] <knittl> but it's displayed in the help of inventory
[17:32] <Glenjamin> "bzr rocks -v" is the same too
[17:32] <vila> knittl: revids and file-ids are *internal* ids, if you want to manipulate them, you'd better use bzrlib (the library, developer oriented) not bzr (the command-line user-oriented tool)
[17:33] <knittl> i don't want to manipulate them
[17:33] <knittl> just use them
[17:33] <vila> s/manipulate/address|get your hands on/ same thing
[17:34] <knittl> no, quite different
[17:34] <dobey> mgz: and why does the first test pass, but all subsequent tests fail?
[17:34] <vila> bzr do not accept them anywhere from the command-line, except for the revid but it's not the recommanded way
[17:34] <Glenjamin> first passing others failing sounds like not resetting state to me
[17:34] <mgz> because you remove the attribute tempdir, which the bzr class uses for a non-test-specific tempdir
[17:34] <mgz> and you removed it.
[17:35] <vila> Glenjamin: yeah, in this specific case, it's even: blowing up the state ;D
[17:37] <mgz> dobey: just don't do this: tempfile.tempdir = os.getcwd()
[17:37] <mgz> but ideally, if you want to be using TestCaseInTempDir, don't do any of that stuff in the other base test case
[17:38] <dobey> we have to do stuff in the other base test case, because we have to create other files
[17:39] <dobey> if i just make the base test case use TestCaseInTempDir instead, then all the tarmac tests fail
[17:39] <vila> dobey: and inheriting from TestCaseInTempDir ?
[17:39] <dobey> vila: hmm?
[17:40] <vila> dobey: make your base class inherit from TestCaseInTempDir
[17:40] <dobey> i did that
[17:40] <dobey> and everything else failed.
[17:40] <vila> single inheritance
[17:41] <vila> class BaseTestCase(TestCaseInTempDir)
[17:41] <knittl> bzr revision-history is nice
[17:41] <mgz> vila, I think ideally he'd do that, but he's trying to update an existing suite and that means lots of changes
[17:41] <vila> right
[17:42] <dobey> well ideally i wouldn't be here having this discussion, because the code i wrote to change this over, would just work
[17:42] <dobey> it works fine if i don't do super(), and instead just call up directly
[17:42] <mgz> life is never that simple :D
[17:42] <vila> dobey: you can also calls both setUp and tearDown explicitely, but that won't address stepping on other toes^W attributes
[17:43] <mgz> anyway, just don't assign to global state in the tempfile module
[17:43] <mgz> it's dodgy and unneeded
[17:44] <mgz> does that change then get your real tests passing?
[17:45] <mgz> (there's no reason to change to using super for the cases it actually breaks)
[17:45] <dobey> they appear to pass with that change, but i suspect there will be other problems
[17:46] <dobey> and if changing it breaks the bzr test case, then the bzr test case is probably doing it wrong
[17:46] <knittl> why does bzr revision-history not take a revision as its argument?
[17:48] <vila> knittl: because hidden commands are generally written for a specific need and then forgotten
[17:49] <mgz> dobey, no, do you want me to walk you through why that's bust?
[17:49] <knittl> vila: it would make a lot of sense
[17:49] <knittl> like git's rev-list
[17:49] <mgz> the point of TestCaseInTempDir is it creates a tempdir and chdirs into it
[17:49] <knittl> so bzr revision-history -r1000
[17:49] <mgz> super call like that means it gets called first
[17:49] <knittl> show history from r1000 to 0
[17:50] <vila> knittl: seen the see also for revision-history ? That's what 'bzr log' does
[17:50] <mgz> you then set the global tempfile default creation to the cwd, which, remember, is going to get deleted in teardown
[17:51] <knittl> vila: hm?
[17:51] <knittl> 'seen the see'?
[17:51] <knittl> also bzr log shows a lot more
[17:51] <mgz> so the next tempdir that is going to get created is put in a dir that was deleted at the end of the last test, hence error
[17:52] <vila> knittl: bzr help revision-history | grep 'See also'
[17:52] <knittl> i don't understand
[17:54] <vila> knittl: why add -r to revision-history when it's already implemented for log whose job is to display the history of the branch
[17:54] <knittl> vila: log shows a lot more info than revision-history
[17:55] <vila> knittl: indeed, listing the revids only doesn't make a lot of sense that's why the command never get more love
[17:55] <knittl> *sigh*
[17:59] <knittl> vila: listing only revids makes a lot of sense when analysing low level architecture of different systems
[18:00] <rubbs> knittl: the point is, that it wouldn't be a command commonly used. most people wouldn't care about it.
[18:00] <knittl> bzr is not doing well so far: little documentation, everything is hidden and locked away from the user, nobody can properly explain object/history model and different types of objects, etc.
[18:00] <vila> knittl: I understand that and I think we've already had this discussion.
[18:00] <mgz> trying to analyse low level architecture from the command line doesn't make any sense at all. why don't you use a Python repl like any sane person would?
[18:01] <knittl> vila: yes, i say that a lot after i've been asking for something in #bzr :D
[18:01] <knittl> mgz: because the command line tools are (generally) there already
[18:01] <vila> i don't understand
[18:02] <mgz> so, they aren't, and you'd just spent a couple of hours complaining about that.
[18:02] <knittl> mgz: yes.
[18:02] <mgz> why not drop that particular hammer and pick up a more suitable tool?
[18:05] <rubbs> also, I'm interested in why you think documentation isn't there. We specifically picked bzr here for a few reasons: Better windows support, and good end user documentation. The things that 90% of people use are documented and documented well. Are there holes, yes, but no more so than other projects.
[18:05] <roryy> mgz: i've more-or-less given up on bug 515569 after trying it on several revisions: 4933, 4934, 4967, 5019, 5365, 5310, which seem to be when bzrlib/ui/text.py had relevant changes.  I think generating a test case might be harder than it appears.
[18:05] <knittl> rubbs: end user documentation might be good, but i don't read end user documentation
[18:06] <knittl> it also lacks a lot when it comes to history/object model
[18:06] <mgz> rorry, I fear you're probably right there. leave it for the moment, and maybe bug garyvdm or bialix about how they hit it if you see them in the chat
[18:06] <knittl> i have yet to find good architectural documentation
[18:06] <rubbs> knittl: ah, thank you for that clarification.
[18:06] <roryy> mgz: on bug 417922, i see martin pool did do something in 4634.26.1 -- did you have something else in mind?
[18:07] <knittl> rubbs: with 'i don't read end user docs' i mean, that end user documentation is irrelevant here for me. it does not contain the information i need
[18:08] <rubbs> knittl: i understand, I just didn't understand when you said bzr had little documentation. I've found that teaching it to my devs here was much easier because they had a lot of good documentation, but I have no experience with dev documentation, only user documentation.
[18:08] <rubbs> so I can not comment one way or the other on it.
[18:08] <knittl> maybe i've just been missing it the last month
[18:08] <knittl> but nobody could point me to good docs
[18:09] <knittl> also the wiki has links to interesting articles
[18:09] <knittl> just to find those articles are empty
[18:09] <mgz> rorry, ha, another bug poolie fixed?
[18:09] <knittl> or have a single line of content
[18:13] <roryy> mgz: i think so.  i must go now; i'll have a look at the bug Glenjamin suggested.
[18:13] <mgz> okay, sorry for the bumpy start they rorry.
[18:13] <mgz> *there
[19:29] <knittl> how do i go about adding a testcase for bzr inventory -r0?
[19:32] <jam> knittl: I just replied to your email
[19:33] <jam> I don't think we really care up at the 'bzr inventory' level, but it is good to have it at the Inventory level
[19:36] <knittl> jam: ok
[19:36] <knittl> that way it was easiest to explain here
[19:36] <jam> knittl: sure
[19:37] <jam> I'm just saying that you *could* explicitly test 'bzr inventory -r0' in a blackbox test, but I think testing closer to the change is better
[19:38] <knittl> i'm not interested in `bzr inventory` either, it's just the command where i found it to fail
[19:38] <knittl> how can i run only that test?
[19:38] <knittl> because i updated to the previous revision and the tests pass
[19:39] <knittl> `bzr selftest -s bt.test_inv -s bb.test_inv`
[19:48] <jam> knittl: roughly that, you have to make sure to not just create "Inventory()" since the default creates a root
[19:49] <knittl> so overwrite root after that?
[19:49] <knittl> no, root_id is None
[19:50] <knittl> self.assertEqual(true, false) should always fail, right?
[19:50] <knittl> the test is not called :(
[19:50] <knittl> afk for 30 min …
[19:51] <danto> Hi, how could I capture an error status of a bzr update in a bash script?
[20:05] <danto> Hi, how can I capture an error status of a bzr update in a bash script?
[20:07] <GaryvdM> danto: you could check the return code ($?), and/or pipe the stdout to a file.
[20:08] <GaryvdM> danto: Or put the stdout in a var
[20:08] <GaryvdM> var = $(bzr update)
[20:09] <GaryvdM> Oh -  that does no work, not sure why. Sorry
[20:11] <danto> thanks GaryvdM, I'm already trying to pipe the stdout and doing grep -i error but doesn't work; bzr's error seems to broke any pipe
[20:12] <GaryvdM> danto: Oh - let me try it myself.
[20:13] <danto> GaryvdM, sure
[20:14] <GaryvdM> danto: That's odd. bzr update | more does not work, but bzr update | less does.
[20:14] <GaryvdM> danto
[20:15] <danto> GaryvdM, I'm here
[20:15] <GaryvdM> danto: I'm not sure. Maybe someone else may be able to help
[20:15] <GaryvdM> danto: Sorry, I misspress enter after typing your name. :-)
[20:15] <danto> thank you GaryvdM :)
[20:40] <jam> danto: have you checked stderr vs stdout?
[20:41] <jam> bzr update 2>&1 | less
[20:51] <danto> jam not yet, I will try and let you know, thank you :)
[21:43] <sender> I
[21:43] <sender> I'm running python 2.5, but can't compile the extensions runnin 'make' b/c of missing python pyrex. Aptitude install python-pyrex gives me python 2.4.
[21:43] <sender> Should I downgrade python? :S
[21:44] <mgz> try cython instead.
[21:46] <mgz> I'm guessing you're on lenny or an older ubuntu.
[21:47] <sender> mgz: thanks, that's right, lenny
[21:48] <sender> mgz: will cython give me pyrex?
[21:48] <mgz> it's an alternative, yes.
[21:48] <sender> mgz: i installed it, do i need to take extra steps?
[21:49] <sender> mgz:  the make command still fails :/
[21:49] <mgz> you may need to purge pyrex as well.
[21:49] <mgz> seems we try for pyrex first in the setup script for some reason.
[21:50] <sender> mgz: No Pyrex, trying Cython...
[21:50] <sender> mgz: bzrlib/_annotator_pyx.c:4:20: error: Python.h: No such file or directory
[21:50] <sender> mgz:   Cannot build extension "bzrlib._annotator_pyx".
[21:50] <mgz> ah, you need the build deps as well.
[21:50] <sender> mgz: any clues?
[21:51] <sender> mgz: build-essential is installed
[21:51] <chx> I just installed bzr 2.2 from PPA to be able to run bzr resolve --take-other and i got bzr: ERROR: Tree transform is malformed [('duplicate', None, 'new-1', None)]
[21:51] <GaryvdM> sender: sudo apt-get build-dep bzr ?
[21:53] <GaryvdM> Hi mgz
[21:53] <mgz> thanks gary, couldn't remember the incantation.
[21:54] <mgz> chx: bug 430129 look like it?
[21:55] <mgz> or bug 611739 instead?
[21:55] <knittl> how can i run a specific test?
[21:55] <chx> mgz: i dunno. the merge finished.
[21:55] <sender> GaryvdM: thanks
[21:55] <chx> mgz: it's not shelve either.
[21:55] <mgz> file a new bug then.
[21:58] <chx> so this is a bug.
[21:58] <chx> any way to get somethin gmore detailed  to help you guys with?
[21:59] <mgz> yeah, look in bzr log for the traceback and extact command you ran
[21:59] <mgz> and paste that into the bug
[21:59] <knittl> need help with bzr tests please …
[21:59] <mgz> `bzr help selftest`
[22:00] <knittl> …
[22:00] <knittl> how can i run tests for inventory?
[22:00] <knittl> bzr selftest inventory does not work
[22:00] <chx> oh good lord, bzr logs everything?
[22:01] <mgz> it's alright, we don't tell your mom.
[22:01] <mgz> `bzr selftest -s bt.test_inventory`
[22:01] <knittl> mgz: it does not run a test
[22:02] <knittl> self.assertEqual(true, false)
[22:02] <knittl> oh, wait
[22:02] <knittl> no, still. it should fail, but does not
[22:02] <mgz> paste the full diff of your change to the file I might be able to help you write a working test.
[22:02] <mgz> true and false should raise NameError if nothing else, this isn't cpp
[22:03] <knittl> asserting true and false should fail …
[22:03] <mgz> seriously, pastebin, bzr diff.
[22:03] <chx> mgz: https://bugs.launchpad.net/bzr/+bug/638451 enough? need more?
[22:04] <mgz> looks pretty good chx, did you notice anything else odd?
[22:05] <chx> yes. bzr 2.2 is even more awesome than usual :p
[22:05] <knittl> http://paste2.org/p/988130 @mgz
[22:05] <mgz> what did the merge consist of, how did you work around etc.
[22:05] <chx> uuuuuuhuuu
[22:06] <mgz> just ideas, generally the more you can braindump now the less you might have to remember later
[22:06] <mgz> knittl: that's in test_inv
[22:06] <knittl> so?
[22:06] <mgz> so, I guessed the name of the file wrong when I said -s bt.test_inv....ENTORY
[22:07] <chx> mgz: I have a branch (alas, private project on lauchpad) stacked on top of a two months old lp:drupal. There are changes. I took a new lp:drupal , applied those changes, resolving the conflicts etc and then wanted to merge this back
[22:07] <chx> mgz: so it's a bit complicated.
[22:07] <knittl> it's in the inventory.py file
[22:07] <knittl> no, test_inv
[22:07] <mgz> the test is on the path bzrlib.tests.test_inv....
[22:07] <maxb> jelmer: Are there any neat tricks for causing bzr-svn to redo a find_tags_between, after the initial attempt after a 'bzr branch' threw an exception?
[22:07] <mgz> which is what -s wants
[22:08] <mgz> chx: that sounds relevent I'm afraid, so if you could try and explain it in the bug I'm sure it'd help
[22:08] <knittl> selftest -s bzrlib.tests.test_inv?
[22:08] <chx> mgz: can you guys reach private LP repos?
[22:08] <mgz> yeah, or the bt. shortening
[22:08] <mgz> chx: I can't personally, but canonical support people probably can.
[22:09] <knittl> ok, it fails now
[22:09] <knittl> good :)
[22:09] <GaryvdM> knittl: You can check if your test is included in your regex/-s by running bzr selftest xxx --list
[22:09] <mgz> or just -v, yeah.
[22:09] <GaryvdM> ah
[22:09] <knittl> included in my regex?
[22:10] <knittl> ok, test failed. test runs without errors. WIN!
[22:10] <mgz> or your -s - selftest has a few different ways of selecting tests
[22:10] <mgz> a winner is very nearly you.
[22:10] <chx> mgz: okay i included the examiner trunk uri then
[22:10] <knittl> no, it failed and after applying my patch it succeeds
[22:10] <mgz> chx: fantastic, thanks.
[22:11] <GaryvdM> Is there some where (like a faq) that explains why bzr-svn often ends up with ghost revs?
[22:11] <mgz> knittl: right, you've nearly got your fix landed.
[22:11] <mgz> fix done, test done.
[22:11] <mgz> you want to deal with all the annoyance in one day? then...
[22:11] <GaryvdM> I would like to link to such a thing in bug 638422
[22:11] <mgz> knittl: have you signed the canonical contributor agreement?
[22:11] <knittl> no
[22:12] <mgz> have fun: http://www.canonical.com/contributors
[22:12] <knittl> do i have to?
[22:12] <mgz> yup, but it's reasonably non-onerous
[22:14] <mgz> then you'll have nearly seen your fix through from >_< to :D and it'll just want approval and landing
[22:15] <mgz> garyvdm: might be a question for the mailing list.
[22:15] <mgz> some kind of ghost writeup is needed if it doesn't already exist.
[22:15] <GaryvdM> mgz: Ok
[22:50] <sender> Getting: bzr: out of memory on a simple branch from 1 server to an other
 danto: have you checked stderr vs stdout? + <jam> bzr update 2>&1 | less <-- yes, it works thanks again :)
[22:51] <sender> source branch is 40K (as outputted by du -h)
[22:56] <danto> sender, see du -h .bzr
[22:56] <danto> I have 137M of videos in a branch but .bzr is about 1.4G  :S
[22:57] <sender> danto: ok, well it seems that the repo is fine, i just get an out of mem on a branch
[23:04] <lifeless> sender: what bzr versions are you using on the client and server?
[23:05] <sender> lifeless: thanks for the reply
[23:05] <sender> lifeless: Bazaar (bzr) 2.2.0 on the client (target)
[23:06] <sender> lifeless: Bazaar (bzr) 1.13.1 on the server (source)
[23:07] <mgz> sender: try nosmart+ for the server url.
[23:08] <sender> mgz: thanks, running now
[23:08] <sender> mgz: lifeless: i do get "Doing on-the-fly conversion from RepositoryFormatKnitPack1() to RepositoryFormat2a()." Problematic?
[23:09] <mgz> can be, yeah.
[23:09] <lifeless> thats a very memory intensive operation
[23:10] <sender> mgz: lifeless: must admit I kinda got lost with repo formats during updates of bzr over the last 2 years or so
[23:23] <sender> mgz: lifeless: mem 100% and process seems halted
[23:27] <GaryvdM> sender: bzr has tried to reduce the format churn. 2a has been arround for more than a year, and there is a strong commitment to stick with it as the default for a lot longer.
[23:27] <poolie> yup
[23:27] <mgz> okay, sender, in which case
[23:27] <poolie> hi gary, lifeless
[23:27] <mgz> you'll want to branch to a fresh repo, so no format conversion
[23:27] <mgz> then upgrade
[23:27] <sender> GaryvdM: great
[23:27] <GaryvdM> Hi poolie
[23:27] <sender> mgz: ok, can I do that with that old version of bzr, or first install 2.2?
[23:28] <mgz> you can do that as is.
[23:28] <mgz> and later push the upgraded version back to the server if you put a newer version of bzr on there
[23:29] <mgz> so, branch to a new dir not inside a shared repo is step one.
[23:29] <lifeless> hi poolie
[23:34] <sender> mgz: ok, new repo is Standalone tree (format: pack-0.92). I run bzr upgrade?
[23:34] <mgz> yup, which may again run out of memory, but hopefully won't.
[23:35] <mgz> if it does, just stick with the old format locally for the moment.
[23:55] <sender> mgz: out of mem on the upgrade :(
[23:56] <sender> mgz: would it be smart to do a (lightweight) checkout instead of a branch and later unbind? to split up operations..
[23:58] <mgz> well, there's no reason you shouldn't use the old format for the moment locally
[23:58] <lifeless> spiv: does bzr have any double-parameterised tests?
[23:58] <lifeless> spiv: I mean foo(Bar)(Quux)
[23:59] <lifeless> spiv: if so, the __copy__ hack will silently break them.
[23:59] <lifeless> spiv: (including in plugins or launchpad or other subclassers.