Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 431802

Summary: www-apps/gitlab Project management and code hosting application written in ruby
Product: Gentoo Linux Reporter: Manuel Rüger (RETIRED) <mrueg>
Component: New packagesAssignee: Default Assignee for New Packages <maintainer-wanted>
Status: UNCONFIRMED ---    
Severity: normal CC: bertrand, cruzki123, dev-zero, hasufell, jakub.daniel, jdavid.ibp, jesse, johu, lucianm, prometheanfire, spiderx, travisghansen, web-apps, yac
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
URL: http://gitlabhq.com/
Whiteboard:
Package list:
Runtime testing required: ---
Attachments: qlist www-apps/gitlab

Description Manuel Rüger (RETIRED) gentoo-dev 2012-08-18 01:26:18 UTC
https://github.com/gitlabhq/gitlabhq/blob/stable/doc/installation.md


GitLab is a free project and repository management application
Application details

    based on Ruby on Rails
    distributed under the MIT License
    works with gitolite


Demo is available here:
http://gitlabhq.com/demo.html

As bug #409077 (gerrit) has very many unsatisfied java dependencies, it would be nice to see this in tree.
Comment 1 Travis Hansen 2013-01-23 04:07:24 UTC
I've put some major work in on this and have what I feel is at least a good starting ground to work from.

https://github.com/travisghansen/chaos-gitlabhq

It's based heavily on a home grown set of ebuilds and the great work I found here https://github.com/cvut/gitlabhq/wiki/Install-on-Gentoo

As many of the deps are 'bundled' it doesn't follow the gentoo way very well.  But I guess that's a reality of the day.  Any feedback/contributions would be great.  It's fully updated to the just-released version 4.1.0.
Comment 2 Travis Hansen 2013-03-29 19:13:32 UTC
I've updated the repo to support 5.0.0 + gitlab-shell.

The ebuild takes over the git system user so if you had/have gitolite running you'll want to uninstall and completely delete the git user so the gitlab ebuild can create it.
Comment 3 Tiziano Müller (RETIRED) gentoo-dev 2013-07-03 08:34:32 UTC
Ebuilds for almost all its ruby dependencies are in my overlay now: http://git.overlays.gentoo.org/gitweb/?p=dev/dev-zero.git;a=tree

currently left out are:

* gitlab_meta .. because I don't see what that does anyway
* gitlab-pygments.rb .. we already need pygments.rb and gitlab-pygments.rb is an old fork of it, I'd rather prefer to patch gitlab to use current pygments.rb
* d3_rails, underscore_rails .. coming soon (didn't see them on gemnasium)
* assets-group
* test-group
Comment 4 Jakub Jirutka 2013-09-22 14:19:12 UTC
Hi, I’m maintainer of the mentioned CVUT Overlay. I’ve just rewritten the gitlabhq ebuild for v6.0.2 and written ebuild for gitlab-shell.

https://github.com/cvut/gentoo-overlay/tree/master/www-apps/gitlabhq
https://github.com/cvut/gentoo-overlay/tree/master/dev-vcs/gitlab-shell

There’s also installation guide for dummies:
https://github.com/cvut/gentoo-overlay/wiki/Installation-guide-for-GitLab-6.x

Feel free to contribute, reuse it or whatever you want.

Note: I intended to become Gentoo developer and push some of my ebuild to Portage, but haven’t had a time yet.
Comment 5 Julian Ospald 2013-09-22 14:36:01 UTC
maintaining your own overlay != contributing to gentoo

contributing:
* attach and discuss ebuilds on bug reports
* contribute to herd overlays directly
* contribute to sunrise user overlay directly (either on the github/bitbucket mirrors or in #gentoo-sunrise)
* help other people with ebuild questions in #gentoo-dev-help and #gentoo-sunrise
* become a proxy maintainer or bother people in the project irc channels directly
* become a gentoo dev
Comment 6 Travis Hansen 2013-09-22 19:28:41 UTC
(In reply to Julian Ospald (hasufell) from comment #5)
> maintaining your own overlay != contributing to gentoo

That's pretty unconstructive.  Creating ebuilds and making them availble/disccussing/etc on a bug tracker seems like a solid contribution to me.  To suggest that what *has* been done is *not* a contribution is obtuse.  It's clear a lot of time and effort has gone into the ebuilds.

Some more appropriate responses might be:

1. I'd like to see these in sunrise and will help you do so.
2. I see you'd like to be a dev, I'd like to be your mentor or help you find one.
3. This is written in ruby, let's get you connected with the ruby devs and see if we can make this happen.
4. Tiziano has most of the deps in his overlay, can we start getting that integrated into your ebuilds or vice versa?

Jakub, I appreciate the contribution!
Comment 7 Julian Ospald 2013-09-23 10:43:09 UTC
(In reply to Travis Hansen from comment #6)
> (In reply to Julian Ospald (hasufell) from comment #5)
> > maintaining your own overlay != contributing to gentoo
> 
> That's pretty unconstructive.  Creating ebuilds and making them
> availble/disccussing/etc on a bug tracker seems like a solid contribution to
> me.  To suggest that what *has* been done is *not* a contribution is obtuse.
> It's clear a lot of time and effort has gone into the ebuilds.

No, it doubles the effort for a) people to figure out which one to use and b) developers who have to look in 3+ overlays and check if any1 did anything different.

We DO answer. We DO help. But these "here's some overlay, have a look or not" replies are really annoying me.

We have more than enough contribution channels. If someone does not use them, then he does so for his own convenience.

The decentralization of packaging is something we constantly have to fight. You either help us or go your own way with a 10% chance that someone might pick up your unreviewed ebuild from your overlay.
Comment 8 Travis Hansen 2013-09-23 15:06:00 UTC
(In reply to Julian Ospald (hasufell) from comment #7)
> 
> No, it doubles the effort for a) people to figure out which one to use and
> b) developers who have to look in 3+ overlays and check if any1 did anything
> different.

How hard is it to say "Can you guys work together to put a unified ebuild together?  Once it's done I'll help you submit it to sunrise."

Seriously, you're fighting an uphill battle telling users their contribution is worthless.  There are so many better ways to approach this.

> 
> We DO answer. We DO help. But these "here's some overlay, have a look or
> not" replies are really annoying me.

I personally have recieved answers and help many times.  So I know it happens.

If you DO help then help period.  Quit complaining about work people do.  If it's annoying you ignore it rather than spreading misguided negativity.  I provided several examples of more effective ways of helping in this situation in lieu of "You're using a personal overlay and that bugs me so it's not a contribution...oh yeah, and go away cause you're 'fighting' us by having a personal overlay."

help != ragging on people *trying* to help

It's fine to direct people to appropriate channels, just use some tact while doing so.  A sliver of appreciation would help as well.

> 
> We have more than enough contribution channels. If someone does not use
> them, then he does so for his own convenience.

So *help* people use these channels instead of saying "You suck, you don't use the channels we have in place so I can't help you and your contribution is worthless."

Ultimately the widespread use of personal overlays reflects the accessibility of such channels.

I've been approached several times over the years to become a gentoo dev and I still maintain a personal overlay.  I assure it's not because I find joy in it or want to purposely fragment things.

> 
> The decentralization of packaging is something we constantly have to fight.
> You either help us or go your own way with a 10% chance that someone might
> pick up your unreviewed ebuild from your overlay.

It's exactly because of this 'fight' sentiment that so many overlays exist.  This kind of negativity only drives people away and is the reason so many overlays exist to begin with.  Why do so many devs 'fight' the contributions of 'users'?  It baffles me.  Essentially you keep the users at arm's lenth and they'll stay there or further.

I'll stop ranting now.  I get super-frustrated when people trying to help simply get a slap in the face and finger-wagging experience.  I've used gentoo for ~10 years now and I've seen this far too often, especially in recent years.
Comment 9 Julian Ospald 2013-09-24 00:10:48 UTC
(In reply to Travis Hansen from comment #8)
> (In reply to Julian Ospald (hasufell) from comment #7)
> > 
> > No, it doubles the effort for a) people to figure out which one to use and
> > b) developers who have to look in 3+ overlays and check if any1 did anything
> > different.
> 
> How hard is it to say "Can you guys work together to put a unified ebuild
> together?  Once it's done I'll help you submit it to sunrise."
> 
> Seriously, you're fighting an uphill battle telling users their contribution
> is worthless.  There are so many better ways to approach this.
> 

I did not say that. So I have no idea who you are quoting.

> > 
> > We DO answer. We DO help. But these "here's some overlay, have a look or
> > not" replies are really annoying me.
> 
> I personally have recieved answers and help many times.  So I know it
> happens.
> 
> If you DO help then help period.  Quit complaining about work people do.  If
> it's annoying you ignore it rather than spreading misguided negativity.  I
> provided several examples of more effective ways of helping in this
> situation in lieu of "You're using a personal overlay and that bugs me so
> it's not a contribution...oh yeah, and go away cause you're 'fighting' us by
> having a personal overlay."
> 
> help != ragging on people *trying* to help
> 
> It's fine to direct people to appropriate channels, just use some tact while
> doing so.  A sliver of appreciation would help as well.
> 

Thanks dad. I don't care about tact.

> > 
> > We have more than enough contribution channels. If someone does not use
> > them, then he does so for his own convenience.
> 
> So *help* people use these channels instead of saying "You suck, you don't
> use the channels we have in place so I can't help you and your contribution
> is worthless."

Again: I did not say such a thing. Talk to the guy you are quoting.

> 
> Ultimately the widespread use of personal overlays reflects the
> accessibility of such channels.

No, most of the time it's laziness or lack of time. And I'v been long enough in those channels to realize that (as user and dev).

> 
> I've been approached several times over the years to become a gentoo dev and
> I still maintain a personal overlay.  I assure it's not because I find joy
> in it or want to purposely fragment things.
> 
> > 
> > The decentralization of packaging is something we constantly have to fight.
> > You either help us or go your own way with a 10% chance that someone might
> > pick up your unreviewed ebuild from your overlay.
> 
> It's exactly because of this 'fight' sentiment that so many overlays exist. 
> This kind of negativity only drives people away and is the reason so many
> overlays exist to begin with.  Why do so many devs 'fight' the contributions
> of 'users'?  It baffles me.  Essentially you keep the users at arm's lenth
> and they'll stay there or further.
> 

Wat? Do you even know what I do to help these contribution channels?

> I'll stop ranting now.  I get super-frustrated when people trying to help
> simply get a slap in the face and finger-wagging experience.  I've used
> gentoo for ~10 years now and I've seen this far too often, especially in
> recent years.

You are basically wrong. We get tons of bogus bug reports because of the widespread use of overlays. It makes life NOT easier for users or us devs.

And there was no negative tone at all in my first post, before you started to call my efforts of pointing people to the right contribution channels UNCONSTRUCTIVE. That's basically what your rant is. And now you expect me to lower my voice? Tzz...
Comment 10 Manuel Rüger (RETIRED) gentoo-dev 2013-09-24 00:38:15 UTC
This is a bug tracker and not a place for (offtopic) discussions. Please settle your disagreements in other channels.


(In reply to Travis Hansen from comment #1)
Maybe you want to move your documentation stuff to

http://wiki.gentoo.org/wiki/Gitlab

So we only have one source of documentation. 

Which dependencies are bundled?
The last time i looked at gitlab's sources, many dependencies were patched heavily and the changes were not upstreamed yet. Has this situation changed? (Otherwise we might add a :gitlab slot to our ruby pkgs)

If there are any (fully upstreamed) dependencies missing in the tree, feel free to open up a bug and block this one. 

As a member of ruby and proxy-maint herds, I'll be happy to work with you to get this into the tree (if it is possible due to above mentioned circumstances). Feel free to ping me on freenode irc: #gentoo-ruby
Comment 11 Tiziano Müller (RETIRED) gentoo-dev 2013-09-24 06:06:20 UTC
(In reply to Manuel Rüger from comment #10)
> This is a bug tracker and not a place for (offtopic) discussions. Please
> settle your disagreements in other channels.
> 
> 
> (In reply to Travis Hansen from comment #1)
> Maybe you want to move your documentation stuff to
> 
> http://wiki.gentoo.org/wiki/Gitlab
> 
> So we only have one source of documentation. 
> 
> Which dependencies are bundled?

A lot. https://gemnasium.com/gitlabhq/gitlabhq is a good start.

> The last time i looked at gitlab's sources, many dependencies were patched
> heavily and the changes were not upstreamed yet. Has this situation changed?
> (Otherwise we might add a :gitlab slot to our ruby pkgs)

Partially. Many of the dependencies listed above are unpatched. Those which are patched got forked and prefixed with gitlab- (while gitlab_ seem to be original packages).

> 
> If there are any (fully upstreamed) dependencies missing in the tree, feel
> free to open up a bug and block this one. 

I'm not sure whether you really want this as the deps are sometimes changing, requiring a lot of work to maintain that buglist.

> 
> As a member of ruby and proxy-maint herds, I'll be happy to work with you to
> get this into the tree (if it is possible due to above mentioned
> circumstances). Feel free to ping me on freenode irc: #gentoo-ruby

one question: what happens with packages which install javascript or css files?
I'm not sure whether we can really unbundle them...

About working together: I would happily move my ebuilds to either sunrise, a ruby-specific overlay or a gitlab-ng-specific overlay. I just don't have time (anymore) to take the lead on this.
Comment 12 Matthew Thode ( prometheanfire ) archtester Gentoo Infrastructure gentoo-dev Security 2015-01-20 22:08:40 UTC
Travis, would you mind attaching the output of 'qlist www-apps/gitlab'.  Am thinking of adding your ebuild to the tree and want to see the impact of the out of tree ruby modules.
Comment 13 Matthew Thode ( prometheanfire ) archtester Gentoo Infrastructure gentoo-dev Security 2015-01-20 22:20:11 UTC
the bundler stuff may mean that the omnibus method is the only one we can use.  Trying to figure out if this is packagable.
Comment 14 Julian Ospald 2015-01-21 00:36:10 UTC
I advise against adding this. I am running a gitlab instance myself and there are tons of ways it can break. And it needs a lot of manual configuration. I don't really see how this can be reasonably automated with an ebuild. It will just cause more invalid bug reports upstream.
Comment 15 Travis Hansen 2015-01-21 05:50:09 UTC
Created attachment 394448 [details]
qlist www-apps/gitlab
Comment 16 Travis Hansen 2015-01-21 06:03:25 UTC
While I agree the ebuild is not gentoo-ish with the built-in deps, I'd have to respectfully disagree with the comment from hasufell.

I've been using this on my own production servers for nearly 2 years.  I simply run emerge --config after each update and everything works fine (db migrations, etc, etc).

On a side note, I'm putting the finishing touches on the gitlab-ci ebuilds and will have those in the overlay soon as well.
Comment 17 Manuel Rüger (RETIRED) gentoo-dev 2015-01-21 09:04:43 UTC
(In reply to Travis Hansen from comment #16)
> While I agree the ebuild is not gentoo-ish with the built-in deps, I'd have
> to respectfully disagree with the comment from hasufell.
> 
> I've been using this on my own production servers for nearly 2 years.  I
> simply run emerge --config after each update and everything works fine (db
> migrations, etc, etc).
> 
> On a side note, I'm putting the finishing touches on the gitlab-ci ebuilds
> and will have those in the overlay soon as well.

From your qlist, please check:
bug #536008 
bug #529635 
bug #520212
bug #516084
bug #495218
and I guess there are many more.
This is why you want to avoid using bundler.
Comment 18 Travis Hansen 2015-01-21 09:18:18 UTC
(In reply to Manuel Rüger from comment #17)
> From your qlist, please check:
> bug #536008 
> bug #529635 
> bug #520212
> bug #516084
> bug #495218
> and I guess there are many more.
> This is why you want to avoid using bundler.

Yeah I get the benefits/pitfalls of it.  You'd be in the same boat with omnibus as well.

I unfortunately don't know enough about ruby (or packaging ruby stuff) to sanely do it, however given the number of deps it seems messy/unlikely to maintain all the required ebuilds at the 'proper' versions etc.  VM (with omnibus) or docker images seem the easiest route to not pollute the gentoo environment I guess.
Comment 19 Matthew Thode ( prometheanfire ) archtester Gentoo Infrastructure gentoo-dev Security 2015-01-22 20:26:57 UTC
Ya, I'm thinking that overlays with your ebuild or users using omnibus directly are the only ways.  I've been testing it with omnibus locally and it hasn't been fun.
Comment 20 Travis Hansen 2015-01-22 22:37:17 UTC
By omnibus are you referring to running omnibus on a supported platform (ubuntu/centos) or trying to install the omnibus packages on a gentoo system?
Comment 21 Matthew Thode ( prometheanfire ) archtester Gentoo Infrastructure gentoo-dev Security 2015-01-22 23:15:22 UTC
omnibus on gentoo, it's actually not that far away from working, the runit cookbook needs updating mostly.
Comment 22 Travis Hansen 2015-01-23 07:46:27 UTC
Interesting.  I'll need to look at omnibus a little closer I guess.

In the mean time, I've published my first stab at gitlab-ci and gitlab-runner (it looks like they're moving to gitlab-runner vs gitlab-ci-runner for some reason) into the overlay.