2

I'm trying to install Gitolite on my Synology DiskStation, following these instructions.

Under Install Gitolite on the DiskStation and Run Setup, when I run the Gitolite install command:

DiskStation> /volume1/homes/git/gitolite/install -ln /bin

I get the following error:

FATAL: have errors but logging failed!

2012-05-31.00:10:22 no GL_LOGFILE env var
2012-05-31.00:10:22 die could not symlink /volume1/home/git/gitolite/src/gitolite to /bin<<newline>> at /volume1/home/git/gitolite/install line 71<<newline>>

I am very new to all of this. Does anyone know what this means, and how I can fix this error?

3 Answers 3

1

2 issues:

The new GitoliteV3 (g3) doesn't handle gracefully the lack of a 'logs' directory, which should be present by default in $HOME/.gitolite.
See Rc.pm:

$rc{LOG_TEMPLATE} = "$ENV{HOME}/.gitolite/logs/gitolite-%y-%m.log";
$rc{GL_LOGFILE} = $ENV{GL_LOGFILE} ||= gen_lfn( $rc{LOG_TEMPLATE} );

Common.pm:

sub gl_log {
    # the log filename and the timestamp come from the environment. If we get
    # called even before they are set, we have no choice but to dump to STDERR
    # (and probably call "logger").

    logger_plus_stderr( "$ts no GL_LOGFILE env var", "$ts $msg" ) if not $ENV{GL_LOGFILE};
    open my $lfh, ">>", $ENV{GL_LOGFILE} or logger_plus_stderr( "open log failed: $!", $msg );

Create a logs directory: mkdir -p $HOME/.gitolite/logs and relaunch the installation.
As sitearm (who, I can only assume from his empty profile, is Sitaram Chamarty, the creator/maintainer of Gitolite), this shouldn't be needed.
And from the OP's answer below, this wasn't needed anyway.

sitearm adds:

The LOGFILE error message is misleading; it happens when the installation directory is not in $PATH.

The latest commit on Common.pm (June, 16th 2012) has indeed replaced the error message in order to not reference anymore the mysterious GL_LOGFILE:

logger_plus_stderr( "errors found before logging could be setup", "$msg" ) if not $ENV{GL_LOGFILE};

Note that if you have your own perl in a non-standard path, none of those install scripts will work, since their shebang references /usr/bin/perl instead of a /usr/bin/env perl...


Second issue:

could not symlink /volume1/home/git/gitolite/src/gitolite to /bin

Check if you have the rights to symlink in /bin. Are you root? As mentioned below

DiskStation> /volume1/homes/git/gitolite/install -ln

(without /bin) would keep everything under $HOME (no /bin writing access issue)


I generally prefer a local installation

 $HOME/gitolite/github/install -to $HOME/gitolite/bin

(so '-to' instead of '-ln', with an absolute path in my account rather than a system path) with:

  • github the name of the local clone of https://github.com/sitaramc/gitolite
  • $HOME/gitolite/bin a directory that I have added to my $PATH.
2
  • Please do not suggest solutions that involve anything that is not in the documentation. mkdir -p ... is one such well-meaning but wrong suggestion. If you think it is required, let me know my documentation is missing something and we can discuss it. The LOGFILE error message is misleading; it happens when the installation directory is not in $PATH. Please run ./install -h for details on various options on this.
    – user140534
    Jun 16, 2012 at 13:16
  • @sitaram ok, answer edited. the mkdir is the least of my issues with g3: all your scripts reference a #!/usr/bin/perl, which is incompatible with my non-standard perl installation. A #!/usr/bin/env perl would be more convenient.
    – VonC
    Jun 17, 2012 at 13:13
0

The following command was a typo:

DiskStation> /volume1/homes/git/gitolite/install -ln /bin

Earlier in the post it has you setup a $HOME/bin directory for the git user. Run the same command but leave the specified /bin directory argument off, and gitolite will default to $HOME/bin which exists and is writeable by the git user.

Run this instead:

DiskStation> /volume1/homes/git/gitolite/install -ln
0

I ran the command gitolite/install -ln /usr/bin/

For me, the symlink error was due to the git user not having the requisite permissions to symlink to /usr/bin. I simply added the git user to wheel group in /etc/group file and that worked like a charm.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .