[00:02] spiv: around? [00:07] jelmer: starting to be :) [00:25] spiv: Have you ever seen anything like this: http://pastebin.com/t0te7wCQ ? [00:35] 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] spiv: ahh! [00:36] spiv: Thanks, that also explains why the number of tests that failed in this way varied [00:36] You're welcome :) [00:45] 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] Chaorain, yes [00:46] ok cool. I saw how to install it but how would I go about doing what I want? [00:47] here is what I found, http://ubuntuforums.org/showthread.php?t=916132 [00:47] oh nvm just saw "bzr init [00:48] thanks for your help [00:48] spiv: Any idea how to figure out what code is doing that muttering? [00:50] jelmer: hmm, not off the top of my head :/ [00:50] jelmer: instrument mutter to emit a traceback to stderr on ValueError, perhaps? [01:18] hello [01:18] can anyone tell me why bzr does a light checkout when i cp -R my repo? [01:21] 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] i'm doing cp -R repo/ repo2/; bzr info; and i see "lightweight checkout" [01:22] shouldn't that be a full branch? [01:22] i mean, how much fuller can it get? [01:23] Well, what does 'bzr info' in the original repo/ report? [01:23] also lightweight checkout [01:23] what the hell? [01:23] how can that be lightweight? i can commit fine locally [01:24] checkout of branch: .bzr/branches/trunk [01:24] i have no idea what's going on :/ [01:24] Are you using the bzr-colo plugin, perhaps? [01:24] ah, i am [01:24] is there some way i can remove it? [01:24] This would just be an artefact of how it works, I think. [01:24] and convert to a full checkout? [01:26] 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] Although, if it's not causing you any problems, why change? [01:26] because i can't commit to my other branch without this branch refusing to do anything unless i update :/ [01:27] Ah ok. [01:28] the command you gave me seems to have worked, let me check [01:29] yep, that works, thanks! [01:30] 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] spiv: what's your new lappy? (am looking at buying one too) [02:32] pm if you like [02:50] mlh: Thinkpad T410, so far so good. [02:51] Of course, I'm running maverick on it, so any issues could be blamed on that anyway ;) [03:07] * spiv -> food [03:40] ta === davidstrauss_ is now known as davidstrauss [09:04] * spiv finishes up for the evening. It's EOD time plus a headache seems to be coming on :( [09:04] On the plus side the new laptop is running smoothly and has all my old crap configured. [09:05] See you all on Monday! === oubiwann is now known as oubiwann-away [11:03] 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] rjek, see the keywords plugin [11:04] * rjek was kinda hoping to avoid plugins. [11:05] And I can't find it on http://wiki.bazaar.canonical.com/BzrPlugins :) [11:05] jelmer_: Do you mean http://doc.bazaar.canonical.com/plugins/en/keywords-plugin.html ? [11:07] 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] Kinnison: yep [11:07] rjek: alternatively you can use "bzr version-info" to generate output, it's not really the same thing though [11:07] Kinnison: Yep [11:08] jelmer_: yeah, but as I said, that doesn't work for people building from a tarball created with bzr export. [11:08] (In that I'm assuming they don't have bzr if they want to use the tarball.) [11:14] 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] right [11:15] It'll work as long as whoever runs 'bzr export' has the plugin installed though [11:16] I'm not aware of any alternatives unfortunately [11:19] Could a branch can't define a hook to run on export which could be used to update the file? [11:19] s/can't// [11:25] Can the rule files described by "bzr help rules" be placed in a branch, rather than global? [11:30] Unfortunately it looks like whoever wrote bzrlib/rules.py never finished it properly [11:30] :-( [11:31] it was ian [11:31] probably [11:31] I wonder who reviewed it and didn't spot that RULES_TREE_FILENAME is defined as ".bzrrules" but then never used anywhere :-( [11:33] Can I have that feature, please? :) [11:33] Only having rules globally and not version controlled is... nasty :) [11:34] Aye, it has rules stacking in it already, but no way to activate them [11:34] boggle [11:39] 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] 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] I fixed it by getting a new branch [12:39] quick q, how do i check out the previous revision? [12:41] in-place of my workign copy [12:54] aj-dneg: bzr update -r -2 [12:54] ah of course. i knew that. thanks :) [14:25] 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] 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] does bzr-svn work with authentication.conf? [14:31] see no reason it shouldn't. [14:32] it should [14:33] aj-dneg: in your bazaar configuration directory, open authentication.conf and add your details there [14:34] run `bzr version` if you're not sure where the dir is. [14:35] mgz: i don't already have one of those files [14:35] what format? [14:35] really? I thought it got created automatically. [14:35] run `bzr help authentication` for the full run down. [14:36] i found this http://doc.bazaar.canonical.com/latest/developers/authentication-ring.html [14:36] thanks [14:36] mgz: perhaps bzr svn doesn't create it... [14:36] 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] use cygwin, or branch on nix, delete the symlinks, commit, and branch that on win. [14:38] also, bug the project to not version symlinks it's nearly always a bad idea anyway. [14:39] normally I use ubuntu but currently I've only internet with win [14:39] I just want to check out a project and get the code [14:39] yeah, I have often had a similar problem. [14:40] there have been a few discussions about a better solution, but there's no easy fix. [14:40] so there is no flag to replace symlinks on win with normal copies or so? [14:41] no. file a bug with the project, they're probably only using them for someting stupid anyway. [14:41] hm, ok [14:41] aj-dneg: bzr itself doesn't create it either [14:41] which reminds me, I should have bugged someone here about lazr while the launchpad event was on. [14:42] i just get a crash when i have svn defined in authentication.conf :( [14:42] 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] might have been someone at the event they could have kicked in person. [14:43] aj-dneg: pastebin the traceback (I presume you mean python threw and exception rather than 'crash') [14:43] -d [14:45] mgz: it created a crash dump for me [14:45] mgz: i will deal with this later, supposed to be working :) [14:45] thanks [14:45] apport thingy? [14:46] pastebin that if it's plaintext. [15:23] Hi mgz [15:32] hey gary [15:42] mgz: I can't find your pastebined patch for the py2exe optimize improvement [15:43] http://paste.ubuntu.com/460272/ [15:43] third in my browser's history :) [15:43] it's only a guess, haven't tested. [15:43] mgz: Ok - let me spin a build of that... [15:48] your 2.2b4 looks good, fixed all the stuff we worked on, though found some new issues that need handling before release === beuno is now known as beuno-lunch === tchan1 is now known as tchan [17:20] http://lkml.indiana.edu/hypermail/linux/kernel/9809.3/0957.html [17:21] A description of bitkeeper from 1998 - I did not realise that it was so old... [17:34] we're all getting old gary ;_; === beuno-lunch is now known as beuno === jelmer_ is now known as jelmer [19:11] hi anyone here have experience in using the bzr plugin for eclipse? [19:13] Some. Which plugin, though? There are two. [19:13] http://verterok.com.ar/bzr-eclipse/update-site/ [19:14] I tried that for a bit, but decided that it was sadly too immature and buggy to be of practical use [19:14] bizzare [19:14] jaxdroid: i use it [19:14] happen to have name to other plugin [19:14] maxb: which is the other one? [19:15] qbzr-eclipse - which is a bit of an odd one, because it's not an Eclipse team provider [19:15] aaah. [19:15] not a team player [19:16] thx [19:17] It's a rather different way of working - but it seems overall to have fewer rough edges than bzr-eclipse [19:17] Unfortunately the sad truth is that bzr doesn't have anywhere near as good eclipse support as mercurial === beuno_ is now known as beuno [19:39] when I do bzr status, one of the items has a * by it. what does that mean? [19:40] "bzr help status" suggests the file has the executable bit set. [19:41] ahhh thanks [19:43] mgz: https://dl.dropbox.com/u/4494367/bzr-2.2b4-optimize-setup.exe [19:46] mgz: 6 kb smaller :-) [19:46] compressed? [19:46] mgz: yes [19:47] busy testing if it works with plugins installed from source with old style help strings. [19:49] appears to have worked [19:50] mgz: Do you how can you get a cold cache on windows with out restarting? [19:50] can't unfortunately, and with new version of windows can't even always get it *with* restarting :) [19:51] library.zip is ~2.5MB smaller as planned, and the exe is creating non-docstring-stripped files [19:52] ^if you have a externally connected spinning rust hdd you could try that for a coolish start [20:01] mgz: Maybe using cacheset, reduce the max cache size, and then put it back... [20:01] http://technet.microsoft.com/en-us/sysinternals/bb897561.aspx [20:01] just murdering your memory does sort of work, but takes longer than simply restarting [20:01] get deep into paging death and takes ages to recover from [20:02] ah, that's not the util I thought it was going to be, but might suffer from similar issues [20:03] mgz can see if you run an qbzr command from that install. I'm getting an error. [20:04] wfm. [20:04] http://pastebin.org/413603 [20:04] mgz: qlog? [20:05] yup. [20:05] Works? [20:05] yup. [20:05] can you do qversion? not being able to import Qt probably means you're totally hosed. [20:06] mgz: I can do qversion [20:06] can't do qlog, qbrowse, and explorer. [20:09] you should get qversion to print where it's getting Qt from/ [20:10] Yes [20:11] Ah - I happens with a old version of qbzr (0.18dev) and a new installer with less qt dll's. [20:12] * It [20:13] Hi everyone, I have a testing question for the room [20:14] Hi mars [20:14] Hi GaryvdM [20:15] so, the question: I presume that bzr tests command-line script output, which means the suite has to work with STDOUT somehow [20:15] If so, how do you do it? [20:16] mars: Most of the tests test the api. But there are some blackbox test. [20:16] assigning to sys.stdout [20:17] or using a subprocess. [20:17] mars: self.run_bzr and self.run_bzr_subprocess [20:17] interesting [20:17] mars: the former uses apply_redirected to run the CLI layer with string io objects [20:18] 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] 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] mars: better yet, don't write a CLI layer, use bzr's. [20:19] 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] 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] thanks everyone [20:22] mars: [20:22] * mars pauses [20:23] mars; for cli opts and args parseing, there is a python libaray [20:23] looking for it... [20:23] GaryvdM, yep, I am familiar with it [20:23] there are issues with both those methods in the bzr suite, but they're pretty esoteric [20:23] run_bzr screws up debugging tests with pdb [20:23] mars: oh ok. [20:24] mgz, heh, that's good to know. I rely heavily on the 'drop to PDB' features of various testrunners [20:24] and run_bzr_subprocess doesn't handle being invoked from non-standard scripts [20:24] mgz, non-standard? [20:25] mars: bzr is small sharp tools :) [20:25] mars: testrepository has more of a flavour of that though, if you want that. [20:25] as in, it's got special casing for a py2exe'd bzr.exe but anything else would break [20:25] 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] mars: layers man, layers. [20:26] 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] 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] heh [20:27] mars: if you're testing CLI *rendering* or *arg marshalling*, blackbox is the way. [20:27] anything else, should be domain objects and narrower non-CLI-blackbox tests. [20:28] IME, etc etc [20:28] lifeless, makes sense - "test double MockFormatStdOutput.printBranch() should be called X times" [20:29] and then black-box test printBranch() or something-or-other [20:30] by blackbox I mean bzr's apply_redirected/run_bzr test methods, which actually exercise the full stack [20:30] right [20:30] 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] 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] a mp to bzr? [20:30] rather than bzr-windows-installers? [20:31] mgz: right now to bzr [20:31] 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] thats why moving the py2exe is important. [20:33] mars: commandant might be better as its designed to be a intermediate library [20:47] okay, this is officially driving me nuts [20:48] 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] ...when the module is already somehow imported... but... how ;_; [20:50] modules shouldn't survive fork+exec right? [21:04] okay, I'm officially just an idiot. [21:10] sure [21:10] :P [21:11] (why?) [21:14] debugging code I'd added earlier was importing the module [21:16] the code's still borked, but not for the reason I just spent all that time chasing [21:38] 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] 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... === Ursinha is now known as Ursinha-bbl [22:27] and ciao [23:38] can we have per branch whoami's? [23:39] micahg, yes [23:39] set email in .bzr/branch/branch.conf [23:39] or in the relevant section in ~/.bazaar/locations.conf [23:39] is there a way to specify what ssh key bzr uses for launchpad? I do not use the default named key [23:39] jelmer: thanks [23:44] or if I must map it with .ssh/config what is the true url to launchpad that lp: hides === kbrown_ is now known as kbrown