| jelmer | w00t, got "bzr builddeb <remote-url>" working :-) | 00:30 |
|---|---|---|
| alecwh | Hello! I want my bzr repository to be something that any user can just clone for the latest version possible of the software. The only problem is, I have a "config.php" file that needs to be changed after a clone, because a variable needs to be set to "$installed = 'no';". However, my local copy has it to 'yes' because that's what I use for myself. So, is there any way that bzr can just "ignore" that config.php to any changes, and just leave | 03:12 |
| bob2 | have a seperate branch | 03:12 |
| bob2 | although then you can only merge one way | 03:13 |
| alecwh | oh, so just merge branches whenever I make a change? | 03:16 |
| alecwh | but that will merge the config.php's (and probably have a merge conflict), because they are different, correct? | 03:16 |
| jelmer | alecwh: alternatively, you may just want to include a file "local-config.php" from your config.php that isn't versioned | 03:20 |
| jelmer | perhaps only if it exists, and set "$installed = 'yes'" if it doesn't | 03:21 |
| alecwh | jelmer: good idea actually... but if bzr doesn't recognize it, then it won't be uploaded with the repository. | 03:22 |
| jelmer | alecwh: yes, but you would be the only one who would have to have that file | 03:22 |
| jelmer | users who wouldn't have it would just get the default configuration | 03:23 |
| alecwh | oh okay. I'll try that out, thanks jelmer. | 03:23 |
| alecwh | =) | 03:23 |
| alecwh | wait - what does bzr ignore do? | 03:23 |
| bob2 | stop bzr status complaining about files being unknown and 'bzr add .' from adding them | 03:23 |
| alecwh | oh, ok. | 03:29 |
| bob2 | (you can still add them by giving their specific name) | 03:30 |
| nekohayo | ugh, for some reason I am still not able to rebase with bzr 1.5, getting tracebacks, can anyone help me figure out if it's me doing something wrong or if it's a bug? | 03:51 |
| jearl | cspam | 05:01 |
| === mwhudson_ is now known as mwhudson | ||
| alecwh | I'm trying to get bazaar to work with http://cia.vc to send my commits to IRC channels, but I'm stuck. Does anybody know how to do this? | 06:25 |
| bob2 | you're using the bzr cia thing? | 06:57 |
| gour | is this "Another possible use for a checkout is to use it with a treeless repository containing your branches, where you maintain only one working tree by switching the master branch that the checkout points to when you want to work on a different branch." common 'bzr-idiom' when for local development? | 06:59 |
| gour | s/when for/for | 06:59 |
| gour | my xdg_email is empty...anyone use Gnus with bzr? | 08:38 |
| vila | gour: I use bzr and I use Gnus, what is your question :) | 09:03 |
| bob2 | I don't even have a xdg_mail | 09:04 |
| vila | gour: no need for a Gnus mail client, just add 'mail_client = emacsclient' in ~/.bazaar/bazaar.conf and add (server-start) to your ~/.gnus | 09:05 |
| vila | gour: I said ^ a few days ago, did you read it ? | 09:05 |
| gour | thanks | 09:06 |
| gour | vila: no, i missed it | 09:06 |
| vila | gour: hmm, yeah, re-reading logs, you left just before I posted it :) Sorry, I missed that detail :-/ | 09:07 |
| gour | ta | 09:08 |
| vila | gour: what exactly means 'ta' | 09:08 |
| vila | I understand the 't' is for thanks but the 'a' ? | 09:09 |
| gour | 'alot' | 09:10 |
| spiv | "ta" is just a short way to say "thanks". | 09:10 |
| gour | :-) | 09:10 |
| vila | spiv: hi ! | 09:10 |
| spiv | vila: good evening | 09:11 |
| vila | I'm looking at bug #230223, but I feel out of my league :-/ | 09:11 |
| ubottu | Launchpad bug 230223 in bzr "smart server probing in 1.4 breaks check outs of short bus http repositories [regression]" [High,Confirmed] https://launchpad.net/bugs/230223 | 09:11 |
| spiv | vila: sorry, I'm just passing through... | 09:12 |
| vila | my understanding so far is that smart server probing is not prepared to receive a 403 | 09:12 |
| vila | spiv: ok, no worries | 09:12 |
| * spiv -> dinner | 09:12 | |
| alefteris | i upgraded my local branch to rich-root-pack, then I'm trying to do the same with the launchpad.net hosted branch, but I get this: "bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format." | 11:39 |
| alefteris | when i try to do bzr info at the launchpad branch i get "Standalone branch (format: unnamed)". What am I doing wrong? | 11:40 |
| === brilliantnut is now known as brilliantout | ||
| lifeless | alefteris: for the launchpad branch you need to upgrade using sftp; that should work | 12:00 |
| alefteris | lifeless, thanks, I had to install paramiko as well and all went fine :) | 12:07 |
| jelmer | nekohayo, please file a bug report | 12:37 |
| lifeless | jelmer: bzr pull from bzr-svn - is it mainly slow cause of bzr ? | 12:46 |
| jelmer | lifeless: yes | 12:47 |
| jelmer | lifeless, there are some minor bits that can be improved in the fetch code of bzr-svn but it's mainly in the bzr-side of things | 12:49 |
| jelmer | lifeless, are you doing a pull that appears to be too slow? | 12:50 |
| bob2 | did the bzr-gtk trunk get rebased? | 12:52 |
| jelmer | bob2 | 12:53 |
| jelmer | no | 12:53 |
| lifeless | jelmer: I was showing ted gould from inkscape | 12:57 |
| lifeless | jelmer: and it was doing a revision every 30-40 seconds ot so | 12:57 |
| lifeless | which is rather appalling :P | 12:57 |
| bob2 | oh, bah, ~bzr/bzr-gtk got killed 6 months ago and I didn't notice | 12:58 |
| jelmer | lifeless: Wow, ok. Worst I've seen is once every couple of seconds | 12:58 |
| jelmer | lifeless: Any idea what is being so slow? | 12:59 |
| jelmer | lifeless, are you trying this with a local svn repository? | 13:01 |
| jelmer | sourceforge can be really slow sometimes | 13:02 |
| jelmer | lifeless: I'm just trying it as well now, and it's taking 2 seconds to reply to each request | 13:05 |
| jelmer | lifeless: so, when are shallow branches going to land ? :-P | 13:06 |
| lifeless | jelmer: argh, 2 second latency on the server is explainable :) | 13:18 |
| lifeless | jelmer: could we show that in thhe ui/log file somehow ? | 13:19 |
| jelmer | lifeless: we are, but the progress bar is sometimes hidden for some unexplainable reason | 13:19 |
| jelmer | there are progress bars being displayed from inside bzr-svn | 13:20 |
| jelmer | s/displayed/created | 13:20 |
| hsn_ | zr: ERROR: No such file: 'http://bazaar-vcs.org/bzr/bzr.dev/.bzr/repository/indices/b072a80d0242839227870cba3a3e0f9b.rix' | 13:20 |
| hsn_ | repo moved? | 13:20 |
| lifeless | hsn_: probably a push going through at the time you were reading | 13:22 |
| lifeless | hsn_: just try again | 13:22 |
| lifeless | hsn_: there is a bug open - this is something we should retry on | 13:23 |
| hsn_ | lifeless: it works now | 13:29 |
| jelmer | lifeless: inkscape isn't exactly fast here either; does about one revision every two or three seconds | 13:56 |
| jelmer | lifeless: seriously though - what's still left for shallwo branches? | 13:57 |
| lifeless | jelmer: thats faster than we were seeing | 13:58 |
| lifeless | jelmer: well the prototype branch is there for testing; you should be able to do bzr-svn work for it now | 13:58 |
| lifeless | jelmer: I'm working on optimisations now - inpartcular exposing historic texts on all repositories | 13:58 |
| jelmer | lifeless: where's the branch? | 14:00 |
| lifeless | jelmer: mumbke shallow-branch or somthing | 14:11 |
| lifeless | http://www.google.com/search?q=bzr+shallow+branch&ie=utf-8&oe=utf-8&aq=t&rls=com.ubuntu:en-US:unofficial&client=firefox-a | 14:11 |
| lifeless | its in that list :) | 14:11 |
| * jelmer wished he could do "lp list-branches bzr | grep shallow" | 14:12 | |
| jelmer | lifeless: how stable is that API supposed to be, and what are the chances it's going to be in 1.6 ? | 14:17 |
| * jelmer doesn't want to go through similar issues as rich roots | 14:17 | |
| lifeless | jelmer: hopefully the external API is done | 14:21 |
| lifeless | I would like it if you worked with me on a beta-bzr-svn branch to use it | 14:21 |
| lifeless | jelmer: that would be better than waiting for me to be 'done' and then findingout its missing/bad for you | 14:22 |
| lifeless | jelmer: just don't offer it to 'users'. | 14:22 |
| jelmer | lifeless: I'm happy to work on "beta" support in bzr-svn, I'm just trying to avoid participating in the process too early | 14:28 |
| jelmer | and having to maintain a bzr-svn branch through API changes and months of bzr releases | 14:29 |
| acuster | hey jelmer! Any chance you'd be willing to flesh out your answer to the last FAQ: http://samba.org/~jelmer/bzr-svn/FAQ.html ? | 14:31 |
| jelmer | acuster: What specifically? | 14:31 |
| acuster | it bit me enough that I'm being pushed towards mercurial but I suspect bzr handles svn copy better than hg | 14:31 |
| acuster | I did a push back to svn, possibly with an --overwrite I don't remember, and the operation deleted the whole trunk and pushed us back to where I had converted from | 14:32 |
| acuster | so I gather I deeply misunderstood how bzr and svn go together | 14:33 |
| acuster | so specifically | 14:33 |
| acuster | that and it are vague | 14:33 |
| acuster | I'd like a recepie possibly with why | 14:33 |
| lifeless | jelmer: I would help maintain such a branch | 14:34 |
| lifeless | jelmer: work goes >> when many hands | 14:34 |
| jelmer | acuster: I updated the FAQ | 14:34 |
| acuster | thanks | 14:34 |
| jelmer | lifeless: Thanks, that'd help | 14:35 |
| acuster | I'll try to get a better grip on my question when I can use 1.5 on this hardy | 14:35 |
| lifeless | jelmer: have you seen my status mails ? | 14:42 |
| jelmer | lifeless: no, I haven't - a quick search for "shallow" in my bzr mailbox doesn't list anything | 15:03 |
| jelmer | lifeless: also, the only "shallow" branch from you on launchpad is 11 weeks was last changed in february | 15:04 |
| bob2 | it's on p.u.c | 15:04 |
| jelmer | http://people.ubuntu.com/~robertc/baz2.0/shallow-branch/ ? that's the one that hasn't hcanged since feb | 15:06 |
| nekohayo | jelmer: hey, it seems it stopped giving me tracebacks! http://pastebin.ca/1021882 but I get a bunch of conflicts. should bzr replay be done with -r2.. (revision 2 is identical in contents) or the revision that followed? | 15:07 |
| jelmer | nekohayo: the branches probably have different file ids | 15:09 |
| nekohayo | jelmer: well, I assume so, they were different branches... what do I do? | 15:09 |
| jelmer | the maptree stuff should be able to help there (it makes rebase/replay use paths rather than file ids) but that's not hooked up to the rebase ui yet (only used by svn-upgrade) | 15:10 |
| jelmer | so it's not really possible to use rebase/replay in this case | 15:11 |
| nekohayo | >_<?! | 15:11 |
| nekohayo | I don't exactly see what's so unusual with my case :| | 15:12 |
| jelmer | different file ids | 15:12 |
| nekohayo | jelmer: what is a fileid actually? and how could branches that were not historically connected ever have matching file ids? | 15:17 |
| jelmer | nekohayo: a file id is a unique string that identifies a file. It's generated when it is first added to bzr | 15:17 |
| jelmer | nekohayo: there's no way for historically not connected branches to have the same file ids | 15:17 |
| nekohayo | so there's no way to go further now? solving the conflicts wouldn't do it? | 15:19 |
| jelmer | nekohayo: you can use diff + patch manually to replay each commit so you end up using the file ids from the branch you're building on rather than the branch you're replaying | 15:20 |
| nekohayo | basically recommitting everything by hand | 15:22 |
| jelmer | yes | 15:22 |
| jelmer | I'm not aware of any bzr plugins at that can do that for you | 15:22 |
| jelmer | rebase/replay could do it if you hooked up the maptree stuff | 15:23 |
| nekohayo | how hard is that? | 15:23 |
| jelmer | should be a matter of adding a call to MapTree() in the function that replays a delta in rebase | 15:25 |
| lifeless | jelmer: yes, thats right - I've been working on 'VersionedFiles' the consolidation of knits etc | 15:26 |
| lifeless | jelmer: that will let me loosen the constraint on version locking in shallow-ranch, and also get good performance for checkout() over the network. | 15:26 |
| nekohayo | rebase.py:410:def replay_delta_workingtree(wt, oldrevid, newrevid, newparents, | 15:27 |
| nekohayo | jelmer: I see that there is a file bzr-rebase/site-packages/bzrlib/plugins/rebase/test_maptree.py | 15:31 |
| nekohayo | but I don't understand it | 15:32 |
| jelmer | nekohayo: you'd need the code in maptree.py | 15:32 |
| jelmer | and wrap the other tree specified to merge in replay_delta_workingtree() with MapTree() | 15:34 |
| nekohayo | x_x beyond my skillset I guess | 15:40 |
| nekohayo | or is there a bug/blueprint I can subscribe to for rebase to support maptree? | 15:40 |
| jelmer | no, though you could file one | 15:41 |
| Verterok | Hi | 15:54 |
| Verterok | nekohayo, jelmer: maybe using fastexport/fastimport to replay the commit? | 15:54 |
| Verterok | s/commit/commits/ | 15:54 |
| lifeless | jelmer: so look for those mails :) | 15:55 |
| lifeless | vila: isn't your new POST bug a dupe? | 15:56 |
| vila | lifeless: I was unsure and wanted a reference to put in my merge request for #230223 | 15:57 |
| vila | lifeless: bug #231649 is for the *test* servers | 15:57 |
| ubottu | Launchpad bug 231649 in bzr "http test server can't handle POST" [Undecided,Confirmed] https://launchpad.net/bugs/231649 | 15:57 |
| lifeless | vila: anyhow, do you have time to look at http vs sftp pull performance? | 15:58 |
| vila | ghaaa, still trying to clean up my plate, I think I shoudl decline :-/ | 15:59 |
| vila | I really really really want to write that use-a-real-server-for-tests plugin now | 16:00 |
| vila | lifeless: wait a minute, what are you talking about ? http vs sftp ? Care to help me page in ? | 16:01 |
| lifeless | vila: couple days ago | 16:04 |
| lifeless | vila: kinnison was saying 'pull never utilises full bandwidth' | 16:04 |
| lifeless | vila: I said 'try sftp'; he did and it maxed his link out | 16:04 |
| lifeless | vila: he had been pulling over http | 16:05 |
| vila | so sftp utilizes full bandwidth but http not ? If it's with urllib, that's a regression from the time I rewrote the streaming part. | 16:09 |
| vila | trying. | 16:12 |
| vila | branch uses full bandwidth AFAICS, or not ? Seems like many pack files are involved. | 16:15 |
| vila | sftp doing asynchronous IO thanks to paramiko may explain a bit of difference | 16:16 |
| nekohayo | jelmer: think that could work? | 16:17 |
| jelmer | nekohayo, not familiar enough with fastexport/fastimport | 16:18 |
| nekohayo | Verterok: never tried them, any pointers how to go about it? | 16:18 |
| vila | lifeless: indeed, pull seems worst than branch for bandwith (did a test with bzr branch -r 3300 bzr.dev tests; cd test; bzr pull bzr.dev | 16:19 |
| jelmer | lifeless, any chance you can merge bzr.dev in your shallow branch branch? | 16:19 |
| Verterok | nekohayo: I'm not an expert, but played a bit with it :) | 16:19 |
| Verterok | nekohayo: first do an fastexport of the branch, then you can write your own processor to filter whatever you need to | 16:20 |
| Verterok | and do a fastimport, using the your custom proccessor | 16:21 |
| lifeless | jelmer: I will, once I have all tests passing with no repository._revision_store | 16:27 |
| lifeless | jelmer: e.g. probably tomorrow | 16:27 |
| jelmer | lifeless, ok | 16:27 |
| vila | lifeless: bzr: ERROR: Not a branch: "sftp://vila@bazaar.launchpad.net/~bzr/bzr/trunk/ ??? | 17:08 |
| bob2 | are you a member of the bzr group? | 17:09 |
| vila | bob2: I hope so :) | 17:10 |
| bob2 | hehe | 17:11 |
| lifeless | vila: ? | 17:24 |
| vila | lifeless: shouldn't there be a branch there ? | 17:25 |
| lifeless | interesting | 17:25 |
| lifeless | vila: no | 17:26 |
| lifeless | vila: its not hosted on launchpad | 17:26 |
| lifeless | vila: its mirrored there only | 17:26 |
| vila | simple, clear. Thanks lifeless :) | 17:26 |
| === emgent is now known as emgent`UDS | ||
| === emgent`UDS is now known as emgent | ||
| abentley | vila: We are hoping to make our sftp and bzr+ssh services behave the same. So that branch might be available on sftp after the next launchpad release. | 18:05 |
| abentley | vila: I worked on that with jml. It was rather tricky because the sftp server is twisted, and bzr+ssh is synchronous. | 18:07 |
| vila | abentley: thanks for the info, what I was searching for was a branch that I can access with http and sftp with the same network context cot ompare respective performances, I totally forgot that I was accessing different hosts on lp, so... | 18:09 |
| vila | s/cot/to/ | 18:09 |
| abentley | vila: I think the host is the same in both cases. The problem is really that there are two different areas on launchpad; the hosted area and the mirrored area. http gives access only to the mirrored area (which contains copies of hosted branches). sftp gives access only to the hosted area. | 18:12 |
| abentley | bzr+ssh gives access to both, preferring hosted. | 18:12 |
| vila | abentley: thks. | 18:14 |
| abentley | np | 18:15 |
| vila | grr, what is the difference between code.lp.net and bazaar.lp.net ? bazaar is giving me a 502 Bad Gateway after a 215s timeout where code seems to issue a redirection (triggering a bug in the nosmart+ decorator by the way) 8-( | 18:22 |
| beuno | vila, I think code.lp is used for the web app, and bazaar.lp is for actual branches | 18:24 |
| beuno | morning :) | 18:24 |
| vila | beuno: hi :) | 18:24 |
| === brilliantout is now known as brilliantnut | ||
| vila | !paste | 18:49 |
| ubottu | pastebin is a service to post multiple-lined texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu.com (make sure you give us the URL for your paste - see also the channel topic) | 18:49 |
| lifeless | see you all tomorrow | 19:00 |
| === weigon_ is now known as weigon | ||
| === emgent is now known as emgent`UDS | ||
| === emgent`UDS is now known as emgent | ||
| === mwhudson_ is now known as mwhudson | ||
| MachinShin | hey guys, getting this error, what can i do to fix it? ->bzr: ERROR: Unsupported protocol for url "sftp://<censored>/trunk": Unable to import paramiko (required for sftp support): No module named paramiko" | 21:24 |
| mwhudson | beuno: damn loggerhead -- i bounced it | 21:24 |
| jelmer | MachinShin, install paramiko | 21:24 |
| MachinShin | thanks jelmer | 21:30 |
| Peng | Ok, this is weird. I'm reading Ben Finney's posts on the mailing list while watching the Star Trek TOS episode about Lt. Cmdr. Ben Finney. | 21:50 |
| pickscrape | Maybe they used bzr for source control when programming the LCARS system? | 21:51 |
| thumper | morning | 22:21 |
| thumper | jelmer: are you available for a few questions? | 22:21 |
| jelmer | thumper, hi | 22:21 |
| jelmer | thumper, sure | 22:21 |
| thumper | jelmer: There are two branches on launchpad that are causing many errors right now | 22:22 |
| thumper | jelmer: and both are bzr-svn branches | 22:22 |
| thumper | jelmer: one is yours, and one is a friends | 22:22 |
| thumper | jelmer: LP is failing to scan them properly as it is failing some basic integrity checks on revisions | 22:22 |
| thumper | jelmer: one thing we do is to check the revisions to make sure that the parentage hasn't changed | 22:22 |
| thumper | jelmer: but for these two branches it appears that between scans, the parents of some revisions did change | 22:23 |
| thumper | jelmer: I was under the impression that bzr revisions didn't change once they were created | 22:23 |
| jelmer | thumper, that's correct | 22:23 |
| thumper | s/didn't/shouldn't/ ? | 22:23 |
| jelmer | which branches are these? | 22:23 |
| thumper | https://code.launchpad.net/~jelmer/python/trunk is one | 22:24 |
| thumper | RevisionModifiedError: parent svn-v3-trunk1:6015fed2-1504-0410-9fe1-9d1591cc4771:python%2Ftrunk:55872 was added since last scan | 22:24 |
| thumper | jelmer: that is the error I am seeing | 22:24 |
| jelmer | to which revision was that parent added? | 22:25 |
| thumper | jelmer: unfortunately I don't think I have that information easily to hand | 22:26 |
| thumper | jelmer: what can I provide in order to help track this down? | 22:26 |
| jelmer | thumper: details about which revision apparently changed parents | 22:26 |
| thumper | ok | 22:26 |
| thumper | is that all? | 22:26 |
| jelmer | thumper: Also, is this integrity checking done across branches? | 22:27 |
| thumper | jelmer: yes | 22:27 |
| thumper | that may be the underlying problem | 22:27 |
| thumper | we store a copy of the revisions in the database | 22:27 |
| jelmer | in that case it's probably that one of the branches was created using an experimental version of bzr-svn | 22:27 |
| thumper | which includes parentage | 22:27 |
| thumper | hmm... | 22:28 |
| thumper | this is an interesting problem to solve then | 22:28 |
| jelmer | thumper: I think one of the branches just has to be thrashed | 22:29 |
| thumper | jelmer: is there any way to determine which branch is the one created with the experimental bzr-svn? | 22:29 |
| jelmer | well, recreating that branch using a stable version of bzr-svn | 22:30 |
| thumper | jelmer: ok, thanks | 22:31 |
| xif | How, and how well, does bzr support the following development process: | 22:41 |
| xif | The project has the following root directories: /linux, /osx, and /osx-diffs. Each time a developer commits /linux/foo.conf, the SCM applies the /osx-diffs/foo.conf.diff to it, and then commits it /osx/foo.conf. | 22:41 |
| xif | (commits it as the file /osx/foo.conf) | 22:41 |
| thumper | xif: sounds like a candidate for looms | 22:43 |
| thumper | xif: as long as you didn't have bidirectional diff application | 22:43 |
| thumper | xif: you could have /linux as the base thread | 22:44 |
| thumper | xif: and /osx os the next thread | 22:44 |
| thumper | xif: and the difference between them is effectively the /osx-diffs | 22:44 |
| thumper | xif: there is an export-loom command that can create branches for each thread | 22:45 |
| xif | thumper: very cool... I'm looking at this right now | 22:45 |
| thumper | xif: you would commit on /linux | 22:45 |
| thumper | xif: then switch up to /osx | 22:45 |
| thumper | xif: and merge, resolve and commit | 22:45 |
| thumper | at least that is how I think it would work | 22:45 |
| xif | yeah, it definitely looks interesting... | 22:46 |
| xif | I'm reading about it right now: http://blogs.gnome.org/jamesh/2008/04/01/bzr-loom/ | 22:46 |
| xif | thumper: thanks for the recommendation :) | 22:46 |
| thumper | xif: np | 22:46 |
| Peng | Wouldn't branches work too? | 23:13 |
| xif | Peng: how, exactly? | 23:28 |
| Peng | I dunno. | 23:32 |
| Peng | I have very little experience with looms, but how are looms better than branches for this? Avoiding lots of merge revisions? | 23:32 |
| awilkins | I have a feeling I should have used looms for one of my projects after reading that page | 23:36 |
| awilkins | My example is patches to a set of model files (written as Java) ; one set of patches that was compatible with the old model, one that was for the new software and wasn't | 23:37 |
| awilkins | I was managing that as two branches ; and I was making compatible changes in one branch and merging up to the other, but it sounds like I should have made a loom and had a compatible thread and an incompatible thread | 23:37 |
| awilkins | It would at least have beem more conveneient | 23:38 |
| * awilkins is tired and his fingers are slipping | 23:38 | |
| awilkins | I still don't think it easily addresses what to do when you are making changes and one part of them should be in a thread lower than you are on... I think you might have to shelve the bits that go in the higher thread, jump down a thread, commit, jump up adnd unshelve and commit | 23:40 |
| awilkins | Anyhow, gnight. | 23:41 |
| igc | morning | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!