Created attachment 233689 [details] gitaly 14.10.0 poudriere build log devel/gitaly 14.10.0 depends on: rubygem-activesupport61>=6.1.4.7<6.1.5:devel/rubygem-activesupport61 but devel/rubygem-activesupport61 is now in version 6.1.5.1, so the port cannot be build and www/gitlab-ce 14.10.0_1 too.
Hitting the same issue.
I have the same problem
Same problem here. My Gitlab server has been down for a week, hope it comes back soon. I have tried to tweak dependencies in the Makefile, Gemfile etc, but it seems to be a slippery slope, and I don't think it's a good idea to explore it further. `pkg upgrade -f rubygem-activesupport61` also seems to be a dangerous thing to do, it would give the correct version, but at the cost of downgrading Ruby from 3.0 to 2.7.
I'm aware of this before committing the update (6.1.5.1). Back in March when Rails 6.1.5 was released, I sent a patch to Matthias for testing since gitaly/gitlab-ce requires "~> 6.1.4.7". He mentioned that upstream and community have no activity for Rails 6.1.5 or Rails 7. Therefore I postponed the update. At the end of April, Rails 6.1.5.1 was released [1] and I committed the update because it is a security update. [1] https://rubyonrails.org/2022/4/26/Rails-7-0-2-4-6-1-5-1-6-0-4-8-and-5-2-7-1-have-been-released
In attempting to build gitaly-14.10 I get the message: gitaly-14.10.0 depends on package: rubygem-activesupport61>=6.1.4.7<6.1.5 - not found Looking at ports/devel/rubygem-activesupport61, the version in Makefile is listed as ------------- Created by: Jonathan Weiss (<jw@innerewut.de>) PORTNAME= activesupport PORTVERSION= 6.1.6 CATEGORIES= devel rubygems ----------
Hello again everybody Could the importance of the bug be bumped up, maybe? I feel that "Affects some people" doesn't do justice to the real severity of the problem, as it's not about Gitaly itself, but about the ability to run Gitlab, a basic tool for many developers (including myself). My Gitlab has been unvailable for 3 weeks, some of my work is blocked, and I don't know if I should go through the hassle of a portdowngrade, including 270 ruby+rubygem ports which would need to be reverted to Ruby 2.7 from 3.0. Or, whether I should give up on the FreeBSD port entirely, and go for an Omnibus install on Linux. Thanks in advance, Laurent.
I was on holiday the port got broken. I will work on it, please give me some days.
Hello Matthias, thank you very much for your answer! I hope your holidays were good :) Take the time you need, it's good to know you're on it :) Laurent.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=055d6b1e467efe51bf72c963c9283fc377c2d330 commit 055d6b1e467efe51bf72c963c9283fc377c2d330 Author: Matthias Fechner <mfechner@FreeBSD.org> AuthorDate: 2022-05-27 15:39:33 +0000 Commit: Matthias Fechner <mfechner@FreeBSD.org> CommitDate: 2022-05-27 17:18:31 +0000 devel/gitaly: update to 15.0.0 Required for gitlab-ce 15.0.0. Relaxe version contraints for rubygem-activesupport. This is not tested by gitlab, but I found no problems in my tests. Changelog: https://gitlab.com/gitlab-org/gitaly/-/blob/master/CHANGELOG.md PR: 263747 devel/gitaly/Makefile | 194 +++--------------- devel/gitaly/distinfo | 294 +-------------------------- devel/gitaly/files/patch-Makefile | 8 +- devel/gitaly/files/patch-config.toml.example | 18 +- devel/gitaly/files/patch-ruby_Gemfile | 21 +- 5 files changed, 51 insertions(+), 484 deletions(-)
Should be fixed now.
Big thank you, Mathias! I'm trying to install gitlab-ce 15.0, hitting a problem, I'll look ingto it later: ===> Applying FreeBSD patches for gitlab-ce-15.0.0 from /usr/ports/www/gitlab-ce/files patch: **** malformed patch at line 119: @@ -423,30 +351,6 @@ group :development, :test, :omnibus do ===> FAILED Applying FreeBSD patch-Gemfile ===> FAILED to apply cleanly FreeBSD patch(es) patch-Gemfile Laurent.
If you not use poudriere to build your packages, make sure you do a `make distclean` before you build, that ensures that everything is downloaded again. Normally a `make clean` is enough, but I did some heavy refactoring of many ports, so a distclean could help. I just do an additional testbuild here: https://pkg.fechner.net/build.html?mastername=130amd64-default&build=2022-05-27_20h35m26s
(In reply to Laurent Daverio from comment #12) Could you please retry. It seems that to patch got corrupted while I prepared the commits.
(In reply to Matthias Fechner from comment #14) OK, thank you, I'll retry as soon as the changes appear in portsnap :)
(In reply to Matthias Fechner from comment #14) Portsnap still not updated, so I've manually updated the patch file for there: https://cgit.freebsd.org/ports/plain/www/gitlab-ce/files/patch-Gemfile?id=35d750f806d4539ed73ccc03bc3d2e4cc14e9afa Gitlab build is ongoing, but I believe everything will be fine :)
(In reply to Laurent Daverio from comment #15) Everything seems to be working now (I had to make sure to replace grpc with grpc 142) :) Many many thanks again :)
(In reply to Laurent Daverio from comment #17) Thanks for feedback, nice you have running Gitlab again. By the way, you should use git to sync ports, portsnap is deprecated and I'm suprised it is working ;)
(In reply to Matthias Fechner from comment #18) Oh, didn't know that, I've been using the same procedure for years. I'll switch to Git, thanks for the tip :) The next step will be to upgrade to Gitlab-Runner 15, as version 14.5 doesn't seem to communicate with Gitlab 15. I have a look at the official Gitlab doc, apparently it no longer recommends using the port, but to install the binary manually. But it's no urgent, all the rest seems to work, I'm happy :)
(In reply to Laurent Daverio from comment #19) The runner 14.5.0 runs fine here. But you can try to contact the maintainer to update the port or provide a diff to the maintainer to update it (which will be for sure quicker to land in ports).
(In reply to Matthias Fechner from comment #20) Actually, neither 14.5 nor 15.0 seem to work for me (I've tried the manual install). Gitlab correctly seed them (correct version is detected), but no jobs are assigned to them
The following configuration works fine for: /var/tmp/gitlab_runner/.gitlab-runner/config: concurrent = 1 check_interval = 0 [session_server] session_timeout = 1800 [[runners]] name = "x.x.x" url = "https://gitlab.fechner.net/" token = "xxx" executor = "shell" [runners.custom_build_dir] [runners.cache] [runners.cache.s3] [runners.cache.gcs] [runners.cache.azure]
(In reply to Matthias Fechner from comment #22) I have the same configuration, it always worked for me before. Right now, it works in one direction only : runners are seen by Gitlab; if I change their version, the new version is picked up immediately; if I register a new runner, it's listed. But, for some reason, Gitlab can't send them jobs. At this stage, I want to explore openssl, as yesterday I stumbled upon this problem, after one hour of trying various things in vain: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261967
(In reply to Matthias Fechner from comment #22) It's so stupid, can't believe it. Spent my afternoon on it... I recently upgraded my PostreSQL 13 to 14, and I forgot to install the extensions. Then I ran the 4 rake scripts (migrate db, compile assets, etc.), and I neglected to check the messages, otherwise I would have noticed that the migrations had failed. So, Sidekiq wasn't running, the Web IDE gave en error 500, and the communication with gitlab-runner failed too. Whew 😅