[00:00] poolie, I'm working on an 'easy' bug (patch pilot program), and I've got a question for you regarding the approach to take to set up a test for this change. The bug is 498409, (https://bugs.launchpad.net/bzr/+bug/498409) Do you, by any chance, have some time? [00:00] Launchpad bug 498409 in bzr "bzr revert takes a branch lock" [Medium,In progress] [00:00] hi dvheumen [00:00] sure, happy to [00:00] * poolie looks [00:01] i just finished a call, i'll get some coffee and be back in a minute [00:01] k [00:01] tnx [00:02] okay, well, fixing the bug seemed pretty simple, and jelmer had some said it seemed reasonable to him, so that gives me some confidence. He also gave me a hint on how to approach this particular type of test, which helped greatly. But it seems I've got some sort of a special case (or lack of understanding of python code, which is more or less a given :P) [00:09] This is what I have at the moment (scrambled together) as a test: http://paste.ubuntu.com/391380/ . I know: 1. that this doesn't work, 2. I've chosen the wrong test file for this particular test. 3. I didn't finish the test exactly, but I wanted to compare the content self.locks. But I think that this approach, using this lock helper, doesn't work since cmd_revert creates its own branch instance. And that's where I'm currently stuck :P [00:10] * I wanted to compare the locks history, although now I'm not sure if that was stored in self.locks, but you get the idea [00:12] hi [00:12] so, right, actually fixing the bug will be pretty trivial [00:12] Oh, btw, I do think there's a way to work around this, by adding an optional parameter to cmd_revert's run-method in which you can pass on the branch. But I don't like that approach [00:12] one line probably [00:13] poolie, that's the easy part :P [00:13] I'll get the diff for you [00:14] so the choice of test location should probably be guided by whether the fix is in cmd_revert or elsewhere [00:14] http://bazaar.launchpad.net/~danny.vanheumen/bzr/bug-498409-bzr-revert-takes-a-branch-lock/revision/4740 [00:14] if it's changed in branch.py, per_branch would be an appropriate place to test it [00:14] i'm glad you asked for help btw [00:15] it's changed in builtins.py, so the preferred location seemed to be: tests/commands/test_revert.py probably [00:15] right [00:15] although that one doesn't exist, at least not in the 2.0 branch [00:15] so i think there is test framework support to record all locks that are taken? [00:15] poolie, right, found that one too [00:16] but it requires you to use a branch instance that is wrapped in this helper that records the history [00:16] not all conceptual locks, but all actual locks, yes. [00:16] dvheumen: hmm, I think you're missing the lock tracker [00:16] i thought there was a way to do it globally [00:17] but this may be only in my head [00:17] look at bzrlib.tests.TestCase._track_locks [00:17] thats uses the lock hooks to check some test characteristics - that locks are matched during tests [00:18] poolie, I've been using the tests in tests/per_branch/test_locking.py [00:18] a single test can hook into Lock.hooks additionally to get extra callbacks [00:20] lifeless, okay, this is interesting. I hadn't seen that yet. [00:20] dvheumen: what he said is correct: you should be able to just do the test then inspect _lock_actions i think [00:20] poolie, do you by any chance know if they are recorded by default, or should I activate this in some way? [00:21] it looks like it's on by defaulct [00:21] okay, thanks, in that case I'll give it a try (tomorrow) [00:21] we should add this to the testing guide [00:22] +1 :P [00:27] poolie, btw, I'm glad you're helping. I've wanted to dive into python for some time, and this provides some goals to tackle :) [00:27] if there are any bugs tagged 'easy' where it's not obvious how to begin, that's a meta-bug [00:27] ask someone here and they will add a comment explaining it [00:27] or tag it -easy :-) [00:30] okay, will do [00:36] hmmm ... maybe I'm asking too fast here, but ... it seems to me that _lock_actions only records lock + unlock, but does not make a distinction between tree, branch and repository locks [00:39] ow w8, I'm asking too fast. There is a distinction made. nevermind, I'll continue puzzling [00:45] if i were you i'd print the whole thing and look at what happens now [00:49] poolie, yeah, I know. I'm first setting up a test file at the correct location [00:50] btw, maybe it's something to add to the Bazaar Testing Guide documentation too, but I wasn't sure. I was running the selftest of a local 2.0 branch, but the plugins that are tested are taken from the system-wide library patch, and those are of version 2.1.0. Maybe it's a useful remark. [00:50] *path [00:52] hm, that's no good [00:52] these are system-wide plugins? [00:53] uhhmm.. well maybe you understand. I ran './bzr selftest' in a local branch in my home dir. But it tried to run tests for the bzr 2.1.0 that was installed with some plugins. One of the plugins wasn't supported in bzr < 2.1.0 so that's how I noticed the error [00:53] *when [00:54] too late, too many errors in my sentences :P [00:56] okay, now a decent clarification: the bzr core tests are ran without problems. But the tests for the plugins are taken from the system-wide library path [00:57] ok, i see what you mean [00:57] so './bzr selftest --no-plugins' works as expected, but without '--no-plugins' I immediately get the error that one of the plugins can not be loaded [00:57] right [00:57] so [00:57] probably it's a bug in that plugin if it doesn't cleanly declare that it can't work with bzr 2.0 [00:58] it may arguably be a bug in bzr too that it's even trying to load plugins if they're meant for 2.1 [00:58] iow if they're installed underneath the bzrlib directory of a different copy of bzr [00:58] no it's more that, if I just run the unit tests, especially as someone without experience with bzr (or python dev) it seems that the unit tests fail, but it's actually a plugin, not the code in the local branch [00:59] so my first idea was: how can the unit tests fail on a stable release?, while it's actually because of the plugins, not bzr itself [01:00] but it's pretty obvious now, so maybe it's not worth mentioning [01:00] what i think should be happening is: you get a message 'plugin blah needs bzr 2.1 and can't work with bzr2.0.4' [01:00] and then the tests pass [01:00] there are many cases where it is not this clean [01:00] we should fix them [01:00] poolie: dvheumen: you can also hook in explicitly. [01:00] because it can be disabled in the test suite, I wouldn't look at self._lock_actions; rather I'd hook it yourself [01:00] that way your setup doesn't get recorded, only the bit where you are doing the actual test. [01:01] how should he do that? [01:02] lifeless, hmmm, I think you're going too fast for me. Do you, by any chance, have an example I can look at? [01:02] # prep the test now [01:02] #... [01:02] locks_taken = [] [01:02] def gather_lock(result): locks_taken.append(result) [01:03] bzrlib.lock.Lock.hooks.install_named_hook('lock_acquired', gather_lock, None) [01:03] mm [01:03] self.run_bzr('revert') # or whatever you want your test code to be [01:03] it's a bit gross to write this into the particular test [01:03] self.assertLength(1, locks_taken) [01:03] dvheumen: rather than writing your own hook, maybe you should just look at _lock_actions before and after running revert [01:04] look at what has been added to it [01:04] poolie: if disable_lock_checks is disabled, that variable will be untouched always [01:04] poolie: its really not meant to be 'user' visible. [01:04] I don't think inspecting it from subclasses is a good idea. I think its a bad idea in fact. [01:04] ok [01:05] so perhaps we should add to the base class a similar or identical implementation that can be reused? [01:05] hm [01:05] in fact, the hook in this case can be: [01:05] locks_taken = [] [01:05] bzrlib.lock.Lock.hooks.install_named_hook('lock_acquired', locks_taken.append, None) [01:05] its two lines :) [01:06] or perhaps we should always record them, and just disable the actual _checks [01:06] the point is to make it easier for people like danny to write these tests [01:06] thats possible too [01:07] I do think we should make it easier for people like danny to write tests [01:07] lifeless, I can follow that, but do you know by any chance if I can make a distinction between read/write lock and tree/branch/repository level? Because I got this info, http://paste.ubuntu.com/391407/ and I only see a filename, but it's probably more [01:07] however, the _lock_actions is orthogonal infrastructure; it will have noise in it, and clearing it will make cleanups fail [01:08] dvheumen: only write locks will show up [01:08] aha, nice :) [01:09] dvheumen: its a bit dirty, but you can see the '/branch/' and '/repository/' in the paths. [01:09] G'day. Does any know if bzr-svn honours $http_proxy? [01:09] these locks are at the lowest layer; Repository and Branch build on top of them: the hook is reporting on things that don't know they are a branch/repository/etc [01:09] dcoles: it should [01:09] dcoles: I think it might [01:09] in pre-2.0 versions there are problems resolving lp: urls through proxies [01:10] lifeless, yeah I saw that, but it seems like a filename to me, with LockResult around it, I thought this might be some python notation of something like a data structure or so [01:10] poolie: Thanks. I'm using 2.1 at the moment, though can't seem to get it to work [01:10] it seems a bit tricky to just search for 'Repository' or 'Checkout' in this string [01:11] dvheumen: nope ;) its just that we've given things on disk reasonably sensible names. [01:11] poolie: Is there a way to enable debugging so I can see the requests made in the log? [01:11] dcoles: what in particular? and use -Dhttp [01:11] dvheumen: I think its a little tricky too - OTOH this is relatively simple; we can add a higher layer hook later (and i you wanted to do that I'd be happy to mentor) [01:11] actually those filenames do look pretty strange [01:12] why is there randomness directly appended to the name? [01:12] poolie: the first one is the metadir lock; called branch because of its starting back in 0.0.x; and this is the 'initialise data structure on disk' stage - the lockdirs may not actually exist yet. [01:12] poolie: Just like to be sure that I'm actually trying to use the HTTP server - at the moment I get DavRequestFailure - could not connect to HTTP server [01:13] poolie: Cheers - I'll take a look [01:13] lifeless: what i mean is, why is it .bzr/repository/lockyxb3rn4sw1oyx1jzkt45 not .bzr/repository/lock [01:13] is it still stuck with a temporary name used during creation? [01:14] it seems strange it would still have that name at least at the time it is released. [01:14] poolie: right, thats what I'm saying; I'm guessing it that its during the bootstrap of the lock. [01:14] poolie: and we want the release path to match, for the lock checking code [01:15] ah actually [01:15] so i propose to add http://paste.ubuntu.com/391411/ to the guide [01:15] poolie: return '%s(%s%s)' % (self.__class__.__name__, [01:15] self.lock_url, self.details) [01:15] looks like a bad repr or something [01:15] mm thought so [01:15] that will at least give people a clue [01:15] adding a better method +1 [01:15] poolie: I really don't like suggesting people look at _lock_actions [01:16] poolie: can we just given a two-line example of capturing to a list? [01:16] it's just going to encourage that to be copy-and-pasted [01:16] how about if we add a common method and call that? [01:17] sure, though that is more work than simply documenting what can be done today. [01:17] at two lines long I'm not personally concerned by copy and paste [01:17] or I could add it after I created a decent example? [01:17] anyhow - either is fine with me. Just poking at private stuff in the base class isn't. [01:17] I don't mind [01:18] * lifeless puts nose back into C code for indicator-sound [01:18] dvheumen: that'd be good [01:18] I'm already contacting you after I've written a (more or less) decent test :P [01:21] okay, created a TODO list. I'd like to do this in a decent way, so I can actually learn something, so I don't mind :) (Could take a couple of days though) [01:21] dvheumen: cool [01:21] lifeless, and you can expect a pm after I get how the lower level hook works ;) [01:22] Tnx guys, I'm gonna go find my bed, it's pretty late/early in the Netherlands [01:22] cheerio [01:22] dvheumen: just ask here - if I'm asleep or whatever I'll see it, but someone else may answer too [01:22] thanks for working on this [01:23] okay, no prob, bye === Adys is now known as Addybot === Addybot is now known as Adys [01:26] poolie: Looks like something isn't working for bzr-svn [01:27] `http_proxy=... bzr -Dhttp info http://bazaar.launchpad.net/~bzr/bzr/trunk` works [01:27] `http_proxy=... bzr -Dhttp info svn+https://clir.googlecode.com/svn/trunk` does not :S [01:28] I guess it depends on how bzr-svn's transport works [01:28] dcoles: maybe you need to set https_proxy? [01:30] poolie: If that works I'll feel very silly. :p [01:30] Uh.. no dice. *sigh* [01:32] hm [01:32] maybe this is a limit in the svn libraries we're calling into [01:32] anyhow you could file a bug [01:32] Just found https://answers.edge.launchpad.net/bzr-svn/+question/101399 [01:33] So yes, that might be the case [01:53] poolie: Ok, so the trick is you have to set it in ~/.subversion/servers [01:54] I understand why (since subversion ignores http_proxy, yay!), but a bit obscure to find [02:04] Aaaaand... awesome! That works. Thanks for your help poolie [02:04] great [02:06] dcoles: see bug 534794 [02:06] Launchpad bug 534794 in bzr-svn "svn connections should inherit proxy settings" [Low,Triaged] https://launchpad.net/bugs/534794 [02:12] Haha. I was about to complain that the FAQ entry for 'behind a proxy' was a bit poor, but then again jelmer only created it 31 mins ago :p [02:13] But yes. Look forward to that feature. [02:15] poolie: bug 534724 - I think you've sidetracked it [02:15] Launchpad bug 534724 in bzr "Large Repository.insert_stream_1.19 call when pushing new stacked branch with no new revisions" [Medium,Confirmed] https://launchpad.net/bugs/534724 [02:15] poolie: its not about new branches, its about trivial commits on existing branches [02:23] * wgrant was going to say that. [02:23] Although the initial push is slow too, that wasn't why I filed it. [02:34] wgrant: I think you added confusion by including a full test case :) [02:34] / example [02:35] lifeless: Yeah, I considered clarifying that after I filed it, but elected not to :/ === NyRy is now known as R-H [03:56] Just testing [03:56] Changed my nick but I thought it was harder than that [04:01] Who what? Changing your nick takes a /nick. [04:01] Aside from dealing with the registration, which is an additional 50 seconds of work (mostly reading NickServ's help) [04:15] how can i make a file the same as it is in lp:drupal ? my tree has a real lot of various changes so lp:drupal is not really a parent or anything... [04:16] is it a parent or not? [04:18] chx: bzr revert -r branch:lp:drupal FILENAMe [04:18] oh tricky [04:18] thanks [04:18] never knew the revisionspec could contain a branch: [04:18] one always learns [04:19] bzr help revisionspec [04:21] lifeless: bad news, the Drupal community decided on git :( I am using bzr at my workplace still. [04:26] :( [05:11] Peng: where do I issue the /nick command? Terminal, my IRC client? [05:12] your irc client [05:12] since it's an irc command [05:12] does anyone else see it or just the server? [05:12] we see the change of nick happen [05:12] we don't see this [05:13] /nick not_SamB [05:13] so if I type /msg nickserve register ... you don't see it? [05:14] indeed [05:14] which is good, or we'd know your password! [05:14] but you just saw it??? [05:14] nope! [05:14] I just know that that command takes a password [05:22] Cool, got it changed. Thanks [05:31] R-H: /parting the channel and /quitting the server are unnecessary, although it is nice to test that your auto-identify command still works. [05:32] Peng; Good to know. Just was exploring around the client really. [07:23] hi all ! [09:39] I'm doing the bazaar in 5 mins tutorial, and bzr diff isn't showing differences [09:40] codygman, the changes you have made since the last commit, are they made in committed files? [09:41] what does "bzr status" give [09:41] one second [09:41] i deleted it and redid the mini tutorial [09:44] donri: here you go [09:44] http://dpaste.com/169810/ [09:45] oh wait, you can only look at differences before commit then? [09:46] aha... how would you look at differences between commits? [09:46] bzr diff -rX..Y [09:46] or bzr diff -cN [09:46] as i suspected, you didn't make any changes *since the last commit* :) [09:47] that's the default for diff and status: changes made since committing [09:47] -rX..Y shows you the changes between revision X and revision Y, -cN shows you the changes made in revision N [09:47] rofl silly mistakes.. they always happen [09:48] codygman, "help" is a useful command also, e.g. bzr help diff [09:48] yeah.. i did that actually [09:48] reading man now [09:53] does bzr have a release folder, or a place where I can put only working versions? [09:53] maybe you want branches, or tags? [09:54] you mean once I verify that my changes didn't break anything, I can commit them to a certain brance? [09:54] branch* [09:56] branches are separate lines of development, usually sharing past commits; tags are named commits. (does these definitions apply to bazaar, people?) [09:56] codygman: in a lot of projects, each new feature / bug fix / whatever will be made on a branch, and then merged to "trunk" once it's ready (for example, the code might have to go through a code review process, or whatever) [09:57] alright.. that's what i'm wanting to do.. I don't want to upload module and brake everything.. lol [09:59] donri: yes [10:03] hi all [10:03] codygman, It's just social convention in Bazaar as well as SVN (I'm inferring that you are coming from SVN) [10:03] actually i'm coiming from no version control.. but have read more about SVN than others [10:03] what do you mean by uploading, though? [10:04] well after my module has been updated and I know it works [10:04] i'll upload it to my djangos custom-modules direcotry [10:04] directory [10:04] in a project I'm working on there is a pre-commit test used like bazaar plugin, the problem is that each developer has to link or copy that plugin in ~/.bazaar, is there any way to distribute it in the /.bzr ? or some repo setting? [10:08] en1gm4: Not really -- general arbitrary code execution is considered unwise. :P [10:09] en1gm4: There is work on doing it in a more-safe way, and it might even be usable, but I don't know. [10:10] en1gm4, I'm getting security-hives about a project that just distributes serialized objects in the VCS folder for later deserialization and execution... [10:11] codygman, you should automate your deployment (with e.g. fabric) and have pip pull dependencies from a requirements.txt file, where you can list the path to your module's bazaar branch [10:12] ahh alright.. i've been looking at fabric [10:18] thanks donri, think its time for me to shutdown the shell tonight though [10:19] you rest that overworked brain! [10:50] hi. i have a corruption problem with bzr branch. for some reason, when i branch almost all line with "foo: stuff $bar" become "foo$bar". i can figure if it's a bug or if there is a functionality that i don't know [10:52] i have no plugins and this is the same with either version 2.0.4 or 2.1.0 [10:53] acezar: "bzr plugins" doesn't list anything? [10:53] acezar: Are you using some incredibly bizarre file system? [10:53] acezar: I'm suspicious you may have keyword replacement enabled. [10:55] i have now fastimport launchpad netrc_credential_store news_merge as plugins. fastimport was'nt installer when i tested. the others are installed as default (i use archlinux) [10:55] i suspected keywords too but cant find it [10:56] i work whith sshfs mounted volumes [10:57] is there any keymord replacement when the keywords plugin is not installed? [10:58] acezar: The keywords extension uses the content filtering feature built into bzr, but that doesn't do anything by default. [10:58] Honestly, I've got no idea. :-\ Probably something obvious, but... [11:00] is the keywod plugin is installed in the repository when used once? it was present on the first branch opration [11:02] acezar: Ah. No, but the changes it made won't be automagically reverted. Does "bzr diff" show these changes? [11:03] no [11:06] um. [11:06] I don't know much about how content filtering works. :-\ It's possible it does do something permanent. [11:07] i found [11:08] the keywords plugin did somthhing to the repository. i don't know what, but a fresh repository witch as never seen the plugin branch perfectly [11:09] the keywords plugin seems to leave somthing event when uninstalled [11:16] Oh. [11:17] Here's what might have happened: someone disabled the keyword plugin, did not revert the changes it had made, and then accidentally committed them. [11:17] Now they're just normal data. You could use annotate to see what it happened and revert the damage. [11:19] i dont think. there was a trunk branch exported from cvs. when branched this to test some files were corrupted not the trunk. the keywords plugin was installed (bzr explorer windows). then we try to do the same without the plugin. corruted again [11:20] so i tryed on my own computer commandline archilux. same result [11:21] so we tryed to restart from scratch. export form cvs no plugin installed. then branch. no more problems [11:22] Huh. [11:22] You said "CVS", so my brain is shutting down to prevent contamination. ;P [11:24] lol [11:24] hi! does anyone know if there's an app that can graph bzr commit histories ? i.e. something good for making charts as to who's committed the most in the last year? [11:24] It's entirely possible something weird happened between the keyword plugin and the CVS converter. [11:25] bytee: I dunno. Ohloh.net probably does. [11:25] bytee: If by "graph" you mean "ASCII list", the bzr-stats plugin should be able to do that. [11:25] Peng: ah ok. let me try bzr-stats [11:31] hi all .. how do i time-travel my working directory back to revision 2? [11:33] neaj: bzr revert -r 2 [11:33] neaj: bzr update -r 2 (if your bzr is new enough) [11:34] neaj: You can also "bzr cat -r 2 some/file" if you just want an old version of one file dumped to stdout [11:34] neaj: You could even make a new branch, "bzr branch -r 2 some_branch time_travel" [11:35] Peng: bzr: ERROR: no such option: -r [11:35] that's for update [11:36] Bazaar (bzr) 2.0.4 [11:36] won't revert throw away intervening commits? [11:36] it's a big ol' tree i want to time travel [11:37] neaj: I guess bzr 2.0.4 isn't new enough, then. :P Must be new in 2.1. [11:38] * neaj kicks Jaunty [11:38] doing revert .. [11:38] neaj: What do you mean by "throw away intervening commits"? Revert just meddles with the contents of the working tree; it doesn't change any meta data. [11:38] phase:comparing files 43229/45619 [11:38] Peng: ah, cool [11:38] neaj: Even "update" will only meddle with the working tree's contents and meta data; it won't change the branch [11:38] Peng: i thought reverted reverted a commit to make it like it never happened [11:39] neaj: uncommit does that [11:39] Peng: yes, that's what i would expect from update [11:39] neaj: If you mean "completely remove all traces of it from history". [11:43] OK, now revert left me with 1000s of files which it's refusing to delete because they're not empty [11:45] how do i go back to "now" now? [11:46] how can bzr tell me "Tree is up to date at revision 6." if i just did a 'bzr revert -r 2'? [11:47] trying bzr revert -r 6 [11:47] neaj: "bzr revert" if you did revert, or "bzr update" if you did update, or "bzr pull -r revid:something" if you did bzr uncommit or bzr branch. :D [11:47] I'm getting an error trying to run bzr after installing the Bazaar-2.1.0-2.1 package for OSX: http://gist.github.com/326509 [11:47] (Just FYI, you can find that revid with bzrtools' "bzr heads" command. bzr uncommit will also tell you.) [11:47] got about a million like this: Conflict adding file zeocluster/src/theme. Moved existing file to zeocluster/src/theme.moved. [11:48] Yikes. [11:48] ("bzr pull . -r revid:something", I should have said.) [11:48] (Unless you did "bzr branch". Anyway this is off-topic.) [11:48] i just did the revert commands i pasted [11:48] neaj: Did it mention any conflicts when you did the original revert? [11:48] well, you & i pasted [11:49] yes, revert left me with 1000s of files which it's refusing to delete because they're not empty [11:49] those were reported as conflicts [11:49] and now going back to now they were all reported as conflicts again [11:49] neaj: Right. You had files that bzr isn't tracking (text editor backups, .pyc files, compiled code, etc.), so it refused to delete the directories. Now it's trying to create the directories, but they don't exist, so it's unhappy again. [11:49] Err, sorry. [11:49] but they already exist* [11:50] that doesn't make sense ;-) [11:50] if it isn't tracking them, how can it be trying to create them? [11:50] it was tracking them alright [11:51] When you did "bzr revert -r 2", it deleted all of the stuff it tracked. However, you had files it wasn't tracking lying around, so it couldn't delete all of the directories it wanted to. [11:51] Now you're doing "bzr revert" and it wants to create those directories -- because it tracks them -- but it's finding that directories with the same names already exist and gets unhappy. [11:51] (Bazaar tracks directories as first-class objects, just like files.) [11:51] I'm sorry, but I don't know of a good magic cleanup button for this. [11:52] Anyone have any idea what the problem is here? http://gist.github.com/326509 [11:52] Error I'm getting is "'module' object has no attribute 'SIGWINCH'" [11:53] Peng: it's OK, it's a sandpit for learning bzr .. [11:53] cayblood: Oh shoot. Other people have been reporting that too. [11:53] Err, wait, they might have been on Windows though. [11:53] cayblood: What OS? [11:53] OSX [11:53] Oh, duh, shoulda looked at the paths... [11:54] snow leopard, to be precise [11:54] Been trying to get this working with various versions of python and bzr for a couple days now [11:54] running into various problems. [11:55] cayblood: Bazaar assumes that the SIGWINCH signal exists on all non-Windows platforms. Perhaps it is mistaken. [11:55] Finally decided to go with the a plain vanilla setup, remove macports and just try to get the built-in python working [11:55] I think it is mistaken [11:55] let me investigate [11:57] Well, the error message states quite obviously that OS X doesn't have that signal, or at least Python doesn't think it does. [11:57] Looks like there is support for SIGWINCH in OSX: http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man3/is_term_resized.3x.html [11:58] But maybe python doesn't expose it? [11:58] I mean, maybe Python is not making the right declarations or something? Just a guess [11:58] Python should expose it. [11:58] AFAIK, anyway. But it obviously isn't. [11:59] There may be a Python bug here, but this is definitely something bzr can fix as well -- it could exclude OS X, or actually check whether SIGWINCH exists instead of assuming based on the OS. You should file a bug. [12:00] cayblood: try: python -c 'import signal; print signal.SIGWINCH' [12:00] jussec [12:00] Err, good point. [12:00] Peng: I tried the above on OSX 10.6.2 and it worked [12:00] Awesome. [12:00] Peng: Here is the result: [12:00] http://gist.github.com/326518 [12:00] As a workaround, you can pretty easily hack bzrlib/osutils.py:watch_sigwinch to just return or something. [12:01] cayblood: Just to be sure, could you: python -c 'import signal; print signal.__file__' [12:01] cayblood: try changing your current dir (wild guess)... hehe like Peng said :) [12:02] Could it be a problem with the built-in python version? Apparently it's 2.4.6 [12:02] Maybe. [12:03] vila: changing current dir did nothing [12:03] if your PYTHONPATH includes '.' or '' the current directory is searched for modules, environment bug [12:03] cayblood: What about the command I asked you to run? [12:03] python -v ? [12:03] Peng: I got 'module' object has no attribute '__file__' [12:03] I've got python-2.6.1 here [12:04] and AFAICT, it's a stock install [12:04] vila: hmm weird [12:04] cayblood: OK. [12:04] vila: only thing I can assume is that my python was not upgraded when I upgraded to Snow Leopard, but I highly doubt that [12:05] So you _are_ getting the right signal module (almost certainly python -c 'import signal; print signal' would confirm it for sure). [12:05] jussec [12:05] certainly;* [12:05] Peng: I get [12:05] cayblood: Yeah, OK. [12:06] I can check what version of python is running on my colleagues' machines. Jussec... [12:07] Python's signal module is about as simple as it can be: #ifdef SIGWINCH [12:08] * vila needs food [12:08] Looks like fresh installs of snow leopard have 2.6.1 [12:08] * Peng has pizza! :D [12:08] bzr branch -r 2 PlonePIMS-ready PlonePIMS-ready-r2 # <- this worked fine [12:08] mv PlonePIMS-ready PlonePIMS-ready-orig [12:09] For some reason mine has 2.4.6. I will investigate further and see if I can start from a clean baseline. [12:09] bzr branch -r 6 PlonePIMS-ready-orig PlonePIMS-ready-r6 # <- bzr: ERROR: Not a branch: "/home/jean/PlonePIMS-ready-orig/". [12:09] ?! [12:10] neaj: ls PlonePIMS-ready-orig [12:10] neaj: Maybe it already exists, so your branch is at PlonePIMS-ready/PlonePIMS-ready-orig [12:10] Err, other way around, sorry. [12:10] neaj: PlonePIMS-ready-orig/PlonePIMS-ready [12:10] nope [12:10] looks like macports reared its ugly head [12:11]