[00:02] <jelmer> spiv: around?
[00:07] <spiv> jelmer: starting to be :)
[00:25] <jelmer> spiv: Have you ever seen anything like this: http://pastebin.com/t0te7wCQ ?
[00:35] <spiv> jelmer: yes, I think it's due to something (e.g. a thread) trying to mutter after the TestCase has torn down the logging/trace setup.
[00:35] <jelmer> spiv: ahh!
[00:36] <jelmer> spiv: Thanks, that also explains why the number of tests that failed in this way varied
[00:36] <spiv> You're welcome :)
[00:45] <Chaorain> I recently heard about Bazaar and have a question. I heard that it will allow me to make a personal branch of a project. For example, I want to start writing a major update for Blender but I don't have write access to the svn server, can I make a branch that only I can write to? I currently have a local linux server that manages a private svn server for me.
[00:46] <jelmer> Chaorain, yes
[00:46] <Chaorain> ok cool. I saw how to install it but how would I go about doing what I want?
[00:47] <Chaorain> here is what I found, http://ubuntuforums.org/showthread.php?t=916132
[00:47] <Chaorain> oh nvm just saw "bzr init
[00:48] <Chaorain> thanks for your help
[00:48] <jelmer> spiv: Any idea how to figure out what code is doing that muttering?
[00:50] <spiv> jelmer: hmm, not off the top of my head :/
[00:50] <spiv> jelmer: instrument mutter to emit a traceback to stderr on ValueError, perhaps?
[01:18] <Stavros> hello
[01:18] <Stavros> can anyone tell me why bzr does a light checkout when i cp -R my repo?
[01:21] <spiv> Stavros: I think I'm missing some context.  You mean you run a bzr command after cp -R'ing your repo, and you get a lightweight checkout when you don't expect one?
[01:22] <Stavros> i'm doing cp -R repo/ repo2/; bzr info; and i see "lightweight checkout"
[01:22] <Stavros> shouldn't that be a full branch?
[01:22] <Stavros> i mean, how much fuller can it get?
[01:23] <spiv> Well, what does 'bzr info' in the original repo/ report?
[01:23] <Stavros> also lightweight checkout
[01:23] <Stavros> what the hell?
[01:23] <Stavros> how can that be lightweight? i can commit fine locally
[01:24] <Stavros> checkout of branch: .bzr/branches/trunk
[01:24] <Stavros> i have no idea what's going on :/
[01:24] <spiv> Are you using the bzr-colo plugin, perhaps?
[01:24] <Stavros> ah, i am
[01:24] <Stavros> is there some way i can remove it?
[01:24] <spiv> This would just be an artefact of how it works, I think.
[01:24] <Stavros> and convert to a full checkout?
[01:26] <spiv> You can probably use 'bzr reconfigure --tree'.  You might need to remove/disable bzr-colo first, I'm not sure.  Ideally bzr-colo's docs would cover this.
[01:26] <spiv> Although, if it's not causing you any problems, why change?
[01:26] <Stavros> because i can't commit to my other branch without this branch refusing to do anything unless i update :/
[01:27] <spiv> Ah ok.
[01:28] <Stavros> the command you gave me seems to have worked, let me check
[01:29] <Stavros> yep, that works, thanks!
[01:30] <spiv> Hooray, my new laptop can run the bzr test suite in under 10 minutes, and I haven't even tried running it in a tmpfs yet.
[02:32] <mlh> spiv: what's your new lappy? (am looking at  buying one too)
[02:32] <mlh> pm if you like
[02:50] <spiv> mlh: Thinkpad T410, so far so good.
[02:51] <spiv> Of course, I'm running maverick on it, so any issues could be blamed on that anyway ;)
[03:07]  * spiv -> food
[03:40] <mlh> ta
[09:04]  * spiv finishes up for the evening.  It's EOD time plus a headache seems to be coming on :(
[09:04] <spiv> On the plus side the new laptop is running smoothly and has all my old crap configured.
[09:05] <spiv> See you all on Monday!
[11:03] <rjek> Afternoon.  Is there any support for keyword-like expansion in bzr?  (ie, I want to include revision information in a file.)  While I could just have my build system query bzr, that doesn't work so well with tarballs produced with bzr export.
[11:04] <jelmer_> rjek, see the keywords plugin
[11:04]  * rjek was kinda hoping to avoid plugins.
[11:05] <rjek> And I can't find it on http://wiki.bazaar.canonical.com/BzrPlugins :)
[11:05] <Kinnison> jelmer_: Do you mean http://doc.bazaar.canonical.com/plugins/en/keywords-plugin.html ?
[11:07] <rjek> My only concern with using plugin to do it is that my experience is that if I then try to build somewhere without that plugin, it'll either silently fail and I'll get strange builds, or I'll get an explosion with a python backtrace I don't understand.
[11:07] <jelmer_> Kinnison: yep
[11:07] <jelmer_> rjek: alternatively you can use "bzr version-info" to generate output, it's not really the same thing though
[11:07] <jelmer_> Kinnison: Yep
[11:08] <rjek> jelmer_: yeah, but as I said, that doesn't work for people building from a tarball created with bzr export.
[11:08] <rjek> (In that I'm assuming they don't have bzr if they want to use the tarball.)
[11:14] <rjek> Also, it looks like that plugin can only have the rules that describe what files to process globally, not in a checkout, which is a bit nasty.
[11:15] <jelmer_> right
[11:15] <jelmer_> It'll work as long as whoever runs 'bzr export' has the plugin installed though
[11:16] <jelmer_> I'm not aware of any alternatives unfortunately
[11:19] <Kinnison> Could a branch can't define a hook to run on export which could be used to update the file?
[11:19] <Kinnison> s/can't//
[11:25] <rjek> Can the rule files described by "bzr help rules" be placed in a branch, rather than global?
[11:30] <Kinnison> Unfortunately it looks like whoever wrote bzrlib/rules.py never finished it properly
[11:30] <Kinnison> :-(
[11:31] <poolie> it was ian
[11:31] <poolie> probably
[11:31] <Kinnison> I wonder who reviewed it and didn't spot that RULES_TREE_FILENAME is defined as ".bzrrules" but then never used anywhere :-(
[11:33] <rjek> Can I have that feature, please? :)
[11:33] <rjek> Only having rules globally and not version controlled is... nasty :)
[11:34] <Kinnison> Aye, it has rules stacking in it already, but no way to activate them
[11:34] <Kinnison> boggle
[11:39] <Kinnison> Also with all of rules.py's external interfaces starting with an underscore, I'm not impressed
[11:40]  * Kinnison doesn't have the time to make a patch right now though :-(
[12:28] <jenkins> hi, I am getting this error when doing bzr pull or commit bzr: ERROR: Could not acquire lock "/home/luke-jennings/Projects/lucid-e2/.bzr/checkout/dirstate": [Errno 11] Resource temporarily unavailable. does that mean there is a problem with launchpad or my computer?
[12:33] <jenkins> I fixed it by getting a new branch
[12:39] <aj-dneg> quick q, how do i check out the previous revision?
[12:41] <aj-dneg> in-place of my workign copy
[12:54] <GaryvdM> aj-dneg: bzr update -r -2
[12:54] <aj-dneg> ah of course. i knew that. thanks :)
[14:25] <aj-dneg> is there any way to save bzr svn username and passwords other than in the URI for it svn://uname:pass@server/branch
[14:25] <aj-dneg> i know it's plain text in my branch config in any case, but it sucks that it shows it to the console!
[14:31] <mgz> does bzr-svn work with authentication.conf?
[14:31] <mgz> see no reason it shouldn't.
[14:32] <jelmer> it should
[14:33] <mgz> aj-dneg: in your bazaar configuration directory, open authentication.conf and add your details there
[14:34] <mgz> run `bzr version` if you're not sure where the dir is.
[14:35] <aj-dneg> mgz: i don't already have one of those files
[14:35] <aj-dneg> what format?
[14:35] <mgz> really? I thought it got created automatically.
[14:35] <mgz> run `bzr help authentication` for the full run down.
[14:36] <aj-dneg> i found this http://doc.bazaar.canonical.com/latest/developers/authentication-ring.html
[14:36] <aj-dneg> thanks
[14:36] <aj-dneg> mgz: perhaps bzr svn doesn't create it...
[14:36] <schlangen_> hi, I want to checkout a repo and have to use win vista. It fails cause win does not support symlinks. Is there any flag or workaround or so to get the checkout done?
[14:37] <mgz> use cygwin, or branch on nix, delete the symlinks, commit, and branch that on win.
[14:38] <mgz> also, bug the project to not version symlinks it's nearly always a bad idea anyway.
[14:39] <schlangen_> normally I use ubuntu but currently I've only internet with win
[14:39] <schlangen_> I just want to check out a project and get the code
[14:39] <mgz> yeah, I have often had a similar problem.
[14:40] <mgz> there have been a few discussions about a better solution, but there's no easy fix.
[14:40] <schlangen_> so there is no flag to replace symlinks on win with normal copies or so?
[14:41] <mgz> no. file a bug with the project, they're probably only using them for someting stupid anyway.
[14:41] <schlangen_> hm, ok
[14:41] <jelmer> aj-dneg: bzr itself doesn't create it either
[14:41] <mgz> which reminds me, I should have bugged someone here about lazr while the launchpad event was on.
[14:42] <aj-dneg> i just get a crash when i have svn defined in authentication.conf :(
[14:42] <mgz> they've got an unbranchable project due to symlinks, and another bug I filed a merge proposal to fix that's been ignored for months
[14:42] <mgz> might have been someone at the event they could have kicked in person.
[14:43] <mgz> aj-dneg: pastebin the traceback (I presume you mean python threw and exception rather than 'crash')
[14:43] <mgz> -d
[14:45] <aj-dneg> mgz: it created a crash dump for me
[14:45] <aj-dneg> mgz: i will deal with this later, supposed to be working :)
[14:45] <aj-dneg> thanks
[14:45] <mgz> apport thingy?
[14:46] <mgz> pastebin that if it's plaintext.
[15:23] <GaryvdM> Hi mgz
[15:32] <mgz> hey gary
[15:42] <GaryvdM> mgz: I can't find your pastebined patch for the py2exe optimize improvement
[15:43] <mgz> http://paste.ubuntu.com/460272/
[15:43] <mgz> third in my browser's history :)
[15:43] <mgz> it's only a guess, haven't tested.
[15:43] <GaryvdM> mgz: Ok - let me spin a build of that...
[15:48] <mgz> your 2.2b4 looks good, fixed all the stuff we worked on, though found some new issues that need handling before release
[17:20] <GaryvdM> http://lkml.indiana.edu/hypermail/linux/kernel/9809.3/0957.html
[17:21] <GaryvdM> A description of bitkeeper from 1998 - I did not realise that it was so old...
[17:34] <mgz> we're all getting old gary ;_;
[19:11] <jaxdroid> hi anyone here have experience in using the bzr plugin for eclipse?
[19:13] <maxb> Some. Which plugin, though? There are two.
[19:13] <jaxdroid> http://verterok.com.ar/bzr-eclipse/update-site/
[19:14] <maxb> I tried that for a bit, but decided that it was sadly too immature and buggy to be of practical use
[19:14] <jaxdroid> bizzare
[19:14] <dash> jaxdroid: i use it
[19:14] <jaxdroid> happen to have name to other plugin
[19:14] <dash> maxb: which is the other one?
[19:15] <maxb> qbzr-eclipse - which is a bit of an odd one, because it's not an Eclipse team provider
[19:15] <dash> aaah.
[19:15] <dash> not a team player
[19:16] <jaxdroid> thx
[19:17] <maxb> It's a rather different way of working - but it seems overall to have fewer rough edges than bzr-eclipse
[19:17] <maxb> Unfortunately the sad truth is that bzr doesn't have anywhere near as good eclipse support as mercurial
[19:39] <rioch> when I do bzr status, one of the items has a * by it. what does that mean?
[19:40] <rjek> "bzr help status" suggests the file has the executable bit set.
[19:41] <rioch> ahhh thanks
[19:43] <GaryvdM> mgz: https://dl.dropbox.com/u/4494367/bzr-2.2b4-optimize-setup.exe
[19:46] <GaryvdM> mgz: 6 kb smaller :-)
[19:46] <mgz> compressed?
[19:46] <GaryvdM> mgz: yes
[19:47] <GaryvdM> busy testing if it works with plugins installed from source with old style help strings.
[19:49] <mgz> appears to have worked
[19:50] <GaryvdM> mgz: Do you how can you get a cold cache on windows with out restarting?
[19:50] <mgz> can't unfortunately, and with new version of windows can't even always get it *with* restarting :)
[19:51] <mgz> library.zip is ~2.5MB smaller as planned, and the exe is creating non-docstring-stripped files
[19:52] <mgz> ^if you have a externally connected spinning rust hdd you could try that for a coolish start
[20:01] <GaryvdM> mgz: Maybe using cacheset, reduce the max cache size, and then put it back...
[20:01] <GaryvdM> http://technet.microsoft.com/en-us/sysinternals/bb897561.aspx
[20:01] <mgz> just murdering your memory does sort of work, but takes longer than simply restarting
[20:01] <mgz> get deep into paging death and takes ages to recover from
[20:02] <mgz> ah, that's not the util I thought it was going to be, but might suffer from similar issues
[20:03] <GaryvdM> mgz can see if you run an qbzr command from that install. I'm getting an error.
[20:04] <mgz> wfm.
[20:04] <GaryvdM> http://pastebin.org/413603
[20:04] <GaryvdM> mgz: qlog?
[20:05] <mgz> yup.
[20:05] <GaryvdM> Works?
[20:05] <mgz> yup.
[20:05] <mgz> can you do qversion? not being able to import Qt probably means you're totally hosed.
[20:06] <GaryvdM> mgz: I can do qversion
[20:06] <GaryvdM> can't do qlog, qbrowse, and explorer.
[20:09] <mgz> you should get qversion to print where it's getting Qt from/
[20:10] <GaryvdM> Yes
[20:11] <GaryvdM> Ah - I happens with a old version of qbzr (0.18dev) and a new installer with less qt dll's.
[20:12] <GaryvdM> * It
[20:13] <mars> Hi everyone, I have a testing question for the room
[20:14] <GaryvdM> Hi mars
[20:14] <mars> Hi GaryvdM
[20:15] <mars> so, the question: I presume that bzr tests command-line script output, which means the suite has to work with STDOUT somehow
[20:15] <mars> If so, how do you do it?
[20:16] <GaryvdM> mars: Most of the tests test the api. But there are some blackbox test.
[20:16] <mgz> assigning to sys.stdout
[20:17] <mgz> or using a subprocess.
[20:17] <lifeless> mars: self.run_bzr and self.run_bzr_subprocess
[20:17] <mars> interesting
[20:17] <lifeless> mars: the former uses apply_redirected to run the CLI layer with string io objects
[20:18] <lifeless> the latter reinvokes bzr to actually do an end to end test, which is only rarely (like, 3-4 times) needed in a full test run.
[20:18] <lifeless> mars: if you're writing a CLI layer, I'd suggest looking at the testrepository code, its a reimplementation of what bzr has, with the lessons learnt applied and some new ideas thrown in.
[20:18] <lifeless> mars: better yet, don't write a CLI layer, use bzr's.
[20:19] <lifeless> mars: lp-tools and commandant both have examples of reusing bzr's core handling to do stuff, and then you can use bzr's test cases to do self.run_... :)
[20:21] <mars> lifeless, interesting idea.  I'll look into it.  It would be nice to find a common ground between the bzr "command language" way and the *nix "small sharp tools" way.  I'm sure there is something.
[20:22] <mars> thanks everyone
[20:22] <GaryvdM> mars:
[20:22]  * mars pauses
[20:23] <GaryvdM> mars; for cli opts and args parseing, there is a python libaray
[20:23] <GaryvdM> looking for it...
[20:23] <mars> GaryvdM, yep, I am familiar with it
[20:23] <mgz> there are issues with both those methods in the bzr suite, but they're pretty esoteric
[20:23] <mgz> run_bzr screws up debugging tests with pdb
[20:23] <GaryvdM> mars: oh ok.
[20:24] <mars> mgz, heh, that's good to know.  I rely heavily on the 'drop to PDB' features of various testrunners
[20:24] <mgz> and run_bzr_subprocess doesn't handle being invoked from non-standard scripts
[20:24] <mars> mgz, non-standard?
[20:25] <lifeless> mars: bzr is small sharp tools :)
[20:25] <lifeless> mars: testrepository has more of a flavour of that though, if you want that.
[20:25] <mgz> as in, it's got special casing for a py2exe'd bzr.exe but anything else would break
[20:25] <lifeless> mars: dropping to pdb is great, but you never need to do that in a blackbox test - if you do you're not isolating your tests anywhere near enough.
[20:26] <lifeless> mars: layers man, layers.
[20:26] <lifeless> mars: it annoyed me in bzr about 2 times a year; I know how to fix it, just 'meh, when it annoys me twice in a row'
[20:26] <mars> lifeless, yes, but learning where the layers are best drawn is the challenge for me - "when do I test the boundaries?  How?  How much?"
[20:27] <mars> heh
[20:27] <lifeless> mars: if you're testing CLI *rendering* or *arg marshalling*, blackbox is the way.
[20:27] <lifeless> anything else, should be domain objects and narrower non-CLI-blackbox tests.
[20:28] <lifeless> IME, etc etc
[20:28] <mars> lifeless, makes sense - "test double MockFormatStdOutput.printBranch() should be called X times"
[20:29] <mars> and then black-box test printBranch() or something-or-other
[20:30] <lifeless> by blackbox I mean bzr's apply_redirected/run_bzr test methods, which actually exercise the full stack
[20:30] <mars> right
[20:30] <lifeless> but its quick, so we're not too worried about it - and we only have a few such tests (under 1K I think)
[20:30] <GaryvdM> mgz: I'm going to submit that patch as a mp. I think we need to make moving the py2exe stuff out of setup.py a priority.
[20:30] <mgz> a mp to bzr?
[20:30] <mgz> rather than bzr-windows-installers?
[20:31] <GaryvdM> mgz: right now to bzr
[20:31] <mars> lifeless, I guess I'll start looking at testrepository.  It has the infrastructure, but not so much code that it is difficult to find a starting point
[20:32] <GaryvdM> thats why moving the py2exe is important.
[20:33] <lifeless> mars: commandant might be better as its designed to be a intermediate library
[20:47] <mgz> okay, this is officially driving me nuts
[20:48] <mgz> in what circumstances is inserting the right dir as the first entry on sys.path not sufficient to get a module imported from there rather than elsewhere on the path on nix...
[20:49] <mgz> ...when the module is already somehow imported... but... how ;_;
[20:50] <mgz> modules shouldn't survive fork+exec right?
[21:04] <mgz> okay, I'm officially just an idiot.
[21:10] <lifeless> sure
[21:10] <lifeless> :P
[21:11] <lifeless> (why?)
[21:14] <mgz> debugging code I'd added earlier was importing the module
[21:16] <mgz> the code's still borked, but not for the reason I just spent all that time chasing
[21:38] <mgz> oh man, and that's the real killer. the fix I already put up a merge proposal *was* correct, I just tyoped it when putting it on the other machine...
[21:39] <mgz> if it didn't take so long to branch from here to there I'd have not spent the last hour trying to discover out why it didn't work...
[22:27] <lifeless> and ciao
[23:38] <micahg> can we have per branch whoami's?
[23:39] <jelmer> micahg, yes
[23:39] <jelmer> set email in .bzr/branch/branch.conf
[23:39] <jelmer> or in the relevant section in ~/.bazaar/locations.conf
[23:39] <Ken69267> is there a way to specify what ssh key bzr uses for launchpad? I do not use the default named key
[23:39] <micahg> jelmer: thanks
[23:44] <Ken69267> or if I must map it with .ssh/config what is the true url to launchpad that lp: hides