| lifeless | davidstrauss: probably a bug in directory resolution lookup, if lp:~pressflow/pressflow/merge-drupal-6.17 works | 00:00 |
|---|---|---|
| * thumper is thinking of wikkid in GAE | 00:00 | |
| davidstrauss | lifeless: correct | 00:00 |
| davidstrauss | lifeless: the plain url work | 00:00 |
| lifeless | davidstrauss: you can replace lp: with bzr+ssh://bazaar.launchpad.net/ - and please file a bug | 00:00 |
| lifeless | thumper: I mean the entire stack in C | 00:00 |
| lifeless | thumper: plugins, UI, the lot. | 00:01 |
| thumper | oh | 00:01 |
| thumper | yeah, I agree that the runtime would be faseter | 00:01 |
| thumper | lifeless: do you know the policy of hg in this area? | 00:02 |
| lifeless | thumper: it used to be C only for some stuff; I know someone buitl python versions, but I don't know if they have a 'keep up to date' policy on them. | 00:03 |
| davidstrauss | lifeless: bzr: ERROR: Unsupported protocol for url "ancestor:http://bazaar.launchpad.net/~pressflow/pressflow/merge-drupal-6.17" | 00:03 |
| jelmer | davidstrauss: ancestor only works for -r | 00:03 |
| davidstrauss | jelmer: it doesn't work for --old? | 00:04 |
| lifeless | oh, of course. | 00:04 |
| davidstrauss | oh | 00:04 |
| === r0bby is now known as robbyoconnor | ||
| spiv | Good morning | 00:59 |
| lifeless | hola | 00:59 |
| MrKeuner | hi, is bzr completely integrated with nautilus? will I see which files are up2date recursively? | 02:58 |
| poolie | i think so | 02:58 |
| MrKeuner | something like tortoise svn? | 02:59 |
| poolie | right | 03:00 |
| poolie | if you're on ubuntu you may want to install groundconttrol | 03:00 |
| MrKeuner | yes, Lucid here | 03:00 |
| MrKeuner | poolie, I used rabbitvcs but it is awfully slow when the number of files is large | 03:01 |
| MrKeuner | do you know if bzr is better handling massive number of files? | 03:01 |
| poolie | i'm not sure | 03:02 |
| poolie | i would probably not recommend using it with nautilus if you have a huge number of files | 03:02 |
| MrKeuner | 20GB | 03:07 |
| lifeless | any pipeline users around? | 04:06 |
| lifeless | thumper: ? | 04:06 |
| thumper | yes? | 04:06 |
| lifeless | how do you go forward/back a single pipe ? | 04:07 |
| lifeless | and all the way to the start/all the way to the end | 04:07 |
| lifeless | I have a loom patch from Aaron which changes up-thread to do --auto by default | 04:07 |
| thumper | bzr switch-pipe :first, :next, :prev, :last | 04:07 |
| lifeless | I'm guessing pipeline is similar ... ah | 04:07 |
| thumper | or bzr switch | 04:07 |
| lifeless | without knowing the names | 04:08 |
| thumper | switch-pipe shelves and switches | 04:08 |
| lifeless | what about pump | 04:08 |
| lifeless | or whatever its called | 04:08 |
| thumper | pump doesn't change the current pipe | 04:08 |
| lifeless | no ? | 04:08 |
| thumper | but pushes the change from the current pipe down the pipeline | 04:08 |
| thumper | it only switches if it finds conflicts | 04:08 |
| lifeless | do you use pump a lot ? | 04:09 |
| thumper | it depends what I'm doing | 04:09 |
| lifeless | ok | 04:09 |
| lifeless | hmm, I'll merge it, can see whether folk like it. | 04:09 |
| * thumper nods | 04:10 | |
| thumper | I've not used pipelines in the last several months | 04:10 |
| thumper | not needed them | 04:10 |
| thumper | all my recent work has been simple | 04:10 |
| thumper | but I find them great for bigger chunks | 04:10 |
| thumper | or to break out refactorings into a different branch | 04:11 |
| lifeless | oh yes | 04:11 |
| lifeless | totally appreciate the use case | 04:11 |
| lifeless | I'm trying to learn about the common bits of their use with looms to make looms good too | 04:12 |
| lifeless | and asking happy users is a great way to do that, I think :) | 04:14 |
| thumper | :) | 04:18 |
| lifeless | spiv: how are you finding finding udd tasks at the moment? | 04:38 |
| lifeless | spiv: you were, IIRC, going to attempt a udd import -> loom converter | 04:39 |
| lifeless | spiv: and I have just finished a slightly painful merge so if you wanted to talk about such a thing, now would be a most excellent time for me | 04:39 |
| === jamesh_ is now known as jamesh | ||
| * lifeless takes a break | 06:00 | |
| spiv | lifeless: sorry, was at lunch and then focussed in finishing my patch for bug 590637 | 06:47 |
| ubot5 | Launchpad bug 590637 in Bazaar "use a socketpair to talk to the ssh client process (affected: 1, heat: 23)" [Medium,Confirmed] https://launchpad.net/bugs/590637 | 06:47 |
| lifeless | spiv: no worries | 06:51 |
| lifeless | spiv: why do we expect that to behave differently ? | 06:52 |
| spiv | lifeless: it's easier to do short reads on sockets | 06:58 |
| lifeless | so the theory is that ssh is filling up its tcp buffer because it can't hand off data to us in small chunks ? | 06:59 |
| spiv | lifeless: something like that. We aren't expecting miracles, but it seemed like a cheap thing to try, and in general less syscalls is a good idea. | 07:01 |
| lifeless | spiv: were we reading 1 byte at a time before, or something? | 07:02 |
| spiv | lifeless: right (sometimes, depending on how much we could be sure should be on the pipe) | 07:02 |
| lifeless | kk | 07:03 |
| spiv | It turned out that the patch was a little bit fiddlier than I thought it would be, but it has helped me clean up a few messy corners of the code, so I'm happy with it on general principles :) | 07:03 |
| GaryvdM | Hi all. | 07:05 |
| GaryvdM | Public holiday today - So I can work on bzr \o/ | 07:05 |
| lifeless | \o/ | 07:05 |
| lifeless | righto, break over, back to lums | 07:07 |
| lifeless | actually, caffeine supply. then looms | 07:07 |
| spiv | And the patch lets us use the nicer socket code paths with paramiko now too. | 07:08 |
| vila | hi all | 07:22 |
| vila | spiv: Is there an impact on the test servers ? | 07:22 |
| spiv | vila: no, it's all client-side | 07:23 |
| vila | spiv: ok | 07:23 |
| vila | spiv: Quick chat about the smart server ? | 07:31 |
| vila | spiv: It's running in the main thread when started with 'bzr serve' but in a background thread for tests right ? | 07:32 |
| === radoe_ is now known as radoe | ||
| spiv | Typically, yes. | 07:39 |
| spiv | (It's possible there's a test or two that runs it in the main thread, I don't recall for sure.) | 07:39 |
| vila | it's ok I can check for details there | 07:39 |
| vila | spiv: How is it stopped ? (From a user point of view) | 07:40 |
| vila | More precisely, can it be asked to stop serving new connections while letting the current requests finish ? | 07:41 |
| spiv | vila: How is "bzr serve" stopped? Ctrl-C, or SIGTERM. | 07:42 |
| spiv | And no, it doesn't yet have a "stop serving new but let current connections finish" feature yet. | 07:42 |
| vila | ha, ok, so the connection threads are just aborted then ? | 07:43 |
| spiv | Hmm, depends on if they are setDaemon(True) I guess, I don't remember. | 07:43 |
| vila | yes, they are daemonic | 07:43 |
| spiv | So, yes :) | 07:43 |
| spiv | I think clean shutdown is a nice-to-have feature for a server, but you need to figure out what to do with very long lived connections/requests... in the end you probably just kill them anyway. | 07:44 |
| spiv | And no-one has asked for it, so it's not a high-priority :) | 07:45 |
| vila | Yeah, I don't want to dive into that now :) I was just making sure I was understanding the current design | 07:45 |
| spiv | *nod* | 07:45 |
| vila | I'm still wondering if I should use my new TestServerInAThread for SmartServer_for_testing or for the real thing, the former smells a bit like cheating (i.e. use a different code for tests as far as threads/sockets are concerned) | 07:47 |
| vila | but since there is no big constraints on the real smart server I may postpone some parts and just focus on the tests | 07:48 |
| vila | spiv: One more thing: digging the history didn't really explain why TCP_NODELAY is used for both the server socket and the connection ones and also why SO_REUSEADDR is used on windows | 07:54 |
| vila | spiv: I ask more for curiosity than anything else and to ensure I don't need to care about it | 07:55 |
| spiv | TCP_NODELAY because HPSS messages are currently written in a bunch of small writes | 07:56 |
| vila | Should I do that unconditionally for all our tests servers ? This shouldn't hurt doesn't it ? | 07:57 |
| spiv | i.e. the code has points at which it knows it is going to do multiple (probably small) writes with no delay between them | 07:57 |
| vila | Or is there a risk to hide bugs doing that ? | 07:57 |
| spiv | It would probably be a little nicer to use TCP_CORK instead to buffer those, and then flush that buffer at the end of those sequences of writes. | 07:57 |
| spiv | I forget exactly why we use SO_REUSEADDR on windows, but I do recall it means something subtly different on win32 to posix | 07:58 |
| vila | Yeah, too bad the comment is only: '# SO_REUSERADDR has a different meaning on Windows' :) | 08:02 |
| vila | nm, thanks for the tips | 08:02 |
| vila | have a good evening, who knows, may be a dream will pop up with the explanation ;-) | 08:03 |
| spiv | vila: https://bugs.edge.launchpad.net/bzr/+bug/164288 | 08:04 |
| ubot5 | Launchpad bug 164288 in Bazaar "bzr serve leaves connections in CLOSE_WAIT a *long* time (affected: 0, heat: 0)" [High,Fix released] | 08:04 |
| spiv | vila: see also the NEWS entry for that bug | 08:04 |
| vila | spiv: excellent ! | 08:06 |
| vila | verrrrry interesting | 08:07 |
| spiv | vila: I would expect that's fairly uninteresting for tests, because tests should generally be careful to listen on free ports (via asking for port 0), so if the TCP stack thinks the old ports are still busy shouldn't matter... | 08:08 |
| spiv | Unless of course the system has a very small transient port range, or something. | 08:09 |
| vila | unless we start smart servers on port 4155... worth checking as this would explain the delays on windows | 08:10 |
| vila | not holding my breath though | 08:10 |
| lifeless | we do 2 I think | 08:10 |
| lifeless | possibly not even that | 08:10 |
| vila | lifeless: ECANTPARSE 2: too ? two ? | 08:11 |
| lifeless | 2 | 08:11 |
| vila | as in 2 tests are doing that ? | 08:11 |
| lifeless | yes | 08:12 |
| lifeless | vila: we may not, but I think we have one or two smoke tests for it | 08:13 |
| spiv | Hmm, IIRC none of our tests rely on port 4155 being free. | 08:15 |
| vila | ok, I will run into them eventually anyway, but if there are only two that's not enough to explain the delays (which of course doesn't occur when a single test is run...) | 08:15 |
| lifeless | vila: that was my point ;) | 08:15 |
| vila | lifeless: ok, thanks | 08:16 |
| spiv | (even blackbox.test_serve uses localhost:0 as the host:port, and then finds out the actual port number via the server-started hook) | 08:16 |
| vila | spiv: thanks for checking :) Oh, and sorry for the noise, I misread the code: we *don't* use SO_REUSEADDR on windows, never :) | 08:18 |
| * vila hides | 08:18 | |
| lifeless | spiv: win32 has socketpairs ? | 08:18 |
| spiv | lifeless: no | 08:19 |
| lifeless | how is it catered for here | 08:19 |
| lifeless | spiv: also the docstring on SSHParams is both ugly (PEP8 may mandate that double empty line; its wrong) but also inaccurate | 08:20 |
| spiv | a) it falls back to subprocess.PIPE for stdin/stdout, and the old pipe-medium code path, b) many windows users will be using paramiko rather than subprocesses anyway | 08:20 |
| lifeless | spiv: I'm worried about the hunk @@ -737,26 +733,42 @@ | 08:20 |
| lifeless | + # XXX: Perhaps should use accept_bytes rather than _accept_bytes? | 08:21 |
| lifeless | would like a little more context | 08:21 |
| spiv | The double-empty line is just a leftover from a earlier edit, thanks for spotting. I'm tempted to just delete that docstring entirely, but maybe add one to the class instead of __init__ | 08:21 |
| spiv | Fair enough. | 08:21 |
| lifeless | + # XXX: perhaps should delegate to read_bytes, not _read_bytes? | 08:22 |
| lifeless | likewise | 08:22 |
| spiv | The short answer is: it's ok to call _accept_bytes, at least with the current implementations of things, and avoids some (probably minor) overhead the public function. | 08:22 |
| spiv | I'll just call the public methods I think. | 08:23 |
| lifeless | spiv: I meant in the code, for poor folk like you coming back in 3 months | 08:23 |
| lifeless | ;) | 08:23 |
| spiv | lifeless: well, deleting XXX > elaborating XXX :) | 08:23 |
| lifeless | :) | 08:23 |
| lifeless | I'm happy any which way | 08:23 |
| lifeless | the _real_medium thing is a little unclear | 08:24 |
| lifeless | its not clear what makes a medium really a medium, or not a medium, | 08:24 |
| lifeless | I think that that should be clarified | 08:24 |
| spiv | If it's not big and not small it's medium ;) | 08:25 |
| lifeless | :P | 08:25 |
| spiv | "A medium is something that implements the contract of SmartMedium", or is that too circular for you? | 08:26 |
| lifeless | spiv: your NEWS entry should list all the publicish functions you are destroying, please. | 08:26 |
| spiv | Ok. | 08:26 |
| lifeless | spiv: I don't understand why a MediumX would delegate to a MediumY | 08:26 |
| spiv | Well, as a separate NEWS entry under API Changese, I guess. | 08:26 |
| lifeless | when it previously was implementing Medium itself | 08:26 |
| lifeless | spiv: NEWS: naturally ) | 08:27 |
| spiv | For ease of implementation | 08:27 |
| lifeless | what isn't clear is what is in SmartSSHClientMedium that isn't in SmartClientSocketMedium | SmartClientAlreadyConnectedSocketMedium | 08:27 |
| vila | mediums are most useful to communicate with dead things, which is why we need them :) | 08:28 |
| lifeless | for instance, looking at the diff | 08:28 |
| lifeless | + def _flush(self): | 08:28 |
| lifeless | + """See SmartClientStreamMedium._flush(). | 08:28 |
| lifeless | + | 08:28 |
| lifeless | + For TCP we do no flushing. We may want to turn off TCP_NODELAY and | 08:28 |
| lifeless | ... | 08:28 |
| lifeless | is on SmartClientSocketMedium | 08:28 |
| lifeless | but the docstring is relevant to a subclass | 08:28 |
| spiv | Well, sometimes this medium will have a pipe, and sometimes you will have a socket, and the SSHClientMedium doesn't know which in advance. | 08:29 |
| lifeless | so perhaps - you've rearranged things | 08:29 |
| mgz | morning all | 08:29 |
| spiv | I have rearranged things, and possibly some docstrings didn't quite land in the best spots. | 08:29 |
| lifeless | but it needs a read-over to make sure that the pulled-up/pushed-down methods still refer to their actual classes | 08:29 |
| GaryvdM | hi mgz | 08:29 |
| lifeless | overall it looks good | 08:29 |
| spiv | Ok, will do. | 08:29 |
| lifeless | I'm still concerned about the | 08:29 |
| lifeless | @@ -737,26 +733,42 @@ | 08:29 |
| lifeless | def _read_bytes(self, count): | 08:29 |
| lifeless | """See SmartClientStreamMedium._read_bytes.""" | 08:29 |
| lifeless | - bytes = osutils.until_no_eintr(self._readable_pipe.read, count) | 08:29 |
| lifeless | hunk | 08:30 |
| spiv | Heh, thanks for pointing that out just as mgz joined the channel ;) | 08:30 |
| vila | mgz, GaryvdM : \o_ | 08:30 |
| lifeless | I don't see, if we keep the ability to use pipes, that we can delete that protection. | 08:30 |
| lifeless | hi mgz | 08:30 |
| lifeless | spiv: am I wrong ? | 08:30 |
| spiv | The SimplePipes medium that line was from was only ever used by the test suite, note real code. | 08:30 |
| mgz | ah, I see the topic is more socket joy | 08:31 |
| spiv | Because the SSHClient medium was actually doing its own pipe IO logic | 08:31 |
| lifeless | spiv: won't the test suite, on windows, still use pipes ? | 08:31 |
| spiv | EINTR is irrelevant on windows, windows doesn't have it. | 08:32 |
| lifeless | ok | 08:32 |
| vila | bbib | 08:32 |
| lifeless | in which case, with all the questions I've asked, if you make the docs shiny and NEWS, +1 | 08:32 |
| spiv | (Also, we've been forced to fix EINTR the crude way: by not using signal handlers, so it's a bit academic anyhow :/) | 08:33 |
| === beaumonta is now known as abeaumont_ | ||
| poolie | hi vila, lifeless, spiv | 08:51 |
| vila | poolie: hi | 08:51 |
| lifeless | hi poolie | 08:54 |
| lifeless | poolie: I have good news and bad news for you | 08:54 |
| lifeless | the good news is that the pqm test run successfully formatted and collated a broken test | 08:54 |
| lifeless | the bad news is that it had a 43M attachment and choked on the MTA limit on the box. | 08:54 |
| lifeless | poolie: I'd like to just raise the limit and supply a small follow on patch to gzip the stdout and stderr logs | 08:55 |
| lifeless | poolie: but if you'd prefer I can also turn subunit off in bzr trunk, as agreed. | 08:55 |
| poolie | hi there | 08:56 |
| poolie | thanks for letting me know | 08:56 |
| poolie | i wonder if those large attachments will also be annoying to recipients of failing test runs? | 08:56 |
| poolie | that's quite a lot to download on a pre-adsl2 link | 08:56 |
| poolie | but i'm ok to persist until it starts actually hurting someone | 08:57 |
| spiv | You have to give spamassassin and amavis something to do ;) | 08:57 |
| poolie | lifeless: i wonder if we should eventually perhaps strip non-failing test output? | 08:57 |
| lifeless | poolie: We used too | 08:57 |
| lifeless | poolie: its a contibuting factor to the test results being sometimes rather useless | 08:57 |
| poolie | stripping them is, or leaving them in is? | 08:58 |
| lifeless | I think its safer, given the requirements, to include everything | 08:58 |
| lifeless | poolie: stripping them - the failure mode can include stripping too much | 08:58 |
| lifeless | poolie: the body of the sent email has pyunit formatted errors | 08:58 |
| poolie | right | 08:58 |
| poolie | if eg there's extra output in the streaom | 08:58 |
| lifeless | poolie: so in principle you can just ignore the attached stdout file. | 08:58 |
| spiv | Not stripping them has the failure mode of being too large for someone to receive ;) | 08:58 |
| poolie | well, we can leave that for later | 08:58 |
| poolie | :) | 08:58 |
| poolie | vila did you see my pm? | 08:59 |
| lifeless | poolie: so tribunal | 08:59 |
| vila | I don't generally like partial outputs... on the other hand, I also generally *need* to reproduce locally... | 08:59 |
| poolie | hraspace is ruining my day | 08:59 |
| lifeless | poolie: looks like you hadn't pushed to trunk in a while, for the merge proposal you commented on the other day | 08:59 |
| lifeless | poolie: hraspace? allhands.c.c? | 08:59 |
| poolie | mm | 09:02 |
| poolie | and i have now pushed what you need? | 09:02 |
| poolie | or i still need to push? | 09:02 |
| lifeless | poolie: trunk appears broken - | 09:02 |
| lifeless | def on_test_started(self, test_id): | 09:02 |
| lifeless | + pass | 09:02 |
| lifeless | poolie: I think you have what I pushed, I'm doing double-checking now and will mark the mp as merged if it is the case. | 09:03 |
| poolie | oops | 09:03 |
| poolie | i may look at it after this | 09:03 |
| lifeless | poolie: so you know, I've been hitting up on loom most of the day | 09:04 |
| lifeless | mgz: I'll be very happy to fix | 09:05 |
| lifeless | mgz: testtools and unicode | 09:06 |
| mgz | I'm still not caught up on the log... | 09:07 |
| mgz | what's that re:? | 09:07 |
| mgz | (^I gzip testrun output, bzr has a lot of tests, and a lot of output) | 09:07 |
| poolie | lifeless: thanks | 09:10 |
| spiv | In NEWS, is the convention for (Some Person, #1234) to be on its own line, or at the end of the line if it fits on one line, or just wrapped any old how? | 09:12 |
| spiv | Or rather, the at the moment we seem to be a bit inconsistent, so what should the convention be? :) | 09:13 |
| poolie | it does seem inconsistent | 09:15 |
| lifeless | I vote on the end if it fits, otherwise a dedicated line. | 09:15 |
| poolie | avoiding wrapping within the names sounds good | 09:15 |
| lifeless | because | 09:15 |
| lifeless | xxxxxxxxxxxxxxx | 09:15 |
| lifeless | xx | 09:15 |
| lifeless | (xxxxx) | 09:15 |
| lifeless | looks really odd to me | 09:15 |
| spiv | Avoiding wrapping seems nice for helping grep. No-one (out of the three of us so far) have spoken in favour of always making a separate line, so I'll go with "on the end if it fits". | 09:17 |
| spiv | I suppose we should document that, although it's the sort of docs no-one would read. I guess the way to enforce that sort of thing is by adding a NEWS linter to the test suite... | 09:18 |
| spiv | (No, I'm not planning to shave that yak) | 09:18 |
| lifeless | spiv: why lint when you can merge. | 09:18 |
| spiv | lifeless: a merge hook that rewrites sections that we're conflicting in the first place isn't totally optimal either :/ | 09:19 |
| spiv | s/we're/weren't/ | 09:19 |
| lifeless | spiv: I think it would be beautiful :) | 09:20 |
| lifeless | vila - more loom love, for your enjoyment - https://code.edge.launchpad.net/~lifeless/bzr/loomsupport/+merge/27684 btw | 09:21 |
| poolie | spiv nobody will read the docs _except_ that in N months time it will make this conversation a bit shorter | 09:22 |
| lifeless | whats the bet its in there already | 09:22 |
| lifeless | no, its not | 09:23 |
| lifeless | I'll send a mp in tomorrow | 09:23 |
| poolie | for things where we don't care strongly but we do want it consistent i think it really helps | 09:24 |
| lifeless | poolie: mail limit for pqm is now raised to 50MB pending a gzip patch | 09:25 |
| poolie | k | 09:25 |
| poolie | this is an interesting case for supporting multiple mime encodings | 09:25 |
| poolie | you want it to be not too much bigger for text | 09:25 |
| lifeless | I'm going to see about getting that patch tucked away tonight | 09:25 |
| poolie | and not too bad for binaries | 09:25 |
| poolie | so perhaps having the option for either qp or base64 is good | 09:25 |
| poolie | which one? | 09:26 |
| lifeless | it might be nice for text to just be gzipped | 09:26 |
| poolie | the tribunal thing? | 09:26 |
| lifeless | gzip for pqm | 09:26 |
| lifeless | tribunal I'm nearly done checking | 09:26 |
| poolie | the problem in tribunal is probably that i was profiling by selectively cutting things out | 09:26 |
| vila | Oh, I thought the convention was to have the (author, #nnn) on its own line | 09:28 |
| vila | I'm ok for smart-wrapping | 09:28 |
| poolie | i think i dropped off | 09:32 |
| lifeless | 20:26 < poolie> the problem in tribunal is probably that i was profiling by selectively cutting things out | 09:33 |
| lifeless | 20:28 < vila> Oh, I thought the convention was to have the (author, #nnn) on its own line | 09:33 |
| lifeless | 20:28 < vila> I'm ok for smart-wrapping | 09:33 |
| lifeless | 20:31 -!- poolie [9665702c@canonical/launchpad/poolie] has quit [Ping timeout: 252 seconds] | 09:33 |
| lifeless | 20:32 -!- poolie [9665702c@canonical/launchpad/poolie] has joined #bzr | 09:33 |
| lifeless | 20:32 < poolie> i think i dropped off | 09:33 |
| vila | hmm, there is a good French joke about that but perfectly untranslatable :-/ | 09:40 |
| lifeless | ce la vie | 09:41 |
| vila | You'll have to trust me on this one :) | 09:41 |
| vila | c'est la vie :) | 09:41 |
| lifeless | gotcha | 09:41 |
| lifeless | I know you couldn't resist :) | 09:41 |
| poolie | ok good night all | 09:53 |
| lifeless | ciao | 09:54 |
| GaryvdM | lifeless: you said when reviewing my diff --using branch that test such as this one: http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/annotate/head:/bzrlib/tests/test_diff.py#L1310 should use sys.executable rather than 'python'. | 10:09 |
| GaryvdM | (may be it was jam - I can't remember | 10:09 |
| lifeless | both of us, I think | 10:10 |
| GaryvdM | lifeless: Would it be ok if i rather used 'echo' | 10:10 |
| GaryvdM | ? | 10:10 |
| lifeless | doesn't exist on windows | 10:10 |
| GaryvdM | I think it does. | 10:10 |
| lifeless | I don't understand something though, we have glue for all this in bzrlib.tests.TestCase already | 10:11 |
| lifeless | don't we ? | 10:11 |
| GaryvdM | lifeless: oh - ok - let me look at that. | 10:11 |
| GaryvdM | lifeless: I don't think so. | 10:20 |
| GaryvdM | lifeless: that test is trying to assert that a arbitrary diff command was executed, and that the file paths were passed to it, and that the output from the command is read. | 10:22 |
| GaryvdM | lifeless: In real life, the command maybe something like diff, or meld, but in the test, we can't rely on those being availible, so it currently uses python -c print... | 10:24 |
| GaryvdM | which could just be echo | 10:24 |
| GaryvdM | I'm going to dbl check on echo on windows | 10:25 |
| lifeless | GaryvdM: so | 10:25 |
| lifeless | we have the following things available | 10:25 |
| lifeless | : - os stuff | 10:25 |
| lifeless | - bzr itself, including test commands (we have some already) | 10:26 |
| lifeless | - mocking, were we pretend we ran something - see the fake gpg support, for instance | 10:26 |
| lifeless | I don't see a great deal of value in actually running something, for your test, if we have a known interface for doing it in general. | 10:27 |
| GaryvdM | lifeless: btw - this is an existing test that I did not write. I just copied the style of it for additional tests. | 10:28 |
| GaryvdM | (I would like to try make it better though) | 10:28 |
| lifeless | ok | 10:29 |
| lifeless | so perhaps: | 10:29 |
| lifeless | - make sure you don't increase whatever sin is there :) - refactor to use the existing style, good or bad, via a helper function rather than via copying | 10:29 |
| lifeless | then, we can decouple your test from improving things that were already there | 10:29 |
| lifeless | vila: did you propose my broken branch to pqm ? | 10:34 |
| vila | lifeless: yes, to test mail | 10:37 |
| lifeless | kk | 10:37 |
| vila | lifeless: is that a problem ? | 10:37 |
| vila | kk | 10:37 |
| vila | :) | 10:37 |
| lifeless | I thought PQM had done something very naughty | 10:37 |
| vila | lifeless: sorry about that, it's only after sending it that I saw you just did | 10:38 |
| lifeless | de nada, only way for you to find out | 10:40 |
| spiv | GaryvdM: there's no "echo" executable on windows -- but it is a builtin command in cmd.exe (and command.com for that matter) | 10:59 |
| GaryvdM | spiv: oh - I see | 10:59 |
| spiv | (or at least, that used to be the case when I used windows) | 10:59 |
| spiv | So I'd expect that subprocess.Popen(['echo', 'foo'], shell=False) would fail | 11:00 |
| kostja_osipov | hello. | 11:02 |
| kostja_osipov | does bzr gtk tools such as gcommit work on mac? | 11:02 |
| kostja_osipov | it says here | 11:02 |
| kostja_osipov | bzr: ERROR: PyGTK not installed. | 11:02 |
| vila | lifeless: bzrlib.version_info should be (2, 2, 0, 'beta', 4) not (2, 2, 0, 'beta', 3) right ? | 11:03 |
| kostja_osipov | even though it is installed (with fink) | 11:03 |
| kostja_osipov | is there some sort of troubleshooting faq? | 11:03 |
| jszakmeister | kostja_osipov: fink installs it's own version of python. :-( | 11:03 |
| lifeless | vila: when we release it, yes. | 11:03 |
| lifeless | vila: is it released yet ? | 11:03 |
| kostja_osipov | jszakmeister: so how does one fix it? | 11:03 |
| vila | no, but trunk never is | 11:04 |
| vila | lifeless: no, but trunk never is | 11:04 |
| lifeless | thats right | 11:04 |
| jszakmeister | kostja_osipov: I'm not sure. But I bet it's a lot of work. Have you tried using QBzr? | 11:04 |
| jszakmeister | It works everywhere. | 11:04 |
| kostja_osipov | jszakmeister: qbzr doesn't support per-file comments, a feature we are using here at mysql | 11:04 |
| jszakmeister | :-( | 11:05 |
| jszakmeister | I wonder if there are prebuilt libs out there... | 11:06 |
| lifeless | kostja_osipov: probably your python for bzr and your python for fink are different | 11:06 |
| kostja_osipov | lifeless, jszakmeister thanks, I got it | 11:07 |
| vila | lifeless: eerk, it should even be (2, 2, 0, 'dev', 5) i.e not beta but dev, dunno for 5 though | 11:07 |
| jszakmeister | kostja_osipov: just used the fink python version, right? | 11:08 |
| lifeless | vila: huh ? | 11:08 |
| lifeless | vila: put down whatever you are smoking. | 11:08 |
| vila | in lp:bzr we use 'dev' not 'beta' right ? | 11:08 |
| lifeless | vila: no | 11:08 |
| lifeless | vila: read releasing.txt | 11:08 |
| lifeless | vila: trunk is absolutely correct | 11:09 |
| lifeless | vila: nothing needs changing, its as per poolie's desire with the beta release approach | 11:09 |
| vila | how do we distinguish between 2.2b3 released and trunk ? | 11:09 |
| lifeless | vila: we don't | 11:09 |
| vila | meh | 11:09 |
| lifeless | vila: I noticed this when I did the release a couple weeks back | 11:10 |
| lifeless | vila: I doesn't seem like a big issue given we're not treating them as we used to treat releases. | 11:10 |
| lifeless | vila: although opinions on that might vary :P | 11:10 |
| * vila scratches head and goes on... | 11:11 | |
| lifeless | vila: whats caught your eye ? | 11:11 |
| vila | lifeless: I was merging 2.0 -> 2.1 -> trunk | 11:11 |
| lifeless | did we sort out what we were doing with NEWS? | 11:11 |
| vila | forgetting 2.2 by the way | 11:12 |
| vila | well, the fact that we didn't release 2.0.6 makes things a bit more blurry as it's now unclear what was included in 2.1.2... | 11:12 |
| lifeless | vila: I think its clear, with what I did | 11:13 |
| lifeless | it wouldn't be with the other proposed approach. | 11:13 |
| lifeless | [which is why I don't like the other way :)] | 11:13 |
| vila | hold on, I may have missed what you did :) | 11:13 |
| lifeless | vila: I duplicated entries | 11:13 |
| vila | Did you duplicate the NEWS entries ? | 11:13 |
| vila | hmm | 11:13 |
| vila | so I should do the same when merging up them | 11:14 |
| lifeless | well | 11:14 |
| vila | then | 11:14 |
| lifeless | if there is disagreement we should resolve it | 11:14 |
| lifeless | all I'm saying is that I felt happy with what I did | 11:14 |
| lifeless | as it meant you don't need to chase pointers or worry about coherency if (say) 2.0.x (unreleased) gets released etc | 11:15 |
| vila | I don't really disagree, I should re-read releasing.txt, it looks like I've missed this detail | 11:15 |
| vila | yeah, that's the first time we released 2.1.x without 2.0.y :) | 11:15 |
| vila | lifeless: I still had in mind the 'merge 2.0 into 2.1 into bzr.dev freely' policy | 11:16 |
| lifeless | vila: right, which I've been doing | 11:17 |
| lifeless | vila: I don't think that that policy has changed, has it ? | 11:17 |
| vila | well, we need to duplicate the NEWS entries then or the RM will need to check and sort things out which would be a nightmare | 11:18 |
| vila | lifeless: I don't want to sound picky, but: releasing.txt doesn't mention 'dev', but the comment in bzrlib.__init__ says: "Additionally we use a # releaselevel of 'dev' for unreleased under-development code." | 11:22 |
| vila | lifeless: Also NEWS mentions 2.2b4 but we still have (2, 2, 0, 'beta' , *3*) in version_info | 11:22 |
| lifeless | not picky at all | 11:23 |
| lifeless | the former is a comment from before things changed; annotate to see :) | 11:23 |
| vila | bah, releasing.txt mentions 'dev' when *opening* for a new release :-/ | 11:24 |
| lifeless | the latter is as per the releasing.txt, which while I tweaked I didn't change process at all | 11:24 |
| vila | sure not throwing stones, but this sounds like a good occasion to clarify things | 11:24 |
| lifeless | vila: however there is every chance I got it wrong, because releasing.txt was really confusing.txt when I started the release process. | 11:24 |
| lifeless | vila: so if it should still be 'dev' according to releasing.txt, thats fine - but its not clear to me whether that is 'starting a new series' or 'starting a new point release' | 11:25 |
| lifeless | vila: and new point releases - going back to dev would be wrong sorting wise | 11:25 |
| lifeless | wouldn't it ? | 11:25 |
| vila | oh my versions sorting... vade retro satanas | 11:26 |
| lifeless | vila: though I'm not looking at the tuple right now, so could be misremembering the order of the 'dev' string in it | 11:26 |
| lifeless | vila: now, for further entertainment, as per lp-code - pqm has been zapped | 11:27 |
| lifeless | vila: I've just sent another failure test. | 11:27 |
| lifeless | vila: I'm going to stay up long enough to see whether it goes boom or wins | 11:27 |
| lifeless | vila: but things will need resubmitted after that | 11:27 |
| mgz | okay, finally caught up with log | 11:28 |
| mgz | lots of windows questions, but they all got answered! crazy. | 11:28 |
| mgz | lifeless: I'm not sure what you meant specifically earlier with: | 11:28 |
| mgz | <lifeless> mgz: I'll be very happy to fix | 11:28 |
| mgz | <lifeless> mgz: testtools and unicode | 11:28 |
| lifeless | mgz: your patch. | 11:29 |
| lifeless | I wants. | 11:29 |
| vila | lifeless: so my submission was zapped, no need to chase if the mail was refused or not (irrelevant now anyway if your gzip patch works) | 11:29 |
| mgz | ah, right, I'll see if I can resubmit something landable today | 11:29 |
| lifeless | vila: right | 11:29 |
| lifeless | mgz: what prompted that was, lets see | 11:29 |
| vila | lifeless: so let me know where you're at before you quit, thks in advance :) | 11:29 |
| lifeless | ====================================================================== | 11:29 |
| lifeless | FAIL: bzrlib.tests.test_setup.TestSetup.test_build_and_install | 11:29 |
| lifeless | ---------------------------------------------------------------------- | 11:29 |
| lifeless | 'ascii' codec can't encode characters in position 33548-33550: ordinal not in range(128) | 11:29 |
| lifeless | vila: naturally | 11:29 |
| lifeless | vila: I'm going slightly mad o/~ | 11:29 |
| mgz | ehe, woho! I see. | 11:30 |
| mgz | wonder if testtools could grow some nicer UnicodeError handling as well, might be worth doing later | 11:31 |
| mgz | okay, my remaining todo list has: | 11:31 |
| mgz | * kill mbcs | 11:31 |
| mgz | * isbaseexception | 11:31 |
| mgz | I can probably do those before I go out around lunchtime | 11:31 |
| lifeless | \o/ | 11:32 |
| mgz | I'll count * fix unicode wrapper as done, even though it probably needs looking at in review | 11:32 |
| mgz | urk, fencepost error, one hour less before I need to go than I thought, will have to wait till the afternoon to finish | 11:50 |
| lifeless | no worries | 11:52 |
| CaMason | Hi guys. I have a revision (about 5 commits ago) but I want to reverse the changes made at that revision. How can I do this? | 12:14 |
| jpds | CaMason: bzr uncommit && bzr revert [--no-backup] | 12:15 |
| CaMason | how will that remove the changes from 5 revisions ago? | 12:16 |
| jpds | Oh, sorry; I read '5 minutes ago'. | 12:16 |
| CaMason | ah seems like I need reverse cherrypicking | 12:17 |
| LeoNerd | Hrm.. I think there's a bug in bzr-svn currently. If I modify two files, "bzr st" and "svn st" can both see this. If I use bzr ci to commit just one of the files, suddenly both tools lose the ability to see the diff on the other file. bzr st, bzr diff, svn st, svn diff; none of them notice it; even though by manual diff I can see there is a difference | 12:19 |
| spiv | CaMason: bzr merge -r -5..-6 (then bzr commit, if you want) | 12:21 |
| lifeless | LeoNerd: file a bug pkease, it sounds plausble | 12:21 |
| CaMason | spiv, yup just did that :) Thanks | 12:21 |
| CaMason | well similar... bzr merge -r 5..4 | 12:21 |
| spiv | Great :) | 12:22 |
| LeoNerd | lifeless: OK... I've also found a "workaround of sorts" | 12:22 |
| === Meths_ is now known as Meths | ||
| LeoNerd | lifeless: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=586096 | 12:38 |
| ubot5 | Debian bug 586096 in bzr-svn "bzr-svn: Partial commit breaks status/diff of uncommitted files" [Normal,Open] | 12:38 |
| ciss_ | hi, i'm currently trying to sync a local repo with an older version on a server. problem is, while the server version crlf line endings, the local files all have lf, making a reliable sync close to impossible. what steps are necessary to make bazaar convert the current revision of the local files to crlf? | 12:44 |
| ciss_ | "local repo" = local revision | 12:45 |
| ciss_ | the server files aren't versioned | 12:45 |
| ciss_ | awfully sorry, i meant to say "... while the server version _has_ crlf line endings ..." | 12:46 |
| lifeless | vila: ping | 13:04 |
| vila | lifeless: pong | 13:09 |
| lifeless | vila: status | 13:09 |
| lifeless | of pqm | 13:09 |
| lifeless | * the gzip patch worked but | 13:09 |
| lifeless | * mail is 7bit | 13:09 |
| lifeless | * new patch deployed with base64 encoding as well | 13:09 |
| lifeless | vila: can you please: | 13:10 |
| lifeless | * test that it works (e.g. with my broken branch) | 13:10 |
| lifeless | * specifically that the pqm-stdout.gz file you can be gunzip'd successfully | 13:10 |
| lifeless | * and piped through subunit-stats happily | 13:10 |
| lifeless | if it can't - or put another way, if you don't get a useful diagnostic back from the error, please ask mthaddon to pull --overwrite lp:pqm | 13:11 |
| lifeless | however | 13:11 |
| vila | yup, broken submission sent, I'll wipe my patch on subunit to test | 13:11 |
| lifeless | the body of the email had a fine error in it for me - after all the skips | 13:11 |
| lifeless | so even though the gzip file was busted, I could diagnose ok | 13:11 |
| lifeless | Its my fond hope that nothing will be wrong at all. | 13:12 |
| lifeless | I'll sync() with you in ~ 7 hours. Thanks! | 13:12 |
| * vila crosses lifeless fingers | 13:12 | |
| lifeless | vila: it should be ok; it passed unit tests, does what the code jml used does just less pre-canned (so does not need file on disk) and the formatting of the error into the body worked ok for me. | 13:15 |
| lifeless | so all in all I think its in a good place. | 13:15 |
| spiv | lifeless: sounds good! | 13:15 |
| lifeless | spiv: \o/ | 13:16 |
| lifeless | spiv: it was particularly fun seeing | 13:16 |
| lifeless | en_G:__a* [.utf8-nodocs] ETror 1 | 13:16 |
| lifeless | pre-t] Rit hook faes)d with UTrorot]de -253 at W)d Jun 16 12:49:05 2010 | 13:16 |
| lifeless | come out of gzip :) | 13:16 |
| vila | lifeless: :) | 13:17 |
| vila | lifeless: meh, bzr diff --old lp:bzr/2.2/2.2b2 --new lp:bzr/2.2/2.2b3 outputs nothing, did you forget to push ? | 13:28 |
| vila | lifeless: some goes for bzr diff --old lp:bzr/2.2 --new lp:bzr/2.2/2.2b2 and bzr diff --old lp:bzr/2.2 --new lp:bzr/2.2/2.2b3 | 13:29 |
| lifeless | vila: I didn't touch 2.2 | 13:29 |
| lifeless | vila: 2.0, 2.1, trunk | 13:29 |
| lifeless | because 2.2 isn't interesting till rc's, AIUI | 13:29 |
| vila | you didn't release 2.2b3 ? | 13:29 |
| lifeless | vila: I did, off trunk. | 13:29 |
| vila | hmm, so we don't have a valid lp:bzr/2.2/2.2b3, can live with that, I will merge 2.1 directly to trunk then | 13:30 |
| vila | lifeless: I got weird conflicts until I realized the 2.2 branch hasn't been updated | 13:31 |
| lifeless | vila: It was my [incorrect?] understanding that that branch was vestigial until rcx | 13:32 |
| vila | lifeless: well, my feeling is the same than for the 'dev' in version_info: how do we know what version was used (in a bug report) and how to we reproduce, more specifically I ran into the issue because I use local mirrors of lp:bzr/x.y and use them for my integration branches... | 13:37 |
| vila | s/how to/how do/ | 13:37 |
| lifeless | I may well have done the wrong thing | 13:37 |
| vila | nothing serious, but we may as well clarify, I'll try to summarize in a mp | 13:40 |
| === idart_ is now known as idart | ||
| mthaddon | vila: we seem to have come across a problem (rob thinks it's a bzr 1.17 bug that's manifesting in pqm) - https://pastebin.canonical.com/33521/ - any ideas if we should just bzr pull --overwrite the local version with the version on LP? | 13:54 |
| vila | mthaddon: it depends on the environment: is this bzr specific to a given project ? Are there plugins that may need to be updated to ? | 13:56 |
| mthaddon | vila: it's currently using bzr 2.1.3dev (recent update) | 13:57 |
| vila | mthaddon: plugins aside, it's generally safe to upgrade bzr to stable releases, the latest being 2.1.2 | 13:58 |
| vila | mthaddon: meh, 2.1.3dev ? What's that ? lp:bzr/2.1 ? | 13:58 |
| lifeless | vila: yes it is | 14:00 |
| lifeless | vila: easiest way to get it, and no important changes | 14:00 |
| lifeless | vila: the thing being pulled would be the funky branch, not the bzr version, for clairty | 14:01 |
| lifeless | vila: I'm off to bed, gl | 14:01 |
| vila | lifeless: ok, sleep well | 14:01 |
| vila | mthaddon: the 'bzr%2Bssh/trunk-2a' looks funny, do you have a path like that locally ? | 14:02 |
| mthaddon | vila: it's "bzr+ssh" locally | 14:03 |
| vila | mthaddon: my question is whether it's really the path you want to use or some url (point to a smart server) badly interpreted as referring to a local file | 14:04 |
| vila | s/point/pointing/ | 14:04 |
| mthaddon | vila: we just define workdir=/srv/balleny.canonical.com/chroot-ubunet/home/pqm/pqm-ubunet-workdir - pqm does the rest - but it actually seems to be processing for the moment, so not sure if it was a transient error | 14:05 |
| vila | mthaddon: maybe a typo in the offending submission ? | 14:06 |
| mthaddon | don't think so, but it's possible | 14:07 |
| lifeless | vila: the urls are irrelevant | 14:07 |
| lifeless | vila: sorry, I really need to crash but you're chasing a ghost | 14:08 |
| lifeless | pqm has url escaped stuff to make a file path | 14:08 |
| vila | ok | 14:08 |
| lifeless | without being subject to .. hacks or other noise | 14:08 |
| lifeless | focus on the exception | 14:08 |
| vila | mthaddon: what are the branches involved here ? | 14:08 |
| lifeless | vila: its the target branch pqm was checking out to | 14:09 |
| lifeless | suspected | 14:10 |
| lifeless | possibly the whole thing is a random glitch caused by a bzr version upgrade while the old pqm version was working | 14:10 |
| lifeless | and we can totally ignore | 14:10 |
| lifeless | OTOH possibly its real | 14:10 |
| vila | lifeless: but I still have no idea about *which* branches are involved ! Nor even which project it is we are talking about... | 14:11 |
| lifeless | I'm suggesting checking known spurious reports of this error - we had a bug like that, and also validating that the master branches can be cleanly branched to e.g. /tmp | 14:11 |
| vila | on my keyboard batteries are low !!! | 14:11 |
| lifeless | vila: do you need to know to examine an exception like this? | 14:11 |
| vila | new batteries | 14:14 |
| vila | lifeless: Well, I need to know what bzr version is used and which branches are involved :) Or nothing if it's transient | 14:15 |
| lifeless | mthaddon: how long ago was 13:20 bst ? | 14:15 |
| lifeless | mthaddon: or utc, or whatever balleny is on | 14:16 |
| parthm | if i have a RevisionSpec or rev_id string ... what would be a good way to get a Revision object? i want get rev.parent_ids. | 14:16 |
| mthaddon | lifeless: 40 mins | 14:16 |
| mthaddon | well, 35 | 14:16 |
| lifeless | mthaddon: so, the bzrlib change was 6 hours or so back | 14:16 |
| lifeless | mthaddon: I don't think its likely that the u1 pqm was uninterruptedly busy for that long ? | 14:17 |
| mthaddon | lifeless: this submission by beuno was the first in 15 hours | 14:18 |
| lifeless | ok | 14:18 |
| lifeless | vila: 2.1.3 from lp:2.1 | 14:18 |
| lifeless | lp:bzr/2.1 | 14:18 |
| lifeless | vila: that was the only version involved that we know of | 14:18 |
| lifeless | I really have to sleep 1:20am | 14:19 |
| lifeless | goodluck | 14:19 |
| lifeless | note that the branch no longer exists | 14:19 |
| lifeless | its in the pqm work area, so was rm -rf'd about 39m back | 14:19 |
| lifeless | but the source branches on the local disk and on lp do exist | 14:19 |
| lifeless | and tom can check/branch test etc them for you | 14:20 |
| lifeless | using either the system bzr or the bzr pqm uses. | 14:20 |
| lifeless | ciao | 14:20 |
| * lifeless crashes | 14:20 | |
| vila | mthaddon: can you find the associated traceback in some .bzr.log ? | 14:21 |
| vila | mtaylor: trying to rule out some more ghosts: the local repository is not shared between several projects or pqm instances right ? | 14:23 |
| mthaddon | nope, the on disk location is only used by this pqm instance | 14:24 |
| parthm | nevermind. got it. repository.get_revision. | 14:24 |
| vila | parthm: hi ! | 14:24 |
| parthm | vila: hi :) | 14:25 |
| vila | mtaylor: sorry, xchat tricked me :( | 14:25 |
| vila | mthaddon: so, backtrace and branches or are you waiting to see if it was transient ? | 14:26 |
| mthaddon | vila: still waiting to see if it was transient - thx for the help so far, will let you know if it's still a problem | 14:27 |
| lifeless | vila: please look back at recent bugs | 14:28 |
| lifeless | I'm *sure* there was a bug where we spuriously said NoSuchRevision on new pack files or something like that | 14:29 |
| lifeless | I have a nasty suspicion we only fixed it in 2.2 | 14:29 |
| lifeless | and if thats the case bzr and u1 are going to be hitting it a lot on pqm | 14:29 |
| vila | overlapping auto-packs ? | 14:32 |
| vila | the other ones I've found are about upgrading | 14:33 |
| ciss_ | is there a safe way (without committing) to check if bazaar regards the eol rules defined in ~/.bazaar/rules? | 15:56 |
| jelmer | ciss_: bzr cat --filters I think | 16:01 |
| jam | morning all | 16:04 |
| ciss_ | jelmer, thanks, works | 16:08 |
| ciss_ | i have a branch that uses lf for line endings. i've added the rule "crlf-with-crlf-in-repo". how can i convert all files to crlf? | 16:11 |
| jelmer | hi jam | 16:13 |
| jelmer | ciss_: bzr revert perhaps? | 16:13 |
| jelmer | ciss_: (no idea, just guessing) | 16:13 |
| jam | ciss_: 'bzr remove-tree ; bzr co .' ? | 16:14 |
| ciss_ | thanks for the suggestions, i used an export (i need to sync the branch with unversioned files from a production server) | 16:27 |
| ciss_ | how do i remove all *.pl files from versioning, no matter what sub directory they're in? i tried "./**/*.pl" and "*.pl", but neither worked | 16:47 |
| === davidstrauss_ is now known as davidstrauss | ||
| glen__ | hello, i'm trying to bzr add a bzr repository within another repository | 17:33 |
| jelmer | glen__: I don't think that's possible at the moment | 17:34 |
| jelmer | glen__: at least, you can't version the '.bzr' directory | 17:34 |
| glen__ | when i run bzr add the repository, nothing is output and after that bzr stat still tells me the repository directory is unknown | 17:34 |
| glen__ | ah, thanks jelmer, i didn't realise that | 17:34 |
| glen__ | i'll remove .bzr and try again, i've got the other repository versioned elsewhere | 17:34 |
| jelmer | glen__: ideally it would add a reference to the other branch - the support for that is partially implemented, but not finished (hence the strange error about it changing to a directory) | 17:34 |
| jelmer | glen__: alternatively you can use "bzr join" | 17:35 |
| jelmer | that will join the two branches while keeping all the history they had when they were still independent branches | 17:35 |
| GaryvdM | jam: I'm finally looking at my diff_using_gui branch. I've fixed some of the problems with the tests. I want to now add a registry of good defaults. | 17:45 |
| GaryvdM | jam: Do I need to be using something like bzrlib.registry, or can I just put them in a dict? | 17:46 |
| jam | GaryvdM: diff_using_gui? You mean external diff programs? | 17:46 |
| jam | You can certainly use a dict, bzrlib.registry is mostly about having key:object pairs | 17:46 |
| jam | and allows stuff like lazy definitions of the objcets | 17:46 |
| jam | objects | 17:46 |
| GaryvdM | jam: which I don't really need. | 17:46 |
| jam | GaryvdM: if you know your 'values' are always going to be cheap, then you can probably just use a dict | 17:47 |
| jam | the main things you'll want to do is make it somewhere that other people can get to it | 17:47 |
| jam | if you want them to be able to extend it easily | 17:47 |
| GaryvdM | jam: ok thanks. | 17:47 |
| jam | (eg, don't put it as a dict inside of a function, make it a Module level or Class attribute level dict) | 17:48 |
| GaryvdM | jam: ok | 17:48 |
| GaryvdM | jam: I plan to also all for config file entries | 17:48 |
| GaryvdM | and a Module level dict will allow for plugins to add p | 17:49 |
| jam | GaryvdM: right. You might also want to consider where you put that dict | 17:49 |
| jam | so that plugins can update it without having to import your whole codebase | 17:50 |
| jam | (see the current discussion about Hooks in bzrlib) | 17:50 |
| GaryvdM | jam: yes | 17:50 |
| glen__ | jelmer: thanks jelmer, i'll remember bzr join in future :) | 17:55 |
| GaryvdM | jam: Thanks for the pointers. It's allways good to discuss be coding. :-) | 17:55 |
| GaryvdM | *before | 17:55 |
| === beuno is now known as beuno-lunch | ||
| === beuno-lunch is now known as beuno | ||
| lifeless | good morning | 20:42 |
| lifeless | vila: hi | 20:42 |
| vila | lifeless: I got no mail at all for the broken submission :-/ | 20:46 |
| vila | lifeless: But I got success mails though | 20:47 |
| lifeless | vila: did the pqm change get rolled back? | 20:47 |
| lifeless | I'll try sending error through again | 20:48 |
| vila | lifeless: not that I know of, since they successful submissions worked I just keep using it | 20:48 |
| bcurtiswx | any reason why i can't bzr branch lp:empathy ? | 21:31 |
| lifeless | no, its just there to tease you | 21:31 |
| bcurtiswx | i get a connection error | 21:31 |
| lifeless | bcurtiswx: :) | 21:31 |
| bcurtiswx | "unexpected end of message" | 21:31 |
| lifeless | bcurtiswx: that sounds like a ssh login error | 21:32 |
| lifeless | bcurtiswx: what happens if you 'ssh yourusername@bazaar.launchpad.net' | 21:32 |
| bcurtiswx | permission denied (publickey) | 21:33 |
| bcurtiswx | need to update my ssh key... maybe? | 21:34 |
| lifeless | if you've changed it :) | 21:34 |
| bcurtiswx | i am using my laptop, so i just need to add this one.. have my desktop one.. that would be it | 21:34 |
| lifeless | or | 21:35 |
| lifeless | you could have the same private key on both | 21:35 |
| lifeless | whatever works for you | 21:35 |
| bcurtiswx | yeah i could i guess | 21:35 |
| lifeless | vila: still around ? | 22:15 |
| lifeless | vila: if so, do you happen to know a pattern like (loom Loom switch) that will get all the tests loom affects with bzr ? | 22:15 |
| lifeless | poolie: I realise you're on the phone; queue this for when you're not. Is there a bash/zsh way to say 'the value of variable X if its set, otherwise LITERAL' ? | 22:56 |
| lifeless | I don't spend enough time *in* my shell to remember such things | 22:56 |
| lifeless | or a ternary operator would do | 22:57 |
| fullermd | I think there is for both... | 22:58 |
| lifeless | fullermd: I have vague memories | 22:59 |
| lifeless | but no details | 22:59 |
| fullermd | Looking around some sh scripts I see some stuff like | 23:00 |
| fullermd | : ${clamav_clamd_enable="NO"} | 23:00 |
| * fullermd glances at the man... | 23:00 | |
| fullermd | ${parameter:-word} Use Default Values. If parameter is unset or null, the expansion of word is substituted; otherwise, the value of parameter is substituted. | 23:01 |
| lifeless | fullermd: so a ternary operator would be better | 23:01 |
| lifeless | I want to say | 23:01 |
| lifeless | PYTHONPATH=$PYTHONPATH *or* don't supply PYTHONPATH= | 23:01 |
| fullermd | Well, the above could give you an empty string. Since it works on an _expansion_ rather than a literal value, it's possible you could somehow finagle an unset in... | 23:04 |
| poolie | lifeless, man zshparam | 23:04 |
| poolie | there is one but i don't recall off hand | 23:04 |
| lifeless | thanks | 23:04 |
| fullermd | You could use short circuiting. | 23:05 |
| fullermd | $PYTHONPATH && PYTHONPATH=$PYTHONPATH or something | 23:05 |
| fullermd | Repetitition is ugly though. | 23:05 |
| lifeless | fullermd: also fragile when constructing a command string to execute :) | 23:05 |
| lifeless | I suspect it would run '&& bzr' | 23:06 |
| lifeless | sorry, '&& PYTHONPATH= bzr' | 23:06 |
| fullermd | Well, we want bzr run as many places as possible, right? :p | 23:06 |
| poolie | it's like ${PYTHONPATH:/usr/lib/python} | 23:06 |
| lifeless | thanks guys, thats enough for me to go on | 23:06 |
| lifeless | I'll stash it in a bug | 23:06 |
| poolie | ${name-otherwise} | 23:07 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!