[bug#61246,v2] gnu: libgit2: Update to 1.5.1.

There were both a missing space on the copyright and a missing texi
'command' tag on the previous patch to guix.texi. Please, apply this
one instead.
From 97b1752180ac89f78fdbbbec7d6c4aaf0a18bdbf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andr=C3=A9=20Batista?= <nandre@riseup.net>
Date: Wed, 8 Feb 2023 12:28:25 -0300
Subject: [PATCH] gnu: libgit2: Update to 1.5.1.
To: guix-patches@gnu.org
Cc: 61246@debbugs.gnu.org

* gnu/packages/version-control.scm (libgit2): Update to 1.5.1.
[source]: Remove snippet to comment out the "10 years ago" test, which
was removed on newer versions.
(libgit2-1.4): New variable. Update to 1.4.5.
(libgit2-1.3): Inherit from 'libgit2-1.4'. Update to 1.3.2.
(libgit2-1.1): Update to 1.1.1. Add back the snippet which comments out
the "10 years ago" test that remains on this older version.
* doc/guix.texi (Using a Custom Guix Channel): Add note and example
on how to exempt a local guix repository from git ownership checks.
---
 doc/guix.texi                    | 20 ++++++++++++-
 gnu/packages/version-control.scm | 50 +++++++++++++++++++++-----------
 2 files changed, 52 insertions(+), 18 deletions(-)

Hello André,

André Batista <nandre@riseup.net> writes:

> There were both a missing space on the copyright and a missing texi
> 'command' tag on the previous patch to guix.texi. Please, apply this
> one instead.
>
>
> From 97b1752180ac89f78fdbbbec7d6c4aaf0a18bdbf Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Andr=C3=A9=20Batista?= <nandre@riseup.net>
> Date: Wed, 8 Feb 2023 12:28:25 -0300
> Subject: [PATCH] gnu: libgit2: Update to 1.5.1.
> To: guix-patches@gnu.org
> Cc: 61246@debbugs.gnu.org
>
> * gnu/packages/version-control.scm (libgit2): Update to 1.5.1.
> [source]: Remove snippet to comment out the "10 years ago" test, which
> was removed on newer versions.
> (libgit2-1.4): New variable. Update to 1.4.5.
> (libgit2-1.3): Inherit from 'libgit2-1.4'. Update to 1.3.2.
> (libgit2-1.1): Update to 1.1.1. Add back the snippet which comments out
> the "10 years ago" test that remains on this older version.
> * doc/guix.texi (Using a Custom Guix Channel): Add note and example
> on how to exempt a local guix repository from git ownership checks.

This loooks good, thanks!

>  doc/guix.texi                    | 20 ++++++++++++-
>  gnu/packages/version-control.scm | 50 +++++++++++++++++++++-----------
>  2 files changed, 52 insertions(+), 18 deletions(-)
>
> diff --git a/doc/guix.texi b/doc/guix.texi
> index 2b1ad77ba5..5314488d7e 100644
> --- a/doc/guix.texi
> +++ b/doc/guix.texi
> @@ -81,7 +81,7 @@ Copyright @copyright{} 2020, 2021 Brice Waegeneire@*
>  Copyright @copyright{} 2020 R Veera Kumar@*
>  Copyright @copyright{} 2020, 2021 Pierre Langlois@*
>  Copyright @copyright{} 2020 pinoaffe@*
> -Copyright @copyright{} 2020 André Batista@*
> +Copyright @copyright{} 2020, 2023 André Batista@*
>  Copyright @copyright{} 2020, 2021 Alexandru-Sergiu Marton@*
>  Copyright @copyright{} 2020 raingloom@*
>  Copyright @copyright{} 2020 Daniel Brooks@*
> @@ -5411,6 +5411,24 @@ From there on, @command{guix pull} will fetch code from the @code{super-hacks}
>  branch of the repository at @code{example.org}.  The authentication concern is
>  addressed below (@pxref{Channel Authentication}).
>  
> +Note that you can specify a local directory on the @code{url} field above if
> +the channel that you intend to use resides on a local file system.  However,
> +in this case @command{guix} checks said directory for ownership before any
> +further processing.  This means that if the user is not the directory owner,
> +but wants to use it as their default, they will then need to set it as a safe
> +directory in their global git configuration file.  Otherwise, @command{guix}
> +will refuse to even read it.  Supposing your system-wide local directory is at
> +@code{/src/guix.git}, you would then create a git configuration file at
> +@code{~/.gitconfig} with the following contents:
> +
> +@example
> +[safe]
> +        directory = /src/guix.git
> +@end example
> +
> +@noindent
> +This also applies to the root user.
> +
>  @node Replicating Guix
>  @section Replicating Guix
>  
> diff --git a/gnu/packages/version-control.scm b/gnu/packages/version-control.scm
> index 78a89cfd5b..2f1eb27b3c 100644
> --- a/gnu/packages/version-control.scm
> +++ b/gnu/packages/version-control.scm
> @@ -799,7 +799,7 @@ (define-public git-cal
>  (define-public libgit2
>    (package
>      (name "libgit2")
> -    (version "1.4.3")
> +    (version "1.5.1")
>      (source (origin
>                ;; Since v1.1.1, release artifacts are no longer offered (see:
>                ;; https://github.com/libgit2/libgit2/discussions/5932#discussioncomment-1682729).
> @@ -810,18 +810,11 @@ (define-public libgit2
>                (file-name (git-file-name name version))
>                (sha256
>                 (base32
> -                "02x1a4zrzpzjd0yxnsi8njh5hgihc1iy1v4r0fnl8m4ckcgp6x2s"))
> +                "04ypzpicpgq1wh6anwcmjjyh2b854lvjhxq0hq2hbsx7kb14qc1b"))
>                (modules '((guix build utils)))
>                (snippet
>                 '(begin
> -                  (delete-file-recursively "deps")
> -
> -                  ;; The "refs:revparse::date" test is time-dependent: it
> -                  ;; assumes "HEAD@{10 years ago}" matches a specific commit.
> -                  ;; See <https://github.com/libgit2/libgit2/pull/6299>.
> -                  (substitute* "tests/refs/revparse.c"
> -                    (("test_object.*10 years ago.*" all)
> -                     (string-append "// " all "\n")))))))
> +                  (delete-file-recursively "deps")))))
>      (build-system cmake-build-system)
>      (outputs '("out" "debug"))
>      (arguments
> @@ -863,10 +856,10 @@ (define-public libgit2
>      ;; GPLv2 with linking exception
>      (license license:gpl2)))
>  
> -(define-public libgit2-1.3
> +(define-public libgit2-1.4
>    (package
>      (inherit libgit2)
> -    (version "1.3.0")
> +    (version "1.4.5")
>      (source (origin
>                (inherit (package-source libgit2))
>                (method git-fetch)
> @@ -876,7 +869,22 @@ (define-public libgit2-1.3
>                (file-name (git-file-name "libgit2" version))
>                (sha256
>                 (base32
> -                "0vgpb2175a5dhqiy1iwywwppahgqhi340i8bsvafjpvkw284vazd"))))
> +                "0q754ipc6skagszi93lcy6qr09ibavivm2q5i5fhpdblvlnv2p7x"))))))
> +
> +(define-public libgit2-1.3
> +  (package
> +    (inherit libgit2-1.4)
> +    (version "1.3.2")
> +    (source (origin
> +              (inherit (package-source libgit2-1.4))
> +              (method git-fetch)
> +              (uri (git-reference
> +                    (url "https://github.com/libgit2/libgit2")
> +                    (commit (string-append "v" version))))
> +              (file-name (git-file-name "libgit2" version))
> +              (sha256
> +               (base32
> +                "1dngga8jq419z6ps65wpmh2jihcf70k6r98pb1m1yiwj7qqh9792"))))
>      (arguments
>       (substitute-keyword-arguments (package-arguments libgit2)
>         ((#:phases _ '%standard-phases)
> @@ -892,17 +900,25 @@ (define-public libgit2-1.3
>  (define-public libgit2-1.1
>    (package
>      (inherit libgit2-1.3)
> -    (version "1.1.0")
> +    (version "1.1.1")
>      (source (origin
>                (inherit (package-source libgit2-1.3))
>                (file-name #f)                      ;use the default name
>                (method url-fetch)
>                (uri (string-append "https://github.com/libgit2/libgit2/"
> -                                  "releases/download/v" version
> -                                  "/libgit2-" version ".tar.gz"))
> +                                  "archive/refs/tags/v" version ".tar.gz"))

We do not use Github/Gitlab/etc. auto-generated tarballs has there is no
guarantee that they'll be bit-for-bit identical upon regeneration and
this led to broken checksums in the past.  Could you please use the
tag/commit instead?

I noticed about this problem looking at the QA page here:
https://qa.guix.gnu.org/issue/61246.  I'm not sure what are the other
problems reported, they look like false positives to me.

Did you rebuild the dependent packages, used that with Guix without
problems so far?  The QA has yet to answer that question.

Hi,

On Wed, 08 Feb 2023 at 22:25, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:

>> * gnu/packages/version-control.scm (libgit2): Update to 1.5.1.
>> [source]: Remove snippet to comment out the "10 years ago" test, which
>> was removed on newer versions.
>> (libgit2-1.4): New variable. Update to 1.4.5.
>> (libgit2-1.3): Inherit from 'libgit2-1.4'. Update to 1.3.2.
>> (libgit2-1.1): Update to 1.1.1. Add back the snippet which comments out
>> the "10 years ago" test that remains on this older version.
>> * doc/guix.texi (Using a Custom Guix Channel): Add note and example
>> on how to exempt a local guix repository from git ownership checks.
>
> This loooks good, thanks!

This patch series should be split into 3 atomic commits.

And the update of libgit2-1.1 from 1.1.0 to 1.1.1 is not necessary and
even this variable could be removed – what I am suggesting. :-)


Cheers,
simon

Hi Maxim and Zimoun!

qua 08 fev 2023 às 22:25:41 (1675905941), maxim.cournoyer@gmail.com enviou:
> Hello André,
>
> (...)
>
> We do not use Github/Gitlab/etc. auto-generated tarballs has there is no
> guarantee that they'll be bit-for-bit identical upon regeneration and
> this led to broken checksums in the past.  Could you please use the
> tag/commit instead?

Oh I did not know about that. I could use the git tag instead, but after
yours and zimoun's messages I've noticed that:

- I had only check dependencies using libgit2 without any @version numbers
and so I thought that there were fewer dependencies than there are in fact;

- no other package seems to be depending on libgit2-1.1, so it should be
remove instead of updated, as zimoun suggested;

- this patch should probably be on core-updates, not on master.

So I'm inclined to agree with zimoun and just remove libgit2-1.1, what do
you think? I'll work on another version of this patch and get back to
you.

> I noticed about this problem looking at the QA page here:
> https://qa.guix.gnu.org/issue/61246.  I'm not sure what are the other
> problems reported, they look like false positives to me.

I did not know about this QA service, thanks for pointing that out. I
couldn't figure out the other warnings as well, but I only had a quick
look at them.

> Did you rebuild the dependent packages, used that with Guix without
> problems so far?  The QA has yet to answer that question.

I did not rebuild all dependent packages yet, I've rebuild only my local
dependencies on two machines (i686 and x86_64).

Yesterday, however, I've bumped on a build error on libjami that could
be related to this patch, even though it does not seem to be so at a
first glance. The build error occurs at check phase with the following
error:

--- ./test/unitTest/test-suite.log ------------------------------------------

======================================================
   Jami Daemon 13.7.0: test/unitTest/test-suite.log
======================================================

# TOTAL: 15
# PASS:  14
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: ut_scheduler
==================

.F


!!!FAILURES!!!
Test Results:
Run:  1   Failures: 1   Errors: 0


1) test: jami::test::SchedulerTest::schedulerTest (F) line: 74 scheduler.cpp
assertion failed
- Expression: cv.wait_for(lk, std::chrono::seconds(3), [&]{ return taskRun == N; })


FAIL ut_scheduler (exit status: 1)


error: in phase 'check': uncaught exception:
%exception #<&invoke-error program: "make" arguments: ("check" "-j" "2" "V=1") exit-status: 2 term-signal: #f stop-signal: #f>
phase `check' failed after 571.8 seconds
command "make" "check" "-j" "2" "V=1" failed with status 2

---

Thanks for helping me out!

Hi!

sex 10 fev 2023 às 14:54:40 (1676051680), nandre@riseup.net enviou:
> (...)
>
> I did not rebuild all dependent packages yet, I've rebuild only my local
> dependencies on two machines (i686 and x86_64).
> 
> Yesterday, however, I've bumped on a build error on libjami that could
> be related to this patch, even though it does not seem to be so at a
> first glance. The build error occurs at check phase with the following
> error:
> (...)

Forget about this, I've built it on yet another machine without
issues, so this problem is indeed unrelated.

Is there a no-brainer way to try building all dependent packages?

TIA

sex 17 fev 2023 às 16:17:15 (1676661435), nandre@riseup.net enviou:
> (...)
> Is there a no-brainer way to try building all dependent packages?

Sigh, please disregard the above question...

Hi,

André Batista <nandre@riseup.net> writes:

> Hi!
>
> sex 10 fev 2023 às 14:54:40 (1676051680), nandre@riseup.net enviou:
>> (...)
>>
>> I did not rebuild all dependent packages yet, I've rebuild only my local
>> dependencies on two machines (i686 and x86_64).
>> 
>> Yesterday, however, I've bumped on a build error on libjami that could
>> be related to this patch, even though it does not seem to be so at a
>> first glance. The build error occurs at check phase with the following
>> error:
>> (...)
>
> Forget about this, I've built it on yet another machine without
> issues, so this problem is indeed unrelated.
>
> Is there a no-brainer way to try building all dependent packages?

Sadly not from the CLI, I used a bunch of shell script helpers to do so:
https://notabug.org/apteryx/guix-api-examples/src/master/command-line-hacks.sh

sex 17 fev 2023 às 14:46:52 (1676656012), maxim.cournoyer@gmail.com enviou:
> Hi,
> 
> André Batista <nandre@riseup.net> writes:
> 
> > Is there a no-brainer way to try building all dependent packages?
> 
> Sadly not from the CLI, I used a bunch of shell script helpers to do so:
> https://notabug.org/apteryx/guix-api-examples/src/master/command-line-hacks.sh

thanks!

Hi Maxim, André,

I belatedly second Zimoun here:

> This patch series should be split into 3 atomic commits.

Maxim Cournoyer 写道：
> Sadly not from the CLI, I used a bunch of shell script helpers 
> to do so:
> https://notabug.org/apteryx/guix-api-examples/src/master/command-line-hacks.sh

Just FYI, it seems like this didn't catch Julia, which (sigh) 
fails its test suite when the libgit2 version number doesn't match 
its hard-coded expectation.  No biggie, but might help you debug 
your scripts.

Kind regards,

T G-R

Tobias Geerinckx-Rice 写道：
> I belatedly second Zimoun here:
>
>> This patch series should be split into 3 atomic commits.

Or maybe I misinterpreted the intention.

When debugging this, I would have liked to find separate commits 
for each version, or a more generic title (without the misleading 
‘to 1.5.1’).

Kind regards,

T G-R

Hi Tobias!

Tobias Geerinckx-Rice <me@tobias.gr> writes:

> Tobias Geerinckx-Rice 写道：
>> I belatedly second Zimoun here:
>>
>>> This patch series should be split into 3 atomic commits.
>
> Or maybe I misinterpreted the intention.
>
> When debugging this, I would have liked to find separate commits for
> each version, or a more generic title (without the misleading ‘to
> 1.5.1’).

Apologies for the breakage, and thank you for the prompt fix!  I wish I
had the QA's badge of approval, but after waiting more than a week I had
no expectation of when it'd show up.

Hi,

On sam., 18 févr. 2023 at 19:13, Tobias Geerinckx-Rice via Guix-patches via <guix-patches@gnu.org> wrote:
> Tobias Geerinckx-Rice 写道：
>> I belatedly second Zimoun here:
>>
>>> This patch series should be split into 3 atomic commits.
>
> Or maybe I misinterpreted the intention.
>
> When debugging this, I would have liked to find separate commits a
> for each version, or a more generic title (without the misleading 
> ‘to 1.5.1’).

The intention was: « When debugging this, I would have liked to find
separate commits a for each version, or a more generic title (without
the misleading ‘to 1.5.1’). » :-)

Just to point that as member of the Julia team, I know by experience
that the dependency relationship between Julia and the Git ecosystem can
be tedious to find.  Hence my proposal to split – it helps to prevent
breakage or help to debug it.

Thanks Tobias for the quick fix!


Cheers,
simon

Hi,

On sam., 18 févr. 2023 at 15:45, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:

> Apologies for the breakage, and thank you for the prompt fix!  I wish I
> had the QA's badge of approval, but after waiting more than a week I had
> no expectation of when it'd show up.

I agree that it is hard to know if something related to QA is going
wrong or if it is something related to the patch.  I had the issue in
[1,2].

1: https://issues.guix.gnu.org/msgid/86ilg1c0cy.fsf@gmail.com
2: https://issues.guix.gnu.org/msgid/CAJ3okZ3pquWUJxcV09LBeb+6Hk_oZgJX3ThpoMUHEjFixqycHA@mail.gmail.com


Cheers,
simon

Hi Tobias!

sáb 18 fev 2023 às 19:13:53 (1676758433), me@tobias.gr enviou:
>
> When debugging this, I would have liked to find separate commits for each
> version, or a more generic title (without the misleading ‘to 1.5.1’).

Ack! I'll keep that in mind and try to alleviate the burden instead of
aggravating it.

Regards,