I'm trying to setup gitlabHQ on a Gentoo server following the steps given on the CVUT overlay page, but I'm failing on the following step.
It's been a long time I haven't work on gentoo so I'm a bit rusty.

Quote:

emerge --config "=www-apps/gitlabhq-4.0.0-r2"
Configuring pkg...

* Checking configuration files
chmod: cannot access ‘/var/lib/gitolite/repositories//.gitolite’: No such file or directory
* ERROR: www-apps/gitlabhq-4.0.0-r2 failed (config phase):
* failed to change permissions on /var/lib/gitolite/repositories//.gitolite
*
* Call stack:
* ebuild.sh, line 93: Called pkg_config
* environment, line 4732: Called die
* The specific snippet of code:
* chmod 750 "${repos_path}"/.gitolite || die "failed to change permissions on ${repos_path}/.gitolite";
*
* If you need support, post the output of `emerge --info '=www-apps/gitlabhq-4.0.0-r2'`,
* the complete build log and the output of `emerge -pqv '=www-apps/gitlabhq-4.0.0-r2'`.
* This ebuild is from an overlay named 'cvut': '/var/db/pkg/'
!!! When you file a bug report, please include the following information:
GENTOO_VM= CLASSPATH="" JAVA_HOME=""
JAVACFLAGS="" COMPILER=""
and of course, the output of emerge --info
* The complete build log is located at '/var/tmp/portage/www-apps/gitlabhq-4.0.0-r2/temp/build.log'.
* The ebuild environment file is located at '/var/tmp/portage/www-apps/gitlabhq-4.0.0-r2/temp/environment'.
* Working directory: '/var/tmp/portage/www-apps/gitlabhq-4.0.0-r2'
* S: '/var/tmp/portage/www-apps/gitlabhq-4.0.0-r2/work/gitlabhq-4.0.0'

When I check the directory /var/lib/gitolite/repositories//.gitolite didn't exists. However a directory with this name existed in the parent folder : /var/lib/gitolite/. I tried create a symlink :

I ran into this error, too, while trying out Gitlab. I'm not sure, but I think path the config script should be "chmodding" is the one to which you symlinked. My workaround was to simply create a ".gitolite" directory under repositories; this worked, and at the end of the installation, it was still empty.

After "fixing" the .gitolite issue, I got the same output as you posted above, complete with three "fatal: Not a git repo..." errors/warnings. I assumed it worked and the git warnings were not fatal.

The solution to this one is to "cp /opt/gitlab-4.0/config/unicorn.rb{.example,}" and edit it to your settings. I had to change the 'app_dir' (to /opt/gitlab-4.0/) and 'listen' settings (to the port on which I want to access GitLab).

After that I was able to access the GitLabHQ application. The default user/pass are the ones you "xxx"ed out in the output above.

If you get the following error while (re)starting, you may need to kill unicorn manually:

I’m author of this ebuild. I’ve just fixed the issue with repos_path (see cvut/gentoo-overlay#1) – .gitolite directory is under Gitolite’s home (/var/lib/gitolite by default), not repository path (/var/lib/gitolite/repositories).

These git errors (lines fatal: Not a git repository (or any of the parent directories): .git) are actually „ok“, it’s bug in bundler (see carlhuda/bundler#1787) that expects git repository in GitLab’s home. If it annoys you, simply create empty git repository (git init) under /opt/gitlab-4.0 or clone upstrem’s repository. I’ve add info message to the end of config phase.

hi i wrote the wiki.gentoo.org git page (and sudo, and rails + passenger, and others) and will next weekend adapt it for gitlab, no overlay or ebuilds required. my friend set up an ubuntu server (that acted rather corrupted) with gitlab working, so were gonna migrate it over to gentoo. just give it a little time and you'll have redundant solutions to your problem.

yes working software is better than broken ebuilds. last i checked passenger ebuild failed and long string of commands worked. gitolites ebuild messes with the git user and places your repositories in a strange location that is not compatible with git's official documentation.

You’re still using the old ebuild, new one is revision 3, i.e. www-apps/gitlabhq-4.0.0-r3 (see Gentoo Handbook for more info about ebuild names, versioning etc.) Did you updated Overlay (layman -s cvut) and reinstalled the package?

edouard.lopez wrote:

First I got an error about the default revision :

Code:

fatal: bad default revision 'HEAD'

This is most likely another false error caused by Bundler (still the same carlhuda/bundler#1787), just ignore it. If it will not be fixed soon, I’m gonna add workaround to the ebuild that will simple initialize empty git repository in GitLab’s home directory or copy actual GitLab’s repository there.

edouard.lopez wrote:

what is this login and password about ? Where would I need it ?

Do you mean user admin@local.host with default password 5iveL!fe? This is GitLab’s default admin account, you need it to log-in into GitLab for the first time…

after trashing my friends VM i built up for em, i can understand why its not supported. emerge doesnt like python 2.7, and gitlab doesnt like python 3.2. i think its possible to get everything running together in harmony, so long as you merge everything before starting on getting gitlab up. i got up to the point of databases from https://github.com/gitlabhq/gitlabhq/blob/stable/doc/install/installation.md this guide.... i know gems can run independent of portage to install goodies. im going to the restore point then going to merge everything before trying to finish off gitlab again....

I have 3.2 as default Python on my system (2.7 installed too) and don’t have any problems with GitLab (when installing from my ebuild with some patches for Gentoo, but not Python related).

To edouard.lopez:
I just realized, there’s one common issue with Gentoo and Ruby - RUBY_OPT environment variable (see /etc/env.d/10rubygems) that is set to -rauto_gem. I don’t know why is there by default, but it breaks many Ruby applications. Make sure that you have this variable empty.

However, it’s weird. I’ve installed it just few days ago without any problem. GitLab ebuild is checking if there’s git user with correct home directory according to yours GitLab settings etc. so it should be ok. Wait a moment… try to unmerge gitlab and gitolite, delete whole /var/lib/gitolite and then emerge it again. Ebuild is not re-initializing Gitolite when it’s already initialized (to not accidentally delete all your precious repositories) so if you did something wrong previously, there may be the problem. Also make sure that you’re installing dev-vcs/gitolite with USE gitlab from CVUT Overlay – GitLab has few modifications in default configuration.

Then it fecth and install tenth of gems and It finishes on the message related to each package.

However, something hit me that time :

Quote:

* Change your user ID to 'git' and run 'gitolite setup -h' to show how
* to setup Gitolite.

So, do I need to do anything about gitolite ? I was expecting the ebuild to do all the setup.

Just to be sure I checked users path in /etc/passwd :

Quote:

git:x:104:121:added by portage for gitolite:/var/lib/gitolite:/bin/sh
redis:x:75:75:added by portage for redis:/var/lib/redis:/sbin/nologin
gitlab:x:105:120:added by portage for gitlabhq:/home/gitlab:/bin/bash
gitdaemon:x:1006:121::/dev/null:/sbin/nologin

So I unmerge `gitlabhq` and `gitolite`
However, something hit me that time :

Quote:

* Change your user ID to 'git' and run 'gitolite setup -h' to show how
* to setup Gitolite.

So, do I need to do anything about gitolite ? I was expecting the ebuild to do all the setup.

This is postinstall message of gitolite ebuild (it can be used even without GitLab). While you’re using Gitolite only with GitLab, you don’t have to care about it, gitlab ebuild initializes gitolite for you.

Quote:

git:x:104:121:added by portage for gitolite:/var/lib/gitolite:/bin/sh
redis:x:75:75:added by portage for redis:/var/lib/redis:/sbin/nologin
gitlab:x:105:120:added by portage for gitlabhq:/home/gitlab:/bin/bash
gitdaemon:x:1006:121::/dev/null:/sbin/nologin

There’s the problem! The ebuild installs GitLab to /opt/gitlab-4.0 and it should be gitlab’s user home directory as well (ebuild take care of it of course, but not when gitolite user already exists). Sure, that you can change this as you want, but did you actually? If not, change this to /opt/gitlab-4.0, move .ssh and .gitconfig to /opt/gitlab-4.0, erase /var/lib/gitolite and then run emerge --config once again. I’m almost sure that it will work now. (I should add check for gitlab home directory to ebuild.)

edouard.lopez wrote:

And get the same issue : [list][*]prompt is asking for a password (but who/for what ?) ;

In this phase, GitLab is trying to pull from Gitolite (repo gitolite-admin.git) and should be authenticated with its SSH key. However, as you see, this fails so Gitolite (more precisely, SSHd daemon) asks for password instead.

In pkg_postinst phase, ebuild generates SSH key for gitlab user and stores it in DEST_DIR, i.e. /opt/gitlab-4.0/. The key is then used in Gitolite as the admin key (during gitolite initialization in pkg_config phase). The problem is that SSH client is looking into ~/.ssh for the key be default, but you’re gitlab’s home directory is /home/gitlab, not /opt/gitlab-4.0 where is the key!

I got the following statement (I put everything so it can help you prevent error):

Quote:

Configuring pkg...

* Checking configuration files
* Gitolite's repos_path from gitlab.yml is not in the HOME of
* git user in passwd
* ERROR: www-apps/gitlabhq-4.0.0-r3 failed (config phase):
* (no error message)
*
* Call stack:
* ebuild.sh, line 93: Called pkg_config
* environment, line 4713: Called die
* The specific snippet of code:
* die;
*
* If you need support, post the output of `emerge --info '=www-apps/gitlabhq-4.0.0-r3'`,
* the complete build log and the output of `emerge -pqv '=www-apps/gitlabhq-4.0.0-r3'`.
* This ebuild is from an overlay named 'cvut': '/var/db/pkg/'
!!! When you file a bug report, please include the following information:
GENTOO_VM= CLASSPATH="" JAVA_HOME=""
JAVACFLAGS="" COMPILER=""
and of course, the output of emerge --info
* The complete build log is located at '/var/tmp/portage/www-apps/gitlabhq-4.0.0-r3/temp/build.log'.
* The ebuild environment file is located at '/var/tmp/portage/www-apps/gitlabhq-4.0.0-r3/temp/environment'.
* Working directory: '/var/tmp/portage/www-apps/gitlabhq-4.0.0-r3'
* S: '/var/tmp/portage/www-apps/gitlabhq-4.0.0-r3/work/gitlabhq-4.0.0'

I thought passenger was a Nginx module, so why does it talk about Apache then ?

Quote:

Powered by Phusion Passenger, mod_rails / mod_rack for Apache.

Passenger is for nginx and Apache2 as well. How did you install Passenger? Did you used my nginx ebuild with added Passenger module?
It should work with Passenger’s installer script as well, but I’ve never installed it this way and don’t recommend it (we’re using package managers for reason). I’m using nginx with Passenger on many servers so it really should work for you as well (I hope so). If not, I’m gonna ask you for access to your server, ’cause it’s nearly impossible how many problems you’ve hit. XD

i started it, and it looks like someone else finished it.... ill be testing this all the way later on tonight..... before i ran into problems on the ruby gem package section... (around 6.7 on the official page)

# if a file, which is not found in the root folder is requested,
# then the proxy pass the request to the upsteam (gitlab unicorn)
location @gitlab {
proxy_read_timeout 300; # https://github.com/gitlabhq/gitlabhq/issues/694
proxy_connect_timeout 300; # https://github.com/gitlabhq/gitlabhq/issues/694
proxy_redirect off;

i got 4.2 up tonight through apache + passenger, and conversion from debian / ubuntu install instructions. ruby 1.9.3xxx mysql 5.2 apache 2.2 its very rough on the wiki so far, ill probably have it polished enough for web users in 2 weeks time. as of right now it has database problems in the write up, requires a production database to get up, but it also has entries for dev and test databases, and clients were reporting read/write problems. im giving up for the night though. my biggest problem, was pretty much exactly what spawned this thread...