problem with git-cvsserver

Hi,

I am trying to use git-cvsserver and I have come across this error:

   $ cvs co -d project-master master

install_driver(SQLite) failed: Can't locate DBD/SQLite.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl /usr/local/lib/perl/5.8.7 /usr/local/share/perl/5.8.7 .) at (eval 7) line 3, <STDIN> line 14.

Perhaps the DBD::SQLite perl module hasn't been fully installed,

or perhaps the capitalisation of 'SQLite' isn't right.

Available drivers: DBM, ExampleP, File, Pg, Proxy, Sponge, mysql.

at /usr/bin/git-cvsserver line 2055

cvs [checkout aborted]: end of file from server (consult above messages if any)

This is a debian testing/unstable machine with git, git-core, git-cvs etc installed (with no problems):

   $ dpkg --list git-cvs

||/ Name Version Description

+++-===============================-===============================-

ii git-cvs 1.4.1.1-1 content addressable filesystem (cvs interoperability)

Also, the perl DBI modules are installed:

   $ dpkg --list libdbd-sqlite3-perl

||/ Name Version Description

+++-===============================-===============================-

ii libdbd-sqlite3-perl 1.12-1 Perl DBI driver with a self-contained RDBMS

   $ dpkg -S SQLite

libdbd-sqlite3-perl: /usr/share/man/man3/DBD::SQLite.3pm.gz

libdbd-sqlite3-perl: /usr/share/perl5/DBD/SQLite.pm

libdbd-sqlite3-perl: /usr/lib/perl5/auto/DBD/SQLite

libdbd-sqlite3-perl: /usr/lib/perl5/auto/DBD/SQLite/SQLite.bs

libdbd-sqlite3-perl: /usr/lib/perl5/auto/DBD/SQLite/SQLite.so

Anyone know whats wrong? If its a problem somewhere else (eg. with debian packaging), please point me there,

thanks

a

Hi,

Have you checked that /usr/share/perl5/DBD/SQLite.pm is actually there? Because your perl does not think so.

OTOH it could be that it only works when SQLite.pm is in /usr/lib/perl5/DBD/ (note the "lib" instead of "share"), because in my (working) setup, both the .pm and the .so are under /usr/lib/perl5/...

Hth,
Dscho

Hi,

Thanks for the reply, but I think the files are in the right place- here is what I have:

   $ dpkg -S SQLite
   libdbd-sqlite3-perl: /usr/share/man/man3/DBD::SQLite.3pm.gz
   libdbd-sqlite3-perl: /usr/share/perl5/DBD/SQLite.pm
   libdbd-sqlite3-perl: /usr/lib/perl5/auto/DBD/SQLite
   libdbd-sqlite3-perl: /usr/lib/perl5/auto/DBD/SQLite/SQLite.bs
   libdbd-sqlite3-perl: /usr/lib/perl5/auto/DBD/SQLite/SQLite.so

and it really is there:

   $ ll /usr/share/perl5/DBD/SQLite.pm
   -rw-r--r-- 1 root root 16K Apr 18 16:20 /usr/share/perl5/DBD/SQLite.pm

I don't know much about the perl SQLite package, but it seems that git-cvsserver is not loading the correct module. The line 'use DBI;' seems to load only this module:

'DBI.pm' => '1.51 from /usr/lib/perl5/DBI.pm'

Does it need something else to load the SQLite module?

a

When things are properly installed, it should be enough to say 'use DBI' upfront and then 'DBI->connect("dbi:Foo:...")' should be enough to use DBD::Foo backend of the DBI interface.

I am on Debian etch plus some from testing and have these:

        perl (5.8.8-6.1)
        perl-base (5.8.8-6.1)
        libdbi-perl (1.51-2)
        libsqlite3-0 (3.3.7-1)
        libdbd-sqlite3-perl (1.12-1)

Does this work for you?

-- >8 -- cut here -- >8 --
#!/usr/bin/perl -w
use DBI;
my $dsn = 'dbi:SQLite:dbname=foo';
my $dbh = DBI->connect($dsn, '', '');
-- 8< -- cut here -- 8< --

If not, does it work for you if you substitute $dsn with 'dbi:mysql:dbname=test'? The error message you showed us in your earlier message said mysql was one of the backend your DBI knows about while SQLite is not.

This did not work for me before installing libdbd-sqlite3-perl and gave a very similar error message as you had.

What's puzzling is that you said you have these:

   $ dpkg -S SQLite
   libdbd-sqlite3-perl: /usr/share/man/man3/DBD::SQLite.3pm.gz
   libdbd-sqlite3-perl: /usr/share/perl5/DBD/SQLite.pm
   libdbd-sqlite3-perl: /usr/lib/perl5/auto/DBD/SQLite
   libdbd-sqlite3-perl: /usr/lib/perl5/auto/DBD/SQLite/SQLite.bs
   libdbd-sqlite3-perl: /usr/lib/perl5/auto/DBD/SQLite/SQLite.so

but that is exactly what I am seeing _after_ installing libdbd-sqlite3-perl.

Hi! all this seems to have happened during NZ's night, so I'm only catching up. +1 on all the diagnosis Junio is proposing. Can't think of anything more relevant to add. The code was developed mainly on a bunch of debian sarge/etch boxes using all the standard libdbd-sqlite-perl libs, and a gentoo box.

Actually, just looking at my etch dev box, libdbd-sqlite-perl is 0.29-1 and sqlite is 2.8.16-1. Not sure if the difference is significant. Perhaps SQLite v3 has a different invocation / driver name?

BTW, I just doublechecked, cvsserver isn't mangling the lib path in any way. However, the environment it's running under may have a strange PERL5LIB.

cheers,

martin

Yes, SQLite v2 and SQLite v3 are different and binary incompatible.

However, on Debian 'etch' you can install packages for both versions concurrently; most packages for SQLite have either a '2' or a '3' in the name. Packages without the number use the "best current choice" which is "3" in 'etch' at the moment but was "2" not too long ago.

So at this moment in Debian 'etch' SQLite3 is the default version and calling

        my $dsn = 'dbi:SQLite:dbname=foo';

will use the SQLite3 driver internally, for which you must have installed the "libdbd-sqlite3-perl" package. Just for the record, if you'd wanted the older SQLite2 version you would install the "libdbd-sqlite2-perl" package and from Perl call "my $dsn = 'dbi:SQLite2:dbname=foo';".

I'd guess that you were unfortunate enough to just install some packages during the transition and now some parts look for the "2" version and other parts for the "3" version. Probably just installing the "libdbd-sqlite3-perl" package and upgrading the other sqlite packages (from synaptic say to easily find them!) will probably cure your situation.

Incidentally I'd guess that in itself SQLite2 (so version 2) would also function perfectly well for git-cvsserver (as would PostgreSQL or MySQL), it's probably in this case just a slight version skew between packages!

Marco Roeland

Hi,

Thanks for all the help- I have it working now. It was not a fault with git-cvsserver at all- more like my own stupidity. The problem was that I had checked the versions on my client machine and forgotten to update the cvs/git server! Once I updated it and installed the libdbd-sqlite3-perl package (on the server) everything works as expected.

So, just to confirm, git-cvsserver is working on a debian testing/unstable machine (acting cvs/git server) with the following versions:

libdbd-sqlite3-perl (1.12-1)
libdbi-perl (1.51-2)
libsqlite3-0 (3.3.7-1)
perl (5.8.8-6.1)
perl-base (5.8.8-6.1)

Apologies for wasting your time, looks like my caffeine levels are getting dangerously low...

a

Thanks for the info!

I have to say though: Ouch. Do you know if there's an upgrade path for apps? Does v3 detect you've got a v2 file and do something smart (upgrade in place / spit out a readable error)?

...

Problem is that we have to help with the transition for users that started with v2 and get upgraded to v3 at the app level I suspect.

This was developed against v2. If v3 is backwards compatible, it'll just work. If not... we'll hear about it soon ;-) Pg/MySQL aren't really supported, though it wouldn't be that hard.

martin

Oh, grumble. See the comment at the bottom of
http://www.sqlite.org/formatchng.html

We may need to add something in the doco pointing to this "technique", and perhaps the URL as later versions may do something different.

I do wonder what the debian packaging does, perhaps the v3 package forces an upgrade to the v2 package that renames the cli binary? I guess the drawback of having the DBs anywhere in the FS is that the packaging can't upgrade them for you as it does with Pg for instance :(

m

On Friday September 1st 2006 at 12:07 Martin Langhoff wrote:

[warning: discussion about sqlite; no direct git serviceable parts inside!]

Applications for both v2 and v3 can work on the same machine at the same time. Both versions will not corrupt a database of the other version and will immediately stop with an error, although the error isn't very readable (doesn't mention _which_ version it saw or needed).

They do not perform an upgrade in place.

But as sqlite or sqlite3 databases are standalone files, most of the time just use the sqlite version that is standard for your platform and/or version. For new development v3 is the way to go, as v2 is in deep sleep maintenance now.

Not just the database format changed in v3, the whole API changed incompatibly.

The commandline programs are called 'sqlite' and 'sqlite3' so there is no "upgrade", you can have the two different versions simultaneously installed and working on the same machine.

Unfortunately the 'sqlite3' doesn't directly read the 'sqlite' format and neither the other way round. You can convert a database easily from the one format to the other:

$ echo .dump | sqlite database.v2.dat > dump.v2.dat
$ sqlite3 < dump.v2.dat database.v3.dat

If you don't use the new features in sqlite3 you can even convert back in the same way:

$ echo .dump | sqlite3 database.v3.dat > dump.v3.dat
$ sqlite < dump.v3.dat database.v2.dat

Use a non-existent file for the target database, and sqlite(3) will create the database for you. Do check the conversion as error reporting in the commandline tools in this "batch" mode is sometimes rather sparse or non-existent!

Once you got it finally going I find that sqlite(3) is a fast, reliable and quite handy database. Especially, as Johannes said, its standalone nature makes developing and deploying very easy.

Marco Roeland

Hi,

AFAIK Pg/MySQL/all-the-others want to have a common place where to put the database files. This is a huge disadvantage over SQLite, where you can put it anywhere you want (e.g. /blabla/.git/...). This also makes installation way easier.

Ciao,
Dscho