| lifeless | GMT+11\ | 00:04 |
|---|---|---|
| jonoxer | Is it possible to use 'bzr diff' or 'bzr log' on a directory, rather than an entire branch or a single file? | 00:12 |
| bob2 | yes | 00:13 |
| BrentHat | well, I am getting closer, so I thank you - hopefully I can make use of it properly before next week. | 00:13 |
| jonoxer | bob2: maybe I didn't explain enough. Doing 'bzr log blah.d' shows just changes to the dir itself, not anything within it. With svn I can do "svn log blah.d" to get a log with all entries touching files in that directory | 00:14 |
| Peng_ | jonoxer: Right. I don't think there's anything you can do about that. | 00:15 |
| jonoxer | Peng_: Ah, OK. Thanks | 00:15 |
| bob2 | jonoxer: hrm, sorry, I thought it did work for log. certainly does for diff. | 00:22 |
| jonoxer | bob2: No problem, I'm sure we can work around it. It's a bit of a problem in our release infrastructure at the moment because we build several hundred .deb packages from one source tree, and the changelogs are automatically pre-populated with entries from log entries for the particular directory for the module | 00:27 |
| bob2 | ah, neat | 00:28 |
| Peng_ | If you need to, I'm sure you could manage something with bzrlib. | 00:28 |
| Peng_ | Or send a patch to add a "--recursive" option to bzr log or something. ;) | 00:29 |
| jonoxer | Peng_: I hadn't thought of that, I'd just been talking to one of the infrastructure guys about making a wrapper script that gets log entries for all files in a directory and intelligently merges / sorts the results, but that'll be kinda nasty | 00:30 |
| Peng_ | jonoxer: Won't that miss any files that have been deleted? | 00:31 |
| lifeless | poolie: network loss? | 00:36 |
| jonoxer | Peng_: yes, true | 00:41 |
| === mw is now known as mw|out | ||
| jelmer | lifeless, that patch was indeed just for review, but you didn't give me any ! ;-) | 01:30 |
| lifeless | jelmer: coming | 01:47 |
| lifeless | poolie:: | 02:37 |
| poolie | mm? | 02:37 |
| lifeless | python -m timeit -s "import bzrlib.branch | 02:37 |
| lifeless | b = bzrlib.branch.Branch.open('.') | 02:37 |
| lifeless | b.lock_read() | 02:37 |
| lifeless | rh = b.revision_history() | 02:37 |
| lifeless | rev1 = rh[200] | 02:37 |
| lifeless | rev2 = rh[201] | 02:37 |
| lifeless | " "inv1 = b.repository.get_inventory(rev1); inv2 = b.repository.get_inventory(rev2); list(inv1.id_to_entry.iter_changes(inv2.id_to_entry))" | 02:37 |
| lifeless | 2.41 sec per loop | 02:37 |
| lifeless | (first cut) | 02:37 |
| poolie | ok, nice | 02:37 |
| lifeless | also iter_changes isn't quite an entire diff | 02:37 |
| lifeless | its just the selection of unique content in both sides | 02:37 |
| lifeless | 2.4 seconds per revision in log -v would clearly be unacceptable; until this is hooked into e.g. diff though its a bit cumbersome to lsprof | 02:38 |
| === timchen1` is now known as nasloc__ | ||
| lifeless | back | 02:59 |
| === sdboyer|class is now known as sdboyer | ||
| lifeless | ok | 03:18 |
| lifeless | thats fixed :) | 03:19 |
| lifeless | 10 loops, best of 3: 51.5 msec per loop | 03:19 |
| lifeless | mtaylor: around? | 04:01 |
| lifeless | real 1m55.129s | 04:10 |
| lifeless | user 1m48.015s | 04:10 |
| lifeless | sys 0m3.708s | 04:10 |
| lifeless | bug 297457 | 04:15 |
| ubottu | Launchpad bug 297457 in bzr "bzr breaks Windows open/close dialogs in other applications" [Undecided,New] https://launchpad.net/bugs/297457 | 04:15 |
| lifeless | fun! | 04:15 |
| Leefmc | Question: I have an issue where i am going to need to integrate with SVN.. and i really dont want to. Its not my call however, so i was hoping Bzr had some good ways to integrate with Svn. Allowing me to put out svn patches, merge patches, etc. Is this possible, and not painful, in Bzr? Or should i just dedicate and fully use Svn? | 04:25 |
| bob2 | bzr-svn | 04:25 |
| lifeless | real 16m21.006s | 04:27 |
| lifeless | user 15m27.894s | 04:27 |
| lifeless | sys 0m2.828s | 04:27 |
| Leefmc | bob2: Yea i saw that on google, but before researching a ton and finding it to be a painful, non-workflow-friendly, and generally poor experience, i wanted to ask about it. | 04:27 |
| Leefmc | bob2: Is it indeed a decent workflow? Will it be horrible? | 04:27 |
| bob2 | it does what you asked, and lots of people seem very happy with it | 04:28 |
| lifeless | time ~/source/baz/repository/bzr log -v -r -10..-1 | 04:28 |
| Leefmc | bob2: Ok thank you | 04:28 |
| lifeless | the new format figures are: | 04:28 |
| lifeless | real 1m55.129s | 04:29 |
| lifeless | user 1m48.015s | 04:29 |
| lifeless | sys 0m3.708s | 04:29 |
| jonoxer | bob2: it basically lets you use bzr to talk to svn repos, so you can use bzr as a direct replacement for the svn client and still do local branching etc- | 04:29 |
| Leefmc | jonoxer: Was that directed at me? | 04:29 |
| jonoxer | Leefmc: oops, yes, sorry (and sorry bob2) | 04:30 |
| Leefmc | jonoxer: Awesome, thanks. | 04:30 |
| Leefmc | jonoxer: I was really worried, because i dont think i can go back to SVN heh | 04:30 |
| Leefmc | jonoxer: Im addicted to distributed development :o | 04:30 |
| abentley | poolie: Hi. Did you still want to talk? | 04:35 |
| poolie | hey | 04:36 |
| poolie | not necessarily | 04:36 |
| poolie | i'm planning to keep going with bug 288751 | 04:36 |
| ubottu | Launchpad bug 288751 in bzr "bzr push to stacked branch returns error Revision <x> not in <y>" [Critical,Triaged] https://launchpad.net/bugs/288751 | 04:36 |
| poolie | so if you'd done something on it i wanted to make sure we didn't overlap | 04:36 |
| poolie | i think i have a pretty good handle on it with other people here | 04:37 |
| abentley | poolie: I haven't done anything on it. I'm happy for you to continue working on it. I'll look into the mega-slow-push bug instead. | 04:37 |
| abentley | poolie: That is, after I get bzr-1.9 landed in rocketfuel. | 04:38 |
| spiv | abentley: that appears to be at least partly bug 294479 | 04:39 |
| ubottu | Launchpad bug 294479 in bzr "Vast number of round-trips pushing stacked branch" [Undecided,Confirmed] https://launchpad.net/bugs/294479 | 04:39 |
| spiv | Although there's definitely too much history being examined via get_parent_map | 04:40 |
| abentley | spiv: I found unreasonably large packs in the uploads directory of failed push attempts. | 04:40 |
| spiv | what was the extension? | 04:40 |
| abentley | spiv: .pack, IIRC. | 04:41 |
| abentley | spiv: Case in point: bzr+ssh://bazaar.launchpad.net/%7Ethumper/launchpad/code-review-multiple-team-reviews/ | 04:43 |
| abentley | I moved the upload packs into backup.bzr. | 04:44 |
| abentley | because that's the only directory it allows us to create. | 04:44 |
| spiv | Right :) | 04:44 |
| spiv | Or you could move it anywhere under .bzr... | 04:44 |
| lifeless | poolie: so, this failing test you have, where can I grab it? | 04:45 |
| lifeless | poolie: I have CHKInventory.iter_changes(CHKInventory) in basic form, need the interface tests to keep fleshing it out ... | 04:45 |
| spiv | abentley: I don't think I can see the hostetd version of that directory | 04:46 |
| lifeless | spiv: hitchhiker/ | 04:46 |
| spiv | lifeless: I see the mirrored version via bzr+ssh, not the hosted version, because I don't have write access to ~thumper's branches. | 04:48 |
| abentley | spiv: Are you a member of Bazaar Experts? If so, you can see hosted versions. | 04:48 |
| abentley | spiv: Of anyone. | 04:48 |
| spiv | I don't think I am, but maybe I should be. | 04:48 |
| spiv | Nope, I'm not. | 04:49 |
| poolie | lifeless: http://sourcefrog.net/tmp/20081113-brisbane-branchbuilder.diff | 04:49 |
| abentley | spiv: Well, here's the money shot: uploads contained 8.8M dum57tlbe0ig0xna38tj.pack but packs only contained 2.1K 62f49775a9349c7b4b78bb3f1483b3f9.pack | 04:50 |
| spiv | Hmm. | 04:51 |
| spiv | How big is the working tree? | 04:51 |
| abentley | spiv: It's launchpad. | 04:52 |
| spiv | There was a merge of trunk in the new revisions, I think? So maybe it was transferring a fulltext for every file that was touched, even by a merge revision. | 04:52 |
| spiv | Even though those text versions were probably identical to ones already present in the stacked on branch? | 04:53 |
| spiv | I believe stacking tends to transfer full texts (because even stacked pack collections should not have delta parents that do not exist in the collection), but generally it doesn't transfer many texts because only a small part of the tree is modified. | 04:55 |
| abentley | spiv: It seems possible. | 04:55 |
| abentley | spiv: At this point, I am not sure how much stacking honours that requirement to not have deltas between repos. | 04:56 |
| abentley | spiv: It doesn't obey it 100%, because that's what poolie's fixing. | 04:56 |
| spiv | Right. | 04:56 |
| poolie | abentley: at the moment i'm changing the checks to also insist that inventory parents are there ; we only do it for texts atm | 05:06 |
| abentley | Are you sure that this is the right approach? It seems to me that even if we remove the dependency on the remote repo for modified files, we'll still need it for unmodified ones. | 05:08 |
| abentley | And in both cases, we're retrieving fulltexts from it. | 05:09 |
| poolie | 'this' meaning not having cross-repository-boundary deltas? | 05:15 |
| poolie | yes, i am pretty sure | 05:15 |
| poolie | firstly it's how that format is defined to work, it's just not always enforced | 05:15 |
| poolie | but also, consider the case where the underlying repository has been upgraded and so the inventory deltas are no longre applicable | 05:16 |
| abentley | poolie: You mean if the stacked-on repository deltas change? | 05:18 |
| lifeless | abentley: no, if the stacked on repository representation changes | 05:20 |
| lifeless | abentley: e.g. if the stacked on repository is upgraded to chk-inventory, how can we upgrade the stacking repository ? | 05:20 |
| abentley | lifeless: Well, how do you deal it even if there are no deltas? | 05:22 |
| lifeless | you reconstruct the inventory in the stacking repository, convert to a chk inventory, and write it out to the upgraded stacking repository | 05:22 |
| abentley | lifeless: So it seems like you could use a similar approach, and then apply the deltas to it. | 05:25 |
| lifeless | abentley: how would you apply a text delta though? | 05:26 |
| lifeless | abentley: note that what I described did not need to access the stacked on repository | 05:26 |
| abentley | So we have text deltas in the stacked repo and chk in the stacked on? | 05:27 |
| abentley | generate the CHK inventory, convert to XML, serialize, apply deltas. | 05:28 |
| lifeless | abentley: that seems rather more complex than just asserting that we won't text-delta across repository boundaries | 05:29 |
| abentley | lifeless: If you've got an XML repo stacked on a CHK repo, you're going to have to do that for inventories anyhow. | 05:31 |
| abentley | For the revision only present in the stacked-on repos. | 05:31 |
| abentley | We already do this kind of thing when applying bundles, after all. | 05:32 |
| lifeless | abentley: no, you don't have to do it if you have no deltas crossing repo boundaries | 05:33 |
| lifeless | we're talking line-deltas, not inventory deltas | 05:33 |
| abentley | How are you going to support Repository.get_inventory_xml on a repo that's stacked on a CHK repo? | 05:35 |
| lifeless | abentley: I imagine it will have to do what bzr-svn does (serialise using an arbitrary xml serialiser) | 05:37 |
| lifeless | abentley: but that shouldn't be called at all often | 05:37 |
| abentley | lifeless: So you already need most of the complex code anyway. | 05:38 |
| lifeless | abentley: I'm not sure why that makes it more desirable | 05:39 |
| abentley | lifeless: Anyhow, none of this applies to texts, which never change representation. | 05:39 |
| lifeless | abentley: they don't yet; what about the big-files discussions we've been having | 05:39 |
| lifeless | well, I guess you can get a flat form out if needed | 05:40 |
| lifeless | I still don't see it being feasible making it desirable; it sounds like you think its desirable to have deltas point across repository boundaries? | 05:40 |
| abentley | lifeless: iter_files_bytes is compatible with big-files. | 05:40 |
| abentley | lifeless: I think that smaller repos and faster pushes are a win, and I think the cross-format case is an edge case. | 05:42 |
| lifeless | abentley: cross-format is one case; its not the only way things can/will go pear shaped | 05:43 |
| lifeless | git has excellent network performance - its users swear by it - and it *never* sends a delta in a network operation unless the basis is also being sent at the same time. | 05:44 |
| abentley | lifeless: Fair enough. I'm starting to fade. Another time perhaps. | 05:45 |
| lifeless | ok, sleep well | 05:45 |
| lifeless | you get snow yet ? | 05:45 |
| abentley | lifeless: Not here. We got some at the epic. g'night | 05:46 |
| lifeless | vila: bzrlib/tests/intertree_implementations/__init__.py | 05:48 |
| vila | I'm there | 05:49 |
| lifeless | see how PreviewTree is hooked in? | 05:49 |
| vila | end of load_tests ? | 05:49 |
| lifeless | CHKInventory trees don't have a specific InterTree subclass - like PreviewTree | 05:49 |
| lifeless | yes | 05:50 |
| lifeless | so we need to do the same thing that is done for PreviewTree - we want to append a permutation for CHKInventory | 05:50 |
| vila | meh | 05:52 |
| lifeless | ? | 05:52 |
| lifeless | vila: so, InterTree is the class that implements Tree.iter_changes(other_tree) | 05:55 |
| lifeless | vila: CHKInventory.iter_changes(CHKInventory) is the guts we want to use when someone does RevisionTree.iter_changes(RevisionTree) when both revision tree objects have a CHKInventory | 05:56 |
| lifeless | vila: intertree_implementations has the interface conformance tests that enforce correct behaviour of tree.iter_changes(tree) | 05:56 |
| vila | ham yes, that's the part I was missing | 05:56 |
| lifeless | vila: so the goal is to have a scenario, with RevisionTree[with CHKInventory].iter_changes(RevisionTree[with CHKInventory]) | 05:57 |
| lifeless | vila: my mega-hack causes the guts I wrote to be used, but there is nothing testing that the guts meet the upper level interface (and I know they don't for e.g. specific-file diffs etc) | 05:58 |
| vila | right, so first thing is looking at test failures (if any) | 05:59 |
| lifeless | vila: first thing is getting the tests to run against the code :) | 05:59 |
| lifeless | vila: second thing is looking at test failures | 05:59 |
| vila | so the *actual* tests don't use your mega-hack or they do ? | 06:00 |
| lifeless | vila: they would, IF they ran with a pair of trees that were both RevisionTree[with CHKInventory] | 06:01 |
| lifeless | vila: which is why we need to add another entry to the parameterisation list | 06:01 |
| vila | yeah, so tell me, because with 5 parameters for the permutation I have large chances to choose a wrong combination :) | 06:03 |
| lifeless | vila: ok, well we had the diversion to make it clear to you :) | 06:05 |
| lifeless | vila: is the reason why - and the goal - clear now ? | 06:05 |
| vila | lifeless, reason and goal yes, | 06:08 |
| lifeless | ok, cool | 06:08 |
| lifeless | so, the how | 06:08 |
| lifeless | the parameters are - name, optimiser class, tree format to use for the basis tree, tree format to use for the working tree, converter to use to convert trees from working trees to test trees | 06:09 |
| vila | what is a test tree ? | 06:10 |
| lifeless | it is a tree for testing with, as opposed to a tree that we use to build up the shape of the tree | 06:10 |
| lifeless | e.g. to test dirstate we need a DirstateRevisionTree as the basis | 06:11 |
| lifeless | but a dirstate revision tree is immutable | 06:11 |
| lifeless | so we use a mutable tree to construct the content the DirstateRevisionTree should have, and then we call a converter which does a commit and returns the basis tree - a DirstateRevisionTree | 06:11 |
| vila | oh, so test trees are really the basis trees | 06:13 |
| lifeless | (waiting for ack when you have absorbed this - look at the code in bzrlib/tests/intertree_implementations/__init__.py bzrlib/tests/intertree_implementations/test_compare.py and bzrlib/tests/tree_implementations/__init__.py | 06:13 |
| lifeless | vila: they are the trees used for the test; different scenarios will use different converters | 06:14 |
| vila | ok | 06:14 |
| vila | So the first permutation added could be RevisionTree[with CHKinv] against another RevisionTree[with CHK] or are theses test already done elsewhere ? | 06:16 |
| lifeless | that is exactly the permutation we need to add | 06:17 |
| vila | pfew, i wasn't totally lost then :0) | 06:19 |
| lifeless | no, they are not tested elsewhere, thats the point of this exercise to get them tested :) | 06:19 |
| lifeless | I have a partial patch for you ... | 06:19 |
| lifeless | interesting, it found bugs in the current behaviour of InterTree(RevisionTree, RevisionTree) | 06:19 |
| lifeless | vila: http://paste.ubuntu.com/71227/ | 06:21 |
| lifeless | vila: this is *nearly* what you need to get going | 06:21 |
| lifeless | vila: what it doesn't do correctly yet is to use a --development3 format rather than a --default format | 06:22 |
| lifeless | vila: shorter version | 06:22 |
| lifeless | http://paste.ubuntu.com/71229/ | 06:22 |
| vila | sooo, i need a mutable_trees_to_chk_trees helper ? | 06:23 |
| lifeless | no | 06:23 |
| lifeless | we just need to make make_branch_and_tree generate --development3 formats | 06:24 |
| lifeless | though we *could* do it by having a different helper | 06:24 |
| lifeless | vila: rev 3771 | 06:34 |
| lifeless | vila: running ./bzr --no-plugins selftest CHK chk_map -1 | 06:35 |
| lifeless | vila: so, you have the code ? :) | 06:48 |
| lifeless | the problem generally isn't *sending* the packets out to the internet | 06:48 |
| lifeless | its generally that the server is sending a big reply, with DF set, and then either a) the ISP not sending ICMP-WF to the server, or b) a firewall at the server end filtering the ICMP-WF | 06:49 |
| spiv | lifeless: we were seeing it both on a large get_parent_map request, but also on a large append. | 06:49 |
| lifeless | setting MTU works because it sets a starting point for the MTU negotiation that is below the actual MTU and thus even though DF is set it never triggers | 06:50 |
| poolie | right | 06:51 |
| poolie | so it's not just the maximum his client will send, but it's also advised to the server | 06:51 |
| lifeless | right | 06:51 |
| vila | grr, too small screen, just catching up | 06:51 |
| spiv | And append requests have small replies, so it appears that in this case sending packets was the problem. | 06:51 |
| poolie | i wonder if his mac os has a firewall installed that filters the virtual nic | 06:52 |
| lifeless | spiv: could well be; could be the VM environment, or hotel, or lots of things | 06:52 |
| lifeless | poolie: ;) | 06:52 |
| spiv | Yeah. | 06:52 |
| poolie | that might account for it being just him | 06:52 |
| poolie | or bad luck | 06:52 |
| lifeless | its a twitch-smell for me now though - hanging network, pmtud blackhole. | 06:52 |
| poolie | according to wp, ethernet is 1500 mtu | 06:52 |
| poolie | i think there are 40 octets of wrapping | 06:53 |
| spiv | lifeless: right, me too | 06:53 |
| vila | well, no firewall on the mac, but the VM is NATed... | 06:54 |
| lifeless | poolie: ethernet frame size is 1500 IIRC | 06:54 |
| lifeless | I'm going to check though, cause I thought it was 1512/1514 physically | 06:55 |
| poolie | there's 1500 of payload, 14 header, 4 trailer, and i think also a lower-level prelude | 06:55 |
| lifeless | ah yes 1520 | 06:56 |
| lifeless | that number rings large bells | 06:56 |
| lifeless | so yes, 1500 MTU at the ip layer | 06:56 |
| poolie | ah ok, the client's mtu gets put into the mss option of the tcp syn packet | 07:01 |
| lifeless | vila: pulled ? | 07:07 |
| vila | :-/ Neither pull nor missing seems to work anymore :-( | 07:08 |
| lifeless | ! | 07:08 |
| vila | eeerk, john and spiv were right, just network slowness 8-( | 07:10 |
| lifeless | awesome | 07:20 |
| vila | lifeless, here we are... ./bzr selftest --no-plugins -s bt.intertree CHK failing a lot :) Yum | 07:20 |
| lifeless | lsprof is saying that seek is 20% of st -r -2..-1 | 07:20 |
| lifeless | vila: ok | 07:20 |
| lifeless | vila: we have 40 minutes to pair on this | 07:21 |
| vila | 46/60 failures :) | 07:21 |
| vila | lifeless, ok, I;m at tree.py line 866 | 07:30 |
| vila | for the first failing test which is intertree_implementations/test_compare.py(130)test_content_modification() | 07:31 |
| lifeless | vila: ok, so its starting to go down my fast-path ;P | 07:33 |
| vila | yup, in iter_changes now (the CHK version) | 07:33 |
| lifeless | vila: so, its expected back 'a', and its getting 'a', 'b', and 'c' all modified | 07:35 |
| lifeless | ah no | 07:35 |
| vila | no it expected nothing | 07:35 |
| lifeless | its expected an empty list for the unchanged set | 07:36 |
| vila | there a re two things I don't understand | 07:36 |
| vila | 1) iter_changes shouldn't return unchanged items... | 07:36 |
| vila | 2) iter_changes shouldn't return unchanged items... | 07:36 |
| lifeless | 'include_unchanged=True' -> iter_changes returns unchanged items | 07:36 |
| vila | :) | 07:36 |
| vila | ha, ok | 07:36 |
| lifeless | but, is include_changed true in this case? | 07:37 |
| vila | is that a parameter for iter_changes ? Cause there is no such param there :) | 07:37 |
| lifeless | vila: it is a parameter for Tree.iter_changes | 07:37 |
| lifeless | remember CHKInventory.iter_changes is *incomplete* | 07:38 |
| vila | should I add that parameter then > | 07:38 |
| lifeless | if it was finished you wouldn't be looking at these tests:) | 07:38 |
| lifeless | well | 07:38 |
| lifeless | you should figure out what is going wrong | 07:38 |
| vila | sure, no problem | 07:38 |
| lifeless | I would start | 07:38 |
| lifeless | by not running TestCompare | 07:39 |
| lifeless | ./bzr --no-plugins selftest IterChanges.*CHK | 07:39 |
| lifeless | will give you lower level tests | 07:39 |
| vila | lifeless, ok, I take notice :) I'll play a bit more with that one, just to become familiar with the stack, and switch to iTerCHanges.*CHK just after :) | 07:40 |
| vila | include_unchanged is indeed false | 07:41 |
| === doko_ is now known as doko | ||
| lifeless | TREE_ROOT being included is likely going to be visible, because currently CHKInventory doesn't know that its a non-rich-root/rich-root | 07:42 |
| lifeless | my poor machine, thrashing so bad fetching mysql revs | 07:43 |
| * vila knows the mysql make my machine trash feeling :) | 07:44 | |
| === abentley1 is now known as abentley | ||
| === Bambi_BOFH is now known as Kamping_Kaiser | ||
| lifeless | ok, autopacking is not really an issue here - | 08:00 |
| lifeless | 1637.168 Auto-packing repository <bzrlib.repofmt.pack_repo.RepositoryPackCollection object at 0x143e5d0>, which has 16 pack files, containing 14041 revisions into no more than 10 packs. | 08:00 |
| lifeless | 1674.764 Auto-packing repository %s completed | 08:00 |
| LarstiQ | string interpolation yay | 08:01 |
| lifeless | 30s, not ideal, but nothing compared to the 16K that have gone by | 08:01 |
| lifeless | LarstiQ: yah, forgot a mutter param, fixed in the tree | 08:01 |
| stub | I think https://bugs.launchpad.net/bzr/+bug/258349 is WONTFIX | 09:11 |
| ubottu | Launchpad bug 258349 in bzr "Special character "ß" cannot be used in the commit message." [Low,Triaged] | 09:11 |
| Kamping_Kaiser | isnt that $EDITORs issue? | 09:31 |
| Peng_ | It's INVALID, not WONTFIX, though the issue with the wording on the WindowsDownloads page is legitimate. | 09:38 |
| Peng_ | (Well, I'd call it INVALID. I don't know what the usual Bazaar policy is. But not being able to use Unicode when your charset is set to ASCII si not a bug.) | 09:38 |
| * Peng_ goes back to being /away | 09:47 | |
| tga | hello | 10:46 |
| tga | I'm having a bit of trouble with `bzr ignore` | 10:46 |
| tga | I want to add the current dir to bzr, but without the /bin and /obj subdirs.. bzr init, bzr ignore /obj, bzr ignore /bin, bzr add * | 10:47 |
| tga | this also adds all the stuff under /bin and /obj | 10:47 |
| tga | I also tried bzr ignore bin, without the / | 10:48 |
| tga | hah, right, `bzr add`, without the * | 10:51 |
| tga | thanks for the inspiration :) | 10:51 |
| bob2 | '*' gets expanded by your shell to all (most of) the names in the dir, bzr's ignore list only affects implied names | 10:53 |
| tga | yeah, I figured it out after trying to bzr ignore obj/* and getting a long list of stuff in .bzrignore | 10:54 |
| awilkins | Anyone know how to make urllib ignore a proxy? | 10:55 |
| awilkins | Specifically, on win32 where there are IE proxy settings I wish to ignore them and go direct. | 10:55 |
| awilkins | Is there a value of the HTTP_PROXY environment variable that will produce this behaviour? | 10:56 |
| eleftherios | Switching from subversion to bzr (and it feels like a joy), when I push changes to a dir on the server (it's a web app) I get the warning, This transport does not update the working tree of: sftp://<URL>. I pushed the branch up there using bzr push --create-prefix sftp://<URL> as per http://bazaar-vcs.org/BazaarForWebDevs. What is it exactly with the warning? | 11:21 |
| Odd_Bloke | eleftherios: So in bzr there are three objects you need to be aware of. The repository, where revisions are kept, the branch, which is essentially a location and a pointer to a revision in a repository, and a working tree, which is a physical representation of a branch. | 11:25 |
| Odd_Bloke | What 'bzr push' gives you is a repository and a pointer at that URL to the correct revision in it. | 11:26 |
| Odd_Bloke | What it doesn't do is give you a physical representation of the contents of that revision. | 11:26 |
| Odd_Bloke | Which, in essence, means that people will be able to branch from that URL but won't see the contents of the revision. | 11:26 |
| Odd_Bloke | (Won't see the contents of the revision when they look at that URL). | 11:27 |
| Odd_Bloke | Am I making sense? | 11:27 |
| eleftherios | Hm | 11:27 |
| eleftherios | Odd_Bloke: No, I can't say I understand. :-/ | 11:28 |
| Odd_Bloke | eleftherios: For example, http://bzr.daniel-watkins.co.uk/wnpp-bg/ is a branch without a working tree. | 11:28 |
| Odd_Bloke | If you point your browser at it, you can't see anything. | 11:29 |
| Odd_Bloke | But if you 'bzr branch http://bzr.daniel-watkins.co.uk/wnpp-bg/', you'll get a bzr branch. | 11:29 |
| Odd_Bloke | So 'bzr push' puts all of the data there, but doesn't check it out. | 11:30 |
| Odd_Bloke | I'm not being very clear, sorry. | 11:31 |
| eleftherios | so if I push rev5 there, it will have the data but will stay in say, rev3? (Which was the original rev when I did the bzr push --create-prefix)? | 11:31 |
| Odd_Bloke | eleftherios: No, it will update the branch to point at revision 5. But if there is a checkout there, the contents checked out will still be those of revision 3. | 11:32 |
| eleftherios | Now I am even more confused! | 11:33 |
| Odd_Bloke | eleftherios: Sorry, I'm over-complicating this. | 11:33 |
| eleftherios | What have I done wrong? I went into my clean project directory, I did bzr init, then bzr add, then bzr commit -m "xxx" | 11:33 |
| eleftherios | then I pushed that on the server with bzr push --create-prefix ... | 11:34 |
| eleftherios | and I am updating the server with bzr push | 11:34 |
| Odd_Bloke | You have a branch, which is a series of revisions. You also have a checkout of that branch, which is where the work happens. When you do that 'bzr commit', bzr takes the changes from the working tree, creates a new revision and updates the branch. | 11:34 |
| eleftherios | the branch and the checkout of the branch are the same dir at the moment | 11:35 |
| Odd_Bloke | Essentially, yes. | 11:35 |
| eleftherios | I had foo/ I got in there and did bzr init && bzr add && bzr commit -m | 11:35 |
| eleftherios | I would like to have something like foo/branches foo/trunk foo/tags but I am not sure this is the right way to use bzr | 11:36 |
| Odd_Bloke | eleftherios: It's not. :) | 11:36 |
| eleftherios | so I just use bzr branch foo foo.newbranch and work like that | 11:36 |
| Odd_Bloke | Yes. | 11:36 |
| eleftherios | ok, so what else do I need to know? :-) | 11:37 |
| eleftherios | and what is that warning I get? | 11:37 |
| Odd_Bloke | That warning is just saying that push updates the branch (i.e. stuff in .bzr) but not the working tree. | 11:38 |
| Odd_Bloke | Because updating the working tree is more complex, and you don't want it happening automagically. | 11:38 |
| eleftherios | what is the working tree Odd_Bloke? :-) | 11:38 |
| eleftherios | I am reading through http://bazaar-vcs.org/SharedRepositoryTutorial now... | 11:39 |
| Odd_Bloke | eleftherios: It's the files you see that aren't in .bzr. | 11:39 |
| Odd_Bloke | It's created from the files within .bzr. | 11:39 |
| eleftherios | Odd_Bloke: the files that I see that aren't in .bzr? | 11:40 |
| eleftherios | Odd_Bloke: what are these files then? | 11:40 |
| awilkins | Your files that you are versioning? | 11:40 |
| eleftherios | the actual project files then | 11:41 |
| awilkins | Yes | 11:41 |
| eleftherios | foo/baz.py etc. But these do get pushed and updated when I do bazaar push | 11:41 |
| awilkins | It doesn't update those over a push via certain remote protocols because it's i) more complex than pushing revisions ii) costly in terms of bandwidth | 11:41 |
| eleftherios | I get the warning, yet the files do get pushed and updated though... | 11:42 |
| awilkins | eleftherios: Are you basing your assertion on the output of `bzr st` in the remote branch? | 11:43 |
| awilkins | eleftherios: If the files are being updated it would seem that the message is in error and needs fixing (either so that the behaviouir is correct again or that the message is fixed) | 11:43 |
| eleftherios | awilkins: I actually see the changes on the server | 11:44 |
| awilkins | You are pushing via sftp:// ? | 11:44 |
| eleftherios | I change foo/baz.py in the local branch, I commit, I push and then baz.py is updated on the server too | 11:44 |
| eleftherios | awilkins: yes :-) | 11:45 |
| awilkins | eleftherios: Are you running some kind of push-and-update hook? | 11:45 |
| eleftherios | This transport does not update the working tree of: sftp://<URL>. | 11:45 |
| awilkins | eleftherios: And what method are you using to look at foo/baz.py after you push? | 11:45 |
| eleftherios | awilkins: yes, I have installed the plugin push-and-update as per http://bazaar-vcs.org/BazaarForWebDevs | 11:46 |
| awilkins | eleftherios: Right, what that does is use ssh to execute "bzr up" on the branch after it pushes | 11:46 |
| awilkins | eleftherios: Push is not aware of this, so it still gives you the warning | 11:46 |
| eleftherios | awilkins: oh here we are, I then get running "ssh <user>@<domain> bzr update "/path/on/my/server" | 11:46 |
| eleftherios | I see | 11:46 |
| eleftherios | ok, so now, the shared repositories are just directories where the actual project files are stored only once and shared between branches? | 11:47 |
| eleftherios | or something like that? | 11:47 |
| eleftherios | "Each branch will share the repository for its revision storage." | 11:48 |
| awilkins | Yes | 11:48 |
| eleftherios | Ok, I get it now :-) So its benefit is that you use less disk space, any other benefits? | 11:48 |
| awilkins | This means you can create additional branches with minimal resource consumption ; standalone branches would copy the entire set of revisions | 11:48 |
| awilkins | Faster, obviously | 11:48 |
| eleftherios | awilkins: but no difference in merging etc | 11:48 |
| awilkins | eleftherios: No | 11:48 |
| eleftherios | (because that was my pain with bloody svn) | 11:49 |
| eleftherios | awilkins, Odd_Bloke thank you very much :-) | 11:49 |
| awilkins | `bzr switch` becomes more useful with shared repos | 11:49 |
| Odd_Bloke | eleftherios: No worries. | 11:49 |
| awilkins | Specifically, a no-trees repo from which you check out working trees | 11:49 |
| eleftherios | I need to read up on trees etc | 11:50 |
| tga | what exactly is the difference between trees and no trees? | 11:50 |
| eleftherios | Not everything is clear in my head yet | 11:50 |
| tga | yeah, me too | 11:50 |
| awilkins | no-trees means that the repository is just that - a repository of branches that have no working files, just revisions and metadat | 11:50 |
| eleftherios | and by the way, I know Trac has a bzr plug-in but is there another similar tool for bzr guys? | 11:51 |
| eleftherios | awilkins: and where do the working files go? | 11:51 |
| tga | ah, so a no-trees repo alone is useless | 11:51 |
| tga | you need the actual files | 11:51 |
| awilkins | Yes, you use your no-trees repo and make a lightweight checkout from one of the branches in it | 11:52 |
| awilkins | A lightweight branch is the closest Bazaar gets to an SVN working copy (although it's ligher, no pristine copy of the files therein) | 11:52 |
| eleftherios | awilkins: thank you | 11:54 |
| awilkins | eleftherios: Loggerhead is a Bazaar branch viewer, but I don't think there is anything that covers all the bases that Trac does for Bazaar yet | 11:54 |
| eleftherios | awilkins: anything in the works maybe? | 11:55 |
| eleftherios | ugh, built on TurboTears | 11:56 |
| lifeless | eleftherios: there is a bzr-trac plugin for trac | 12:14 |
| lifeless | and also abentley's embryonic cart; now abandoned I think | 12:14 |
| LeoNerd | I tried bzr with trac.. it's paaaaainfully slow | 12:15 |
| eleftherios | oh is it | 12:15 |
| eleftherios | It would be nice if someone made something with modern technologies, like Pylons + SQLAlchemy fron-end project management thingy for bzr | 12:15 |
| LeoNerd | Well, I don't think this is bzr related... even the non-bzr parts were slow. | 12:15 |
| eleftherios | oh ok | 12:15 |
| LeoNerd | so I've now given up on that and am working on some integration with my existing web framework. 'cept that's all in perl, so I'm having fun using perl's Inline::Python :) | 12:16 |
| eleftherios | :-) | 12:17 |
| Peng_ | What uses TurboGears? | 12:20 |
| Peng_ | Loggerhead doesn't. | 12:20 |
| Peng_ | FWIW, Redmine supports bzr, but I don't know how well. | 12:20 |
| lifeless | lh isn't really that tg centric | 12:21 |
| lifeless | its just wsgi | 12:21 |
| Peng_ | It's not tg at all. | 12:21 |
| eleftherios | Peng_: that's what the site writes => "The primary difference is that loggerhead is built on top of TurboGears." At http://www.lag.net/loggerhead/ | 12:21 |
| eleftherios | That's where I based my comment :-) | 12:21 |
| Peng_ | eleftherios: It used to be TurboGears, but they moved to Paste a few months ago. | 12:21 |
| eleftherios | Awesome :-) | 12:22 |
| Peng_ | eleftherios: Also, https://launchpad.net/loggerhead is its current home. | 12:22 |
| eleftherios | Peng_: running it now, looks really nice | 12:28 |
| === Spaz is now known as Paradoxataur | ||
| thrope | which version of loggerhead do I use for bzr 1.9? | 12:58 |
| thrope | is the 1.6.1 release OK? | 12:58 |
| thrope | is there any documentation for installing loggerhead? | 13:02 |
| thrope | also is there any documentation for installing bzr on centos - the repositories suggested on the web page only have 1.3 | 13:05 |
| thrope | i am having trouble installing celementtree since it conflicts with elementtree which yum depends on | 13:07 |
| ushimitsudoki | is there a way to stop bzr from asking for a passphrase when I "bzr push lp:"? | 13:08 |
| Peng_ | ushimitsudoki: SSH keys? | 13:15 |
| ushimitsudoki | Peng_: I guess i don't know how to automatically allow bzr access to my ssh keys - I think that is what i am after | 13:16 |
| Peng_ | ushimitsudoki: What OS are you on? | 13:16 |
| ushimitsudoki | Peng_: ubuntu 8.10 | 13:16 |
| Peng_ | thrope: FWIW, installing Loggerhead for me was just "unpack and run serve-branches". (I should set up the init script!) | 13:17 |
| thrope | I'm having trouble installing celementtree on centos | 13:17 |
| Peng_ | celementtree conflicts with elementtree? Your packager is wrong. | 13:17 |
| thrope | oh well | 13:18 |
| thrope | centos is really a pain | 13:18 |
| * Peng_ waves an Ubuntu flag. :P | 13:18 | |
| Peng_ | ushimitsudoki: I'm sure bzr is finding your ssh keys, then, if you have them set up properly (~/.ssh...). Have you put your public key on Launchpad? | 13:18 |
| ushimitsudoki | Peng_: yes i have it on launchpad, it's just when i push up a revision to launchpad, i have to "Enter passpharase for key '/../.../id_rsa' | 13:19 |
| Peng_ | ushimitsudoki: Oh. | 13:19 |
| Peng_ | ushimitsudoki: That's because you put a password on your SSH key. Run ssh-agent if you don't want to have to enter it constantly. | 13:19 |
| ushimitsudoki | Peng_: ah thank you i will check that out | 13:20 |
| Peng_ | ushimitsudoki: If you're on Ubuntu, it should be running already. Run "ssh-add", enter your password, and there you go. | 13:20 |
| Peng_ | (Well, it's running already for me..) | 13:20 |
| ushimitsudoki | Peng_: and you appear to be correct, sir! Thanks much! | 13:21 |
| Peng_ | :) | 13:21 |
| thrope | Peng_: unfortunately the centos people tell me that they do conflict (celementtree and elementtree) and it appears to be impossible to have them both on the same system | 13:31 |
| thrope | and since yum (the package manager) requires elementtree - it doesnt seem possible to intall bzr on centos | 13:31 |
| Peng_ | I have both installed on my Ubuntu system right now, and the universe hasn't imploded, so I daresay it's possible. | 13:32 |
| Peng_ | thrope: You don't *need* cElementTree for bzr. ElementTree is enough; it's just slower. | 13:32 |
| Peng_ | (A lot slower. But bzr would still /work/.) | 13:33 |
| Peng_ | thrope: BTW, do you have Python 2.5? | 13:35 |
| thrope | no its 2.4 | 13:35 |
| thrope | I thought 2.4 was OK? | 13:35 |
| hmeland | 2.4 is OK, but 2.5 comes bundled with cElementTree. | 13:36 |
| lifeless | 2.4 is ok | 13:36 |
| Peng_ | Yeah, what he said. | 13:36 |
| lifeless | as hmeland says | 13:36 |
| lifeless | thrope: the centos people are wrong :P | 13:36 |
| lifeless | thrope: celementree is a C extension for elementttree, it's not standalone | 13:37 |
| thrope | actually I found this on the celementtree page "Note that some distributors have included cElementTree in their ElementTree package." | 13:37 |
| thrope | so I'm hoping its in there and that explains the conflict | 13:37 |
| Peng_ | thrope: Run "python -c 'import cElementTree'" to check. | 13:37 |
| thrope | doh, how obvious | 13:37 |
| thrope | yes it seems to be there | 13:38 |
| lifeless | hmm | 13:38 |
| lifeless | I need to get bzr-search CHKInventory enabled | 13:38 |
| thrope | is it ok to use loggerhead 1.6 releas with bzr 1.9, or should I pull the trunk | 13:38 |
| lifeless | thrope: should be fine | 13:38 |
| lifeless | thrope: but its been a while since lh released, so if you have trouble grab the trunk | 13:38 |
| lifeless | yay finally, revno 2K of mysql with a split-inv repo | 13:39 |
| Peng_ | This may be a stupid question, but would bzr-search benefit from btrees? | 13:39 |
| thrope | of course centos doesn't have simpletal or paste | 13:40 |
| lifeless | it only took 22254 seconds | 13:40 |
| Peng_ | Hmm..does "bzr branch" copy over search indexes too? Should it? | 13:40 |
| lifeless | Peng_: yes; I have a alpha branch with that; I need to implement a helper/subclass for -s support | 13:40 |
| lifeless | Peng_: it doesn't, it shouldn't | 13:40 |
| Peng_ | Heh, okay. Why not? | 13:40 |
| lifeless | indexing is fast :>, network is expensive | 13:40 |
| Peng_ | Ah. | 13:41 |
| lifeless | seriously, I'm seriously proud of index performance | 13:41 |
| * beuno is reminded we need an "auto-index" feature for bzr-search in LH | 13:41 | |
| lifeless | beuno: I still don't think that that is a LH issue | 13:42 |
| Peng_ | Please make such a feature optional. Indexing large branches kills me VPS. | 13:42 |
| beuno | Peng_, yes, completely optional | 13:43 |
| Peng_ | Err, my* | 13:43 |
| lifeless | Peng_: yes, your memory issues :P | 13:43 |
| Peng_ | lifeless: :( | 13:43 |
| lifeless | Peng_: btrees help there; also ratcheting down the batch size | 13:43 |
| beuno | lifeless, who else would handle indexing the branches LH serves? | 13:43 |
| Peng_ | beuno: I wrote a little script and run it occasionally. | 13:43 |
| lifeless | Peng_: split inventories will reduce the benefit to large batch size too, which means I can reduce it and your memory issues will be reduced | 13:43 |
| lifeless | Peng_: you know bzr auto-updates an index once it has it | 13:44 |
| lifeless | beuno: well; I think there are several factors; just running lh on a branch isn't enough to say to me, the user wants this indexed. | 13:44 |
| lifeless | beuno: bzr could do with a policy on what to auto index, for folk that dont use lh | 13:45 |
| beuno | lifeless, sure, I want it to be a flag for server-branches, like --auto-index or something | 13:45 |
| lifeless | beuno: barry tried bzr-search today; claimed to be deleting grep afterwards :) | 13:45 |
| beuno | heh, I can sure understand that! | 13:45 |
| lifeless | beuno: once an index is created, all write operations add to the index | 13:45 |
| Peng_ | How much RAM does it take to index a copy of bzr.dev? | 13:46 |
| beuno | lifeless, yeah, I know that much, it's just the initial indexing that's a PITA | 13:46 |
| lifeless | Peng_: one sec, I'll see | 13:46 |
| Peng_ | Ehh, I can check myself. | 13:46 |
| thrope | I get ImportError: No module named pkg_resources with loggerhead | 13:46 |
| beuno | however, if it could be done in bzr-search, maybe that would work as well | 13:46 |
| lifeless | beuno: and I think the last thing we want is to make a web ui do an initial index | 13:46 |
| lifeless | beuno: much better to have the first bzr push leave the server indexing after the client disconnectes | 13:46 |
| beuno | ok, that's true | 13:46 |
| lifeless | [for instance] | 13:47 |
| beuno | then I'll rephrase: /me is reminded he has to look into adding an auto-index option to bzr-search :) | 13:47 |
| lifeless | beuno: that would be nice | 13:48 |
| beuno | yeah, I've been wanting to contribute a few more things to bzr-search, I have a tomboy note with 'em somewhere | 13:49 |
| beuno | anyway, off to barry's for more planning on taking over the world (of open source) | 13:49 |
| beuno | bbl! | 13:49 |
| Peng_ | "tomboy note"? | 13:50 |
| lifeless | beuno: show him lh w/bzr-search | 13:50 |
| lifeless | Peng_: desktop notes | 13:50 |
| beuno | lifeless, yes, I've been luring him in so we add it to code.python.org/loggerhead | 13:51 |
| lifeless | beuno: right, its just now he's seen search in CLI :) | 13:51 |
| beuno | lifeless, yes, that was me luring him in ;) | 13:52 |
| Peng_ | "desktop notes"? As in a scrap of paper, or a piece of software I don't know about? | 13:52 |
| lifeless | beuno: also ... | 13:52 |
| beuno | Peng_, software | 13:53 |
| Peng_ | OK :) | 13:53 |
| lifeless | 09:10 < barry> lifeless: i just heard about that yesterday and haven't had time to try it yet :) | 13:53 |
| beuno | sudo aptitude install tomboy | 13:53 |
| lifeless | 09:10 < barry> lifeless: but i'm eager to fill that cup of awesome | 13:53 |
| lifeless | 09:15 < lifeless> barry: do it! | 13:53 |
| beuno | lifeless, yes, I was behind that! | 13:53 |
| lifeless | Peng_: a desktop organiser | 13:53 |
| lifeless | beuno: well, good work :) | 13:53 |
| beuno | lifeless, I'm your biggest fan ;) | 13:54 |
| lifeless | Peng_: wiki-like, but not html display, gtk window display | 13:54 |
| fullermd | I glanced past tomboy the other month. Looked vaguely interesting. | 13:54 |
| beuno | fullermd, you should be in sales | 13:54 |
| fullermd | I know. It's a gift of mine. | 13:54 |
| * beuno -> barry's | 13:56 | |
| thrope | does auto_publish_folder in loggerhead recurse? Ie can I just point it to ~/bzr and it will pick up ~/bzr/project/brancha for different projects and branches | 14:01 |
| thrope | where does configobj come from? | 14:02 |
| thrope | oh got it | 14:02 |
| lifeless | thrope: best to use 'serve-branches' rather than logger.conf | 14:09 |
| lifeless | serve-branches DoesTheRightThing | 14:09 |
| thrope | lifeless: but I want to go through apache | 14:09 |
| thrope | can I still use serve-branches | 14:09 |
| Peng_ | thrope: Yes | 14:12 |
| jbl1 | Hello all, would anyone be able to tell me if the concept of "branch locking" is applicable to bzr? Documentation search revealed nothing. | 14:14 |
| lifeless | jbl1: what do you mean by that concept ;P | 14:17 |
| jbl1 | well, in some cases under CVS, you could create a file called 'cvs.lock' in the repository, which would revent any further commits to it, essentially locking the branch | 14:19 |
| jbl1 | revent=prevent | 14:19 |
| Peng_ | jbl1: You can't do that in bzr. | 14:20 |
| Peng_ | I guess you'd just chmod it read-only? | 14:21 |
| w00t_ | hmm. I used bzr fast-import to import a repo, and I seem to have no checked out files in my branches, is there a way I can populate them so I can use it as a working copy? | 14:22 |
| Peng_ | w00t_: "bzr co" | 14:22 |
| jbl1 | Yeah I considered that permissions option as well, looks like thats the way to go | 14:23 |
| w00t_ | Peng_: but that would involve another copy off this, wouldn't it? | 14:23 |
| Peng_ | w00t_: Run "bzr co" in the branch. That'll create a working tree. | 14:24 |
| w00t_ | nope. it tells me '.bzr' in that branch already exists | 14:25 |
| Peng_ | w00t_: Just "bzr co"? No other arguments? | 14:26 |
| w00t_ | Peng_: yes | 14:26 |
| Peng_ | ...Huh. | 14:26 |
| Peng_ | w00t_: Oh. It says that if there already is a working tree. | 14:27 |
| Peng_ | w00t_: Try bzr up and bzr revert. | 14:27 |
| * Peng_ shrugs | 14:27 | |
| Peng_ | That's a bad error message. :\ | 14:27 |
| w00t_ | bzr up worked | 14:28 |
| w00t_ | and gave me a tree | 14:28 |
| jelmer | beuno, is there some easy way to run loggerhead inside of apache/ | 14:29 |
| jelmer | ? | 14:29 |
| beuno | jelmer, yes, something about pastedeploy | 14:30 |
| beuno | which should be in the README | 14:30 |
| jelmer | ah, thanks | 14:30 |
| Peng_ | If you want it to run at the / of a domain, you probably don't even need that. | 14:30 |
| jelmer | Peng_: Why would that be different? | 14:31 |
| Peng_ | If you want to run it at e.g. /bzr/loggerhead/, you need the Paste Deploy PrefixMiddleware stuff so it knows how to treat that part of the path. | 14:33 |
| Peng_ | Otherwise, whether or not you're proxying to it from something, you don't. | 14:33 |
| lifeless | jbl1: you can also lock the branch, but thats considered a transient state, not a long term state | 14:39 |
| Peng_ | And it's easy to break locks anyway. | 14:47 |
| Peng_ | Well heck, if you have write access, no locking can stop you... | 14:48 |
| Peng_ | But anyway.. | 14:48 |
| === mw|out is now known as mw | ||
| jelmer | Peng_, with mod_proxy you can also have it rewrite the URLs, etc | 14:49 |
| jelmer | I'd just like to keep this as simple as possible | 14:50 |
| * Peng_ shrugs | 14:51 | |
| Peng_ | PrefixMiddleware is very simple. | 14:52 |
| lifeless | jelmer: serve-branches --prefix=/bzr/loggerhead | 14:59 |
| lifeless | jelmer: thats all | 15:00 |
| thrope | I'm having a lot of trouble getting loggerhead to work through apache ssl | 15:03 |
| thrope | both with config file and with server branches | 15:04 |
| thrope | is there any documentation for that? | 15:04 |
| thrope | witht he config file I got as far as the front page (project list) but with serve-branches I can't get anything (just get not found) | 15:05 |
| thrope | I am running /serve-branches --port=8999 --prefix=/bzr /home/robince/bzr/pyentropy/tests/ | 15:05 |
| thrope | and it works directly | 15:05 |
| thrope | but not through the apache proxy | 15:05 |
| lifeless | thrope: details needed about what '~not works' means for you | 15:06 |
| thrope | where I have <Location "/bzr"> ProxyPass http://127.0.0.1:8999/ ProxyPassReverse http://127.0.0.1:8999/ | 15:06 |
| thrope | well at the moment with serve-branches I get a not found error | 15:06 |
| thrope | although the request shows up in the serve-branches stdout debug | 15:06 |
| lifeless | 404? | 15:07 |
| thrope | 127.0.0.1 - - [13/Nov/2008:15:07:11 +0100] "GET . HTTP/1.1" 404 - "-" "Mozilla/5.0 (Macintosh; U; I... | 15:07 |
| thrope | yes | 15:07 |
| lifeless | at https://host/bzr/ ? | 15:07 |
| thrope | yep | 15:08 |
| thrope | but the 404 is coming from serve-branches not from my apache | 15:08 |
| lifeless | sure | 15:08 |
| lifeless | uhm | 15:08 |
| lifeless | the . is suspicious | 15:08 |
| thrope | going directly works | 15:08 |
| fullermd | Yah. "GET ."? | 15:08 |
| jelmer | lifeless: Yeah, I know about standalone. I'd like to run it from inside of apache, preferably as app | 15:08 |
| lifeless | jelmer: well, launchpad runs it as standalone with proxypass | 15:10 |
| lifeless | jelmer: so its the most heavily deployed variant | 15:10 |
| thrope | Ok - I changed location to /bzr/ instead of /bzr in apache and now get 301 not found instead | 15:10 |
| thrope | 127.0.0.1 - - [13/Nov/2008:15:09:52 +0100] "GET / HTTP/1.1" 301 - " | 15:10 |
| lifeless | jelmer: you can wire up mod_python to wsgi - there are recipes on the net, even in the bzr docs I think, but - well shrug. | 15:11 |
| thrope | so the changes divert doesn't seem to be working | 15:12 |
| lifeless | thrope: ah | 15:12 |
| lifeless | I think I know your problem :P | 15:12 |
| lifeless | /home/robince/bzr/pyentropy/tests/ | 15:12 |
| lifeless | is that a branch | 15:12 |
| lifeless | or a subdir of a branch | 15:12 |
| thrope | yep | 15:12 |
| thrope | it is a branch | 15:12 |
| lifeless | is it in a shared repo ? | 15:12 |
| thrope | yes | 15:12 |
| lifeless | try serve-branches repo-root | 15:12 |
| thrope | lifeless: hmm - it seems to work now but I don't have any css or images | 15:15 |
| thrope | and a lot of the links are to 127.0.0.1 | 15:16 |
| thrope | instead of being rewritten | 15:16 |
| lifeless | thrope: workaround, add the --host option | 15:17 |
| thrope | i already have --host=127.0.0.1 | 15:17 |
| lifeless | oh | 15:17 |
| thrope | since I want to restrict access to localhost | 15:17 |
| lifeless | remove it then | 15:17 |
| lifeless | erm | 15:18 |
| edreamleo | Hello All. Bzr broke after updating ubuntu. I don't see recent bzr versions in the synaptic package manager. Reinstalling older versions fails. How can I install the latest? Thx. | 15:18 |
| lifeless | apache is meant to add headers with the external host I thought | 15:18 |
| lifeless | thrope: anyhow, beuno should be back online soon; ping him, he's a maintainer | 15:18 |
| thrope | it is the same withit removed | 15:18 |
| lifeless | its 2am for me :P | 15:18 |
| thrope | ok thanks | 15:18 |
| Peng_ | edreamleo: Ubuntu has a "bzr" package. For something newer, you could use https://launchpad.net/~bzr/+archive | 15:19 |
| edreamleo | Peng_: the bzr package is 1.4rc1-1~bazaar1~gutsy1, but iirc I'm using hardy heron. This seems weird to me. | 15:20 |
| Peng_ | edreamleo: Check /etc/apt/sources.list. Maybe you still have some references to gutsy? | 15:24 |
| edreamleo | Peng_: Thanks. That's probably it. | 15:25 |
| edreamleo | Peng_: Yes, I see lots of references to hardy in /etc/apt/sources.list I'm no ubuntu expert. Can I delete the file, or must I edit it? | 15:29 |
| Peng_ | Um. Deleting it sounds like a really bad idea. | 15:30 |
| Peng_ | If you want apt to work. | 15:31 |
| edreamleo | apt would be good :-) | 15:31 |
| Peng_ | You can look at /etc/lsb-release to see what version of Ubuntu you run. | 15:31 |
| Peng_ | Then fix up your sources.list. | 15:31 |
| Peng_ | If that's the problem in the first place. I'm not really an Ubuntu guy. | 15:32 |
| edreamleo | Peng_: At present I'm running hardy. But I see from the bzr web page that ubuntu is up to intrepid. Maybe I'll install intrepid first. Anyway, thanks for your help. | 15:33 |
| Peng_ | If your system is brokenish, I doubt throwing an upgrade at it will help. | 15:34 |
| edreamleo | Oh. I just see I've been confused. sources.list is correct: it has references to hardy, which is indeed what I am running. But the package manager is only giving me access to gutsy files. So that appears to be the immediate problem. | 15:36 |
| dobey | you probably have a gutsy ppa in sources.list.d/ somewhere, and that version is newer than what comes on hardy | 15:37 |
| dobey | i don't remember what comes on hardy though | 15:38 |
| dobey | intrepid has 1.6.1 | 15:38 |
| Peng_ | Hardy has 1.3.1, apparently. | 15:39 |
| edreamleo | dobey: I have a half memory of modifying some "magic" file like sources.list.d several months ago in order to upgrade bzr at that time. I should have made a note of what I did, but did not. How can I find such a file? | 15:42 |
| dobey | edreamleo: sources.list.d is a directory | 15:42 |
| Odd_Bloke | edreamleo: What is in /etc/apt/sources.list.d/? | 15:42 |
| dobey | edreamleo: grep for "gutsy" in the files there, or in /etc/apt/sources.list should give you the errant file | 15:43 |
| dobey | Peng_: that would explain the "gutsy" file | 15:43 |
| edreamleo | The sources.list.d directory contains 3 files, all starting with edgy-universe.list | 15:45 |
| thrope | lifeless: well turns out theres a fairly serious bug in loggerhead: https://answers.launchpad.net/loggerhead/+question/45503 have to hard code the host in to the source to get it to create the urls correctly | 15:45 |
| thrope | but the good news is its working now | 15:45 |
| edreamleo | dobey: Yes. 2 of the three files contain gutsy rather than hardy: edgy-universe.list.distUpgrade and .edgy-universe.list.save. I'm wondering about the 'edgy' prefix. Should I edit the dubious files or delete them all? | 15:49 |
| Peng_ | edreamleo: The filename doesn't matter. You should edit the files. | 15:50 |
| edreamleo | Peng_ Thx. Will do. | 15:50 |
| dobey | if they are .distUpgrade and .save, they probably aren't being used any more anyway | 15:51 |
| dobey | you probably had the package installed before you upgraded, and it wasn't upgraded because it was already newer | 15:51 |
| dobey | ie, there was nothing to upgrade | 15:51 |
| === kiko__ is now known as kiko-fud | ||
| edreamleo | Oh my. My ubuntu system is looking pretty hosed. I can't uninstall bzr because of broken packages, like the Epiphany browser(!) and trying to fix the broken packages fails. Arrrgh. apt-get install bzr says bzr is already the latest version, and gives gibberish about evolution. | 16:12 |
| === thunderstruck is now known as gnomefreak | ||
| edreamleo | One moment. Buried in the blah blah blah as a hint to do apt-get -f install. I'll try that. | 16:13 |
| edreamleo | No. 'apt-get -f install' fails with the same errors as when trying to fix broken packages | 16:14 |
| edreamleo | Hmm. The failures are in Python 2.5: I'll try messing with python... | 16:16 |
| === thekorn_ is now known as thekorn | ||
| === kiko-fud is now known as kiko | ||
| rocky | jelmer: how does bzr-svn deal with authentication? i mean can it reuse svn authentication credentials in the standard svn locations ? | 17:10 |
| jelmer | rocky: yes | 17:12 |
| rocky | very strange, i'm trying to do a push into a svn repo where i know i have write access... and it's reporting back a 401 auth error ... if i put my credentials into the url directly https://someuser:somepass@wherever it works fine | 17:13 |
| jelmer | are you on Mac OS X or Windows perhaps? | 17:14 |
| rocky | nope, ubuntu | 17:15 |
| jelmer | does it work if you use svn+https:// rather than https:// ? | 17:19 |
| jelmer | rocky: ^ | 17:20 |
| rocky | jelmer: yes it does | 17:22 |
| rocky | and i just installed pycurl too and discovered it was having a problem with my self-signed cert which also went away when i did svn+https:// | 17:22 |
| rocky | i think you need to undeprecate svn+https ;) | 17:22 |
| jelmer | I think https:// in bzr needs to be fixed :-) | 17:26 |
| w00t_ | does bazaar have a web frontend that isn't trac? also, if anyone knows of a guide for how to get bzr:// up and running on debian/ubuntu, that'd be lovely, google isn't being too helpful! :) | 17:37 |
| jelmer | w00t_: "bzr serve" should get bzr:// up and running | 17:38 |
| jelmer | w00t_: another web frontend is loggerhead - https://launchpad.net/loggerhead | 17:39 |
| w00t_ | jelmer: but can that be done from the system level? also, which projects does that then serve | 17:39 |
| w00t_ | I'll look at loggerhead, ta | 17:39 |
| jelmer | w00t_: you can specify the directory it should serve | 17:39 |
| w00t_ | jelmer: ah, that's good | 17:40 |
| w00t_ | jelmer: it's not possible to start it via xinitd or something? | 17:40 |
| jelmer | there's no init script distributed at the moment, if that's what you mean | 17:40 |
| w00t_ | *nod* | 17:40 |
| w00t_ | that would have come in handy | 17:40 |
| w00t_ | but regardless | 17:40 |
| thrope | w00t_: if you plan to run it behind apache look at this: https://answers.launchpad.net/loggerhead/+question/45503 | 17:56 |
| thrope | I've spent quite a bit of time today trying to get it to work | 17:56 |
| thrope | it has to be the root directory (ie its own vhost, won't redirect correctly to www.com/bzr | 17:57 |
| thrope | and you need to manually edit the source as per that link to have links generated correctly | 17:57 |
| thrope | (but that is only if you want to run it behind apache - which I do for ssl, user auth etc.) | 17:57 |
| w00t_ | thanks for the tip, I'm not sure what I'll be doing yet :) | 17:57 |
| Peng_ | I don't have any of those problems, but I use Lughttpd. | 17:57 |
| Peng_ | Err, s/Lu/Li/. | 17:58 |
| Peng_ | Maybe it's some sort of Apache mod_proxy oddity? | 17:58 |
| skipm | help - bzr novice here | 17:58 |
| thrope | Peng_: I don't think so - its nothing to do with apache, loggerhead doesn't generate the correct links... everything is http://127.0.0.1:8080/stuff once you get past the first page | 17:58 |
| thrope | maybe it is apache... Idont know really | 17:59 |
| Peng_ | thrope: Yeah, but what if Loggerhead doesn't like the headers Apache sets or something? | 17:59 |
| Peng_ | Anyway, it's just a wild guess. | 17:59 |
| Peng_ | skipm: Go on? | 18:00 |
| thrope | well I got it working now anyway with vhost and the hack from that question | 18:00 |
| thrope | I just think its a shame the .conf file is being deprecated for the serve-branch becuase the config file seems a lot more sensible to me | 18:00 |
| * Peng_ uses serve-branches. | 18:00 | |
| skipm | i wanted to "checkout" the latest ipython release. I couldn't figure out how to tell what tags were available so I executed | 18:01 |
| skipm | bzr branch lp:ipython | 18:01 |
| skipm | cd ipython | 18:01 |
| skipm | bzr tags | 18:01 |
| skipm | rel-0.9.1 is the latest, so I tried | 18:01 |
| skipm | bzr update -r tag:rel-0.9.1 | 18:01 |
| skipm | no joy | 18:01 |
| skipm | I couldn't figure out how to accomplish this basic task so I simply blew away my first checkout and | 18:01 |
| skipm | am now executing | 18:01 |
| skipm | bzr branch -r tag:rel-0.9.1 lp:ipython | 18:01 |
| skipm | There must have been a better way, right? | 18:01 |
| Peng_ | skipm: 'bzr revert -r tag:rel-0.9.1' is the best thing to do. | 18:02 |
| Peng_ | update probably should support a -r argument, but it...doesn't. | 18:02 |
| skipm | thanks. switching branches hardly seems like "revert"ing. I would never have thought to check that command | 18:03 |
| thrope | skipm: it's not really switching branches - in bzr branch = directory, so the ipython checkout is a single branch. The tag is just a label for a specific revision, so you are reverting to that revisition rather than switching branches (it is part of the same history that the head of the trunk is on) | 18:05 |
| thrope | skipm: I agree it's a bit confusing but just trying to show there is some logic to it | 18:06 |
| skipm | thrope: thanks for the explanation - makes a little more sense now | 18:06 |
| thrope | skipm: although its still a bit messy becuase the revert leaves uncommited changes in the working tree | 18:08 |
| thrope | so it might be neater to checkout the tagged revision so you have a clean copy | 18:09 |
| thrope | ie ipython is the dir with the trunk branch in it | 18:09 |
| thrope | then bzr co -r tag:rel-0.9.1 ipython/ ipython-0.9.1 | 18:09 |
| thrope | means you have a checkout at the correct version in ipython-0.9.1 | 18:09 |
| thrope | and can continue to keep the trunk up to date | 18:09 |
| skipm | thrope: i'm not really wanting to develop, just use version control commands to get specific revisions/releases | 18:19 |
| thrope | skipm: I think the checkout might still be easier... if you reverted then you would have trouble when you came to update | 18:19 |
| EarthLion | hey how can i roll back to a previous revision? | 18:26 |
| Peng_ | EarthLion: "Roll back"? To revert your working tree to a previous revision, use "bzr revert -r 123". | 18:31 |
| mfoniso | what's the correct syntax for "bzr push bzr+ssh... " | 18:35 |
| Peng_ | "bzr push bzr+ssh://user@example.com/some/path/relative/to/root"? | 18:36 |
| mfoniso | ok, lemme try that | 18:36 |
| Peng_ | (/and/not/your/home/dir) | 18:36 |
| mfoniso | I keep getting this: "ssh: connect to host launchpad.net port 22: Connection timed out" | 18:36 |
| mfoniso | when I run "bzr push bzr+ssh://mfoniso@code.launchpad.net/~mfoniso/source-switcher/devel" | 18:37 |
| Peng_ | mfoniso: It's bazaar.launchpad.net, not code.launchpad.net. | 18:37 |
| Peng_ | mfoniso: Also, you could use lp:~mfoniso/source-switcher/devel as a shortcut. | 18:38 |
| mfoniso | hmm.. I see | 18:39 |
| mfoniso | Peng_: I get the following error when I do that: "Permission denied (publickey). bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required)" | 18:42 |
| Peng_ | mfoniso: I dunno. Have you uploaded your public key to Launchpad? | 18:46 |
| mfoniso | yeah | 18:46 |
| LarstiQ | right user, right key? | 18:51 |
| mfoniso | LarstiQ: yes... I think so | 18:54 |
| mfoniso | Peng_:if I used the lp: shortcut, what would the full command be? | 18:54 |
| Peng_ | mfoniso: "bzr push lp:..." | 18:58 |
| mfoniso | when I do that it complains about not being able to push via http | 18:58 |
| Peng_ | mfoniso: "bzr launchpad-login mfoniso" | 18:59 |
| w00t_ | my gosh, bzr branch on an svn branch takes a long time | 19:00 |
| mfoniso | ok, thanks that's what I needed to do. Unfortunately I'm still stuck at with the public key error | 19:00 |
| w00t_ | jelmer: hmm, if someone else mirrors my bzr-svn imported branch, are they able to use bzr to keep it up to date themselves? | 19:02 |
| Peng_ | w00t_: Yes. | 19:04 |
| w00t_ | excellent! | 19:04 |
| lifeless | mfoniso: are you on windows? | 19:12 |
| mfoniso | lifeless:nope, ubuntu | 19:12 |
| lifeless | mfoniso: the most likely thing is that you either are not using the correct lp usercode, or you haven't uploaded your public key | 19:18 |
| mfoniso | phew... I hope I get this fixed soon... uploading my key was serious hassle, but I finally got launchpad to accept it... | 19:20 |
| mfoniso | and now I'm stuck at this. :-( | 19:20 |
| mfoniso | I'm fresh out of options | 19:20 |
| mfoniso | what do you mean when you say "...lp usercode"? | 19:20 |
| lifeless | mfoniso: what is your lp usercode | 19:20 |
| lifeless | lp == launchpad | 19:20 |
| mfoniso | but what do you mean by 'usercode'? | 19:24 |
| mfoniso | do you mean the unique id provided during registration? | 19:24 |
| lifeless | yes | 19:24 |
| mfoniso | than I'm really out of options, cos that's what I'm using.. | 19:25 |
| lifeless | mfoniso: what is your lp usercode though | 19:25 |
| mfoniso | well, the error message points to the public key, I just can't see what's wrong with it | 19:25 |
| mfoniso | lp usercode is "mfoniso" | 19:26 |
| lifeless | mfoniso: so this https://edge.launchpad.net/~mfoniso is you ? | 19:28 |
| mfoniso | should be... lemme see... | 19:28 |
| === mDuff is now known as nDuff | ||
| * mfoniso waits for his slow connection | 19:29 | |
| mfoniso | lifeless: yes, that's me | 19:29 |
| lifeless | ok | 19:29 |
| lifeless | and you have run 'bzr lp-login mfoniso' ? | 19:30 |
| mfoniso | yes | 19:30 |
| mfoniso | and that ran without incident | 19:30 |
| lifeless | ok | 19:30 |
| lifeless | please run 'ssh -vv mfoniso@bazaar.launchpad.net false' | 19:30 |
| lifeless | and pastebin the output | 19:31 |
| mfoniso | ok | 19:31 |
| w00t_ | ugh, i interrupted a bzr branch halfway through by accident, is there any way to resume rather than restarting the process? | 19:31 |
| mfoniso | lifeless: what's the "false" for? | 19:31 |
| lifeless | mfoniso: just tells it what command to run on the server | 19:32 |
| mfoniso | ok | 19:32 |
| mfoniso | lifeless:http://www.pastie.org/314097 | 19:35 |
| w00t_ | from reading up, 'bzr pull' looks like a reasonable candidate for resuming, but i'm subsequently told that my branch ..is not a branch | 19:39 |
| lifeless | mfoniso: it looks to me like you have done something funny in your ~/.ssh/ directory | 19:40 |
| lifeless | mfoniso: you said you had trouble uploading your public key, could you enlarge on that | 19:40 |
| w00t_ | this seems quite strange, and annoying, is there a way to work around it? or am I going to have to set this whirring for another 3-5 hours | 19:40 |
| dobey | w00t_: i think you want get, not pull | 19:40 |
| lifeless | w00t_: if you did bzr branch... and it got interrupted, cd to the branch dir, run 'bzr init', then 'bzr pull URL' | 19:40 |
| dobey | pull ~= svn/cvs update | 19:41 |
| lifeless | dobey: get is a synonym for branch | 19:41 |
| w00t_ | lifeless: thanks, i'll give it a go | 19:41 |
| mfoniso | when I tried to upload my keys, lp complained that my keys were compromised due to a vulnerability in the ssh suite used to create it... | 19:41 |
| mfoniso | I created new keys and tried but kept having the same problem | 19:41 |
| mfoniso | at some point, I noticed something... | 19:41 |
| lifeless | mfoniso: that means that the new keys you created had the same problem, or you werenot uploading the new keys | 19:41 |
| mfoniso | the ssh key is something like so "ssh-rsa AAAAB3...." | 19:42 |
| lifeless | mfoniso: well, thats what a public key gets encoded like | 19:43 |
| lifeless | mfoniso: there are two files for every key | 19:43 |
| mfoniso | when pasted in lp, the text after the ssh-rsa was on a new line from the "ssh-rsa", it looked as though it was being wrapped, but on a hunch | 19:43 |
| dobey | no it should look like 3 lines when you paste in lp | 19:44 |
| mfoniso | I had a hunch the copy and paste may have messed with it (inserted a newline maybe), so I backspaced and hit spacebar, and launchpad accepted it | 19:44 |
| lifeless | mfoniso: ok, your hunch was probably ok | 19:44 |
| lifeless | mfoniso: now, did you create the new keys on the same machine you are using right now ? | 19:44 |
| mfoniso | yes | 19:44 |
| lifeless | as the same user | 19:44 |
| mfoniso | yes | 19:44 |
| mfoniso | in fact, I don't mind going over the process again | 19:44 |
| mfoniso | just to be sure, | 19:45 |
| lifeless | nono, thats fine | 19:45 |
| mfoniso | ok | 19:45 |
| lifeless | what file did you copy the public key from to upload to launchpad | 19:45 |
| lifeless | (full path to it please) | 19:45 |
| mfoniso | /home/mfoniso/.ssh/id_rsa.pub | 19:46 |
| lifeless | ok | 19:46 |
| * w00t_ wonders if it is really resuming | 19:46 | |
| lifeless | I'm going to ask you to look at your id_rsa file. DO NOT SHOW ME THE CONTENTS | 19:46 |
| lifeless | (its your private key) | 19:47 |
| lifeless | but we need to make sure its intanct | 19:47 |
| lifeless | the first three lines of it should be something like this: | 19:47 |
| lifeless | -----BEGIN RSA PRIVATE KEY----- | 19:47 |
| lifeless | Proc-Type: 4,ENCRYPTED | 19:47 |
| lifeless | DEK-Info: DES-EDE3-CBC,8B36D5AFB68087BC | 19:47 |
| mfoniso | ok | 19:49 |
| mfoniso | that's what it is | 19:49 |
| mfoniso | except for the part after "DEK-Info: DES-EDE-CBC," | 19:49 |
| lifeless | ok | 19:50 |
| lifeless | can you run 'ssh-add ~/.ssh/id_rsa' | 19:53 |
| mfoniso | ok | 19:54 |
| mfoniso | I ran that, entered the passphrase, and got "Identity added: /home/mfoniso/.ssh/id_rsa (/home/mfoniso/.ssh/id_rsa)" | 19:54 |
| lifeless | now try the ssh ... false command again | 19:55 |
| mfoniso | ok | 19:56 |
| mfoniso | I get a similar message as last time | 19:56 |
| lifeless | permission denied(publickey) ? | 19:58 |
| mfoniso | yes | 19:58 |
| lifeless | ok | 20:00 |
| lifeless | it seems to me that the ssh key you uploaded does not match your id_rsa file | 20:00 |
| lifeless | there are several possibilities | 20:01 |
| lifeless | a) your id_rsa.pub and id_rsa file were generated seperately | 20:01 |
| lifeless | b) you uploaded a different id_rsa.pub file | 20:01 |
| lifeless | c) something has been altered since creation | 20:01 |
| mfoniso | hm...ok, how about I delete the current keys, recreate and upload? | 20:02 |
| lifeless | sure, if you're not using them elsewhere | 20:02 |
| lifeless | rm ~/.ssh/id_rsa | 20:02 |
| lifeless | and ~/.ssh/id_rsa.pub | 20:03 |
| mfoniso | yup | 20:04 |
| lifeless | in lp delete the current key | 20:04 |
| mfoniso | just recreated, uploaded, and running that command again (the ssh command ending with "false") | 20:05 |
| mfoniso | I get the same error | 20:05 |
| lifeless | mfoniso: did you get an error about being created by a vulnerable ssh? | 20:05 |
| lifeless | and/or did you edit the text in the upload window at all? | 20:06 |
| mfoniso | yes I did, edit the text that is | 20:06 |
| lifeless | ok | 20:06 |
| lifeless | delete the key, try without editing the text | 20:06 |
| mfoniso | ok | 20:07 |
| lifeless | delete it on lp I mean | 20:07 |
| mfoniso | yup | 20:07 |
| mfoniso | yeah, I get that message about the key being vulnerable | 20:09 |
| lifeless | ok | 20:10 |
| lifeless | can you pastebin the same thing you're pasting in the lp key upload box ? | 20:10 |
| mfoniso | ok | 20:10 |
| lifeless | mfoniso: also please run 'ssh-vulnkey ~/.ssh/id_rsa' | 20:12 |
| mfoniso | lifeless: http://www.pastie.org/314151 | 20:14 |
| mfoniso | ssh-vulnkey says: "Unknown (no blacklist information)... " | 20:14 |
| lifeless | mfoniso: ok | 20:18 |
| lifeless | mfoniso: your editing is removing an A from the front of the key | 20:18 |
| lifeless | mfoniso: this makes it look like a different key | 20:19 |
| lifeless | mfoniso: and so you can't login | 20:19 |
| lifeless | mfoniso: your ssh is still vulnerable | 20:19 |
| lifeless | mfoniso: do you have 'security updates' turned on ? | 20:19 |
| Peng_ | If you have ssh-vulnkey, doesn't that mean you're using a modern enough OpenSSL/OpenSSH? | 20:20 |
| lifeless | Peng_: no, it means you have ssh-vulnkey | 20:21 |
| Peng_ | :P | 20:21 |
| lifeless | these are the two keys: first is what was pastebinned, second was what lp had | 20:21 |
| lifeless | ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwUF9kcG18g4d4+LZaBxZy18on2mq3a14fFxHQOnkVMVA3OOLVj6b3KoHqxM5LfDYJRce4kbN0L8Nbe7Usk87Ru434rSFSKHZQuAVH079rM9ayrMk7h/hmGrevW1iAXn5MMAK2VEQUyY+sUGrKmyshoOSBHrh9IkD1Lk/HCgzrqNXYqO7ZyGoyFGBnJypSpZHCyTFNOxUa2g07BJqbXd9RY9yCYZQNLH21guhI36vNBWM6DfU4/xRfUAs5PWyIyHZJQJVv3nncdAlBf200KNJpcQxVlVFJEwkhax07HxIpOXGCV/Dg1cBQJCHXGvFmP39tXP92UltaxLB5u+EbMvQEw== mfoniso@xanax | 20:21 |
| lifeless | ssh-rsa AAAB3NzaC1yc2EAAAABIwAAAQEAwUF9kcG18g4d4+LZaBxZy18on2mq3a14fFxHQOnkVMVA3OOLVj6b3KoHqxM5LfDYJRce4kbN0L8Nbe7Usk87Ru434rSFSKHZQuAVH079rM9ayrMk7h/hmGrevW1iAXn5MMAK2VEQUyY+sUGrKmyshoOSBHrh9IkD1Lk/HCgzrqNXYqO7ZyGoyFGBnJypSpZHCyTFNOxUa2g07BJqbXd9RY9yCYZQNLH21guhI36vNBWM6DfU4/xRfUAs5PWyIyHZJQJVv3nncdAlBf200KNJpcQxVlVFJEwkhax07HxIpOXGCV/Dg1cBQJCHXGvFmP39tXP92UltaxLB5u+EbMvQEw== mfoniso@xanax | 20:21 |
| mfoniso | lifeless: I suppose that would mean the security sources are uncommented in /etc/apt/sources.list? | 20:22 |
| lifeless | mfoniso: just use synaptic | 20:22 |
| mfoniso | ok | 20:22 |
| lifeless | settings - repositories - updates - important security | 20:23 |
| lifeless | make sure that that option is ticked | 20:23 |
| lifeless | then in the main window hit the reload button | 20:24 |
| lifeless | I'll bet it wants to update openssh etc | 20:24 |
| lifeless | possibly openssl; I don't recall where the exact bug was | 20:24 |
| Peng_ | The exact bug was in OpenSSL, so both should be upgraded. | 20:24 |
| mfoniso | you are probably right, some security stuff wasn't enabled | 20:25 |
| mfoniso | and after "reload" it's getting a bunch of stuff | 20:25 |
| mfoniso | lifeless: while I wait for that to complete, a question: | 20:26 |
| mfoniso | from your fine detective work, it's obvious I was uploading a wrong key (having inadvertently deleted and "A" from the key) | 20:26 |
| mfoniso | so why did "bzr launchpad-login mfoniso" not give an error? | 20:27 |
| lifeless | mfoniso: two possible reasons | 20:27 |
| lifeless | one is that it might not be possible to tell a slightly damaged public key; I haven't read the format details | 20:27 |
| lifeless | the other is the lp may be checking for known gotchas but not checking it really is a public key | 20:28 |
| lifeless | I think the former is more likely | 20:28 |
| mfoniso | I'm not sure I follow, but I have the impression it uses the public key to match against my private key when I run that command. | 20:30 |
| mfoniso | if that's the case, then the login should fail cos what it had wasn't my public key | 20:30 |
| mfoniso | ok, my updates are going to take quite sometime, my connection isn't terribly fast | 20:30 |
| mfoniso | hopefully with the new ssh suite, I'll get a proper key and this problem will go away.... forever.. never to return... | 20:31 |
| * mfoniso is very hopeful | 20:31 | |
| === kiko is now known as kiko-phone | ||
| eleftherios | I have been bzr pushing to a remote server and after an interruption I can no longer push, I get a message that is locked. I deleted the info file under .bzr/branch/lock but now it just hangs. ANy ideas? | 20:42 |
| Peng_ | eleftherios: "bzr break-lock $the_url"? | 20:44 |
| lifeless | eleftherios: don't manually change things under .bzr; you'll upset things | 20:44 |
| lifeless | eleftherios: as peng says, 'bzr break-lock url-you-were-pushing-to' | 20:45 |
| eleftherios | let's hope that the deleted info file won't matter | 20:45 |
| Peng_ | eleftherios: Nah, that was part of the locking procedure, so it shouldn't have done any harm. But you should do it properly. | 20:46 |
| eleftherios | Peng_: it just hangs for ages... | 20:49 |
| w00t_ | man oh man, this import is *slow* :/ | 20:49 |
| eleftherios | bzr break-lock returned fine | 20:49 |
| eleftherios | but the push just hangs | 20:50 |
| eleftherios | no messages | 20:50 |
| eleftherios | Peng_: ah here it is, an error message at last: bzr: ERROR: Could not acquire lock "LockDir(<url>)" | 20:51 |
| lifeless | eleftherios: what precise file did you delete | 20:52 |
| eleftherios | .bzr/branch/lock.info | 20:52 |
| eleftherios | .bzr/branch/lock/info | 20:52 |
| lifeless | eleftherios: ok, make sure there are no other files in .bzr/branch/lock/ | 20:53 |
| * eleftherios is checking | 20:53 | |
| eleftherios | there are two dirs: czwk9moldm.tmp held | 20:53 |
| eleftherios | shall I delet them? | 20:53 |
| lifeless | yes | 20:54 |
| eleftherios | ok | 20:54 |
| eleftherios | it worked, thank you Peng_ and lifeless :-) | 20:55 |
| Peng_ | Should break-lock be more accepting of, well, broken locks? | 21:02 |
| lifeless | Peng_: maybe; or check should report or something | 21:04 |
| lifeless | Peng_: OTOH its not naturally occuring | 21:05 |
| meuserj | the latest bzr-gtk is supposed to have nautilus integration turned on by default... but it doesn't seem to be working for me... bzr 1.9, bzr-gtk 0.95.0, python-nautilus 0.5.1 | 21:10 |
| meuserj | is there anything I need to do to enable it? | 21:10 |
| === abadger19991 is now known as abadger1999 | ||
| mfoniso | lifeless: I've updated my openssh suite and now have new keys (not subject to the previous vulnerability) | 21:42 |
| mfoniso | the problem's been solved - I've uploaded the key yo LP, and pushed my code across. :-) | 21:43 |
| mfoniso | thanks a lot for your effort and patience | 21:43 |
| mfoniso | you too Peng_ | 21:43 |
| mfoniso | thank guys, I really appreciate it | 21:43 |
| abentley | spiv: around? | 21:46 |
| lifeless | mfoniso: no problem, happy to help | 21:47 |
| Peng_ | mfoniso: That's great that it's been worked out. Don't forget to run security updates in the future. :) | 21:54 |
| mfoniso | Peng_: will do | 21:54 |
| lifeless | beuno: | 22:38 |
| lifeless | beuno: is there glue around to lsprof loggerhead for a single page request? | 22:39 |
| beuno | lifeless, I don't think so, but rockstar was working on exactly that during the epic if IIRC | 22:40 |
| lifeless | rockstar: ^ yo, dude. | 22:40 |
| lifeless | beuno: is there some function that is called and contains the entire request? | 22:43 |
| lifeless | beuno: cause, if you can point me at that, I can whip it up in about 5 minutes | 22:43 |
| Peng_ | There might be information about profiling Paste somewhere. | 22:44 |
| beuno | lifeless, since mwhudson added streaming to it, I lost track of how that part worked | 22:45 |
| beuno | maybe in loggerhead/app/__init__.py? | 22:46 |
| beuno | are you planning on fixing our memory leaks? :)\ | 22:46 |
| lifeless | beuno: no | 22:47 |
| lifeless | beuno: but nice try | 22:47 |
| lifeless | beuno: I want to know the impact of split-inventory on loggerhead | 22:47 |
| lifeless | so I can make sure it will be suitable/give you advance warning|do any changes needed to work well with it | 22:47 |
| beuno | ah, it's great you would do that | 22:48 |
| beuno | there is quite a bit of the code that interacts with bzrlib that we want to change (it's part of what leaks memory) | 22:48 |
| rockstar | lifeless, I have a profiling branch, yes. | 22:51 |
| rockstar | The Paste profiling middleware isn't great... :( | 22:52 |
| rockstar | So I wrote one that uses cProfile, and spits it to a log file. | 22:52 |
| lifeless | rockstar: where's the brinanch, I'll rip the guyts out and use lbzr's pofiling code | 22:53 |
| lifeless | mucho nico | 22:53 |
| lifeless | excuse my typing, thashing machine right now | 22:53 |
| lifeless | *thrashing8 | 22:53 |
| rockstar | beuno, I have a block of time this weekend that I'll be fixing the memory leaks that we know about for loggerhead. herb would really like this fixed. | 22:53 |
| lifeless | bah. | 22:53 |
| rockstar | lifeless, how did you get non ascii characters in there? | 22:54 |
| beuno | rockstar, so not tomorrow? | 22:54 |
| beuno | I'mm be flying around and recovering from jetlag this weekend :/ | 22:55 |
| rockstar | beuno, probably not. | 22:55 |
| beuno | I'll | 22:55 |
| rockstar | beuno, PQM closes tomorrow, so I'm busting ass to get stuff in. | 22:55 |
| beuno | rockstar, yeah, i did that dance today | 22:55 |
| rockstar | lifeless, https://code.edge.launchpad.net/~rockstar/loggerhead/dev-tools | 22:56 |
| rockstar | lifeless, I'd be interested in the results. | 22:58 |
| rockstar | lifeless, especially if you can land it soon, so I can use it this weekend. | 22:59 |
| spiv | abentley: I'm around now | 23:02 |
| rockstar | Odd_Bloke, re: bzr-laconica -- I'm relatively familiar with the API, if that helps. | 23:02 |
| abentley | spiv: On a call. Catch you later | 23:02 |
| spiv | abentley: ok | 23:02 |
| Odd_Bloke | rockstar: Cool. It's trivial to do with python-twitter (i.e. "x = twitter.Api(username='foo', password='bar'); x.NewStatus('message')"). | 23:04 |
| rockstar | Odd_Bloke, yea, it's similar. I think I might take a stab at it soon (I've been thinking about it for a while) | 23:05 |
| Odd_Bloke | rockstar: I was going to do it earlier, but python-twitter has tests which I'd want to ensure were testing correctly for laconi.ca as well. | 23:06 |
| Odd_Bloke | I'm actually incapable of submitting a patch upstream which doesn't include tests (assuming the project already has tests). | 23:06 |
| Odd_Bloke | I hold bzr developers collectively responsible for that. | 23:06 |
| rockstar | Odd_Bloke, :) | 23:07 |
| lifeless | http://paste.ubuntu.com/71472/ | 23:15 |
| lifeless | poolie: ^ ja1 | 23:15 |
| lifeless | :^ | 23:15 |
| lifeless | spiv:^ etc | 23:15 |
| lifeless | poolie: ja1: spiv: vila: igc: | 23:16 |
| === ja1 is now known as jam | ||
| poolie | hello Odd_Bloke | 23:16 |
| Odd_Bloke | poolie: Hi. :) | 23:17 |
| === AnMaster_ is now known as AnMaster | ||
| igc | morning | 23:41 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!