problem with git-cvsserver

problem with git-cvsserver

[aonghus]

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

Re: problem with git-cvsserver

[Johannes Schindelin]

Hi,

On Wed, 30 Aug 2006, aonghus wrote:

>    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.
>
> [...]
> 
>    libdbd-sqlite3-perl: /usr/share/perl5/DBD/SQLite.pm

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

Re: problem with git-cvsserver

[aonghus]

Johannes Schindelin wrote:
> Hi,
>
> On Wed, 30 Aug 2006, aonghus wrote:
>
>   
>>    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.
>>
>> [...]
>>
>>    libdbd-sqlite3-perl: /usr/share/perl5/DBD/SQLite.pm
>>     
>
> 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

Re: problem with git-cvsserver

[Junio C Hamano]

aonghus <thecolourblue@gmail.com> writes:

> 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?

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.

Re: problem with git-cvsserver

[Martin Langhoff]

On 8/31/06, Junio C Hamano <junkio@cox.net> wrote:

> 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< --

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

Re: problem with git-cvsserver

[Marco Roeland]

On Thursday August 31st 2006 at 08:29 uur Martin Langhoff wrote:

> [git-cvsserver and trouble with Perl DBI and SQLite]
> 
> 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?

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

Re: problem with git-cvsserver

[aonghus]

Marco Roeland wrote:
> On Thursday August 31st 2006 at 08:29 uur Martin Langhoff wrote:
>
>   
>> [git-cvsserver and trouble with Perl DBI and SQLite]
>>
>> 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?
>>     
>
> 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!
>   

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

 

Re: problem with git-cvsserver

[Martin Langhoff]

On 8/31/06, Marco Roeland <marco.roeland@xs4all.nl> wrote:
> 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.

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)?

...

> I'd guess that you were unfortunate enough to just install some packages
> during the transition

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.

> Incidentally I'd guess that in itself SQLite2 (so version 2) would also
> function perfectly well for git-cvsserver (as would PostgreSQL or
> MySQL)

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

Re: problem with git-cvsserver

[Johannes Schindelin]

Hi,

On Fri, 1 Sep 2006, Martin Langhoff wrote:

> Pg/MySQL aren't really supported, though it wouldn't be that hard.

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

Re: problem with git-cvsserver

[Martin Langhoff]

On 9/1/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> 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)?

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

Re: problem with git-cvsserver

[Marco Roeland]

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

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

> >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)?

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.

> 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
> :(

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