Package Details: gitlab 8.7.0-2

Git Clone URL: https://aur.archlinux.org/gitlab.git (read-only)
Package Base: gitlab
Description: Project management and code hosting application
Upstream URL: http://gitlab.org/gitlab-ce
Licenses: MIT
Submitter: onny
Maintainer: Lopo (caleb)
Last Packager: Lopo
Votes: 83
Popularity: 2.628751
First Submitted: 2013-08-27 19:16
Last Updated: 2016-04-25 13:40

Dependencies (16)

Required by (0)

Sources (16)

  • apache-ssl.conf.example
  • apache.conf.example
  • apache2.2-ssl.conf.example
  • apache2.2.conf.example
  • gitlab-8.7.0.tar.gz
  • gitlab-backup.service
  • gitlab-backup.timer
  • gitlab-mailroom.service
  • gitlab-sidekiq.service
  • gitlab-unicorn.service
  • gitlab.logrotate
  • gitlab.target
  • gitlab.tmpfiles.d
  • lighttpd.conf.example
  • nginx-ssl.conf.example
  • nginx.conf.example

Latest Comments

twiggers commented on 2016-04-25 12:39

I'm now getting these errors:

/usr/share/webapps/gitlab/config/application.rb:7:in `require_relative': cannot load such file -- /etc/webapps/lib/gitlab/redis (LoadError)

Lopo commented on 2016-04-22 07:34

@caleb np, until now I've updated them manually using /usr/bin/sha512sum

caleb commented on 2016-04-22 07:26

Hey @Lopo would you mind updating whatever routine you use for updating checksums to use `/usr/bin/updpkgsums` that comes with pacman instead? We keep pushing whitespace back and forth and standardizing on how Arch handles this upstream seems like the best way to avoid that.

axil42 commented on 2016-04-14 14:18

Yeah, the wiki definitely needs an update. I'll see to find some time and refactor it. That'll give me the chance to play with this package, never tried it.

mentatf commented on 2016-04-13 17:34

I don't really want to do the installation from source (I'm not an experimented user). What I would like to do is install gitlab from scratch with https and access it either through the website with https://gitlab.example.com, either through CLI (git clone https://gitlab.example.com/...). The host is the same for gitlab, the database and the webserver.

I'd like everything to be served through an nginx webserver. And I'd prefer to use this package since it's easier to maintain.

But the arch wiki looks obsolete and I'm trying to find the proper config by myself, by mixing the how-to of the wiki, with the official documentation, the comments below, and the default nginx config included in the AUR package.

But the more I try, the less I understand, what goes where on what port or through what socket. I don't understand at all the lines:

upstream gitlab {
server localhost:8080 fail_timeout=0;
}

and

root /dev/null;

in the wiki, and I don't know how to adapt the config bundled in the package as I don't understand what to replace the sockets with...

I wouldn't thank you enough for clarifying the wiki in this regard.

caleb commented on 2016-04-13 07:47

@mentatf If you want to install from sources yourself you are welcome to, but there is a whole host of decisions you'll have to make to decide how to adapt it to an Arch based system (where you want to keep things, how closely you want it to work with systemd vs. the default of ignoring it, etc.).

The migration guides for major and minor version bumps are always here:

https://gitlab.com/gitlab-org/gitlab-ce/tree/master/doc/update

Patch versions are always the same procedure:

https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/update/patch_versions.md

mentatf commented on 2016-04-12 19:28

Would it work to follow the official config setup, for instance here: http://doc.gitlab.com/ce/install/installation.html#installation-from-source

Followup question: how to you find a link to the official guide related to a previous version ? I can't find the guide for 8.6.5 (current aur package).

onny commented on 2016-04-12 10:26

There seems to be a packaging issue according to the Gitlab devs, see here: https://gitlab.com/gitlab-org/gitlab-workhorse/issues/37

Further you should use the more recent nginx config examples bundled in the gitlab tarball: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/support/nginx/gitlab

Thanks for maintaining!
Regards,
Jonas

caleb commented on 2016-04-12 09:06

@Lyce chmod 777 should _never_ be even in your toolbox to try, you're doing it wrong. If the systemd enforced permission scheme is working and other daemons are doing what they should that would _break_ the system not fix it.

Upgrading Gitlab is a regular pain in the butt, but it's not the fault of this package. The way the upstream project handles this is just much less than ideal for installation on a non-containerized host. Please make sure you've read the release notes and upgrade guide for _EACH_ version between the one you upgraded from and the current one. You can't always just go from W→Z, you need to take the steps they detail to get from W→X→Y→Z. This package doesn't take care of all possible upgrade scenarios, although it is doing a better job than it used to of getting from point release to point release without breaking things. For example the default rake commands for database format updates and cache clears are getting called, but you still need to make sure you follow along with the upstream notes.

caleb commented on 2016-04-12 08:59

@hunger I thought about calling for the mailroom service from the gitlab target, but as this only handles _incoming_ mail and some systems may not be equipped for that I didn't want to break people's upgrade process. As that's an optional service I figured people can enable it if they want it.

I also thought about but wasn't sure on the security features for other services. I tried enabling them on my system and stuff broke. As I didn't have time to figure out _why_ they broke I didn't commit those changes in my last tweaks. If you try if and figure out which limits can be places on which services I'd be willing to verify the results on my install.

Lyce commented on 2016-04-11 21:16

So. Recently upgraded, as I've done _MULTIPLE_ times in the past.

New project -> everything works perfectly fine.
Project from previous version -> 'The repository for this project does not exist.'

Same repo path, same folder structure, same permissions, same god damn file names.
Hell, I even 777'd EVERY. SINGLE. MOTHERF- in the repo folder. But nah. Doesn't work.

Someone explain this bullshit to me before I lose my shit.

hunger commented on 2016-04-09 09:58

Can you also turn on the security features found in the other services?

Didn't gitlab-sidekiq trigger the mail-code before? Does its unit need modifications now to not do that anymore? Can you now enable NoNewPriviliges=true in gitlab-sidekiq.service now or does that still send mails?

hunger commented on 2016-04-09 09:48

How is gitlab-mailroom.service triggered?

Shouldn't the gitlab.target want that?

mentatf commented on 2016-04-08 15:32

I try to create a new gitlab install, but the instructions are unclear, maybe I'm not doing things right but the wiki doesn't look well updated, especially concerning the nginx config i'm interested in:
- the file shell.yml mentionned for https doesn't exist
- what is /dev/null in the nginx config from the wiki ?
- what is resque.target ? the unit doesn't exist for me.
Why is the nginx recipe given by the official installation guide that complicated, but that simple for this wiki page ? If you have a working nginx config I'd be interested to see the how-to.

orbifx commented on 2016-03-31 08:38

@axil42: I noticed that after asking the question. I had copied pasted twiggers' code, but then found another post with the correct name.

All works now, thanks.

PS: Turns out weights are only for enterprise edition :(

axil42 commented on 2016-03-31 06:53

@orbifx it's 'pg_trgm'. Look at the order of the letters 'rg', you have 'gr'.

orbifx commented on 2016-03-30 16:15

If this is related to needing the "pg_tgrm" extension, psql tells me this extension doesn't exist?!

orbifx commented on 2016-03-30 16:07

Has anyone come across the internal error (500)? Any ideas?

ActionView::Template::Error (undefined method `main_language' for #<Project:0x0000000612c680>):
28: = project.name
29:
30: .controls
31: - if project.main_language
32: %span
33: = project.main_language
34: - if ci_commit
app/views/shared/projects/_project.html.haml:31:in `block in _app_views_shared_projects__project_html_haml___2849907815792411827_47936740'
app/views/shared/projects/_project.html.haml:14:in `_app_views_shared_projects__project_html_haml___2849907815792411827_47936740'
app/views/shared/projects/_list.html.haml:16:in `block in _app_views_shared_projects__list_html_haml___795613533982587609_51138760'
app/views/shared/projects/_list.html.haml:14:in `_app_views_shared_projects__list_html_haml___795613533982587609_51138760'
app/views/dashboard/projects/_projects.html.haml:1:in `_app_views_dashboard_projects__projects_html_haml__718267727617775421_51183980'
app/views/dashboard/projects/starred.html.haml:10:in `_app_views_dashboard_projects_starred_html_haml___4200266926739221071_52154860'
app/controllers/dashboard/projects_controller.rb:40:in `starred'
lib/gitlab/middleware/go.rb:16:in `call

wangfengfight commented on 2016-03-29 21:51

@rzomatz, do not use the orphaned package ruby-2.1, ruby2.1 is the right one.

thelinuxguy commented on 2016-03-29 17:36

ruby2.1 is not orphaned and it's building fine here

tzomatz commented on 2016-03-29 16:26

Ruby2.1 is orphaned, and it is not compilling anymore.

Correction: It does build with yaourt for some reason.

axil42 commented on 2016-03-28 12:06

About pg_trgm and any other changes requiring manual configuration on each update, I urge you to take a look at the blog post of each release on 22nd every month. It's under the Upgrade barometer section. https://about.gitlab.com/2016/03/22/gitlab-8-6-released/

melvinvermeeren commented on 2016-03-26 09:42

@twiggers it did print out some information regarding this during the database updating phase in the update, but this was only really readable if you read the full output log gitlab throws at you when upgrading.

Perhaps it is an idea to add an install message or something similar.

twiggers commented on 2016-03-26 09:24

FYI, I had to upgrade postgresql to 9.5 and `CREATE EXTENSION pg_trgm;' in the gitlabhq_production database for upgrade to work.

I was getting this error:

NoMethodError (undefined method `external=' for #<User:0x00000006cc75d0>):
app/controllers/sessions_controller.rb:21:in `new'
lib/gitlab/middleware/go.rb:16:in `call'

str_t commented on 2016-03-23 17:37

FWIW, the error occurs at application.rb, found in /etc/webapps/gitlab/.

The file does a require_relative there. This should probably be patched to
require '/usr/share/webapps/gitlab/lib/gitlab/redis_config'

EDIT: I manually patched my config according to my comment, and everything seems to be working now. I had to re-run migrations and asset compilation manually, though.

melvinvermeeren commented on 2016-03-23 17:34

EDIT: Basically same issue as str_t below me.

Upon updating to 8.6.0 I get the following error.

/usr/share/webapps/gitlab/config/application.rb:7:in `require_relative': cannot load such file -- /etc/webapps/lib/gitlab/redis_config (LoadError)

There is no file called "redis_config" anywhere on my system, haven't checked with .rb or any extension however.

Reinstalling all gitlab-related packages changes nothing. Might be a packaging issue.

Downgrading to 8.5.7 for now.

str_t commented on 2016-03-23 17:26

8.6.0-1 broke for me.

(1/1) upgrading gitlab [#############] 100%
warning: /etc/webapps/gitlab/gitlab.yml installed as /etc/webapps/gitlab/gitlab.yml.pacnew
warning: directory permissions differ on /var/lib/gitlab/builds/
filesystem: 770 package: 755
warning: directory permissions differ on /var/lib/gitlab/satellites/
filesystem: 770 package: 755
rake aborted!
LoadError: cannot load such file -- /etc/webapps/lib/gitlab/redis_config
/usr/share/webapps/gitlab/config/application.rb:7:in `require_relative'
/usr/share/webapps/gitlab/config/application.rb:7:in `<top (required)>'
/usr/share/webapps/gitlab/Rakefile:5:in `require'
/usr/share/webapps/gitlab/Rakefile:5:in `<top (required)>'
(See full trace by running task with --trace)
D, [2016-03-23T12:14:03.636543 #28164] DEBUG -- : ** [Raven] Event not sent due to excluded environment: production
rake aborted!
LoadError: cannot load such file -- /etc/webapps/lib/gitlab/redis_config
/usr/share/webapps/gitlab/config/application.rb:7:in `require_relative'
/usr/share/webapps/gitlab/config/application.rb:7:in `<top (required)>'
/usr/share/webapps/gitlab/Rakefile:5:in `require'
/usr/share/webapps/gitlab/Rakefile:5:in `<top (required)>'
(See full trace by running task with --trace)
D, [2016-03-23T12:14:14.130001 #28286] DEBUG -- : ** [Raven] Event not sent due to excluded environment: production
New optional dependencies for gitlab
gitlab-workhorse=0.7.1: for http(s) access [installed]

mfc_alpha commented on 2016-03-17 13:08

Webserver configuration file example have been updated and simplified on the upstream repo :
https://gitlab.com/gitlab-org/gitlab-recipes/tree/master/web-server/apache

Netrix commented on 2016-03-13 15:18

Could you write an instructions how to do it in not invasive way to arch package ?

Ok, I just answer myself.

In my case I just reinstalled ruby2.1 from AUR and it recompiled the ruby with openssl thus I have no error now.

melvinvermeeren commented on 2016-03-10 14:20

@guycook Try to recompile ruby2.1, it was needed for me after the recent OpenSSL update.

guycook commented on 2016-03-10 03:48

I'm struggling to build the current package while upgrading 8.5.1 -> 8.5.4. Here's the output:

==> Starting build()...
==> Fetching bundled gems...

Could not load OpenSSL.
You must recompile Ruby with OpenSSL support or change the sources in your Gemfile from 'https' to 'http'. Instructions for compiling with OpenSSL using RVM are available at http://rvm.io/packages/openssl.
==> ERROR: A failure occurred in build().

This is a bit confusing as
a) the only version of ruby I have installed is the ruby2.1 dependency of this package
b) my current /usr/share/webapp/gitlab/Gemfile uses the https source, and everything is working fine with my current Gitlab installation

Any idea where I might have gone wrong here?

bayi commented on 2016-03-05 00:53

Nope, dont have any socket its using ports to communicate, sorry that im posting here, but upstream wont help and im out of ideas.

Here is what i have checked now:

workhorse is started with default parameters:
-authBackend http://127.0.0.1:8080 /var/lib/gitlab/repositories

so no socket from workhorse side, the default port for 8080 (gitlab) 8181 (workhorse) are open.

gitlab socket created with gitlab:gitlab 777

orbifx commented on 2016-03-04 18:44

I suspect gitlab-workhorse.

Check that the socket has the right permissions, I remember that being an issue.

bayi commented on 2016-03-04 18:13

Anybody knows what could i do to get the "download as zip" feature working ?
I only receive a JSON, i had this earlier but it was fixed with editing the apache config files and if i google this issue i only receive this answer but it isnt working for 8.5 anymore ( it worked before with 8.2 for example )

What i did:
Installed gitlab-workhorse
Edited apache vhost config to forward everything to port 8181 (where workhorse is running)
Just verified, workhorse is running and listening on 8181

did i missed something ?

axil42 commented on 2016-02-26 22:54

Ruby 2.2 was to be shipped with 8.5 but had issues, so upstream reverted to 2.1.8 again, see https://gitlab.com/gitlab-org/gitlab-ce/issues/13514

As for Ruby 2.3 https://gitlab.com/gitlab-org/gitlab-ce/issues/12507

hunger commented on 2016-02-24 19:52

Please do not change over to ruby: I do try that sometimes and it does *not* work reliably for me.

Ok, most things works, but mails do not work for me, gitlab-shell does not always trigger updates and things like that. Plus you are completely alone as upstream will just tell you to downgrade ruby and try again.

caleb commented on 2016-02-24 14:29

@radu Most functions of Gitlab will work on newer Ruby, but not all. You won't notice the brokenness at first but behind the scenes various things are not actually working at it will eventually get you in trouble. Until the upstream software is actually updated to fully support (rather than just happening to mostly work on) the current version we're kind of stuck using Ruby 2.1 (and you would be well advised to use it as well. Believe me, I tried going down the same road you did substituting current versions in this package and even though it seemed to work at first it eventually burned me.

thelinuxguy commented on 2016-02-24 14:18

@radu: I highly doubt you ran the tests and or checked every function of gitlab!
as noted in their dependencies https://github.com/gitlabhq/gitlabhq/blob/master/doc/install/installation.md#2-ruby only 2.1.x is supported. If you really think it works with 2.3.x contact upstream and let them change it.

radu commented on 2016-02-24 08:37

@Lopo Why is it using 'ruby-2.1' package? I changed to 'ruby' package and it works with the latest version of ruby. Please change to 'ruby' and also include armv7h in the architectures.

hunger commented on 2016-02-23 18:50

Please keep ProtectSystem=full :-)

http://pastebin.com/t3daCMw1 moves the builds directory into /var (to the other writeable directories) instead.

(SHAsums need to be updated after applying this patch)

caleb commented on 2016-02-20 15:45

The `ProtectSystem=full` line in the service file for this breaks the CI system which needs write access to ~gitlab/builds in order to store logs posted back from runners. The "full" setting marks /usr read-only, which is where gitlab's homedir is.

melvinvermeeren commented on 2016-02-13 10:48

@axil42 That worked, thanks a bunch.

In the new config all traffic passes through workhorse instead of filtering with mod_rewrite, works ok so far.

axil42 commented on 2016-02-13 05:46

@melvinvermeeren There is a fix on this I think, see https://gitlab.com/gitlab-org/gitlab-recipes/commit/fe1bb890a60a3bfcb8a7b28b3aca2f83e08ef98b

Update your config https://gitlab.com/gitlab-org/gitlab-recipes/tree/master/web-server/apache

melvinvermeeren commented on 2016-01-31 19:56

I'm having problems when browsing the tree of a repository if there are spaces in the path. Basically, as soon as there is a space in the path, HTTP code 400 (Bad Request) is returned.

Can't find anything about this problem online. Using Apache with up-to-date configuration. The logs don't give me anything useful either.

Anyone else experiencing this problem?

FallenSnow commented on 2016-01-15 04:06

@Lopo alright I'll take your word for it.

Lopo commented on 2016-01-09 11:45

@FallenSnow: 1st - I'm the maintainer, not caleb ... 2nd - yes, there is ... the version is explicitly defined int GITLAB_SHELL_VERSION, in history there were problems with another as defined version

FallenSnow commented on 2016-01-09 04:48

@caleb is there a reason you can't set gitlab-shell>=2.6.9 instead of gitlab-shell=2.6.9? It would make upgrading via yaourt seamless.

wangfengfight commented on 2015-12-30 17:35

@niqingliang2003, the "network" view has been moved into "commits"

niqingliang2003 commented on 2015-12-27 02:23

I installed the gitlab on a new pc, but there is not 'network' on the left side in project page. is it bug?

niqingliang2003 commented on 2015-12-25 17:23

@caled maybe:
the apache conf.example is not compatible with workhorse service's default args.

niqingliang2003 commented on 2015-12-25 15:51

@caleb there is not log for workhorse, I checked all /var/log/gitlab/*, can't get any new items for clone failure.


original problem:
after upgrade, can't clone through http, 'The requested URL returned error: 503'.

the workaround is edit /usr/lib/systemd/system/gitlab-workhorse.service.
remove the arguments of workhorse but the repository directory.

WHY?

lnicola commented on 2015-12-23 07:17

There are some issues with the systemd config for gitlab-sidekiq:

ExecStart=/usr/bin/bundle-2.1 exec "sidekiq -q post_receive -q mailer -q system_hook -q incoming_email -q project_web_hook -q gitlab_shell -q common -q default -q archive_repo -e production -L /var/log/gitlab/sidekiq.log >> /var/log/gitlab/sidekiq.log 2>&1"

1. The mailer queue name is wrong, which breaks sending emails; it should be "mailers".

2. sidekiq.log is used both with the -L parameter and a shell redirection, which is probably a bad idea since there will be two writers for that file.

tzomatz commented on 2015-12-12 23:14

@lopo: Good point. Maybe we should feature request that. Or patch it, Go isnt a particularly hard language.

axil42 commented on 2015-12-11 22:28

About Nginx, hold your horses! https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/2073

Lopo commented on 2015-12-11 06:20

@tzomatz: do you see some support for config files in the gitlab-workhorse sources ? I see only cmdline args parsing ...

@thelinuxguy: https://github.com/Lopo/archlinux-packages, but the nginx cfg files are from https://github.com/gitlabhq/gitlabhq/tree/master/lib/support/nginx

thelinuxguy commented on 2015-12-10 20:50

The nginx files are not directly compatible with the package. I'm happy to submit a MR if you tell me where I can do that

tzomatz commented on 2015-12-10 18:03

Why does not gitlab workhorse have a config file? Isnt it rather stupid to actually have to edit the service file?

Or isnt gitlab workhorse meant to be ran as a daemon?

Salamandar commented on 2015-12-05 18:49

Hi there.
Is icu55 really necessary ? That means compiling the pkg from source instead of using the (often already installed) icu package.
Moreover the compilation doesnt pass with only 512mo RAM, such as on a raspberry pi.

caleb commented on 2015-12-05 10:27

Lopo I'd have to agree with @Mic92 here. First, the systemd unit should be on the other package (see comment and AUR gitlab-workhorse). And systemd should be allowed to manage the process directly not through some secondary process management wrapper.

How can we configure the backend port variable that needs to get passed so the service can run on another machine (or some other port as 8080 is a regular conflict with other generic defaults)?

Mic92 commented on 2015-12-05 10:24

First of all great thanks for packaging gitlab!

I would structure gitlab-workhorse.service differently.
- Services files do not support redirection:
`> /var/log/gitlab/gitlab-workhorse.log`
will never work.
- I would discourage the use of this daemon script as it does provide any additional benefit

I use the following now:

```
[Unit]
Description=Gitlab Workhorse
Requires=gitlab-unicorn.service
Wants=gitlab-unicorn.service
After=gitlab-unicorn.service

[Service]
User=gitlab
Group=gitlab
WorkingDirectory=/usr/share/webapps/gitlab
ExecStart=/usr/bin/gitlab-workhorse -listenUmask 0 -listenNetwork unix -listenAddr /var/lib/gitlab/sockets/gitlab-workhorse.socket -authBackend http://127.0.0.1:8080 /var/lib/gitlab/repositories

[Install]
WantedBy=multi-user.target
```

thelinuxguy commented on 2015-12-04 21:06

So I upgraded gitlab from 8.0.3 directly to 8.2.2
Everything seemed to work. Except for creating new users as an admin. Submitting the form results in an empty page. Also changing the user attributes doesn't work.
Anyone run into this issue?

tzomatz commented on 2015-12-03 19:31

Maybe you could try to redownload all the gems, and compile the assets again?

It worked for me when i uninstalled everything and followed the guide on the wiki in regards to redownloading the gems, and compiling the assets again. Remeber to save the config files though.

Therefore I see no reason why it should not work for you. Assuming you are running current and not testing..

asrenzo commented on 2015-12-03 15:51

Hi,

I updated my system first with pacman. MariaDB was updated.
Then I updated gitlab-shell with no deps check throught yaourt
Then I updated gitlab with yaourt.

Now, everything is broken with this error : Incorrect MySQL client library version! This gem was compiled for 10.0.22-MariaDB but the client library is 10.1.9-MariaDB

gitlab:env:info will fail,
gitlab:check will fail,

Any idea to clean this ?

Regards,

Laurent

tzomatz commented on 2015-12-03 00:06

Just updated. No errors.

Had to uninstall and reinstall because of a circular dependency between gitlab and gitlab-shell though.

push and pull works both over ssh and http.

caleb commented on 2015-12-02 09:39

@lynxcore I don't think that is necessary. If you update MariaDB first _then_ update or re-install gitlab thy issue with versions will correct itself. You only had that issue because you updated your system after gitlab compiled that library against your system libraries.

The issue with workhorse is also something else I believe. @niqingliang2003 do you have any log information from the workhorse service? What was the status of the service for you?

lynxcore commented on 2015-12-02 09:33

@niqingliang2003:
You can safely upgrade the gem that keeps unicorn from starting with a newer libmariadbclient version:

cd /usr/share/webapps/gitlab
sudo -u gitlab /usr/bin/gem-2.1 install activesupport

This is not really a solution, but an ugly workaround, as far as I'm concerned, since I don't know if a newer activesupport version will lead to problems with gitlab, but so far, I haven't noticed any problems.

Apparently that solves the clone-over-http problem, too, or at least I don't have that problem. Didn't check before I installed activesupport 4.2.5, though.

niqingliang2003 commented on 2015-12-01 06:53

after upgrade, can't clone through http, 'The requested URL returned error: 503'.

the workaround is edit /usr/lib/systemd/system/gitlab-workhorse.service.
remove the arguments of workhorse but the repository directory.

WHY?

niqingliang2003 commented on 2015-12-01 05:52

I think we should update the example files

niqingliang2003 commented on 2015-12-01 05:47

do we must have the same version mariadb as compiling environment for running gitlab?

the gitlab-unicorn, gitlab-sidekiq can't start after upgrade system, which looks like the mariadb is the reason.

wangfengfight commented on 2015-12-01 00:11

I think the dependency icu55 can be removed

axil42 commented on 2015-11-30 17:13

> It looks like the apache related conf file is still for 6.x, do we need update them?

Yes. See the upstream repo: https://gitlab.com/gitlab-org/gitlab-recipes/tree/master/web-server/apache

francoism90 commented on 2015-11-30 15:54

Thanks Lopo for updating! :)
Will try the new version this or next week.

niqingliang2003 commented on 2015-11-30 04:03

It looks like the apache related conf file is still for 6.x, do we need update them?

Lopo commented on 2015-11-28 06:36

@francoism90: probably this weekend

francoism90 commented on 2015-11-27 15:50

@Lopo: when will all the GitLab in AUR be upgraded to the latest?
Thanks! :)

twiggers commented on 2015-11-25 10:43

If you're having trouble running this (8.0) build, that's because it's dependent on icu 0.55. You can get that from aur/icu55

Lopo commented on 2015-11-24 09:35

I pushed 8.2 branch to caleb's github repo for testing ... i tested it with https://gist.github.com/Lopo/2724a98bd9945e59cd77 version of workhorse

if there's no problems, i'll push it into aur

Lopo commented on 2015-11-20 12:40

@caleb: thx for offer and a good will ... i'll commit today to the github repo all modifications that i have actually prepared to enable testing for all interested

@axil42: tell to all the dev of gitlab, that (not only we) need a bit more stability, not so drastic changes so often (think twice, cut once)

axil42 commented on 2015-11-20 09:23

+1 being a co-maintainer. That was the whole point this feature got introduced in AUR.

If you need anything to ease out with the packaging let me know. I have write access in the upstream repos.

caleb commented on 2015-11-20 07:36

Lopo I understand this package is a pain in the butt and dealing with the upstream's resistance to bare-metal installs and constant churn in their stack is a lot of trouble. But I also realize that Gitlab is central to a lot of people's workflow and keeping up to date is important. I've been getting a ton of email from folks using my cobbled together updates because your package is just too out of date. Being perpetually a month or two behind the release schedule is not okay, and this isn't the first cycle that has been problematic.

I don't really want to take over maintenance of this by myself (for reasons of it being such a pain in the butt) but we do need to improve things for everybody using that package. One way to do that is invite more collaboration. This is open-source after all.

I have two requests/suggestions:

1. Add me as a co-maintainer to this package. That way whichever of us has time available can get this fixed up and I don't have to think about maintaining a separate package. I'm already getting too many support requests for people switching to my packaging even though it isn't really finished. I'd rather keep everybody on the same package and work together to get it into a better state.

2. Lets use Github or some place that handles collaboration better than the AUR git system to manage issue reports on the package and invite contributions. To this end I've mirrored the repo to https://github.com/alerque/aur-gitlab and added you to the contributor list. With as complex as this package is I think maintaining an issue list there will help work the problems out better than comments here on AUR.

Lopo commented on 2015-11-20 06:35

mg ... they renaming git-http-server => workhorse ... f.ck them !

... preparing for 8.2

melvinvermeeren commented on 2015-11-16 18:20

After the icu update to 56 from 2015-11-03 gitlab-backup is no longer working due to it requiring version 55.
To fix this, install icu55 from AUR: https://aur.archlinux.org/packages/icu55/

Thanks for maintaining this!

caleb commented on 2015-11-10 17:51

Anyone hankering for an 8.1.3 install can try my PKGBUILD: https://gitlab.alerque.com/aur/gitlab/tree/update-813

The easiest thing to do is probably clone this AUR package's git repository, then add mine as a remote and checkout my update-813 branch, then build. Be warned that it seems to Work For Me™ but it hasn't been tested very thoroughly and it's a little dirty.

Note: One thing not fixed in this build is the permissions for the CI runner. Builds are posted back and end up in /usr/share/webapps/gitlab/builds, but the current systemd service blocks write access to /usr. See https://gitlab.com/gitlab-org/gitlab-ce/issues/3056#note_2414776 and pick your own poison for fixing that issue if you use the CI functions.

Lopo commented on 2015-11-10 14:18

working on the update, but was busy last few weeks

CarstenF commented on 2015-11-09 13:06

Please Update this Package or disown it.

Eriner commented on 2015-11-07 01:04

@Lopo not sure if you are going to be updating this package or not, but if you don't have the time/energy to, I suggest you orphan it and let someone like @caleb take over maintaining it. He seems to have his ducks in a row, based on his maintenance of his own gitlab PKGBUILD.

orbifx commented on 2015-11-05 09:46

@caleb: they just can't have an intuitive name..

caleb commented on 2015-11-05 08:31

The dependency of gitlab-git-http-server has been renamed to gitlab-workhorse upstream. I'll update the AUR package for that dep as soon as the repos are available again. Ironically gitlab.com seems to have issues involving this package themselves because their own installation is broken and repos are not accessible ATM.

Eriner commented on 2015-11-01 01:05

Any time estimate for update? It has been almost a whole month.

wangfengfight commented on 2015-10-27 23:08

@orbifx, exactly. you need to enable the write permission of the socket file. I have no idea why git-http is not included in gitlab package either.

orbifx commented on 2015-10-27 11:57

wangfengfight: I got it working. One remark, the gitlab-git-http socket had write permissions restricted and nginx couldn't communicate with it.

orbifx commented on 2015-10-27 09:51

wangfengfight, I will try your instructions and respond with the results. Thanks.

If Gitlab needs gitlab-git-http-server, why is it not in the dependencies?

hunger commented on 2015-10-26 20:48

https://gitlab.com/hunger/aur-gitlab has my update to 8.1.

This fixes the gitlab-CI by moving the build package to /var, removes satellites (no longer necessary since 8.0).

If you install gitlab-git-http-server then gitlab-CI works (at least for me), after patching nginx (not part of this patch).

wangfengfight commented on 2015-10-26 18:28

@Lopo, the nginx exaple should be updated as we have the new gitlab-git-http service.
By default, the http service uses port 8181.
https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/support/nginx/gitlab

wangfengfight commented on 2015-10-26 18:20

@orbifx, you need to configure the gitlab-git-http.service and nginx properly before you start to use the new gitlab.
In my /usr/lib/systemd/system/gitlab-git-http.service:
ExecStart=/usr/bin/gitlab-git-http-server -authBackend http://localhost:9999 -listenAddr /var/lib/gitlab/sockets/gitlab-git-http-server.socket -listenNetwork unix /var/lib/gitlab/repositories
--authBackend is the location of unicorn, it should be 8080 in the default settings. -listenAddr is the address this small service will use. You can also use a tcp address like localhost:8181, but you need to change the -listenNetwork into tcp

Then you need to compare your nginx config file with the new example:
https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/support/nginx/gitlab

Basically, you should add a new upstream for gitlab-git-http server. In config, this is:
upstream gitlab-git-http-server {
server unix:/var/lib/gitlab/sockets/gitlab-git-http-server.socket fail_timeout=0;
}
Then look for the new address specification for git-http:
proxy_pass http://gitlab-git-http-server;

I changed this into
proxy_pass http://unix:/var/lib/gitlab/sockets/gitlab-git-http-server.socket;

The other configurations should be the same as before.

orbifx commented on 2015-10-26 14:53

Has anyone else had issues with pushing over HTTP and fixed it?

hunger commented on 2015-10-25 13:49

https://gitlab.com/hunger/aur-gitlab has an update to version 8.1.

Changes are pretty minimal: I got rid of sattelites (they are no longer needed since 8.0) and linked the builds subfolder into a writable place so that CI can actually work.

Note: You need gitlab-git-http-server to be set up for CI to work.

bgaleotti commented on 2015-10-23 14:39

Consider https://gitlab.com/gitlab-org/gitlab-ce/issues/3056#note_2414776 on the next release.

adminempire commented on 2015-10-23 04:58

Whats the hangup for the pkgver bump? Is there something I am missing as to why its being held up?

trusktr commented on 2015-10-19 18:32

Any suggestions on how to upgrade from version 6.5 of this package to the latest (8.0.3)?

axil42 commented on 2015-10-16 07:04

Also don't forget to update the nginx service because of https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/1548

axil42 commented on 2015-10-16 06:58

A new (optional) service `gitlab-mailroom.service` is added. Be sure to add this to PKGBUILD and also update the sidekiq service as well. This is due to the new feature 'Reply by e-mail'.

https://gitlab.com/gitlab-org/gitlab-ce/tree/master/doc/incoming_email
https://gitlab.com/gitlab-org/gitlab-recipes/tree/master/init/systemd

Lyce commented on 2015-10-08 06:40

@SWW13 that does seem like a better alternative. I didn't know
you could join namespaces.

Although, in the case you modify the sidekiq service file, you
will also need to add gitlab-unicorn.service as dependency,
otherwise, sidekiq won't join unicorn's namespace.

For this, you need to add "gitlab-unicorn.service" to "Requires="
and "After=" under "[Unit]"

markzz commented on 2015-10-08 03:08

When upgrading, the postupgrade function hangs indefinitely, anyone else getting this?

SWW13 commented on 2015-10-07 22:32

@Lyce thanks for debugging the issue, it was on my todo for several months now.

But I think the better solution for this problem is to join the namespaces and keep the private temp dir.
This can be achieved by adding "JoinsNamespaceOf=gitlab-unicorn.service" under "[Unit]" in gitlab-sidekiq.service or vice versa.

@Lopo Could you add that to the service file?

Lyce commented on 2015-10-07 15:41

Downloading repositories (any format) causes infinite redirect loops!

I've been troubled by this for quite a while and saw that there is
quite a bunch of people affected by this. This has been going on for
months, yet no one has come up with a solution.. until now.

This loop happens because of systemd's PrivateTmp feature. By default,
repositories are archived in tmp/repositories, which links to /var/tmp.
The archives are created by gitlab-sidekiq and saved in the tmp folder -
everything's fine. But when gitlab-unicorn tries to read from the same
folder, it finds nothing. This is because both services have separate
private tmp folders. As a result, gitlab-unicorn thinks the archive
hasn't been created yet and just keeps trying, causing an infinite
redirect loop.

In order to fix this, it is necessary to edit both gitlab-sidekiq.service
and gitlab-unicorn.service files and set PrivateTmp to false, then do
'systemctl daemon-reload' and restart the services.

It would also be possible to just change the repositories setting in
gitlab.yml without disabling PrivateTmp, but then the archives won't be
generated in tmp.

I hope this is useful for anyone with the same issue.

thelinuxguy commented on 2015-10-03 21:11

@caleb thanks for all the work you are putting into this!

I think you missed the gitlab-git-http-server upstream config section in your example nginx configs

Lopo commented on 2015-10-02 09:22

@caleb, thx ... i noticed the http daemon in upgrade instructions ... and started appropriate modifications, but when you posted updates, i thought that they are fully tested and the new http daemon isn't really required

so now i have to return to it and check dependencies again

i really hate the system, which is practiced by gitlab authors - changing base things, strictly required versions of dependencies, ignoring newer ruby version, ...

caleb commented on 2015-10-02 09:05

One more change that needs to be made for anybody trying to use the continuous integration system that I haven't done yet except on my host is that the systemd file system protections need to be lifted for the unicorn service such that it can write to the data dir. It now puts job output temp files in there.

caleb commented on 2015-10-02 08:45

Gitlab 8.0.0 pulled a fast one on us. The package as updated works fine for most scenarios, but you can only clone repos over git+ssh. This package no longer includes a way to serve up the git repos over http(s)! This function has been moved to yet another daemon™ running on yet another port™. For anybody that noticed the CI is non-functional or otherwise tried to clone over http(s) you need to install and run a separate service for that. See my package in the AUR for gitlab-git-http-service:

https://aur4.archlinux.org/packages/gitlab-git-http-server/

@Lopo I have added you as a co-maintainer for that package in case anything comes up as far as updates/conflicts as these packages need to interact a bit. I have also made some updates to this package to show it as a dependency, require it as part of the service set, and setup the example proxy configs. If you could merge these changes into your master that would be great:

https://gitlab.alerque.com/aur/gitlab/commits/gitlab-git-http

@All Once you get the new daemon up and running don't forget to update your proxy settings for Apache/Nginx/Lighthttpd to catch *.git requests and forward them to 8181. See the updated example configs in my branch above.

hunger commented on 2015-10-01 19:11

@caleb: Sorry for butchering the patch: I only noticed after sending it that I was still using pre-git AUR in that build-container:-/

Won't happen again!

Eriner commented on 2015-10-01 16:58

Before anyone builds this (may want to add to PKGBUILD), you should export the ruby2.1 gem dirs, otherwise it will default to the old dirs, and fail to build.

GEM_HOME='/opt/ruby2.1/lib/ruby/gems/2.1.0'
GEM_PATH='/opt/ruby2.1/lib/ruby/gems/2.1.0'

caleb commented on 2015-10-01 10:54

Sorry for the wave of comments, but I keep running into more issues with the 8.x upgrade. I have fixed a bunch more things related to the ruby downgrade, but I've also bumped the release to 8.0.3.

Scratch the links in my previous comments. The much cleaner commit tree is in a new branch here:

https://gitlab.alerque.com/aur/gitlab/commits/update-803

caleb commented on 2015-10-01 08:51

Note the commits in my previous comment had checksum issues due to the rebasing. I've fixed this if you look at the branch at https://gitlab.alerque.com/aur/gitlab/commits/cleanup-802 or if you just want the finished product it's at https://gitlab.alerque.com/aur/gitlab/raw/cleanup-802/PKGBUILD and you can just copy that straight to your build directory.

caleb commented on 2015-10-01 08:24

The patch in the previous comment from @hunger has a bunch of issues.

1) The unnecessary whitespace and source code order changes make it almost impossible to read.
2) It includes a bunch of dependency changes for things that are already dependencies of other included packages or the base-devel group.
3) It patches a rather old version of the PKGBUILD file rather than the latest one.

I have rebased the patch against the current version and corrected the above issues. You can find my package at https://gitlab.alerque.com/aur/gitlab in the cleanup-802 branch.

Original patch rebased on master and cleaned up of bogus whitespace:

https://gitlab.alerque.com/aur/gitlab/commit/8757e95

Revert changes that didn't belong:

https://gitlab.alerque.com/aur/gitlab/commit/ef86c2a

@Lopo if you add my Gitlab address as remote and fetch the branch it should merge cleanly into your latest master.

caleb commented on 2015-10-01 08:20

The patch in the previous comment from @hunger has a bunch of issues.

1) The unnecessary whitespace and source code order changes make it almost impossible to read.
2) It includes a bunch of dependency changes for things that are already dependencies of other included packages or the base-devel group.
3) It patches a rather old version of the PKGBUILD file rather than the latest one.

I have rebased the patch against the current version and corrected the above issues. You can find my package at https://gitlab.alerque.com/aur/gitlab in the cleanup-802 branch.

Original patch rebased on master and cleaned up of bogus whitespace:

https://gitlab.alerque.com/aur/gitlab/commit/14ea6d704ad111349e18e1a2559020861922b5db

Revert changes that didn't belong:

https://gitlab.alerque.com/aur/gitlab/commit/09d78cd7c3e1aa45212243328e7a27d47f36db0a

@Lopo if you add my Gitlab address as remote and fetch the branch it should merge cleanly into your latest master.

hunger commented on 2015-09-26 20:48

http://pastebin.com/Cd6HYTFD has a diff updating this to gitlab 8.0.2.

The diff is pretty big though, but most are WS only changes. Git won't let me fix those and I have no idea why. Sorry for that.

Works-for-me(TM).

PS: Also removes /run/gitlab from gitlab.tmpfiles.d.
PPS: ... and depends on ruby2.1 from AUR. I got quite a few really strange bugs with ruby 2.2.

hunger commented on 2015-09-26 20:46

http://pastebin.com/Cd6HYTFD has a diff updating this to gitlab 8.0.2.

The diff is pretty big though, but most are WS only changes. Git won't let me fix those and I have no idea why. Sorry for that.

Works-for-me(TM).

PS: Also removes /run/gitlab from gitlab.tmpfiles.d.

hunger commented on 2015-09-26 16:25

You should be able to remove the /run/gitlab directory from the gitlab.tmpfiles.d. The service files manage that and create/delete that directory as necessary.

You should also consider to build this against ruby2.1 from AUR, since ruby 2.2 breaks gitlab in subtle ways:-/

Thanks for incorporating most of the things Stefan and I did!

caleb commented on 2015-09-26 10:58

@kreon All the packages in the base-devel group are ASSUMED to be available when building any packages and pkg-config is in that group so specifying it as a build dependency for this package would be incorrect. Before building anything from the AUR you should install that package group.

https://wiki.archlinux.org/index.php/Arch_User_Repository#Prerequisites
https://www.archlinux.org/groups/i686/base-devel/

kreon commented on 2015-09-26 10:41

pkg-config is also required to build app.

kreon commented on 2015-09-26 10:39

nokogiri failes to build with --use-system-libraries flag and libxml2 2.9.2 together.
removing this line fixes the problem.

Lopo commented on 2015-09-24 11:00

1 week

orbifx commented on 2015-09-24 09:50

What's the ETA on upgrading to gitlab-8.0?

thelinuxguy commented on 2015-09-24 01:43

@salamandar: it might be that you don't have enough memory or so.
just to be sure it's not a yaourt bug use makepkg to create the package.
You could also cross compile the package somewhere else and then copy it over.

I just installed a gitlab instance (on my PC) this morning which was working fine.

Salamandar commented on 2015-09-23 19:58

While trying to install it on my Rasberry Pi :

………
Installing fog-terremark 0.1.0
Installing fog-vmfusion 0.1.0
Installing fog-voxel 0.1.0
Installing ipaddress 0.8.0
Installing trollop 2.1.2
Installing rbvmomi 1.8.2
Installing opennebula 4.12.1
Installing fog 1.25.0
/tmp/yaourt-tmp-salamandar/aur-gitlab/./PKGBUILD: line 118: 6843 Killed bundle install --no-cache --deployment --without development test aws ${_wo[@]}

bayi commented on 2015-09-22 15:39

ofc the CI isnt working as it is not started yet ...

bayi commented on 2015-09-22 15:25

The package updated seamleasly... used the previous build of gitlab-shell as i didnt found any new version.

Theese are the versions used:
local/gitlab 8.0.0-1
local/ruby-2.1 2.1.6-1
local/ruby-bundler 1.10.6-1
local/gitlab-shell 2.6.5-1


bayi commented on 2015-09-22 15:01

gitlab 8 is out , trying a manual update on my test server, will keep you informed ....

Skullcrasher commented on 2015-09-16 18:24

I have the same problems every time I want to upgrade gitlab. I resolve this by installing gitlab-shell without dependency check (--nodeps) and after just update gitlab as normal. But I doubt that is the "clean" way.

asrenzo commented on 2015-09-15 12:01

Hi,

I have ==> aur/gitlab 7.14.1-1 and aur/gitlab-shell 2.6.4-1 installed.

Trying to update with yaourt returns:

==> Software upgrade (new version) :
aur/gitlab 7.14.1-1 -> 7.14.3-1
aur/gitlab-shell 2.6.4-1 -> 2.6.5-1

But updates fails during gitlab-shell update with :

loading packages...
resolving dependencies...
looking for conflicting packages...
error: failed to prepare transaction (could not satisfy dependencies)
:: gitlab: requires gitlab-shell=2.6.4
==> WARNING: Your packages are saved in /tmp/yaourt-tmp-saruman
==> Restart building gitlab ? [y/N]

Any idea ?

Regards,

Laurent

lyoko commented on 2015-09-09 17:27

I built armv7h package for anyone who wishes to skip the long build.
https://drive.google.com/file/d/0B1c0yUwEyKTdaDhWMmx4VTJLalk/view?usp=sharing

francoism commented on 2015-08-25 20:15

Also how to upgrade safely? :)

francoism commented on 2015-08-25 20:12

7.14.1 released. :)

guiguan commented on 2015-08-25 14:55

Had to downgrade my ruby version to 2.1.6 using ruby-2.1 aur package in order for this to work properly

Lopo commented on 2015-07-28 04:52

No, it wouldn't ... because there was problems with that in history ...
To upgrade, just force gitlab-shell with -d or -dd and then normally upgrade gitlab

Netrix commented on 2015-07-27 18:14

I think it would be much better to add gitlab-shell version as '>=' instead od '=' because there's a problem with upgrading gitlab-shell when version is changed later.

Or am I doing something wrong?

Lopo commented on 2015-07-12 06:35

I think, i wrote it once, so again: don't think so ... adding each lib required by all sub libs (vendor gems) is a path to dependency hell. It's almost impossible to track all (hidden) dependencies with each new release

chris commented on 2015-07-11 19:52

@Lopo
As crashandburn4 already mentioned, I think this should depend on libgit2.
Mind adding the dependency?

sanerb commented on 2015-07-07 08:59

@bendavis78 -

/usr/share/webapps/ is the Arch packaging standard. See https://wiki.archlinux.org/index.php/Web_application_package_guidelines

It is expected that the user copy over (or (sym|hard)?link) the files to /srv/http when serving them live to match the FHS. This prevents a package update from overwriting customizations you may have applied yourself.

bendavis78 commented on 2015-05-31 21:33

One suggestion: if you're wanting to follow linux filesystem hierarchy standard, store files in /srv/webapps/gitlab instead of /usr/share/webapps/gitlab. /usr/share should only be used for platform-independent files such as documentation, fonts, etc. Whereas /srv is intended for situations like this.

http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/usr.html
http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/srv.html

Prototik commented on 2015-05-30 18:25

Please add to gitlab-sidekiq.service to ExecStart section this: -q archive_repo
This options required for processing repo download request (download zip button).

crashandburn4 commented on 2015-05-29 00:53

This has a dependency on libgit2 (for rugged, which is installed with `--use-sytem-libraries`)

chris commented on 2015-05-25 19:24

@bayi
I am deploying gitlab using docker so separating Ruby is not a concern.
If you are interested, my image can be found on the public hub at [1] and on github respectively.
The image is hard geared towards a postgres database and documentation is admittedly poor, so you should probably look at the code too see how to get it working or feel free contact me directly.

[1] https://registry.hub.docker.com/u/kampka/gitlab/

bayi commented on 2015-05-25 17:13

is this now compatible with 2.2 ?

I can't use vim because i need to hold ruby at 2.1 on my dev server ...

Or does anybody have a solution for that ? (somehow installing 2.1 for gitalb and 2.2 for vim)

axil42 commented on 2015-05-09 21:45

Ah you wrote libs, ignore my previous comment.

axil42 commented on 2015-05-09 21:42

@chris that's not true. You need the databases as the relevant gems have C extensions which need to be compiled and the db must be installed.

chris commented on 2015-05-09 18:15

Any chance we can get rid of the "return 1" abort if the database libs are not installed? I am building this package in a chroot on a machine where gitlab is not going to be installed and database libs are not required for building, only on the installation target so this behavior is a bit annoying.

niqingliang2003 commented on 2015-04-22 10:00

it looks like the dep version of 'ruby-bundler' need update

panda-z commented on 2015-04-13 08:28

@latelx:
You can config bundle mirror by adding this line to PKGBUILD (works for me):
bundle config mirror.https://rubygems.org https://ruby.taobao.org

latelx commented on 2015-04-12 17:32

@axil42 thank you

change source to https://ruby.taobao.org/ doesn't solve my problem.

instead, I used a VPN to do it.

axil42 commented on 2015-04-11 10:56

@latelx You'll have to edit the Gemfile{,.lock} manually

https://gitlab.com/gitlab-org/gitlab-ce/blob/master/Gemfile#L1
https://gitlab.com/gitlab-org/gitlab-ce/blob/master/Gemfile.lock#L2

latelx commented on 2015-04-11 04:40

since the official gem source is way too slow, I have changed to a third-party source using the following commands:

gem source --remove https://rubygems.org/
gem source --add https://ruby.taobao.org/
gem source --list

while, during the installation, the gem still uses the original "http://rubygems.org/" source, thus failed everything because of the network failure.

so, how can I force the source to "https://ruby.taobao.org/"?

archaurwiki commented on 2015-04-06 01:08

@panda-z: thank you, that worked great.
@Lopo: is there any reason why we can't add nodejs as a dependency or any alternatives that @caleb pointed out? We should at least be notified of this new dependency and let the end-user decide which to go with.

panda-z commented on 2015-04-03 14:22

@orbifx: There's already a bug report and a pending PR for that. See https://gitlab.com/gitlab-org/gitlab-ce/issues/1289 and https://github.com/gitlabhq/gitlabhq/pull/9008

caleb commented on 2015-04-03 06:41

The upgrade process now expects Ruby to be able to run ExecJS, which means the system needs a Javascript interpreter. This needs to be added as a dependency. Installing nodejs on my system worked, but there are others available: https://github.com/sstephenson/execjs

orbifx commented on 2015-04-01 15:17

panda-z: Thanks that works. I couldn't find anything in the logs, would have taken me a long time.

Is this fix upstream? Will it override the modification in the next upgrade?

panda-z commented on 2015-04-01 15:05

@orbifx: For the second one. Recent version of ssh-keygen shows SHA256 fingerprint by default. But what gitlab expected is MD5 fingerprint.

You can, open /usr/share/webapps/gitlab/app/models/key.rb, find the following line:
cmd_output, cmd_status = popen(%W(ssh-keygen -lf #{file.path}), '/tmp')
replace the above line with:
cmd_output, cmd_status = popen(%W(ssh-keygen -E md5 -lf #{file.path}), '/tmp')
Then restart gitlab related service:
sudo systemctl restart gitlab.target gitlab-sidekiq gitlab-unicorn

For more information, you can `man ssh-keygen`

orbifx commented on 2015-04-01 14:16

Two issues. I think I fixed the first one, still working in the second. Any help would be appreciated.

# 1 - Git configuration for gitlab

During the check, the only failure is that git is not configured for gitlab. But when I try to execute the commands given:
Try fixing it:
sudo -u gitlab -H "/usr/bin/git" config --global user.name "GitLab"
sudo -u gitlab -H "/usr/bin/git" config --global user.email "no-reply@xxx.xxx"
sudo -u gitlab -H "/usr/bin/git" config --global core.autocrlf "input"

I got the error, until I create a git repository in the gitlabs home-dir. So its not only an issue for the error given:
fatal: Not a git repository (or any of the parent directories): .git

But also for configuring git for the gitlab user?

# 2 -

When trying to add SSH key get the error:

Fingerprint cannot be generated

Any ideas on this?

panda-z commented on 2015-03-31 11:02

@archaurwiki Installing nodejs works for me.

archaurwiki commented on 2015-03-30 09:29

Any ideas? Running --trace doesn't help either.

# su - gitlab -s /bin/sh -c "cd '/usr/share/webapps/gitlab'; bundle exec rake assets:precompile RAILS_ENV=production"

rake aborted!
ExecJS::RuntimeUnavailable: Could not find a JavaScript runtime. See https://github.com/sstephenson/execjs for a list of available runtimes.
(in /usr/share/webapps/gitlab/app/assets/javascripts/application.js.coffee)
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/execjs-2.0.2/lib/execjs/runtimes.rb:51:in `autodetect'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/execjs-2.0.2/lib/execjs.rb:5:in `<module:ExecJS>'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/execjs-2.0.2/lib/execjs.rb:4:in `<top (required)>'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/activesupport-4.1.9/lib/active_support/dependencies.rb:247:in `require'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/activesupport-4.1.9/lib/active_support/dependencies.rb:247:in `block in require'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/activesupport-4.1.9/lib/active_support/dependencies.rb:232:in `load_dependency'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/activesupport-4.1.9/lib/active_support/dependencies.rb:247:in `require'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/coffee-script-2.2.0/lib/coffee_script.rb:1:in `<top (required)>'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/activesupport-4.1.9/lib/active_support/dependencies.rb:247:in `require'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/activesupport-4.1.9/lib/active_support/dependencies.rb:247:in `block in require'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/activesupport-4.1.9/lib/active_support/dependencies.rb:232:in `load_dependency'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/activesupport-4.1.9/lib/active_support/dependencies.rb:247:in `require'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/tilt-1.4.1/lib/tilt/template.rb:144:in `require_template_library'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/tilt-1.4.1/lib/tilt/coffee.rb:36:in `initialize_engine'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/tilt-1.4.1/lib/tilt/template.rb:56:in `initialize'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/sprockets-2.11.0/lib/sprockets/context.rb:196:in `new'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/sprockets-2.11.0/lib/sprockets/context.rb:196:in `block in evaluate'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/sprockets-2.11.0/lib/sprockets/context.rb:194:in `each'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/sprockets-2.11.0/lib/sprockets/context.rb:194:in `evaluate'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/sprockets-2.11.0/lib/sprockets/processed_asset.rb:12:in `initialize'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/sprockets-2.11.0/lib/sprockets/base.rb:374:in `new'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/sprockets-2.11.0/lib/sprockets/base.rb:374:in `block in build_asset'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/sprockets-2.11.0/lib/sprockets/base.rb:395:in `circular_call_protection'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/sprockets-2.11.0/lib/sprockets/base.rb:373:in `build_asset'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/sprockets-2.11.0/lib/sprockets/index.rb:94:in `block in build_asset'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/sprockets-2.11.0/lib/sprockets/caching.rb:58:in `cache_asset'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/sprockets-2.11.0/lib/sprockets/index.rb:93:in `build_asset'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/sprockets-2.11.0/lib/sprockets/base.rb:287:in `find_asset'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/sprockets-2.11.0/lib/sprockets/index.rb:61:in `find_asset'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/sprockets-2.11.0/lib/sprockets/bundled_asset.rb:16:in `initialize'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/sprockets-2.11.0/lib/sprockets/base.rb:377:in `new'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/sprockets-2.11.0/lib/sprockets/base.rb:377:in `build_asset'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/sprockets-2.11.0/lib/sprockets/index.rb:94:in `block in build_asset'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/sprockets-2.11.0/lib/sprockets/caching.rb:58:in `cache_asset'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/sprockets-2.11.0/lib/sprockets/index.rb:93:in `build_asset'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/sprockets-2.11.0/lib/sprockets/base.rb:287:in `find_asset'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/sprockets-2.11.0/lib/sprockets/index.rb:61:in `find_asset'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/sprockets-2.11.0/lib/sprockets/manifest.rb:211:in `block in find_asset'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/sprockets-2.11.0/lib/sprockets/manifest.rb:257:in `benchmark'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/sprockets-2.11.0/lib/sprockets/manifest.rb:210:in `find_asset'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/sprockets-2.11.0/lib/sprockets/manifest.rb:119:in `block in compile'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/sprockets-2.11.0/lib/sprockets/manifest.rb:118:in `each'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/sprockets-2.11.0/lib/sprockets/manifest.rb:118:in `compile'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/sprockets-rails-2.2.4/lib/sprockets/rails/task.rb:70:in `block (3 levels) in define'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/sprockets-2.11.0/lib/rake/sprocketstask.rb:146:in `with_logger'
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/sprockets-rails-2.2.4/lib/sprockets/rails/task.rb:69:in `block (2 levels) in define'
Tasks: TOP => assets:precompile
(See full trace by running task with --trace)

caleb commented on 2015-03-28 14:47

@ArArgyridis: I commented on this back on Nov 11, 2014. This package has been difficult to install and ever worse to upgrade for a long time. Part of it it Gitlab's fault, it's kind of a weird beast and not at all friendly toward distro packaging (they want you to use omnibus). Part of is is this package just doesn't take care of everything it needs to.

The files you need to check up on are the two gitlab secrets and the two gitlab-shell secrets. If in doubt you can pretty much just copy any one of them to the other three and call it a day unless your hosting scheme has some reason to issolate them.

Here is a command you can you to check on them all:

md5sum /etc/webapps/gitlab{,-shell}/secret /usr/share/webapps/gitlab{,-shell}/.gitlab_shell_secret


If the checksums are not all the same (or at least the same in pairs) then that's your problem. This also came up in a Github issue here:

https://github.com/gitlabhq/gitlabhq/issues/8261#issuecomment-64673938

ArArgyridis commented on 2015-03-28 10:22

@caleb: Thank you for your answer. Could you please pin point to me where these files are located? (it's the first time I am trying to install gitlab)

Lopo commented on 2015-03-26 05:21

i think that i know why ... secret file is in backup array ... so update renames it into .pacsave and install script creates it again ...
but it shall be symlinked in all other places ...
when i'll get some time, i'll check it and try to fix it

caleb commented on 2015-03-25 17:42

@ArArgyridis Check that your secret key files are identical in all four places where they appear (run checksums on them). Chances are you have mismatched secrets and authentication is failing. This PKGBUILD seems to perpetually screw up the secrets and I'm not sure why, but that's usually the problem when you get that message.

ArArgyridis commented on 2015-03-25 16:56


I am getting the following error when running the following:

sudo -u gitlab bundle exec rake gitlab:check RAILS_ENV=production

error:

Running /usr/share/webapps/gitlab-shell/bin/check
Check GitLab API access: FAILED: Failed to connect to internal API

Any ideas?

zarac commented on 2015-03-24 05:06

BUG : no-sudo

I have no sudo.
sudo is required by install.
sudo is not in list of dependencies.
install fails.

..

gitlab.install:49
sudo -u gitlab -H bundle exec rake gitlab:backup:create RAILS_ENV=production

simonzack commented on 2015-03-17 16:36

@Lopo: another issue, the following:

sed -e "s|production: unix:/var/run/redis/redis.sock|production: redis://localhost:6379|" \
config/resque.yml.example > config/resque.yml

doesn't makes sense since gitlab shell uses redis.sock by defualt now. Either redis.sock should be used or the gitlab's redis settings (resque.yml) should be configurable, it currently isn't (gitlab only looks in it's config dir rather than in /etc)

simonzack commented on 2015-03-17 16:21

@Lopo thanks, works like a charm!

Lopo commented on 2015-03-15 08:50

@simonzack: check it, should be ok now

simonzack commented on 2015-03-14 08:09

@Lopo can you please fix the gitlab_shell_secret issue?

I need to do `sudo ln -fs /etc/webapps/gitlab-shell/secret /usr/share/webapps/gitlab/.gitlab_shell_secret` on every upgrade since I have a different secret than the default.

wertha commented on 2015-03-11 22:25

@Lopo
I just said the 2.2 thing because of these issues
https://github.com/gitlabhq/gitlabhq/issues/8696
which some of them are open and related to ruby 2.2

wertha commented on 2015-03-11 09:27

@Lopo
Yeah, >=2.0 also covers 2.2 which is not supported, probably adding <2.2?
I'm not complaining that your package doesn't work, yeah I fixed those things for me, just letting you. As the developers said https://gitlab.com/gitlab-org/gitlab-ce/blob/master/.ruby-version
"757df014 GitLab does not work well with Ruby 2.2 yet"

Lopo commented on 2015-03-11 05:15

@zegAnjer: no, because that was changed to i686/x86_64 some time ago - search in comments history

@wertha: because >=2.0 ?

both of you: you can change those things in pkgbuild before makepkg

wertha commented on 2015-03-10 20:22

gitlab doesn't support ruby 2.2. Why don't you change ruby to ruby2.1 and ruby2.1-bundler ?

zegAnjer commented on 2015-03-07 15:58

Could you set the arch to 'any'? That way Arch ARM user could also use this PKGBUILD.

ferllings commented on 2015-03-05 13:25

I can't start gitlab anymore, after update:
$ sudo -u gitlab bundle exec rake gitlab:env:info RAILS_ENV=production
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.2.0/gems/activesupport-4.1.1/lib/active_support/values/time_zone.rb:285: warning: circular argument reference - now
/usr/share/webapps/gitlab/vendor/bundle/ruby/2.2.0/gems/fog-core-1.21.1/lib/fog/core/collection.rb:148: warning: circular argument reference - filters
rake aborted!
LoadError: cannot load such file -- builder

I tried gem install builder, but no change.

Any idea?

Araeos commented on 2015-02-28 19:53

This can be temporary fixed by manually removing the version number in the PKGBUILD of gitlab-shell under dependencies.

simonzack commented on 2015-02-26 13:15

I'm in the same situation as wertha. Lopo can you please take a look? It's been like this for months.

wertha commented on 2015-02-25 03:48

I'm on a loop dependency issue here. I cannot upgrade gitlab because it says that it requires gitlab-shell 2.5.3 and then gitlab-shell cannot be upgraded because the previous gitlab instalation required some 2.4 version, I think that having a dependency on gitlab-shell but no specific version should be enough, it might break it when gitlab-shell is not updated.

calrama commented on 2015-02-24 19:26

@Lopo: Please change every ',' in the "ExecStart" line of gitlab-sidekiq.service to " -q ", because the former seems to longer be supported[1] and leads to sidekiq e.g. not sending emails. You can also see this has been adressed in the official systemd service files[2].

The full line should read:
ExecStart=/usr/bin/bundle exec "sidekiq -q post_receive -q mailer -q system_hook -q project_web_hook -q gitlab_shell -q common -q default -e production -L /var/log/gitlab/sidekiq.log >> /var/log/gitlab/sidekiq.log 2>&1"

[1] http://stackoverflow.com/a/28653533
[2] https://github.com/gitlabhq/gitlab-recipes/tree/master/init/systemd

calrama commented on 2015-02-24 19:24

@Lopo: Please change every ',' in the "ExecStart" line of gitlab-sidekiq.service to " -q ", because the former seems to longer be supported[1] and leads to sidekiq e.g. not sending emails.

The full line should read:
ExecStart=/usr/bin/bundle exec "sidekiq -q post_receive -q mailer -q system_hook -q project_web_hook -q gitlab_shell -q common -q default -e production -L /var/log/gitlab/sidekiq.log >> /var/log/gitlab/sidekiq.log 2>&1"

[1] http://stackoverflow.com/a/28653533

arnefm commented on 2015-02-18 00:23

I can't get this package to work anymore. I tried all the suggestions mentioned here (installing ruby-2.1 aur package, replacing the commas gitlab-sidekiq.service with -q, correcting all the .secret files) but I still can't create new repositories. gitlab:check says everything should be good.
When I try to create a new repository from the web UI I get the error "Failed to create repository". There's nothing in gitlab-shell.log and nothing in sidekiq.log. Production.log shows a post request that returns 200 OK. The same thing happens when trying to import a repo.

Even tried reinstalling the package/deleting all config. I'm about to abandon gitlab for something else, perhaps give Gogs (http://gogs.io/) a try.

archaurwiki commented on 2015-02-10 21:47

@commiebstrd: thanks for the patch.

@78666cdc: try this package with the ruby-2.1 AUR package and with ruby-bundler 1.7.12. The ruby-bundler package is still out of date so you'll have to make the changes manually.

@Lopo: for backwards compatibility could you please please pretty please do the following: $ sed -i 's/,/ -q /g' gitlab-sidekiq.service

I wasted countless hours debugging a perfectly good installation because of this one package-related issue. Comma-delimited args should work perfectly fine but with this ruby-2.1 installation, they do not. As a result, sidekiq was keeping all jobs "Enqueued" and never executing them. Also, neither sidekiq, gitlab, or redis were reporting any errors so, this made for a very frustrating experience.

Whether this a ruby-2.1 issue or strange systemd issue, I don't know. Regardless, could you please make the simple change? Thank you.

commiebstrd commented on 2015-02-10 17:46

You might want to consider adding an ssh environment file within gitlab's $HOME/.ssh folder. Was fighting with ssh access for a long while until I added this and allowed per profile environment files within sshd(I know we don't want to modify that). My working example is shown below, this also resolves the inability of gitlab-shell to use "#!/bin/env ruby" correctly.

PATH="/var/lib/gitlab/.gem/ruby/2.2.0/bin:/var/lib/gitlab/.gem/ruby/2.2.0@global:/var/lib/gitlab/.gem/ruby/2.2.0@local/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl"
GEM_HOME="/var/lib/gitlab/.gem/ruby/2.2.0"
GEM_PATH="/var/lib/gitlab/.gem/ruby/2.2.0:/var/lib/gitlab/.gem/ruby/2.2.0@global"
MY_RUBY_HOME="/var/lib/gitlab/.gem/ruby/2.2.0"

chris commented on 2015-02-07 13:14

In case it is useful for anyone, I am also maintaining a gitlab docker container on the docker hub that is based on this package, albeit without the systemd integration.
I must admit that documentation is scarce to say the least, so if you want to give it a spin I advise you to look at the source for specifying the configuration. I is also geared to work with postgres only.

https://registry.hub.docker.com/u/kampka/gitlab/
https://github.com/kampka/dockerfiles/tree/master/gitlab

78666cdc commented on 2015-02-07 06:07

I had more typed out, with copy/pasted outputs, but accidentally hit my keyboard's back/forward key and lost what I had, so this is partly from memory; I apologize.

I did not have GitLab installed at all, and installing GitLab via packer was failing. (This is immediately prior to composing this comment.) The error message I was getting had something to do with installing the particular version of rugged (I'm sorry, I lost the exact message, as I said). After manually running the install command for rugged (0.21.2, I think?), I saw an error message saying that pkg-config was missing. After a `pacman -S pkg-config`, it got quite a bit farther than before, but is now failing with:

Unfortunately, a fatal error has occurred. Please see the Bundler troubleshooting documentation at http://bit.ly/bundler-issues. Thanks!
/usr/lib/ruby/gems/2.2.0/gems/bundler-1.7.11/lib/bundler/installer.rb:305:in `install_in_parallel': undefined method `[]' for nil:NilClass (NoMethodError)
from /usr/lib/ruby/gems/2.2.0/gems/bundler-1.7.11/lib/bundler/installer.rb:88:in `run'
from /usr/lib/ruby/gems/2.2.0/gems/bundler-1.7.11/lib/bundler/installer.rb:18:in `install'
from /usr/lib/ruby/gems/2.2.0/gems/bundler-1.7.11/lib/bundler/cli/install.rb:79:in `run'
from /usr/lib/ruby/gems/2.2.0/gems/bundler-1.7.11/lib/bundler/cli.rb:145:in `install'
from /usr/lib/ruby/gems/2.2.0/gems/bundler-1.7.11/lib/bundler/vendor/thor/command.rb:27:in `run'
from /usr/lib/ruby/gems/2.2.0/gems/bundler-1.7.11/lib/bundler/vendor/thor/invocation.rb:121:in `invoke_command'
from /usr/lib/ruby/gems/2.2.0/gems/bundler-1.7.11/lib/bundler/vendor/thor.rb:363:in `dispatch'
from /usr/lib/ruby/gems/2.2.0/gems/bundler-1.7.11/lib/bundler/vendor/thor/base.rb:440:in `start'
from /usr/lib/ruby/gems/2.2.0/gems/bundler-1.7.11/lib/bundler/cli.rb:9:in `start'
from /usr/lib/ruby/gems/2.2.0/gems/bundler-1.7.11/bin/bundle:20:in `block in <top (required)>'
from /usr/lib/ruby/gems/2.2.0/gems/bundler-1.7.11/lib/bundler/friendly_errors.rb:5:in `with_friendly_errors'
from /usr/lib/ruby/gems/2.2.0/gems/bundler-1.7.11/bin/bundle:18:in `<top (required)>'
from /usr/bin/bundle:23:in `load'
from /usr/bin/bundle:23:in `<main>'
==> ERROR: A failure occurred in build().
Aborting...
The build failed.

78666cdc commented on 2015-02-07 05:48

I am just trying to install this package for the first time (after making sure with `packer -Syu` that everything else is up to date, first). I do not already have gitlab installed. Here is my result:

Type numbers to install. Separate each number with a space.
Numbers: 0
/tmp/packertmp-1000/gitlab.PKGBUILD: line 74: warning: command not found
/tmp/packertmp-1000/gitlab.PKGBUILD: line 79: warning: command not found

Aur Targets (1): gitlab

Proceed with installation? [Y/n]

/tmp/packertmp-1000/gitlab.PKGBUILD: line 74: warning: command not found
/tmp/packertmp-1000/gitlab.PKGBUILD: line 79: warning: command not found
Edit gitlab PKGBUILD with $EDITOR? [Y/n] n
PKGBUILD: line 74: warning: command not found
PKGBUILD: line 79: warning: command not found
Edit gitlab.install with $EDITOR? [Y/n] n
==> WARNING: detected libmariadbclient
==> WARNING: detected postgresql-libs
==> Making package: gitlab 7.7.2-1 (Sat Feb 7 05:38:54 UTC 2015)
...

An error occurred while installing rugged (0.21.2), and Bundler cannot continue.
Make sure that `gem install rugged -v '0.21.2'` succeeds before bundling.
==> ERROR: A failure occurred in build().
Aborting...
The build failed.

78666cdc commented on 2015-02-07 05:44

After a packer -Syu, I'm getting the following error:

An error occurred while installing rugged (0.21.2), and Bundler cannot continue.
Make sure that `gem install rugged -v '0.21.2'` succeeds before bundling.

I am not sure whether it is relevant that I saw the following after `packer gitlab`:

Type numbers to install. Separate each number with a space.
Numbers: 0
/tmp/packertmp-1000/gitlab.PKGBUILD: line 74: warning: command not found
/tmp/packertmp-1000/gitlab.PKGBUILD: line 79: warning: command not found

Aur Targets (1): gitlab

Proceed with installation? [Y/n]

/tmp/packertmp-1000/gitlab.PKGBUILD: line 74: warning: command not found
/tmp/packertmp-1000/gitlab.PKGBUILD: line 79: warning: command not found
Edit gitlab PKGBUILD with $EDITOR? [Y/n] n
PKGBUILD: line 74: warning: command not found
PKGBUILD: line 79: warning: command not found
Edit gitlab.install with $EDITOR? [Y/n] n

archaurwiki commented on 2015-02-07 00:18

@Lopo: thank you for doing another test. I tried this PKGBUILD on another fresh install with another VM but had mixed results. At one point I had a successful build. At another, the same charlock_holmes build failure. At another, a different Gem build failure because of a missing python2 dependency. All in all, I think the problem lies upstream with Ruby and/or with a fluctuating Gem somewhere.

Running this package with Ruby 2.1.5 (ruby-2.1 in AUR) seems to work well so far. This whole PKGBUILD issue could've been a Ruby 2.2.0 issue to begin with, so I agree with @theflyingfool that enforcing @chris's ruby-2.1 package may be a better option for now.

If anyone else is reading this thread, are you are having any success or similar build errors with this package?

theflyingfool commented on 2015-02-06 05:01

I am not using gitlab from AUR, however the word from upstream is does not currently support ruby 2.2.0.

Since there is a package in the AUR for 2.1.0 it might not be a bad idea to force that for now.

https://github.com/gitlabhq/gitlabhq/issues/8696

Link lists some known issues using 2.2.0

Lopo commented on 2015-02-05 11:00

@archaurwiki: successfully instaled on new minimal arch install through yaourt
instaled pkgs: base, base-devel, mc, yaourt, mariadb

archaurwiki commented on 2015-02-04 21:18

@Lopo: it successfully builds, even with ruby 2.2.0-1, but only when directly issuing a makepkg on the command line in $pkgdir, and that's after having installed the latest ruby-bundler with an updated PKGBUILD (that package is currently is out-of-date, but that's not your problem). This package still fails miserably when attempting to build with yaourt.

To test, I eliminated all possible variables (and potential previous hacks on any of the systems that I previously tested against) by creating a fresh install of Arch on a separate VM. Alas, the same charlock_holmes build error was given. Only after the build failed, when I cd $pkgdir and issued makepkg on the console did it successfully build.

I'm looking at the PKGBUILD and don't see anything blatantly wrong, but obviously something is or something is not lining up with a dependency. I'm marking this package as out-of-date not because gitlab is out-of-date, but because I think the PKGBUILD needs a serious look-through.

Pavol, thank you very much for keeping this package maintained. I know you are more versed with the nuances of gitlab than I so I hope you can find this bug and squash it. If you can, I would encourage you to do a fresh install of archlinux-2015.02.01-dual.iso, install this package with yaourt, and see for yourself.

Thanks again for keeping this package up-to-date, I can see that gitlab has a fair amount of moving parts and it's not a breeze to keep this package running efficiently.

Lopo commented on 2015-02-03 04:40

makepkg finished w/o error on my server ... ruby 2.2.0-1

archaurwiki commented on 2015-02-02 17:52

@chris: Thank you for doing that.

I am still getting the charlock_holmes error that I previously posted. Before I report this upstream, could someone please confirm that this is indeed a gem build error and not a package error? @Lopo?

chris commented on 2015-01-31 17:21

I have created a package for ruby 2.1 on the AUR for the use with gitlab.
Note that you cannot use it alongside the extra/ruby package, as it is designed as a dropin replacement of extra/ruby.
If you have problems running gitlab under ruby 2.2, it might be worth considering.

https://aur.archlinux.org/pkgbase/ruby-2.1/

archaurwiki commented on 2015-01-30 18:17

When attempting a fresh install:
...
==> Starting build()...
==> Fetching bundled gems...
You are replacing the current global value of build.nokogiri, which is currently "--use-system-libraries"
Fetching source index from https://rubygems.org/
...
Gem::Ext::BuildError: ERROR: Failed to build gem native extension.

/usr/bin/ruby -r ./siteconf20150130-22905-1eiy3wk.rb extconf.rb
checking for main() in -licui18n... yes
checking for main() in -licui18n... yes
checking for unicode/ucnv.h... yes
-- tar zxvf file-5.08.tar.gz
-- ./configure --prefix=/tmp/yaourt/aur-gitlab/src/gitlabhq-7.7.1/vendor/bundle/ruby/2.2.0/gems/charlock_holmes-0.6.9.4/ext/charlock_holmes/dst/ --disable-shared --enable-static --with-pic
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of necessary
libraries and/or headers. Check the mkmf.log file for more details. You may
need configuration options.

Provided configuration options:
--with-opt-dir
--without-opt-dir
--with-opt-include
--without-opt-include=${opt-dir}/include
--with-opt-lib
--without-opt-lib=${opt-dir}/lib
--with-make-prog
--without-make-prog
--srcdir=.
--curdir
--ruby=/usr/bin/$(RUBY_BASE_NAME)
--with-icu-dir
--without-icu-dir
--with-icu-include
--without-icu-include=${icu-dir}/include
--with-icu-lib
--without-icu-lib=${icu-dir}/lib
--with-icui18nlib
--without-icui18nlib
--with-icui18nlib
--without-icui18nlib
extconf.rb:7:in `sys': ./configure --prefix=/tmp/yaourt/aur-gitlab/src/gitlabhq-7.7.1/vendor/bundle/ruby/2.2.0/gems/charlock_holmes-0.6.9.4/ext/charlock_holmes/dst/ --disable-shared --enable-static --with-pic failed, please report issue on http://github.com/brianmario/charlock_holmes (RuntimeError)
from extconf.rb:60:in `block (2 levels) in <main>'
from extconf.rb:59:in `chdir'
from extconf.rb:59:in `block in <main>'
from extconf.rb:55:in `chdir'
from extconf.rb:55:in `<main>'

extconf failed, exit code 1

Gem files will remain installed in /tmp/yaourt/aur-gitlab/src/gitlabhq-7.7.1/vendor/bundle/ruby/2.2.0/gems/charlock_holmes-0.6.9.4 for inspection.
Results logged to /tmp/yaourt/aur-gitlab/src/gitlabhq-7.7.1/vendor/bundle/ruby/2.2.0/extensions/x86-linux/2.2.0/charlock_holmes-0.6.9.4/gem_make.out
An error occurred while installing charlock_holmes (0.6.9.4), and Bundler cannot continue.
Make sure that `gem install charlock_holmes -v '0.6.9.4'` succeeds before bundling.
==> ERROR: A failure occurred in build().
Aborting...
==> ERROR: Makepkg was unable to build .
$

$(gem install charlock_holmes -v '0.6.9.4'), per the instruction, successfully installs BUT when building this package after the successful install, the same error above is given. Also, reading *mkmf.log shows nothing of interest.

Can anyone else reproduce this? Is this purely a Ruby 2.2.0 issue?

sham235 commented on 2015-01-30 06:52

After ruby was upgraded to 2.2.0 by 'pacman -Syu', I couldn't delete repositories in gitlab.

It turned out that gitlab 7.7.1 doesn't support ruby 2.2.0 yet.

If you want to use gitlab 7.7.1, then downgrade ruby to 2.1.5 or install ruby 2.1.5 via rvm system-wide.

You could also deploy gitlab on docker and avoid this package altogether.

sham235 commented on 2015-01-30 06:51

After ruby was upgraded to 2.2.0 by 'pacman -Syu', I couldn't delete repositories in gitlab.

It turned out that gitlab 7.7.1 doesn't support ruby 2.2.0 yet.

If you want to use gitlab 7.7.1, then downgrade ruby to 2.1.5 or install rvm ruby 2.1.5 system-wide.

You could also deploy gitlab on docker and avoid this package altogether.

Araeos commented on 2015-01-27 00:37

I had this issue where sidekiq would not process the queues. I noticed that mails stopped being send since around version 7.5 or 7.6.
It seems sidekiq requires each queue to be specified one after another.

Changing it to this line fixed it for me:
ExecStart=/usr/bin/bundle exec "sidekiq -q post_receive -q mailer -q system_hook -q project_web_hook -q gitlab_shell -q common -q default -e production -L /var/log/gitlab/sidekiq.log >> /var/log/gitlab/sidekiq.log 2>&1"

I hope it helps somebody. I use sendmail per msmtp if it is relevant.

chris commented on 2015-01-25 21:55

Gitlab 7.7 has upgraded the problematic gems, so a package upgrade would be of great benefit.

simonzack commented on 2015-01-13 22:23

Phew finally have this working again. Doesn't affect usage, but I'm getting a lot of permissions differ to that of package errors after installing.

simonzack commented on 2015-01-13 21:27

@Saren

Alternatively, reinstall and modify PKGBUILD before re-installing to insert the following:

sed -i -e "s|eventmachine (1.0.3)|eventmachine (1.0.4)|" Gemfile.lock
sed -i -e "s|raindrops (0.12.0)|raindrops (0.13.0)|" Gemfile.lock
sed -i -e "s|kgio (2.8.1)|kgio (2.9.0)|" Gemfile.lock

right before

msg "Fetching bundled gems..."

bgaleotti commented on 2015-01-13 15:35

gitlab-sidekiq.service needs to be updated according to https://github.com/gitlabhq/gitlabhq/issues/8490#issuecomment-68107207

Rulatir commented on 2015-01-13 13:27

Eventmachine won't build. There are voices that it will never support Ruby 2.2. Are we thus permanently screwed?

Saren commented on 2015-01-13 10:27

@onny
should be eventmachine 1.0.4

Saren commented on 2015-01-13 10:09

@sham235
Upgrading Gitlab is very scary. I shiver during upgrading Gitlab, no other packages can do that.
If you are experienced/dev/you have a lot of time to spend, then go for it. Gitlab usually breaks about every 5 AUR package upgrades.

onny commented on 2015-01-11 15:08

So since the upgrade to ruby 2.2.0 gitlab failed to start on my system.
Here's kind of a workaround I applied on the installed version.
I adjusted version numbers in /usr/share/webapps/gitlab/Gemfile.lock to the following:
eventmachine 1.0.3
raindrops 0.13.0
kgio 2.9.0
After that I run:
sudo -u gitlab -H bundle install

Thats it. But I guess we should fix gitlab-git in the meanwhile because I think this upstream already dealt with compatibily issues.

sham235 commented on 2015-01-11 02:09

Can it be used to upgrade gitlab?

Upgrading gitlab is a complicated process which I'm not sure that this package is capable of.

Saren commented on 2015-01-08 10:08

Upgrading to ruby 2.2.0 breaks gitlab.

axil42 commented on 2014-12-29 17:20

You might want to update the systemd services, if you notice that the background jobs aren't being processed. See https://github.com/gitlabhq/gitlab-recipes/pull/249

simonzack commented on 2014-12-25 13:59

Thanks for putting the service restarts, db migrations & asset cleanups in, that saves a lot of work!

I just updated and think `/usr/share/webapps/gitlab/.gitlab_shell_secret` is still needed, it didn't have a correct value and triggered the same problem as before. Doing a `ln -s /etc/webapps/gitlab-shell/secret /usr/share/webapps/gitlab/.gitlab_shell_secret` fixes the problem.

And1G commented on 2014-12-25 13:44

When I perform "sudo -u gitlab bundle exec rake gitlab:check RAILS_ENV=production" it complains about gitlab-shell:

Running /usr/share/webapps/gitlab-shell/bin/check
Check GitLab API access: FAILED. code: 401
gitlab-shell self-check failed
Try fixing it:
Make sure GitLab is running;
Check the gitlab-shell configuration file:
sudo -u gitlab -H editor /usr/share/webapps/gitlab-shell/config.yml
Please fix the error above and rerun the checks.

Checking GitLab Shell ... Finished

From what I found out this could be related to the gitlab and gitlab-shell secrets. Both /etc/webapps/gitlab{,-shell}/secret exist.
I am using the packages created by Lopo.

rockwyc992 commented on 2014-12-23 03:55

chown: cannot access ‘/etc/webapps/gitlab/secret’: No such file or directory
chmod: cannot access ‘/etc/webapps/gitlab/secret’: No such file or directory

what is this? no such file?

triaxx commented on 2014-12-19 12:22

@rumpelsepp
I cannot create a new repository from the webinterface. Before applying the patch, I could create a web repo, but the bare repo wasn't create on the filesystem. I could pull and push if I created it manually. Now, I cannot create a web repo at all.

rumpelsepp commented on 2014-12-19 08:56

@triaxx
Remember this patch only works when you create a new repo via the webinterface. It does not create a missing bare repo (on the filesystem) which has already a corresponding repo on the webinterface. For that purpose just delete and recreate it.

rumpelsepp commented on 2014-12-19 08:53

@triaxx:
Does pushing work when you create the missing bare repo on the server manually? I had the same problem and this patch from upstream fixed it.

triaxx commented on 2014-12-19 08:50

Thank you for your patch. I applied it but it doesn't work yet. But now, I have "Failed to create repository". I'm not sure if it is correlated, but the method create_repository seems to be not exposed in for the Project class in the API entities. Sorry, I'm not a ruby developer ...

rumpelsepp commented on 2014-12-18 11:55

@triaxx
https://github.com/rumpelsepp/gitlab-pkgbuilds/commit/2e8ebe5091198c8afee67945cdc64823cca37a4f

triaxx commented on 2014-12-18 10:43

Since update to 7.5, gitlab-shell doesn't create repositories on filesystem any more. When I create a new project, it is successfully added to redis list of project, but no repository is created. Even after a manual downgrade to gitlab-shell 2.2.0, the problem remains.

I've tried to investigate but I still don't understand how gitlab request gitlab-shell to create the repository.

I'm ready to provide any information (but not my root passwd) if someone could help me to understand how I could resolve this problem.

guiguan commented on 2014-12-16 15:32

Thank you for the package.

I just installed it, which is working quite okay. I have noticed that the new version has come out. Once you update the package to the newest version. How could I upgrade to that new version?

Using packer? Has to recompile everything from scratch? What if things like database structure has changed? Or should we just follow official guide (provided updater) to upgrade?

Your answers will be much appreciated :P

nofxx commented on 2014-12-05 16:36

Thank you for this package!

Just had to do the 'check if the keys are the same':
https://github.com/gitlabhq/gitlabhq/issues/8261#issuecomment-64673938

Chmod satelites and git config gitlab user (explained in gitlab:check)

nofxx commented on 2014-12-05 16:35

Thank you for this package!

Just had to do the 'check if the keys are the same':
https://github.com/gitlabhq/gitlabhq/issues/8261#issuecomment-64166141

Chmod satelites and git config gitlab user (explained in gitlab:check)

Netrix commented on 2014-11-27 10:53

Fix is strictly temporary and works only in git push and pull with problems which I encountered. I am unable to edit but please use following code:

if json == "true"
json = '{ "status": "true" }'
elsif json == "false"
json = '{ "status": "false" }'
end

It will not change status if something else is provided.

Lopo commented on 2014-11-27 10:46

@Netrix: nice fix ... it's working now ...
I'll try to add it into pkg

Netrix commented on 2014-11-27 10:41

Quick fix to allow push and pull:

Add at the beginning of the method 'create_from_json(json)' in file /usr/share/webapps/gitlab-shell/lib/gitlab_access_status.rb following code

if json == "true"
json = '{ "status": "true" }'
else
json = '{ "status": "false" }'
end

This will convert return value to accepted string and will pass.

Netrix commented on 2014-11-27 10:28

I probably tracked the problem:

Pls see the changelog which caleb gave:
https://gitlab.com/gitlab-org/gitlab-shell/compare/dbdcc5f4...6e5c1adc

there are parts of code as in:
spec/vcr_cassettes/allowed-push.yml

which sends now {"status": "true"}' instead of 'true'

So gitlab-shell is requiring now JSON response instead of simple true value and that is what the error says.

So those two versions are not compatible. Correct me if I'm wrong.

Lopo commented on 2014-11-27 09:26

i tested it today again:
arch minimal install
gitlab 7.5.1 + gitlab-shell 2.4.0

push ended with:
/usr/lib/ruby/2.1.0/json/common.rb:155:in `parse': 757: unexpected token at 'true' (JSON::ParserError)
from /usr/lib/ruby/2.1.0/json/common.rb:155:in `parse'
from /usr/share/webapps/gitlab-shell/lib/gitlab_access_status.rb:13:in `create_from_json'
from /usr/share/webapps/gitlab-shell/lib/gitlab_net.rb:31:in `check_access'
from /usr/share/webapps/gitlab-shell/lib/gitlab_shell.rb:63:in `validate_access'
from /usr/share/webapps/gitlab-shell/lib/gitlab_shell.rb:24:in `exec'
from /usr/share/webapps/gitlab-shell/bin/gitlab-shell:16:in `<main>'

so it seems to be problem by gitlab.org ... not sure if gitlab or gitlab-shell ...
they alredy got issue ticket https://gitlab.com/gitlab-org/gitlab-ce/issues/838

rumpelsepp commented on 2014-11-27 08:38

@caleb: I will try updating my setup to 2.4. If it works I will let you know

caleb commented on 2014-11-27 08:31

@rumpelsepp I've seen at least two different people _say_ that in the Github issue tracker, but I don't see any proof. On the contrary the actual Gitlab code only does a check that it is at least 2.2.0 but it passes it's own self checks with newer versions. Additionally I have reviewed the [changelog][1] and actual [code changes][2] and don't see anything that would trip it up. Most importantly I'm running tho combination in production and don't have any problems with it now that all the other issues are sorted out.

If I'm wrong on this I'd love to see proof because it could not only affect my environment but many others as the AUR package for gitlab-shell has been updated to 2.4 and should be downgraded if that pairing is actually a requirement for Gitlab.

[1]: https://gitlab.com/gitlab-org/gitlab-shell/blob/master/CHANGELOG
[2]: https://gitlab.com/gitlab-org/gitlab-shell/compare/dbdcc5f4...6e5c1adc

rumpelsepp commented on 2014-11-26 20:59

@caleb
Today I read in the bugtracker that it is not compatible to gitlab-shell 2.4. But I am not able to find it quickly...

caleb commented on 2014-11-26 20:02

@lksbhm In spite of the "incompatibility" messages on that Github issue thread I was able to run Gitlab 7.5.1 with Gitlab-shell 2.4 just fine once all the other issues were sorted out. A quick look at the change log between them shows nothing that would make them incompatible and the check system only looks for 2.2 or greater (which _is_ needed for sure). I believe your issue was caused by something else (most likely permissions) was the real cause and re-installing got that cleared up.

@Netrix The ones in /etc should be 0640 and owned by root:gitlab. The symlinks in /usr/share should be owned the same way the rest of the stuff there that the package installs.

An additional problem getting 7.5 working is that the hook layout has changed. There is a rake formula + shell script for setting up the new hook system (hint: it copies rather than symlinks the ones used by gitlab and there is a new system for dealing with custom hooks: put them in ~gitlab/repositories/<repo>.git/custom_hooks).

As for gitlab-shell, some of the paths changed in the latest versions and you will need to rebuild your authorized keys file (there is a ruby formula for that) in addition to the other repository changes.

Lastly there are several things that don't install properly from this AUR package until after some of the above issues are fixed. It particular the migration stuff does not actually work right until you've fixed basically all the issues that show up in gitlab:check, including making sure all your repos have satalites. One you get all that cleared up again, you may need to run the install routine again. And don't forget to flush out your caches!

rumpelsepp commented on 2014-11-26 18:56

nice catch. I'll add this to my pkgbuild

lksbhm commented on 2014-11-26 18:27

Ok, I finally have a working gitlab again. It really seems like gitlab 7.5 is not yet compatible with gitlab-shell 2.4. So what I did was cloning rumpelsepp's repository, run makepkg on both gitlab (which is 7.5 there) and gitlab-shell (2.3!!!), and install both outcomes. I assume that only downgrading gitlab shell would also have worked

rumpelsepp commented on 2014-11-26 17:07

Just have a look at my repo. Hunger has fixed this a few days ago...
https://github.com/rumpelsepp/gitlab-pkgbuilds/compare/a371b8a4fefcad52eb06934761cdb58e042aa618...c2b0dc8a70a2ce09b152921bec389a4555a9225f

Netrix commented on 2014-11-26 17:00

But there is also .secret and .gitlab_shell_secret in my /usr/share/webapps/gitlab directory
.secret is linked to /etc/... and .gitlab_shell_secret is standalone, strange.

Which one should be used?
And what permissions should those files/link have?

I made them the same and it passed the check but now I have the same problem as @lksbhm.

caleb commented on 2014-11-26 16:36

The latest gitlab/gitlab-shell packages (7.5.1-2 and 2.4.0-1) are not working out of the box. The major issues is that the secrets are not the same ( /etc/webapps/gitlab{,-shell}/secret need to be identical) and /usr/share/webapps/gitlab{,-shell}/.gitlab_shell_secret need to both be symlinked to the respective secrets. Notably the one in the gitlab package is not symlinked correctly and the one in the gitlab-shell package is not the same secret.

For more information: https://github.com/gitlabhq/gitlabhq/issues/8261#issuecomment-64672842

lksbhm commented on 2014-11-26 16:26

@Netrix I had the same error. After some research I found out that /usr/share/webapps/gitlab/.gitlab_shell_secret should point to the same file at which /usr/share/webapps/gitlab-shell/.gitlab_shell_secret points - which it didn't.
Then I made both symlinks point to /etc/webapps/gitlab-shell/secret, but now I get this when I try to push/pull:

/usr/lib/ruby/2.1.0/json/common.rb:155:in `parse': 757: unexpected token at 'true' (JSON::ParserError)
from /usr/lib/ruby/2.1.0/json/common.rb:155:in `parse'
from /usr/share/webapps/gitlab-shell/lib/gitlab_access_status.rb:13:in `create_from_json'
from /usr/share/webapps/gitlab-shell/lib/gitlab_net.rb:31:in `check_access'
from /usr/share/webapps/gitlab-shell/lib/gitlab_shell.rb:63:in `validate_access'
from /usr/share/webapps/gitlab-shell/lib/gitlab_shell.rb:24:in `exec'
from /usr/share/webapps/gitlab-shell/bin/gitlab-shell:16:in `<main>'
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

I seem to be alone on the internet with this error. Help would be very much appreciated.

Netrix commented on 2014-11-26 13:43

Did you encountered any problems with gitlab and gitlab-shell collaboration?

I cannot get gitlab-shell access gitlab repositories.

sudo -u gitlab bundle exec rake gitlab:check RAILS_ENV=production

gets me:

Running /usr/share/webapps/gitlab-shell/bin/check
Check GitLab API access: "Performing GET http://mydomain:80//api/v3/internal/check"
FAILED. code: 401
gitlab-shell self-check failed
Try fixing it:
Make sure GitLab is running;
Check the gitlab-shell configuration file:
sudo -u gitlab -H editor /usr/share/webapps/gitlab-shell/config.yml
Please fix the error above and rerun the checks.

I cannot access my repos via shell.

Lopo commented on 2014-11-24 10:04

@joko: yep ... just ownership

i just finishing with fixing - in pre_upgrade stopping gitlab services (to prevent usage of tmp/log dirs), after backup proces renaming recreated dirs to prevent conflicts

now trying to restart services in post_upgrade

joko commented on 2014-11-24 09:55

Sure thing and thanks for your effort.

One more thing, during db migration I was getting this error:
rake aborted!
Errno::EACCES: Permission denied @ rb_sysopen - /usr/share/webapps/gitlab/db/schema.rb

Tasks: TOP => db:schema:dump
(See full trace by running task with --trace)

The error seems to be fixed if I change ownership to the aforementioned file:

sudo chown gitlab:gitlab /usr/share/webapps/gitlab/db/schema.rb

After this, everything seems to be working ok.

Lopo commented on 2014-11-24 07:49

ah ... problem is with making backups in pre_upgrade ... in that step the dirs are recreated again and makes the conflict ...
package is upgraded but dirs are wrong ... i'll try to fix it today

joko commented on 2014-11-24 07:36

The same error ("error: extract: not overwriting dir with file /usr/share/webapps/gitlab/log" etc.) appears also if I use the force flag e.g., "sudo pacman -U gitlab-7.5.1-1-x86_64.pkg.tar.xz --force"

joko commented on 2014-11-24 07:23

ok, here is what I get after deleting these directories:

% sudo pacman -U gitlab-7.5.1-1-x86_64.pkg.tar.xz
loading packages...
resolving dependencies...
looking for inter-conflicts...

Packages (1): gitlab-7.5.1-1

Total Installed Size: 175.08 MiB
Net Upgrade Size: 0.76 MiB

:: Proceed with installation? [Y/n]
(1/1) checking keys in keyring [###################################] 100%
(1/1) checking package integrity [###################################] 100%
(1/1) loading package files [###################################] 100%
(1/1) checking for file conflicts [###################################] 100%
(1/1) checking available disk space [###################################] 100%
chown: cannot access ‘/etc/webapps/gitlab/secret’: No such file or directory
chmod: cannot access ‘/etc/webapps/gitlab/secret’: No such file or directory
Dumping database ...
Dumping PostgreSQL database gitlab ... [DONE]
done
Dumping repositories ...
* user/project ... [DONE]
* user/project.wiki ... [SKIPPED]
done
Dumping uploads ...
done
Creating backup archive: 1416813668_gitlab_backup.tar ... done
Uploading backup archive to remote storage ... skipped
Deleting tmp directories ... done
Deleting old backups ... skipping
warning: /etc/nginx/sites-available/gitlab-ssl saved as /etc/nginx/sites-available/gitlab-ssl.pacsave
(1/1) upgrading gitlab [###################################] 100%
warning: /etc/webapps/gitlab/gitlab.yml installed as /etc/webapps/gitlab/gitlab.yml.pacnew
warning: /etc/webapps/gitlab/secret installed as /etc/webapps/gitlab/secret.pacnew
error: extract: not overwriting dir with file /usr/share/webapps/gitlab/log
error: extract: not overwriting dir with file /usr/share/webapps/gitlab/tmp
warning: directory permissions differ on /var/lib/gitlab/satellites/
filesystem: 770 package: 755
error: problem occurred while upgrading gitlab
The database may need to be migrated to reflect the latest changes in the application
To migrate run the following command:
# su - gitlab -s /bin/sh -c "cd /usr/share/webapps/gitlab; bundle exec rake db:migrate RAILS_ENV=production"
To clean up assets and cache:
# su - gitlab -s /bin/sh -c "cd /usr/share/webapps/gitlab; bundle exec rake assets:clean assets:precompile cache:clear RAILS_ENV=production"
error: could not commit transaction
error: failed to commit transaction (transaction aborted)
Errors occurred, no packages were upgraded.

Lopo commented on 2014-11-24 07:16

@joko:
dir structure changed with this build (symlinks instead of regular dirs etc.) ... so delete those dirs (make backup if you want) and then run update (and move backuped dirs/files to appropriate locations)

install script is runned after fileconflict check
i tested this problem with --force, but it doesn't work on dirs ...
so i don't know any other solution

joko commented on 2014-11-24 07:10

Hello,

I have been running gitlab 7.4.2-1 and tried installing gitlab-7.5.1-1. Unfortunately I get the following errors:

error: failed to commit transaction (conflicting files)
gitlab: /usr/share/webapps/gitlab/log exists in filesystem
gitlab: /usr/share/webapps/gitlab/public/assets exists in filesystem
gitlab: /usr/share/webapps/gitlab/tmp exists in filesystem

The funny thing is that all of them are owned by the previous gitlab installation, e.g.:

pacman -Qo /usr/share/webapps/gitlab/log
/usr/share/webapps/gitlab/log is owned by gitlab 7.4.2-1

Any ideas?

Lopo commented on 2014-11-23 15:42

I now finishing with testing of new build ... cross fingers ;)

hunger commented on 2014-11-23 15:09

I just updated rumpelsepps repo with gitlab 7.5 (and the new gitlab-shell).

Cleaned up the handling of the secrets files a bit to get rid of the symlinks which will make that more robust (I hope:-). Works for me, your millage may vary (as usual).

rumpelsepp commented on 2014-11-20 14:12

Updated gitlab at https://github.com/rumpelsepp/gitlab-pkgbuilds to 7.4.4. I will update gitlab-shell when 7.5 is out.

hunger commented on 2014-11-17 12:10

HLFH: You will most likely need to build the packages with rumpelsepp's PKGBUILD... the .service files will break Lopo's packages with all the security features we enabled:-)

hunger commented on 2014-11-17 08:51

HLFH: Please consider using https://github.com/rumpelsepp/gitlab-pkgbuilds . Those work great (at least for me) and do enable quite a few security-related features in systemd.

They make /usr read-only and /home completely inaccessible to all gitlab processes. Gitlab is unable to access tmp-files from other users. Most files in /dev are gone for the gitlab processes. The unicorn processes are stopped from ever gaining more privileges in the system (you can enable that for sidekiq, too, provided you do not need it to run sendmail) and all capabilities are removed from the started processes.

simonzack commented on 2014-11-15 12:52

Can somebody port the gitlab upgrade script to aur too? Upgrading on every minor version's release is a chore :(

HLFH commented on 2014-11-14 18:41

I got the error: PID file /home/gitlab/gitlab/tmp/pids/sidekiq.pid not readable (yet?) after start. As mentioned rumpelsepp... And I'm using the last files: https://github.com/gitlabhq/gitlab-recipes/tree/master/init/systemd

Lopo commented on 2014-11-14 16:32

sorry that still no upgrade. working on it, but there is a lot of changes that i need to test before release

Lopo commented on 2014-11-08 10:48

just a few things:
- sources of all my arch packages are here: https://github.com/Lopo/archlinux-packages so you can send pull requests to speed up updates like now with systemd changes
- i'm a bit busy last months, so it takes a bit long to update packages right after new stable release
- my english isn't my mature language, so i'm not the right man to update wiki, feel free to do it someone who hasn't problem with that

- i'm not sure if mention all dependencies found in all .so files of gitlab vendor gems is good idea ... they can be changed in any new version of gitlab - it's a way to dependency hell

Lopo commented on 2014-11-08 10:32

@rumpelsepp:
thanks for that work ... it's a lot easier for me when i can just adopt and no need to test every possible thing mentioned in comments
so ... today or tomorrow i'll try to release new version

rumpelsepp commented on 2014-11-04 20:02

hunger and I have developped a slightly improved PKGBUILD of gitlab and gitlab-shell:

- nothing writes to /usr any more
- we enabled lots of systemd's security features (such as privatetmp)
- the secrets are placed in /etc
- we fixed the annoying git error when displaying gitlab's revision number
- logfiles are in /var/log/gitlab

The sources are here: https://github.com/rumpelsepp/gitlab-pkgbuilds
Before you install our packages you'll have to move a few directories:
mv "/usr/share/webapps/gitlab/.secret" "/etc/webapps/gitlab/secret"
mv "/usr/share/webapps/gitlab/log" "/var/log/gitlab"
mv "/usr/share/webapps/gitlab/public/assets" "/var/lib/gitlab/assets"
mv "/usr/share/webapps/gitlab/public/uploads" "/var/lib/gitlab/uploads"
rm -rf "/usr/share/webapps/gitlab/tmp"

As always: Be careful, make backups, test the stuff and report any issues. Have fun! :)

Lopo commented on 2014-11-03 15:43

yes ... this week ... probably

chris commented on 2014-11-03 13:43

Any chance to get a version bump for the security update soon?

hunger commented on 2014-11-01 10:41

Hmmm... can we have pacman create /usr/share/webapps/gitlab/.secret as part of the installation?

Just wondering:-)

hunger commented on 2014-11-01 10:20

Is there a place where we can chat?

I use the same nick on freenode that I use here.

rumpelsepp commented on 2014-11-01 10:08

@hunger: I think we should take a look at gitlab-shell as well...

rumpelsepp commented on 2014-11-01 10:06

@hunger: here you are: https://github.com/rumpelsepp/gitlab-pkgbuilds
It is a work in progress (see TODO file) and it's not ready. But I think we could manage it. Feel free to clutter it with pull requests. :)

hunger commented on 2014-11-01 10:03

There is lots of dependencies missing.

These are the packages referenced in .so files found in the gitlab package:

e2fsprogs gcc-libs glibc gmp icu keyutils krb5 libgcrypt libgpg-error libmariadbclient libssh2 libxml2 libxslt openssl postgresql-libs ruby xz zlib

The first three are in base, so they can get removed. The rest may or may not be optdepends. We should list them somewhere.

rumpelsepp commented on 2014-11-01 09:40

@hunger: I think in about 1 hour or so I'll be able to post a github link here. Maybe we could collaborate then. :)

hunger commented on 2014-11-01 09:38

@rumpelsepp: What a coincidence, I am doing the same. I would be glad to pool my efforts with yours (and anybody else's for that matter).

hunger commented on 2014-11-01 09:36

Could you please consider to remove the mysql.service and syslog.service from the target's Require/After? It is so much easier to add them after the fact with systemd (just drop a file into /etc/systemd/system/gitlab.target.d!) than it is to remove them that way (e.g. when using postgresql;-).

rumpelsepp commented on 2014-11-01 09:32

@hunger: It's funny, at the moment I am trying to create an updated PKGBUILD for gitlab. I will put it on github and we could improve it together. Maybe some day the maintainer will adopt it. But it's really hard work to package software like this... :)

rumpelsepp commented on 2014-11-01 09:31

@hunger: It's funny, at the moment I am trying to creae an updated PKGBUILD for gitlab. I will put it on github and we could improve it together.

hunger commented on 2014-11-01 09:27

gitlab.install's fixperms seems way to permissive to me. The last line recursively changes the owner/group of all files in /usr/share/webapps/gitlab to gitlab:gitlab, so the gitlab user ends up able to write to basically all the files. I think removing the "-R" from that line will fix that.

Is it possible to symlink /usr/share/webapps/gitlab/tmp and .../log to places in /tmp and /var/log? I would like to keep the /usr as static as possible:-)

How about adding some security features to the .service files?

InaccessibleDirectories=/boot would definitely not hurt with the setup you have created. ProtectHome=true should also be save, as well as ReadOnlyDirectories=/etc.

CapabilityBoundingSet= (set to empty) should also work with these daemons (and will make it impossible to undo ProtectHome;-).

PrivateTmp=true is something that can be enabled on most daemons, too. Should be save here.

One could even experiment with PrivateNetwork... nginx is handling the external network after all.

NoNewPrivileges=true would make sure the daemon is never going to get any new privileges ever. I *think* that should be ok for gitlab.

Finally you might want to use RuntimeDirectory=, RuntimeDirectoryMode= to get rid of that tmpfiles.d snippet you are using.

The full list of hardening options is available here: http://www.freedesktop.org/software/systemd/man/systemd.exec.html

axil42 commented on 2014-10-31 10:19

Yes, you should rebuild gitlab because some of its gems depend on system libraries.

Garagoth commented on 2014-10-31 08:18

Maybe try recompiling gitlab after upgrading icu.

And1G commented on 2014-10-31 05:24

Is there an other solution than downgrading icu?
I am facing the same issue.
When I had to hold back the icu update on my notebook because of an other package, I had compatiblity issues with other programs. So I kind of want to avoid doing so.

CromFr commented on 2014-10-30 18:58

It seems there is an issue with icu-54.1-1:
LoadError: libicui18n.so.53: cannot open shared object file: No such file or directory - /usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/extensions/x86_64-linux/2.1.0/charlock_holmes-0.6.9.4/charlock_holmes/charlock_holmes.so
Adding a symlink libicui18n.so.53 to libicui18n.so.54 just produces undefined symbol error
Resolved by downgrading to icu-53 (http://seblu.net/a/arm/packages/i/icu/)

Garagoth commented on 2014-10-30 10:46

There is a dependency missing - pkg-build is required to complete "gem install rugged" during makepkg.

rumpelsepp commented on 2014-10-28 08:56

@axil42: Nice, thx. :)

I have spotted another little "issue": We are placing gitlab log in /usr/share/webapps/gitlab/log. I think putting these logs in /var/log/gitlab would better and more logical, wouldn't it? I think /usr/share/webapps/gitlab/log/ could then be replaced with a symlink to /usr/share/webapps/gitlab/log; but don't forget to fix logrotate as well!

axil42 commented on 2014-10-28 08:05

@chris

While you raise a valid point that redis could be an optional dep, I would say that the majority of users don't even bother concerning about redis, it's just plug and play. For someone experienced, I expect them to edit the PKGBUILD to their liking. If we make this change, I'm afraid that people will come complaining that their gitlab installation is broken :/

@rumpelsepp @Lopo

I agree that guessing all the possible web server installations makes the PKGBUILD a little cluttered. I propose to deliver example files and put the rest information to the wiki (which could use a refresh btw).

@rumpelsepp

I will merge the PR at github, thanks. I have write access to upstream repos so feel free to ping me for things like that.

rumpelsepp commented on 2014-10-28 07:37

I have fixed my errors mentioned below. See my pull request here: https://github.com/gitlabhq/gitlab-recipes/pull/238

rumpelsepp commented on 2014-10-28 05:44

gitlab-sidekiq seems to have problems with its pid file:
PID file /var/run/gitlab/sidekiq.pid not readable (yet?) after start.

This results in issues when running with systemd:
`gitlab-sidekiq.service: Supervising process 16365 which is not our child. We'll most likely not notice when it exits.`

Is this a gitlab or a package issue?

rumpelsepp commented on 2014-10-27 08:40

A few thoughts:
- Why do you provide server config files depending on what server is installed? Just do it like the arch devs do [1]: Put example files in "/etc/webapps/gitlab". The current solution is a little bit odd as the package content changes depending on what packages you have installed.
- Why do you build backup arrays depending on what software is installed? Providing example files as mentioned before would give a proper solution for this. What happens if I decide to change my webserver and remove apache? The next gitlab update will overwrite my previous apache config file because it is not in the backup array any more.

[1] https://wiki.archlinux.org/index.php/Web_Application_Package_Guidelines

chris commented on 2014-10-26 12:55

@Lopo: What's to tell? A Redis is required to run gitlab, just as much as a database is needed. Nobody would advocate though that is is necessary to install a database on the same host as the application and the same is true for Redis.
As to the document, it states that Redis is required, it does not advocate in any way on how to deploy this Redis, so how would you like that to change?

Lopo commented on 2014-10-26 12:38

@chris: then tell it to gitlab authors ... https://github.com/gitlabhq/gitlabhq/blob/master/doc/install/requirements.md

chris commented on 2014-10-26 10:30

Redis should be an optional dependency in my opinion.
Although a redis is is mandatory, it is by no means required to be installed on the same host as gitlab.

rumpelsepp commented on 2014-10-26 09:56

@Lopo: Oh sorry I reported the issues on the wrong aur page. Sorry my mistake!

Lopo commented on 2014-10-26 09:55

@rumpelsepp:
/usr/share/webapps/gitlab-shell/.gitlab_shell_secret & /var/lib/gitlab/.ssh/authorized_keys & redis port are gitlab-shell related

anyway, should be fixed now

rumpelsepp commented on 2014-10-25 16:54

I installed and i had to fix several errors:

- /usr/share/webapps/gitlab-shell/.gitlab_shell_secret was missing
- /var/lib/gitlab/.ssh/authorized_keys as missing
- satellites permission (could be set in install script, couldn't it?)
- redis uses a TCP port by default. Gitlab tries to connect to a redis socket by default, so it fails.

Lopo commented on 2014-10-23 08:46

@msloan depends of python versions and config on your system
@sledge looks like problem inside the charlock_holmes gem itself

sledge commented on 2014-10-22 15:54

Just installed ArchBang from 21st October RC, did pacman -Syyu yet yaourt gitlab fails:
==> Edit PKGBUILD ? [Y/n] ("A" to abort)
==> ------------------------------------
==> n

==> WARNING: detected libmariadbclient
==> WARNING: detected postgresql-libs
==> gitlab dependencies:
- ruby>=2.0 (already installed)
- git>=1.7.10 (already installed)
- ruby-bundler>=1.5.2 (already installed)
- gitlab-shell>=2.0.1 (already installed)
- openssh (already installed)
- redis>=2.0 (already installed)
- libxslt (already installed)
- icu (already installed)
- cmake (already installed)


==> Edit gitlab.install ? [Y/n] ("A" to abort)
==> ------------------------------------------
==> n

==> Continue building gitlab ? [Y/n]
==> --------------------------------
==>
==> Building and installing package
==> WARNING: detected libmariadbclient
==> WARNING: detected postgresql-libs
==> Making package: gitlab 7.3.2-2 (Wed Oct 22 16:46:59 BST 2014)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
-> Found gitlab-7.3.2.tar.gz
-> Found gitlab.target
-> Found gitlab-unicorn.service
-> Found gitlab-sidekiq.service
-> Found gitlab.tmpfiles.d
-> Found gitlab.logrotate
-> Found gitlab-apache2.4.conf
-> Found gitlab-ssl-apache2.4.conf
-> Found gitlab.conf
-> Found gitlab-ssl.conf
-> Found gitlab-ssl
-> Found 10-gitlab.conf
==> Validating source files with sha512sums...
gitlab-7.3.2.tar.gz ... Passed
gitlab.target ... Passed
gitlab-unicorn.service ... Passed
gitlab-sidekiq.service ... Passed
gitlab.tmpfiles.d ... Passed
gitlab.logrotate ... Passed
gitlab-apache2.4.conf ... Passed
gitlab-ssl-apache2.4.conf ... Passed
gitlab.conf ... Passed
gitlab-ssl.conf ... Passed
gitlab-ssl ... Passed
10-gitlab.conf ... Passed
==> Extracting sources...
-> Extracting gitlab-7.3.2.tar.gz with bsdtar
==> Starting prepare()...
==> Removing existing pkg/ directory...
==> Starting build()...
==> Fetching bundled gems...
You are replacing the current global value of build.nokogiri, which is currently "--use-system-libraries"
Fetching source index from https://rubygems.org/
Using rake 10.3.2
Using RedCloth 4.2.9
Using ace-rails-ap 2.0.1
Using i18n 0.6.11
Using json 1.8.1
Using minitest 5.3.5
Using thread_safe 0.3.4
Using tzinfo 1.2.2
Using activesupport 4.1.1
Using builder 3.2.2
Using erubis 2.7.0
Using actionview 4.1.1
Using rack 1.5.2
Using rack-test 0.6.2
Using actionpack 4.1.1
Using mime-types 1.25.1
Using polyglot 0.3.4
Using treetop 1.4.15
Using mail 2.5.4
Using actionmailer 4.1.1
Using activemodel 4.1.1
Using arel 5.0.1.20140414130214
Using activerecord 4.1.1
Using bundler 1.7.3
Using thor 0.19.1
Using railties 4.1.1
Using hike 1.2.3
Using multi_json 1.10.1
Using tilt 1.4.1
Using sprockets 2.11.0
Using sprockets-rails 2.1.3
Using rails 4.1.1
Using acts-as-taggable-on 2.4.1
Using asciidoctor 0.1.4
Using descendants_tracker 0.0.3
Using ice_nine 0.10.0
Using axiom-types 0.0.5
Using bcrypt 3.1.7
Using sass 3.2.19
Using bootstrap-sass 3.0.3.0
Using carrierwave 0.9.0
Using timers 1.1.0
Using celluloid 0.15.2

Gem::Ext::BuildError: ERROR: Failed to build gem native extension.

/usr/bin/ruby extconf.rb
checking for main() in -licui18n... yes
checking for main() in -licui18n... yes
checking for unicode/ucnv.h... yes
-- tar zxvf file-5.08.tar.gz
-- ./configure --prefix=/tmp/yaourt-tmp-sim/aur-gitlab/src/gitlabhq-7.3.2/vendor/bundle/ruby/2.1.0/gems/charlock_holmes-0.6.9.4/ext/charlock_holmes/dst/ --disable-shared --enable-static --with-pic
-- patch -p0 < ../file-soft-check.patch
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of necessary
libraries and/or headers. Check the mkmf.log file for more details. You may
need configuration options.

Provided configuration options:
--with-opt-dir
--without-opt-dir
--with-opt-include
--without-opt-include=${opt-dir}/include
--with-opt-lib
--without-opt-lib=${opt-dir}/lib
--with-make-prog
--without-make-prog
--srcdir=.
--curdir
--ruby=/usr/bin/ruby
--with-icu-dir
--without-icu-dir
--with-icu-include
--without-icu-include=${icu-dir}/include
--with-icu-lib
--without-icu-lib=${icu-dir}/lib
--with-icui18nlib
--without-icui18nlib
--with-icui18nlib
--without-icui18nlib
extconf.rb:7:in `sys': patch -p0 < ../file-soft-check.patch failed, please report issue on http://github.com/brianmario/charlock_holmes (RuntimeError)
from extconf.rb:61:in `block (2 levels) in <main>'
from extconf.rb:59:in `chdir'
from extconf.rb:59:in `block in <main>'
from extconf.rb:55:in `chdir'
from extconf.rb:55:in `<main>'

extconf failed, exit code 1

Gem files will remain installed in /tmp/yaourt-tmp-sim/aur-gitlab/src/gitlabhq-7.3.2/vendor/bundle/ruby/2.1.0/gems/charlock_holmes-0.6.9.4 for inspection.
Results logged to /tmp/yaourt-tmp-sim/aur-gitlab/src/gitlabhq-7.3.2/vendor/bundle/ruby/2.1.0/extensions/x86-linux/2.1.0/charlock_holmes-0.6.9.4/gem_make.out
An error occurred while installing charlock_holmes (0.6.9.4), and Bundler cannot
continue.
Make sure that `gem install charlock_holmes -v '0.6.9.4'` succeeds before
bundling.
==> ERROR: A failure occurred in build().
Aborting...
==> ERROR: Makepkg was unable to build gitlab.


many thanks for help

msloan commented on 2014-10-17 22:31

I had to install python-docutils not python2-docutils to get reStructuredText markup language support working.

kidoz commented on 2014-10-05 21:42

@Lopo
Can you add 'armv7h' to arch and 'nodejs' to depends?

kidoz commented on 2014-10-05 21:40

@Lopo

kidoz commented on 2014-10-05 21:28

@Lopo
Can you add 'armv7h' to arch and options=('staticlibs')?

bgaleotti commented on 2014-09-24 13:15

7.3.1 is out

simonzack commented on 2014-08-26 20:19

To configure gitlab to run in a subdirectory, application.rb needs to be modified. Can this be moved to /etc/ as well for convenience when updating?

axil42 commented on 2014-08-09 07:12

@fiveop https://wiki.archlinux.org/index.php/AUR#Prerequisites

fiveop commented on 2014-08-08 17:38

In order to run makepkg for this package, I had to install the following packages on my system: patch, make, gcc, and binutils.

axil42 commented on 2014-07-30 05:59

@diversifizierer install ruby-bundler from AUR instead of installing it for just your user. It is dependency of gitlab, how come you missed it?

diversifizierer commented on 2014-07-29 21:50

This may not be very important, but the packaging procedure fails despite having bundler installed on my system. (This has been done with $ gem install bundler --no-user-install)

Is there a simple and elegant way to fix that for the sake of convenience?

Tahvok commented on 2014-07-17 10:42

After latest move to mariadb 10, you should run (after system update):
gem update
I have also rebuilded and reinstalled gitlab again, though it may be not necessary.

BunBum commented on 2014-07-11 06:21

@Lopo, @ianto thank you for your help. I changed the arch array to ('any'). Then the installer runs. Unfortunately I get now following error. It seems that it was not made for the ARM system.

linking shared-object v8/init.so
/usr/bin/ld: /tmp/yaourt-tmp-me/aur-gitlab/src/gitlabhq-7.0.0/vendor/bundle/ruby/2.1.0/gems/libv8-3.16.14.3/vendor/v8/out/arm.release/obj.target/tools/gyp/libv8_base.a(api.o): relocation R_ARM_MOVW_ABS_NC against `_ZN2v88internal7Isolate12isolate_key_E' can not be used when making a shared object; recompile with -fPIC
/tmp/yaourt-tmp-me/aur-gitlab/src/gitlabhq-7.0.0/vendor/bundle/ruby/2.1.0/gems/libv8-3.16.14.3/vendor/v8/out/arm.release/obj.target/tools/gyp/libv8_base.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
Makefile:232: recipe for target 'init.so' failed
make: *** [init.so] Error 1

make failed, exit code 2

Lopo commented on 2014-07-09 18:10

@BunBum, @ianto: https://wiki.archlinux.org/index.php/Arch_Packaging_Standards#Architectures

"The arch array should contain 'i686' and/or 'x86_64' depending on which architectures it can be built on. You can also use 'any' for architecture independent packages. "

'any' was replaced recently to prevent copying from arch to arch, because there are compiled binaries
and there isn't other enabled architecture - so if you want to use any package from AUR, you have to modify PKGBUILD

ianto commented on 2014-07-09 14:14

@BunBum if you edit the PKGBUILD so that ARCH is 'any' or contains 'armv7h' it should then try to compile itself for the architecture in use. I had the same problem with my rPi and post-install it works as I'd expect a local gitlab installation to work.

@Lopo the only change I made to the PKGBUILD was as stated above adding 'armv6h' to the ARCH array. My rPi uses the armv6h architecture.

BunBum commented on 2014-07-09 14:03

gitlab is not available for the 'armv7h' architecture. Is there a reason for this issue? I am using an Odroid U3 and would like to use gitlab on it.

Lopo commented on 2014-07-09 04:47

@ianto: "... I'm using a Raspberry Pi ..." - this package isn't meant to be used on rPi ... can require some changes for use

I'll do some test on minimal Arch install if this problem is also on PC architecture

axil42 commented on 2014-07-08 18:51

Interesting. So you need python2 at least in makedepends.

ianto commented on 2014-07-08 18:50

I didn't proofread that message very well, I meant system and not sister.

Anyway here is the output of "packer -S gitlab" starting from just before the error occuring:
Installing jquery-turbolinks 2.0.1
Installing jquery-ui-rails 4.2.1
Installing jwt 0.1.8
Installing kaminari 0.15.1
Installing kgio 2.8.1

Gem::Ext::BuildError: ERROR: Failed to build gem native extension.

/usr/bin/ruby extconf.rb
creating Makefile
which: no python2 in (/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/core_perl:/usr/local/rvm/bin)
/tmp/packerbuild-0/gitlab/gitlab/src/gitlabhq-7.0.0/vendor/bundle/ruby/2.1.0/gems/libv8-3.16.14.3/ext/libv8/builder.rb:58:in `setup_python!': libv8 requires python 2 to be installed in order to build, but it is currently 3.4.1 (RuntimeError)
from /tmp/packerbuild-0/gitlab/gitlab/src/gitlabhq-7.0.0/vendor/bundle/ruby/2.1.0/gems/libv8-3.16.14.3/ext/libv8/builder.rb:42:in `block in build_libv8!'
from /tmp/packerbuild-0/gitlab/gitlab/src/gitlabhq-7.0.0/vendor/bundle/ruby/2.1.0/gems/libv8-3.16.14.3/ext/libv8/builder.rb:40:in `chdir'
from /tmp/packerbuild-0/gitlab/gitlab/src/gitlabhq-7.0.0/vendor/bundle/ruby/2.1.0/gems/libv8-3.16.14.3/ext/libv8/builder.rb:40:in `build_libv8!'
from /tmp/packerbuild-0/gitlab/gitlab/src/gitlabhq-7.0.0/vendor/bundle/ruby/2.1.0/gems/libv8-3.16.14.3/ext/libv8/location.rb:24:in `install!'
from extconf.rb:7:in `<main>'

extconf failed, exit code 1

Gem files will remain installed in /tmp/packerbuild-0/gitlab/gitlab/src/gitlabhq-7.0.0/vendor/bundle/ruby/2.1.0/gems/libv8-3.16.14.3 for inspection.
Results logged to /tmp/packerbuild-0/gitlab/gitlab/src/gitlabhq-7.0.0/vendor/bundle/ruby/2.1.0/extensions/armv6l-linux/2.1.0/libv8-3.16.14.3/gem_make.out
An error occurred while installing libv8 (3.16.14.3), and Bundler cannot continue.
Make sure that `gem install libv8 -v '3.16.14.3'` succeeds before bundling.
==> ERROR: A failure occurred in build().
Aborting...
The build failed.

ianto commented on 2014-07-08 18:48

I didn't proofread that message very well, I meant system and not sister.

Anyway here is the output of "packer -S gitlab" starting from juts before the error occuring:
Installing jquery-turbolinks 2.0.1
Installing jquery-ui-rails 4.2.1
Installing jwt 0.1.8
Installing kaminari 0.15.1
Installing kgio 2.8.1

Gem::Ext::BuildError: ERROR: Failed to build gem native extension.

/usr/bin/ruby extconf.rb
creating Makefile
which: no python2 in (/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/core_perl:/usr/local/rvm/bin)
/tmp/packerbuild-0/gitlab/gitlab/src/gitlabhq-7.0.0/vendor/bundle/ruby/2.1.0/gems/libv8-3.16.14.3/ext/libv8/builder.rb:58:in `setup_python!': libv8 requires python 2 to be installed in order to build, but it is currently 3.4.1 (RuntimeError)
from /tmp/packerbuild-0/gitlab/gitlab/src/gitlabhq-7.0.0/vendor/bundle/ruby/2.1.0/gems/libv8-3.16.14.3/ext/libv8/builder.rb:42:in `block in build_libv8!'
from /tmp/packerbuild-0/gitlab/gitlab/src/gitlabhq-7.0.0/vendor/bundle/ruby/2.1.0/gems/libv8-3.16.14.3/ext/libv8/builder.rb:40:in `chdir'
from /tmp/packerbuild-0/gitlab/gitlab/src/gitlabhq-7.0.0/vendor/bundle/ruby/2.1.0/gems/libv8-3.16.14.3/ext/libv8/builder.rb:40:in `build_libv8!'
from /tmp/packerbuild-0/gitlab/gitlab/src/gitlabhq-7.0.0/vendor/bundle/ruby/2.1.0/gems/libv8-3.16.14.3/ext/libv8/location.rb:24:in `install!'
from extconf.rb:7:in `<main>'

extconf failed, exit code 1

Gem files will remain installed in /tmp/packerbuild-0/gitlab/gitlab/src/gitlabhq-7.0.0/vendor/bundle/ruby/2.1.0/gems/libv8-3.16.14.3 for inspection.
Results logged to /tmp/packerbuild-0/gitlab/gitlab/src/gitlabhq-7.0.0/vendor/bundle/ruby/2.1.0/extensions/armv6l-linux/2.1.0/libv8-3.16.14.3/gem_make.out
An error occurred while installing libv8 (3.16.14.3), and Bundler cannot continue.
Make sure that `gem install libv8 -v '3.16.14.3'` succeeds before bundling.
==> ERROR: A failure occurred in build().
Aborting...
The build failed.

axil42 commented on 2014-07-08 18:16

btw for the rpi you can omit the rubyracer gem and install nodejs instead, should any problems arise during building.

ianto commented on 2014-07-08 17:22

I didn't proofread that message very well, I meant system not sister.

axil42, I will just let my Pi try to build it this time without Python installed but it may take some time for this information to be provided due to how slow the Pi is with CPU intensive tasks.

axil42 commented on 2014-07-08 17:16

python should not be a build/runtime dependency unless you want to support .rst files properly formatted. Do you recall which gem failed to build?

ianto commented on 2014-07-08 16:14

I recently tried building this with packer on a fresh install of Arch Linux without Python. During the build phase the gem install failed due to not having /usr/bin/python or /usr/bin/python2 (I suspect version is the requirement and not 3) on my sister. I'd recommend adding those as dependencies unless I am mistaken in my undertanding of what happened with this error. I have since installed Python2 and did not record exactly the error message, after installing the bundle gem install succeeded and I was able to install gitlab correctly.

For me to retest this without python installed to get an error it would take over an hour as I'm using a Raspberry Pi to host a local gitlab site. After fixing many errors, mostly due to insufficient RAM and space in /tmp and then later finding out that python2 was a requirement I have spent many hours in the compilation stages to get this working.

Hopefully you can add python2 as a dependency to avoid this happening in future for other users. :)

Lopo commented on 2014-06-05 11:02

@niqingliang2003: https://aur.archlinux.org/packages/gitlab-ci/ ;)

maybe not perfect, but functional on my vps

pschmitt commented on 2014-05-28 15:53

@Tahvok You should be save. Updates are pretty smooth. Just do what the post_install function tells you to do.

Tahvok commented on 2014-05-26 08:41

How should I proceed with updating the system?
Is the package made for update as well? Will it not overwrite my configs?

Lopo commented on 2014-05-21 05:16

@niqingliang2003: working on it ;)

niqingliang2003 commented on 2014-05-21 02:18

can we have gitlab-ci?

Lopo commented on 2014-05-19 06:29

@wrm: and which one ? they are equal and you can't force pgsql to mariadb user and vice versa ...
and they are hard required, not build only

rumtata commented on 2014-05-18 17:00

The build currently fails with this error:
-> Install at least libmariadbclient or postgresql-libs

I would suggest adding either of one as build-deps at least.

jonkristian commented on 2014-05-18 01:01

Figured out my issue. gitlab.conf for apache needs to change, see this: https://github.com/Chluz/gitlab-recipes/commit/125a2d1f6533f725f615719850f3489e618b03fc

See line: 14

jonkristian commented on 2014-05-18 00:28

Well, something is not right. all assets returns 404. I did assets:clean/precompile etc... but that did not seem to work. So any ideas?

Lopo commented on 2014-04-30 13:22

@axil42: updated to use -j argument ;)
better than nproc is using /proc/cpuinfo - nproc reports HTs as cores, cpuinfo reports just physical cores
it looks like bundler has some problem when -j is greater than number of physical cores

axil42 commented on 2014-04-25 12:04

@Lopo I just tried with latest bundler and I had no problem with `bundle install -j5` on my machine. Anyway thanks for considering it :)

Lopo commented on 2014-04-25 11:43

@axil42: next versions will be with arch=(i686 x86_64) because of compiled libs - just to prevent hard copying pkg from system with one arch into another arch system
parallel install - tested now, but it fails: "/usr/lib/ruby/gems/2.1.0/gems/bundler-1.6.2/lib/bundler/installer.rb:303:in `install_in_parallel': undefined method `[]' for nil:NilClass (NoMethodError)"
after restart it continues, but then it again fails (same msg) ... makepkg finishes on 3rd-4th try ...
So I'll add jobs number nproc-1 (for nproc>2)
when it will be fully functional

axil42 commented on 2014-04-25 10:37

@Rulatir: They get compiled during build time. Check in `/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/extensions/x86_64-linux/2.1.0/` to see what gems are built that way. So I guess if you try to install this package when built on x86_64 it will fail at i686 arches.

@Lopo: Consider adding a comment that bundler supports parallel gem installation, see https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/install/installation.md#install-gems

Rulatir commented on 2014-04-25 09:39

@axil42: I think a package "has architecture" whenever it contains compiled machine code. Those compiled extensions - are they compiled when the package is built, or only when it is installed? In the former case I believe it needs to have specific architecture.

@Lopo: nothing gets written to any log under /usr/share/webapps/gitlab/log when the sidekiq service fails to start.

Lopo commented on 2014-04-25 06:42

@axil42: I don't think that arch=any is problem - there's no need to detect current architecture (like drivers do) ... but i'll do some tests and maybe i'll change my mind

remove vendor/build and then run bundle install after icu update - i'm afraid, that this must be done only by hand - icu can't do it and gitlab has no chance to detect that icu is updating

@Rulatir: look into /usr/share/webapps/gitlab/log/sidekiq.log and other logs around for more info what's wrong

@magikmw: looks like the makepkg process was killed externally
postifx - thx, fixed

magikmw commented on 2014-04-25 02:10

I've built the package succesfuly on another system and transfered it over to my server, so I guess that's not important anymore.

optdepends=(
'mariadb: database backend'
'postgresql: database backend'
'python2-docutils: reStructuredText markup language support'
'postifx: mail server in order to receive mail notifications'
)

Surely this was ment to be postfix?

magikmw commented on 2014-04-25 00:55

Hello, my build crashes with this error:
==> Fetching bundled gems...
Fetching source index from https://rubygems.org/
/tmp/yaourt-tmp-magikmw/aur-gitlab/./PKGBUILD: line 96: 7386 Killed bundle install --no-cache --no-prune --deployment --without development test aws ${_wo[@]}
==> ERROR: A failure occurred in build().

I tried to debug this myself, but there is no other message. I'm not sure what to even look for.

Rulatir commented on 2014-04-24 15:21

@axil42 re: charlock_holmes - my obvious_when_explained.txt just gained another line, thanks! ;)

But now I have a different problem: I cannot start sidekiq "legally" with systemctl. Here's what I get:

$ sudo systemctl status gitlab-sidekiq
● gitlab-sidekiq.service - GitLab Sidekiq Worker
Loaded: loaded (/etc/systemd/system/gitlab-sidekiq.service; enabled)
Active: failed (Result: exit-code) since czw 2014-04-24 17:12:07 CEST; 10s ago
Process: 904 ExecStart=/usr/bin/bundle exec sidekiq -q post_receive,mailer,system_hook,project_web_hook,gitlab_shell,common,default -e production -P tmp/pids/sidekiq.pid -d -L log/sidekiq.log >> log/sidekiq.log 2>&1 (code=exited, status=200/CHDIR)

kwi 24 17:12:07 berbelek systemd[1]: gitlab-sidekiq.service: control process exited, code=exited status=200
kwi 24 17:12:07 berbelek systemd[1]: Failed to start GitLab Sidekiq Worker.
kwi 24 17:12:07 berbelek systemd[1]: Unit gitlab-sidekiq.service entered failed state.

$ sudo journalctl -xn
-- Logs begin at pon 2014-01-27 19:59:31 CET, end at czw 2014-04-24 17:13:09 CEST. --
kwi 24 17:12:07 berbelek systemd[904]: Failed at step CHDIR spawning /usr/bin/bundle: No such file or directory
-- Subject: Process /usr/bin/bundle could not be executed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- The process /usr/bin/bundle could not be executed and failed.
--
-- The error number returned while executing this process is 2.
kwi 24 17:12:07 berbelek systemd[1]: gitlab-sidekiq.service: control process exited, code=exited status=200
kwi 24 17:12:07 berbelek systemd[1]: Failed to start GitLab Sidekiq Worker.
-- Subject: Unit gitlab-sidekiq.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit gitlab-sidekiq.service has failed.
--
-- The result is failed.


Strangely enough when I do manually what the service file specifies (su gitlab, cd /usr/share/webapps/gitlab, execute the command specified in ExecStart) then it works. It is not the case of systemd erroneously believing that the service failed: gitlab is actually unavailable after an attempt to start it with systemctl, but becomes available when I start it manually.

axil42 commented on 2014-04-24 13:38

Also I have my concerns that this package should not be of `any` arch since it contains gems with binary extensions that need compilation.

axil42 commented on 2014-04-24 13:27

charlock_holmes needs icu. So every time icu gets an update, charlock_holmes needs to be rebuilt against icu. One way is to remove `vendor/bundle` dir and run `bundle install` again. I guess it could be included in the PKGBUILD or in an .install file.

qguv commented on 2014-04-24 11:49

@Rulatir: So "basically" icu fails to start, but what precisely is the reason? We can't even begin to fathom what is going wrong if we have no logs, etc. to examine. The status subcommand of systemctl might be a good start.

Also, if "gitlab is mission-critical", why are you running it on the same machine as Libreoffice? You ought to at least consider running on a proper headless install if it's so crucial. If you're running it locally with just one user, you might want to consider setting up something like Git Cola for visualization and a small Git-remote for backup/collaboration. It may be less of a big deal to maintain that.

Lopo commented on 2014-04-24 08:50

@Rulatir: and any closer info about that problem ? now i don't know anything, just "there's a problem" ...

Rulatir commented on 2014-04-24 08:46

There is a 100% reproducible recurring problem that happens whenever the distro's version of the icu package is updated. Basically, gitlab services refuse to start. Since gitlab is mission-critical for me, I am forced to keep icu in IgnorePkg and only upgrade it when I have the time and courage to upgrade gitlab too. But this cripples my system because software that requires updated versions of icu stops working - most regrettably LibreOffice.

Is there a way to permanently solve this problem so that distro's updates to icu won't *immediately* force me to choose between a dangerous, schedule-wrecking gitlab upgrade and a crippled system without LibreOffice? IgnorePkg every last thing that depends on icu directly or indirectly?

Saren commented on 2014-04-11 18:33

Clicked "Flag package out-of-date" accidentally.
Sorry and please revert this

Saren commented on 2014-04-11 18:28

==> Packages no longer required by any installed package:
icu

This is FALSE. DO NOT UNINSTALL icu.

If you uninstalled icu you will likely to get this following error:

/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/activesupport-4.0.3/lib/active_support/dependencies.rb:229:in `require': libicui18n.so.52: cannot open shared object file: No such file or directory - /usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/extensions/x86_64-linux/2.1.0/charlock_holmes-0.6.9.4/charlock_holmes/charlock_holmes.so (LoadError)

Saren commented on 2014-04-11 18:25

==> Packages no longer required by any installed package:
icu

This is false. If you uninstalled icu you will get this following error:

/usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/gems/activesupport-4.0.3/lib/active_support/dependencies.rb:229:in `require': libicui18n.so.52: cannot open shared object file: No such file or directory - /usr/share/webapps/gitlab/vendor/bundle/ruby/2.1.0/extensions/x86_64-linux/2.1.0/charlock_holmes-0.6.9.4/charlock_holmes/charlock_holmes.so (LoadError)

axil42 commented on 2014-04-04 10:16

modernizr problem fixed with 6.7.3.

Also the problem about the changing checksums is on its way to get resolved. It appears it only affected gzip archives. See https://github.com/gitlabhq/gitlab_git/issues/32

theflyingfool commented on 2014-04-03 23:54

@mappi & Saren, if you are still having this problem going into the source directory and changing modernizr 2.6.2 to modernizr-rails 2.71 in both the Gemfile and Gemfile.lock (two locations in the latter) will cause it to build. Related note make sure to use the -e flag with makepkg if your doing that. it is still building for me, but after a google search I did find that solution somewhere on the gitlab site.

theflyingfool commented on 2014-04-03 23:36

Also having the same problem as @Saren, doing a little searching modernizr 2.6.2 is no longer available form rubygems.org

mappi commented on 2014-04-03 22:10

Hi, I have the same error as @Saren

Saren commented on 2014-04-03 20:09

Is that happening to everyone or just me?

Could not find modernizr-2.6.2 in any of the sources
==> ERROR: A failure occurred in build().
Aborting...
==> ERROR: Makepkg was unable to build gitlab.

TheReverend403 commented on 2014-04-02 12:36

Fantastic, works now.

Lopo commented on 2014-04-02 12:29

mea culpa

axil42 commented on 2014-04-02 12:18

Oh yeah, it's because we changed the source url...

@Lopo you may want to assign the extracted dir to a variable.

TheReverend403 commented on 2014-04-02 12:15

Getting an error on upgrade.

http://paste.revthefox.co.uk/view.php?id=533bff4f9e9bb

TheReverend403 commented on 2014-04-02 12:14

Getting this error when upgrading ._.

http://paste.revthefox.co.uk/view.php?id=533bfe9532a19

Lopo commented on 2014-04-02 10:27

source URL is now github

caleb commented on 2014-04-02 10:08

@axil42 Done.

axil42 commented on 2014-04-02 09:42

I just ran a directory diff between today's tar and a previous one and as I had suspected there were no differences.

This points to be a bug in the tag release, GitLab devs do not change the tag release every now and then :p

Nevertheless, I also downloaded the 6.7.2.tar.gz from Github and we shall see if tomorrow the checksum will change as well :)

@caleb can you maybe change the title of the bug to be descriptive to this situation? https://github.com/gitlabhq/gitlabhq/issues/6662

alekpr commented on 2014-04-01 18:19

If you go through the sums in the PKGBUILD file, change the first sum in the list to 6db6c62204dd57281f514fc1829294398b5a6aa22431e032dbf086fabad30e2bf1505b32719af23de4708a36bc73a1c33ff413462b6ce67ba12700ff156f011f

Lopo commented on 2014-04-01 16:17

@axil42 ... ah ... i'm blind .. you wrote github ...
ok, i'll check hashes from github release files and we'll see if it's better than gitlab

axil42 commented on 2014-04-01 11:16

@Lopo I meant that if the tag was indeed changed, then it would show a more recent date. As I pointed in my previous comment, change the source to point at github and see if this persists. If yes then its upstream's fault, if not there is a bug that changes the checksum. Maybe a long shot but it's worth the try ;)

vianney commented on 2014-03-31 17:05

I see.

Did somebody try to make a diff of the extracted files to know if they actually change beetween archives or if the only informations that really change are things such as the archive's date creation?

qguv commented on 2014-03-31 15:34

@vbouchaud: Just because Gitlab seems incapable of releasing zipped archives of versions which hash to the same value doesn't necessarily mean the software isn't stable, it just means they're doing it wrong in terms of zipping releases. This isn't a consequence of them being in v0.x.y, it's just the result of lazy packaging. If it were the former, we'd already be skipping the checksum.

vianney commented on 2014-03-31 15:08

@caleb: since the tar.gz change so often, I don't consider it that much stable...

caleb commented on 2014-03-31 14:15

@vabouchaud Skipping checksums is alright for devel packages built directly from source repository HEADs but completely inappropriate for packages with stable release points.

vianney commented on 2014-03-31 11:43

Maybe we should start considering using the value 'skip' in the sha512sum array?

Lopo commented on 2014-03-31 11:02

@axil42 - which concrete link do you mean ? because on https://gitlab.com/gitlab-org/gitlab-ce/tags there is only 1 link to tar.gz with required version, and thats what we're using now ...

axil42 commented on 2014-03-31 10:35

As far as I can see, the 6.7.2 tag was released 10 days ago and not edited since [0]. I can't understand why it changes the checksum, something tells me this could be a bug related to the PR that got archived tags into gitlab[1].

@Lopo try to use github's tag url to see if this persists.


[0] https://gitlab.com/gitlab-org/gitlab-ce/tags
[1] https://github.com/gitlabhq/gitlabhq/pull/5891

caleb commented on 2014-03-31 10:32

Anybody sufficiently tired of this package breaking for no good reason please weigh in on this upstream issue so they get the point that re-releasing the package without bumping the version number is not cool:

https://github.com/gitlabhq/gitlabhq/issues/6662

onny commented on 2014-03-31 09:47

checksum fails on: gitlab-6.7.2.tar.gz :(

vianney commented on 2014-03-30 22:50

Waw, I started installing gitlab on my rpi at ~18:00, it's now ~00:45 and it just finished with success.

vianney commented on 2014-03-30 17:56

You know the song:
a2897313d4267b404005cd3744bd1c0bb6c9bf72f4135d4ace1173435c8310d2f04ac3e4b032ff326c4d1b1aa86d30c787d905bdd956e2c00f60d8d3298e9a6b

@Lopo: Thanks for your suggestions, I already checked disk space with no success (I exported TEMPDIR to a hard drive with few hundred Gb free).
I'll keep trying to install it on my rpi but also consider testing it in a virtual machine.
I also tought maybe the "Make sure that `gem install ace-rails-ap -v '2.0.1'` succeeds before bundling." line was what did not happen these different times (though I can't find a reason why).

axil42 commented on 2014-03-29 07:56

Some remarks:

* python2 is no longer a dependency
* Add your name as maintainer
* I would drop versions from dependencies since in Arch there always the latest ones (I remember there was a discussion about this in arch-general)

;)

robvelor commented on 2014-03-27 21:33

and again...

4f738da40d241c1dfd820c6be34f888ecb129e01fcf1402197f483aceab1036cab4f829ef8b24ff75db821e4beb8ac562e6a571f73512f710285e01c47bda715

Lopo commented on 2014-03-27 07:46

@vbouchaud: it looks like there's an error by download of that gem ... check free space on disc/card etc ... because it requires a lot of small files when installing required gems
i don't have any other idea what can be wrong ... and no time to test it on my rPi

vianney commented on 2014-03-26 20:41

Hi again.

I'm trying to install this package on a raspberry and it looks like it's the third time I get this error:

Bundler::GemspecError: Could not read gem at /space/junks/vianney/documents/tempfile/yaourt-tmp-vianney/aur-gitlab/src/gitlab-ce.git/vendor/bundle/ruby/2.1.0/cache/ace-rails-ap-2.0.1.gem. It may be corrupted.
An error occurred while installing ace-rails-ap (2.0.1), and Bundler cannot continue.
Make sure that `gem install ace-rails-ap -v '2.0.1'` succeeds before bundling.
==> ERROR: A failure occurred in build().
Aborting...
==> ERROR: Makepkg was unable to build gitlab.
==> Restart building gitlab ? [y/N]
==> -------------------------------
==>

And nothing more.
Does somebody know anything abaut that? The file ace-rails-ap-2.0.1.gem looks good to me.

vianney commented on 2014-03-26 13:10

Looks like they did it again... 186ca89d11dd757be384f6c361426cb870a40df1b0d63bcce00c46e2762d97efc942c2bc9be5f52f79828a4be94d1e73412fa4dc73f01365fd97fe61bbea97ce for gitlab-6.7.2.tar.gz

Lopo commented on 2014-03-24 09:11

eh ... i hate when they change package on same version

onny commented on 2014-03-24 09:06

checksum fails on: gitlab-6.7.2.tar.gz

Lopo commented on 2014-03-24 08:33

updated to 6.7.2

EsterniTY commented on 2014-03-22 08:26

==> ERROR: One or more files did not pass the validity check!
Here is correct sha512sum
6cad56bc89914190d1a1365fbceb2124c10e51917811cd91995f710ba86801648659ab4c448135f25ac42038b450bd7355084435d0a99dae8825e0d9d8469072

Lopo commented on 2014-03-21 16:58

fresh new 6.7.0 out in less than an hour from release ;)

onny commented on 2014-03-21 15:04

@caleb: You're right. I'm not that active right now so it's better Lopo or someone else adopts this package.

caleb commented on 2014-03-17 14:24

Hey @onny, this is getting pretty out of date for a fast moving project. Most of us are having to hack together our own installs instead of having something in the AUR that works. If you aren't going to keep it more up to date than this can you disown it so one of us can pick up the slack? I for one would be willing to.

cooperong commented on 2014-03-17 09:13

new hash code=bb056a4b53faeafe859db772a01193ea290c13caa6d28cda16222c6671a95a233e09f861eba2b39ed4eb791cbd85e5b13025a1cd7e53e6301986563148af8d00

isiachi commented on 2014-03-08 13:07

libxslt is not a makedependence but a dependence without it the gitlab-sidekiq service doesn't run.

underdoeg commented on 2014-03-06 13:47

I get

ERROR: One or more files did not pass the validity check!

Lopo commented on 2014-03-03 09:50

I've updated my gist:
- fixed args for ln
- removed git user settings in install (already in gitlab-shell)
- updated Upstream URL
- version 6.6.4

Lopo commented on 2014-03-03 07:48

@onny: Upstream URL with https is invalid ... "Connecting to www.gitlab.org (www.gitlab.org)|176.32.97.196|:443... failed: Connection refused."
http version is OK
https works only as https://gitlab.org, but that redirects to dev.gitlab.org login
best to use is http://gitlab.org/gitlab-ce/ - direct to used CE version

Lopo commented on 2014-02-11 16:58

@caleb: fixed a few days ago in my gist version ... now it's up to onny to implement it here

caleb commented on 2014-02-11 15:18

Needs backup('gitlab.conf' 'gitlab-ssl.conf'). Upgrading just nuked my apache configs!

trusktr commented on 2014-02-09 08:24

I found yet one more issue. I had to add

install -d "${pkgdir}/run/gitlab"

to PKGBUILD, right before the lines where pids and sockets are linked to /run/gitlab.

I also had to add this to gitlab.install fix_perms():

chown -R git:git "/run/gitlab"

Without adding those lines to PKGBUILD and gitlab.install the /run/gitlab folder will fail to be created, and gitlab-sidekiq.service will fail to start. I'm not sure why this is a problem now, but it wasn't before.

This is what my PKGBUILD gist looks like: https://gist.github.com/trusktr/8896135

trusktr commented on 2014-02-08 21:56

@Lopo, Sweet. I also noticed that gitlab.install has user-deploy(), which is better left to gitlab-shell to avoid duplicity.

Lopo commented on 2014-02-08 11:06

@trusktr, @onny gist updated:
- fixed url
- added support for multi http servers
- fixed _wo
- removed useradd/userdel from gitlab.install - duplicity with gitlab-shell which is dependency of gitlab

trusktr commented on 2014-02-08 01:02

@onny @ferllings @onny @Lopo,
Yep, confirmed. /bin/false should be changed to /bin/bash.

Additionally, the following can be added to ~gitlab/.ssh/config to prevent password login and allow only key-based login (like what github.com does):

Match User gitlab
PasswordAuthentication no

I'm gonna leave a comment at https://aur.archlinux.org/packages/gitlab-shell with a suggested new PKGBUILD and gitlab-shell.install.

Apes commented on 2014-02-07 22:45

@onny If you toss this project up on Github, I would be willing to put in some pull requests to help you out with this project.

Apes commented on 2014-02-07 22:39

@onny The package changes the owner/group on a lot of files under /usr/share/webapps/gitlab to root:root on upgrade, which requires a manual change back to gitlab:gitlab.

Apes commented on 2014-02-07 21:12

@onny @trusktr @ferllings gitlab-shell uses command restriction via the authorized_keys file to run /usr/share/gitlab-shell/bin/gitlab-shell

For command restricted keys, OpenSSH runs the command listed in the authorized_keys file via "$SHELL -c". Therefore, if gitlab user's shell is set to /bin/false, the restricted command cannot run.

The Package is incorrect in setting the gitlab user's shell to /bin/false. It should be set to /bin/bash.

Apes commented on 2014-02-07 20:42

@trusktr @ferllings I think the correct solution is to change the shell for gitlab user to /usr/share/gitlab-shell/bin/gitlab-shell

trusktr commented on 2014-02-07 02:34

@ferllings changing /bin/false to /bin/bash is definitely *not* recommended if you wish for your gitlab installation remain secure. You should find a different solution.

trusktr commented on 2014-02-07 02:34

@ferllings changing /bin/false to /bin/bash is definitely not recommended if you wish your gitlab installation to be secure.

ferllings commented on 2014-02-06 19:56

I had the same issue described here: https://bbs.archlinux.org/viewtopic.php?id=176189

The solution was to change /bin/false to /bin/bash for gitlab

trusktr commented on 2014-02-06 03:28

@Lopo I have more than one server installed, on different ports. It's not too rare. xD
Adding a few plus signs isn't too much more complex than it already is.

That being said, it's really not difficult to modify PKGBUILD before building to suit specific needs. :)

trusktr commented on 2014-02-06 03:27

@Lopo I have more than one server installed, on different ports. It's not too rare. xD
Adding a few plus signs isn't too much more complex than it already is.

That being said, it's really not difficult to modify PKGBUILD before making to suit specific needs. :)

trusktr commented on 2014-02-06 03:12

@Lopo I have more than one server installed, on different ports. It's not too rare. xD
Adding a few plus signs isn't too much more complex than it already is.

Lopo commented on 2014-02-05 17:12

@onny: you need to move backup() of ruby confs before http server checks - now it rewrites
@trusktr: having installed more than 1 http server is very rare, we can say that only in special situations ... and then it's still required to setup it all by hand ... so i don't think that we need to complicate PKGBUILD for just a few rare special situations

trusktr commented on 2014-02-02 21:12

Nevermind about my error in my last comment. It's because I was using quotes which messes the command up.

trusktr commented on 2014-02-02 19:52

@Lopop Hey, just checked your gist: _server also needs the += assignment so it works with the case statement at the end. Some people might have more than one server installed.

So now that I've gotten it installed, I can't get gitlab-unicorn to start. The gitlab-unicorn.service fails with no useful output. So to debug I'm running:

sudo -u gitlab bundle exec "unicorn_rails -c /usr/share/webapps/gitlab/config/unicorn.rb -E production" --verbose

That result in a error saying:

bundler: command not found: unicorn_rails -c /usr/share/webapps/gitlab/config/unicorn.rb -E production
Install missing gem executables with `bundle install`

Any idea why?

Lopo commented on 2014-02-02 12:32

@trusktr:
- += assignment is fixed in my gist version from yesterday
- pids dir is created in gitlab.install using systemd-tmpfiles - and doesn't need to exist when calling ln -fs
- patch is part of base-devel pkg group, which is "required" for makepkg - Packages belonging to this group are not required to be listed as dependencies in PKGBUILD files => https://wiki.archlinux.org/index.php/Makepkg#Usage

trusktr commented on 2014-02-02 04:51

I discovered that if you don't have `patch` installed from the official repos then this makepkg will fail (it errors out when `bundle install` tries to install the `charlock_holmes` gem).

Should `patch` be added to makedepends to fix the issue?

trusktr commented on 2014-02-01 23:16

On line 110 of PKGBUILD, I see:

ln -fs /run/gitlab "${pkgdir}${_homedir}/pids"

But that that folder has to exist for the command to be successfuly. The only possible time I see when it might be created is during the "bundle install" command of build() phase, which happens after "/home/git/gitlab/tmp/.*/" is replaced with "/var/run/gitlab/" in unicorn.rb of the prepare() phase.

Is that the case?

The "${pkgdir}${_homedir}/pids" folder must have also been created during "bundle install" because I don't see it created anywhere else. Just want to make sure.

I still haven't gotten gitlab to build successfully so I'm just going through the PKGBUILD to figure out what's going on.

trusktr commented on 2014-02-01 23:12

On line 110 of PKGBUILD, I see:

ln -fs /run/gitlab "${pkgdir}${_homedir}/pids"

But that that folder has to exist for the command to be successfuly. The only possible time I see when it might be created is during the "bundle install" command of build() phase, which happens after "/home/git/gitlab/tmp/.*/" is replaced with "/var/run/gitlab/" in unicorn.rb of the prepare() phase.

Is that the case?

trusktr commented on 2014-02-01 23:12

On line 110 of PLGBUILD, I see:

ln -fs /run/gitlab "${pkgdir}${_homedir}/pids"

But that that folder has to exist for the command to be successfuly. The only possible time I see when it might be created is during the "bundle install" command of build() phase, which happens after "/home/git/gitlab/tmp/.*/" is replaced with "/var/run/gitlab/" in unicorn.rb of the prepare() phase.

Is that the case?

trusktr commented on 2014-02-01 22:19

Marking as out-of-date because the PKGBUILD has a few errors in it. Specifically, in lines 22 through 35 the assignment operations should use "+=" instead of just "=".

Lopo commented on 2014-02-01 17:27

@onny: i've updated my gist ...
- fixed backup defs
- added logrotate
- sockets dir as link (similar to pids)

onny commented on 2014-01-31 15:02

@Apes: Thank you for the feedback and for your work on the wiki. I was aware that I missconfigured some socket paths, etc. I rechecked and fixed it.
Unfortunately I had to revert some of your changes in the wiki, since I chose a different location for config files: /etc/webapps/gitlab.
Still I applied other corrections you made, hope you agree with that.

Apes commented on 2014-01-31 01:05

Hello @onny,

I set up gitlab from scratch yesterday and today. I ran into some issues while doing so and updated the wiki with the workarounds that I figured out. I did not realize that you were also in the process of updating the wiki, so my apologies if I stepped on your toes.

There are a couple of issues with the current version of the AUR gitlab package that I made note of on the wiki:

* Nginx and unicorn are not configured with the same socket path, which results in a 502
* The gitlab-unicorn systemd script has an incorrect ExecStart command, which causes the unicorn workers to never start.

Hopefully you find this helpful

axil42 commented on 2014-01-30 12:51

I can submit the needed service files in gitlab-recipes so that you don't have to change them or whatever. Just pull them from upstream. Let me know.

Lopo commented on 2014-01-30 11:39

@onny: thanks for compliment ;)
one thing - when you used "local" copy of service files, use final version, don't change it in makepkg process

onny commented on 2014-01-30 10:28

@ImperialDwarf: Check out the wiki again and test the instructions. It should work more or less. Otherwise comment here or on the wiki.

@Lopo: So I reviewed your PKGBUILD and I must say: wow, great job! I adopted all of your changes and I hope you agree with it. Thank you for that!
If you have further improvements in mind, you can adopt the package if you want.

Well, I also created a clean ArchLinux VM and tested the package. It should work much better now.

ImperialDwarf commented on 2014-01-24 11:09

Hello. Where i can find actual guide for install gitlab from aur? As I understand the installation guide in arch wiki is out of date.

Lopo commented on 2014-01-23 14:31

@onny: the security risk is ... eh ... we can say ... minimal ...
and packages installed from AUR are always asking to edit them ... so you can check them before running ...
option is mentioned fetching of tagged versions ... but they're downloaded from another repo as gitlab himself ... so the tags are not paired
another option is fetching specific commit

maybe @axil42 can be helpfull to push hash files into gitlab-services alongside the used files ...
and i think that it has meaning only for service files, because conf file(s) for http server need additional checking/changing before enabling
but it requires additional downloads and hash check handling

but i don't see any real purpose to require hashing of those files

PS: my gist version was updated to create backup before update and don't require both of mysql/postgre

onny commented on 2014-01-23 12:23

Lopo: Sorry but I don't have the time now to look at all your changes. I'll do that later.
But I don't agree to fetch the service files without checksums. Just think about the security risk in executing unverified services with root privileges :/
On the other site, I want to be sure to include the latest and up-to-date conf/service-files from the _original_ origin. To avoid checksum issues we could fetch these files at a specific revision / commitid?

Lopo commented on 2014-01-23 07:43

hmmm ... new (6.5-1) PKGBUILD but still with all that errors ...
@onny are you reading what we're all writing here ?

axil42 commented on 2014-01-22 20:28

@onny sidekiq.service has wrong sha512sum ;)

onny commented on 2014-01-22 19:45

@Rulatir: do you still have these issues with gitlab 6.5?

Lopo commented on 2014-01-22 09:43

@crashandburn4 dunno ... in my linked gist version it's reverted back ...

crashandburn4 commented on 2014-01-20 19:14

out of interest, why is the gitlab-unicorn.service file changed to
ExecStart=/usr/bin/bundle exec rails server
instead of:
ExecStart=/usr/bin/bundle exec "unicorn_rails -c /usr/share/webapps/gitlab/config/unicorn.rb -E production"
this breaks the installation for me (the standard webserver has got to be unicorn rather than webrick, right??)

axil42 commented on 2014-01-20 16:02

We should then take it upstream.

Rulatir commented on 2014-01-20 13:51

sidekiq.log

/home/gitlab/gitlab/vendor/bundle/ruby/2.0.0/gems/activesupport-4.0.2/lib/active_support/dependencies.rb:229:in `require': libicui18n.so.51: cannot open shared object file: No such file or directory - /home/gitlab/gitlab/vendor/bundle/ruby/2.0.0/gems/charlock_holmes-0.6.9.4/lib/charlock_holmes/charlock_holmes.so (LoadError)
from /home/gitlab/gitlab/vendor/bundle/ruby/2.0.0/gems/activesupport-4.0.2/lib/active_support/dependencies.rb:229:in `block in require'
from /home/gitlab/gitlab/vendor/bundle/ruby/2.0.0/gems/activesupport-4.0.2/lib/active_support/dependencies.rb:214:in `load_dependency'
from /home/gitlab/gitlab/vendor/bundle/ruby/2.0.0/gems/activesupport-4.0.2/lib/active_support/dependencies.rb:229:in `require'
from /home/gitlab/gitlab/vendor/bundle/ruby/2.0.0/gems/charlock_holmes-0.6.9.4/lib/charlock_holmes.rb:1:in `<top (required)>'
from /home/gitlab/gitlab/vendor/bundle/ruby/2.0.0/gems/activesupport-4.0.2/lib/active_support/dependencies.rb:229:in `require'
from /home/gitlab/gitlab/vendor/bundle/ruby/2.0.0/gems/activesupport-4.0.2/lib/active_support/dependencies.rb:229:in `block in require'
from /home/gitlab/gitlab/vendor/bundle/ruby/2.0.0/gems/activesupport-4.0.2/lib/active_support/dependencies.rb:214:in `load_dependency'
from /home/gitlab/gitlab/vendor/bundle/ruby/2.0.0/gems/activesupport-4.0.2/lib/active_support/dependencies.rb:229:in `require'
from /home/gitlab/gitlab/vendor/bundle/ruby/2.0.0/gems/gitlab-grit-2.6.3/lib/grit.rb:79:in `<top (required)>'
from /home/gitlab/gitlab/vendor/bundle/ruby/2.0.0/gems/activesupport-4.0.2/lib/active_support/dependencies.rb:229:in `require'
from /home/gitlab/gitlab/vendor/bundle/ruby/2.0.0/gems/activesupport-4.0.2/lib/active_support/dependencies.rb:229:in `block in require'
from /home/gitlab/gitlab/vendor/bundle/ruby/2.0.0/gems/activesupport-4.0.2/lib/active_support/dependencies.rb:214:in `load_dependency'
from /home/gitlab/gitlab/vendor/bundle/ruby/2.0.0/gems/activesupport-4.0.2/lib/active_support/dependencies.rb:229:in `require'
from /home/gitlab/gitlab/vendor/bundle/ruby/2.0.0/gems/gitlab_git-4.0.0.pre/lib/gitlab_git.rb:4:in `<top (required)>'
from /home/gitlab/.gem/ruby/2.0.0/gems/bundler-1.3.5/lib/bundler/runtime.rb:72:in `require'
from /home/gitlab/.gem/ruby/2.0.0/gems/bundler-1.3.5/lib/bundler/runtime.rb:72:in `block (2 levels) in require'
from /home/gitlab/.gem/ruby/2.0.0/gems/bundler-1.3.5/lib/bundler/runtime.rb:70:in `each'
from /home/gitlab/.gem/ruby/2.0.0/gems/bundler-1.3.5/lib/bundler/runtime.rb:70:in `block in require'
from /home/gitlab/.gem/ruby/2.0.0/gems/bundler-1.3.5/lib/bundler/runtime.rb:59:in `each'
from /home/gitlab/.gem/ruby/2.0.0/gems/bundler-1.3.5/lib/bundler/runtime.rb:59:in `require'
from /home/gitlab/.gem/ruby/2.0.0/gems/bundler-1.3.5/lib/bundler.rb:132:in `require'
from /home/gitlab/gitlab/config/application.rb:6:in `<top (required)>'
from /home/gitlab/gitlab/config/environment.rb:2:in `require'
from /home/gitlab/gitlab/config/environment.rb:2:in `<top (required)>'
from /home/gitlab/gitlab/vendor/bundle/ruby/2.0.0/gems/sidekiq-2.17.0/lib/sidekiq/cli.rb:198:in `require'
from /home/gitlab/gitlab/vendor/bundle/ruby/2.0.0/gems/sidekiq-2.17.0/lib/sidekiq/cli.rb:198:in `boot_system'
from /home/gitlab/gitlab/vendor/bundle/ruby/2.0.0/gems/sidekiq-2.17.0/lib/sidekiq/cli.rb:42:in `parse'
from /home/gitlab/gitlab/vendor/bundle/ruby/2.0.0/gems/sidekiq-2.17.0/bin/sidekiq:7:in `<top (required)>'
from /home/gitlab/gitlab/vendor/bundle/ruby/2.0.0/bin/sidekiq:23:in `load'
from /home/gitlab/gitlab/vendor/bundle/ruby/2.0.0/bin/sidekiq:23:in `<main>'
Process doesn't exist

Looks like our good friend charlockholmes, except the divergence is the other way than described in troubleshooting: the distro's icu is ahead of the gem's.

Rulatir commented on 2014-01-20 13:42

The problem is somewhere in the deep corridors of the ruby mine. I will temporarily delete the "graft" and replicate the stacktrace for you just now, stay tuned.

Rulatir commented on 2014-01-20 13:38

"Solved" by grafting the following dirs/files from the 51 package saved in /var/cache/pacman/pkg:

/usr/lib/icu/51.2/
/usr/lib/*.so.51*
/usr/share/icu/51.2/

There are icu-44 and icu-48 packages in AUR. I might just look at their PKGBUILDs and make a -51.

axil42 commented on 2014-01-20 13:30

@Rulatir I'm not quite following your issue. How come is gitlab limiting you to icu51? This package is supposed to pull the latest version from the repos which is icu52, no?

Rulatir commented on 2014-01-20 13:13

All for naught!

While 6.4 bumped the icu dependency to 51, Arch Linux is now at 52, and libreoffice will not have anything less than that. Still can't have both libreoffice and gitlab, and until a permanent solution to this problem is found, it is going to reappear again and again, with the dreaded possibility that a time window when the required icu versions match will never actually happen.

Rulatir commented on 2014-01-20 12:59

All for naught!

While 6.4 bumped the icu dependency to 51, Arch Linux is now at 52, and libreoffice will have nothing less. ***STILL*** can't have both libreoffice and gitlab.

Is there a ***PERMANENT*** solution to lagging dependencies?

Rulatir commented on 2014-01-20 09:38

@axil42:

What is badly needed is a separate, parallel set of upgrade guides for the "upgrade using your distro's package manager" workflow. Current 6-0 to 6-4 upgrade quide just tells me to upgrade using git, but I *must* upgrade with Pacman if I am to upgrade at all, because my sole motivation for upgrading is an old library dependency that blocks me from installing LibreOffice if I want to keep gitlab. 6-4 will release this dependency if I upgrade with pacman, but not if I follow the official guide.

axil42 commented on 2014-01-16 13:26

Hey guys, I co-maintain the gitlab-recipes repo in github/gitlab.com, so if you think we could anything to make the packaging in Arch easier let me know :)

crashandburn4 commented on 2014-01-15 19:02

Thanks Lopo, looks good.

Lopo commented on 2014-01-15 13:28

take a look: https://gist.github.com/Lopo/8436091
It's not perfect ... but better as actual

fixes:
- service files not as source (prevents hash problems)
- missing lighttpd support
- dependencies (tested on minimal Arch install)

improvements:
- pid files moved to system dir /run
- easier to extend for another http server

Lopo commented on 2014-01-15 12:04

i'm working on new version of PKGBUILD ... fixed some errors, configs etc.
i hope to finish it today

crashandburn4 commented on 2014-01-14 21:28

got the same problem as lopo again.
==> Validating source files with sha512sums...
gitlab-ssl ... FAILED

Lopo commented on 2014-01-10 13:41

@onny, no problem ... but think about changing of source in PKGDUILD ... look at my netbeans-nightly package and process of getting JS files - this prevents hash sum errors in future

onny commented on 2014-01-10 08:14

@Lopo: sorry for being that late, fixed it!

KaiSforza commented on 2014-01-09 20:10

Just a hint, gitlab.org doesn't have https set up.

Lopo commented on 2014-01-09 12:25

==> Validating source files with sha512sums...
gitlab-ssl ... FAILED

viq commented on 2013-12-20 20:28

Seems 6.4.0 is out

pschmitt commented on 2013-12-19 13:08

@danmilon: From my understanding ~gitlab/www should be a symlink to /usr/share/webapps/gitlab. The said command should than work as expected.

In order to get gitlab working I also changed gitlab's default shell from /bin/false to /bin/bash (otherwise you won't be able to push/pull via ssh)

danmilon commented on 2013-12-13 14:32

upon installation www directory is empty.

$ su - gitlab -s /bin/sh -c "cd www; bin/rake gitlab:setup RAILS_ENV=production"
-sh: bin/rake: No such file or directory

$ pacman -Ql gitlab | grep -i www
gitlab /usr/share/webapps/gitlab/www/

solarwind commented on 2013-12-01 22:27

This packages requires extra/icu as a build dependency. Without it, installing/building charlock_holmes fails during makepkg -s.

Also requires extra/mariadb as a build dependency. extra/libmariadbclient alone may be sufficient, but I haven't tested. I'm going to be using PostgreSQL anyway.

solarwind commented on 2013-12-01 22:20

This packages requires extra/icu as a dependency. Without it, installing/building charlock_holmes fails during makepkg -s.

asbachb commented on 2013-11-25 21:20

You might consider to switch to the http rubygems - For me I sturggeled into problems with most of the https redirects.

bakkegaard commented on 2013-11-18 11:02

Really nice package, only problem i can't get it to work, and i tried alot...
When i bundle exec rake gitlab:setup RAILS_ENV=production it says "Could not locate Gemfile". And even when i found the folder /usr/share/webapps/gitlab it says "bundler: command not found: rake:setup Install missing gem executables with `bundle install`". I think the guide should be updated.

onny commented on 2013-11-11 03:34

@knirps: try:
cd /usr/share/webapps/gitlab
sudo su -c "bundle exec rake gitlab:setup RAILS_ENV=production" -s /bin/sh gitlab

knirps commented on 2013-11-09 00:35

Hey I'm trying to use the actual aur package and get a error while configure the database: su - gitlab -s /bin/sh -c "cd www; bin/rake gitlab:setup RAILS_ENV=production" -sh: bin/rake: No such file or directory When i look into /var/lib/gitlab/www its an empty directory. Have you any hints for me ?

onny commented on 2013-11-07 22:31

axil42: yep I did this: I know using /var/lib/gitlab as persistent program storage directory and it seems to work fine now.

axil42 commented on 2013-11-06 18:51

I would recommend against using /home/git and follow the initial FHS mtorommeo has in his PKGBUILD.

axil42 commented on 2013-11-05 21:30

Can you also share your thoughts on the removal of installation and other sections in the wiki? https://wiki.archlinux.org/index.php/Talk:Gitlab

axil42 commented on 2013-11-05 21:08

Hi, please update to 6.2.3, this is a security release.
http://blog.gitlab.org/gitlab-ce-6-2-and-5-4-security-release/

mappi commented on 2013-10-30 15:09

I have follow error: Post-install message from httparty:
When you HTTParty, you must party hard!
==> Starting package()...
rm: cannot remove ‘config/gitlab.yml’: No such file or directory
==> ERROR: A failure occurred in package().
Aborting...
The build failed.
... during install gitlab from this AUR package. I use packer tool to install packages from AUR repository.

onny commented on 2013-10-23 09:51

I have to admit that I don't get it to work. Support welcome ...

onny commented on 2013-10-23 08:48

brenix: thats right, I noticed this error too. I guess I'll switch back to /home/gitlab after further testing.

brenix commented on 2013-10-23 01:39

I noticed that this package and gitlab-shell both specify different home directories for the gitlab user. Since gitlab-shell is a dependency of this package, the gitlab user is created in /home/gitlab. However, in this package the install file shows the home directory as /var/run/gitlab?

orkosoy commented on 2013-10-10 15:12

I have problems setting de proxy.

The error is in the build step:

==> Iniciando build()...
==> Fetching bundled gems...
Fetching source index from https://rubygems.org/
Unfortunately, a fatal error has occurred. Please see the Bundler troubleshooting documentation at http://bit.ly/bundler-issues. Thanks!
/usr/lib/ruby/2.0.0/net/http/response.rb:119:in `error!': 504 "Gateway Time-out" (Net::HTTPFatalError)

orkosoy commented on 2013-10-10 13:56

The name of source is ${pkgname}hq-$pkgver.tar.gz

solusipse commented on 2013-10-06 23:53

I also had to install these two packages:
https://www.archlinux.org/packages/extra/i686/icu/
https://www.archlinux.org/packages/extra/i686/libxslt/

crashandburn4 commented on 2013-10-01 07:29

This build fails for me as it says I'm missing icu. Now looking at the package it seems that these dependencies are commented out? now I'm not too familiar with PKGBUILDS so I just ran 'pacman -Syu --noconfirm --needed sudo base-devel zlib libyaml openssl gdbm readline ncurses libffi curl git openssh redis libxml2 libxslt icu python2' to ensure that everything required was installed and restarted but shouldn't these be in the packagebuild itself?

onny commented on 2013-09-18 07:17

@Rulatir: according to their github page, 6.0.1 is in fact the latest stable version https://github.com/gitlabhq/gitlabhq/releases

Rulatir commented on 2013-09-17 12:51

How should I modify the PKGBUILD in order to build 6-1-stable instead of 6.0.1? Makepkg won't accept dashes in pkgver.