beuno | lifeless, you know what would be cool? Making bzr-stats have similar indexes to bzr-search. So to make it easy to get stats, and be able to get something line "how many lines X commiter has added" | 00:07 |
---|---|---|
beuno | (in a cheap way, not processing everything each time) | 00:11 |
lifeless | beuno: yah | 00:11 |
edcrypt_ | hi people - are there any script to fetch svn:externals with bzr-svn? | 00:35 |
edcrypt_ | pinax.hotcluboffrance.com uses a lot of external apps, I think I'll write a quick script to fetch each one with bzr... | 00:37 |
Verterok | beuno: pushed, mail sent | 00:53 |
Verterok | I'm off, at least for a few hours (birthday party), seeya later | 00:54 |
beuno | Verterok, cool, have fun | 00:58 |
Verterok | beuno: thanks | 00:59 |
engie | Hi. I've pushed, with sftp, a branch to a web server and I can browse to it at http://www.studentrobotics.org/~stephen/jsdndide/local/ - what do I use to branch from this over http from another machine? I've tried every variant on branch with that URL I can think of! | 01:34 |
jam | engie: You seem to have a shared repository in use on that machine, which is not exposed via http | 01:38 |
jam | I'm guessing you have one in your home dir | 01:38 |
jam | and Apache is only serving things under public_html | 01:39 |
jam | So you need to "bzr init-repo public_html/" or possibly "public_html/jsdndide" before you do another "bzr push" | 01:39 |
engie | OK. Is this because the local branch is under an init-repo directory on my local machine? | 01:40 |
jam | engie: no, there is a repo on the remote machine | 01:40 |
jam | otherwise we would have created one with the branch | 01:40 |
jam | sorry, with the "push" | 01:40 |
jam | engie: It is a good thing to have a shared repo on the other machine, it just needs to be somewhere that people can access it through http | 01:42 |
engie | Ohh, looks like I accidentally pushed a .bzr up there when I was trying things out yesterday | 01:42 |
engie | That machine doesn't have bzr on it | 01:42 |
jam | engie: you don't need one, you can do "bzr init-repo sftp://host/~/public_html" | 01:43 |
=== eMxyzptlk is now known as eMxyzptlk[away] | ||
engie | Is there any benefit to doing that? Does it share history between multiple branches? | 01:43 |
engie | Ahh brilliant, that's working, thanks | 01:46 |
lifeless | jelmer: so what do you think | 03:33 |
lifeless | RAOF: go to http://200.127.6.219:8080/bazaar/bzr/changes | 03:33 |
lifeless | RAOF: and type in the search box | 03:34 |
RAOF | lifeless: Is there really only one change there matching 'lambda'? | 03:40 |
lifeless | looks like | 03:41 |
RAOF | So, the find-as-you-type thing is good. And it's nice and fast. | 03:42 |
RAOF | The formatting seems a little off? | 03:42 |
lifeless | yes | 03:42 |
lifeless | being worked on | 03:42 |
RAOF | Hm, it also doesn't much like "refactor" as a search term. | 03:42 |
lifeless | hey, spare time, hacked up, new search engine etc | 03:42 |
RAOF | It flips between anything matching 're' and 'refactor' :) | 03:42 |
lifeless | beuno: http://200.127.6.219:8080/bazaar/bzr/revision/33?q=lambda doesn't search-complete? | 03:43 |
lifeless | RAOF: uhm, not sure what you mean about flipping | 03:43 |
RAOF | lifeless: Oh, I thought you were after comments/queries/criticisms. If you'd like unadulterated praise, I can provide that, too :) | 03:43 |
lifeless | RAOF: I'm not after either actually :) | 03:43 |
lifeless | RAOF: you can throw peanuts at SLUG on friday if you like | 03:44 |
lifeless | RAOF: this is just a follow up to the xesam comment in u-m | 03:44 |
RAOF | Right. | 03:44 |
RAOF | Aaah, I think I see the problem: Typing r..e..f..a..c..t..o..r gives "refactoring" as the sole hit. | 03:44 |
lifeless | which comment I can't even remember now | 03:44 |
lifeless | just that it made me think I should show you this | 03:45 |
RAOF | Right. Contrary to Amaranth, I think search can be useful. And I can immediately see how this could be nice and useful :) | 03:45 |
lifeless | yah, this is a tiny code base its searching - the bzr-search plugin itself | 03:45 |
lifeless | searching bzr's code base will give more suggstions: | 03:45 |
lifeless | :!bzr search -s refactor | 03:46 |
lifeless | Suggestions: [('refactor',), ('refactored',), ('refactoring',), ('refactorings',), ('refactors',)] | 03:46 |
RAOF | But typing 'refactor' really quickly will briefly bring up 'refactoring', and then bring up all matches for 'r' | 03:46 |
lifeless | RAOF: oh interesting. Thats because its a lot cheaper to search a smaller dataset I suspect | 03:46 |
lifeless | RAOF: so its getting out of order results | 03:46 |
lifeless | beuno: you should include in the response to a lookup, the string that was asked for | 03:47 |
lifeless | beuno: then the client can ignore responses that are not the same as the current search is showing (or perhaps just ones that were done off a shorter prefix) | 03:47 |
lifeless | s/smaller dataset/smaller number of terms/ | 03:48 |
lifeless | RAOF: there is a full command line client to bzr-search, if you prefer that | 03:50 |
lifeless | garh, fugliest site ever: http://python2.near-by.info/index.php?option=com_content&view=article&id=144&Itemid=111 | 03:52 |
lifeless | I was trying to find pure python b+/b-tree implementations | 03:52 |
lifeless | but that one sure seems locked away | 03:52 |
beuno | lifeless, the javascript isn't included in the revision page. It's a bug :) | 04:05 |
lifeless | beuno: :P | 04:06 |
beuno | and, it does wierd things because it looks for every character, no matter how fast you type | 04:06 |
beuno | another know bug | 04:06 |
beuno | I have to make the javascript stop propagating if you type before it sends out the request | 04:07 |
beuno | right now it queues them, which was simpler at the time | 04:08 |
lifeless | beuno: not at all | 04:08 |
lifeless | beuno: my suggestion will make it appear better | 04:08 |
lifeless | say it asked for - in order - 'r', 're', 'ref', 'refa' | 04:08 |
lifeless | but the answers come back in the order 'ref', 'refa', 're', 'r' | 04:08 |
lifeless | thats why it looks wierd | 04:09 |
lifeless | but more specific searches complete faster, so this is actually expected | 04:09 |
beuno | yeah, probably because | 04:09 |
lifeless | now, imagine that in each answer you include the search at the top of it | 04:09 |
beuno | 'r' took longer to process | 04:09 |
lifeless | so the answer for r will have 'I am a search for 'r' | 04:09 |
lifeless | and so on | 04:09 |
lifeless | then the client can do this: | 04:10 |
lifeless | if the current contents of the widget does not start with the response, ignore it | 04:10 |
lifeless | if the contents do start with the response, and no drop down is shown, store the thing the response is for in a variable and show the drop down | 04:11 |
beuno | yes, that's one way to do it. But that would hammer the servers pretty bad on a large scale | 04:11 |
lifeless | if a drop down is already shown, and the response is for a shorter query than the drop down is, discard the response | 04:11 |
lifeless | beuno: this is not a replacement for asking less often; its needed anyway (because under high load this can happen anyway) | 04:12 |
beuno | lifeless, right, that makes sense | 04:12 |
lifeless | (oh, and if the user deletes terms, obviously reset this variable or something | 04:12 |
beuno | so it should be a combination of both | 04:12 |
lifeless | yes | 04:13 |
beuno | ok, so *more* javascript to write :) | 04:13 |
lifeless | :) | 04:13 |
beuno | but it's great that we're debugging this so much, it may get in shape to go into trunk sooner | 04:14 |
beuno | I'd like to add a few optional plugins to LH | 04:14 |
beuno | this being one of the strongest recommended ones | 04:14 |
beuno | also, I have plans to get the integrated into bzr-gtk, if no one does it first | 04:16 |
beuno | it's even better as a desktop application ;) | 04:16 |
lifeless | perhaps jelmer will now hes seen it work :) | 04:19 |
lifeless | beuno: perhaps these glitches (like revision page missing the javascript should be bugs ? | 04:19 |
beuno | lifeless, I'd have to create a project for that. Do you think it's worth having a seperate project for it? | 04:20 |
lifeless | nah just on loggerhead | 04:20 |
beuno | oh, sure, that sounds like a good idea | 04:21 |
beuno | I'll file the revisions one (and annotate, and the rest) if you file the search order :) | 04:22 |
lifeless | k | 04:22 |
lifeless | done | 04:23 |
beuno | me too | 04:24 |
jml | File "/home/jml/.bazaar/plugins/svn/core.py", line 25, in <module> | 04:24 |
jml | from bzrlib.plugins.svn.client import get_config | 04:24 |
jml | ImportError: No module named client | 04:24 |
jml | I got that when I tried to branch a svn branch with bzr | 04:25 |
lifeless | is there a client.py file ? | 04:25 |
jml | there's a client.c file. Apparently I need to build bzr-svn. | 04:26 |
lifeless | jelmer: ^ | 04:27 |
* jml installs a bunch of stuff | 04:29 | |
jml | ok. that version of bzr-svn is not going to help me much. | 04:30 |
lifeless | now | 05:01 |
lifeless | Peng: around? | 05:01 |
lifeless | jml: ping | 05:03 |
jml | lifeless: pong | 05:03 |
lifeless | loggerhead is down | 05:03 |
lifeless | do you know if we moved it off vostok yet ? | 05:03 |
jml | lifeless: no I don't. | 05:05 |
lifeless | dang | 05:05 |
lifeless | do you know the new machine name it would have moved too ? | 05:06 |
beuno | lifeless, AFAIK, the new version of LH will be deployed on wendsday, so maybe that's when they're moving it? | 05:07 |
lifeless | beuno: these things are unrelated | 05:07 |
lifeless | beuno: deployments are routine; moving to a new machine is reconfiguration, testing etc | 05:07 |
lifeless | mwhudson was talking about doing it driday | 05:08 |
jml | lifeless: no, I don't. | 05:08 |
lifeless | anyhow, It's 5am in London, I'll wait till 7am and ring james | 05:08 |
lifeless | jml: have you played with kjbuckets ever? | 05:10 |
lifeless | http://gadfly.sourceforge.net/kjbuckets.html | 05:10 |
jml | lifeless: years ago | 05:10 |
lifeless | thats more than I; impressions? | 05:10 |
lifeless | http://bazaar-vcs.org/RobertCollins#head-b2dc9ae46f1860c46f79682db455c3512152d148 | 05:10 |
jml | lifeless: memories more like it. in the end I did my own graph classes. | 05:11 |
jml | lifeless: I recall the API as being a little cumbersome. | 05:12 |
lifeless | k, thats sufficient to tip me away | 05:12 |
lifeless | needing to compile would be a burden anyhow | 05:12 |
lifeless | scary: http://www.pythonweb.org/engine/ | 05:14 |
Peng | lifeless: pong | 05:16 |
lifeless | Peng: do you have that magic to get the new LH running at a subfolder? | 05:16 |
Peng | lifeless: Subfolder? | 05:17 |
lifeless | yeah, so it can fit in an existing site | 05:17 |
lifeless | mwhudson showed you how last week | 05:17 |
Peng | lifeless: Oh. | 05:17 |
Peng | lifeless: Here's my serve-branches.py: http://paste.pocoo.org/show/75647/ | 05:19 |
lifeless | Peng: thanks! | 05:19 |
Peng | lifeless: (Then I just used lighty's mod_proxy/mod_proxy_core.) | 05:19 |
lifeless | Peng: yeah, I have squid for that :P | 05:20 |
Peng | :) | 05:20 |
lifeless | loggerhead is back | 05:35 |
beuno | lifeless, are you deploying the new LH in squid-cache.org? | 05:35 |
lifeless | beuno: not just yet, I'm going to deploy a demo copy at my house | 05:36 |
beuno | lifeless, re: bug #242046 | 05:41 |
ubottu | Launchpad bug 242046 in bzr "ppa feisty bzr and bzrtools not installable" [Undecided,New] https://launchpad.net/bugs/242046 | 05:41 |
beuno | is bzr uninstalable too? | 05:41 |
beuno | I used PPAs copy feature, and have had to re-upload without it akready for gutsy | 05:41 |
lifeless | beuno: bzr and bzrtools - both | 05:42 |
* beuno grumbles | 05:42 | |
beuno | I'll re-upload now | 05:42 |
beuno | so the copy tool is not really useful... | 05:42 |
beuno | (or I'm using it wrong, which is more probable) | 05:43 |
beuno | hrm, that's odd. I *did* re-upload bzr for feisty | 05:44 |
beuno | not bzrtools though | 05:45 |
lifeless | well | 05:45 |
lifeless | the problem is the dependency on python-central | 05:45 |
beuno | buildlog seems to think the right version was used: http://launchpadlibrarian.net/14569048/buildlog_ubuntu-feisty-i386.bzr_1.5.0-1~bazaar1~feisty1_FULLYBUILT.txt.gz | 05:49 |
lifeless | ok | 05:51 |
lifeless | may just be bzrtools;) | 05:51 |
lifeless | let me uninstall that and upgrade bzr | 05:51 |
beuno | I'm fixing bzrtools now | 05:51 |
lifeless | ok bzr is fine | 05:51 |
beuno | cool, I'll upload bzrtools in a minute | 05:52 |
beuno | sorry about that | 05:52 |
lifeless | np | 05:55 |
* beuno uploads and waits for the build deamons to wake up | 05:59 | |
Peng | Bug 241938?! | 06:01 |
ubottu | Launchpad bug 241938 in bzr "MemoryError on "bzr ci" for 1396 Megabytes file" [Undecided,New] https://launchpad.net/bugs/241938 | 06:01 |
lifeless | Peng: yah, we should be able to handle such files | 06:03 |
lifeless | theres nothing in the disk format preventing handling them | 06:04 |
Peng | How much work would it take not to read entire files into RAM? | 06:04 |
lifeless | Peng: for simple storage and tree building, not a huge amount, though doing it without affecting performance for normal files is important | 06:06 |
lifeless | Peng: for delta storage, diffs, merge its much tricker | 06:08 |
lifeless | delta storage depends on diffs | 06:10 |
lifeless | merge could just write .BASE, .OTHER, .THIS and give up | 06:10 |
lifeless | but three-way merge etc is nice to offer, and that depends on diff | 06:10 |
lifeless | in a high entropy file the line count is about 1/256 the file length, a 1.4G file is 5.6million lines long | 06:11 |
lifeless | if we hash the file to (say) sha1, its still 100MB per instance of the file (20*5.6million) | 06:12 |
lifeless | which is pretty high | 06:12 |
lifeless | and easily exploited to cause DOS by having many more \n's. | 06:13 |
beuno | lifeless, re-uploaded bzrtools, should be fixed, but can you double check? | 06:21 |
lifeless | beuno: its good now | 06:25 |
beuno | :) | 06:26 |
jelmer | lifeless: hmm, I'll give that a try some time | 07:19 |
jelmer | lifeless: the loggerhead frontend certainly is very fast! | 07:19 |
jelmer | jml: you need to run make these days (or ./setup.py build_ext --inplace) | 07:20 |
lifeless | jelmer: revno 42 should work nicely for you | 07:20 |
Peng | jelmer: Is bzr-svn supposed to have any old-style classes? | 07:20 |
jelmer | Peng: nope | 07:21 |
Peng | It has 11. :P | 07:21 |
jelmer | is there anything in particular bad about old style classes? | 07:21 |
jelmer | or is it just a stylistic thing? | 07:22 |
Peng | For me, it's stylistic. | 07:22 |
lifeless | jelmer: is there a small svn repo around you run live tests against ? | 07:26 |
lifeless | jelmer: in particular one that bzr-svn supports :P | 07:26 |
jelmer | I generally use svn://svn.samba.org/smb-build/trunk | 07:28 |
jelmer | lifeless: if you've got any repositories in particular that don't work, please file a bug.. | 07:29 |
lifeless | jelmer: do you support repository.weave_store.get_weave ? | 07:29 |
jelmer | lifeless: nope, don't support any weave implementation at all | 07:30 |
jelmer | not as provider, that is | 07:30 |
lifeless | jelmer: are you working on it? (will be needed for stacking) | 07:30 |
Peng | jelmer: fwiw, I have a branch up at http://bzr.mattnordhoff.com/bzr/bzr-svn/trivial/new-style-classes that fixes all of the old-style classes I could find. | 07:30 |
jelmer | lifeless: I'm planning to work on it, haven't started yet | 07:31 |
lifeless | jelmer: and can you point me at the bits of bzr-svn that would give access to the svn backing data? | 07:31 |
jelmer | lifeless: Trying to finish my own python bindings atm | 07:31 |
jelmer | lifeless: what do you mean with backing data specifically? | 07:31 |
jelmer | lifeless: *svn python bindings | 07:32 |
jelmer | Peng: thanks, I'll have a look at merging that | 07:32 |
Peng | :) | 07:32 |
lifeless | jelmer: I'd like to make bzr-search index svn repos | 07:34 |
lifeless | jelmer: all it needs is a non-colocated branch object supporting the repository graph and versionedfile apis | 07:35 |
jelmer | Peng: merged, thanks | 07:36 |
jelmer | lifeless: Getting the versionedfile APIs to work is a fair amount of work | 07:37 |
jelmer | lifeless: the graph code is all there | 07:37 |
lifeless | eww | 07:39 |
lifeless | bzr: ERROR: libsvn._core.SubversionException: ("Can't find a temporary directory", 20014) | 07:39 |
lifeless | jelmer: ^ hints? | 07:40 |
lifeless | jelmer: I did '/home/robertc/bin/bzr', 'checkout', '--lightweight', 'svn://svn.samba.org/smb-build/trunk', 'sbm-build-test' | 07:40 |
lifeless | 4.G free on / | 07:44 |
lifeless | 198 files in /tmp/ | 07:44 |
jelmer | hmm, no - what version of bzr-svn is this? | 07:46 |
lifeless | svn --version | 07:46 |
jelmer | you may want to try with the latest release just to be sure | 07:46 |
lifeless | svn, version 1.4.6 (r28521) | 07:46 |
lifeless | compiled Mar 11 2008, 08:53:49 | 07:46 |
lifeless | I'm running hardy | 07:46 |
lifeless | happens just running svn co | 07:47 |
jelmer | also happens running svn co you mean? | 07:50 |
lifeless | svn: Can't find a temporary directory | 07:51 |
lifeless | I mean | 07:51 |
lifeless | $ svn co svn://svn.samba.org/smb-build/trunk | 07:51 |
lifeless | svn: Can't find a temporary directory | 07:51 |
jelmer | time for strace :-) | 07:51 |
lifeless | garh | 07:52 |
lifeless | I was hoping you had seen fuckage before :) | 07:52 |
jelmer | I vaguely recall something like this | 07:53 |
jelmer | but don't remember the specifics :-( | 07:53 |
Peng | Set TMP or whatever, just to check? | 07:53 |
lifeless | server side fuckage | 07:58 |
lifeless | http://rafb.net/p/sOwYPM49.html | 07:58 |
lifeless | the first line, I think, is the key | 08:00 |
lifeless | read(3, "( success ( ) ) ( success ( 36:e8204dac-47fa-0310-9482-a4e8a03ab89e 29:svn://svn.samba.org/smb-build"..., 4096) = 105 | 08:00 |
lifeless | sorry, line 5 | 08:01 |
lifeless | read(3, "( success ( ( ) 0: ) ) ( failure ( ( 20014 32:Can\'t find a temporary directory 77:/home/tretkowski/s"..., 4096) = 170 | 08:01 |
lifeless | success (failure!) | 08:01 |
jelmer | hardcoehmm, chroot broken perhaps :-( | 08:01 |
jelmer | hardcoded paths? | 08:02 |
lifeless | well, I'm not tretkowski :P | 08:02 |
lifeless | bzr-svn work with gcode yet ? | 08:02 |
jelmer | yeah, always has afaik | 08:02 |
lifeless | k | 08:03 |
lifeless | I'll hunt for a small project there ;P | 08:03 |
jelmer | you just need the svn+ hack to work around the fact that bzr aborts as soon as it gets a permission denied | 08:03 |
Peng | Oh. | 08:05 |
Peng | Hmm. | 08:06 |
Peng | With the 0.4 branch, trying to branch http://ack.googlecode.com/svn/trunk/ (with or without "svn+") exits after a second with a return code of 11. | 08:06 |
asabil | lifeless: last time I checked bzr-svn was unable to checkout some code from gcode : http://code.google.com/p/waf/ | 08:07 |
jelmer | asabil: even with the svn+ hack? | 08:13 |
asabil | jelmer: hack ? I was using either http:// or svn+ssh:// | 08:14 |
jelmer | asabil: I don't remember seeing a bug report about that :-) | 08:15 |
jelmer | asabil: I meant svn+http:// | 08:15 |
asabil | I don't think I tried svn+http | 08:16 |
lifeless | jelmer: what needs to happen to fix the bug? | 08:16 |
jelmer | lifeless: bzr needs to be somewhat more persistent when probing for repository formats | 08:17 |
jelmer | rather than aborting the minute it gets something that's not NotBranchError | 08:17 |
lifeless | jelmer: why? what raises the permission denied ? | 08:18 |
jelmer | lifeless: trying to open .bzr/branch/format raises a 403 | 08:18 |
lifeless | rather than a 404? | 08:18 |
jelmer | yes, afair that was the problem | 08:19 |
lifeless | hmmm | 08:19 |
lifeless | so | 08:19 |
lifeless | I don't think the driver loop should catch more things | 08:19 |
lifeless | the probe functions should catch whatever other things that neither indicate an error nor a found branch | 08:20 |
jelmer | I don't think the Bzr branch format catching 403 is very nice though | 08:20 |
jelmer | if something's got to do it, rather have it be the driver loop | 08:21 |
lifeless | well | 08:23 |
lifeless | how can the driver loop tell that 403 means 404? | 08:23 |
lifeless | have we filed a bug with googlecode that it gives 403 when a 404 is appropriate? | 08:25 |
lifeless | (I agree that the Bzr branch format catching 403 is not nice). But I also think that the driver catching 403 is not nice | 08:25 |
lifeless | because, if you had nested branches, typeA and typeB | 08:26 |
jelmer | ah, and the other reason the svn+ stuff exists is to work around the ssl certificate stuff | 08:26 |
lifeless | and there is a permission problem on typeB, typeA can be detected incorrectly | 08:26 |
lifeless | what will address the ssl certiicate stuff? | 08:29 |
jelmer | there's an ancient bug report open about bzr dealing with self signed certificates | 08:31 |
lifeless | k, I have a lightweight checkout | 08:38 |
lifeless | so I can fiddle | 08:38 |
lifeless | no promises, but if I get something shaping up I'll give you a branch | 08:39 |
lifeless | now for dinner and games though :) | 08:39 |
jelmer | cool | 08:40 |
jelmer | have a nice weekend | 08:40 |
* jelmer goes and removes the last dependencies on the official svn python bindings | 08:40 | |
Jc2k | oooh | 08:45 |
gour | congrats jelmer | 08:45 |
gour | they finally did 1.5.0, but still.... | 08:45 |
Peng | Would your bindings be usable by other projects? | 08:45 |
jelmer | Peng: in theory, yes | 08:46 |
jelmer | however, they're not very well documented and the set I converted is limited to what bzr-svn needs | 08:47 |
gour | that's good enough | 08:47 |
jelmer | if there are other projects interested in using these bindings as well, I'd happily provide them as a separate package | 08:49 |
jelmer | I'd rather wait for such projects to ask first though, rather than putting all of the work in now to find out nobody cares | 08:53 |
lifeless | jelmer: you still support 1.4 w/patches? | 09:27 |
lifeless | jelmer: (hardy only has that ...) | 09:27 |
lifeless | jelmer: how do I get a repository id out of a bzr-svn branch object? | 09:29 |
jelmer | lifeless: yeah, patches aren't even necessary anymore | 09:30 |
jelmer | lifeless: branch.repository.uuid | 09:30 |
lifeless | jelmer: and the relative path to the branch? | 09:46 |
lifeless | jelmer: I'm going to use uuid/branch-path-here/ as a lookaside index path | 09:46 |
jelmer | lifeless: branch.get_branch_path() | 09:50 |
lifeless | hi AfC | 10:08 |
AfC | lifeless: Good evening | 10:09 |
AfC | Is there a command [line client command] which lists all the revision properties / metadata of a given revision? | 10:14 |
lifeless | I don't think there is today | 10:14 |
lifeless | some of the data can be pretty big and is not human consumable | 10:14 |
AfC | Huh | 10:15 |
lifeless | gcommit stores per-file commit messages as revision properties | 10:15 |
AfC | (oh yeah? What consumes it?) | 10:16 |
lifeless | I think gannotate or something | 10:16 |
lifeless | jam will know | 10:16 |
AfC | (not important) | 10:16 |
=== yacc_ is now known as yacc | ||
lifeless | AfC: speaking of locale, ulrich drepper rejected the latin patch for libc | 10:33 |
lifeless | AfC: so Ubuntu is carrying it locally :) | 10:33 |
lifeless | jelmer: ok, I've got to the point where File "/home/robertc/.bazaar/plugins/svn/repository.py", line 332, in get_inventory_weave | 10:34 |
lifeless | raise NotImplementedError(self.get_inventory_weave) | 10:34 |
lifeless | is triggered | 10:34 |
lifeless | jelmer: its kinda slow to get that far :( | 10:34 |
AfC | lifeless: Ulrich has always been a hard case. | 10:48 |
lifeless | AfC: oh yes :) | 10:48 |
lifeless | he applied his trademark tact and diplomacy | 10:49 |
AfC | Maybe if you were to become a Benedictine monk or something. That might add credibility (you know, since you have none). | 10:49 |
lifeless | :) | 10:49 |
lifeless | wasn't my credentials, its was the locals | 10:49 |
lifeless | 'just another made up locale' wa the prhase I think | 10:53 |
AfC | Yeah, I can see that. Latin is a lot like Klingon, after all. | 10:55 |
lifeless | :P | 10:56 |
lifeless | ok, its working now for commits | 11:01 |
lifeless | jelmer: | 11:01 |
lifeless | jelmer: revno 43, if you'd like to tell me what I'm doing wrong that makes it so slow, that would be cool. | 11:04 |
lifeless | jelmer: ping | 11:40 |
lifeless | jelmer: where do you want bugs filed, ctrl-C was having trouble stopping 'bzr search test' on http://waf.googlecode.com/svn/trunk | 11:42 |
* Jc2k is tempted to forcefully upgrade parents to ubuntu | 11:46 | |
Jc2k | lifeless: will bzr-search work against bzr-mirror.gnome.org :) | 11:47 |
lifeless | Jc2k: yes, bzr-mirror is native bzr | 11:52 |
lifeless | Jc2k: I recommend fresh indices with revno 42 | 11:52 |
Jc2k | cool i might give that a spin later | 11:53 |
lifeless | if you do, you could also try the loggerhead branch that supports it :) | 11:59 |
Jc2k | presumably thats now all shiny and wsgi-ify-arific | 12:00 |
Jc2k | in which case, take me to ur url :) | 12:00 |
lifeless | yes | 12:00 |
lifeless | https://code.edge.launchpad.net/loggerhead | 12:01 |
lifeless | second from top | 12:01 |
Jc2k | this ok for bzr-search: cd ~/.bazaar/plugins && bzr branch lp:bzr-search search && cd search && bzr revert -r40 | 12:07 |
Jc2k | ? | 12:07 |
lifeless | no need to revert | 12:07 |
Jc2k | 40 was wrong anyway, i meant 42 | 12:09 |
lifeless | 43 is fine too | 12:09 |
lifeless | but < 42 will use a different index logic that gives poorer results on searches | 12:09 |
Jc2k | i see | 12:10 |
Jc2k | rar, the search branch of loggerhead hard depends on a bzr-search that is globally installed | 12:10 |
lifeless | well | 12:11 |
lifeless | file a bug | 12:11 |
lifeless | and show me the error | 12:11 |
mwhudson | surely you can fiddle BZR_PLUGINS_PATH ? | 12:11 |
Peng | Or run LH as a user with it in his ~/.bazaar/plugins? | 12:11 |
lifeless | Jc2k: what user does loggerhead run as | 12:12 |
Jc2k | lifeless: at the moment, as me, but in a second im going to move it to x469yq | 12:14 |
lifeless | pastebin thee rrror | 12:15 |
lifeless | Jc2k: it should not depend on a global install of bzr-search | 12:17 |
lifeless | Jc2k: if you can pastebin the error I can advise | 12:17 |
lifeless | Jc2k: for different accounts, just put bzr-search in the ~/.bazaar/plugins/search dir in the relevant account | 12:18 |
Jc2k | lifeless: sorry, laptop just ran out of power | 12:18 |
Jc2k | lifeless: thats where it is | 12:18 |
Jc2k | this is going to be painful.. *tries to remember copy and paste in putty* | 12:19 |
Jc2k | lifeless: line 20 of loggerhead/search.py | 12:21 |
Jc2k | from bzrlib.plugins.search import errors | 12:21 |
Jc2k | No module named search | 12:21 |
lifeless | ok, do this | 12:21 |
lifeless | python -c 'import bzrlib.plugins.search' | 12:21 |
Jc2k | same error | 12:22 |
lifeless | ok | 12:22 |
lifeless | for me: | 12:23 |
Jc2k | ah | 12:23 |
Jc2k | got it | 12:23 |
lifeless | :P | 12:23 |
Peng | Does Loggerhead use any global bzr settings for anything, like your username or something? | 12:24 |
lifeless | Peng: well, it doesn't do commits | 12:24 |
Peng | Yeah, but.. | 12:24 |
lifeless | Peng: but yes, it does load the global settings | 12:24 |
Peng | Do any of them affect it? | 12:24 |
lifeless | dunno | 12:24 |
Peng | My only ones are email, editor and LP user. | 12:25 |
lifeless | I can't imagine any of those affecting it | 12:25 |
Peng | Anyway, I'm moving it to its own user, and wondering if I should copy bazaar.conf over. | 12:25 |
lifeless | Jc2k: what was wrong? | 12:25 |
* Jc2k blushes | 12:26 | |
Jc2k | fix was | 12:26 |
lifeless | Jc2k: also, currently indices are per-branch, not per-repository (because search shouldn't return commits from a different branch), so you probably only want to index trunk; a full text index is a pretty large fraction of the history in the first place | 12:26 |
Jc2k | cd ~/.bazaar && mv search plugins/ | 12:26 |
lifeless | Jc2k: :P | 12:26 |
* Jc2k blushes some more | 12:26 | |
Jc2k | ok. i'll index conduit/trunk first. what is the command foo? | 12:27 |
lifeless | bzr index conduit/trunk | 12:27 |
lifeless | or | 12:27 |
lifeless | cd conduit/trunk && bzr index | 12:27 |
Jc2k | and i can run that every time i update the mirror? | 12:28 |
lifeless | nah | 12:28 |
lifeless | it will keep itself up to date once indexed | 12:28 |
Jc2k | sweet! | 12:28 |
lifeless | (or at least its meant to; we can check that it is by running your script and searching for something in the most recent commit) | 12:28 |
* Jc2k desperately wants to learn more about bzr internals some time so he can hack on things :) | 12:30 | |
Jc2k | k, the conduit index was quite quick | 12:30 |
Jc2k | awesome | 12:32 |
* Jc2k searches for fixme :) | 12:32 | |
lifeless | its currently case insensitive only | 12:32 |
lifeless | sorry | 12:32 |
lifeless | sensitive | 12:33 |
Jc2k | what are your thoughts on showing GNOME this? | 12:33 |
Jc2k | i want to keep up the "look at this shiny shiny" blogging | 12:33 |
lifeless | well | 12:33 |
lifeless | you're supporting the mirror :P | 12:33 |
Jc2k | hmm | 12:34 |
lifeless | I would say | 12:34 |
lifeless | give beuno a few days to polish loggerheads UI for it | 12:34 |
lifeless | its web2.0y | 12:34 |
lifeless | but a little crude | 12:35 |
Jc2k | kk | 12:35 |
lifeless | talk to him when he gets up though | 12:35 |
lifeless | and get it running so you can tell him what bits suck and what don't :) | 12:35 |
Jc2k | :D | 12:35 |
Jc2k | the only think i noticed is that it finds a revision, but i have no clue what file the match is in | 12:36 |
Jc2k | thing, even | 12:36 |
ToyKeeper | hrrm... looks like bzr_access does 'bzr' but not 'access' yet. | 12:36 |
lifeless | ToyKeeper: I recall a patch or two for that recentl | 12:37 |
ToyKeeper | I took a quick look, and it appears the reason it doesn't do per-repo permissions is because the repo path isn't specified in SSH_ORIGINAL_COMMAND. | 12:38 |
ToyKeeper | Every "bzr push bzr+ssh://host/path/to/repo" results in "bzr serve --inet --directory=/ --allow-writes" on the remote side. I'm not sure how to get the /path/to/repo part. | 12:41 |
ToyKeeper | At least, it's not in os.environ anywhere. Maybe there's a better place to look. :) | 12:43 |
lifeless | ToyKeeper: does bzr_access hook into the smart server methods, or just wrap things ? | 12:44 |
ToyKeeper | As far as I can tell, it just wraps things... look up the ssh user, then replace the --directory= and --allow-writes parameters, and exec bzr. | 12:45 |
lifeless | ah | 12:45 |
ToyKeeper | Granted, that's sufficient for my personal use... but it's not very useful for more than one user. :) | 12:47 |
clemente | Hi. I have this: „etec“ is a link to /etc, and is listed to be added to the repository. I want not to add it, so I try: „bzr remove --keep etec“. And the result: „bzr: ERROR: Not a branch: "/etc/".“ | 12:51 |
clemente | So I can't remove it | 12:51 |
lifeless | clemente: I think there is a bug open | 12:52 |
lifeless | clemente: you need to: | 12:52 |
lifeless | rm <link>; bzr remove <link> | 12:52 |
lifeless | ln -s <whatever> | 12:53 |
Peng | (or mv <link> <link>.bak or something..) | 12:53 |
clemente | lifeless: thanks, that works | 12:54 |
clemente | It's bug 236149, by the way | 13:00 |
ubottu | Launchpad bug 236149 in bzr ""Error: Not a branch" when trying to revert a symlink" [Low,Triaged] https://launchpad.net/bugs/236149 | 13:00 |
Pieter | Vienna:5.0 pieter$ time bzr pull lp:mysql-server/6.0 | 13:00 |
Pieter | bzr: ERROR: These branches have diverged. Use the merge command to reconcile them. | 13:00 |
Pieter | real25m3.689s | 13:00 |
Pieter | why does that have to take 23 minutes? | 13:01 |
Jc2k | what happens if you do it again? | 13:01 |
mwhudson | which bzr version? | 13:01 |
mwhudson | there was a bug here | 13:01 |
Pieter | 1.5 | 13:02 |
Peng | Were the performance issues pulling from packs to knits fixed? | 13:02 |
Pieter | Jc2k: then it's 'just' 23 seconds | 13:02 |
lifeless | Pieter: it has pulled the data in | 13:02 |
lifeless | Pieter: repeat the operation; bet you it will be much faster | 13:03 |
Pieter | yeah, 60x as fast is ok | 13:04 |
lifeless | Peng: well, knits to packs has to annotate | 13:04 |
lifeless | Pieter: hmm, 30 seconds still. likely an index problem: | 13:04 |
lifeless | http://bazaar-vcs.org/RobertCollins#head-b2dc9ae46f1860c46f79682db455c3512152d148 | 13:05 |
lifeless | Peng: I believe it should be 'ok' to pull to knits, not stellar, but ok | 13:05 |
Jc2k | Pieter: can you answer a gitweb question? | 13:06 |
Pieter | Jc2k: perhaps, try me :) | 13:06 |
Jc2k | *grabs a url* | 13:07 |
Jc2k | ok question 1, how can i make the first page faster. its scanning 520 modules and is insanely slow. | 13:08 |
Jc2k | question 2, have a look at http://git-mirror.gnome.org/?p=glib;a=summary | 13:09 |
Pieter | what version of gitweb do you have? (out of which git version?) | 13:09 |
Pieter | there have been patches for the slow listing, I think they were integrated into 1.5.5 or 1.5.6 | 13:09 |
Jc2k | its a bare mirror, i have down git --bare svn fetch, how to i update "master" to svn/trunk? | 13:10 |
Jc2k | *done | 13:10 |
Pieter | git update-ref svn/trunk master | 13:10 |
Pieter | eh | 13:11 |
Pieter | reverse those | 13:11 |
Jc2k | is that a once per update thing, or a once per repository thing? | 13:11 |
Pieter | once per update | 13:11 |
Pieter | if you want to do it for always, try git symbolic-ref master svn/trunk | 13:12 |
Pieter | or rather, git symbolic-ref refs/heads/master refs/remotes/svn/trunk, or wherever it is | 13:13 |
Jc2k | will that cause any problems for people cloning from git-mirror.gnome.org ? | 13:14 |
Pieter | no | 13:15 |
Jc2k | ace | 13:17 |
Jc2k | thank you for answering my questions Pieter, as always :) | 13:17 |
Jc2k | what as the git-gc command you wanted me to run? | 13:17 |
Pieter | git repack -adf --window=100 or so should do | 13:18 |
Jc2k | i'll run that and the symbolic-ref thing when theres some free time on the server then | 13:18 |
Jc2k | im guessing that'll be about 4 hours | 13:19 |
Pieter | make sure you have the refs right :) i'm not sure wher git-svn stores its refs | 13:19 |
Jc2k | will do! | 13:20 |
Pieter | Jc2k: http://kerneltrap.org/mailarchive/git/2008/3/13/1160884 << about projcet list caching | 13:22 |
Jc2k | Pieter: does one of those say "this is in HEAD and will be in git 1.x"? | 13:39 |
Jc2k | :) | 13:40 |
Pieter | Jc2k: no. There's a gitweb caching GSoC going on though that will be in 1.6.0 | 13:40 |
Jc2k | ah | 13:40 |
Peng | This is weird... when one of my branches was branched over http, the smart server was barely used at all. | 13:49 |
Peng | Absolutely none of the more bandwidth-intensive requests used it. There are a couple dozen hits to the indexes and packs. | 13:49 |
awilkins | Peng: Do people find HTTP more convenient? | 13:52 |
Peng | awilkins: ? | 13:52 |
awilkins | Peng: Are you saying that making it availeble over HTTP makes people use the smart server less, or that serving over HTTP doesn't USE the smart server? | 13:53 |
lifeless | Peng: it falls back to VFS operations for many things today; spiv has been working on making it do so less; possibly there are bugs there, or the client was one tat doesn't have his work incorporated | 13:54 |
Peng | One person branched this branch over http. It auto-detected bzr+http being available, but barely used it. | 13:55 |
Peng | There were 35 hpss requests and 49 for packs or indices. | 13:56 |
lifeless | wow, very chatty | 13:56 |
Peng | Hmm, does the smart server log? | 13:56 |
lifeless | yes | 13:56 |
lifeless | .bzr.log | 13:56 |
Peng | Huh. | 13:56 |
Peng | Well, it's running as my web servers user, and it doesn't have a home dir. Oh well. | 13:57 |
Peng | server's* | 13:57 |
jelmer | lifeless: filed as bugs against bzr-svn in lp | 14:09 |
* jelmer reads his backlog | 14:10 | |
spiv | jelmer: I've seen flurry of commits on bzr-svn recently. How's the cext going? | 14:10 |
jelmer | spiv: it's there and working :-) | 14:13 |
spiv | jelmer: sweet | 14:15 |
spiv | jelmer: if I want to try out the shiny new stuff, which branch should I sue? | 14:21 |
spiv | Er, "use" :) | 14:21 |
Jc2k | eh, we know your motives now spiv :P | 14:22 |
jelmer | the 0.4 one | 14:22 |
jelmer | lifeless: woot on getting bzr-search working against svn! | 14:24 |
spiv | jelmer: hmm, I get a segfault if I try to pull in my python trunk conversion (in svn_auth_set_parameter), and traceback if I try to pull in my Twisted trunk checkout (KeyError for u'trunk' in _get_old_id). | 14:26 |
spiv | I mustn't be lucky tonight :) | 14:27 |
jelmer | please try pulling again | 14:28 |
jelmer | I'm pushing my latest changes now | 14:29 |
jelmer | hmm, one sec | 14:29 |
* spiv -> zzz | 14:37 | |
jelmer | spiv: g'night | 14:40 |
jelmer | awilkins: ping | 14:40 |
=== mario_ is now known as pygi | ||
Jc2k | lifeless: my server is about to explode :P k thx bai | 14:55 |
Jc2k | its sucked up 95% of memory :) | 14:58 |
Jc2k | it seems to have calmed down now | 14:59 |
=== gour is now known as gour|afk | ||
jelmer | Jc2k: what were you running? | 15:33 |
Jc2k | jelmer: bzr index | 15:36 |
Jc2k | on gcompris | 15:36 |
MvG | Is there any verbose documentation about the different repository formats? I'm especially curious about the difference between rich-root and rich-root-pack. | 15:52 |
Peng | MvG: rich-root is dirstate-tags (well, the repo hasn't changed since knit) only with rich roots, and rich-root-pack is pack-0.92 only with rich roots. | 16:15 |
MvG | What are rich roots? | 16:18 |
jelmer | MvG: in rich root formats, the root directory has a file id | 16:21 |
MvG | Ah. | 16:22 |
jelmer | MvG: older formats don't store a file id for the root directory | 16:22 |
MvG | What's the kind of operation that uses this feature? | 16:23 |
MvG | Anything to do with having nested branches? | 16:23 |
MvG | What's the status of nested branches, by the way? | 16:23 |
jelmer | yeah, nested branches need root ids | 16:24 |
jelmer | bzr-svn also relies on root ids because it avoids a lot of special casing and corner cases | 16:24 |
jelmer | MvG: LarstiQ was working on it last I heard | 16:25 |
jelmer | LarstiQ: ping | 16:25 |
LarstiQ | has no one else done anything with it? | 16:34 |
jelmer | not afaik | 16:36 |
LarstiQ | ok | 16:36 |
vxnick | Hi All - got a bit of a problem if anyone can help? | 16:46 |
fredreichbier | just ask, vxnick ;) | 16:47 |
vxnick | Thanks - basically, I'm tracking an upstream by way of "svn export" (as I can't get bzr-svn working for one reason or another) | 16:48 |
vxnick | I'm tracking this in "upstream/project", (which I "bzr init"-ed) - I then "bzr add" and "bzr commit" these files | 16:49 |
vxnick | The problem I'm having is merging the contents of that project into an empty trunk (which is a checkout) | 16:49 |
vxnick | It tells me the working copy is out of date, although a "bzr update" doesn't do anything as there's nothing in the repository | 16:49 |
vxnick | I also managed to get a nice traceback somehow :( | 16:50 |
vxnick | Now, merging the contents into trunk works fine (bzr status shows N+ for each file), but I can't commit these as it says there are no changes to commit | 16:51 |
vxnick | When I bzr update, it shows "-D" next to each file, and I get "bzr: ERROR: Reserved revision-id {null:}" (presumably because I'm on revision 0) | 16:55 |
vxnick | bzr status then shows whitespace next to each filename | 16:56 |
vxnick | and bzr commit deletes the files, but throws a traceback and this error: bzr: ERROR: exceptions.AssertionError: 2 != 1 | 16:56 |
vxnick | any ideas, fredreichbier? | 16:57 |
Peng | Wow. | 16:59 |
Peng | Using "svn export" for a mirror is pretty awful. | 16:59 |
Peng | You should really try to get bzr-svn -- or any other converter -- working. | 16:59 |
vxnick | Yeah, I gave it a couple of goes but with no luck | 16:59 |
Peng | What issues were you having? | 17:00 |
vxnick | bah, I can't remember now | 17:00 |
vxnick | it was a couple of weeks ago I last tried | 17:00 |
vxnick | I was working on the basis that "svn export" doesn't export any history with it, just a clean tree | 17:01 |
vxnick | in effect working the same as if I were to add the files myself | 17:01 |
clemente | vxnick: that's what I was thinking... Can you reproduce the problem if you add the files yourself? Maybe the problem has nothing to do with Subversion | 17:03 |
vxnick | bear with me and i'll give it a go now... | 17:03 |
clemente | I myself am getting a crash with „bzr status“ and I'm trying to figure out the cause | 17:06 |
clemente | File "/Werkstatt/bzr.dev/bzrlib/tsort.py", line 415, in __init__ | 17:06 |
clemente | parents = self._graph.pop(branch_tip) | 17:06 |
clemente | KeyError: 'pop(): dictionary is empty' | 17:06 |
vxnick | clemente: same issue when adding the files myself | 17:06 |
Peng | Uh-ohs. | 17:06 |
Peng | clemente: Up-to-date bzr.dev? | 17:07 |
vxnick | just to clarify - should I be "bzr init" the directory when I add the files, along with bzr add and bzr commit, then merge into trunk? | 17:07 |
clemente | Peng: almost; one moment... | 17:07 |
clemente | Peng: yes | 17:08 |
Peng | clemente: If you can find a way to reproduce this, file a bug. | 17:09 |
Peng | (Well, search for existing bugs first...) | 17:09 |
clemente | What's the efficient way of finding out more about an error? Inserting „pdb.set_trace()“? Turning on some debug mode...? Running tests? | 17:09 |
Peng | clemente: You can run it so it'll automatically drop into pdb, but I forget how. | 17:10 |
vila | BZR_PDB=1 ? | 17:11 |
clemente | vila: yes | 17:11 |
clemente | vxnick: I suppose that init+add+commit should work... (Do they work without problems for you?) The big problems could be with the merge | 17:12 |
clemente | vxnick: if you get errors, maybe you can debug them. BZR_PDB=1 :-) | 17:13 |
vxnick | clemente: those work fine for me usually, so I think you're right in that it's the merge. | 17:13 |
vxnick | I presume you can merge something into an empty directory, or do you need to have the same (older) files there beforehand? | 17:14 |
vxnick | I could pull the files in, but then the parent dir for the trunk would be the upstream, which doesn't make much sense to me | 17:14 |
vxnick | the main problem, to clarify, seems to be that "bzr commit" doesn't commit the merge to the repository - bzr status shows the new files, and I can see them in the physical directory of the trunk too | 17:16 |
vxnick | "commit" just reckons there's no changes, thus nothing to commit | 17:16 |
clemente | I thought „commit“ sends the changes to your branch, whereas „push“ sends them to the remote repository. I would try „push“ and „merge“ instead of „commit“ | 17:18 |
vxnick | I've got a remote repository setup with a checkout on my local machine | 17:18 |
vxnick | commit can work locally and/or remotely I believe | 17:19 |
vxnick | if you are using a checkout | 17:19 |
vxnick | I believe push/pull work for a branch | 17:19 |
vxnick | but I'm quite new to bazaar, so might be wrong :) | 17:19 |
clemente | vxnick: yes, right. I'm also new and in fact I still haven't succeeded in doing a „merge“... | 17:22 |
vxnick | I've managed to merge branches locally, but this is the first time I've tried merging into a checkout | 17:22 |
vxnick | I have prevously "bzr init"-ed a directory and then branched it, then merged from the branch back into the "trunk" | 17:23 |
vxnick | if you branch something, you have to "pull" the changes from the original dir into the new branch - I think that merges as well automatically | 17:23 |
vxnick | if you want to merge the differences from the new branch to the old, you use merge | 17:24 |
vxnick | if that makes sense | 17:24 |
clemente | vxnick: I don't know. I would try looking at where the error message comes from in the code, in case you get an error | 17:29 |
vxnick | yeah I might try that, but I'm not familiar with Python | 17:29 |
vxnick | and I have to do some weird stuff to get the trace from it | 17:29 |
vxnick | other than that, it's just the generic bzr error messages such as "working copy out of date" and so on | 17:30 |
clemente | Then look if the syntax you're using is the correct one | 17:31 |
clemente | You may also find a way to reproduce it to see if some other person sees the problem | 17:31 |
vxnick | yeah fair enough | 17:33 |
clemente | Don't worry... I have just gotten your error :-) | 17:33 |
clemente | bzr: ERROR: Reserved revision-id {null:} | 17:33 |
clemente | After doing a merge of a patch I created with „send“ | 17:33 |
Leonidas | What is the command to modify the working tree to look like some older revision? | 17:34 |
Leonidas | I've tried both checkout and update, but none of them lets me specify the desired revision | 17:35 |
vxnick | bzr revert? | 17:35 |
vxnick | or uncomitt | 17:35 |
vxnick | uncommit* | 17:35 |
vxnick | see what "bzr help revert" or "bzr help uncommit" show - that should help :) | 17:36 |
Leonidas | vxnick: bzr revert seems to be what I needed. Right. uncommit whould be too much, I don't want to loose the tip/HEAD | 17:36 |
vxnick | ah right | 17:36 |
Leonidas | btw, that is the name of the most recent revision? hg calls it tip, git HEAD and bzr? -1? | 17:36 |
LarstiQ | Leonidas: -1 is a shorthand for that, yes | 17:37 |
vxnick | HEAD I think | 17:37 |
LarstiQ | vxnick: not in a tool addressable way | 17:38 |
LarstiQ | Leonidas: but if you want to talk terminology in discussions, tip or head would be understood | 17:38 |
Leonidas | LarstiQ: ok, thanks. | 17:39 |
clemente | vxnick: I got also „D-“ on update | 17:46 |
vxnick | is that with a checkout? | 17:47 |
clemente | Problem is: rev_id=null here: | 17:48 |
clemente | /Werkstatt/bzr.dev/bzrlib/mutabletree.py(52)tree_write_locked() | 17:48 |
clemente | -> return unbound(self, *args, **kwargs) | 17:48 |
clemente | > /Werkstatt/bzr.dev/bzrlib/workingtree_4.py(1103)set_parent_trees() | 17:48 |
clemente | -> _mod_revision.check_not_reserved_id(rev_id) | 17:48 |
clemente | But I don't understand more | 17:48 |
clemente | vxnick: it was with init+merge+update | 17:48 |
clemente | where the merge came from a patch file (created with „bzr send“) | 17:49 |
clemente | It happens also with latest bzr | 17:49 |
vxnick | have you tried just a normal merge? | 17:50 |
clemente | You mean, from a repository instead of from a file? (No) | 17:50 |
vxnick | try making a dir "bzr init dir" then branching it to "dir2" - add a couple of files with some random text in "dir" and then cd to dir2 and "bzr pull". Make some changes in "dir2", cd to "dir" and "bzr merge ../dir2" | 17:53 |
clemente | vxnick: I suppose you had to do „commit“ at least once after the „init“ | 17:58 |
clemente | otherwise you stay at revision 0 | 17:59 |
vxnick | yeah, sorry | 17:59 |
vxnick | and bzr add before the commit | 17:59 |
clemente | (and this may be the problem for rev_id to be null...) | 17:59 |
clemente | vxnick: ok, it stays there without errors under „pending merges“ | 18:04 |
clemente | (I did a „commit“ also on dir2) | 18:04 |
vxnick | do a commit and it should work | 18:04 |
clemente | Ok, so no problems in update/commit/status | 18:05 |
clemente | My first successful merge, thanks for the help :-) | 18:05 |
clemente | Now I try with a patch file instead of with a repo | 18:05 |
clemente | Ok, I only get the error message if the merge occurs before revision 1 | 18:10 |
clemente | This fails on „update“: mkdir bzr00004; cd bzr00004; bzr init; bzr merge /n/resprueba/mezcla ; bzr update | 18:11 |
clemente | But this works: mkdir bzr00005; cd bzr00005; bzr init; echo a>b; bzr add b; bzr commit -m "be"; bzr merge /n/resprueba/mezcla ; bzr update | 18:11 |
clemente | So the problem is doing the „merge“ before you have done a „commit“ on your new repository | 18:12 |
clemente | I suppose it's a bug | 18:12 |
=== mw|out is now known as mw | ||
asabil | clemente: how do you want to merge in an empty repo ? | 18:16 |
asabil | They have no parent in common | 18:16 |
clemente | Is it not allowed? „merge with empty“ == „branch“? | 18:17 |
asabil | clemente: try to pull | 18:18 |
clemente | Yes, „pull“ works | 18:19 |
clemente | I think then that instead of failing, bzr should show an error message which says that (you can't merge in an empty repository) | 18:20 |
Peng | s/repository/branch/ | 18:22 |
clemente | But I thought that after „init“ you got really an empty repository, that is, a first parent (a root parent) | 18:23 |
Peng | s/repository/branch/ | 18:37 |
clemente | Thanks. Does „repository“ mean „collection of branches“? | 18:38 |
Peng | No. | 18:38 |
Peng | A repository is a big bag of revision data. | 18:38 |
clemente | A branch too | 18:38 |
Peng | No. | 18:39 |
clemente | Or a branch is the place, and the repository the content? | 18:39 |
Peng | On disk, a branch is simply the ID of the most recent revision in that branch. That's used to figure everything else out from the revisions in the repository. | 18:39 |
clemente | I submitted bug 242175, about improving the error message | 18:43 |
ubottu | Launchpad bug 242175 in bzr "Better error message when merging into empty branch" [Undecided,New] https://launchpad.net/bugs/242175 | 18:43 |
clemente | Peng: where can I find precise definitions of those concepts? (applied to Bazaar) | 18:44 |
Peng | I dunno; user guide? | 18:44 |
clemente | (Peng: yes, it was) | 19:30 |
clemente | What's that about a „smart server“? Does it work? According to [1] it's still under design phase. [1]: http://bazaar-vcs.org/Specs/SmartServer | 19:30 |
Peng | clemente: Yes the smart server works. | 19:30 |
clemente | Ok, I'll try it | 19:32 |
Peng | clemente: It still doesn't have optimal performance, but they're working on it, and it's perfectly usable today. | 19:32 |
Peng | clemente: FWIW, I always use the smart server. | 19:33 |
Peng | clemente: If you're using a knit repo (upgrade!), it's a huge performance improvement. Packs are fast enough that it's not really, but it probably would be if you're moving a lot of data, and anyway, it's cooler and getting better all the time. | 19:34 |
clemente | Can you also use on a machine where you can't modify apache.conf? | 19:35 |
Peng | clemente: bzr+http? Um, can you modify .htaccess? | 19:36 |
clemente | Yes | 19:37 |
Peng | clemente: You can use it then | 19:43 |
Peng | clemente: You can install bzr? | 19:43 |
clemente | Yes | 19:45 |
clemente | Is that in the manual? | 19:46 |
Peng | Is what? | 19:46 |
clemente | The explanations for setting up the smart server with .htaccess | 19:47 |
clemente | I only find that for ssh, inetd, or a dedicated server | 19:47 |
* Peng shrugs. | 19:48 | |
Peng | When I set it up, I used the documentation. | 19:48 |
clemente | I will read more documentation then | 19:49 |
Peng | Hmmm. | 19:49 |
Peng | You're right. | 19:49 |
Peng | That section doesn't mention it. | 19:49 |
Peng | The source tree has doc/en/user-guide/http_smart_server.txt | 19:50 |
Peng | Not sure where to find it in the html | 19:50 |
Peng | clemente: Oh, it's at the bottom, in an appendix. http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#serving-bazaar-with-fastcgi | 19:51 |
Peng | clemente: (You don't need to use FastCGI.) | 19:51 |
clemente | Ok, thanks for all help, I will continue learning bzr; bye | 20:16 |
bkor | jelmer: "It generates inefficient code - it generates proxy classes that " <-- ends abruptly | 20:33 |
awilkins | jelmer: pong | 20:35 |
jelmer | bkor: whoops, thanks | 20:45 |
jelmer | awilkins: The C extensions branch is there! | 20:46 |
jelmer | and passing all tests on Linux | 20:46 |
Peng | Hmm. I was able to push bzr-svn into a rich-root-pack repo, but not upgrade the subtree repo to it. | 20:47 |
jelmer | Peng: Hmm, that sounds like a bug | 20:49 |
Peng | jelmer: (I meant bzr-svn's repo itself, not an svn repo managed by bzr-svn.) | 20:50 |
Peng | I was also left with a "repository.backup". | 20:50 |
Peng | Probably the same thing that happened to you a couple days ago. | 20:50 |
Peng | Bzr flatly refused to do it since, of course, rich-root-pack doesn't support subtrees. | 20:50 |
jelmer | Ideally, bzr would only refuse to upgrade from subtree to rich-root-pack if there was actually a revision in that repository that used subtrees | 20:51 |
Peng | Yep. | 20:52 |
Peng | And it already has the proper machinery, since push can do it. | 20:52 |
jelmer | Push probably breaks if you try to push a revision with a subtree into rich-root-pack | 20:53 |
Peng | That's what I mean. Push probably handles it exactly how upgrade should. | 20:53 |
edcrypt | some of this info seems outdated: http://live.gnome.org/DistributedSCM | 20:54 |
jelmer | Peng: I mean that it breaks badly :-) | 20:55 |
Peng | Oh. | 20:55 |
bkor | edcrypt: please update | 21:01 |
edcrypt | bkor: will try to research some references... | 21:02 |
mwhudson_ | morning | 21:10 |
Jc2k | evening mwhudson_ :) | 21:10 |
mwhudson_ | Jc2k: did you see that you can run loggerhead trunk now? :) | 21:11 |
Jc2k | mwhudson_: did you try search on my copy of loggerhead ;) | 21:11 |
Jc2k | you should be able to give it a spin on gtk+ now :) | 21:11 |
mwhudson_ | neat :) | 21:13 |
Jc2k | so yeah, im running a different branch now :) | 21:13 |
mwhudson_ | heh, ok | 21:14 |
Jc2k | its very had not to blog about the loggerhead foo :) | 21:16 |
Jc2k | mwhudson_: i can link loggerhead into apache more now? | 21:18 |
Jc2k | rather than having it running in a screen session :P | 21:18 |
Peng | Heh, I have it running in screen too. | 21:19 |
Jc2k | i guess i just need mod_wsgi | 21:22 |
mwhudson_ | Jc2k: i guess so, yes | 21:27 |
mwhudson_ | Jc2k: feel free to blog | 21:27 |
mwhudson_ | i don't really know if there are any real actual advantages to mod_wsgi | 21:27 |
Jc2k | mwhudson_: waiting a few days for some bueno polish :) | 21:27 |
mwhudson_ | oh, ok :) | 21:27 |
mwhudson_ | beuno: i see you noticed your ~loggerhead-team membership :) | 21:28 |
=== edcrypt is now known as edcrypt_ | ||
lifeless | moin | 22:05 |
thumper | morning | 22:05 |
=== eMxyzptlk[away] is now known as eMxyzptlk | ||
mkanat | mwhudson_: Trying loggerhead trunk, getting a traceback with start-loggerhead.py: http://pastebin.mozilla.org/465681 | 22:09 |
mwhudson_ | mkanat: you use auto_folder ? | 22:10 |
mkanat | mwhudson_: I do. | 22:10 |
mwhudson_ | i bet i never even checked that | 22:10 |
mwhudson_ | mkanat: have you seen the new serve-branches.py script? | 22:10 |
mkanat | mwhudson_: I have, but I don't want to serve everything in the path. Is that avoidable? | 22:10 |
mwhudson_ | not without programming i guess | 22:11 |
=== mwhudson_ is now known as mwhudson | ||
* mwhudson hmms | 22:13 | |
mwhudson | actually it's url_prefix that's broken i think | 22:14 |
mkanat | Oh, hmm. | 22:14 |
mkanat | Yeah, I need that unless I can just tell it "strip off the /var/www/html/everythingsolved.com/bzr/ from every path for the URL". | 22:15 |
lifeless | jelmer: any comment on the speed issue it has? | 22:16 |
mwhudson | truth be told, i've never understood the purpose of many of the things you can put in loggerhead.conf :) | 22:16 |
mkanat | mwhudson: Heh. :-) | 22:16 |
mwhudson | mkanat: i just pushed r166 of trunk, try that? | 22:17 |
lifeless | Jc2k: which branch chewed all your ram while indexing? | 22:17 |
mwhudson | morning lifeless | 22:17 |
mkanat | mwhudson: Yes, that seems to be running! :-) | 22:18 |
mwhudson | mkanat: woo! | 22:19 |
Jc2k | lifeless: i'm not entirely sure if it was bzr index or not, but things got a little rough on the box for trunk of... gcompris, gimp-help, gimp and guadec-web | 22:19 |
mwhudson | mkanat: i hope this one doesn't chew all your ram... | 22:19 |
Jc2k | i aborted them.. | 22:19 |
mkanat | Well, the first plus I can see is that my log isn't full of 404s. :-) | 22:19 |
lifeless | Jc2k: oh it likely was :) | 22:19 |
lifeless | Jc2k: can you edit index.py | 22:19 |
Jc2k | gimp.. i dont know, i was just worried it would break so i abored it anyway | 22:19 |
lifeless | look for group_size = 2500 | 22:19 |
Jc2k | lifeless: i can, but i'd prefer not to whilst it was still running | 22:20 |
Jc2k | its indexing nautilus | 22:20 |
lifeless | drop that down and repeat until it stays happy | 22:20 |
lifeless | I'd like to figure out some way to auto tune | 22:20 |
jelmer | lifeless: 'morning | 22:20 |
jelmer | lifeless: speed issue? | 22:20 |
lifeless | Jc2k: uhm, its fine to do as its running :P | 22:20 |
mkanat | mwhudson: I'm getting a few tracebacks in my debug.log, though not sure what the problem is (I just have spiders that are crawling the site, apparently). Want to see the traceback? | 22:20 |
lifeless | jelmer: in the backlog; it was very slow at indexing just the commits via bzr-svn | 22:21 |
mwhudson | mkanat: yeah, let's have a look | 22:21 |
mkanat | mwhudson: http://pastebin.mozilla.org/465683 | 22:21 |
lifeless | Jc2k: the .py -> .pyc will be recompiled the next time python loads it | 22:21 |
mwhudson | mkanat: so i think that happens when someone browses to blah/blah/inventory?file_id=file_id_of_non_directory | 22:22 |
mwhudson | mkanat: it's possible we're generating a bogus link somewhere | 22:23 |
mkanat | mwhudson: Ah. And that link shows up in the UI? (This is the Googlebot doing this, apparently.) | 22:23 |
mwhudson | mkanat: it seems unlikely that googlebot just made such a url up, indeed :) | 22:23 |
mkanat | mwhudson: And WOW, this version is WAY better on the resources! | 22:23 |
mkanat | I can't even pick it out in top's list. | 22:24 |
mwhudson | mkanat: :) | 22:24 |
lifeless | jelmer: the easiest way to show you is for you to try it yourself :P | 22:24 |
mwhudson | mkanat: i can't see anywhere where a bogus link like that would be generated | 22:26 |
mkanat | mwhudson: I'll watch my apache log for referrers. | 22:26 |
mwhudson | mkanat: it's possible that we fixed this bug without noticing at some point and googlebot is remembering it | 22:26 |
mkanat | mwhudson: Yeah, that is possible. | 22:26 |
mwhudson | mkanat: one idea | 22:27 |
mkanat | Ah, I couldn't pick it out in top because it wasn't there--I had Ctrl-C'ed and I forgot that I was running ./start-loggerhead.py -f. :-) | 22:27 |
mwhudson | mkanat: do you have an 'updir' link in the root of the branch (in the files view)? | 22:27 |
mkanat | mwhudson: I'll look. | 22:28 |
mwhudson | that's something i could imagine going wrong | 22:28 |
mwhudson | (though it doesn't in my tests) | 22:28 |
mwhudson | mkanat: this branch should still be a lot better than the old version on resources | 22:28 |
mwhudson | mkanat: please let us know how it does over time | 22:28 |
mkanat | mwhudson: Yeah, it is so far. | 22:29 |
mkanat | mwhudson: Yeah, I will. | 22:29 |
mkanat | mwhudson: Oh, problem. | 22:29 |
awilkins | jelmer: So the 0.4 branch now has the cext branch merged in it? | 22:29 |
mkanat | mwhudson: The URLs look like http://localhost:8080//bzr.everythingsolved.com//vci/stable/revision/88 | 22:29 |
jelmer | lifeless: I'm confused - bzr-search appears to rely on weaves which bzr-svn doesn't have | 22:30 |
mkanat | mwhudson: Which is the path to the local server, not the right URL. | 22:30 |
mwhudson | mkanat: oh bugrit | 22:30 |
mwhudson | mkanat: i thought i'd fixed that | 22:30 |
jelmer | awilkins: yep | 22:30 |
lifeless | jelmer: it only indexes commit messages on SvnBranch objects today | 22:30 |
mwhudson | ugh, indeed, totally not | 22:30 |
jelmer | lifeless: ah, ok | 22:31 |
lifeless | jelmer: yesterday I did the various bits of machinery needed to teach it where to store an index for a svn branch, and disabled the stuff it couldn't use | 22:31 |
awilkins | jelmer: Will distutils build them? | 22:31 |
jelmer | awilkins: yes | 22:31 |
lifeless | jelmer: if you change commits_only = True, to False on line 161 of index.py you can see it fail to access weaves :) | 22:32 |
mwhudson | mkanat: fixing... | 22:32 |
mkanat | mwhudson: Okay. :-) | 22:33 |
=== eMxyzptlk is now known as eMxyzptlk[away] | ||
mwhudson | mkanat: can you try r167 from https://code.edge.launchpad.net/~mwhudson/loggerhead/config-vhost ? | 22:33 |
mkanat | mwhudson: I can just pull from that into my current? | 22:34 |
mwhudson | yes | 22:34 |
mkanat | mwhudson: Wow, bzr does not like that URL. | 22:34 |
mwhudson | mm | 22:35 |
mwhudson | it should redirect to the branch | 22:35 |
mwhudson | lp:~mwhudson/loggerhead/config-vhost should work better | 22:35 |
mkanat | mwhudson: http://pastebin.mozilla.org/465687 | 22:35 |
Jc2k | Sorry, you don't have permission to access this page. | 22:35 |
Jc2k | You are logged in as John Carr. | 22:35 |
mwhudson | oh | 22:36 |
thumper | ??? | 22:36 |
mwhudson | mkanat: try again | 22:36 |
mkanat | bzr: ERROR: Not a branch: "http://bazaar.launchpad.net/~mwhudson/loggerhead/config-vhost/". | 22:36 |
thumper | ah | 22:37 |
thumper | mkanat: there will be a pause | 22:37 |
thumper | mkanat: while the http system realises that it is no longer private | 22:37 |
mkanat | Okay. | 22:37 |
thumper | mkanat: give it a minute or so | 22:37 |
mkanat | bzr: ERROR: Cannot lock LockDir(http://bazaar.launchpad.net/%7Eloggerhead-team/loggerhead/trunk/.bzr/branch/lock): Transport operation not possible: http does not support mkdir() | 22:38 |
mwhudson | what command line are you running?? | 22:39 |
mkanat | mwhudson: bzr pull https://code.edge.launchpad.net/~mwhudson/loggerhead/config-vhost | 22:39 |
mwhudson | (do you have a checkout? in which case 'bzr unbind') | 22:39 |
mkanat | Oh, right, I should unbind. | 22:39 |
mkanat | mwhudson: Thanks. :-) | 22:39 |
mkanat | mwhudson: I had it bound manually so that I could just type "bzr up" when I wanted to. | 22:39 |
mwhudson | uh | 22:40 |
mwhudson | 'bzr pull' should work | 22:40 |
mwhudson | mkanat: oh, this branch will require paste.deploy, btw | 22:40 |
mkanat | mwhudson: Okay, that version dies: http://pastebin.mozilla.org/465688 | 22:40 |
mwhudson | PrefixMiddleware(app, translate_forwarded_server=True, prefix=webpath) | 22:41 |
mwhudson | i.e. add the 'app' argument | 22:41 |
mwhudson | (sorry) | 22:41 |
mkanat | Okay. | 22:41 |
Jc2k | lifeless: i halved it, whatever that will lead to.. | 22:41 |
mkanat | mwhudson: Now my frontpage URLs are slightly wrong: http://bzr.everythingsolved.comvci/stable | 22:42 |
mkanat | mwhudson: And if I fix that in the URL bar, the internal URLs look like: http://bzr.everythingsolved.comhttp%3a//bzr.everythingsolved.com/vci/stable/revision/88 | 22:43 |
mwhudson | so basically, that didn't work at all | 22:43 |
mwhudson | mkanat: what's the server.webpath in your loggerhead.conf ? | 22:43 |
mkanat | server.webpath = 'http://bzr.everythingsolved.com/' | 22:44 |
mkanat | I just added that slash. | 22:44 |
mkanat | So it was server.webpath = 'http://bzr.everythingsolved.com' | 22:44 |
mwhudson | mkanat: so if you remove that | 22:44 |
mwhudson | and the "translate_forwarded_server=True" in start-loggerhead.py | 22:44 |
mwhudson | then it should Just Work | 22:44 |
LarstiQ | (TM) | 22:44 |
mkanat | mwhudson: It originally didn't have the /. | 22:45 |
mkanat | mwhudson: Adding the slash makes no difference, it seems. | 22:45 |
mwhudson | mkanat: but that worked with the old loggerhead, right? | 22:45 |
mkanat | mwhudson: Yeah, slashless worked with the old loggerhead. | 22:46 |
mwhudson | so two things (1) do what i said above, that should get you working (2) i have some work to do to get perfect compatibility with old loggerhead.conf files | 22:46 |
mkanat | mwhudson: Oh, remove server.webpath entirely? | 22:47 |
mwhudson | mkanat: yes | 22:47 |
mkanat | Okay, here we go! Let's try. :-) | 22:47 |
mkanat | Okay, with both of them gone, the front page works. | 22:48 |
mkanat | mwhudson: But the internal URLs look like: http://localhost:8080/vci/stable/revision/88 | 22:49 |
mwhudson | mkanat: you are running behind apache using mod_proxy ? | 22:50 |
mkanat | mwhudson: Yeah, I think so. | 22:50 |
mwhudson | oddness | 22:51 |
mkanat | mwhudson: Here's my Apache conf: http://pastebin.mozilla.org/465704 | 22:52 |
mwhudson | mkanat: that's not mod_proxy, that's mod_rewrite :) | 22:52 |
mkanat | mwhudson: Well, [P] is using mod_proxy, no? | 22:52 |
mwhudson | hm, maybe | 22:53 |
mwhudson | anyway, what paste.deploy is doing is relying on HTTP_X_FORWARDED_SERVER | 22:53 |
* mkanat read the Apache docs just now and it says that [P] does indeed use mod_proxy. | 22:54 | |
mwhudson | yeah, me too | 22:54 |
mkanat | mwhudson: Anywhere I could put some debug code to spit out that env var? | 22:55 |
mwhudson | def (environ, start_response, orig=app): | 22:56 |
mwhudson | print environ | 22:56 |
mwhudson | return orig(environ, start_response) | 22:56 |
mkanat | mwhudson: In what file? | 22:56 |
mwhudson | in start-loggerhead.py, just before the serve call | 22:56 |
mkanat | Okay. | 22:57 |
mkanat | mwhudson: In the try block? | 22:57 |
mwhudson | mkanat: yeah, should work | 22:58 |
mwhudson | (doesn't matter much, basically) | 22:58 |
mkanat | def (environ, start_response, orig=app): | 22:58 |
mkanat | ^ | 22:58 |
mkanat | SyntaxError: invalid synta | 22:58 |
mwhudson | erm | 22:59 |
mwhudson | do you know python well? | 22:59 |
mkanat | I know it, but I don't know these frameworks well enough. | 22:59 |
mkanat | And I don't know it well enough to know what an empty def call does. | 22:59 |
mwhudson | i typed three lines for that function | 23:00 |
mwhudson | mkanat: http://pastebin.ubuntu.com/22225/ | 23:00 |
mwhudson | mkanat: phone now, brb | 23:00 |
mkanat | mwhudson: Okay. | 23:00 |
mkanat | (Ahh, it was nameless originally.) | 23:00 |
mwhudson | mkanat: oops :) | 23:01 |
mkanat | 'HTTP_X_FORWARDED_SERVER': 'bzr.everythingsolved.com' | 23:01 |
mwhudson | mkanat: sorry about this, thanks for being patient | 23:01 |
mkanat | mwhudson: Hey, no problem. | 23:01 |
mwhudson | mkanat: and then still funky urls? | 23:02 |
mkanat | mwhudson: Yep. | 23:02 |
mwhudson | grr | 23:02 |
mkanat | Not *as* funky as they used to be. | 23:02 |
mkanat | I mean, at least these could theoretically be right, if I was somehow on the server itself. :-) | 23:02 |
mkanat | You can see it here if you want: http://bzr.everythingsolved.com/vci/stable/changes | 23:03 |
mkanat | HTTP_X_FORWARDED_HOST is also bzr.everythingsolved.com. | 23:04 |
mwhudson | mkanat: i wonder what version of paste deploy you have? | 23:05 |
mkanat | rpm -q python-paste | 23:05 |
mkanat | python-paste-1.6-1.el5 | 23:05 |
mkanat | rpm -q python-paste-deploy | 23:06 |
mkanat | python-paste-deploy-1.3.1-1.el5 | 23:06 |
mwhudson | mm, pretty close to the same as me | 23:06 |
mkanat | Hmm, welcome to "our product has no changelog". | 23:08 |
mkanat | Ahh, yes it does. | 23:09 |
mkanat | It was just cleverly hidden. | 23:09 |
mkanat | mwhudson: What version of paste-deploy do you have? | 23:09 |
mwhudson | 1.3.1-2 (ubuntu hardy here) | 23:10 |
mkanat | Yeah. | 23:10 |
mkanat | Okay, so yeah, the same. | 23:10 |
mkanat | mwhudson: And paste 1.6? | 23:11 |
mwhudson | 1.6-2 | 23:12 |
Peng | What's this about url_prefix being broken? | 23:13 |
mwhudson | Peng: if you're not using loggerhead.conf. it shouldn't affect you | 23:13 |
Peng | Indeed I am not. | 23:14 |
Peng | I'm using serve-branches.py with the Paste Deploy prefix thingy. :) | 23:15 |
Peng | (If that's what url_prefix does..) | 23:15 |
mwhudson | Peng: it's not | 23:16 |
Peng | Heh, okay. | 23:16 |
Peng | I'll shut up then. :) | 23:16 |
mwhudson | mkanat: try this patch: http://pastebin.ubuntu.com/22228/ | 23:16 |
mwhudson | i think i was getting too complicated :) | 23:17 |
poolie_ | good morning | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!