Created attachment 173636 [details] The output of gitlab:check Following the major version upgrade instructions listed in port's pkg-message, upgrading from 8.8.7 to 8.9.6, the gitlab:check phase fails (and GitLab is broken, accessing it shows gateway error 500). Attached is the output of > rake gitlab:check --trace RAILS_ENV=production
This looks like the change in gitlab_git that causes trouble: https://gitlab.com/gitlab-org/gitlab_git/commit/396cba39c62d401aacf6e9d006eedd5aecfeeab7
Sorry, forgot to specify, def initialize() got third argument, 'name', in that commit. I'll try revert gitlab_git to a version before that.
Thanks for the report. I will have a look at it. I think you are right with gitlab_git. Maybe it needs a downgrade. Or GitLab another upgrade to 8.10.x. But i wonder why i didn't get this error...
Downgraded rubygems-gitlab_git to 10.3.2, rebuilt it and Gitlab, force-reinstalled the gem, now it works. I suppose the upcoming Gitlab 8.10 will put everything back in place.
Oops, sorry, posted right after you and reverted the feedback. Fixing.
Before an update of GitLab is possible, there is the need to update Rails (and some other ports). I'm not entire sure that the GitLab Update fixes the issue. But the next GitlLab version will be released in 5 days and will definitely fix the issue. Therefore it is wise to lay the ground for the update. Created a review for the Rails update: https://reviews.freebsd.org/D7543 More will follow. I'm currently testbuilding the various updates needed for GitLab 8.10
Unfortunately lay ground until the next update is not an option due the current version is broken. I just did the upgrade today and now the check doesn't work for me either. You marked this release with the minimum requirement of rubygem-gitlab_git > 10.2, but the only available older package is 10.1.1 Currently I cannot figure out how to solve the problem (other than full wipe and restore backup which is a terrible option), should I try to run gitlab with the 10.1.1 gem version?
Ok I tried to install the old 10.1.1 rubygem-gitlab_git pkg, but it didn't changed anything, gitlab still doesn't work. @Vladimir how exactly you fixed this? I'm not using ports on this server, everything from package. What I've done is pkg install /var/cache/pkg/rubygem-gitlab_git-10.1.1.txz Gitlab is running for me, but if I try to access any repo I get exactly the same error message as I had from the gitlab:check ArgumentError (wrong number of arguments (2 for 3)): app/models/repository.rb:673:in `new' app/models/repository.rb:673:in `block in local_branches' app/models/repository.rb:672:in `each' app/models/repository.rb:672:in `each' app/models/repository.rb:672:in `map' app/models/repository.rb:672:in `local_branches' app/models/repository.rb:221:in `block in branch_count' lib/repository_cache.rb:19:in `fetch' app/models/repository.rb:221:in `branch_count' app/models/repository.rb:77:in `block in has_visible_content?' lib/repository_cache.rb:19:in `fetch' app/models/repository.rb:76:in `has_visible_content?' app/models/project.rb:757:in `empty_repo?' app/controllers/projects_controller.rb:303:in `repo_exists?' lib/gitlab/middleware/go.rb:16:in `call'
Okay I managed to fix it: stop gitlab service pkg delete -f rubygem-gitlab_git check: "gem list | grep gitlab_git" is empty (it has to be) gem install gitlab_git --version 10.3.2 re-do the upgrade procedure from Torsten's documentation (db migrate and assets clear/rebuild). Thanks for @Vladimir for the fix!!!
> You marked this release with the minimum requirement of rubygem-gitlab_git > > 10.2, but the only available older package is 10.1.1 If you have a local ports-tree copy just make: $ cd /usr/ports/devel/rubygem-gitlab_git $ vi Makefile $ change PORTVERSION from 10.4.0 to 10.3.2 $ make makesum # make reinstall This should work. Using gem install works, but will cause problems later, because it ignores pkg completly. I'm sorry to have broken this :(
Created attachment 173928 [details] patch of devel/rubygem-gitlab_git Hello, i attached the patch of rubygem-gitlab_git. I do not believe the next update hits the tree before the end of the week. So lets get this fixed beforehand. Vlad already described the "bundler-way" to fix. This is a good workaround but will cause problems later, especially since bundler completely ignores pkg. When you apply the patch and make a "make reinstall" be sure you removed gitlab_git from bundler via bundler. Please let me know if this fixes the issue! :) Greetings, Torsten
Oh, i forgot to add: redo the upgrade documentation after applying the patch! :)
Well, technically, I did that too with my local svn tree and installed from there. Although I didn't bump the epoch. Is it needed? pkg understands downgrades...
> Well, technically, I did that too with my local svn tree and installed from > there. Although I didn't bump the epoch. Is it needed? pkg understands > downgrades... A "normal" user just do a "pkg update". Even with more information there is no binary package with the needed version. The downgrade with the PORTEPOCH assures that even if you have the higher version (which breaks everything) the new but lower version is detected as "higher version" and an update is done. So this is the best message to roll the downgrade out without extra needed steps for the users. @Gabor: can you please check if it works with my patch?
(In reply to Torsten Zuehlsdorff from comment #14) I understand. I was really asking for personal edification. Sorry if I wasn't clear, I actually run Poudriere and install everything with pkg exclusively, and in this case the repo in question was my local svn testing & patching repo, from which Poudriere built the package, but eventually it was a matter of pkg upgrade which did the reinstall even without PORTEPOCH. But yeah, I agree, better to force it like that.
(In reply to Torsten Zuehlsdorff from comment #14) Hi Torsten, Thanks a lot, the patch just works perfectly. No conflict with ports or pkg at all. Steps I have taken: - gem uninstall gitlab_git (I had the gem installed manually) - portsnap fetch update (to make sure I work with the latest ports tree) - apply your patch on ports tree - make install clean (no reinstall as I use pkg always) Voila, everything works, pkg not complaining about 10.4.0
Torsten, the next Quarterly branch is coming up. Do you think perhaps GitLab should be set as BROKEN for Q4? Or maybe just downgrade rubygems-gitlab_git. AFAIK that port has no use outside of gitlab so downgrading it shouldn't violate any POLA wrt some other port...
I would go with the downgrade because of the same reasons. Also i aimed to get the next major update in the tree, but this depends on the next Rails 4 version. After starting to write the update for this, there were around 20 more updates needed. I think its possible to get a fix by using the next version, but i don't know if its before the next branch. So lets go the safe path.
A commit references this bug: Author: tz Date: Tue Sep 13 15:59:03 UTC 2016 New revision: 422026 URL: https://svnweb.freebsd.org/changeset/ports/422026 Log: devel/rubygem-gitlab_git: Downgrade from 10.4.0 to 10.3.2 The forme upgrade to 10.4.0 breaks the current version of www/gitlab, but the port works fine with 10.3.2. Since only www/gitlab depends on this port, its safe to downgrade it. PR: 211815 Approved by: pi (mentor) Changes: head/devel/rubygem-gitlab_git/Makefile head/devel/rubygem-gitlab_git/distinfo