| jml | poolie: may I join the call? | 00:02 |
|---|---|---|
| poolie | yes | 00:02 |
| poolie | just fiddling with linux audio :/ | 00:02 |
| jml | ahh :) | 00:02 |
| spiv | That's an endless source of joy. | 00:03 |
| * jml finds a bzr bug | 00:04 | |
| jml | http://paste.ubuntu.com/47016/ | 00:04 |
| spiv | jml: is it normal that it takes almost a minute to authenticate to bazaar.staging.launchpad.net? | 00:24 |
| mwhudson | sadly, yes :/ | 00:24 |
| jml | spiv: there's a graph of auth times available internally | 00:25 |
| jml | so what's the deal with KeyError? | 00:27 |
| justizin | so hey guys, someone said a while back, and i know i ask once in a while about this because i don't have latest bzr and haven't started using, but there is a semi-equivalent to svn:externals in bzr being worked on, or maybe in 1.6, but i can't find it in docs or anywhere.. | 00:28 |
| spiv | jml: https://bugs.edge.launchpad.net/bzr/+bug/208869 | 00:28 |
| ubottu | Launchpad bug 208869 in bzr "info -v fails over bzr+ssh" [High,Confirmed] | 00:28 |
| jml | oh. fun. | 00:28 |
| justizin | i have access to an ubuntu intrepid box with 1.6 now so want to plan to use that feature if possible.. | 00:28 |
| poolie | jml, i wish it was faster to put tags on bugs | 00:29 |
| lifeless | justizin: its not baked yet unfortunately; the feature is called nested trees, and LarstiQ has a bzr branch on launchpad with it | 00:29 |
| jml | poolie: me too. | 00:30 |
| jml | poolie: we might actually make it so over the next couple of months. | 00:30 |
| justizin | i'd love to help test, i make heavy use of svn externals and have replaced it for now with a bash script in my bzr repo that just fetches the contents of EXTERNALS.txt, but i'm looking to mirror all our svn dependencies in bzr so that i can hand-merge upstream changes, be aware, etc.. and get off svn. | 00:30 |
| jml | poolie: is there a "this shows users a stack trace zomg fix it now" tag? | 00:30 |
| poolie | for bzr? | 00:31 |
| justizin | it's a handy feature but bzr's list tips the scales pretty heavily away from it either way | 00:31 |
| poolie | not really | 00:31 |
| poolie | just set importance=zomg | 00:31 |
| justizin | it is a one-liner to fetch the externals, and i'm soon going to just use bzr to fetch either bzr or svn externals, and make our file contain svn+http urls | 00:31 |
| justizin | lifeless: I'll try to find the branch in lp :) | 00:33 |
| lifeless | jml: lots of things show stack traces; its not a great metric for how many users it affects | 00:33 |
| justizin | lifeless: do you know anything about the feature's current design? | 00:33 |
| lifeless | jml: we try to set importance by normalising frequency and impact | 00:33 |
| justizin | is it like a shared repo? | 00:33 |
| lifeless | justizin: not really, shared repos just optimise storage | 00:34 |
| lifeless | brb | 00:34 |
| justizin | well, i mean, i guess a better formed question would be, does it use a shared repo, or similar func, to optimize storage.. | 00:34 |
| jml | lifeless: sure. It's something dear to me because I've had reports from friends who show off bzr to *their* friends and then get all embarrassed because of stack traces. | 00:34 |
| lifeless | jml: is it the branch-history one? wtf is branch-history anyhow :P | 00:38 |
| jml | lifeless: it's https://bugs.edge.launchpad.net/bzr/+bug/208869 — info -v fails over bzr+ssh | 00:38 |
| ubottu | Launchpad bug 208869 in bzr "info -v fails over bzr+ssh" [High,Confirmed] | 00:38 |
| jml | oh look, ubottu doesn't suck :) | 00:39 |
| jml | poolie: I get this with your branch: http://paste.ubuntu.com/47029/ | 00:42 |
| * jml tries a couple of things to ensure not pebkac | 00:43 | |
| jml | yeah, looks like a bug. | 00:49 |
| poolie | jml, interesting | 01:11 |
| poolie | thanks | 01:11 |
| jml | poolie: np | 01:14 |
| lifeless | spiv: ping | 01:20 |
| lifeless | poolie: ping | 01:25 |
| spiv | lifeless: pong | 01:26 |
| poolie | lifeless, hi | 01:27 |
| lifeless | spiv: is the hash for a char-converted-to-int the same as a 1-length string containing the same char (for dict lookups from C python) | 01:29 |
| spiv | lifeless: I don't know, I'd guess not. It's certainly not guaranteed. | 01:29 |
| lifeless | pyrex FTL then :P | 01:30 |
| spiv | Yep, definitely different. | 01:30 |
| lifeless | it translated _minikind_to_kind[minikind] to _minikind_to_kind[PyLongInt_FromInt(minikind)] | 01:30 |
| lifeless | when I made minikind into a cdef char, rather than a python string | 01:31 |
| poolie | lifeless, was that all you wanted? | 01:31 |
| lifeless | poolie: yeah, echannel :P | 01:31 |
| poolie | intrepid wants to reboot now, biab | 01:31 |
| spiv | lifeless: Hmm, maybe pyrex things _minikind_to_kind is a C array rather than a dict, or something? | 01:31 |
| spiv | Oh, except obviously not if it's doing PyLongInt_FromInt. | 01:32 |
| spiv | Anyway, that does seem badly broken :) | 01:32 |
| spiv | lifeless: python -c "for i in range(256): print i, hash(i), hash(chr(i))", btw :) | 01:33 |
| lifeless | spiv: yeah, I wasn't going to list all the C Python API calls to do the dict lookup | 01:37 |
| lifeless | I was just showing the key 'oops' moment | 01:37 |
| lifeless | 2.4 seconds now | 01:44 |
| lifeless | oh, thats by cheating. doh. | 01:44 |
| spiv | :) | 01:46 |
| lifeless | ok, thats annoying | 01:48 |
| lifeless | we put every dir into a dict during st | 01:48 |
| lifeless | if there are no renames, epic fail. | 01:48 |
| === kiko is now known as kiko-zzz | ||
| lifeless | spiv: is there a constant value for True and False in CPYthon ? | 02:56 |
| mwhudson | Py_True | 02:56 |
| jml | I would like to make a branch using make_branch that has a stackable branch format and a non-stackable repo format. | 03:00 |
| jml | what's the easiest way of doing this? | 03:00 |
| spiv | jml: heh | 03:00 |
| spiv | jml: take a look at the mail I *just* sent to the bazaar@ list | 03:01 |
| jml | I saw :) | 03:01 |
| jml | slightly different though. | 03:01 |
| spiv | jml: TestCaseWithMemoryTransport.make_branch unfortunately ignores shared repos. | 03:01 |
| jml | spiv: I don't need shared repos, just a non-standard branch/repo format pair | 03:01 |
| spiv | And doesn't give you any way to specify non-standard format groupings. | 03:02 |
| jml | :) | 03:02 |
| spiv | I suppose you could register a new format in the bzrlib.bzrdir.format_registry | 03:02 |
| jml | I'll just steal code I have elsewhere that does what I want (but doesn't use make_branch) | 03:03 |
| spiv | But simplest is probably to instantiate a custom BzrMetaFormat1 and set the *_format attributes appropriately | 03:03 |
| jml | *nod* | 03:05 |
| === mlh_ is now known as mlh | ||
| poolie | lifeless, ping? | 03:35 |
| poolie | i want to run something past you re bug 261315 | 03:36 |
| ubottu | Launchpad bug 261315 in bzr "getting a stacked branch over the smart protocol fails with "Could not install revisions"" [Critical,In progress] https://launchpad.net/bugs/261315 | 03:36 |
| poolie | either before or after lunch | 03:36 |
| poolie | that is basically, is it reasonable for the RemoteBranch to get the branch.conf file and interpret it itself to extract the fallback url, rather than relying on the server to do this? | 03:36 |
| poolie | i think it is | 03:36 |
| lifeless | poolie: you mean via VFS calls? | 03:47 |
| lifeless | poolie: or delegated to _real_branch? | 03:47 |
| lifeless | poolie: accessing branch.conf from RemoteBranch, directly, would be unreasonable - abstraction violation IMO | 03:48 |
| poolie | re branch.conf | 04:25 |
| poolie | it kind of is | 04:25 |
| poolie | otoh i'm not sure why it's exposed by an rpc if the client is not supposed to read it directly | 04:26 |
| poolie | maybe this is a spurious historical reason | 04:26 |
| lifeless | err | 04:26 |
| lifeless | you've lost me | 04:26 |
| lifeless | simple thought experiment, imagine the branch at the other end is a bzr svn branch | 04:26 |
| lifeless | or a BzrBranch5 | 04:26 |
| lifeless | neither of which have branch.conf | 04:27 |
| poolie | sure, that's just the case i'm thinking of | 04:27 |
| lifeless | an rpc can abstract that | 04:27 |
| lifeless | without the client having the format's code locally | 04:27 |
| poolie | my point is it's odd that RemoteBranch supplies a get_config() method | 04:30 |
| poolie | well | 04:30 |
| lifeless | why is that odd? | 04:30 |
| poolie | arguably that can represent the configuration file as any object | 04:31 |
| lifeless | SvnBranch supplies such a method, and so does Branch5 | 04:31 |
| poolie | i meant to say Branch.get_config_file, | 04:32 |
| poolie | and it's no longer called, i removed it a while ago iirc | 04:33 |
| poolie | so that's ok | 04:33 |
| poolie | spiv, ping? | 04:43 |
| poolie | my current plan for this is then | 04:44 |
| poolie | first off, read it through the real branch at RemoteBranch construction time | 04:44 |
| poolie | this is unfortunately going to cause all branches to do vfs operations | 04:44 |
| poolie | but we need to do this to work with older servers | 04:44 |
| spiv | poolie: pong | 04:45 |
| poolie | then, add an rpc that gets all the information we need when opening a branch: repository location, last revision, stacking, etc | 04:45 |
| poolie | probably called Branch.open_v3 or something | 04:45 |
| poolie | then change the client to call this, and only if the server fails go back to using the vfs | 04:46 |
| spiv | That sounds good to me. | 04:46 |
| poolie | so the fact that we have to be able to do it over vfs suggests i should get that going first | 04:46 |
| poolie | if we do that second stage we will save some roundtrips when opening a branch | 04:47 |
| poolie | but we need to think a bit about where to cache it | 04:47 |
| poolie | the straightforward thing would be to just naively cache it in the RemoteBranch object indefinitely | 04:47 |
| poolie | however, the general approach aaiu is that caching should be scoped by locks | 04:47 |
| spiv | How do non-remote branches handle caching of stacking info/ | 04:48 |
| spiv | ? | 04:48 |
| poolie | so then there seem to be a few options | 04:48 |
| poolie | apparently they don't cache it | 04:48 |
| poolie | heh, nice question :) | 04:49 |
| poolie | so, the stacking info does not particularly need to be cache because it's normally only used from the constructor to open the repository | 04:49 |
| poolie | caching it would not be particularly important for performance | 04:49 |
| poolie | and if we can arrange to make this open_v3 call from the constructor or nearby we would not need to call it either | 04:50 |
| poolie | i guess i was thinking more about putting other things like the last_revision into the same call | 04:50 |
| poolie | where it both would be important to call it and also it's quite likely to change | 04:51 |
| spiv | Hmm, last revision info is currently cached, and that cache's lifetime is managed by locks. | 04:51 |
| spiv | Possibly what's missing is an open-and-immediately-read-lock operation? | 04:52 |
| poolie | um, also, if the only higher-level rpc that reads the stacking location is the open_v3 one, then presumably it needs to be cached for commands like info that might ask for it later | 04:52 |
| poolie | this does seem related to creating objects locked | 04:53 |
| poolie | both on disk when we start writing to them and also in the api | 04:53 |
| spiv | Right. | 04:53 |
| poolie | spiv, how is the lifetime managed by a lock? | 04:54 |
| poolie | afaics it isn't | 04:55 |
| spiv | See BzrBranch.unlock | 04:55 |
| spiv | It calls _clear_cached_state | 04:55 |
| spiv | RemoteBranch also calls _clear_cached_state on unlock. | 04:56 |
| poolie | ah | 04:57 |
| poolie | right | 04:57 |
| poolie | i was mislead a bit by the lack of a call to the super constructor, but there is a comment saying why | 04:57 |
| poolie | though it's still a bit tasteless | 04:57 |
| poolie | so it would be a bit dodgy but we could cache it there from the constructor and it would last until the object is first unlocked | 05:01 |
| lifeless | uhm | 05:01 |
| lifeless | thats lots dodgy | 05:02 |
| lifeless | if you want an idiom for open-locked, do that as a separate branch IMO, possibly lots of things that can break | 05:02 |
| poolie | sure | 05:03 |
| poolie | so if we don't do that, it seems necessary to add a specific fine-grained api to get the stacked location | 05:04 |
| poolie | this could be done in addition to putting it in the constructor | 05:04 |
| poolie | i guess we need one to set it so it's not unreasonably increasing the number of available apis. | 05:05 |
| lifeless | didn't jml put up a branch to allow getting stacked location from the branch format object? | 05:06 |
| jml | lifeless: it was rejected. | 05:07 |
| lifeless | we do have api's for settings and getting the location already | 05:07 |
| jml | the problem for me was that I needed a Branch object to use BranchConfig | 05:07 |
| * poolie reads | 05:12 | |
| poolie | ok, i read that thread | 05:18 |
| jml | in the end, I used something close to the original patch. | 05:20 |
| poolie | used meaning it was merged to bzr.dev? | 05:22 |
| poolie | or used in an external patch? | 05:22 |
| poolie | lifeless, sure, i'm just wondering how those apis should be implemented on RemoteBranch | 05:23 |
| poolie | or rather, how to most cleanly get my implementation of it to pass the existing test_remote tests | 05:23 |
| poolie | spiv, re those tests we were looking at on friday | 05:23 |
| jml | poolie: used as in "wrote a standalone function that did the same thing" | 05:24 |
| jml | poolie: https://pastebin.canonical.com/9155/ if you are interested. | 05:25 |
| spiv | I think it's useful for tests if merely constructing a RemoteBranch doesn't trigger an RPC. | 05:25 |
| poolie | spiv, that's the heart of the problem here | 05:28 |
| spiv | A possibility would be to add an optional fallback_urls= param to RemoteBranch.__init__. | 05:32 |
| poolie | and do it from the RemoteBranchFormat | 05:32 |
| poolie | that's true | 05:32 |
| poolie | but, if we find we need to do it through the real_branch, then what... | 05:32 |
| spiv | The existing test_remote tests would just pass fallback_urls=[], and for now the real code can not pass it. | 05:32 |
| spiv | And when not passed RemoteBranch could then fallback to using real_branch. | 05:33 |
| poolie | hm | 05:45 |
| poolie | so i can see how that's handy if you just want to test some other aspect | 05:45 |
| poolie | of the class | 05:45 |
| poolie | on the other hand it seems a bit like cheating | 05:45 |
| spiv | poolie: it's a bit weird to me that opening a branch mutates the repository object, which potentially belongs to other branches too. | 05:58 |
| spiv | poolie: (i.e. by adding the fallbacks) | 05:59 |
| poolie | that's true | 06:02 |
| poolie | but, that's the api | 06:02 |
| spiv | Yeah. | 06:02 |
| poolie | it's kind of related to being able to get the repository either from the bzrdir or the branch | 06:03 |
| poolie | and now you get different behaviour | 06:03 |
| poolie | um | 06:03 |
| poolie | there are some other possible paths as far as asking the Repository class method or format object too | 06:03 |
| poolie | it should be more clear which one is primary | 06:03 |
| lifeless | could someone with linux try this - valgrind --tool=callgrind python2.5 bzr st bzr.dev | 06:10 |
| lifeless | spiv: it was a tradeoff | 06:10 |
| lifeless | spiv: having a arbitrarily large list of fallbacks is intrinsic to a shared repo with stacking | 06:11 |
| lifeless | spiv: having the branch maintain the state allows restricting that scope to just the repository instances that need to know about it | 06:11 |
| spiv | lifeless: you say "the branch maintain the state", but they state is kept on the repo afaict? | 06:12 |
| spiv | lifeless: I guess my naive expectation would be that stacked_branch.repository would be a FallbackRepository(real_repo, *fallback_urls) rather than having the branch mutate the repo. | 06:13 |
| spiv | I haven't spent much time thinking about this, though :) | 06:13 |
| lifeless | spiv: the disk state is in the branch | 06:14 |
| lifeless | spiv: reconcile needs to be able to work with all branch's fallback repos at once | 06:15 |
| jml | lifeless: I've run that valgrind command, what output do you want? | 06:15 |
| lifeless | jml: did it fail with 'cannot allocate memory' ? | 06:16 |
| jml | lifeless: nope. | 06:16 |
| lifeless | ok | 06:16 |
| jml | that's using bzr.dev built for py2.5 | 06:16 |
| poolie | spiv, the thing is that the repo implementation might want to know about how they're stacked | 06:17 |
| poolie | rather than it just being a composite object | 06:17 |
| poolie | um | 06:17 |
| lifeless | jml: thanks | 06:17 |
| poolie | it might be cleaner though to unambiguously give the branch responsibility for opening the repo | 06:17 |
| poolie | if it has the knowledge how to do so | 06:17 |
| lifeless | by comparison, git has a single repo instance with a list of 'alternates', and hg just writes nulls for parents at the edge of the stacking boundary | 06:18 |
| poolie | could it be a security problem for the server to give arbitrary urls back to the client? | 06:21 |
| lifeless | yes, if they are trusted | 06:22 |
| lifeless | but that applies to normal content and hooks too | 06:22 |
| lifeless | so I don't think they are any more special than reading a file from a http server | 06:22 |
| poolie | mm | 06:23 |
| poolie | it seems like it'd be good for test_smart to start its test with the tuple-like request it wants to test | 06:49 |
| poolie | so it can also check the right thing gets called | 06:50 |
| poolie | rather than starting with the Request class that's going to ultimately run... | 06:50 |
| poolie | hm | 06:55 |
| poolie | it's not really easily accessible though | 06:55 |
| vila | Good morning Bazaar | 07:07 |
| gour | morning | 07:07 |
| lifeless | hi vila | 07:08 |
| poolie | hello vila | 07:13 |
| chandlerc | i got an odd error when upgrading a shared repository with a bzr-svn branch in it: | 07:20 |
| chandlerc | bzr: ERROR: No such file: ('3@fc50161f-d74b-0410-97f1-43881e8fa688:parser%2Ftrunk:templates', 'svn-v3-trunk1:fc50161f-d74b-0410-97f1-43881e8fa688:parser%2Ftrunk:18') | 07:20 |
| spiv | jelmer: ^ see chandlerc's upgrade problem | 07:24 |
| spiv | poolie: have you seen David Ingamells' stacking problem on the mailing list? | 07:26 |
| poolie | no | 07:26 |
| spiv | poolie: https://lists.ubuntu.com/archives/bazaar/2008q3/047516.html is the most recent post in the thread | 07:27 |
| poolie | ok, yes | 07:27 |
| poolie | spiv, what about it? | 07:28 |
| spiv | Just that you are somewhat likely to know if it's a already known issue or not. | 07:29 |
| poolie | it's not totally surprising to me, but i don't specifically know what it is | 07:30 |
| spiv | i.e. you're probably best placed to reply and say "yes, that's bug #NNN" or "that's a problem, please file a new bug report". | 07:30 |
| poolie | not off hand | 07:30 |
| poolie | i'd have to try to reproduce it | 07:30 |
| poolie | so, (B) | 07:30 |
| poolie | it would be nice if we could just say "expose this as an rpc" rather than declaring each one as a custom class | 07:31 |
| poolie | i guess there's no strong reason why we can't? | 07:31 |
| poolie | like it would probably fit into the registry format | 07:31 |
| spiv | poolie: for RPCs with simple arguments and return values? | 07:32 |
| poolie | yeah | 07:32 |
| poolie | at least to start with | 07:32 |
| poolie | i'm going to put the fallback repositories into the real_repository fallback, as well as the remote one | 07:34 |
| spiv | Or rather than changing the registry, you could perhaps have a helper to construct a SmartServerRequest* subclass for you, and then register that. | 07:34 |
| poolie | exactly | 07:34 |
| poolie | or even just an instance | 07:34 |
| poolie | well, archetype or something | 07:34 |
| poolie | spiv, i wouldn't be totally surprised if this current branch fixes it but i'm not sure it will | 07:35 |
| spiv | I needs to be a class, or object factory of some sort, I think. | 07:35 |
| spiv | poolie: yeah. That's what I thought about my last fix, though ;) | 07:35 |
| poolie | ^^ which "that"? | 07:35 |
| spiv | "i wouldn't be totally surprised if this current branch fixes it but i'm not sure it will" | 07:36 |
| poolie | heh | 07:36 |
| vila | spiv: regarding but #269535, could you make a quick review of lp:~vila/bzr/py26bzr revno 2940 ? It fixes a lot of python-2.6 failures and errors but makes bzrlib.tests.test_fetch.TestHttpFetch.test_weaves_are_retrieved_once fails. | 07:50 |
| vila | Which is a bit puzzling... | 07:51 |
| vila | spiv: I'm not asking for a true review, just a look and feedback, it may need more polish (I'm just trying to make it work for now) | 07:52 |
| spiv | vila: ok | 07:52 |
| vila | spiv: thanks | 07:53 |
| * AfC would just like to say that he is finding bzr fast today. | 07:57 | |
| AfC | Take THAT all you whingers. | 07:57 |
| spiv | AfC: :) | 07:59 |
| gour | AfC: 1.7x? | 08:00 |
| AfC | gour: don't be ridiculous; 1.6.1. | 08:02 |
| AfC | Running released software == sanity. | 08:02 |
| gour | ok, ok...nice to hear | 08:02 |
| AfC | [Unless of course it's a project you're hacking on. Then of course you run upstream from source. | 08:02 |
| AfC | Which reminds me of something I was chatting about with Rusty one day... I was observing that I had just done a release of my project, and didn't feel terribly enlightened or uplifted as a result. | 08:03 |
| AfC | After all, *I* don't need to do a release to use my code. We just need everyone _else_ in the software universe to release _their_ code so we can use it :) :)] | 08:03 |
| gour | lol | 08:04 |
| AfC | (I first thought of this when I'd get "congratulations on your release" type emails from colleagues, when all doing a release was good for was a lot of time consumed away from time spent on hacking ... and bug reports for OSes I don't use and for situations that were all WORKSFORME) | 08:05 |
| spiv | vila: wow that's a lot of changes! | 08:06 |
| gour | "everybody is thinking about himself/herself, only I think..." | 08:07 |
| vila | don't look at the whole ! Just diff -c 2940 ! | 08:07 |
| AfC | (made me realize just how big a burden doing releases really is. Its not only work. It's also psychological pain and distraction ... just so other people can use your work and not pay your anything. Reminds you just how much we owe people who offer their work as Open Source and promote Software Freedom). | 08:07 |
| spiv | vila: sure :) | 08:07 |
| vila | I'm not sure all changes in that branch are still needed, but since that was an early attempt to be compatible with python-2.6 I didn't re-start from scratch | 08:07 |
| vila | but if your remark was about: "what is needed to be compatible with 2.6" then, yes, it's not as trivial as one may hope ;-/ | 08:08 |
| gour | AfC: just consider eternal glory people are using your software | 08:09 |
| gour | vila: bzr will soon jump to 2.6 bandwagon? | 08:09 |
| spiv | vila: yeah, that's what my remark was | 08:09 |
| spiv | gour: no, we'll still support 2.4 for quite a while I think | 08:09 |
| vila | gour: no, I'm looking at what is needed, I don't think we want to rush | 08:10 |
| gour | thanks | 08:10 |
| spiv | gour: (and 2.5). But we want to work with 2.6 as well. | 08:10 |
| * gour wonders who will use 3.0 then | 08:10 | |
| spiv | vila: so at a glance the changes in 2940 look nice. Interesting that it causes that test to fail. | 08:10 |
| vila | vila == puzzled, spiv == interested :D | 08:11 |
| vila | spiv: I don't really like passing transport at medium construction time, it may be enough to provide it at request time | 08:12 |
| vila | but that's the make it right part ;) | 08:12 |
| poolie | spiv, did we ever settle something about systematically marshalling all/most errors across hpss? | 08:13 |
| spiv | vila: so for some reason it's reprobing for a smart server | 08:13 |
| poolie | afc, that's good to hear | 08:13 |
| spiv | poolie: somewhat | 08:13 |
| spiv | poolie: bzrlib/remote.py now has a _translate_error helper. | 08:14 |
| poolie | i saw | 08:14 |
| poolie | i guess i meant, on the server side, it's be nice to let the do() method just pass the error up and have it automatically sent | 08:14 |
| * vila thinks that the smart probes are itching more and more.... redirection bugs, now that :-/ | 08:15 | |
| vila | spiv: That's why I asked for feedback, I'm wondering if my patch is in the right direction or is foobaring some "ok, I have already probed, no need for more" | 08:16 |
| spiv | poolie: so there's a single place to handle the unmarshalling now, and it deals with the "this exception needs an other_branch param" problem. On the server side I think it's enough to make _call_converting_errors smarter. | 08:16 |
| spiv | vila: I think it's the right direction | 08:23 |
| vila | ok | 08:23 |
| spiv | vila: so the reason it fails is that SmartClientMedium is the thing that remembers if there's been a protocol error or not | 08:24 |
| spiv | vila: and now we are making new SmartClientMedia rather than re-using them. | 08:25 |
| lifeless | vila: bug 246880 | 08:25 |
| ubottu | Launchpad bug 246880 in bzr "ghost fetch issue: fail when fetching a text referenced by a live revision introduced by a ghost revision" [High,Triaged] https://launchpad.net/bugs/246880 | 08:25 |
| spiv | vila: probably the thing to do is keep the medium in the _shared_connection object, so there's one instance per connection. | 08:25 |
| vila | spiv: Haaaaa ! Thks | 08:25 |
| spiv | vila: rather than making a new one for each get_smart_medium call | 08:25 |
| lifeless | vila: please poke now at my fixed branch and script so you can see what I've done | 08:25 |
| lifeless | vila: as the EU guys come online, I won't be around to answer questions shortly | 08:26 |
| vila | spiv: so it should not keep a transport instance | 08:26 |
| lifeless | vila: we still have code changes to make vis-a-vis the bug, but the casper branch should be done | 08:26 |
| spiv | vila: (search for _protocol_version_error inside SmartClientMedium to see where/how this state is tracked) | 08:26 |
| vila | lifeless: ok, switching to it right now so that *I* can ask questions :) | 08:26 |
| vila | spiv: sure, now that you mention that, it should be easy | 08:27 |
| vila | lifeless: http://paste.ubuntu.com/47101/ | 08:54 |
| vila | when trying your script on cp -R casper.backup casper | 08:55 |
| vila | Your script is intended to produce a 'cleaned' branch from a 'casper' branch, the later being broken, right ? | 08:56 |
| lifeless | vila: you shouldn't need to run it though, I uploaded a fixed branch | 09:00 |
| vila | I downloaded it, your script runs ok on it :D | 09:00 |
| vila | I thought your script was intended to be used by people having broken branches | 09:01 |
| vila | lifeless: what should be done with your clean branch ? push --overwrite it to lp:~ubuntu-core-dev/casper/trunk ? | 09:01 |
| vila | and from there everybody should re-clone ? | 09:02 |
| vila | should we go private from here to avoid spamming this channel ? | 09:02 |
| poolie | here is fine | 09:02 |
| poolie | but i think he's signed off | 09:02 |
| lifeless | vila: something like that | 09:03 |
| lifeless | vila: that error is a local repo error in whatever branch you tried it on | 09:04 |
| lifeless | my script assumes a 'working but cannot clone' branch | 09:05 |
| vila | lifeless: ok, I may have played too much, I'll retry with a less broken one | 09:05 |
| vila | so, starting again with the casper.backup from http://people.ubuntu.com/~cjwatson/tmp/casper-wreckage.tar.gz, your script works | 09:14 |
| vila | lifeless: I won't pretend I understand everything that is going on nor that I can go further, but I think I can help them get back a clean branch | 09:15 |
| vila | lifeless: that's what you're expecting from me right ? | 09:16 |
| lifeless | vila: well, ideally they grab my cleaned branch | 09:55 |
| lifeless | vila: and you help them become users of that branch, and its all good | 09:55 |
| vila | lifeless: ok | 09:55 |
| VSpike | morning folks... just looking for advice on an easier way to do something | 10:31 |
| VSpike | I keep coming across a similar problem.. I organised a directory of files under source control by creating subdirectories and moving the file in there | 10:31 |
| VSpike | Previously I've resolved this with bzr after the fact by doing a series of bzr move --after file1 /newdir/file1 | 10:33 |
| VSpike | Trouble is, if the directory is new, it complains there about it not being controlled, so I have to do bzr add newdir, but this then adds all the files in that new directory.. so I have to then remove each one before issuing the move --after command | 10:34 |
| VSpike | Is there an easier way to do this? | 10:34 |
| VSpike | It's bad enough that on windows the files are listed in bzr st with "/" when windows won't accept that so you can't even copy and paste to speed things up :) | 10:34 |
| spiv | VSpike: "bzr add --no-recurse newdir" would help you I think | 10:35 |
| spiv | That will add newdir without adding the files underneath it | 10:35 |
| VSpike | spiv: ah was hoping there was something like that :) | 10:36 |
| lifeless | vila: may need LOSA help to zap the existing branches | 10:36 |
| lifeless | jml: could you draft a _real quick_ mail to vila about what it would take to zap the existing corrupt branches of casper, for LOSA's to execute ? | 10:36 |
| lifeless | jml: (you know the details I'd have to say 'look up' on) | 10:37 |
| jml | casper's a project on Launchpad? | 10:38 |
| vila | jml: yes | 10:38 |
| lifeless | jml: its a package whose source is managed in bzr | 10:38 |
| lifeless | jml: I'm not sure what product the branches are attached to | 10:38 |
| * vila would really like to know the expansion of LOSA... | 10:39 | |
| lifeless | some are not on LP but are mirrored - the 'remirror now' button discussed previously would suite those branches, others are hosted on LP | 10:39 |
| mwhudson | vila: Launchpad/Landscape Operation System Administrator | 10:39 |
| vila | ok, I was close with my Launchpad Overlord System Admins, but no cigar :) | 10:40 |
| gnomefreak | my bzr login id would be just gnomefreak? | 11:14 |
| gnomefreak | nope guess not | 11:15 |
| cjwatson | vila: hey, so I'm looking through lifeless' work on bug 246880, and I understand he briefed you on what it'll take to deal with existing LP branches | 11:16 |
| ubottu | Launchpad bug 246880 in bzr "ghost fetch issue: fail when fetching a text referenced by a live revision introduced by a ghost revision" [High,Triaged] https://launchpad.net/bugs/246880 | 11:16 |
| Kinnison | gnomefreak: It's unclear to me what you mean | 11:16 |
| Kinnison | gnomefreak: If your username is gnomefreak then bzr will default to using that to record commits | 11:16 |
| gnomefreak | Kinnison: trying to push to my bzr branch it asks for "bzr launchpad-login YOUR_ID" | 11:16 |
| Kinnison | gnomefreak: aah, you need to tell it your launchpad login id | 11:17 |
| spiv | gnomefreak: that's not a "bzr login", that's your Launchpad login :) | 11:17 |
| Kinnison | gnomefreak: e.g. mine is 'dsilvers' | 11:17 |
| vila | cjwatson: yes, basically the bug has a clean branch associated with it | 11:17 |
| gnomefreak | i used gnomefreak as ID and it still failed permissions on ssh key | 11:17 |
| cjwatson | vila: right, I actually had to reconvert it using lifeless' script as he was missing some new revisions | 11:17 |
| Kinnison | gnomefreak: You are John Vivirito? | 11:17 |
| cjwatson | vila: I'm doing a diff-at-every-revision test now | 11:17 |
| gnomefreak | Kinnison: yes | 11:17 |
| vila | cjwatson: great | 11:17 |
| cjwatson | vila: I'm going to want to push to lp:casper, and I have a funny feeling that I'll need to move the old branch out of the way first | 11:18 |
| Kinnison | gnomefreak: and you're using one of gnomefreak@Development or gnomefreak@Hardy in terms of ssh keys? | 11:18 |
| cjwatson | vila: do you know whether simply changing the branch name with "edit details" in LP will do the trick there? | 11:18 |
| gnomefreak | Deveklopemt | 11:18 |
| gnomefreak | Development Kinnison | 11:18 |
| Kinnison | gnomefreak: so, having done bzr launchpad-login gnomefreak, did it give you errors? | 11:18 |
| gnomefreak | it seems the permissions are due to shh key :( | 11:19 |
| vila | cjwatson: ah, I don't remember if lp supports branch renames, it wasn't a long time ago, but that may have changed | 11:19 |
| poolie | vila, i think it does | 11:19 |
| cjwatson | I suppose I can just try it | 11:19 |
| vila | poolie: thks :) | 11:20 |
| spiv | cjwatson: To change the branch that "lp:casper" resolves to you'd need to use https://code.edge.launchpad.net/casper/trunk/+edit | 11:20 |
| gnomefreak | and i know it worksoh yuck looks like no key in my ~/.ssh dir :( is there a way to add the exsisting key to it? | 11:20 |
| spiv | cjwatson: (and simply renaming the underlying branch wouldn't affect lp:casper AIUI) | 11:20 |
| Kinnison | gnomefreak: either copy your .id_{dsa,rsa}{,.pub} files in, or make a new key for that machine and register it on launchpad | 11:20 |
| cjwatson | spiv: right, the bazaar.launchpad.net mirror won't care about what lp:casper is though. I just want to make sure the physical branch data is out of the way so that a fresh push will copy it all from scratch | 11:20 |
| cjwatson | see what I mean? | 11:20 |
| Kinnison | gnomefreak: s/\.id/.ssh/id/ | 11:21 |
| spiv | cjwatson: so probably for clarity for everyone you'd want to rename the existing branch, make a new one, and then point lp:casper at the new one | 11:21 |
| === mvo__ is now known as mvo | ||
| cjwatson | I've renamed the existing one to trunk.old | 11:21 |
| gnomefreak | Kinnison: that is gonna be hard since the dir is empty but i think i saved it to USB stick | 11:21 |
| cjwatson | $ lftp sftp://bazaar.launchpad.net/~ubuntu-core-dev/casper/trunk | 11:21 |
| cjwatson | cd: Access failed: stat/lstat failed (~ubuntu-core-dev/casper/trunk) | 11:21 |
| cjwatson | that looks promising | 11:21 |
| spiv | cjwatson: (or get an admin to empty branch directory behind the scenes for casper in both the hosted and mirror areas then re-use that) | 11:22 |
| cjwatson | http://bazaar.launchpad.net/~ubuntu-core-dev/casper/trunk/ says "no changes!" rather than missing | 11:22 |
| spiv | cjwatson: bazaar.launchpad.net mapping of name->branch has a slight lag | 11:22 |
| spiv | cjwatson: so check again in say 2 minutes | 11:22 |
| gnomefreak | Kinnison: thanks i got it working | 11:23 |
| spiv | cjwatson: if https://code.launchpad.net/~ubuntu-core-dev/casper/trunk is 404 (and it is), bazaar.launchpad.net should follow suit shortly | 11:23 |
| cjwatson | ok, even if bzr barfed on that branch? | 11:23 |
| cjwatson | I wasn't sure of the level at which that stuff worked | 11:24 |
| cjwatson | aha, yes, it's 404 now | 11:24 |
| cjwatson | spiv: so that will definitely have moved aside all traces of the broken branch? | 11:24 |
| spiv | bazaar.launchpad.net stores branches internally by a fixed ID, and maps alls requests as they come in to the underlying ID. | 11:25 |
| cjwatson | oh, right, so no moving directories around required | 11:25 |
| spiv | Right. | 11:25 |
| * spiv -> food | 11:27 | |
| vila | cjwatson: now you can push the cleaned one on lp:~ubuntu-core-dev/casper/trunk | 11:27 |
| cjwatson | yep, in progress | 11:27 |
| vila | cjwatson: ok | 11:27 |
| Kinnison | gnomefreak: you're welcome | 11:32 |
| vila | cjwatson: looks like the new trunk has been uploaded, now you should be able to update lp:casper | 11:33 |
| cjwatson | vila: yep, I asked Mithrandir to do that a few minutes ago | 11:34 |
| cjwatson | (can't do it myself, I don't own the casper product) | 11:34 |
| vila | ha, ok | 11:34 |
| cjwatson | thanks for all the help, this is looking good now | 11:36 |
| vila | cjwatson: lp:casper is not updated yet though | 11:40 |
| cjwatson | yes, that will have to wait for Mithrandir to be present | 11:41 |
| cjwatson | I'm not in much of a rush there | 11:41 |
| vila | ok, as long as people needing the cleaned branch use the one you just uploaded, they should be fine | 11:42 |
| VSpike | To use bzr in windows, which works best overall - cygwin + windows port of bzr, or cygwin + cygwin port of bzr? | 12:31 |
| VSpike | I've used both - I'm currently using windows port without cygwin, but using the normal cmd prompt is driving me insane | 12:32 |
| poolie | VSpike, i'm not totally sure but i think the cygwin one works better within cygwin | 12:35 |
| poolie | and the windows one is better outside | 12:35 |
| poolie | the windows one comes with some Explorer integration, if that's useful | 12:35 |
| VSpike | poolie: thanks - I agree, the all-cygwin one worked OK for me mostly, once you get used to the quirks of cygwin and also hack it to make ssh work with bzr | 12:46 |
| VSpike | poolie: the explorer integration is not enough to make up for the horror of the windows command line :) | 12:46 |
| nDuff | aren't there alternatives available to cmd.exe? | 12:46 |
| * nDuff remembers... 4dos, was it?... from back in the day. | 12:47 | |
| VSpike | nDuff: yes, there's the windows power shell | 12:47 |
| nDuff | and I've heard Microsoft talking about how they were going to make a decent shell for a *long* while | 12:47 |
| VSpike | I thought about trying learn that, but decided i just didn't have enough time when i could better put my efforts into improving my bash skills | 12:47 |
| VSpike | their enhanced shell does look interesting but .. well, deadlines loom etc | 12:48 |
| poolie | VSpike, learn zsh :-) | 12:57 |
| poolie | like bash but a bit better | 12:57 |
| poolie | back to work... | 12:57 |
| VSpike | poolie: Ah yeah saw an article about it somewhere recenly | 12:58 |
| VSpike | will push it up the project queue :) thx | 12:58 |
| * nDuff has been using zsh for some time, and is constantly annoyed / trying to decide whether to go back to bash. | 12:59 | |
| nDuff | ...granted, though, the things that annoy me are probably configurable. | 12:59 |
| * vila trying export ANNOYING=False | 13:05 | |
| msq_ | Hi guys, after upgrading bzr on both ends I'm getting http://pastie.org/272628 | 13:20 |
| spiv | msq_: huh, weird. What versions on both ends? | 13:26 |
| msq_ | spiv: 1.6.1 | 13:26 |
| spiv | msq_: does "ssh <host> bzr --version" report the version you expect? | 13:26 |
| msq_ | spiv: that's it :) | 13:27 |
| msq_ | spiv: though, how do I change it | 13:27 |
| msq_ | spiv: I use bzr in my own PATH on the server | 13:27 |
| spiv | msq_: You can set BZR_REMOTE_PATH locally, or set bzr_remote_path in your locations.conf | 13:28 |
| msq_ | spiv: the latter on my server? | 13:29 |
| spiv | No, both on the client. | 13:29 |
| spiv | They are ways to configure the client to run a different path than just 'bzr' | 13:30 |
| msq_ | spiv: I assume that there is no server-side | 13:30 |
| msq_ | solution | 13:30 |
| msq_ | ? | 13:30 |
| spiv | Well, if you replace OpenSSH with something more configurable there is ;) | 13:30 |
| msq_ | spiv: heh ;) | 13:31 |
| spiv | But I don't know of a way to make OpenSSH run your .bashrc or whatever before running any command. And bzr doesn't have any feature on the server to workaround this, the client side is generally enough. | 13:31 |
| msq_ | spiv: thanks anyway! | 13:31 |
| spiv | It wouldn't surprise me if there's some magic setting for OpenSSH on the server to change this behaviour, but I haven't been able to find it. | 13:32 |
| msq_ | spiv: ok, everything works perfect, locations.conf updated | 13:35 |
| hsn_ | i really need python based installers for windows, anybody knows who is building them? | 14:02 |
| poolie | hsn_, as opposed to the exe installer? | 14:02 |
| matejcik | vila: are you there? | 14:03 |
| hsn_ | yes i need something like this http://launchpad.net/bzr/1.6/1.6beta3/+download/bzr-1.6b3.win32-py2.5.exe | 14:03 |
| poolie | hsn_, i think bialix was building them, but i might be behind the times | 14:05 |
| poolie | you could ask on the list | 14:05 |
| poolie | woo | 14:05 |
| poolie | test_remote is clearing up nicely | 14:05 |
| === mark1 is now known as markh | ||
| === kiko-zzz is now known as kiko | ||
| === kiko is now known as kiko-phone | ||
| vila | matejci1: back, sorry, I was in the basement for a central heating problem :-/ | 14:55 |
| matejci1 | vila: cool, now i'm back too | 14:58 |
| matejci1 | reporter of https://bugs.launchpad.net/bzr/+bug/269535 pointed me to you, said that you were working on it today | 14:58 |
| vila | and the heating is back too, we are all here, good | 14:58 |
| ubottu | Launchpad bug 269535 in bzr "bzr does not work with python2.6" [Medium,In progress] | 14:58 |
| matejci1 | i'm the guy who maintains python in opensuse, so this issue is kind of my responsibility | 14:59 |
| matejci1 | so is there anything i can help with? | 14:59 |
| vila | matejci1: phone, hold on | 14:59 |
| * matejci1 holds | 14:59 | |
| vila | back, pfew, some days.. | 15:05 |
| vila | ok, so, bzr supports python-2.4 and 2.5 | 15:05 |
| matejci1 | yes, and there's some subtle change that breaks it for python 2.6 | 15:05 |
| vila | I'm working on 2.6 and the last problem seems to related to our test framework | 15:06 |
| vila | so, out of our ~1300 tests there remains only 8 failing and I don't think there are really problematic | 15:07 |
| vila | yet, it will take time for python-2.6 to be truly supported, so if you want to include bzr in opensuse, it will be better to also include python-2.5 | 15:07 |
| vila | matejci1: is this possible ? | 15:08 |
| matejci1 | well... the thing is, that we only recently started working on the possibility of having two different pythons installed | 15:08 |
| vila | bah, s/1300/13000/ | 15:08 |
| matejci1 | so at least for 11.1 that probably won't happen | 15:08 |
| poolie | wow | 15:09 |
| poolie | are they really shipping only 2.6 even before 2.6 is released? | 15:09 |
| poolie | or am i just out of date | 15:09 |
| matejci1 | poolie: we're not -shipping- it, mind you | 15:09 |
| vila | and none of your packages that depends on python break ? Amazing... | 15:09 |
| matejci1 | poolie: python 2.6 release date is way before 11.1 release | 15:09 |
| poolie | heh | 15:10 |
| vila | when is 11.1 due ? | 15:10 |
| poolie | certainly if you're using ubuntu numbering and that's January 2011 :-) | 15:10 |
| vila | lol | 15:10 |
| poolie | i realize you're probably not :) | 15:10 |
| matejci1 | hah :e) | 15:10 |
| matejci1 | nope, its ... i'm not sure how the numbering works actually | 15:10 |
| matejci1 | 11.1 should be out in december or something | 15:10 |
| matejci1 | and yes, packages do break ... mostly the "wild" complex ones like bzr, scons... | 15:11 |
| poolie | vila, yay, my 261315 is all passing | 15:11 |
| poolie | i think it still needs packwards compatibility | 15:11 |
| matejci1 | strangely enough, twisted framework seems to work perfectly | 15:11 |
| vila | poolie: like hewlett packwards ? | 15:11 |
| vila | poolie: woot, was the last remaining one to use stacked branches on lp ? | 15:13 |
| poolie | realistically i think we will find some more | 15:13 |
| poolie | but, basically yes | 15:13 |
| vila | poolie: great | 15:13 |
| poolie | also i think the remote tests are now easier to read and debug | 15:13 |
| poolie | or at least the ones i've updated | 15:13 |
| vila | poolie: I'll look at that asap then :) | 15:15 |
| poolie | i was kind of fishing for reviews | 15:15 |
| poolie | so it may not be perfect but i want to sleep | 15:15 |
| poolie | if you can read it that would be good | 15:15 |
| poolie | it will be kind of large so don't rubber stamp it | 15:15 |
| vila | matejci1, poolie : I don't know how to proceed from there, but we need someone to pass the test suite with python-2.6 to ensure we don't regress | 15:15 |
| poolie | but hopefully it will be ok enough to do 1.7 roughly on schedule | 15:16 |
| poolie | multiple inheritance is annoying... | 15:16 |
| matejci1 | okay. where can i get the thing that needs testing? | 15:17 |
| vila | bug #261315 | 15:18 |
| ubottu | Launchpad bug 261315 in bzr "getting a stacked branch over the smart protocol fails with "Could not install revisions"" [Critical,In progress] https://launchpad.net/bugs/261315 | 15:18 |
| vila | errr | 15:18 |
| vila | bug #269535 | 15:19 |
| ubottu | Launchpad bug 269535 in bzr "bzr does not work with python2.6" [Medium,In progress] https://launchpad.net/bugs/269535 | 15:19 |
| vila | matejci1: do you have a working bzr ? | 15:20 |
| matejci1 | sure | 15:20 |
| vila | matejci1: use it to 'bzr branch lp:~vila/bzr/py26bzr' | 15:20 |
| vila | and file new bugs if you encounter problems | 15:21 |
| matejci1 | okay | 15:21 |
| vila | I intend to use that one for the first round and close it once the test suite fully pass | 15:21 |
| === kiko-phone is now known as kiko | ||
| poolie | vila, we can probably get 2.6 running inside pqm though it might be annoying | 15:32 |
| poolie | hm | 15:33 |
| poolie | no 2.6 at all in intrepid yet | 15:33 |
| vila | poolie: at least we should do that as we intend to do for windows and maybe osx ? | 15:33 |
| poolie | right | 15:33 |
| poolie | ok | 15:33 |
| poolie | patch sent, off to bed | 15:34 |
| matejci1 | alright, what's the official way to run the testsuite? | 15:34 |
| poolie | 'make check' or './bzr selftest' | 15:34 |
| poolie | first is more thorough | 15:34 |
| matejci1 | hmm ... i wonder what would happen if we made that run at build time... | 15:34 |
| vila | matejci1: as poolie said :) But if you have some plugins installed (and they fail to pass the test suite) you may try bzr selftest --no-plugins | 15:34 |
| poolie | matejci1, actually i think that would be a great idea | 15:35 |
| vila | matejci1: running it at build time will be perfect until we officially support it | 15:35 |
| poolie | it takes 10 minutes or so | 15:35 |
| poolie | depending on your hardware etc | 15:35 |
| matejci1 | that should be ok | 15:35 |
| matejci1 | but make check requires docutils, which we don't have... | 15:36 |
| matejci1 | selftest appears to work fine though | 15:36 |
| poolie | it would be good to get docutils so that you'll get html documentation for bazaar | 15:37 |
| poolie | ok | 15:37 |
| matejci1 | i'll leave that to bzr maintainer | 15:37 |
| poolie | note that you should probably run 'make' or some sub-targets | 15:37 |
| poolie | otherwise the binary extensions won't be built and it will be slow | 15:37 |
| matejci1 | setup.py build is sufficient? | 15:37 |
| poolie | that also works | 15:43 |
| matejci1 | ....heh, cool, turns out most of the extensions did not build because of missing pyrex. i'll end up rewriting the package beyond recognition | 15:44 |
| === mark1 is now known as markh | ||
| matejci1 | hahahaha | 15:55 |
| matejci1 | warnings.warn("this is your last warning") | 15:55 |
| james_w | :-) | 15:58 |
| === abadger1999_afk is now known as abadger1999 | ||
| matejci1 | vila: http://pastebin.ca/1203397 is test output | 16:01 |
| matejci1 | i don't like how it skips tests due to "missing feature" ... even though the modules do get compiled | 16:02 |
| matejci1 | but that is probably due to bad module paths... | 16:05 |
| vila | Are you running as root ? | 16:05 |
| matejci1 | yep | 16:05 |
| vila | try a regular user :D | 16:05 |
| matejci1 | that won't fly :ep this is a chrooted env | 16:06 |
| vila | Missing feature 'bzrlib._walkdirs_win32', obviously concerns windows only | 16:06 |
| vila | Missing feature 'FTPServer' skipped 94 tests => You need to install nedusa (python ftp server) | 16:06 |
| vila | Missing feature 'bzrlib._dirstate_helpers_c' and all that ends up with _c, you need pyrex and to run 'make' | 16:08 |
| matejci1 | i have that | 16:08 |
| matejci1 | but this is before installation, in the source dir | 16:08 |
| vila | you did run make ? | 16:08 |
| matejci1 | so those .so aren't on pythonpath | 16:09 |
| matejci1 | that's what i'm trying to work around now | 16:09 |
| vila | ./bzr selftest isn't enough ? | 16:09 |
| matejci1 | doesn't seem to be ... should it? | 16:09 |
| vila | AFAIK, if you're running from sources, yes | 16:10 |
| matejci1 | okay let me find out what exactly happens | 16:10 |
| matejci1 | well ... correct me if i'm wrong but that can't work | 16:11 |
| matejci1 | the .so are in build/lib.linux.blabla/bzrlib | 16:12 |
| matejci1 | but when bzr says import bzrlib, it takes the bzrlib directory from source tree root | 16:12 |
| matejci1 | completely avoiding the .so libraries | 16:12 |
| matejci1 | and there doesn't seem to be anything to override this in sys.path.. | 16:12 |
| vila | forget the build directory | 16:14 |
| vila | make build the .so in the bzrlib directory | 16:15 |
| vila | build is a selftest produced directory, arguably a leak :) | 16:15 |
| matejci1 | hmm, indeed | 16:16 |
| matejci1 | is it possible to run only tests for the .so modules? | 16:16 |
| === kiko is now known as kiko-phone | ||
| vila | there are ways, but we risk spending more time establishing the list of tests than just re-running the whole ;) | 16:18 |
| matejci1 | whatever, just give me one ;e) i don't want to spend 10 minutes just to see "sorry your libraries didn't load" | 16:22 |
| matejci1 | ah, i get it now | 16:24 |
| matejci1 | "make" places the .so's in bzrlib/ | 16:24 |
| matejci1 | "python setup.py build" doesn't | 16:24 |
| rockstar | Can I use a wildcard in my locations.conf ? | 16:25 |
| vila | matejci1: haaa, one is another story :) | 16:27 |
| vila | matejci1: try ./bzr selftest -s bzrlib.tests.test__dirstate_helpers -v | 16:30 |
| vila | it should run in less than one second and show you which tests are skipped (if any) for which feature | 16:31 |
| vila | well, for the bzrlib._dirstate_helpers_c feature | 16:31 |
| vila | matejci1: did the Exception class hierarchy changed in 2.6 ? | 16:34 |
| matejci1 | i'm not sure | 16:34 |
| matejci1 | i've lost the list of changes ;e) | 16:34 |
| matejci1 | let me find it | 16:34 |
| matejci1 | well, nothing about Exceptions is in PEP361, so i assume that if something changed, it did in a slight, almost unnoticeable way. just like the __init__ thing | 16:36 |
| vila | :) | 16:39 |
| vila | export PY_CRY_OUT_LOUD_ON_SLIGHT_ALMOST_UNNOTICEABLE_CHANGES=42 | 16:40 |
| matejci1 | - Issue #1537: Changed GeneratorExit's base class from Exception to BaseException. | 16:40 |
| matejci1 | this is what i found, only mention of exception hierarchy in NEWS. that should be much more trustworthy | 16:40 |
| matejci1 | why does "internaly performed glob", "utf8filesystem" and "unicodefilename" skip? | 16:41 |
| vila | that's NEWS in Misc/ directory from sources right ? | 16:41 |
| matejci1 | yes | 16:41 |
| matejci1 | ....and why do i now skip 1138 tests, even though i have more features? | 16:42 |
| vila | how many were you skipping before ? | 16:42 |
| matejci1 | 800something, iirc | 16:42 |
| matejci1 | yes, 841 | 16:42 |
| vila | hmmm, I don't really know from here :-/ | 16:43 |
| matejci1 | http://pastebin.ca/1203434 there's a new selftest output | 16:44 |
| vila | the first one is caused by running as root I think (per_lock.test_lock.TestLock.test_readonly_file(fcntl) ) | 16:46 |
| matejci1 | i see | 16:46 |
| matejci1 | then there's a bunch about missing thread.get_name | 16:46 |
| matejci1 | oh, but those aren't failures | 16:46 |
| matejci1 | but appear to break stuff anyway | 16:47 |
| vila | I can't reproduce that one ( thread.get_name) but it's highly suspicious of either a 2.6 bug or an change not backward compatible | 16:47 |
| vila | all the PROXY ones seems due to a surprising change in SokectServer.py (currently trying to fix or work around that one) | 16:48 |
| matejci1 | let's see what NEWS say about get_name | 16:48 |
| matejci1 | .....nothing | 16:49 |
| matejci1 | wait a minute | 16:49 |
| matejci1 | the method name is supposed to be getName, not get_name | 16:49 |
| vila | right and this is in python2.6/threading.py... | 16:51 |
| matejci1 | hmm, indeed | 16:51 |
| === bobbo_ is now known as bobbo | ||
| matejci1 | that makes sense - they were renaming the methods to python naming convention (underscores), apparently didn't do a good enough job | 16:52 |
| matejci1 | lemme fix it and retry | 16:52 |
| vila | you seem to running python2.6b3, I'm running python2.6rc1 do you know who got the older one ? | 16:53 |
| vila | s/to/to be/ | 16:53 |
| matejci1 | you have the newer one | 16:53 |
| matejci1 | i'm going to package rc1 now | 16:53 |
| matejci1 | should be straightforward, too | 16:53 |
| === mark1 is now known as markh | ||
| matejci1 | get_name was python's fault, it works fine on 2.6rc1 | 17:35 |
| vila | matejci1: ok, I will stop shortly, at least for one run, all the proxy related tests succeeded, so I strongly suspect a python bug, especially since now, when I try to catch the exceptions related to error: (9, 'Bad file descriptor'), I get either socket.error or select.error exceptions | 17:44 |
| vila | none of which occurred with 2.5 and the modified code in SocketServer.py having some XXX, now use select with a timeout (I rely on a blocking behavior) | 17:46 |
| vila | all in all, a can of worms that needs a fresh mind :) | 17:46 |
| LarstiQ | vila: you take your rest now :) | 17:46 |
| vila | LarstiQ: indeed :) | 17:46 |
| matejci1 | okay, i'll follow suit and go home get some sleep ;e) | 17:47 |
| matejci1 | (down to 841 skips, making much more sense) | 17:47 |
| nandersson | Verterok, hurray!!! I can branch directly from Launchpad :-) Thanks tons for fixing this :-) Great job! | 17:47 |
| nandersson | Using BzrEclipse that is :-) | 17:48 |
| LarstiQ | nandersson: what are you branching? (I see you're in some blender channels as well) | 17:49 |
| nandersson | LarstiQ, I tested with some stuff from my personal archives in Launchpad | 17:49 |
| nandersson | Regarding Blender I'm investigating how to get the 3D-controllers from 3DConnexion to work :) | 17:50 |
| LarstiQ | aaah | 17:50 |
| LarstiQ | nandersson: good luck with that :) | 17:51 |
| nandersson | Have you seen those? | 17:51 |
| LarstiQ | not in real life, but yes | 17:51 |
| nandersson | I'm also covering F/OSS for Swedish netmag Techworld Open Source and bzr+bzreclipse is an important implementation | 17:54 |
| nandersson | That together with Launchpad will hopefully speed up development | 17:54 |
| === kiko-phone is now known as kiko | ||
| === kiko is now known as kiko-fud | ||
| Verterok | nandersson: glad you like it! (you can branch directly from a project into a new one too ;) ) | 17:56 |
| nandersson | Verterok, yes I saw that :-) Very impressive stuff!! | 17:58 |
| Verterok | nandersson: thanks, more comming soon :-) | 17:59 |
| nandersson | Verterok, hehe, with this I'm more than happy :-) Launchpad+Eclipse is now a one-stop-shop | 18:00 |
| Verterok | nandersson: and with mylyn integration should be awesone ;) | 18:02 |
| nandersson | Verterok, Yes, the possibilities are mind blowing :-) | 18:12 |
| nandersson | ...and now with all Ubuntu-packages under distributed version control :-) Very exiting times indeed | 18:12 |
| justizin | nandersson: i've also wondered about 3dconnexion and blender. have you met #blender? | 18:14 |
| justizin | my understanding is that it requires linking to their libs somehow. | 18:14 |
| nandersson | justizin, I don't know but there has been experimental support for 3dconnexion in blender for quite some time, but it seems that the support is still not in main. | 18:23 |
| nandersson | justizin, I asked in #blendercoders | 18:24 |
| justizin | ah right on, so maybe it's in the experimental tree.. ipthopthotet or whatever it's called ;d | 18:24 |
| justizin | blender, iirc, isn't too much trouble to build. what platform are you on? | 18:24 |
| justizin | anyway whatev. have fun. :) | 18:24 |
| * justizin back to bzr-ing | 18:25 | |
| LarstiQ | justizin: I'm going shopping for food, after that maybe we can talk about nested trees? (svn:externals) | 18:38 |
| justizin | that would rawk! | 18:40 |
| justizin | i'll be around | 18:40 |
| mthaddon | have upgraded the version of bzr that's being used by PQM to 1.6.1 - if anyone experiences any issues, please let me know | 18:40 |
| justizin | actually, i should also go shopping for food, but ... meh. ;d | 18:40 |
| vila | mthaddon: thanks, I'll keep you informed about my next submissions :) | 18:58 |
| === ozzloy is now known as they | ||
| === they is now known as ozzloy | ||
| justizin | um, i just commited some renames from one directory to another, pushed via ssh, 'bzr update' on the server says the tree is up to date, but the changes are not proliferated. am i missing something? | 20:08 |
| beuno | vila, hi! Have you seen bug #270219 ? | 20:09 |
| ubottu | Launchpad bug 270219 in bzr-upload "File contents are not updated when a revision also renames the file" [Undecided,New] https://launchpad.net/bugs/270219 | 20:09 |
| vila | beuno: yes, surprising, I didn't find the time to write the test to confirm it, that's shouldn't be hard | 20:11 |
| vila | beuno: and you catch me just passing in front of my computer, I'm not there :) | 20:11 |
| vila | beuno: but we shoud chat some day ;) | 20:12 |
| beuno | vila, heh, ok ok. Just wanted to see if you'd seen it | 20:12 |
| beuno | yes we do! | 20:12 |
| beuno | I'm usually around from 13UTC on | 20:12 |
| justizin | LarstiQ: reading some of the nested tree details, would love to give some input, some good ideas but also some things need to be optional, like fetching subtrees (sometimes you just want to check out the master, to change the subtree locations, or just to make minor edits without trying to run or compile) | 20:43 |
| epsy | hi, i'm getting trouble using my launchpad account | 20:43 |
| epsy | i recently changed my "name" on launchpad, i changed bzr launchpad-login, but bzr up fails telling me that there is no "epsy46" account on launchpad | 20:43 |
| LarstiQ | justizin: something like --ignore-externals? | 20:44 |
| epsy | bzr launchpad-login tells me my account is "epsy" | 20:44 |
| LarstiQ | justizin: you can play with https://code.edge.launchpad.net/~larstiq/bzr/nested-trees to see what the status is at | 20:44 |
| LarstiQ | epsy: hmm | 20:44 |
| === kiko-fud is now known as kiko | ||
| nandersson | epsy, Do you have the correct name in ~/.bazaar/bazaar.conf? | 20:45 |
| justizin | LarstiQ: yeah, i thought you might be aware, just didn't see it in the notes / status.. | 20:45 |
| justizin | i'll check out the tree and give it a spin. | 20:45 |
| LarstiQ | epsy: is your branch bound to epsy46@... ? | 20:45 |
| LarstiQ | justizin: to be truthful, development has been very stagnant | 20:46 |
| mbt | Anyone run into an issue with bzr on Win32 (XP) accessing a https:// repo? Am getting an error in bzr 1.7rc1 thrown from pycurl, saying 'error: (65, "necessary data rewind wasn't possible")' | 20:46 |
| epsy | LarstiQ, indeed | 20:46 |
| mbt | I am able to check out the same repository on a Linux box with bzr just fine. | 20:46 |
| LarstiQ | mbt: that one is new to me | 20:46 |
| mbt | I did find one mention of it here on 8/29, but no fix was mentioned: http://irclogs.ubuntu.com/2008/08/29/%23bzr.txt | 20:46 |
| LarstiQ | mbt: does it do that with https+urllib:// as well? | 20:47 |
| mbt | can try that | 20:47 |
| epsy | LarstiQ, thanks, got it solved | 20:47 |
| LarstiQ | mbt: bug 207734 and bug 241698 might be relevant | 20:47 |
| ubottu | Launchpad bug 207734 in bzr "push on bzr+http, pycurl fails with: necessary data rewind wasn't possible" [Undecided,Incomplete] https://launchpad.net/bugs/207734 | 20:47 |
| LarstiQ | epsy: cheers | 20:47 |
| ubottu | Launchpad bug 241698 in bzr "POST to authenticating proxy causes "necessary data rewind wasn't possible" error" [Undecided,New] https://launchpad.net/bugs/241698 | 20:47 |
| justizin | LarstiQ: yah i see it is based on bzr 0.15 O.o | 20:49 |
| LarstiQ | justizin: last I really touched it was the sprint in may this year or so? | 20:50 |
| mbt | LarstiQ: Yeah, https+urllib:// worked, but plain https:// did not | 20:59 |
| LarstiQ | mbt: right, without the urllib decorator you're using pycurl | 21:01 |
| LarstiQ | mbt: did you see the bugs I mentioned? | 21:01 |
| mbt | Yes, though this one is without a proxy, so I am going to guess that the problem has to be with pycurl and is more fundamental, though what it is I've not a clue | 21:02 |
| LarstiQ | mbt: if you could comment that on 241698, then we can prod spiv again that there's more information | 21:06 |
| mbt | LarstiQ: Will do, thanks | 21:06 |
| LarstiQ | mbt: other than that, I've stopped using pycurl a while ago. Did it get installed with the windows installer, or did you install it seperately? | 21:06 |
| mbt | Windows installer, from the launchpad page | 21:07 |
| mbt | First Python app on the machine, so I assume its bundled | 21:07 |
| LarstiQ | thanks | 21:07 |
| LarstiQ | markh, vila: are there reasons to not drop pycurl from the bundled win32 installer? | 21:08 |
| === BasicPRO is now known as BasicATT | ||
| nandersson | I filed an idea at Brainstorm "Integrate bzr-builddeb in Eclipse" http://brainstorm.ubuntu.com/idea/13260/ | 21:34 |
| beuno | Verterok, cool! Verterok will be very please | 21:35 |
| === thumper_laptop is now known as thumper | ||
| * Verterok looks | 21:37 | |
| Verterok | nandersson: cool :) | 21:42 |
| nandersson | As long as bzr-builddeb is installed it's a matter of executing bzr bd in the root directory - the file ends up in ../buildarea | 21:43 |
| james_w | nandersson: "bzr bd lp:update-manager" | 21:43 |
| vila | LarstiQ: pycurl validates ssl certificates, urllib doesn't, I wonder why I've never thought about making urllib the default for http, yet leaving pycurl the default for https...The least I could now is to send a one-lie patch on the list to get it discussed | 21:43 |
| * vila off to bed | 21:43 | |
| james_w | or rather a URI that works | 21:44 |
| * nandersson looks into lp:update-manager :-) | 21:44 | |
| * vila coughs one li*n*e-patch, where do I find my typos.... | 21:44 | |
| LarstiQ | vila: it brought a smile to my face though :) | 21:44 |
| nandersson | james_w, That's cool! Didn't knew you could do that :-) | 21:47 |
| james_w | nandersson: thanks jelmer | 21:47 |
| nandersson | james_w, Then perhaps the next thing would be to specify where to store the files? As in the Personal Package Archive for example? | 21:51 |
| james_w | nandersson: yeah, I don't know about automatically uploading | 21:52 |
| nandersson | james_w, Then my idea would basically already be implemented - just build a wrapper around it in Eclipse | 21:53 |
| nandersson | That runs the command | 21:53 |
| nandersson | bzr bd lp:my-package my-personal-package-archive | 21:53 |
| Verterok | nandersson: you could setup a external tool in eclipse to run the command, in the meantime | 21:54 |
| nandersson | Verterok, Yes, you're right, I can create my own script :-) | 21:55 |
| awilkins | I keep having problems with Pycurl too | 23:07 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!