Using my hacky scripts, I recently updated the wiki with the missing gems and the runtime dependencies comparison table between GitLab (Gemfile), Fedora (rawhide) and Upstream (rubygems.org).
If we were to start packaging, I'd start by first reading the current guidelines (if you are new this will take a while). Bare in mind that the packaging also involves being an approved packager, and uploading the newly created package is a process of its own.
I've created a COPR repo for our work. You can reach it here: https://copr.fedorainfracloud.org/coprs/asrob/gitlab/
I'm also a package maintainer, but I've never packaged rubygems, that's why I'm going to read everything this weekend.
Looking at https://fedoraproject.org/wiki/GitLab/missing_gems, is there chance to get rid of rack-mount in upstream, since rack-mount was deprecated like 5 years ago, replaced by journey, which is now integrated in rails?
Also, I don't think you need the whole fog and its dependency chain. Instead, you want to use fog-core and some selected components you specifically need.
That would reduce the packaging maintenance effort a bit (and it would reduce GL foot print generally).
@sytses The "Active Releases" refer to releases of Fedora and/or RHEL/CentOS in which the creator of the COPR plans to support. Fedora COPR currently supports the full range of RHEL/CentOS and Fedora releases currently supported by their respective organizations. That means it's possible to use COPR to release packages in a form that can be consumed by the package manager (Yum on RHEL/CentOS and DNF on Fedora) for RHEL/CentOS 5-7, Fedora 22-24, and Fedora Rawhide (at the time of this post).
Using COPR enables rapid development of packages that can be used broadly by the Fedora community. COPR can also be used to build packages for architectures that are less commonly available, such as PowerPC. I believe there's also an effort to add ARM to the mix soon, too.
The GitLab COPR currently has nothing in its release channels, because no packages have been submitted to build yet.
@Conan_Kudo@asrob@vo.x thanks for your work on this. I see that the dependencies deprecation @stanhu mentioned was pushed to 8.9. How else can we help?
@DouweM any updates on @vo.x question: "Looking at https://fedoraproject.org/wiki/GitLab/missing_gems, is there chance to get rid of rack-mount in upstream, since rack-mount was deprecated like 5 years ago, replaced by journey, which is now integrated in rails?"
@vo.x I replaced colorize with rainbow in !4425 (merged), though it was worth mentioning since I saw that colorize was set to ASSIGNED in the gem list.
@asrob I found your username and added you to the trello board, although I'd rather use something else because that one was used to track my progress, etc. There is also this trello board which I created after GSoC to coordinate with some other folks about packaging, but didn't end up anywhere. We might want to use the latter to track progress.
Hey, do y'all need any additional help with this effort? Ruby isn't really my strong suit, but packaging is, and I'd love to help make this a reality for Fedora/RHEL!
I did read the summary! It was just unclear to me what work (if any) had actually been done, what was currently being worked, and what was needed most immediately.
I do have one comment, though -- it looks like y'all are really focussing on getting through the official Fedora process for all the packages you need or want to built, which seems kind of odd to me. If I was trying to make packages for gitlab happen, myself, I would first start with getting everything packaged and working, and then work on getting things through the official Fedora process.
The reason being -- I can put up a yum repo with gitlab and all of the packages for the various gems and whatnot, and have that be available for use on a broad scale, without involving the Fedora project directly at all. If I build those packages with some sense (e.g. following the Fedora packaging guidelines), getting them accepted by Fedora should be relatively straightforward, and people can still get the benefit of the work in the meantime.
(This is assuming that all that packaging hasn't already been done and this issue is just about getting the components accepted by the Fedora project. But if that's the case, I'm blind, because I sure as heck couldn't find it. No, the omnibus package doesn't count. :)
This is the usual way things work in the Fedora project. Doing it by
yourself, by setting up a local repo, actually moves you away from
upstream and might cause unnecessary effort in the end. "Upstream
first"... The process at Fedora actually is not that much more
troublesome.
@elfchief Actually, the "YUM repo" is quite good point. Moreover, these days, there is Copr, which might be quite good starting point to get GL into Fedora. Please note that Copr does not existed in the days when @axil was working on the GitLab.
Curious -- how firm is the admonishment in the Gitlab docs that ruby 2.1 is the only supported ruby version? The last (only?) version of Fedora to have ruby 2.1 is Fedora 21, which is already unsupported. There's also not a ruby 2.1 build in the Redhat Software Collections (just 2.0 and 2.2), so if ruby 2.1 is a hard requirement that won't change soon, step 1 of this would be "package and support ruby 2.1 for modern Fedora," which does not generally meet my definition of "a good time."
Unrelated: Is there a good place to have these types of discussions that isn't an issue ticket?
I did read the summary! It was just unclear to me what work (if any) had actually been done, what was currently being worked, and what was needed most immediately.
@elfchief As far as I know, I don't think much work has been done on it. It's open for anyone to take a crack at it. If anyone knows someone from the community who has been working on it, please let us know here!
I do have one comment, though -- it looks like y'all are really focussing on getting through the official Fedora process for all the packages you need or want to built, which seems kind of odd to me. If I was trying to make packages for gitlab happen, myself, I would first start with getting everything packaged and working, and then work on getting things through the official Fedora process.
That sounds consistent with what we do at GitLab and a great way to start. @axil, did you have any opinions here?
how firm is the admonishment in the Gitlab docs that ruby 2.1 is the only supported ruby version? The last (only?) version of Fedora to have ruby 2.1 is Fedora 21, which is already unsupported. There's also not a ruby 2.1 build in the Redhat Software Collections (just 2.0 and 2.2), so if ruby 2.1 is a hard requirement that won't change soon, step 1 of this would be "package and support ruby 2.1 for modern Fedora," which does not generally meet my definition of "a good time."
We are actually preparing for the transition to Ruby 2.3 since 2.1 is nearing its end-of-life (#12507 (closed)). Does this help, or is the same problem there?
@stanhu: Moving to ruby 2.3 does indeed help! f24 is currently shipping 2.3.1, so that lines up perfectly.
The bigger fly in the ointment is that RHEL7/CentOS7 only ship ruby 2.0 (...sigh), and I suspect those EL variants have a much larger potential audience than Fedora has. On the plus side, there's a software collection for ruby 2.3 on RHEL7, so that might be workable, even if using those really sucks). But, I suppose, one problem at a time.
@elfchief I'd say don't worry about officially supported Ruby version and just try what works and what doesn't. For example 'listen' gem recently started to enforce some Ruby versions not because it doesn't work, but because they just decided to do that ...
@elfchief Mmm, interesting but disappointing to hear that RHEL7 only ships ruby 2.0.
Red Hat provides a Software Collection for newer versions of Ruby. For example, there's a SCL for Ruby 2.3 that can be used to support GitLab there. Gems can be built as packages against the SCL environment, allowing for whole applications to be supported through it. Alternatively, you can treat it much in the same way you do rvm and similar tools, and just use bundler for constructing something to work against the SCL environment.
I think that the way to getting a RHEL package would be to get it into Fedora first. What is the ruby version in Fedora?
@sytses As of this moment, Fedora 24, 25, and Rawhide have Ruby 2.3. @vo.x is working on getting Ruby 2.4 to land in Fedora Rawhide, which will eventually become Fedora 26.
Honestly, I was pretty turned off by the "upstream first" desire and kind of tuned out at that point. It's a noble desire, but I think getting things well-packaged will be enough of a slog that adding in the extra bonus slog of dealing with upstream at the same moment is just not something that sounds like a project I'd do "for fun". (I guess there's also some disagreement with the upstream-first desire)
I do have a bit of free time right now, though; if I wanted to take a swing at getting things together, is there a technical resource on the gitlab side of the house that could work with me so I could focus on the actual packaging issues and not on figuring out the finer points of gitlab (which I followed closely for a bit, but not for several years now)? If I had a proper technical resource, I don't think it would really take all that long to get stuff in a decent state.
(Plus that would also give me someone at gitlab to have a discussion with over things like "what specific OS releases to target" and the like.)
@elfchief Feel free to reach-out for any GitLab specific question. That said, I'm not very familiar with native packages so maybe @marin and the ~Build team can also help here?
First of all, thank you for raising an issue to help improve the GitLab product. This issue was labelled as a ~"feature proposal" in the past. In order to maintain order in the issue tracker, we are starting to close off old, unpopular feature proposals that have not gained many votes since opening.
This issue will be marked for closure, as it meets the following criteria:
Created over 1 year ago
Labelled as a ~"feature proposal"
Unscheduled (not associated with a milestone)
Less than 10 upvotes
Thanks for your help and please raise any new feature proposals as a new issue.
I tried CentOS/RHEL 7 package some time ago - it may be that it was Fedora 26.
The problem is that most binaries are bundled! This has the advantage that the gitlab may / will run, but the great disadvantage that
the Fedora system packages are not used by gitlab, but some (sometimes old) libraries and packages that are bundled with gitlab
updates of Fedora, also security updates, will not be used by gitlab
there exists no SELinux policy rules for binary gitlab, so it runs in unconfined mode, including all bundled services like web server, database, etc.
Especially the missing SELinux restrictions for the all gitlab services are not acceptable for me. Therefore I am currently using gitlab in the Docker Container, where SELinux restricts at least the Docker Container in its permissions.
We need native Fedora packages, with SELinux policy rules for all services. Most services and packages which gitlab requires already exist for Fedora, including SELinux policy rules, for example for postgresql, web server, etc. But gitlab uses and requires (? this needs to be tested and fixed, preferable to enable gitlab to work with the newer software module) some older libraries and software packages as available for current Fedora versions, and some software modules are still not available as a Fedora package.
Fedora 26 hits its End of Life (EOL) status on June 1, 2018. Current versions are Fedora 27 and 28.
I could not wait for gitlab to provide fedora native packages, so i installed
gitlab-ee-10.8.3-ee.0.el7.rpm on fedora 28 4.16.13-300.fc28.x86_64 myself.
After little tinkering and help from community i got it working using following steps:
chown -R git.root /var/opt/gitlab/gitlab-rails
These is workaround for a bug
step 2)
At the following location
/opt/gitlab/embedded/lib/ruby/gems/2.3.0/gems/bcrypt-3.1.11/lib/bcrypt
modify engine.rb of bcrypt 3.1.11 ruby gem. Take backup of engine.rb before making changes.
change line no 51 to:
__bc_crypt(secret.to_s, salt).gsub(/(\n|\x00).*/, '')
Got to know this is fixed in bcrypt 3.1.12, until it is updated by gitlab use above workaround
This might be peculiar with Fedora 28 update.
step 3)
Create /etc/gitlab/gitlab.rb put following as per your env
external_url "http://192.168.1.49:7070"
unicorn['port'] = 7080
prometheus['listen_address'] = ':7090'
#Also enable above ports for http transport using semanage for SELinux, make sure the ports are opened in firewall too
step 4) gitlab-ctl reconfigure
wait patiently for this step to be over. This should pass without any error.
I hope gitlab fixes couple of the bugs whose workaround are provided above in next build
gitlab-ee-10.8.4-ee.0.el7.rpm and also provide fedora 28 or above native package too.
GitLab is moving all development for both GitLab Community Edition
and Enterprise Edition into a single codebase. The current
gitlab-ce repository will become a read-only mirror, without any
proprietary code. All development is moved to the current
gitlab-ee repository, which we will rename to just gitlab in the
coming weeks. As part of this migration, issues will be moved to the
current gitlab-ee project.
If you have any questions about all of this, please ask them in our
dedicated FAQ issue.
You can also find more information here:
Using "gitlab" and "gitlab-ce" would be confusing, so we decided to
rename gitlab-ce to gitlab-foss to make the purpose of this FOSS
repository more clear
I created a merge requests for CE, and this got closed. What do I
need to do?
Everything in the ee/ directory is proprietary. Everything else is
free and open source software. If your merge request does not change
anything in the ee/ directory, the process of contributing changes
is the same as when using the gitlab-ce repository.
Will you accept merge requests on the gitlab-ce/gitlab-foss project
after it has been renamed?
No. Merge requests submitted to this project will be closed automatically.
Will I still be able to view old issues and merge requests in
gitlab-ce/gitlab-foss?
Yes.
How will this affect users of GitLab CE using Omnibus?
No changes will be necessary, as the packages built remain the same.
How will this affect users of GitLab CE that build from source?
Once the project has been renamed, you will need to change your Git
remotes to use this new URL. GitLab will take care of redirecting Git
operations so there is no hard deadline, but we recommend doing this
as soon as the projects have been renamed.
Where can I see a timeline of the remaining steps?