| spiv | GaryvdM: and I can reproduce it. Thanks! | 00:01 |
|---|---|---|
| GaryvdM | Yhea | 00:01 |
| GaryvdM | spiv: I just tested with 1.10 and I was able to reproduce. | 00:02 |
| spiv | My current hypothesis is that it's to do with which texts are stored as deltas and which are stored as fulltexts in the source repo, which tends to vary in each repo depending on the order things get inserted, etc. | 00:04 |
| GaryvdM | I better go to bed as it 2am. | 00:06 |
| GaryvdM | Bye | 00:06 |
| lifeless | spiv: you might like to look at the analysis I did on a bug a month or so back, the one with (IIRC) casper, or apt, or something | 00:07 |
| lifeless | spiv: where there were references to ghosts and $stuff | 00:07 |
| lifeless | spiv: I wrote a tool to rewrite things, but you'd want to id root cause etc | 00:07 |
| spiv | lifeless: thanks, I'll take a look | 00:08 |
| spiv | GaryvdM: good night | 00:08 |
| markh | GaryvdM: I like the throbber :) | 00:15 |
| markh | GaryvdM: I'm also very happy to hear you aren't opposed to threads used carefully :) | 00:16 |
| poolie | hello markh | 00:17 |
| markh | hi poolie - good trip? | 00:17 |
| markh | you back now, right? | 00:17 |
| poolie | yes, great | 00:17 |
| poolie | and yes, i just got home | 00:17 |
| poolie | well, a couple of hours ago | 00:17 |
| markh | excellent | 00:18 |
| markh | heh - well - I'm sure you aren't quite feeling excellent yet! | 00:18 |
| poolie | i got an upgrade on the way back, so i'm reasonably ok | 00:18 |
| poolie | will probably fade later | 00:18 |
| spiv | poolie: welcome back | 00:20 |
| poolie | hello spiv | 00:20 |
| poolie | how was your week? | 00:21 |
| spiv | Pretty good. Quiet :) | 00:23 |
| GaryvdM | Hi markh | 00:25 |
| poolie | what did you get up to in bzr? | 00:25 |
| GaryvdM | Re: threads - If we want responsiveness when looking at remote branch - we are going to need threads. | 00:26 |
| markh | GaryvdM: I understand that well - Lukas is vehemently opposed though | 00:27 |
| markh | ie, gone so far as to say he would *refuse* to accept patches that had threads | 00:27 |
| poolie | for bzr-eclipse? | 00:28 |
| GaryvdM | Yhea - I read that. | 00:28 |
| markh | qbzr | 00:28 |
| markh | poolie: for background, I had a patch that used a single background thread to talk to bzr, while the main thread was doing *only* GUI work. | 00:28 |
| markh | that kept the gui alive even while bzr blocked | 00:28 |
| markh | there were never 2 threads hitting bzrlib | 00:29 |
| GaryvdM | markh: I think we should merge threadless into trunk now. What do you think? | 00:30 |
| markh | this was only for things like building the list of changed files - not actually doing the final commit or whatever the "real" operation is | 00:30 |
| GaryvdM | Readonly commands | 00:31 |
| markh | GaryvdM: I agree for sure. I'm trying hard not to step on Lukas's toes though - possibly a little too hard | 00:31 |
| markh | its a shame he hasn't commented on anything he might like on the branch | 00:31 |
| markh | I haven't heard from him since I posted the threadless version | 00:32 |
| GaryvdM | ok - Really going home now. | 00:36 |
| spiv | Huh, the problem that garyvdm's hitting appears to be that the initial push is stacked, but subsequent pushes aren't. | 00:43 |
| spiv | Hence the subsequent pushes are understandably upset about missing data. | 00:43 |
| spiv | I guess this is a bad interaction with the way Launchpad tries to make the client auto-enable stacking. | 00:44 |
| spiv | I think I have a fix for GaryvdM's bug for pushing to a new stacked LP branch. | 01:30 |
| spiv | Yes, it worked. BzrDir cloning-format logic is such a mess. | 01:32 |
| mwhudson | oh my yes | 01:33 |
| spiv | mwhudson: this has probably affected LP devs a lot, although upgrading the local format to a stacking-capable format works around it I think. | 01:33 |
| mwhudson | the cloning format mess has certainly affected _me_ a lot! | 01:34 |
| spiv | mwhudson: :) | 01:34 |
| * spiv sees what the test suite thinks of his patch | 01:34 | |
| poolie | spiv, can we catch up on the phone when it's convenient? | 01:46 |
| spiv | poolie: sure. How about now, or otherwise just after lunch? | 01:47 |
| spiv | Now might be better if you're likely to fade. | 01:47 |
| === mark1 is now known as markh | ||
| poolie | i'm just going to have lunch now, maybe after that? | 01:50 |
| spiv | Sure. | 01:51 |
| mwhudson | spiv: btw, i reported https://bugs.edge.launchpad.net/bzr/+bug/291046 a while ago | 01:54 |
| ubottu | Launchpad bug 291046 in bzr "pushing branch6/packs5 to location with default stacking policy creates broken branch" [Undecided,New] | 01:54 |
| mwhudson | spiv: i think that might be what you've just rediscovered? | 01:54 |
| mwhudson | unless https://bugs.edge.launchpad.net/bzr/+bug/259275 has just reappeared somehow | 01:55 |
| ubottu | Launchpad bug 259275 in bzr "pushing a non-stacking format into a non-repo bzrdir with a default stacking policy creates broken branch" [Critical,Fix released] | 01:55 |
| Jerub | Given a bzr repo that's at revision 82, but I want to do a compile of the source as at revision 77. How do I revert the code back to that revision? | 01:55 |
| mwhudson | Jerub: bzr revert -r 77 will do it, i think | 01:58 |
| Jerub | mwhudson: thanks! that worked. | 01:58 |
| * spiv wonders why running "./bzr --no-plugins selftest" just failed with plugins/svn in the traceback... | 02:10 | |
| jml | :) | 02:16 |
| lifeless | spiv: https://bugs.launchpad.net/bugs/307988 - did you end up writing up stuff re central mail? [btw I'm on leave :)] | 02:28 |
| ubottu | Launchpad bug 307988 in bzr-email "Central repository email?" [Undecided,Invalid] | 02:28 |
| spiv | mwhudson: those sound suspiciously similar. | 02:35 |
| spiv | lifeless: not yet, but I intend to | 02:35 |
| lifeless | spiv: :) if you could reply to that bug then, I would appreciate that. | 02:40 |
| igc | hi all | 03:30 |
| poolie | hello ian | 03:38 |
| igc | poolie: when your formats email said "the following needn't block merges", were you implying bb:tweak by that? | 03:49 |
| poolie | yes | 04:09 |
| poolie | or rather, that they were optional but suggested changes | 04:09 |
| stewart | hi! i'm getting (after recent bzr pull of bzr) bzr: ERROR: The API for "<module 'bzrlib' from '/home/stewart/lib/python/bzrlib/__init__.pyc'>" is not compatible with "(1, 9, 0)". It supports versions "(1, 11, 0)" to "(1, 11, 0)". | 04:57 |
| stewart | anybody get any ideas? | 04:57 |
| spiv | stewart: It's probably due to a plugin asking for a the 1.9 bzrlib API | 04:59 |
| spiv | bzr-svn is a common culprit | 04:59 |
| stewart | spiv: ahh.. ok, thanks! | 04:59 |
| stewart | any ideas on Revision {stewart@flamingspork.com-20081121160607-n6gdlt013spuo54r} not present in "table.h-20080625052902-61bbthtf22shh0p6-550". | 05:00 |
| stewart | https://code.launchpad.net/~stewart-flamingspork/drizzle/nofrm-dev2 | 05:00 |
| spiv | Probably a stacking-related bug :( | 05:01 |
| stewart | any way to push without stacking? | 05:02 |
| spiv | 1.10 is better at catching those errors sooner, and I'm about to send a patch that looks like it might fix the main cause. | 05:02 |
| stewart | that'd be good... | 05:03 |
| stewart | so probably a problem tha lp is using 1.7.1 | 05:03 |
| spiv | Not to Launchpad, afaik. But if you upgrade your source repository and branch with "bzr upgrade --1.6" and push a new branch that should avoid the bug, I think. | 05:03 |
| spiv | (Or you could re-use the existing LP branch by using a tool like lftp to recursively delete sftp://bazaar.launchpad.net/~stewart-flamingspork/drizzle/nofrm-dev2/.bzr and re-push to that with --use-existing-dir) | 05:04 |
| spiv | stewart: actually, the offending bugs are entirely client-side :( | 05:08 |
| stewart | fun | 05:08 |
| === Mario__ is now known as pygi | ||
| jml | how do you show a shelf with the new builtin stuff? | 06:50 |
| vila | hi all | 07:05 |
| jml | hello. | 07:06 |
| lifeless | jml: unshelve --dry-run | 07:51 |
| jml | lifeless: if there are conflicts, it doesn't show you anything useful. | 07:51 |
| jml | in those cases, it would be useful to see the contents of the shelf, rather than the merge results. | 07:51 |
| jml | (which are reverted in case of a dry run) | 07:52 |
| lifeless | jml: bug a file | 07:52 |
| jml | ok. | 07:53 |
| === AfC is now known as AfC|run | ||
| * igc dinner | 08:50 | |
| jml | in a lightweight checkout, is there a way to remove all files that aren't in version control? | 08:57 |
| RAOF | jml: bzr clean-tree doesn't work there? | 08:58 |
| jml | RAOF: it does something different | 08:58 |
| jml | RAOF: I don't want to delete all of the files that show up in "unknown" | 08:59 |
| jml | RAOF: I want to delete all my *~ and *.pyc files and the like | 08:59 |
| jml | RAOF: essentially, remake my tree from the branch. | 09:01 |
| RAOF | Aaah. Because you've added those files to .bzrignore. Of course! | 09:02 |
| fullermd | bzr ls --ignored | xargs rm? | 09:03 |
| === AfC|run is now known as AfC | ||
| spiv | jml: bzr clean-tree --ignored ? | 09:07 |
| jml | spiv: thanks. | 09:08 |
| * spiv -> food | 09:08 | |
| pygi | hi mvo | 09:31 |
| asabil | hi all | 10:40 |
| asabil | can bzr replay, replay commits from unrelated branches (standalone branches) ? | 10:41 |
| === jszakmeister is now known as jszakmeister|awa | ||
| === mark1 is now known as markh | ||
| LarstiQ | asabil: I'd think so | 13:22 |
| asabil | LarstiQ: it didn't seem to work, so I gave up | 13:22 |
| LarstiQ | ok | 13:22 |
| awilkins | is "--fixes" supposed to be used for bzr.dev when comitting? | 13:28 |
| Odd_Bloke | awilkins: I don't think there's a policy either way. | 13:55 |
| awilkins | Odd_Bloke: I'm not sure how it works, it seems to require a tag | 13:56 |
| awilkins | Does Bundle Buggy support PGP/MIME? | 13:58 |
| awilkins | (or not care at all?) | 13:59 |
| Odd_Bloke | awilkins: You'll want --fixes lp:123456 I think. | 14:00 |
| awilkins | Neato | 14:02 |
| Odd_Bloke | Bugtrackers are namespaced. | 14:03 |
| awilkins | Oh crap, used the wrong mail address | 14:08 |
| vila | jam: ping | 14:08 |
| jam | vila: is it urgent? | 14:08 |
| jam | I'm around, but having breakfast, etc. | 14:08 |
| vila | just ping me back when you have a couple of quarters available | 14:09 |
| vila | jam: but if you can update your mysql branches meanwhile.. feel free :) | 14:10 |
| Peng_ | awilkins: BB can process such mail, but I dunno if it validates it. | 14:10 |
| Peng_ | At least, I think. | 14:11 |
| jam | vila: I'll at least pull in mysql-6.0 which tends to include most of the other stuff | 14:11 |
| vila | should be enough, I'd like your help to understand which revisions are taken into account on a particular content conflict but you may well already have all the needed revisions | 14:12 |
| awilkins | Peng_: That's rather what I expected - just as long as PGP/MIME doesn't choke it, I can use it | 14:22 |
| Peng_ | awilkins: Lots of people on the list use PGP.. If "This is a multi-part message in MIME format." means it's PGP/MIME, then it definitely works. | 14:26 |
| === maxb is now known as Guest20139 | ||
| === Guest20139 is now known as maxb | ||
| sven_ | hi! i got a stack trace when running bzr push: http://pastebin.com/m32a4c395 . Then i ran bzr push again and it worked | 17:03 |
| sven_ | is this a known bug? | 17:03 |
| beuno | sven_, it has been reported, yes. An autopacking error | 17:04 |
| beuno | waht version of bzr are you using? | 17:04 |
| sven_ | beuno, ok, thanks. i'm using bzr 1.10. added version and plugins to paste: http://pastebin.com/d3d4e0032 | 17:05 |
| sven_ | beuno, do you know any details? is it safe to just ignore the failure and push again? | 17:06 |
| beuno | sven_, well, I'm actually not sure if it shouldn't be fixed by now... | 17:07 |
| beuno | sven_, can you file a bug anyway? | 17:07 |
| beuno | it should be safe though, if the second push was succesful | 17:07 |
| fullermd | Pushing again should always be safe, at least. | 17:07 |
| sven_ | beuno, ok, will file a bug | 17:07 |
| sven_ | fullermd, beuno, ok, that's reassuring :-) | 17:07 |
| Kobaz | http://pastebin.ca/1286019 | 17:12 |
| Kobaz | why does bzr need dbus? | 17:13 |
| LeoNerd | <guess>HAL integration for monitoring network events?</guess> | 17:13 |
| beuno | Kobaz, my guess is that you have the plugin installed? | 17:14 |
| Kobaz | oh | 17:17 |
| Kobaz | maybe | 17:17 |
| Kobaz | ii bzr-dbus 0.1~bzr36-3 D-Bus announcements plugin for Bazaar | 17:17 |
| Kobaz | mmm | 17:17 |
| === jrydberg_ is now known as jrydberg | ||
| vila | Kobaz: 'xhost +localhost' under your regular login maybe ? | 17:20 |
| Kobaz | well i dont need dbus stuff, so i guess i'll just axe it out | 17:22 |
| Kobaz | is there a way to get bzr to save bzr+http passwords? | 17:25 |
| Kobaz | bzr pull | 17:26 |
| Kobaz | Using saved parent location: bzr+https://markm@bzr.local/bzr/myproject/usrLocalLibrary/trunk/ | 17:26 |
| Kobaz | HTTPS markm@bzr.local, Realm: 'Bazaar Repository' password: | 17:26 |
| AmanicA | Kobaz: maybe this helps: http://doc.bazaar-vcs.org/bzr.dev/en/user-reference/bzr_man.html#id24 | 17:44 |
| Kobaz | k | 17:46 |
| === mark1 is now known as markh | ||
| vila | Kobaz: Amanica was right, authentication.conf should address your problem, did you find it ? | 18:04 |
| vila | err, did you *solve* your problem ? | 18:05 |
| NfNitLoop | Hrmm. Can `bzr rebase` cause problems between repositories? Are there any gotchas I should be aware of? | 18:16 |
| NfNitLoop | I just rebased my changes against someone else's tree and noticed that the rebased revisions have the same IDs as the original ones. | 18:16 |
| NfNitLoop | but, don't they have different parents? | 18:16 |
| NfNitLoop | wouldn't that cause issues? *confused* | 18:17 |
| fullermd | The rebased revs shouldn't have the same ID's... | 18:19 |
| NfNitLoop | Hrmm, I may have run bzr log from the wrong dir. :p | 18:23 |
| NfNitLoop | can't reproduce that. I *thought* that sounded fishy. | 18:23 |
| lifeless | Kobaz: thats fixed in bzr-dbus upstream, just the debian package hasn't caught up | 18:26 |
| bialix | AmanicA: hi | 18:28 |
| Kobaz | k | 18:34 |
| Kobaz | vila: i just removed bzr-dbus... that fixed it... heh | 18:34 |
| vila | Kobaz: I kind of doubt that provides passwords but.. If you say so :) | 18:36 |
| AmanicA | bialix: hi чувак | 18:37 |
| AmanicA | LOL @ vila | 18:38 |
| Kobaz | oh | 18:39 |
| Kobaz | vila: oooh | 18:39 |
| Kobaz | the autheitcation stuff | 18:39 |
| Kobaz | i'm all confuzzeled | 18:41 |
| Kobaz | okay now i'm good, well i was confuzzeleded | 18:41 |
| Kobaz | so where it says [myprojects] | 18:44 |
| Kobaz | do i really use [myprojects], in the authentication.conf... or do i name it the project namer | 18:44 |
| Kobaz | never mind | 18:46 |
| Kobaz | scrolling down helps... | 18:46 |
| Kobaz | i wrote out an authentication.conf... but bzr doesn't even open it | 18:48 |
| Kobaz | oh | 18:59 |
| Kobaz | does bzr diff really have to obey the file locks set by bzr commit? | 18:59 |
| Kobaz | it's a read-only operation | 19:00 |
| Kobaz | with subversion i always go around diffing everything while i'm in the middle of a commit | 19:00 |
| beuno | Kobaz, how about bzr commit --show-diff? | 19:01 |
| lifeless | Kobaz: its a bug on windows only, we will fix it but yes, it does need to obey the file lock | 19:01 |
| Kobaz | lifeless: i'm on linux | 19:02 |
| lifeless | Kobaz: oh, hmm, ah yes. | 19:02 |
| Kobaz | beuno: hmm, that's good, but i would still want to be able to view individual file diffs... i like working with smaller units | 19:02 |
| lifeless | Kobaz: it will be locked out there in that case as well :( | 19:02 |
| lifeless | Kobaz: same cause, same fix when we get it done | 19:03 |
| lifeless | you might like gcommit | 19:03 |
| Kobaz | lifeless: ah, so the fix will allow diffing on commit-in-progress files? | 19:03 |
| LarstiQ | (or qcommit!) | 19:03 |
| lifeless | Kobaz: roughly yes ;) | 19:04 |
| Kobaz | yay | 19:04 |
| Kobaz | so, why would it need to obey the file lock? | 19:04 |
| Peng_ | What would the fix be? | 19:04 |
| Kobaz | when you're in the editor for bzr commit, nothing is changing, the diff is a read-only operation, linux has no restrictions on reading files that are "in use" | 19:05 |
| Kobaz | windows on the other hand is a pita with file locking... not sure how you would fix it there | 19:06 |
| Peng_ | While you're in the editor, the repo is in the middle of a commit.. | 19:07 |
| Peng_ | Even if nothing is happening *right then*, there's still a half-completed commit sitting around. | 19:07 |
| Kobaz | but at that time... the repo is in a consistant state | 19:08 |
| Kobaz | since nothing has been written of the commit yet | 19:08 |
| LarstiQ | I'm not sure how true that actually is. | 19:09 |
| Kobaz | the entities in question should only be locked for reading when the actual commit is taking place (ie: done with the editor, the files are being added) | 19:10 |
| Kobaz | it makes sense to lock them for writing, but not for reading | 19:10 |
| Kobaz | theoretically, i see no harm in allowing reading operations during the commit message editing... but then again i don't know all the internals of bzr... but what's your objection to not having a read-lock | 19:12 |
| fullermd | Write locks as a rule lock out readers :p | 19:12 |
| Kobaz | it depends on the system | 19:12 |
| fullermd | Every locking formalism that comes readily to mind? | 19:13 |
| Peng_ | Hmm, ISTM while the editor is open, the upload file has been created, but it's empty. | 19:13 |
| Kobaz | like for database transactions. you will have several different types of locks... you will have read commited (read/write lock), read uncommited (write lock), and others | 19:13 |
| fullermd | Writing changes things. Changes tend to lead to inconsistencies. Reading during inconsistencies is Bad(tm). | 19:13 |
| Peng_ | But then, I was just testing with a tiny test repo. | 19:13 |
| Peng_ | It's probably not inconsistent at that point. | 19:13 |
| Kobaz | Peng_: exactly | 19:13 |
| Peng_ | At least in pack repos. | 19:13 |
| Peng_ | Kobaz: I imagine that's why lifeless said it *could* be fixed. ;) | 19:14 |
| Kobaz | yeah | 19:14 |
| Peng_ | I've never paid attention; bzr asks for the commit message before going through all the mechanics? | 19:14 |
| Peng_ | hg asks afterwards. | 19:14 |
| fullermd | I'm not saying it _good_ to lock out diff while you're sitting in the editor, nor do I think it's likely to be the eternal state. But it's not just as simple as "change X" to fix. There are likely a lot of implications and assumptions and side effects to unwind. | 19:14 |
| Kobaz | as far as i know, it's only inconsistant during the upload/write procedure after editing the message | 19:14 |
| Kobaz | fullermd: oh of course, but i figured i would bring it up | 19:15 |
| fullermd | Peng_: No, the mechanics are run through. You can prove this to yourself by starting a commit, then editing the file while sitting in the log editor. | 19:16 |
| lifeless | Kobaz: its the dirstate file that is the thing | 19:16 |
| lifeless | not the repo | 19:16 |
| Peng_ | fullermd: Oh, good point. I've done that, in fact. | 19:16 |
| lifeless | the repo is multimaster safe, branches are single writer N readers, trees are [currently] single-writer-no-readers | N-readers | 19:17 |
| Peng_ | I just tested it by committing a bunch of large files. When it was a teensy test file, the upload file was empty because of buffering. | 19:17 |
| Kobaz | anyways... next topic | 19:18 |
| Kobaz | lemme finish my paste | 19:18 |
| Peng_ | lifeless: So what's the fix, then? | 19:18 |
| fullermd | Yum. Is it mint-flavored? | 19:18 |
| lifeless | Peng_: write to a newly named dirstate each time, with a atomic-update pointer to the active dirstate, and a RCU style late-delete of old dirstates | 19:19 |
| Kobaz | http://pastebin.ca/1286109 | 19:19 |
| Kobaz | i'm trying to use authentication.conf | 19:19 |
| Peng_ | lifeless: Ah. | 19:20 |
| Kobaz | so umm, is there any config options i need to turn on in bazaar.conf, in order to use authentications.conf ? | 19:21 |
| Kobaz | this is 1.10 | 19:21 |
| lifeless | Kobaz: its on by default, but I've never used it | 19:22 |
| Kobaz | as you can see from the pastebin | 19:23 |
| Kobaz | bzr isn't even touching authentication.conf | 19:23 |
| lifeless | Kobaz: what url are you pulling from though; you've helpfully edited that out :) | 19:23 |
| Kobaz | i'm pulling from bzr+https | 19:24 |
| lifeless | try just https: | 19:26 |
| lifeless | also whats the error that occurs | 19:27 |
| Kobaz | the error is that the login failed | 19:29 |
| Kobaz | since it's not specifying the password that's stored in authentication.conf (since authentication.conf is not read) | 19:29 |
| Kobaz | bzr: ERROR: Generic bzr smart protocol error: Invalid http response for https://bzr.local/bzr/myProject/usrLocalLibrary/trunk/.bzr/smart: Unable to handle http code 401: Authorization Required | 19:30 |
| lifeless | vila: ^ is this a smart oversight? | 19:31 |
| Kobaz | using bzr+https:// and https:// have the same problem... authentication.conf is never read | 19:31 |
| Kobaz | lemme try the example in the docs | 19:31 |
| vila | lifeless: shouldn't be | 19:32 |
| Peng_ | Kobaz: What about nosmart+https? | 19:32 |
| vila | Kobaz: try -Dhttp -Dauth | 19:32 |
| Kobaz | stat64("/home/root/.bazaar/authentication.conf", {st_mode=S_IFREG|0644, st_size=82, ...}) = 0 | 19:32 |
| Kobaz | okay... if i use ftp:// it will read authentication.conf | 19:32 |
| vila | Kobaz: Oh, try adding user in the url | 19:33 |
| Kobaz | strace bzr pull ftp://localhost | 19:33 |
| vila | ftp and http are different we provide a default user for ftp not for http | 19:34 |
| Kobaz | i dont get any debugging for -Dhttp -Dauth | 19:34 |
| vila | in the .bzr.log file | 19:34 |
| Kobaz | ah | 19:34 |
| LarstiQ | vila: it would be nice to prompt for credentials, what needs to happen for that? | 19:38 |
| Kobaz | http://pastebin.ca/1286123 | 19:39 |
| vila | vila.cucles.free() :) | 19:39 |
| vila | vila.cycles.free() :) | 19:39 |
| vila | I hate typos in jokes | 19:39 |
| lifeless | vila: your spellchecker needs more timeslices | 19:39 |
| vila | Kobaz: Ok, add your user in the url | 19:40 |
| Kobaz | k | 19:40 |
| vila | I don't know why I keep thinking this bug is fixed.... | 19:40 |
| vila | jelmer would kill me for saying that :-) | 19:41 |
| jfroy|work-sl | vila: this sounds like the stuff I was working on a few months ago | 19:41 |
| jfroy|work-sl | I haven't had the time to sit down and figure out a good way to handle this. | 19:41 |
| vila | jfroy|work-sl: Hey ! | 19:41 |
| Kobaz | http://pastebin.ca/1286128 | 19:41 |
| jfroy|work-sl | But vanilla authentication.conf certain works for me, even though it's gross to leave a password in cleartext. | 19:42 |
| Kobaz | authentication.conf doesn't get loaded when you use https or bzr+https | 19:42 |
| Kobaz | if i manually edit branch/branch.conf | 19:43 |
| Kobaz | and put in the url with my username in it | 19:43 |
| mwhudson | good morning | 19:43 |
| vila | Kobaz: it used : 0.958 Using authentication section: 'myProject' | 19:43 |
| Kobaz | it will promot for a password | 19:43 |
| Kobaz | 2.716 Using authentication section: 'myProject' | 19:43 |
| Kobaz | yes, but | 19:43 |
| Kobaz | look at this strace | 19:44 |
| vila | Kobaz: That's a bug, authentication.conf should be usable to provides the user | 19:44 |
| Kobaz | oh | 19:44 |
| Kobaz | wait | 19:44 |
| vila | the password is wrong | 19:44 |
| Kobaz | if i provide the username, it loads authentication.conf | 19:44 |
| Kobaz | if i don't provide the username, it wont | 19:45 |
| Kobaz | i see | 19:45 |
| vila | or at least that's what the server said (AFAICS), by the way, change it as soon as we finish discussing, basic really is not secure, | 19:45 |
| Kobaz | ? | 19:46 |
| Kobaz | what's wrong with basic auth | 19:46 |
| Kobaz | over https | 19:46 |
| vila | nothing | 19:46 |
| vila | posting pastebin with the http headers on the other hand... | 19:47 |
| Kobaz | it's all local | 19:47 |
| Kobaz | and i have a little scrubber script | 19:47 |
| Kobaz | oh | 19:48 |
| Kobaz | yeah | 19:48 |
| Kobaz | the source password is def123 | 19:48 |
| === elmo_ is now known as elmo | ||
| LarstiQ | Kobaz: what's wrong with basic is that if you have the header, you have the password. | 19:56 |
| evarlast | so run it over https :p | 19:58 |
| LarstiQ | evarlast: and then paste the headers on pastebin? :P | 19:59 |
| LarstiQ | Digest isn't that hard to set up. | 19:59 |
| Kobaz | yeah | 20:02 |
| Kobaz | doing that now | 20:02 |
| Kobaz | heh | 20:02 |
| Kobaz | i dont have any real passwords in there anyway | 20:03 |
| === Mario__ is now known as pygi | ||
| === asac_ is now known as asac | ||
| jelmer | beuno, ping | 20:43 |
| beuno | jelmer, pong | 20:45 |
| jelmer | beuno, bug 305995 is blocking adoption by alioth and it seems like an easy bug | 20:46 |
| ubottu | Launchpad bug 305995 in loggerhead "includes internal port numbers in links" [Undecided,New] https://launchpad.net/bugs/305995 | 20:46 |
| jelmer | beuno, can you perhaps give me a hint as to how to do so? | 20:46 |
| * beuno looks | 20:47 | |
| mwhudson | oh that | 20:47 |
| mwhudson | it sounds like a configuration problem tbh | 20:47 |
| beuno | jelmer, that's using start-loggerhead? | 20:48 |
| beuno | mwhudson, hi! | 20:48 |
| mwhudson | jelmer: please stop using start-loggerhead | 20:48 |
| jelmer | Hi mwhudson :-) | 20:48 |
| jelmer | beuno, yes | 20:48 |
| beuno | we should talk about trying to get a day or two a month to work on LH | 20:48 |
| mwhudson | jelmer: in the interests of actually solving your problem though | 20:48 |
| mwhudson | jelmer: can you pastebin your loggerhead.conf ? | 20:48 |
| beuno | jelmer, and you're using that because it lets you tweak stuff that serve-branches doesn't? | 20:49 |
| beuno | mwhudson, we should make sure we can provide a config for serve-branches, and kill off start/stop-lh | 20:50 |
| beuno | oh, and, of course, fix that memory problem... | 20:50 |
| jelmer | mwhudson, please remove start-loggerhead then.. | 20:50 |
| * beuno pokes thumper | 20:50 | |
| lifeless | beuno: I thought you had a day a week :) | 20:50 |
| jelmer | mwhudson, start-loggerhead is the only thing that has an init-script in Debian (but I think we've had this discussion before :-) | 20:50 |
| mwhudson | yes | 20:50 |
| thumper | beuno: yes? | 20:51 |
| beuno | lifeless, *sigh* | 20:51 |
| lifeless | :> | 20:51 |
| mwhudson | jelmer: do you want to run from the loggerhead package on alioth? | 20:52 |
| mwhudson | jelmer: or would you be ok running trunk? | 20:52 |
| mwhudson | jelmer: at any rate, i really don't think you want auto_publish_folders, and would be much happier with the serve-branches approach | 20:53 |
| jelmer | beuno, config is at http://pastebin.ubuntu.com/85753/ (not created by me but by Lolando) | 20:53 |
| mwhudson | (i mean, how many links saying "unstable" are there on http://bzr.debian.org/loggerhead/ ?) | 20:53 |
| jelmer | mwhudson, Well, it should be some package, but since I'm the Debian packager I can upload a new upstream snapshot if necessary | 20:53 |
| beuno | jelmer, I'm going to try and release a new version in this week or the next | 20:54 |
| mwhudson | jelmer: so remind me, why is serve-branches unsuitable? lack of a config file? | 20:54 |
| beuno | jelmer, and that's not passing through apache? | 20:54 |
| jelmer | mwhudson, Lack of config file and init file | 20:54 |
| beuno | or it is, and LH is creating the :8080 links? | 20:54 |
| mwhudson | jelmer: so there's an init file in trunk | 20:55 |
| mwhudson | (for serve-branches) | 20:55 |
| jelmer | mwhudson, yes, but it's not using the standard functions for Debian/Ubuntu and it requires users to pick either serve-branches or start-loggerhead | 20:56 |
| mwhudson | lack of a config file is fixable, presumably, let's fricking fix it | 20:56 |
| jelmer | mwhudson, we can hack our way around the current situation | 20:56 |
| jelmer | mwhudson, I'm just lobbying for a single binary that does loggerhead and uses a config file | 20:56 |
| jelmer | rather than having two binaries, both of which can do some things but can neither do both | 20:57 |
| jelmer | s/do both/do everything/ | 20:57 |
| mwhudson | jelmer: it seems unlikely then that loggerhead can by itself supply an init file that would be acceptable by debian? | 20:57 |
| jelmer | mwhudson: Not sure I follow.. | 20:58 |
| mwhudson | "<jelmer> mwhudson, yes, but it's not using the standard functions for Debian/Ubunt" | 20:59 |
| mwhudson | jelmer: perhaps i didn't understand this bit? ^^ | 20:59 |
| jelmer | Loggerhead can include an init script that is appropriate, it just doesn't atm :-) | 20:59 |
| jelmer | The infrastructure provided by start-loggerhead matches a bit better what we need there | 21:00 |
| jelmer | since start-loggerhead can write pid files, etc | 21:00 |
| mwhudson | oh right daemonization | 21:00 |
| mwhudson | hm, links like http://bzr.debian.org/loggerhead//bzr.debian.org/current/changes don't look quite right :) | 21:03 |
| mwhudson | oh man, i always forget how much i hate config file formats :) | 21:06 |
| rkistner | i'm creating a website using python/django, hosting content similar to a wiki site | 21:09 |
| rkistner | and i need version control for the content | 21:09 |
| rkistner | would it be possible to integrate bazaar into the website for version control? | 21:09 |
| rkistner | similar to how google code uses svn for the wiki pages | 21:10 |
| Odd_Bloke | rkistner: Yes, bzr has a good Python API. | 21:10 |
| rkistner | how much work would it require? | 21:10 |
| rkistner | or is that a bad question? | 21:11 |
| rkistner | i'm completely new to bazaar | 21:11 |
| Odd_Bloke | rkistner: Well, it's hard to express work. :p | 21:11 |
| Odd_Bloke | It wouldn't be that hard. | 21:11 |
| poolie | jam, hi | 21:11 |
| rkistner | ok, thanks | 21:12 |
| Odd_Bloke | rkistner: A handful of API calls. | 21:12 |
| rkistner | and i won't need to run any additional processes, apart from the main python process? | 21:12 |
| Odd_Bloke | rkistner: Nope. | 21:13 |
| rkistner | ok, cool | 21:13 |
| rkistner | bazaar seems like a good solution then | 21:13 |
| mwhudson | hmm | 21:18 |
| jelmer | mwhudson, :-) | 21:18 |
| mwhudson | jelmer: what's going on here? | 21:18 |
| mwhudson | mwh@grond:serve-branches-config-file$ ./start-loggerhead | 21:18 |
| mwhudson | Traceback (most recent call last): | 21:18 |
| mwhudson | File "./start-loggerhead", line 26, in <module> | 21:18 |
| mwhudson | from bzrlib.util.configobj import ConfigObj | 21:18 |
| mwhudson | ImportError: cannot import name ConfigObj | 21:18 |
| Peng_ | Oops, it should be "from bzrlib.util.configobj.configobj import ConfigObj", I think. | 21:19 |
| mwhudson | yeah | 21:19 |
| jelmer | Yeah, looks like it :-/ | 21:19 |
| Peng_ | Um, the same typo is elsewhere too. | 21:20 |
| LarstiQ | to be honest, it's a bit daft. | 21:21 |
| * Peng_ wonders why his Loggerhead installation isn't broken because of this. | 21:21 | |
| poolie | kfogel: hey | 21:21 |
| kfogel | poolie: hey, about to paste, one sec | 21:21 |
| Peng_ | So anyway, who volunteered to fix it? | 21:21 |
| Peng_ | :P | 21:21 |
| poolie | btw i was re-reading 'producing open source' on my trip, coincidentally | 21:21 |
| poolie | it's good | 21:21 |
| LarstiQ | Peng_: didn't you? *duck* | 21:21 |
| Peng_ | LarstiQ: Heh. | 21:22 |
| Peng_ | LarstiQ: It takes more time for someone with commit access to merge a fix from me than it does to fix it. :P | 21:22 |
| kfogel | poolie: http://paste.lisp.org/display/72205 | 21:23 |
| kfogel | poolie: (and thanks, re the book!) | 21:23 |
| jelmer | mwhudson, I've pushed a fix to http://people.samba.org/bzr/jelmer/loggerhead/trunk. Should I file a merge request? | 21:24 |
| mwhudson | Peng_: you don't use start-loggerhead i guess | 21:24 |
| Peng_ | mwhudson: serve-branches won't wind up importing loggerhead/apps/config.py? | 21:24 |
| lifeless | FWIW | 21:24 |
| poolie | kfogel: a good way to make sure this wouldn't get lost is to make sure there are clear bugs for each of them, and tag them eg 'emacs-adoption' | 21:25 |
| mwhudson | jelmer: ok, though i guess it's the same as the change i have here :) | 21:25 |
| poolie | hey lifeless | 21:25 |
| lifeless | I'd rather serve-branches and a wrapper o r something | 21:25 |
| jelmer | mwhudson, Ah, never mind then :-) | 21:25 |
| lifeless | *I* loath loggerhead.conf with a passion, having deployed it on squid-cache.org | 21:25 |
| * Peng_ made the change too. :D | 21:25 | |
| kfogel | poolie: well, each has a bug ticket already. I can tag with emacs-adoption now | 21:25 |
| jelmer | lifeless, if it's simple, I don't see the problem | 21:25 |
| jelmer | lifeless, The alternative is loads of config options in /etc/default/loggerhead | 21:25 |
| poolie | and then subscribe to the bugs about the tags interface, this gets recursive :_) | 21:26 |
| jelmer | lifeless, finding branches automagically is a must in any case | 21:26 |
| LarstiQ | not having deployed loggerhead yet, I wonder what's so bad about the config file? | 21:26 |
| lifeless | jelmer: what sort of defaults are you talking about? | 21:26 |
| lifeless | LarstiQ: its broken, heinously and deeply so | 21:27 |
| LarstiQ | lifeless: I'm naturally inclined to believe you, but I'm still curious as to _why_ | 21:27 |
| jelmer | lifeless, bzr root path, url prefix, port, hostname, log file, title, log rotation, ... | 21:27 |
| mwhudson | jelmer: committed, thanks | 21:28 |
| jelmer | lifless: trunk directory, user dirs, reload setting, | 21:28 |
| DBO | I received a patch file from one of my contributors, but when I try to bzr merge it (it is a bzr patch file) i get this | 21:28 |
| DBO | bzr: ERROR: Revision is not compatible with KnitPackRepository('file:///home/jason/do/future2/.bzr/repository/') | 21:28 |
| mwhudson | well user-dirs/trunk directory is very much a setting for people who know they need it | 21:29 |
| lifeless | so | 21:29 |
| DBO | can anyone help? | 21:29 |
| lifeless | I've proposed before, 'bzr serve --http' -> fires up a loggerhead instance; that should be serve-branches, then you can have a demon if you want. | 21:29 |
| kfogel | poolie: all tagged with "emacs-adoption" now | 21:29 |
| lifeless | What I'd like really is: | 21:29 |
| lifeless | - no separate loggerhead.conf; branches and configs-for-roots are configured in the standard bzr config | 21:30 |
| lifeless | - a sane-default for 'gimme a web ui' | 21:30 |
| jelmer | As I've mentioned before, I don't care what we end up with, as long as there's a single correct way to configure and start a loggerhead daemon. | 21:30 |
| lifeless | - a sane-dfault for 'I'm running a production server environment' | 21:30 |
| lifeless | *I* strongly suspect these two things are different | 21:31 |
| poolie | kfogel: btw, vila is working on log, both performance and functionality | 21:31 |
| lifeless | hi poolie | 21:31 |
| jelmer | lifeless, so, serve-branches seems to be "just give me sane a web frontend" without requiring configuration | 21:32 |
| mwhudson | that's the idea, basically | 21:33 |
| === sdboyer-laptop_ is now known as sdboyer|sprint | ||
| jelmer | and start-loggerhead/stop-loggerhead the "run loggerhead as a service and let me tweak its behaviour however I want" | 21:33 |
| mwhudson | that's a nice idea, but it's not really a reflection on reality | 21:33 |
| jelmer | What are the plans for start-loggerhead/stop-loggerhead then? | 21:35 |
| kfogel | poolie: specifically those issues are on his plate? | 21:35 |
| mwhudson | jelmer: i would like to kill start-loggerhead with a vengeance | 21:36 |
| LarstiQ | lifeless: moving loggerhead.conf into bazaar.conf/branch.conf would go a long way to make it less heinously broken? | 21:37 |
| mwhudson | jelmer: then _add_ something new that fits the "service" requirement | 21:37 |
| jelmer | mwhudson, ok | 21:38 |
| poolie | kfogel: no, not those issues specifically, more the log requests from mysql | 21:38 |
| poolie | but there is some overlap | 21:38 |
| poolie | i haven't caught up with him since i left for UDS | 21:38 |
| lifeless | LarstiQ: No, removing the things like nested-nested-config-nested would | 21:39 |
| LarstiQ | lifeless: aha, thank you | 21:39 |
| lifeless | brb | 21:40 |
| poolie | kfogel: so as far as how they get proritised | 21:43 |
| poolie | s/they/bugs/ | 21:43 |
| poolie | we're prioritizing finishing network and repository speed improvements, in what's called the brisbane-core projcet | 21:44 |
| poolie | plus dealing with bugs that are particularly biting people, | 21:44 |
| poolie | and just generally keeping things rolling along with reviews and releases | 21:45 |
| kfogel | poolie: ok. I don't really have development time to offer, unfortunately, so the most I can do is tell the Emacs team "Here is where the bugs are, and here is what they're tagged with." | 21:50 |
| poolie | i'll pass them on to vila | 21:51 |
| poolie | actually that sounds a bit lame | 21:52 |
| poolie | it's not just down to him, but i will tell him you marked them | 21:52 |
| poolie | i would guess bug 130588 should be straightforward | 21:52 |
| ubottu | Launchpad bug 130588 in bzr "show commandline in diff output" [Wishlist,Confirmed] https://launchpad.net/bugs/130588 | 21:52 |
| poolie | and probably also bug 203394 | 21:53 |
| ubottu | Launchpad bug 203394 in nspluginwrapper "npviewer.bin crashed with SIGSEGV in g_str_hash()" [Medium,Invalid] https://launchpad.net/bugs/203394 | 21:53 |
| poolie | i mean 306394 | 21:53 |
| jelmer | mwhudson, We'll just go with serve-branches for now then, until something better comes around. Thanks for commenting! | 21:53 |
| mwhudson | jelmer: cool, i hope something better can come soon! | 21:54 |
| === jaavaagu1u is now known as jaavaaguru | ||
| spiv | Good morning. | 22:03 |
| enigma | Hm...I'm using the head of bzr-svn 0.5 and it seems *much* slower during the "determining changes" phase. | 22:08 |
| jelmer | hi enigma | 22:09 |
| enigma | So much so that the remote SVN repo is closing the HTTPS connection on my client. | 22:09 |
| enigma | jelmer: Hi | 22:09 |
| jelmer | enigma, during push, pull branch, ? | 22:09 |
| enigma | branch | 22:09 |
| enigma | I noticed that downloading the history is *very* fast now. :-D | 22:10 |
| enigma | (There are 8549 versions total in the remote svn repo) | 22:10 |
| jelmer | enigma, the first time it will be slower since it wouldn't have the cache yet that bzr-svn 0.4 has already built up | 22:12 |
| enigma | OK, so the revision graph is saved in the svn-cache? | 22:13 |
| enigma | Hm...it looks like I might be getting subversion timeouts on top of it all. | 22:14 |
| enigma | We're using collabnet and they've been very flaky. | 22:14 |
| jelmer | enigma, it would definitely be a bug if 0.5 was slower than 0.4 | 22:15 |
| enigma | OK, thanks for letting me know. | 22:15 |
| jelmer | enigma, but please make sure you've removed the cache in ~/.bazaar/svn-cache and that you're cloning into a fresh bzr repository when testing if that is the case | 22:15 |
| enigma | Let me ask around my team and see if anyone else is having collabnet issues. | 22:15 |
| enigma | jelmer: No problem. I did remove the cache and I'm cloning into a fresh repo. | 22:16 |
| kfogel | poolie: agree those two emacs-adoption bugs are likely trivial to fix. I may have a look too. | 22:16 |
| jfroy|work-sl | jelmer: any particularly nasty upgrade issues you might be aware of with 0.5, particularly if less-than-release-candidate versions have been used? | 22:26 |
| jelmer | jfroy|work-sl, not any that I'm aware of (yet) | 22:26 |
| jfroy|work-sl | (BTW, so far, 0.4.16 with the modified prefix has been rock solid) | 22:26 |
| enigma | jelmer: Just tried a branch using 0.4.16 and it's taking forever too. I'm pretty sure it's the remote SVN server in this case. | 22:29 |
| jelmer | jfroy|work-sl, Unless there's a particular reason, I would recommend just testing 0.5 on a temporary repository, not on the actual production branch yet | 22:29 |
| jfroy|work-sl | jelmer: I don't plan to switch anyone yet until I've tested it further, yeah. | 22:31 |
| Peng_ | jelmer: I might need to RTFM, but what does bzr-svn 0.5 do if you have a repo using the old mapping format? Keep using it? | 22:35 |
| jelmer | Peng_, Yes, you need to read the file UPGRADING :-) Basically, it will use the old mapping for revisions that are already there and use the new mapping (unless the "mapping = v3" configuration setting is present) for new revisions. | 22:36 |
| Peng_ | jelmer: Even for new revisions in the same repo? Huh. | 22:37 |
| jelmer | Peng, it will use the old mapping for revisions that were roundtripped from bzr using that old mapping | 22:38 |
| Peng_ | Okay. | 22:39 |
| Peng_ | Hmm, what happens if you're in a shared repo with revisions in the old mapping format, and do a "bzr branch svn://..."? Will it use the new format? | 22:41 |
| jelmer | peng_: yes | 22:41 |
| Peng_ | Okay. :) Thanks for the information. :) | 22:42 |
| Peng_ | Ooh, bzr-svn 0.5 bombed. | 22:52 |
| jelmer | Peng_, please file a bug :-) | 22:52 |
| Kobaz | bzr add * | 22:54 |
| Kobaz | ... | 22:54 |
| Kobaz | ignored 1 file(s). | 22:54 |
| Kobaz | it should tell you which files were ignored | 22:54 |
| mwhudson | Kobaz: not if there are 4000 of them | 22:55 |
| Kobaz | hmm | 22:55 |
| Kobaz | but what if i wanted to know | 22:56 |
| mwhudson | i think 'bzr ignored' will show you them | 22:56 |
| Kobaz | ah okay | 22:56 |
| Peng_ | jelmer: Before filing a bug, here's the .bzr.log bit: http://paste.pocoo.org/show/DKInz7G6HBc20ifJONCe/ | 22:57 |
| Peng_ | jelmer: Filed https://bugs.edge.launchpad.net/bzr-svn/+bug/308353 | 23:05 |
| ubottu | Launchpad bug 308353 in bzr-svn "[0.5] KeyError in old_inventory when branching Lighttpd 1.4" [Undecided,New] | 23:05 |
| jelmer | Peng_, thanks, reproduced here | 23:10 |
| Peng_ | :D | 23:10 |
| jelmer | a large number of bug reports against bzr is with company svn servers, making it hard to debug the actual issue | 23:13 |
| jelmer | s/against bzr/against bzr-svn/ | 23:13 |
| enigma | jelmer: Is there anyway to have bzr-svn dump out all the metadata without any of the log messages and such? I would be happy to send that your well to help with debugging. | 23:14 |
| enigma | jelmer: Think I found a bug around tagging. | 23:39 |
| enigma | jelmer: Make a brand new svn repo. | 23:39 |
| enigma | jelmer: Create a "trunk/gui" directory and commit it. | 23:39 |
| enigma | jelmer: Then do "bzr branch test-repo/trunk/gui gui" | 23:40 |
| enigma | Then go into "gui" and do: bzr tag "test-tag-01" | 23:40 |
| enigma | Then bzr push -v ../test-repo/trunk/gui | 23:40 |
| enigma | bzr: ERROR: exceptions.AssertionError | 23:41 |
| enigma | File "/home/enigma/.bazaar/plugins/svn/tags.py", line 53, in set_tag | 23:41 |
| enigma | assert isinstance(path, str) | 23:41 |
| jelmer | Ah, thanks | 23:41 |
| jelmer | enigma, It should be refusing to set any tags in that situation | 23:42 |
| enigma | Oh, OK. | 23:42 |
| jelmer | since it wouldn't know where to set tags if you're pushing to "trunk/gui" instead of "trunk" | 23:42 |
| jelmer | in the case of "trunk" it would be creating "tags/test-tag-01" | 23:42 |
| poolie | spiv, can you please before this afternoon make some measures for insert_revision_stream performance? | 23:42 |
| poolie | or point me to them | 23:42 |
| spiv | poolie: sure | 23:43 |
| Peng_ | jelmer: Could my bug be related to bug 304134? | 23:43 |
| ubottu | Launchpad bug 304134 in bzr-svn "KeyError when updating lightweight bzr-svn checkout" [Medium,Triaged] https://launchpad.net/bugs/304134 | 23:43 |
| poolie | like for pushing one more rev, and pushing many revs | 23:44 |
| Peng_ | Well, maybe not. | 23:44 |
| * Peng_ shrugs. | 23:44 | |
| enigma | jelmer: I just got another assertion error when trying to pull down a approx 380 rev from an 8000 rev repo | 23:46 |
| enigma | File "/home/neumann/.bazaar/plugins/svn/revmeta.py", line 225, in get_fileprops | 23:46 |
| enigma | lm = lm.get_direct_lhs_parent_revmeta() | 23:46 |
| enigma | File "/home/neumann/.bazaar/plugins/svn/revmeta.py", line 310, in get_direct_lhs_parent_revmeta | 23:46 |
| enigma | assert self == firstrevmeta | 23:46 |
| jelmer | enigma: ah, that's a known issue in 0.5 | 23:50 |
| enigma | OK. | 23:50 |
| jelmer | enigma, I've fixed the tags issue you mentioned. Thanks! | 23:51 |
| enigma | jelmer: You're welcome. | 23:52 |
| jelmer | Peng_, no, I think it's not related. | 23:56 |
| enigma | jelmer: Are there docs on the bzr svn-* commands? How do I know what all the different commands are? | 23:58 |
| Peng_ | enigma: "bzr help commands"? | 23:58 |
| Peng_ | jelmer: Okay. :) | 23:59 |
| Peng_ | jelmer: Thanks for your help tonight. :) | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!