Date: Sun, 08 May 2022 17:42:18 +0000 From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 263867] www/gitlab-ce v14.10.0 failures when pushing or pulling Message-ID: <bug-263867-7788@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D263867 Bug ID: 263867 Summary: www/gitlab-ce v14.10.0 failures when pushing or pulling Product: Ports & Packages Version: Latest Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: Individual Port(s) Assignee: mfechner@FreeBSD.org Reporter: gwright@antiope.com Assignee: mfechner@FreeBSD.org Flags: maintainer-feedback?(mfechner@FreeBSD.org) Hi Matthais, The recent gitlab-ce (v14.10.0) introduced an annoying bug. It shows up as failure to push/pull from a server running gitlab, and apparent corruption = of repositories on the Gitlab server. Here are the observed symptoms. When pushing, I get: (base) ~/src/vev-renormalization> git push warning: core.fsyncObjectFiles is deprecated; use core.fsync instead Enumerating objects: 5, done. Counting objects: 100% (5/5), done. Delta compression using up to 8 threads Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 389 bytes | 389.00 KiB/s, done. Total 3 (delta 2), reused 1 (delta 0), pack-reused 0 remote: warning: core.fsyncObjectFiles is deprecated; use core.fsync instead remote: warning: core.fsyncObjectFiles is deprecated; use core.fsync instead remote: fatal: commit-graph requires overflow generation data but has none warning: core.fsyncObjectFiles is deprecated; use core.fsync instead fatal: commit-graph requires overflow generation data but has none remote: warning: core.fsyncObjectFiles is deprecated; use core.fsync instead To ssh://<HOST REDACTED>/software/vev-renormalization.git ! [remote rejected] master -> master (missing necessary objects) error: failed to push some refs to 'ssh://<HOST REDACTED>/software/vev-renormalization.git' Going to the corresponding repository on the server, I see: [git@gitlab ~/repositories/@hashed/92/2c/922c7954216ccfe7a61def609305ce1dc7c67e225f873f= 256d30d7a8ee4f404c.git]$ git fsck --full Checking object directories: 100% (256/256), done. fatal: commit-graph requires overflow generation data but has none [git@gitlab ~/repositories/@hashed/92/2c/922c7954216ccfe7a61def609305ce1dc7c67e225f873f= 256d30d7a8ee4f404c.git]$ echo $? 128 After some searching, I found this recommendation: https://docs.gitlab.com/ee/install/installation.html#git Now GitLab seems to depend on a version of git patched to work with a particular version of gitaly. In the jail in which I run gitlab, I did: > cd /tmp > git clone https://gitlab.com/gitlab-org/gitaly.git -b 14-10-stable /tmp/g= italy > cd /tmp/gitaly > gmake git GIT_PREFIX=3D/usr/local This installed the patched version of git, overwriting the binaries install= ed in /usr/local/by the git package. After I did this, the repository checked clean: 05ce1dc7c67e225f873f256d30d7a8ee4f404c.git # git fsck --full Checking object directories: 100% (256/256), done. Checking objects: 100% (107/107), done. Verifying commits in commit graph: 100% (24/24), done. Also after switching to the patched version of git, pushing from a remote worked without error. It is rather annoying that gitlab (or perhaps more specifically gitaly) can= not use the released git. Let me know if I can run more experiments. Reinstal= ling git from packages seems to reliably recreate the failed state, at least for= one of my repositories. BR, Greg --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-263867-7788>