Guix makes invalid assumptions regarding guile-git guarantees leading to guix pull failing

  • Open
  • quality assurance status badge
Details
4 participants
  • Denis 'GNUtoo' Carikli
  • wolf
  • Simon Tournier
  • Tomas Volf
Owner
unassigned
Submitted by
wolf
Severity
normal
W
(address . bug-guix@gnu.org)
ZRcA23RUYvBuE1JX@ws
Attachment: file
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEt4NJs4wUfTYpiGikL7/ufbZ/wakFAmUXANUACgkQL7/ufbZ/
wakODA/8DxkKlgO32+U9sJxD0ZS8QN7Hua1SzsUmVChlPasuFqHgqx0Exu9y8qSv
I7N72W0zam6LEjWtGhzfF8kTamtrNALObqPi6Xw21VrXm4iO2LFQy9tZaGAxQvtb
+I8CCVtAxS/Gk8ehCYGXpGpeafE0/TBzB/b+0Mjqx+KdAq7amWTzLGo8/5O1Qe8l
Zrr+VW2KdYCDRi6qMR5DsxCQin38m8yuYiD/mX7vjTF6w/XHf73U9QqzTNwYwYLi
vgEscW+5VbseEE3ESyyei9S0H2cORfRT2UIFZGwsg6IZE1nHCD+lQjfPdGl8pIo8
3iFWgffkOYdp6zqo1VLPNcEGIDwvN5JdPRE3O+skqzCUhfoT9a3wymDgd/92HDKp
YvxNiGLQfXmXIq3UsCbBIAvSy6wec+rn8twxRDFf8fNlB1Ma8UPUXwV0h3TSFet5
xWlMeTyki/uWcLDSBSaVt5SyRvKw3DZ9XO+G6L91G5KqdWvjn/Ll03OuHezM8K7I
SIhcZylwdEhBCRdZr6JVN/uu005nkhKQ1omgi8hjsZaHGZFVg9o9+r22n5cFPOol
6ocs4DDXf81fMuhY48FB4+/9Ha62xsO/m/tEhFsNEqrCIPe9ciAPjoa5ElPsYaiI
iJEwqduWUGCQ9TXWS1ZyKhIZkG9iO2DU7e+4GGP9BwSjzEQp0iU=
=yCeP
-----END PGP SIGNATURE-----


S
S
Simon Tournier wrote on 30 Sep 2023 17:48
86fs2vek60.fsf@gmail.com
Hi,

Hum, the updates seem:

+ libgit2 on Feb 17 2023,
+ guile-git on May 15 2022.

(See 8d8e1438ae5a2e50005b500dacd0a26be540fe69 and
b6bfe9ea6a1b19159455b34f1af4ac00ef9b94ab)

And some commits with large body are around:

+ 7b45ead9ec40a5ea1ef8332d55c2bb4beff85eb5 from Jul 18 2023
+ 1e6ddceb8318d413745ca1c9d91fde01b1e0364b from Feb 19 2023
+ 5897d873d0c902f08d13c38500eff11098f2a634 from Aug 10 2022

And I have not investigated more about their commit object size. Just
counting the number of characters per commit message. The one you
provided is about 3030, if I am correct. Here, let filter with the
criteria of 4500, why not. :-)

Toggle snippet (10 lines)
$ for ci in $(git log --format=%H --after=2022-05-13); do \
echo "$(git show -s $ci | wc -c) $ci" \
| awk '$1>4500{print $2 " " $1}' \
;done
7b45ead9ec40a5ea1ef8332d55c2bb4beff85eb5 4997
1e6ddceb8318d413745ca1c9d91fde01b1e0364b 16120
575a03ab3997edee08d20867228e886043d5240f 5511
5897d873d0c902f08d13c38500eff11098f2a634 6258

Well, it is probably not a regression. Or I am missing some details. :-)

I am probably overlooking something, from my understanding, the issue
arises for some corner cases when the bound of the closure does not fit
’eq?’. For these cases, instead of relying on ’setq’ using ’eq?’, we
could rely on ’set’ using ’equal?’. No?

On Fri, 29 Sep 2023 at 18:52, wolf <wolf@wolfsden.cz> wrote:

Toggle quote (10 lines)
> ,----
> | scheme@(guile-user)> (use-modules (git) (guix git))
> | scheme@(guile-user)> (define %repo (repository-open "/tmp/my-fork"))
> | scheme@(guile-user)> (define %hash "d51135e8477118dc63a7e5462355cd27e884f4fb")
> | scheme@(guile-user)> (commit-relation
> | (commit-lookup %repo (string->oid %hash))
> | (commit-lookup %repo (string->oid %hash)))
> | $5 = unrelated
> `----

[...]

Toggle quote (5 lines)
> ,----
> | $ git merge-base --is-ancestor 9b985229bcd 71f544c102a; echo $?
> | 0
> `----

[...]

Toggle quote (3 lines)
> 2 Possible solutions
> ====================

Naive question. Why not rely on “git merge-base --is-ancestor” for
implementing “commit-relation”?

Since f651a359691cbe4750f1fe8d14dd964f7971f91 from Sep 26 2023:

build: Add dependency on Git.

* configure.ac: Check for ‘git’ and substitute ‘GIT’.
* guix/config.scm.in (%git): New variable.
* guix/self.scm (compiled-guix): Define ‘git’ and pass it to
‘make-config.scm’.
(make-config.scm): Add #:git; emit a ‘%git’ variable.
* doc/guix.texi (Requirements): Add it.

we can assume Git is available by the code that run “commit-relation”,
no?

The implementation relying on “git merge-base --is-ancestor” does not
have the problem, right?

And from [1], it is 35x faster. Win-win, no? Because the fix for ’eq?’
will introduce performance cost and ’commit-relation’ will be even
slower, no?

Well, I do not know. My words are probably irrelevant.

Cheers,
simon


1: comparing commit-relation using Scheme+libgit2 vs shellout plumbing Git
Simon Tournier <zimon.toutoune@gmail.com>
Tue, 12 Sep 2023 00:48:30 +0200
id:865y4gz5q9.fsf@gmail.com
W
(name . Simon Tournier)(address . zimon.toutoune@gmail.com)(address . 66268@debbugs.gnu.org)
ZRsuFGEjxymdIK92@ws
Attachment: file
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEt4NJs4wUfTYpiGikL7/ufbZ/wakFAmUbLhQACgkQL7/ufbZ/
wanojQ/8DdcufuFV9CPyAjBgHpmnrazzRB0Er3BQJYkMYaMOlQJjCzwoiIsS7tcn
m6ZCWrf0ApYNIvTRervUoZ+FyMddrAIgHFELV6kWsMV4GXP0c+Vb7Z5yZifvmjZ2
nGKd/xiAABUmhVE8N1uNkZ0mOtHOqsNbVojI1eyDTd2ATWMKELDHMmlhIcGLgsFK
08RLqVBPiANaCr+yzm9celiiDjTlnW80DlL9JZrYXYGa4EMphHqQXLvCgsFiLkY0
Kfqhxq1slCLvbAMMJe4nII5NUXNrm4aTUt+NrQhWTwSqiKK9CzOWFzzUGuwZKtRY
IeHfyav7wFdDEWWJfuA6NORFyJ1G06hVOZPAOigC/4yyFjoqY457Y2wnjPt6Jsob
dCZP7TdXDuCNpIpZTdB7UKxF0PhUzDZhxsXGtSnvcMd7pPgRNsBbI1fJuOXyAEVa
dcwgb8VIkqnfzx4GxF1++vYLTyREPf1sv3h18QSNKJZKHIuUcbS/Mlb0s2JdsqoM
mvJZexkUI8f6eH+VEf89M7KKKzG1vrdJcFfHFTvAcpxRHgntkBDXFOVbl3bpVV9o
Y3UcW+dlz3XhtYRLkYH/rBtwl48O/ssfajdNNjid8dyiF/H1UArOtQ7MT4/Wlh7k
E8lYmbCN7F32VyV2VKNZ8bTSceMaRuXdvVr8Ttg2Utu2conm2w0=
=02wv
-----END PGP SIGNATURE-----


T
T
Tomas Volf wrote on 9 Jan 17:57 +0100
control message for bug #66268
(address . control@debbugs.gnu.org)
904475e80b1e0082013667e088c18334@wolfsden.cz
submitter 66268 !
quit
D
D
Denis 'GNUtoo' Carikli wrote 35 hours ago
Re: Guix makes invalid assumptions regarding guile-git guarantees leading to guix pull failing
20241126191508.3145f604@primary_laptop
Hi,

I've found a much smaller test case:
Toggle quote (7 lines)
> cd gnuboot
> guix git authenticate \
> bf2b91df54aa71ecbfab891d32000ad2d6af6093 \
> "E23C 26A5 DEEE C5FA 9CDD D57A 57BC 26A3 6871 16F6" \
> -k origin/keyring

The repository only consists of 683 commits for now.

The commit that is problematic is precisely the introduction commit
(bf2b91d). There are bigger commits messages in the history before that
but it seems not to be an issue.

A workaround I found is to substitute the commit bf2b91d ("Add
.guix-authorizations file for "guix git authenticate".") with the one
right after it (dde4223 Fix .guix-authorizations for Denis 'GNUtoo'
Carikli.).

So while this bug needs fixing, we are also looking for a workaround as
once a fix lands upstream, it could take some time to reach everybody
especially because we'd like to make guix git authenticate work, with
the guix packages from various distributions (PureOS has Guix 1.2),
without requiring to do a git pull which can probably take hours.

If I understood right, the workaround explained above is not sufficient
as at any time, pushing commits could break guix git authenticate, so
I'm also looking for a reliable way to avoid the condition that makes
guix git authenticate fail.

So I see 2 approaches, one is to write code that looks at the size of
commits, I've done that but then we can't easily reproduce the issues
if we use the commit right after bf2b91d. I've added big commits after
that.

I've now started to
commits in another repository that adds a .guix-authorizations file but
it will take between 24h and 48h to rebase on a VM on a D16 on tmpfs, so
it's not very practical for the tests.

Another way could be to remove the authentication setup with some code
like that:
Toggle quote (3 lines)
> cp -f config .git/config
> rm -f .git/hooks/post-merge
> rm -f .git/hooks/pre-push
and then run the guix git authenticate command but I'm unsure if this
could have false negative and let through commit that break everything
when people clone the repository and run guix git authenticate for the
first time.

Also did other people encounter this issue in other git repositories?
This could also help with testing.

Denis.
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEeC+d2+Nrp/PU3kkGX138wUF34mMFAmdGECwACgkQX138wUF3
4mPEpQ//ciLT4c2KaLDE0C3Zcna5DBE7IavU+EwyUOVIh0jAFRHuCuBKkRPDKWaT
kFMSJEfR4VA0RHtVIalx0samPFgU2sgk0FZOMKn5fydmj0wOcBYvQv6XSMfwkwyx
xrrsJnhBRbpYBAaKtzNtx9NcqrstvdpaVHY7QjqaZ1H79NIKZS2NFh4WMDVnKB3y
YergiuyNC9cH91/EzJA+iWxB6TT+Ff/8xzHAtrOM2Wt0BvvkPftxbwrR9e4/ptJZ
uLpCSdQ2rwqkxu2fClVNlc4s5m+651NgVlds/YwBRLut0+8pl8H8G0niLKEZXiih
ZB6hAy1M/TsqLdoPRqn0hzaz74JRoQC+6oGHeh80Q2biu2m1ubkpyxzlms9LtE2K
gC5pO1+yMFvE+xMmmMrQU8DfCuPCKvbMFupXh0WyN50elPMp1wXQYzL95KjE0uED
jgjyxyGlovRvCjI2JUf935ANEgyB1oym4B3rd2gojk+vZnxOxzuxG7E+f4FCx5uf
Y3iDiD2FeTAFF6+zmICikAIRjrYw3euEVV2Ski2QdnUWwjYLZBMC2bQkXUWaq18A
BRR/vpLdgvy5ArkmEsvxpDy8H3aDT7QgygYo0CCvyyEx7NdqMoQHPf9aJPSjmFoG
rwptD19AzRcfkt8yQdeP9ap54zyYeNNsfdytwvjfJ/iiUBXT5Gk=
=F0ny
-----END PGP SIGNATURE-----


?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 66268@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 66268
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch