| mwhudson | hmm | 00:02 |
|---|---|---|
| lifeless | mwhudson: ? | 00:27 |
| mwhudson | lifeless: nm :) | 00:28 |
| poolie | good morning bzr! | 00:29 |
| lifeless | hi poolie | 00:34 |
| igc | morning | 00:38 |
| kingos | lifeless: thanks for your help so far with my bug 356028. Where do we go from here? | 00:40 |
| ubottu | Launchpad bug 356028 in bzr "bzr check fails with KeyError" [Undecided,New] https://launchpad.net/bugs/356028 | 00:40 |
| * igc continues reviewing the check patch from lifeless | 01:25 | |
| * igc lunch | 04:03 | |
| lifeless | igc: what -Dprogress changes? | 04:36 |
| lifeless | igc: oh, I see it. | 04:44 |
| igc | lifeless: ui/text.py + some doc in debug-flags & NEWS | 04:48 |
| lifeless | yah | 04:49 |
| lifeless | I can split it out if needed, but it seems like make-work | 04:49 |
| rockstar | lifeless, around? | 07:22 |
| lifeless | yes | 07:23 |
| rockstar | lifeless, scenario: I have a working tree with changes in it from a merge. How can I get the revisions that are being merged into this tree? | 07:25 |
| lifeless | cli or lib? | 07:28 |
| rockstar | lifeless, lib | 07:28 |
| rockstar | lifeless, it looks like WorkingTree.changes_from(WorkingTree.basis_tree).modified will give me a list of tuples in which index 1 is a rev id. | 07:29 |
| lifeless | tree.get_parent_ids() returns a vector | 07:29 |
| lifeless | 0 is the tree's commit (which may not be the branch tip if the tree is stale) | 07:30 |
| lifeless | 1 is the first merge | 07:30 |
| lifeless | etc | 07:30 |
| lifeless | then use tree.branch.repository (or some other repo if needed) to get a graph - r.get_graph() | 07:30 |
| rockstar | Hm. That's a bit sub-optimal. The WorkingTree is a checkout, both branches are remote branches (on Launchpad) | 07:31 |
| lifeless | if you want all the 'new revs' you can use one of the difference functions in the graph object (pydoc bzrlib.graph.graph) to get the new revs | 07:31 |
| lifeless | the tree doesn't store or cache the new revs details | 07:31 |
| rockstar | Yea, all I want is the revs that will be merged in the merge. | 07:31 |
| lifeless | if you want the revs that will be the parents of the new commits, it is precisely tuple(tree.get_parent_ids()) | 07:32 |
| lifeless | assuming this is for tarmac; it sounds like you're reproducing some aspect of bzr core - is there some higher level functio that isn't quite right? | 07:33 |
| rockstar | Well, ideally, I want all the revs that will be part of the merge, i.e. the source branch may have 10 revisions with 3 different authors. I want to find those 3 authors. | 07:33 |
| lifeless | ok, then do the graph bit I referenced above | 07:33 |
| rockstar | You mean bzrlib.graph.Graph ? | 07:34 |
| lifeless | tree.branch.repository.get_graph(), and then one of the functions there can give you the difference data | 07:34 |
| lifeless | bzr status -v does precisely this | 07:35 |
| lifeless | in terms of performance; firstly lightweight checkouts over the internet are slow. | 07:35 |
| lifeless | I don't recommend that lightweight checkouts ever be used over the net | 07:35 |
| lifeless | but even so - you need the revision graph, so there really isn't anyway around it: you either have it locally, or you don't :) | 07:36 |
| rockstar | It's not lightweight. It's similar to what PQM does, if I'm not mistaken. | 07:36 |
| rockstar | Although Tarmac is pretty worthless if the net goes away. | 07:36 |
| lifeless | if its a heavyweight checkout then you have the revision data locally | 07:37 |
| rockstar | Okay. That's good. | 07:37 |
| rockstar | But that local revision data is still gotten through tree.branch.repository, correct? | 07:37 |
| lifeless | yes | 07:38 |
| lifeless | the branch oobject will be a local bound branch | 07:38 |
| rockstar | Ah, that's nice. I always wondered what the difference was between lightweight and heavyweight checkouts. | 07:39 |
| vila | hi all | 07:41 |
| poolie | hey vila | 07:46 |
| poolie | spiv, how did you go today? | 08:13 |
| spiv | poolie: good so far. A little bit of API friction but nothing serious. | 08:15 |
| spiv | I have StreamSource producing inventory delta records and StreamSink consuming them successfully in-process, I think. I haven't done a full test suite run yet though. | 08:19 |
| lifeless | spiv: I'm inclined to have it in the normal SS and SS | 08:20 |
| lifeless | spiv: rather than subclasses; what do you think? | 08:20 |
| lifeless | spiv: (your text implies you agree, just putting it out there for explicit consideration) | 08:20 |
| spiv | lifeless: yes, that's definitely my preference, and how it's implemented so far. | 08:21 |
| spiv | The only real impediment to that I think is making sure it can operate compatibly with network sinks/sources that can't take inv deltas, I haven't poked much at that yet but I'm sure it's not going to be too bad. | 08:23 |
| lifeless | spiv: I think we should define them as all taking them | 08:23 |
| lifeless | its why I made this a critical bug, so it would be in place for 2.0 and not need bumping then | 08:23 |
| poolie | well | 08:24 |
| spiv | Sure, but there are 1.16 and earlier servers (and clients) that can't. Possibly we can just make RemoteStreamSink/Source translate delta->fulltext before passing to the network serialisation layer. | 08:24 |
| poolie | ^w | 08:25 |
| lifeless | spiv: on a missing verb condition? yes, for push. pull will get the missing verb asking for the stream. | 08:25 |
| spiv | (iff the network layer knows that the other end can't cope with inv delta recods) | 08:25 |
| spiv | Right. Like I said, I don't think it's too hard to deal with. | 08:26 |
| lifeless | agreed | 08:27 |
| lifeless | EOD | 08:31 |
| poolie | spiv, so when you say in process you mean it works doing a cross-format local pull? | 08:35 |
| poolie | or push | 08:35 |
| spiv | poolie: right. | 08:35 |
| vila | spiv: do you know how to bind a class method into an instance method explicitly ? | 08:45 |
| vila | spiv: re-reading my question I now have doubts about the means :) The need is: I want to decide at load_tests() time what method will be called inside setUp. I don't want to have a test in setUp, I want a single raw call | 08:48 |
| spiv | vila: I don't quite follow your question. | 08:56 |
| spiv | Or what problem you are trying to solve :) | 08:56 |
| vila | spiv: I want parametrized tests to call a method during setUp. I want to define that method in load_tests. I refer to that method by its name, so I get the class attribute, | 08:58 |
| vila | If I make a call with attribute, it's an unbound method | 08:58 |
| vila | If I make a call with that attribute, it's an unbound method | 08:58 |
| vila | spiv: my current workaround is to do: self._do_changes(self) | 08:59 |
| vila | and that's ugly :) | 08:59 |
| spiv | I don't understand why it would be an unbound method in that case. | 08:59 |
| spiv | There's some part of this picture I don't see :) | 08:59 |
| spiv | if you do "x = object.method", then "x" will be a bound method (assuming no wacky descriptors like property, staticmethod, etc) | 09:00 |
| vila | spiv: because the test object is created and then self.do_change receive class.method because the test instance doesn't exist when load_tests is called | 09:00 |
| lifeless | vila: ?! | 09:01 |
| lifeless | vila: pastebin your code | 09:01 |
| lifeless | vila: you're doing something special | 09:01 |
| spiv | vila: so you're doing "x = klass.method", because you don't have an instance of the object yet? | 09:01 |
| spiv | (why?) | 09:01 |
| spiv | In that case, yes, you should do what you're doing. | 09:01 |
| spiv | There's probably a way to bind it post hoc, but I'd avoid the magic. This sounds like a strange thing to be doing, though. | 09:02 |
| vila | http://paste.ubuntu.com/206061/ | 09:02 |
| poolie | i'm going to stop soon... | 09:03 |
| vila | spiv, lifeless: I realize I shouldn't run into that, that's why I ask where I went wrong :) | 09:04 |
| vila | poolie: g'night | 09:04 |
| spiv | vila: so I think that's as clean as you can make that approach with current APIs | 09:05 |
| vila | spiv, lifeless : An other way to do what I want is to use the *name* of the method, but it's not very elegant either :-/ | 09:05 |
| lifeless | so to paraphrase | 09:06 |
| lifeless | you want to run a set of tests in a class, twice | 09:06 |
| spiv | vila: because multiply_tests doesn't give you any way to read attributes off the test cases you are multiplying, just assign to them. | 09:06 |
| lifeless | changing one function call from A to B | 09:06 |
| vila | spiv: yes | 09:06 |
| vila | lifeless: yes | 09:06 |
| spiv | vila: (and you really would want to make sure that if it did it that the bound methods were bound to the right TestCase instance!) | 09:06 |
| lifeless | vila: file a bug on testscenarios if you would; this is interesting :) | 09:07 |
| spiv | vila: personally I think I would have gone with the name of the method and a getattr | 09:07 |
| spiv | getattr at call time, that is, obviously. | 09:08 |
| vila | spiv: Yeah, that's what I thought, thanks | 09:08 |
| spiv | Because "here's the name of the method" is a very clear indirection point. | 09:08 |
| vila | lifeless: will do, thanks too :) | 09:08 |
| spiv | And also because that would consume less memory I think ;) | 09:08 |
| vila | spiv: and can be explicitly checked at setUp time, right | 09:09 |
| spiv | Creating methods via assigning callables to instances is pretty cool, but it's easy for it to be confusing. | 09:09 |
| vila | spiv: well, the same can be said about any technique you don't practice often | 09:10 |
| lifeless | def do_dirty_tree: | 09:10 |
| lifeless | getattr(self, change_method)(self) | 09:10 |
| spiv | Well, yes, but particularly with dynamic features where you can't e.g. look up _do_changes in your tags file an get taken to the method definitino. | 09:10 |
| vila | spiv: I don't think cricket rules are so confusing since my last trip to Australia for instance :-D | 09:10 |
| spiv | vila: do you remember how many ways there are to get out? :) | 09:11 |
| * vila looks behind him, but no, lifeless isn't reading above his shoulder :) | 09:12 | |
| vila | spiv: no. But I think I could understand when it happens when watching a game... | 09:12 |
| spiv | (http://en.wikipedia.org/wiki/Laws_of_cricket#Ways_to_get_out has the answer) | 09:12 |
| vila | 42 laws... now, *that's* says a lot about H2G author :-) | 09:14 |
| vila | err HG2 | 09:14 |
| poolie | vila, having what looks like a test class but only exists to provide those mixin bits seems not quite right | 09:18 |
| poolie | hm | 09:18 |
| vila | lifeless: https://bugs.edge.launchpad.net/testscenarios/+filebug :-P | 09:18 |
| lifeless | vila: bah humbug | 09:19 |
| vila | poolie: creating a mixin just for creating a mixin ? | 09:19 |
| poolie | using the word mixin loosely | 09:19 |
| lifeless | vila: one way would be to write those mutators as standalone functions that take a test case object | 09:19 |
| vila | poolie: Right, I see your point | 09:19 |
| lifeless | vila: testscenarios has a functional feel | 09:19 |
| poolie | in parts... | 09:19 |
| poolie | not so much in | 09:20 |
| poolie | + tests.multiply_tests(changes_tests, changes_scenarios, result) | 09:20 |
| lifeless | using the word functional loosely :P | 09:20 |
| poolie | that line was just annoying me | 09:20 |
| lifeless | vila: fixed | 09:20 |
| poolie | it's a shame it doesn't return a thing for you to use | 09:20 |
| vila | poolie: so that I can assign the right method there you mean ? | 09:21 |
| vila | I'm quite happy with getattr(self, self._do_changes)() | 09:21 |
| vila | I'ts clear, light and robust | 09:22 |
| poolie | so i was going to theorize thatn | 09:22 |
| poolie | if you want more power in your test multiplication stuff | 09:23 |
| poolie | you're probably doing it wrong | 09:23 |
| poolie | as they say | 09:23 |
| poolie | like, trying to test too many combinations | 09:23 |
| poolie | presumably the effects of strictness are separated in the code from the determination of whether we're strictly ok or not? | 09:23 |
| poolie | vlia, what i was going to say about the mixin class is, why not put do_uncommitted_changes and do_pending_merges into the TestPushStrict class | 09:24 |
| poolie | if they're only used there | 09:24 |
| poolie | and then, um | 09:25 |
| poolie | getattr(self, self._type_of_changes) | 09:25 |
| jml | vila, rugby union also has laws | 09:26 |
| vila | poolie: it seems we all agree about getattr(self, self._do_changes)() | 09:26 |
| vila | jml: well, the point is, I once watched a cricket match, and when one team burst out in joy, I was puzzled about why :) | 09:28 |
| vila | jml: at least in rugby you get some understanding that when the ball pass the line, points are scored :) | 09:28 |
| poolie | > Results 1 - 10 of about 1,210,000 for rugby scandal | 09:29 |
| spiv | vila: depends on which line :) | 09:29 |
| poolie | vila: :) my new bit, maybe, is suggesting you fuse the classes | 09:29 |
| poolie | also, i think _do_changes is not such a good name | 09:29 |
| poolie | because it actually sounds like a method | 09:29 |
| poolie | but you can't _do_changes | 09:30 |
| poolie | i mean, you can't _do_changes() | 09:30 |
| spiv | Sometimes the ball passes a line and then they stand in a funny formation and just toss it back over the line ;) | 09:30 |
| poolie | oh like basketball? :) | 09:30 |
| vila | poolie: I may be overtesting here, but yet, the full test suite reveals at least one bug when I make --strict the default for push (push can be used without tree and I wasn't testing that) | 09:31 |
| spiv | Yeah, a variable name that clearly indicates "this variable is the name of a method" rather than "this variable is a method" would be good I think. | 09:31 |
| poolie | vila: nice one | 09:31 |
| poolie | and fair enough | 09:31 |
| poolie | on further consideration | 09:31 |
| poolie | i think one reason to put the methods in their class is to make it clear how much stuff they apply to | 09:31 |
| vila | spiv: but they are having some kind of discussion when they stand in that funny formation, not a single team piling up with joy :) | 09:32 |
| poolie | parameterization is kind of action-at-a-distance | 09:32 |
| poolie | which can be confusing | 09:32 |
| poolie | so the more you do to reduce the distance and make it clear, the better | 09:32 |
| spiv | poolie: right | 09:32 |
| abeaumont_ | vila: i'm playing with bzr-upload testsuite, i'm trying to add a test for my branch, but i've seen that many tests are disabled due to not having FtpServer feature, i installed test_local_server but even with the plugin (and installing anon proftpd) it didn't work, looking at the code i'm not sure it should work... should it? | 09:32 |
| vila | poolie: yes, | 09:32 |
| vila | abeaumont_: short: you want to install muddleftp | 09:33 |
| vila | abeaumont_: long: local_test_server is used to *inject* real ftp servers into the test suite | 09:33 |
| spiv | poolie: and also it helps make clear what facilities the methods can use (i.e. a method on a TestCaseWithTransport can obviously use self.make_branch, a free function somewhere less clearly so). "Action at a distance" is a key part of the problem, I think. | 09:34 |
| vila | spiv: I agree with that | 09:34 |
| vila | poolie: my intent in defining more classes here is that it's better than a single one for clarity. It may not be pure enough for application code, but the classes are final here, so any reader can focus on trivial test code without the need to read more classes | 09:36 |
| * igc dinner | 09:36 | |
| abeaumont_ | vila: ah, ok, i'll look at muddleftp. Thanks! | 09:37 |
| vila | abeaumont_: eerk, memory playing tricks, I meant: http://code.google.com/p/pyftpdlib/ | 09:38 |
| vila | abeaumont_: bzrlib supports medusa and pyftplib, but medusa is bogus starting with python2.6 | 09:39 |
| vila | abeaumont_: look at bzrlib/tests/ftp_server directory for all the details | 09:39 |
| abeaumont_ | vila: ok, thanks again :) | 09:47 |
| abeaumont_ | vila: i was surprised to see that my broken code didn't cause any test to fail, until i used verbose :D | 09:48 |
| vila | abeaumont_: hmm, but even the non verbose mode should tell you about skipped tests no ? | 09:48 |
| abeaumont_ | vila: yes, but i didn't take it too seriously (FtpServer? my trivial test doesn't need such a thing :) | 09:50 |
| vila | abeaumont_: :) | 09:50 |
| nil1 | Hi | 09:57 |
| nil1 | Is the encrypted repository format already usable? | 09:58 |
| jml | hmm. | 10:02 |
| vila | lifeless: ./bzr selftest '(?i)loom' => FAILED (failures=3, errors=6) :-} | 10:08 |
| vila | lifeless: no offence intended, just a data point :-D | 10:08 |
| \sh | lifeless: bug #81689 , well this could be a nice workaround, but in general I would like to see that behaviour fixed on MS Windows :) | 10:50 |
| ubottu | Launchpad bug 81689 in bzr "Branches with symlinks can't be checked out on Windows" [Medium,Triaged] https://launchpad.net/bugs/81689 | 10:50 |
| === mvo__ is now known as mvo | ||
| TheJosh1337 | Hi | 12:58 |
| TheJosh1337 | Does anyone know of a tool that I can use to generate merge graphs for a bzr repo? | 12:58 |
| TheJosh1337 | like 'bzr visualise' | 13:02 |
| TheJosh1337 | I wan't to show a commit history graph on a web page | 13:06 |
| vila | TheJosh1337: bzr qlog | 13:06 |
| vila | ha, that's different, I thought you wanted bzr viz for all branches in a shared repo | 13:07 |
| TheJosh1337 | What I want is a generated image file which I can dump onto a website | 13:08 |
| vila | You want to ask again to beuno maybe, or garyvdm (but he's off-line right now) | 13:08 |
| TheJosh1337 | showing the commits and merges made to trunk | 13:08 |
| TheJosh1337 | or become friendly with the PHP gd commands | 13:08 |
| TheJosh1337 | beuno, is there a program that is similar to bzr viz, but which generates an image file appropriate for embedding on a web page? | 13:10 |
| asabil | TheJosh1337: I think bzrtools has something like that | 13:11 |
| asabil | it generates a graphviz file iirc | 13:11 |
| TheJosh1337 | cool | 13:11 |
| TheJosh1337 | sweet that's perfect thanks!q | 13:14 |
| TheJosh1337 | asabil, Thank you that was perfect. The tool generates .pngs native, so it's perfect. | 13:55 |
| TheJosh1337 | im off now, going to bed | 13:55 |
| === mrevell is now known as mrevell-lunch | ||
| === mrevell-lunch is now known as mrevell | ||
| === abentley1 is now known as abentley | ||
| === bac` is now known as bac | ||
| beuno | vila, hi! | 15:12 |
| vila | beuno: good morning ;-) | 15:13 |
| beuno | vila, good afternoon | 15:13 |
| beuno | how are you? | 15:13 |
| vila | beuno: fine, you ? | 15:14 |
| beuno | vila, pretty good as well | 15:14 |
| beuno | want to help me out with a small OSX issue? | 15:14 |
| beuno | I need bzr 1.16 working on 10.5 :) | 15:14 |
| vila | let's try | 15:14 |
| vila | beuno: let me guess, you have the C files for the extensions ? | 15:15 |
| beuno | vila, I haven't done anything, the guy always uses the installer | 15:15 |
| beuno | and there's only one available for 1.14 | 15:15 |
| vila | oh, damn, phanatic where are you ? :-/ | 15:16 |
| vila | hmm, wait didn't someone create an installer for 1.16 ? | 15:16 |
| beuno | and I impulsively upgraded all branches at the office to 2a | 15:16 |
| beuno | and I left out one of the guys who uses 10.5 | 15:16 |
| verterok | beuno: just use 1.16 from source | 15:17 |
| beuno | verterok, how do I tell him to do that? :) | 15:17 |
| vila | verterok: can't you 10.4 installer be used on 10.5 ? | 15:17 |
| vila | verterok: can't youR 10.4 installer be used on 10.5 ? | 15:17 |
| verterok | vila: no :( becuase 10.5 defulat python installation is in a different directory than the MacPython install in 10.4 :p | 15:18 |
| * vila cries | 15:18 | |
| * verterok joins vila | 15:18 | |
| * beuno cries | 15:18 | |
| vila | http://bazaar-vcs.org/MacOSXBundle/Prepare | 15:19 |
| verterok | beuno: curl <url to tar.gz> > bzr-1.16.1.tar.gz && tar -zxf bzr-1.16.1.tar.gz && cd bzr-1.16 && make; ./bzr | 15:19 |
| vila | verterok: excellent ! Update the wiki :-P | 15:20 |
| verterok | vila: heh | 15:20 |
| beuno | verterok, will try that, and continue crying about the installer | 15:21 |
| beuno | thank you :) | 15:21 |
| vila | http://straussd.fourkitchens.com/bzr-1.16-osx-10.5.zip | 15:21 |
| beuno | oh | 15:21 |
| vila | http://straussd.fourkitchens.com/bzr-1.16-osx-10.5-2.zip | 15:21 |
| verterok | beuno: or I can build a bzr-only package in my 10.5 machine...but you 'll need to wait bit | 15:21 |
| vila | eerr, forget the first link | 15:21 |
| verterok | ohh, nice! | 15:21 |
| beuno | OH | 15:22 |
| beuno | even nicer :) | 15:22 |
| vila | I thought that one found its way to the right place though, I'll try to poke the list | 15:22 |
| beuno | perfect, now I feel less bad about upgrading everything without talking to anyone | 15:23 |
| beuno | thank you :) | 15:23 |
| verterok | vila: btw, I'm doing a bit of research to automate the 10.5 installer build, looks like it's possible as 10.5 use an xml descriptionto build the installer, with 10.4 I'm still stuck with the manual build (damn binary formats!) | 15:25 |
| vila | verterok: that would be a signigicant step for 10.5 and maybe you may find a way to use that installer for 10.4 too.... | 15:26 |
| verterok | vila: I hope so... | 15:26 |
| beuno | vila, installer worked great | 15:27 |
| vila | beuno: please reply on the list and keep david in CC :-P | 15:30 |
| === Kissaki^0ff is now known as Kissaki | ||
| phinze | so i've got local changes in a branch i need to move to another local branch, which i would usually cheat with cd ~/right.place; bzr diff ../wrong.place | patch -p0 | 16:56 |
| phinze | but this time it has file moves | 16:56 |
| phinze | which diff/patch won't pick up... is there a way to pull this off with shelves or something? | 16:57 |
| phinze | or is it just easiest to replay the moves and then diff/patch (which i imagine may very well be the case)? | 16:58 |
| jml | phinze, cd right.place; bzr merge --uncommitted ../wrong.place | 16:58 |
| phinze | aha... will give it a shot jml | 16:58 |
| vila | jml, phinze: will work if both branches are at the same tip | 16:58 |
| phinze | "All changes applied successfully. | 16:59 |
| phinze | beautiful; thanks :) | 16:59 |
| jml | phinze, yeah, it's one of my favourite features. | 16:59 |
| phinze | vila: actually wrong.place was a large feature branch and right.place was trunk, and it work without problems... | 16:59 |
| phinze | so i guess today i got lucky :) | 17:00 |
| vila | phinze: oh, it will always work, the question is will it do what you think :) | 17:00 |
| vila | phinze: merge --uncommitted will get the uncommitted changes but also the missing revisions | 17:01 |
| jml | vila, ! | 17:01 |
| phinze | hah; yeah looks good for this case, though the code in question was in a plugin that is kept in sync between the two branches, so that probably helps | 17:01 |
| phinze | the merge didn't look like it was any more than what 'bzr st' showed | 17:01 |
| vila | phinze: most of the time I use it to apply a work in progress on a remote-but-accesible-vis-mounted-file-system machine where I want to run tests before committing | 17:03 |
| vila | s/vis/via/ | 17:03 |
| phinze | yeah i was in a fixing-bug-on-feature-branch-caused-by-plugin-code-kept-in-trunk situation | 17:03 |
| vila | jml, phinze: bah forget me, I misread the command as (cd ~/wrong.place; bzr diff) | (cd ~/right.place; patch -p0) | 17:13 |
| trondn | Hi.. How do I update the content of a sandbox to a given version ? | 17:42 |
| trondn | or do I need to create a new clone to do so? | 17:43 |
| trondn | (I'm thinking of the equivalent of just doing: hg up -r <rev> ) | 17:47 |
| dash | 'bzr revert -r xxx' | 17:47 |
| trondn | dash: thanks | 17:48 |
| ingenthr | quick question based on trondn's; if i bzr revert -r previous-rev-no | 17:51 |
| ingenthr | bzr revno still shows the current revno | 17:52 |
| dash | right. revert only affects your working copy, not your branch. | 17:52 |
| ingenthr | this is why i thought revert wasn't doing it's thing... how can see what the state of my current branch is? | 17:52 |
| dash | which part of its state? | 17:52 |
| ingenthr | oh, okay, how can i see my current working copy | 17:53 |
| dash | it's the files you've got :) | 17:53 |
| ingenthr | use case is as follows: i need to go back and work on an older, tagged version | 17:53 |
| ingenthr | so i used bzr tags to find the revno | 17:53 |
| dash | ok | 17:53 |
| ingenthr | then the correct thing to do is revert to that revno and do whatever work i need to do? | 17:53 |
| ingenthr | thanks for the help by the way dash | 17:54 |
| dash | np | 17:54 |
| dash | well it depends | 17:54 |
| ingenthr | do i have the right workflow for my use case? | 17:54 |
| dash | you want to create a new version based on modifications to the version at that tag, and not including the changes since the tag? | 17:54 |
| ingenthr | in this case, probably not | 17:55 |
| === mario_ is now known as pygi | ||
| ingenthr | but i can see other cases where i may | 17:55 |
| ingenthr | i.e. a "sustaining tail" | 17:55 |
| ingenthr | i guess that'd be it's own branch then? | 17:55 |
| dash | yes | 17:55 |
| dash | you can do 'bzr branch -r <revno>' if you only want to get the history up to a certain point | 17:56 |
| dash | when creating a branch | 17:56 |
| ingenthr | but in the case i'm not making changes, i can just revert -r revno and do my build with alternate parameters, right? | 17:56 |
| dash | yep. | 17:56 |
| ingenthr | okay, thanks.... spent a lot of time with the docs on this... | 17:57 |
| ingenthr | i didn't find much in the docs with what to do with a tag once you've got one :) | 17:57 |
| ingenthr | and i'm obviously new to bzr | 17:57 |
| dash | it's just a name for a revision | 17:57 |
| ingenthr | yeah, it's the larger workflow issues | 17:58 |
| ingenthr | i.e. going back to a tag, working from there, issuing a patch, etc. | 17:58 |
| ingenthr | i think i'm in good shape for now though, thanks dash! | 17:58 |
| dash | :) | 17:59 |
| dash | ingenthr: bzr itself, for example, has separate branches for each major version | 18:00 |
| dash | so if there's a problem in 1.15, changes can be made in lp:bzr/1.15 and 1.15.1, 1.15.2, etc., versions can be released from there | 18:01 |
| ingenthr | where 1.15 is a tag, right? | 18:03 |
| ingenthr | not a revno | 18:03 |
| dash | it's a branch name | 18:03 |
| dash | they may use tags, I don't remember. | 18:03 |
| Chuck__ | Hi all. I appreciate bzr for its ease of use. I am currently worked with just one colleague on a paper in latex and we want to use bzr. I have my own repository and I sent it to him via e-mail. Now what is the most straightforward way to send him a patch which he may merge (eventually getting conflicts)? I want the result to be that we have the same revisions | 18:11 |
| Chuck__ | I tried to use bzr submit -o file | 18:12 |
| Chuck__ | using as a public branch a branch with the exact revision I sent | 18:12 |
| Chuck__ | and then merge works, but does not commit a new version, so the log message is not the same for example. I want instead to see the same log message and author of the commit on both sides. | 18:12 |
| luks | the original revisions are still there | 18:13 |
| luks | but if there were no modifications on the other side, he could use pull instead of merge | 18:13 |
| luks | then the branch would look identically on both sides | 18:14 |
| Chuck__ | aha just use pull | 18:14 |
| Chuck__ | and if there are conflicts it will work as usual | 18:14 |
| Chuck__ | he will get conflicts, then send a patch to me, isn't it? | 18:14 |
| luks | if there is a possibility for conflicts, pull will refuse to work | 18:14 |
| luks | pull will only work if there are no changes at all | 18:14 |
| Chuck__ | hmm conflicts always lead to confusion. So if we both change the repository what are the options to get synchronised? | 18:15 |
| Chuck__ | without both having r/w access to a repository? | 18:15 |
| luks | well, the easiest option is to use merge and not worry | 18:16 |
| luks | bzr log will still show you the original revisions | 18:16 |
| Chuck__ | luks: you mean, use merge, and then commit? | 18:16 |
| luks | but it will have one new revision, the merge commit | 18:16 |
| luks | yes | 18:16 |
| Chuck__ | but if I happen to have both repositories, will bzr be able to tell that the two seemingly different commits are the same? | 18:17 |
| luks | as I said, there are situations when you can use pull instead of merge | 18:17 |
| Chuck__ | He could pull on a clean copy of the last synchronisation point | 18:17 |
| luks | Chuck__: I think you are misunderstanding how merge works | 18:17 |
| Chuck__ | and then merge with his own, that would work? | 18:18 |
| Chuck__ | luks please explain me if you have time | 18:18 |
| Chuck__ | I always get confused by VCS in general | 18:18 |
| luks | sure | 18:18 |
| luks | let's assume you have two branches, both with two commits A B | 18:19 |
| luks | now if you commit C to one of them, you can use bzr send to generate a patch and use bzr pull on the other side to apply it | 18:20 |
| luks | then you end up with identical branches on both sides | 18:20 |
| luks | now let's say you commit C to one of them, and send him the patch | 18:21 |
| luks | but before he gets the patch, he commits D to his branch | 18:21 |
| Chuck__ | luks wait a sec. I am already lost | 18:21 |
| luks | now you have "A B C" and he has "A B D" | 18:21 |
| Chuck__ | ah ok | 18:21 |
| Chuck__ | yes this is the situation | 18:22 |
| luks | and in this situation you need to merge | 18:22 |
| Chuck__ | aha ok | 18:22 |
| luks | so after merge you end up something that is not really a line | 18:22 |
| luks | one sec | 18:22 |
| Chuck__ | yes this is clear, it's like a diamond sort of | 18:23 |
| luks | ok, so I'm not doing to "draw" it :) | 18:24 |
| luks | the point is that bzr knows where each revision is from | 18:24 |
| luks | and it knows the original ordering of the revisions | 18:24 |
| Chuck__ | ok | 18:25 |
| Chuck__ | so the merge is actually a new revision | 18:25 |
| luks | so your revision C is still there, but there is a new revision, under which your original revision is merged | 18:25 |
| luks | yes | 18:25 |
| Chuck__ | yes but will I see C in the changelog? | 18:25 |
| luks | of course | 18:26 |
| Chuck__ | hmm then I did the wrong experiment, let me redo it | 18:26 |
| luks | you will see it "indented" under the new revision | 18:26 |
| Chuck__ | aah so only when I finally commit the merge. So the merge status is special. I have the conflicts and then I can commit, but it will actually commit 2 revisions | 18:26 |
| Chuck__ | did I get it? | 18:26 |
| luks | technically, it will commit only 1 revision | 18:27 |
| luks | your original revision will be copied when you run merge | 18:27 |
| Chuck__ | my original revision="C" | 18:28 |
| Chuck__ | ? | 18:28 |
| luks | and the new revision will be added when you merge | 18:28 |
| luks | yes | 18:28 |
| Chuck__ | but after merge if I do bzr log I still don't see C, right? | 18:28 |
| luks | Chuck__: are you on windows by a chance? | 18:28 |
| luks | Chuck__: you should see C | 18:28 |
| Chuck__ | luks: no way, I left windows for good 12 years ago :) | 18:28 |
| Chuck__ | aha ok I will retry now | 18:28 |
| Chuck__ | ok I see C | 18:29 |
| Chuck__ | whatever it is | 18:29 |
| Chuck__ | I was just wrong earlier. | 18:29 |
| luks | if you have bzr-gtk or qbzr installed (bzr plugins), you can use bzr viz or bzr qlog | 18:29 |
| luks | that should make it much more obvious what's going on | 18:29 |
| Chuck__ | so it's very clear now. I just prepare a patch with "bzr something" which I already forgot, and then "bzr merge" on the obtained file. What is something btw :) I'll write this down | 18:30 |
| Chuck__ | bzr send | 18:30 |
| luks | something is send :) | 18:30 |
| luks | yea | 18:30 |
| Chuck__ | you've been patient and helpful. Thanks. A last question though: is there any sane reason why I should prefer the hassle to find a shared sftp service instead of sending patches via e-mail in such a simple scenario? | 18:31 |
| luks | it might be easier for you than sending emails | 18:31 |
| luks | but no technical reason | 18:31 |
| luks | the result will be the same both ways | 18:31 |
| Chuck__ | the result is the same, that's what it seems, ok. | 18:32 |
| luks | yes | 18:32 |
| Chuck__ | *very* good. This will become popular among my friends :) | 18:32 |
| Chuck__ | because until now we had two options: a centralised server, which always was a pain, because of passwords, and firewalls, or send all the files by e-mail every time, which is a pain when the directory grows | 18:33 |
| Chuck__ | now we will use bzr :) | 18:33 |
| Chuck__ | thanks again and bye | 18:33 |
| luks | bye :) | 18:33 |
| Chuck__ | luks sorry there is still a "very last one" :) Previously I did bzr diff using as a "public branch" just the result of "bzr branch -rLAST_REVISION_SENT" on my repository. Is there a more convenient way than re-creating a branch every time? | 18:37 |
| dash | diff takes an -r argument | 18:38 |
| luks | dash: but send doesn't (in an useful way) | 18:38 |
| Chuck__ | bzr send I meant | 18:38 |
| luks | Chuck__: unfortunatelly, there isn't | 18:38 |
| Chuck__ | luks the pqm extension seem in topic but I do not dare :) | 18:39 |
| dash | hm | 18:39 |
| luks | you can bzr pull -rLAST_REVISION_SENT in the pseudo-public branch | 18:39 |
| dash | can't you use 'bzr diff -rsubmit:'? | 18:39 |
| luks | dash: you can't merge from that | 18:39 |
| luks | send is useful because it sends a bundle | 18:39 |
| luks | but it insists on a public branch | 18:39 |
| dash | oh, sorry, he meant send. :) | 18:40 |
| Chuck__ | ok no problem so I will have two repositories. One will be the most up-to-date idea I can have of the "other" repository, that is the "pseudo public repository". The other one will be my working copy. | 18:40 |
| luks | I think bzr send with -r or -c will start doing cherry-picks | 18:40 |
| luks | which are not the desired result | 18:40 |
| Chuck__ | luks yes -r applies to the "local" revisions | 18:40 |
| Chuck__ | I think it would be possible to implement this behavior in bzr itself | 18:41 |
| luks | yeah, there were some discussion what should send do in such situations | 18:41 |
| luks | the use case was very similar actually | 18:41 |
| luks | for now you will have to run pull in the public branch every time you send a patch | 18:42 |
| Chuck__ | luks not sure: I will have to wait for the possible merge, and either pull or merge myself no? | 18:43 |
| Chuck__ | no sorry, always pull | 18:43 |
| luks | Chuck__: no, you don't have to wait for the merge | 18:43 |
| Chuck__ | yes I do, I want the other person's changes :) | 18:43 |
| luks | well, they will send it to you | 18:43 |
| luks | but that should not block the workflow (from bzr point of view) | 18:44 |
| Chuck__ | and I will apply these at least in the working copy. But what about the "pseudo public" | 18:44 |
| Chuck__ | ah yes I know | 18:44 |
| Chuck__ | but then the notion of synchronisation point is becoming fuzzy again | 18:44 |
| Chuck__ | so when I get the merge from the other party, I have to pull it in the public repository | 18:45 |
| Chuck__ | and then this is my new public repo | 18:45 |
| luks | if you send a patch, and after that update the pseudo-public branch to match your working branch, it will work | 18:45 |
| luks | merging from somebody else is just "working on the branch" | 18:45 |
| Chuck__ | I will probably send redundant versions including the other person's own merge in the future, but it will work. | 18:45 |
| luks | yes, exactly | 18:46 |
| luks | you can look at the log he sent, and update the pseudo-public branch to the right revision | 18:46 |
| Chuck__ | ok now I got the complete picture I hope. Pull in the pseudo-public, merge in the working copy | 18:46 |
| luks | but that might be too much work | 18:46 |
| Chuck__ | this must be automatised | 18:46 |
| Chuck__ | ok bye for now I wish I had the time to help a bit. | 18:47 |
| dash | Hm =/ | 19:02 |
| dash | does loggerhead 1.10 not work with bzr 1.16? | 19:02 |
| dash | https://bugs.launchpad.net/loggerhead/+bug/382765 suggests it does not | 19:17 |
| ubottu | Ubuntu bug 382765 in loggerhead "history.py uses deprecated (and deleted) ProgressBarStack" [Critical,Triaged] | 19:17 |
| jenred | hello! Having a very frustrating problem with bazaar +launchpad maybe someone could help? | 19:36 |
| jenred | I'll ask anyway ;> | 19:36 |
| jenred | despite having what looks like a good local setup -- I have a GSoC student who keeps getting permission denied when she tries to push to her branch | 19:37 |
| jenred | as far as I can tell her key-pair is set up correctly | 19:38 |
| Tak | anyone have thoughts about the design for a gui for interactive conflict resolution? | 19:45 |
| beuno | Tak, something that shows me the code that I have, and the code that's coming it clearly and let me decide which one to keep, for starters, would be fantastic | 19:46 |
| Tak | beuno: well yeah, those are the essential ingredients | 19:47 |
| beuno | exactly, essential is a fantastic start! | 19:48 |
| Tak | but I'm hoping to come up with something a little less clumsy than, say, the tortoise ui | 19:48 |
| luks | jenred: it's hard to say what's wrong without knowing details | 19:49 |
| jenred | luks is there somewhere better to ask? | 19:50 |
| jenred | she's running Intrepid and has regenerated her keys multiple times | 19:50 |
| jenred | -Dhpss did give her a "report a bug" with a traceback -- I think she's opening a bug | 19:51 |
| luks | well, the obvious problems might be missing "bzr launchpad-login" | 19:51 |
| jenred | we already tried that ;> | 19:51 |
| luks | or not uploaded key on launchpad | 19:51 |
| jenred | yep key is there | 19:51 |
| luks | or wrong key on laynchpad | 19:51 |
| jenred | that's what I was thinking but she's double-checked | 19:52 |
| luks | can she use sftp to connect to bazaar.launchpad.net? | 19:52 |
| jenred | not sure if she's tried sftp ... we'll give that a try | 19:54 |
| luks | that might give some more useful error message | 19:54 |
| dash | "interactive conflict resolution"? | 19:57 |
| dash | is that the new euphemism for a fight in the parking lot | 19:57 |
| jenred | luks thanks | 19:57 |
| luks | jenred: btw, just to be safe, when I said sftp I meant actual sftp client, not a sftp url for bzr | 20:00 |
| jenred | ohhh | 20:01 |
| jenred | right | 20:02 |
| jenred | she's getting a bzr: ERROR: Unable to connect to SSH host launchpad.net; EOF during negotiation | 20:03 |
| jenred | using sftp url | 20:03 |
| luks | bazaar.launchpad.net | 20:15 |
| luks | not launchpad.net | 20:15 |
| jenred | right | 20:15 |
| jenred | no luck but a better error message | 20:15 |
| jenred | i think there is a mismatch problem between her UID locally, and her lp login | 20:16 |
| kanika_vats | luks, Hi there I am the one getting this error jenred is talking about..... | 20:18 |
| kanika_vats | I have tried everything what you have said.....also I feel that I have my right ssh public key registered with launchpad...and that my launchpad-login registered with bazaar is also correct | 20:20 |
| luks | "sftp YOUR_LAUNCHPAD_IS@bazaar.launchpad.net" | 20:20 |
| luks | *ID | 20:21 |
| kanika_vats | alright...let me see | 20:22 |
| kanika_vats | ohk...i have got an sftp> prompt | 20:23 |
| luks | so it's working | 20:23 |
| kanika_vats | yea...it is | 20:23 |
| luks | what's your launchpad ID and what's the project/branch you want to push to? | 20:24 |
| kanika_vats | launchpad ID: kanika-krikan | 20:24 |
| kanika_vats | branch:lp:~systers-dev/systers/orm | 20:26 |
| luks | ok, try bzr push with this URL - bzr+ssh://kanika-krikan@bazaar.launchpad.net/~systers-dev/systers/orm/ | 20:27 |
| kanika_vats | i am getting the error: | 20:29 |
| kanika_vats | Permission denied (publickey). | 20:29 |
| kanika_vats | bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required) | 20:29 |
| luks | well, that's strange | 20:29 |
| kanika_vats | I know it is.....have tried many things...and have also checked everything is right multiple times | 20:30 |
| kanika_vats | I am able to do a local commit...an update..checkout everything except commiting or pushing to my launchpad branch | 20:31 |
| luks | can you please run "bzr push -Derror bzr+ssh://kanika-krikan@bazaar.launchpad.net/~systers-dev/systers/orm/" and pastebin the error? | 20:31 |
| kanika_vats | ohk...yea sure | 20:31 |
| luks | ideally from ~/.bzr.log | 20:31 |
| kanika_vats | there is no log file....in ~/.bzr | 20:34 |
| kanika_vats | wheni do ls | 20:34 |
| kanika_vats | i get | 20:34 |
| kanika_vats | branch branch-format branch-lock checkout README repository | 20:34 |
| kanika_vats | these files | 20:34 |
| kanika_vats | but the error that i am getting on running the above cmnd is: | 20:34 |
| luks | on in ~/.bzr, "less ~/.bzr.log" | 20:35 |
| luks | btw, having a .bzr dir in your home directory is probably not a good idea | 20:35 |
| kanika_vats | I am not having .bzr dir in my home directory | 20:36 |
| kanika_vats | I am having it another directory /usr/local/mailman where i checked out my code from the launchpad branch | 20:37 |
| kanika_vats | Permission denied (publickey). | 20:38 |
| kanika_vats | bzr: ERROR: bzrlib.errors.ConnectionReset: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required) | 20:38 |
| kanika_vats | Traceback (most recent call last): | 20:38 |
| kanika_vats | File "/usr/lib/python2.5/site-packages/bzrlib/commands.py", line 857, in run_bzr_catch_errors | 20:38 |
| kanika_vats | return run_bzr(argv) | 20:38 |
| kanika_vats | File "/usr/lib/python2.5/site-packages/bzrlib/commands.py", line 797, in run_bzr | 20:38 |
| kanika_vats | ret = run(*run_argv) | 20:38 |
| kanika_vats | File "/usr/lib/python2.5/site-packages/bzrlib/commands.py", line 499, in run_argv_aliases | 20:38 |
| kanika_vats | return self.run(**all_cmd_args) | 20:38 |
| kanika_vats | File "/usr/lib/python2.5/site-packages/bzrlib/builtins.py", line 802, in run | 20:38 |
| kanika_vats | use_existing_dir=use_existing_dir) | 20:38 |
| kanika_vats | File "/usr/lib/python2.5/site-packages/bzrlib/push.py", line 47, in _show_push_branch | 20:38 |
| kanika_vats | dir_to = bzrdir.BzrDir.open_from_transport(to_transport) | 20:38 |
| kanika_vats | File "/usr/lib/python2.5/site-packages/bzrlib/bzrdir.py", line 798, in open_from_transport | 20:38 |
| kanika_vats | return format.open(transport, _found=True) | 20:38 |
| kanika_vats | File "/usr/lib/python2.5/site-packages/bzrlib/bzrdir.py", line 1725, in open | 20:38 |
| kanika_vats | return self._open(transport) | 20:38 |
| kanika_vats | File "/usr/lib/python2.5/site-packages/bzrlib/bzrdir.py", line 2605, in _open | 20:38 |
| kanika_vats | return remote.RemoteBzrDir(transport) | 20:38 |
| kanika_vats | File "/usr/lib/python2.5/site-packages/bzrlib/remote.py", line 76, in __init__ | 20:38 |
| kanika_vats | response = self._client.call('BzrDir.open', path) | 20:38 |
| kanika_vats | File "/usr/lib/python2.5/site-packages/bzrlib/smart/client.py", line 111, in call | 20:38 |
| kanika_vats | result, protocol = self.call_expecting_body(method, *args) | 20:38 |
| kanika_vats | File "/usr/lib/python2.5/site-packages/bzrlib/smart/client.py", line 124, in call_expecting_body | 20:38 |
| kanika_vats | method, args, expect_response_body=True) | 20:38 |
| kanika_vats | File "/usr/lib/python2.5/site-packages/bzrlib/smart/client.py", line 72, in _call_and_read_response | 20:38 |
| kanika_vats | expect_body=expect_response_body) | 20:38 |
| kanika_vats | File "/usr/lib/python2.5/site-packages/bzrlib/smart/message.py", line 258, in read_response_tuple | 20:38 |
| kanika_vats | self._wait_for_response_args() | 20:38 |
| kanika_vats | File "/usr/lib/python2.5/site-packages/bzrlib/smart/message.py", line 224, in _wait_for_response_args | 20:38 |
| kanika_vats | self._read_more() | 20:38 |
| kanika_vats | 20:39 | |
| kanika_vats | File "/usr/lib/python2.5/site-packages/bzrlib/smart/message.py", line 247, in _read_more | 20:39 |
| kanika_vats | "(and try -Dhpss if further diagnosis is required)") | 20:39 |
| kanika_vats | ConnectionReset: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required) | 20:39 |
| kanika_vats | this is what i get on running the command | 20:39 |
| luks | kanika_vats: I'm afraid I don't know what's the problem :( | 20:40 |
| luks | you can try asking in #launchpad | 20:40 |
| luks | they will be probably more helpful | 20:40 |
| kanika_vats | hey never mind .....thanks a lot for your time and help | 20:40 |
| kanika_vats | I will ask the launchpad people about the bug.... | 20:41 |
| kanika_vats | ;> | 20:41 |
| kanika_vats | thnks | 20:41 |
| spirov92 | hey, there's no example on using feature branches. How do these work? | 20:50 |
| dash | it's a branch | 20:50 |
| dash | you write a feature | 20:50 |
| dash | then later, you merge it to the mainline. | 20:51 |
| spirov92 | sounds simple | 20:51 |
| spirov92 | to use a feature branch, do I have to copy the files? | 20:54 |
| luks | no, you have to create a branch | 20:57 |
| luks | using "bzr branch" :) | 20:57 |
| beuno | mwhudson, hi | 21:41 |
| beuno | I feel like releasing loggerhead again | 21:42 |
| Lo-lan-do | Yay | 21:42 |
| mwhudson | beuno: ah yeah, good idea :) | 21:42 |
| Lo-lan-do | Will you be at debconf? | 21:42 |
| beuno | there are 2 blockers I can think of: we need to ship with a daemonized version of serve-branches | 21:42 |
| beuno | and, we need to fix the Critical bug that breaks lh and bzr 1.16 | 21:42 |
| Lo-lan-do | So we can discuss how best to integrate with fusionforge… | 21:43 |
| beuno | Lo-lan-do, I won't this time :( | 21:43 |
| Lo-lan-do | Blah | 21:43 |
| beuno | Lo-lan-do, there may be other developers like lifeless | 21:43 |
| beuno | he's a DD, but I'm not sure if he plans to go | 21:43 |
| Lo-lan-do | I think jelmer will be there. But anyway, I'll poke you on IRC when the release is done. | 21:44 |
| beuno | mwhudson, bug 382765 | 21:45 |
| ubottu | Launchpad bug 382765 in loggerhead "history.py uses deprecated (and deleted) ProgressBarStack" [Critical,Triaged] https://launchpad.net/bugs/382765 | 21:45 |
| beuno | I have *no* idea how to fix it | 21:45 |
| beuno | mind if I assign it to you? :) | 21:46 |
| mwhudson | beuno: i can't in any way make the code fail | 21:46 |
| mwhudson | so i guess we should delete it | 21:46 |
| beuno | yay! | 21:46 |
| beuno | easy fix | 21:46 |
| mwhudson | beuno: the bug about loggerhead not working as a plugin should be fixed i guess | 21:55 |
| beuno | mwhudson, agreed. Target whatever you feel needs to be fixed before release. I'm going to tackle some of the bugs, and start brushing up on the release process | 21:58 |
| beuno | Lo-lan-do, do you have the code you use to daemonize serve-branches? | 22:01 |
| Lo-lan-do | Um, I thought you merged it already… | 22:02 |
| beuno | did I? | 22:03 |
| Lo-lan-do | http://bzr.debian.org/loggerhead/users/lolando/loggerhead/daemonise | 22:03 |
| Lo-lan-do | Drop the first "loggerheadd/" for the branch URS | 22:03 |
| Lo-lan-do | L | 22:04 |
| beuno | thanks Lo-lan-do | 22:04 |
| Lo-lan-do | bzr missing --other http://bzr.debian.org/users/lolando/loggerhead/daemonise | 22:04 |
| Lo-lan-do | You might need to rebase and/or port to current code :-) | 22:05 |
| === ja1 is now known as jam | ||
| === BasicPRO is now known as BasicOSX | ||
| jam | poolie: ping | 23:08 |
| poolie | hi jam | 23:18 |
| poolie | jam, want a chat? | 23:18 |
| jam | yep | 23:18 |
| beuno | mwhudson, any ideas why even though I have python-paste installed, I can't import it from any version of python? | 23:28 |
| mwhudson | beuno: that sounds fairly broken | 23:29 |
| beuno | mwhudson, it's a fresh install from 2 weeks ago, after setting up Launchpad | 23:30 |
| mwhudson | beuno: is /var/lib/python-support/python2.6/paste/ there? | 23:31 |
| beuno | mwhudson, yes, and has files | 23:31 |
| mwhudson | beuno: and what happens when you import paste in python2.6 ? | 23:32 |
| mwhudson | beuno: is /var/lib/python-support/python2.6 on sys.path? | 23:32 |
| mwhudson | (if not, then everything would be broken i guess | 23:32 |
| mwhudson | ) | 23:32 |
| beuno | >>> import paste | 23:33 |
| beuno | Traceback (most recent call last): | 23:33 |
| beuno | File "<stdin>", line 1, in <module> | 23:33 |
| beuno | ImportError: No module named paste | 23:33 |
| beuno | I do have it in sys.path | 23:34 |
| beuno | >>> import sys | 23:35 |
| beuno | >>> print sys.path | 23:35 |
| beuno | ['', '/usr/lib/python2.6', '/usr/lib/python2.6/plat-linux2', '/usr/lib/python2.6/lib-tk', '/usr/lib/python2.6/lib-old', '/usr/lib/python2.6/lib-dynload', '/usr/lib/python2.6/dist-packages', '/usr/lib/python2.6/dist-packages/PIL', '/usr/lib/python2.6/dist-packages/gst-0.10', '/var/lib/python-support/python2.6', '/usr/lib/python2.6/dist-packages/gtk-2.0', '/var/lib/python-support/python2.6/gtk-2.0', '/usr/local/lib/python2.6/dist-packages'] | 23:35 |
| mwhudson | beuno: this is impossible :) | 23:38 |
| mwhudson | beuno: try running python -v | 23:39 |
| mwhudson | and then import paste | 23:39 |
| mwhudson | (there will be heaps of output, pastebin it) | 23:39 |
| beuno | mwhudson, https://pastebin.canonical.com/19122/ | 23:41 |
| mwhudson | ?? | 23:42 |
| mwhudson | beuno: maybe the same with -vv ? | 23:42 |
| beuno | mwhudson, https://pastebin.canonical.com/19123/ | 23:45 |
| mwhudson | beuno: does /var/lib/python-support/python2.6/paste have an __init__.py file? | 23:46 |
| lifeless | ls /var/lib/python-support/python2.6 for us | 23:46 |
| beuno | lifeless, https://pastebin.canonical.com/19124/ | 23:47 |
| beuno | mwhudson, it does not | 23:47 |
| mwhudson | beuno: well there's the problem then | 23:47 |
| lifeless | I think you need to run 'sudo update-python-modules /usr/share/python-support/python-paste.public' | 23:48 |
| lifeless | or sudo update-python-modules python-paste.public, if the former complains about the argument | 23:48 |
| rellis__ | How do you pass in username with bzr+ssh:// ? | 23:50 |
| lifeless | bzr+ssh://USERNAME@host/... | 23:50 |
| rellis__ | bah i thought i tried that | 23:51 |
| beuno | lifeless, https://pastebin.canonical.com/19125/ | 23:53 |
| beuno | mwhudson, I've reinstalled the package thrice! | 23:53 |
| mwhudson | beuno: i guess you need to find someone know knows something about ubuntu | 23:53 |
| mwhudson | (that's surely not me :/) | 23:54 |
| mwhudson | beuno: have you tried searching for similar bugs on launchpad? | 23:54 |
| lifeless | beuno: karmic ? | 23:54 |
| beuno | lifeless, jaunty | 23:54 |
| beuno | mwhudson, searching... | 23:54 |
| lifeless | beuno: run the second command I gave you | 23:55 |
| beuno | lifeless, I did | 23:55 |
| beuno | that's the pastebin | 23:55 |
| lifeless | please include the actual command run when pastebinning, it will avoid confusion | 23:56 |
| beuno | yeah, sorry :) | 23:56 |
| beuno | both commands give the same output | 23:56 |
| lifeless | I can't tell if you did 'sudo update-python-modules /usr/share/python-support/python-paste.public' or 'sudo update-python-modules python-paste.public' | 23:56 |
| beuno | lifeless, both gave me the same output | 23:57 |
| lifeless | ok | 23:58 |
| lifeless | ls /usr/share/python-support/python-pas* -d - I get '/usr/share/python-support/python-pastedeploy.public /usr/share/python-support/python-paste.public /usr/share/python-support/python-pastescript' | 23:58 |
| beuno | beuno@beuno-laptop:~$ ls /usr/share/python-support/python-pas* -d | 23:59 |
| beuno | /usr/share/python-support/python-paste /usr/share/python-support/python-pastedeploy /usr/share/python-support/python-pastescript | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!