[00:11:56] <Simon Wilkinson> Not yet.
[01:23:33] --- manfred furuholmen has left
[01:25:35] --- manfred furuholmen has become available
[01:32:54] --- haba has left
[05:00:50] --- haba has become available
[05:57:41] --- manfred furuholmen has left
[05:59:56] --- matt has left
[06:37:40] --- matt has become available
[06:38:01] --- manfred furuholmen has become available
[07:03:57] --- reuteras has left
[07:54:26] <jhutz@jis.mit.edu/owl> (stark)
> in much the way as it does with CVS now
Except now it doesn't do that.  What it emits is a concatenation of
exactly one single-file version-to-version diff for each line appearing
in the delta file, so split deltas and other horrors Just Work(tm).
git wdelta will have a lot less work to do, since it'll be able to
more or less just extract a changeset, but it will have to know about
split changesets.  That shouldn't be too hard, though.
[07:55:19] <Simon Wilkinson> I'm thinking that git wdelta will just extract the multiple changesets, then mergediff them. Is that a horrific idea?
[07:55:28] <shadow@gmail.com/owl72BABB76> why even mergediff?
[07:55:53] <Simon Wilkinson> I guess it doesn't need to.
[07:55:53] <shadow@gmail.com/owl72BABB76> (mergediff is known to screw up; in the process of working on 1.4.10, i
discovered that)
[07:56:20] <jhutz@jis.mit.edu/owl> (more stark)
> pull up selected deltas and then have to resolve three million ^)&#$ Id
> conflicts.

That's what -kk is for.
[07:56:40] <shadow@gmail.com/owl72BABB76> > That's what -kk is for.

and wdelta doesn't use it, does it?
[07:57:11] <Simon Wilkinson> So, all that it needs to do is check to see if $delta exists in git. If it doesn't, check for $delta."-part-1", and if that exists, concatenate all of the parts together and return them?
[07:57:40] <shadow@gmail.com/owl72BABB76> yeah, that'd be my opinion. it matches what wdelta already does, and it
should be no less safe
[07:58:37] --- haba has left
[07:58:38] <Simon Wilkinson> There are actually only around 100 deltas that fall into this category. I haven't yet checked to see how many of them are unmergable (because they span tag or branch points), and how many could be merged by resorting to patches.
[07:58:50] <jhutz@jis.mit.edu/owl> > not expose all of the deltas as tags
Agree.  As long as there's some way to map a delta to a commit, we
can write git-wdelta, and people won't miss being able to extract deltas
without wdelta because they never had that capability before.
[07:59:00] <Simon Wilkinson> I'm not convinced it's worth the effort, though. It's certainly not high on my priority list.
[07:59:11] --- haba has become available
[07:59:34] <Simon Wilkinson> git show refs/deltas/<branch>/<deltaname> == git-wdelta
[08:00:03] <shadow@gmail.com/owl72BABB76> > people won't miss being able to extract deltas

gatekeepers did.
[08:00:42] <jhutz@jis.mit.edu/owl> > I think the tools for our git->cvs translation are done...

yay
[08:00:58] <shadow@gmail.com/owl72BABB76> i wish jhutz would have just read backwards.
[08:01:54] <Simon Wilkinson> I wish the link between here and Stanford was faster than 32KB/s
[08:02:08] <andersk@mit.edu/vinegar-pot> Oh, hmm, does that mean that this git import isn’t using -kk either?
[08:02:17] <shadow@gmail.com/owl72BABB76> where do you have a fast link to?
[08:02:20] <Simon Wilkinson> The import uses -kk
[08:02:32] <Simon Wilkinson> I'm at home. I have a fast link to ~nowhere.
[08:02:40] <shadow@gmail.com/owl72BABB76> oh. stop being at home?
[08:19:13] --- haba has left
[08:19:34] --- Jeffrey Altman has become available
[08:20:04] <jhutz@jis.mit.edu/owl> > The one in /afs/.grand.central.org is incomplete...
incomplete how?
[08:20:54] <jhutz@jis.mit.edu/owl> Oh.  The modules that are not openafs are in
/afs/.grand.central.org/project/gco/cvs
[08:21:46] <jhutz@jis.mit.edu/owl> Yeah; I wouldn't try to mergediff; I'd just concatenate, the way current
wdelta does.
[08:22:01] <jhutz@jis.mit.edu/owl> wdelta has a checkbox you can click to get -kk
[08:22:54] <jhutz@jis.mit.edu/owl> > gatekeepers did.
How?
And, gatekeepers are a small part of the audience for this.
Yinz can just deal.
[08:23:47] <shadow@gmail.com/owl72BABB76> shell script
[08:23:56] <shadow@gmail.com/owl72BABB76> "getdelta"
[08:23:57] <jhutz@jis.mit.edu/owl> > simon has access to grand now, doesn't he?
Not until he sends me a username and ssh key
[08:24:10] <Simon Wilkinson> Just about to...
[08:25:26] <jhutz@jis.mit.edu/owl> Well, then.  You can fix your shell script.
[08:25:58] <Simon Wilkinson> Like I said, providing you have a full copy of the repository, deltas are just another type of reference.
[08:29:09] <jhutz@jis.mit.edu/owl> > git show refs/deltas/<branch>/<deltaname> == git-wdelta

Sort of.  Certainly most of the things wdelta does can be done using
the existing git web tools.  So mostly git-wdelta is a redirector to
make sure that existing URI's do something useful.  Especially, I
want to make sure there's still an easy way to (manually) construct
a URI that returns the diff corresponding to some delta name.
[08:31:56] <Simon Wilkinson> Anyone here got root on openafs.stanford.edu ?
[08:35:24] <jhutz@jis.mit.edu/owl> OK; you now have an account on grand
[08:35:34] <Simon Wilkinson> Thanks!
[08:45:01] <Simon Wilkinson> For those who want to play:  git-clone http://openafs-git.stanford.edu/git/openafs-test-20090526.git/ openafs
[08:55:08] <manfred furuholmen> do you have a web git ? 
[08:55:50] <Simon Wilkinson> Not until someone who can tweak a configuration setting for me appears ...
[08:59:37] <stevenjenkins> painfully slow..
[08:59:58] <Simon Wilkinson> What's "painfully slow" ?
[09:00:28] <stevenjenkins> ~1 min to figure out it needs to get a pack.
[09:00:35] <stevenjenkins> ie, not very responsive.
[09:00:41] <Simon Wilkinson> I suspect it may be busy :)
[09:00:47] <stevenjenkins> perhaps.
[09:00:56] <stevenjenkins> I thought of that, too, but not sure who else here is poking at it.
[09:00:56] <andersk@mit.edu/vinegar-pot> Have a gitweb: http://andersk.mit.edu/gitweb/openafs.git
[09:02:52] <manfred furuholmen> great 
[09:02:55] <andersk@mit.edu/vinegar-pot> HEAD currently points to openafs-stable-1_2_2x.  Can you `git
symbolic-ref HEAD refs/heads/master`?
[09:03:03] <Simon Wilkinson> I can, yes.
[09:04:01] <Simon Wilkinson> Done.
[09:04:21] <Simon Wilkinson> The delta stuff actually seems to work quite nicely with gitweb - that's a pleasant surprise.
[09:05:59] <Simon Wilkinson> I wonder if, now that the delta and author information is in the repository metadata, we should just pull them out of the log message.
[09:07:55] <andersk@mit.edu/vinegar-pot> The delta name generally makes a better shortlog than the first line
of the commit message.  Yes, it appears repeated in gitweb, but not
in gitk.
[09:08:35] --- haba has become available
[09:09:59] <andersk@mit.edu/vinegar-pot> Though making the first line “linux-revalidate-renames-correctly”
instead of “DELTA
STABLE14-linux-revalidate-renames-correctly-20080707” might improve
readability.
[09:10:11] <shadow@gmail.com/owl72BABB76> i probably hve root on openafs.stanford.edu
[09:10:44] <shadow@gmail.com/owl72BABB76> > we should just pull them out of the log message.    

yes
[09:10:56] <Simon Wilkinson> If you do, can you change /etc/gitweb.conf so that $pathroot points at "/srv/git"
[09:12:15] <shadow@gmail.com/owl72BABB76> if i do have root, i don't remember how to use it. 
[09:12:39] <Simon Wilkinson> Oh well, I've mailed Russ.
[09:13:34] <shadow@gmail.com/owl72BABB76> me too.
[09:13:36] <shadow@gmail.com/owl72BABB76> oops
[09:14:49] <Simon Wilkinson> Basically, what I'd like now is for people to take a look at that git repo, and let me know anything that could do with being changed. Unless we're going to have masses of rebase pain, we only have one chance to get this right!
[09:15:55] <andersk@mit.edu/vinegar-pot> There are lots of empty commits with messages like “file
vsutils_prototypes.h was added on branch openafs-devel-1_5_x on
2008-04-10 17:52:27 +0000”.
[09:16:23] <Simon Wilkinson> Hrmmm. Thank cvsps for those.
[09:16:33] <andersk@mit.edu/vinegar-pot> Thank you, cvsps.
[09:16:43] <Simon Wilkinson> I think I can probably drop them - they just create dead files, after all.
[09:17:18] <andersk@mit.edu/vinegar-pot> STABLE14-yscall-cleanup-if-we-installed-20071024 is on the devel15
branch?
[09:17:58] <Simon Wilkinson> Yeh. Someone got the delta name wrong.
[09:18:10] <Simon Wilkinson> (It's on both 14 and 15 with the same name)
[09:19:18] <Simon Wilkinson> There's a few of those ...
[09:20:59] <shadow@gmail.com/owl72BABB76> "someone" being me
[09:21:43] <andersk@mit.edu/vinegar-pot> Some of the multiple commits that got squashed together, such as in
the rxk5-devel-1_5_7 branch, possibly shouldn’t have been even though
they use the same delta names.
[09:21:58] <andersk@mit.edu/vinegar-pot> er, rk5-devel-1_5_57
[09:22:15] <andersk@mit.edu/vinegar-pot> er, rxk5-devel-1_5_57
[09:22:27] <Simon Wilkinson> That was the remit. That if something was a delta, it became a changeset as far as that was possible.
[09:22:36] <Simon Wilkinson> What's your reasoning for not joining them together?
[09:24:06] <andersk@mit.edu/vinegar-pot> Well, it loses some potentially useful information, and I have a
preference for commits that atomically do one thing if possible.
[09:25:14] <Simon Wilkinson> Apart from the fact that I wrote some fairly neat code to do the merging, I'm not fussed one way or the other really. I'll let you and Derrick discuss that one ...
[09:26:04] <andersk@mit.edu/vinegar-pot> Don’t get me wrong, the merging looks to be a definite improvement in
most cases.
[09:26:42] <Simon Wilkinson> I'm happy to add manual exceptions as required...
[09:27:08] <shadow@gmail.com/owl72BABB76> squashing rxk5-devel-1_5_57 commits together: don't care
[09:27:27] <Simon Wilkinson> BTW: Did you have to do anything in particular to get a clone of that repo that included the delta references?
[09:27:43] <andersk@mit.edu/vinegar-pot> I used `git clone --mirror`.
[09:28:09] <shadow@gmail.com/owl72BABB76> those commits may have been in small groups but it was effectively one
commit, so merging them isn't a problem. if you want to argue about it,
pick another branch
[09:28:10] <andersk@mit.edu/vinegar-pot> A normal git clone doesn’t include them.
[09:28:19] <Simon Wilkinson> Yeh.
[09:29:07] <Simon Wilkinson> I was hoping that git show would have a nice way of saying 'show me the commit corresponding to this reference in a remote repository', but I'm drawing a blank ...
[09:30:13] <andersk@mit.edu/vinegar-pot> Very well.  I won’t argue, then, unless I notice a particularly bad
merge.
[09:30:34] <shadow@gmail.com/owl72BABB76> well, there are places it might make sense to argue. that branch isn't
one of them
[09:30:36] <Simon Wilkinson> git show `git ls-remote origin refs/deltas/openafs-stable-1_2_x/STABLE12-linux-include-osidnlc-header-for-ia64-20020506 | cut -f1`
[09:30:44] <Simon Wilkinson> works, but won't win any prizes for neatness ...
[09:31:07] <andersk@mit.edu/vinegar-pot> You could modify your .git/config so that it fetches the delta refs
too.
[09:31:45] <Simon Wilkinson> I'm not sure I want everyone who fetches the git repository downloading all 10,000 or so delta references ...
[09:32:33] <andersk@mit.edu/vinegar-pot> Sorry.  By “your .git/config” I mean in the clone, not in the origin
repository.
[09:32:46] <Simon Wilkinson> Ah. Ok.
[09:33:34] <Simon Wilkinson> BTW: I've detailed the way the conversion process works at http://blob.inf.ed.ac.uk/sxw/2009/05/26/converting-openafs-to-git/
[09:36:21] <andersk@mit.edu/vinegar-pot> git config remote.deltas.fetch
'+refs/deltas/*:refs/remotes/deltas/*'; git config remote.deltas.url
http://openafs-git.stanford.edu/git/openafs-test-20090526.git; git
fetch deltas; git show
deltas/openafs-stable-1_2_x/STABLE12-linux-include-osidnlc-header-for-ia64-20020506
[09:37:05] <Simon Wilkinson> That's a snippet worth remembering ...
[09:38:43] <Simon Wilkinson> And RT #119102 now contains all of the necessary code, just in case of the proverbial bus.
[09:47:39] --- Russ has become available
[09:54:51] <andersk@mit.edu/vinegar-pot> Are you planning on post-processing the author field so that “shadow
<shadow>” becomes “Derrick Brashear <shadow@dementia.org>”?
[09:56:03] <Simon Wilkinson> Hrmmm. I guess I could.
[09:56:18] <Simon Wilkinson> We don't have that information for all of our authors, though.
[09:59:23] <andersk@mit.edu/vinegar-pot> You have all their email addresses, so you could send them all email
asking for it.
[09:59:55] <Simon Wilkinson> Yeh, but I'm not sure I have enough bother to collate all of the responses ... :)
[10:00:31] <shadow@gmail.com/owl72BABB76> we have a list somewhere
[10:00:49] <andersk@mit.edu/vinegar-pot> Post it on a wiki page and make them edit it there instead of
emailing you back?
[10:02:00] <shadow@gmail.com/owl72BABB76> well, i need to eat, but after that i will find the list we generated
the contributor page from (that also needs to be updated anyway)
[10:02:08] <Simon Wilkinson> I'd like to get git done within a pretty aggressive time frame, and there's other stuff (like gerrit and other tools to make git work with our workflow) that's probably higher priority. But if someone can give me a list, I'll happily add an author processing step.
[10:04:31] <andersk@mit.edu/vinegar-pot> List of all authors currently in Git:
`git log --all --pretty='format:%an <%ae>' | sort -u`
(Not what you just asked for, but useful to whoever plans on
producing it.)
[10:09:27] <Simon Wilkinson> It's a good place to start though...
[10:10:30] <Simon Wilkinson> 303 contributors. That's more than I would have thought, actually.
[10:16:37] --- manfred furuholmen has left
[12:01:05] <andersk@mit.edu/vinegar-pot> Looks like there’s no openafs-stable-1_4_10 tag?
[12:01:21] <matt> really?
[12:01:33] <shadow@gmail.com/owl72BABB76> in git, or cvs?
[12:02:00] <andersk@mit.edu/vinegar-pot> In git (haven’t checked CVS).
[12:14:23] <Simon Wilkinson> Okay. Puzzled. cvsps is creating that one (shock, horror) but it's being eaten somewhere. Let me investigate.
[12:24:37] <Simon Wilkinson> Found the bug. There were some cases where a tagged patchset would be incorrectly accepted as a merge candidate. I've fixed in my code, but as an import run takes over 5 hours, the fix won't make it into git until quite a bit later!
[12:29:13] <jhutz@jis.mit.edu/owl> What are you running your import runs on?
[12:29:41] <jhutz@jis.mit.edu/owl> As in, is it possible we could shorten the cycle by coming up with a
faster machine to do the work on?
[12:32:21] <Simon Wilkinson> I'm running it on a 4 CPU Mac Pro.
[12:33:38] <Simon Wilkinson> I think the process is actually I/O bound though. You end up with a CVS server on one core, and the import script on another, and pretty much everything waiting for disk.
[12:37:32] <stevenjenkins> are the relevant repos in a tarball or some such that I could pull down?  I have a decent system here (8 cpu, 8G RAM, w/relatively good RAID array) that I could put it on and see..
[12:37:50] <stevenjenkins> someone else might have something better..
[12:39:00] <Simon Wilkinson> All of the code is in RT. The cvs repo is in AFS.
[12:40:45] <andersk@mit.edu/vinegar-pot> The openafs-stable-1_4_10_1-branch head doesn’t match CVS.
[12:40:49] <stevenjenkins> 119102?
[12:41:03] <stevenjenkins> sxw - I thought you had modified some of the scripts..
[12:57:11] <Simon Wilkinson> Sorry, dinner happened.
[12:57:34] <Simon Wilkinson> Yeh. That's going to be the problem, that I'm constantly revising the scripts. Just giving someone them as a bundle probably won't help.
[12:57:55] <jhutz@jis.mit.edu/owl> You could... <gasp> put them in AFS
[12:58:14] <andersk@mit.edu/vinegar-pot> Or in Git, even.
[12:58:37] <Simon Wilkinson> Indeed.
[13:27:04] <shadow@gmail.com/owl72BABB76> i recompiled the list of contributors. side effect: i'll go fix the
credits page now
[13:43:34] <andersk@mit.edu/vinegar-pot> I checked the rest of the branches; they all match CVS (modulo some
missing files in CVS) except openafs-rxkad-krb5-lha and
openafs-stable-1_4_10_1-branch.
[13:44:25] <Simon Wilkinson> openafs-rxkad-krb5-lha is a known problem, that we're never going to manage to fix. Only part of that branch got tagged, so stuff's leaked into it from HEAD.
[13:44:32] <andersk@mit.edu/vinegar-pot> Right.
[13:44:39] <Simon Wilkinson> I wonder what's going on with openafs-stable-1_4_10_1-branch. 
[13:45:25] <Simon Wilkinson> Hmmm. I'm letting cvsps pick the branch point for that one. I bet it's getting it wrong.
[13:55:59] <shadow@gmail.com/owl72BABB76> istr i tagged the branchpoint
[13:56:35] <shadow@gmail.com/owl72BABB76> there. credits updated, complete with correct non-ascii characters
where known
[13:56:41] <Simon Wilkinson> Same place?
[13:57:08] <shadow@gmail.com/owl72BABB76> you already had a correct file, but if you need utf8 i should give you
a new copy
[13:57:26] <Simon Wilkinson> The cvsps post processor has logic to find branch points when they aren't tagged, so it doesn't really matter either way.
[13:58:12] <jhutz@jis.mit.edu/owl> In ISO-8859-1?
[14:01:58] <shadow@gmail.com/owl72BABB76> list injected into 124873
[14:03:24] <jhutz@jis.mit.edu/owl> Yay latenct.
[14:03:44] <jhutz@jis.mit.edu/owl> I meant, the www page has to be iso-8859-1, or it will display wrong.
I don't know what charset Simon needs.
[14:05:41] <shadow@gmail.com/owl72BABB76> the web page displayed wrong, in fact, until i fixed it
[14:05:52] <shadow@gmail.com/owl72BABB76> because in my first pass i simply wasn't thinking
[14:07:00] <jhutz@jis.mit.edu/owl> Perhaps the new web site should just use UTF-8 everywhere.
But the server will have to be told to advertise that.
I wonder if you can do that in a .htaccess file.
[14:07:37] <Russ> Yes, I'm fairly sure you can.
[14:07:52] <Russ> And yeah, I would recommend it.
[14:08:52] <jhutz@jis.mit.edu/owl> Yes; it looks like you can say
AddDefaultCharset utf-8
[14:13:50] <jhutz@jis.mit.edu/owl> That will override any charset in a meta tag in the document, but I think
that's OK because the nature of charset selection is such that a meta tag
is really too late anyway.
[14:15:48] <matt> -very- nice.  whee.
[14:17:20] <jhutz@jis.mit.edu/owl> Like, the problem is that before you can parse a meta tag, you have to
know that the document is http, which makes it too late to provide
Content-Type that way.  Though apparently lots of clients will support
the special case of a <meta http-equiv="Content-Type" content="text/html">
in a document they already think is text/html.
[14:41:43] <haba> Btw, all software projects from the US must screw up öäå at least once. Fortunately AFS did that allready back in the Transarc times. This year zope/plone did it for us: No form submissions with öäå worked.
[14:46:50] <jhutz@jis.mit.edu/owl> That's not totally fair.  In the days when AFS was invented, common
practice was to represent öäå by replacing ASCII [\]{|} with them (hence
the need for ANSI C trigraphs to represent).  That approach worked just
fine with AFS.
[14:52:08] <Russ> That's specific to Scandinavian languages, though, right?
[14:52:15] <Russ> Not that that changes your point.
[14:53:11] <jhutz@jis.mit.edu/owl> No; similar approaches were used for most of the Western European
languages, with different modified-ASCII variants for each language.
[14:53:20] <Russ> Oh, huh.  I didn't know that.
[14:53:35] <Russ> I knew German just did the multi-letter transcriptions.
[14:53:42] <Russ> But I didn't know what everyone else did.
[14:54:01] <jhutz@jis.mit.edu/owl> German used [\] for ÄÖÜ, {\} for the lowercase versions, and I think
~ for ß
[14:54:11] <Russ> Huh.
[14:54:50] <Russ> I thought they just did ß => ss.
[14:54:52] <jhutz@jis.mit.edu/owl> Germans _also_ often used multi-letter transcriptions, but those have
been considered legitimate alternate spellings in German since long
before computers got involved.
[14:55:02] <Russ> Right.  That was the part that I had remembered.
[14:55:31] <Russ> Did Spanish do that sort of transcription as well?
[14:55:37] <jhutz@jis.mit.edu/owl> The ß => ss case has an interesting twist, in that people _have_ to
do that in everyday life, because ß is lowercase and there is no
uppercase equivalent.
[14:55:48] <jhutz@jis.mit.edu/owl> I have no idea what other languages did.
[14:56:16] <Russ> Spanish can *mostly* do without its accent marks and n~ for n-with-tilde I used to see routinely.
[14:56:28] <jhutz@jis.mit.edu/owl> Well, I know they had funny ASCII variants of some sort, but I don't
know how complete they were or to what extent transliteration was used.
[14:57:18] <Russ> IIRC, there are places where dropping accents in Spanish cause serious problems, but they're relatively rare compared to some other European languages.  But it's been a long time.
[14:57:28] --- stevenjenkins has left
[14:57:38] --- abo has left
[14:58:01] <jhutz@jis.mit.edu/owl> FWIW, someone (haba?) tells me the sorting rules used for German at the
time were not what I thought they were, but I no longer remember which
approach was which.  There's probably something in zephyr logs.
[15:01:17] --- stevenjenkins has become available
[15:27:23] <haba> Sorting in german: ß eq ss, ä eq a, ö eq o, ü eq u.
[15:28:15] <haba> Sorting in swedish: At the end like this: ....xyzåäö, v eq w
[15:32:16] <haba> Encoding with å=},ä={,ö=\ see http://en.wikipedia.org/wiki/ISO/IEC_646 (see table at end for national variants) I still can write quite fluently 646-SE.
[15:33:26] <haba> And I have programmed with terminals chipped with 646-SE:
main() ä
 int arrÄ80Å
[15:33:31] <haba> å
[15:39:13] <haba> The funny thing is that the pipe sign (|) in 646 is exactly that sound "ö" that you make when thinking what to type next. So it comes naturally :-) :-)
[16:01:03] <jhutz@jis.mit.edu/owl> Oh, yes, that was the surprising thing - that ä is sorted with a, not
with ae
[16:10:02] --- matt has left
[16:39:43] <haba> However, a company named Möller would register moeller.de and moller.se as most people in these countries expect it to be written that way when there is no ö available. Nowadays, it is possible to register names with all characters of the swedish language and the swedish minority languages in domain names under .SE.
[16:40:45] <jhutz@jis.mit.edu/owl> Wait, which are swedish minority languages?
[16:42:55] <haba> I'd have to google but from my head finnish, Romani, Yiddish and a bundle of different tougues spoken in Lappland.
[16:45:30] <haba> http://en.wikipedia.org/wiki/Minority_languages_of_Sweden
[17:06:00] <Russ> Yeah, I was going to say Sami.
[17:07:33] <haba> That was the "bundle" I was talking about. Most of them sound finnsh like and some of them are nearly extinct.
[17:08:38] <Russ> Yeah, Finnish, Sami, and Hungarian, as I recall, are vaguely related.
[17:09:03] <Russ> Uralic, rather than Indo-European.
[17:09:05] <haba> add Estonian
[17:09:10] <Russ> Ah, yes.
[17:09:22] <Russ> But not Lithuanian or Latvian.
[17:11:20] * haba been to Estonia and Latvia and that's a completely different piece of cake. I can't say I've "been to" Lithuania only because the night train passed through and I was awoken by customs.
[17:13:37] <haba> (but that's Europe, go through a country by train and barely awake to notice it before you out again :-)
[17:15:13] <haba> But looking at the time in this TZ (at the start of each row in my gaim window) I really should.... Good night or whatever to everyone, see you later.
[18:15:06] --- edgester has become available
[18:28:41] --- Russ has left: Disconnected
[18:45:57] --- Russ has become available
[18:53:47] --- edgester has left
[23:32:12] --- reuteras has become available