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.
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.
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.
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
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.
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
(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!
(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.
(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.
(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...
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
(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.
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.
the bundler stuff may mean that the omnibus method is the only one we can use. Trying to figure out if this is packagable.
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.
Created attachment 394448 [details] qlist www-apps/gitlab
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.
(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.
(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.
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.
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?
omnibus on gentoo, it's actually not that far away from working, the runit cookbook needs updating mostly.
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.
