jelmer | spiv: around? | 00:02 |
---|---|---|
spiv | jelmer: starting to be :) | 00:07 |
jelmer | spiv: Have you ever seen anything like this: http://pastebin.com/t0te7wCQ ? | 00:25 |
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:35 |
jelmer | spiv: Thanks, that also explains why the number of tests that failed in this way varied | 00:36 |
spiv | You're welcome :) | 00:36 |
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:45 |
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:46 |
Chaorain | here is what I found, http://ubuntuforums.org/showthread.php?t=916132 | 00:47 |
Chaorain | oh nvm just saw "bzr init | 00:47 |
Chaorain | thanks for your help | 00:48 |
jelmer | spiv: Any idea how to figure out what code is doing that muttering? | 00:48 |
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? | 00:50 |
Stavros | hello | 01:18 |
Stavros | can anyone tell me why bzr does a light checkout when i cp -R my repo? | 01:18 |
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:21 |
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:22 |
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:23 |
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:24 |
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:26 |
spiv | Ah ok. | 01:27 |
Stavros | the command you gave me seems to have worked, let me check | 01:28 |
Stavros | yep, that works, thanks! | 01:29 |
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. | 01:30 |
mlh | spiv: what's your new lappy? (am looking at buying one too) | 02:32 |
mlh | pm if you like | 02:32 |
spiv | mlh: Thinkpad T410, so far so good. | 02:50 |
spiv | Of course, I'm running maverick on it, so any issues could be blamed on that anyway ;) | 02:51 |
* spiv -> food | 03:07 | |
mlh | ta | 03:40 |
=== davidstrauss_ is now known as davidstrauss | ||
* 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:04 |
spiv | See you all on Monday! | 09:05 |
=== oubiwann is now known as oubiwann-away | ||
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:03 |
jelmer_ | rjek, see the keywords plugin | 11:04 |
* rjek was kinda hoping to avoid plugins. | 11:04 | |
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:05 |
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:07 |
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:08 |
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:14 |
jelmer_ | right | 11:15 |
jelmer_ | It'll work as long as whoever runs 'bzr export' has the plugin installed though | 11:15 |
jelmer_ | I'm not aware of any alternatives unfortunately | 11:16 |
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:19 |
rjek | Can the rule files described by "bzr help rules" be placed in a branch, rather than global? | 11:25 |
Kinnison | Unfortunately it looks like whoever wrote bzrlib/rules.py never finished it properly | 11:30 |
Kinnison | :-( | 11:30 |
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:31 |
rjek | Can I have that feature, please? :) | 11:33 |
rjek | Only having rules globally and not version controlled is... nasty :) | 11:33 |
Kinnison | Aye, it has rules stacking in it already, but no way to activate them | 11:34 |
Kinnison | boggle | 11:34 |
Kinnison | Also with all of rules.py's external interfaces starting with an underscore, I'm not impressed | 11:39 |
* Kinnison doesn't have the time to make a patch right now though :-( | 11:40 | |
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:28 |
jenkins | I fixed it by getting a new branch | 12:33 |
aj-dneg | quick q, how do i check out the previous revision? | 12:39 |
aj-dneg | in-place of my workign copy | 12:41 |
GaryvdM | aj-dneg: bzr update -r -2 | 12:54 |
aj-dneg | ah of course. i knew that. thanks :) | 12:54 |
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:25 |
mgz | does bzr-svn work with authentication.conf? | 14:31 |
mgz | see no reason it shouldn't. | 14:31 |
jelmer | it should | 14:32 |
mgz | aj-dneg: in your bazaar configuration directory, open authentication.conf and add your details there | 14:33 |
mgz | run `bzr version` if you're not sure where the dir is. | 14:34 |
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:35 |
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:36 |
mgz | use cygwin, or branch on nix, delete the symlinks, commit, and branch that on win. | 14:37 |
mgz | also, bug the project to not version symlinks it's nearly always a bad idea anyway. | 14:38 |
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:39 |
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:40 |
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:41 |
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:42 |
mgz | aj-dneg: pastebin the traceback (I presume you mean python threw and exception rather than 'crash') | 14:43 |
mgz | -d | 14:43 |
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:45 |
mgz | pastebin that if it's plaintext. | 14:46 |
GaryvdM | Hi mgz | 15:23 |
mgz | hey gary | 15:32 |
GaryvdM | mgz: I can't find your pastebined patch for the py2exe optimize improvement | 15:42 |
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:43 |
mgz | your 2.2b4 looks good, fixed all the stuff we worked on, though found some new issues that need handling before release | 15:48 |
=== beuno is now known as beuno-lunch | ||
=== tchan1 is now known as tchan | ||
GaryvdM | http://lkml.indiana.edu/hypermail/linux/kernel/9809.3/0957.html | 17:20 |
GaryvdM | A description of bitkeeper from 1998 - I did not realise that it was so old... | 17:21 |
mgz | we're all getting old gary ;_; | 17:34 |
=== beuno-lunch is now known as beuno | ||
=== jelmer_ is now known as jelmer | ||
jaxdroid | hi anyone here have experience in using the bzr plugin for eclipse? | 19:11 |
maxb | Some. Which plugin, though? There are two. | 19:13 |
jaxdroid | http://verterok.com.ar/bzr-eclipse/update-site/ | 19:13 |
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:14 |
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:15 |
jaxdroid | thx | 19:16 |
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:17 |
=== beuno_ is now known as beuno | ||
rioch | when I do bzr status, one of the items has a * by it. what does that mean? | 19:39 |
rjek | "bzr help status" suggests the file has the executable bit set. | 19:40 |
rioch | ahhh thanks | 19:41 |
GaryvdM | mgz: https://dl.dropbox.com/u/4494367/bzr-2.2b4-optimize-setup.exe | 19:43 |
GaryvdM | mgz: 6 kb smaller :-) | 19:46 |
mgz | compressed? | 19:46 |
GaryvdM | mgz: yes | 19:46 |
GaryvdM | busy testing if it works with plugins installed from source with old style help strings. | 19:47 |
mgz | appears to have worked | 19:49 |
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:50 |
mgz | library.zip is ~2.5MB smaller as planned, and the exe is creating non-docstring-stripped files | 19:51 |
mgz | ^if you have a externally connected spinning rust hdd you could try that for a coolish start | 19:52 |
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:01 |
mgz | ah, that's not the util I thought it was going to be, but might suffer from similar issues | 20:02 |
GaryvdM | mgz can see if you run an qbzr command from that install. I'm getting an error. | 20:03 |
mgz | wfm. | 20:04 |
GaryvdM | http://pastebin.org/413603 | 20:04 |
GaryvdM | mgz: qlog? | 20:04 |
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:05 |
GaryvdM | mgz: I can do qversion | 20:06 |
GaryvdM | can't do qlog, qbrowse, and explorer. | 20:06 |
mgz | you should get qversion to print where it's getting Qt from/ | 20:09 |
GaryvdM | Yes | 20:10 |
GaryvdM | Ah - I happens with a old version of qbzr (0.18dev) and a new installer with less qt dll's. | 20:11 |
GaryvdM | * It | 20:12 |
mars | Hi everyone, I have a testing question for the room | 20:13 |
GaryvdM | Hi mars | 20:14 |
mars | Hi GaryvdM | 20:14 |
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:15 |
GaryvdM | mars: Most of the tests test the api. But there are some blackbox test. | 20:16 |
mgz | assigning to sys.stdout | 20:16 |
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:17 |
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:18 |
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:19 |
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:21 |
mars | thanks everyone | 20:22 |
GaryvdM | mars: | 20:22 |
* mars pauses | 20:22 | |
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:23 |
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:24 |
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:25 |
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:26 |
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:27 |
lifeless | IME, etc etc | 20:28 |
mars | lifeless, makes sense - "test double MockFormatStdOutput.printBranch() should be called X times" | 20:28 |
mars | and then black-box test printBranch() or something-or-other | 20:29 |
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:30 |
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:31 |
GaryvdM | thats why moving the py2exe is important. | 20:32 |
lifeless | mars: commandant might be better as its designed to be a intermediate library | 20:33 |
mgz | okay, this is officially driving me nuts | 20:47 |
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:48 |
mgz | ...when the module is already somehow imported... but... how ;_; | 20:49 |
mgz | modules shouldn't survive fork+exec right? | 20:50 |
mgz | okay, I'm officially just an idiot. | 21:04 |
lifeless | sure | 21:10 |
lifeless | :P | 21:10 |
lifeless | (why?) | 21:11 |
mgz | debugging code I'd added earlier was importing the module | 21:14 |
mgz | the code's still borked, but not for the reason I just spent all that time chasing | 21:16 |
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:38 |
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... | 21:39 |
=== Ursinha is now known as Ursinha-bbl | ||
lifeless | and ciao | 22:27 |
micahg | can we have per branch whoami's? | 23:38 |
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:39 |
Ken69267 | or if I must map it with .ssh/config what is the true url to launchpad that lp: hides | 23:44 |
=== kbrown_ is now known as kbrown |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!