[PATCH] gnu: git: Update to 2.39.0.

  • Done
  • quality assurance status badge
Details
4 participants
  • Greg Hogan
  • Leo Famulari
  • Ludovic Courtès
  • zimoun
Owner
unassigned
Submitted by
Greg Hogan
Severity
normal
G
G
Greg Hogan wrote on 13 Dec 2022 19:40
(address . guix-patches@gnu.org)(name . Greg Hogan)(address . code@greghogan.com)
d02fff8168a225aa7cdcd1a513f5a0beef4fe0b9.1670956476.git.code@greghogan.com
* gnu/packages/version-control.scm (git): Update to 2.39.0.
---
gnu/packages/version-control.scm | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

Toggle diff (32 lines)
diff --git a/gnu/packages/version-control.scm b/gnu/packages/version-control.scm
index 5da93fa0ce..fa303ba00b 100644
--- a/gnu/packages/version-control.scm
+++ b/gnu/packages/version-control.scm
@@ -224,14 +224,14 @@ (define git-cross-configure-flags
(define-public git
(package
(name "git")
- (version "2.38.1")
+ (version "2.39.0")
(source (origin
(method url-fetch)
(uri (string-append "mirror://kernel.org/software/scm/git/git-"
version ".tar.xz"))
(sha256
(base32
- "1n8afjjim30lddhm25cdscdr2xfa518293jhqbxy1fd2b3mgipcp"))))
+ "0nr6d46z3zfxbr1psww7vylva3mw6vbhnywixhywm6aszc9rn6ds"))))
(build-system gnu-build-system)
(native-inputs
`(("native-perl" ,perl)
@@ -251,7 +251,7 @@ (define-public git
version ".tar.xz"))
(sha256
(base32
- "17bms6d0v5dw34bpsm78gpq1pn0jp6ap8nbcrby4hzfwa810kya7"))))
+ "0rwl3rkj50r1dkrlgf3d2paxbz5fz7bq4azhzb6a4d6c8bazcw3p"))))
;; For subtree documentation.
("asciidoc" ,asciidoc)
("docbook-xsl" ,docbook-xsl)
--
2.38.1
Z
Z
zimoun wrote on 15 Dec 2022 12:35
(name . Greg Hogan)(address . code@greghogan.com)
86len8dhnb.fsf@gmail.com
Hi,

On Tue, 13 Dec 2022 at 18:40, Greg Hogan <code@greghogan.com> wrote:
Toggle quote (2 lines)
> * gnu/packages/version-control.scm (git): Update to 2.39.0.

This change is for staging, IMHO.

Toggle snippet (4 lines)
$ guix refresh -l git git-minimal | cut -f1 -d':'
Building the following 302 packages would ensure 664 dependent packages are rebuilt

Cheers,
simon
G
G
Greg Hogan wrote on 15 Dec 2022 19:55
(address . 60042-done@debbugs.gnu.org)
CA+3U0ZnU-_yfDxF2pgkRWHQxCon=1W1wH7ODJyV=VZz6+0nG0w@mail.gmail.com
On Thu, Dec 15, 2022 at 6:39 AM zimoun <zimon.toutoune@gmail.com> wrote:
Toggle quote (15 lines)
>
> Hi,
>
> On Tue, 13 Dec 2022 at 18:40, Greg Hogan <code@greghogan.com> wrote:
> > * gnu/packages/version-control.scm (git): Update to 2.39.0.
>
> This change is for staging, IMHO.
>
> --8<---------------cut here---------------start------------->8---
> $ guix refresh -l git git-minimal | cut -f1 -d':'
> Building the following 302 packages would ensure 664 dependent packages are rebuilt
> --8<---------------cut here---------------end--------------->8---
>
> Cheers,
> simon
Closed
L
L
Ludovic Courtès wrote on 20 Dec 2022 15:52
Re: bug#60042: [PATCH] gnu: git: Update to 2.39.0.
(name . zimoun)(address . zimon.toutoune@gmail.com)
87edsu6sbp.fsf_-_@gnu.org
Hi,

zimoun <zimon.toutoune@gmail.com> skribis:

Toggle quote (8 lines)
> On Tue, 13 Dec 2022 at 18:40, Greg Hogan <code@greghogan.com> wrote:
>> * gnu/packages/version-control.scm (git): Update to 2.39.0.
>
> This change is for staging, IMHO.
>
> $ guix refresh -l git git-minimal | cut -f1 -d':'
> Building the following 302 packages would ensure 664 dependent packages are rebuilt

According to figures in the manual, it’s for ‘staging’ (info "(guix)
Submitting Patches"). But I guess those figures are less appropriate
now that the package collection and build farms have grown. We’ll have
to think about it!

Ludo’.
S
S
Simon Tournier wrote on 20 Dec 2022 16:38
(name . Ludovic Courtès)(address . ludo@gnu.org)
CAJ3okZ3j+HTATsoGE978b+LGk0KAEM7-BAGSy_Gtm61FzTWwQA@mail.gmail.com
Hi Ludo,

On Tue, 20 Dec 2022 at 15:52, Ludovic Courtès <ludo@gnu.org> wrote:

Toggle quote (5 lines)
> According to figures in the manual, it’s for ‘staging’ (info "(guix)
> Submitting Patches"). But I guess those figures are less appropriate
> now that the package collection and build farms have grown. We’ll have
> to think about it!

On one hand, I agree that these numbers could be revisited on the
light of the new QA. On the other hand, this "trivial" patch implies
a Julia (almost) world rebuild -- so potentially some breakages. And
personally, I cannot run again and again after broken packages from
unrelated changes. :-)

Well, if the new QA is able to deal with heavy rebuilds, yeah for
sure, if all is green and the patch does not introduce any breakage,
there is no reason for not merging. However, if you go to the
dashboard [1], it is far from being all green. And do not give a look
for other architectures [2] than x86_64. And these breakages often
arise from an unrelated minor change.

On a side note, personally I am not convinced that moving fast (=
burning a lot of energy) is something helpful in the world context.
For instance, the same source version of a package as FreeCAD is
almost rebuilt daily [3] (and each build costs ~50min); aside a minor
change elsewhere can easily break it, I am not convinced it brings
something to rebuild it again and again. Well, I have mixed feelings
about this topic and indeed, we will have to think about it.


Cheers,
simon
G
G
Greg Hogan wrote on 20 Dec 2022 17:38
(name . Ludovic Courtès)(address . ludo@gnu.org)
CA+3U0ZmV=50kpOgRGwKnjFA2471O9duKdTJrqdLOZAiQJjeuWQ@mail.gmail.com
On Tue, Dec 20, 2022 at 9:52 AM Ludovic Courtès <ludo@gnu.org> wrote:
Toggle quote (5 lines)
> According to figures in the manual, it’s for ‘staging’ (info "(guix)
> Submitting Patches"). But I guess those figures are less appropriate
> now that the package collection and build farms have grown. We’ll have
> to think about it!

I closed this ticket after noticing that Tobias had hotfixed the
update to the staging branch.

In addition to potentially increasing the dependent package
thresholds, we should consider alternatives to the process for
submitting, reviewing, and testing the patches for staging and
core-updates. I think just having an announced window for submissions
(perhaps 1 week for staging and 2 weeks for core-updates) would
eliminate some unnecessary work. There would be little benefit to
submitting simple package updates before the open window when an even
newer release may still become available. Also, this could encourage
more participation in the validation and testing process: similar to
how releases are branched off master, we could encourage developers
and users to test the pre-merge staging and (especially) core-updates.
L
L
Ludovic Courtès wrote on 24 Dec 2022 00:51
Julia dependency on Git
(name . Simon Tournier)(address . zimon.toutoune@gmail.com)
875ye1znjz.fsf_-_@gnu.org
Hi Simon,

Simon Tournier <zimon.toutoune@gmail.com> skribis:

Toggle quote (4 lines)
> On one hand, I agree that these numbers could be revisited on the
> light of the new QA. On the other hand, this "trivial" patch implies
> a Julia (almost) world rebuild -- so potentially some breakages.

Oh right. I found that ‘julia-documenter’ depends on ‘git-minimal’; I
changed it to depend on ‘git-minimal/fixed’. (The purpose of ‘/fixed’
variants, such as ‘guile-3.0/fixed’, is to avoid rebuilds of unrelated
sub-graphs.) A few other packages were in a similar situation:

bae13578f7 gnu: python-scikit-build: Depend on 'git-minimal/fixed'.
8f31575ad1 gnu: gnome-photos: Depend on 'git-minimal/fixed'.
0dcca97c9f gnu: opam: Depend on 'git-minimal/fixed'.
9203de5250 gnu: ocamlformat: Depend on 'git-minimal/fixed'.
83b1a2f682 gnu: julia-documenter: Depend on 'git-minimal/fixed'.

This is a simple way to reduce unnecessary rebuilds with potential
breakage, making it less risky and less costly to upgrade Git.

Thanks,
Ludo’.
L
L
Ludovic Courtès wrote on 25 Dec 2022 17:18
Re: bug#60042: [PATCH] gnu: git: Update to 2.39.0.
(name . Greg Hogan)(address . code@greghogan.com)
871qonzcc2.fsf@gnu.org
Hi,

Greg Hogan <code@greghogan.com> skribis:

Toggle quote (3 lines)
> I closed this ticket after noticing that Tobias had hotfixed the
> update to the staging branch.

Oh good.

Toggle quote (12 lines)
> In addition to potentially increasing the dependent package
> thresholds, we should consider alternatives to the process for
> submitting, reviewing, and testing the patches for staging and
> core-updates. I think just having an announced window for submissions
> (perhaps 1 week for staging and 2 weeks for core-updates) would
> eliminate some unnecessary work. There would be little benefit to
> submitting simple package updates before the open window when an even
> newer release may still become available. Also, this could encourage
> more participation in the validation and testing process: similar to
> how releases are branched off master, we could encourage developers
> and users to test the pre-merge staging and (especially) core-updates.

Yes, I agree. I once proposed adding a web page that would list open
branches with target merge dates:


Perhaps it’s time to pick it up? The difficulty here will be to honor
the time windows.

Thanks,
Ludo’.
Z
Z
zimoun wrote on 30 Dec 2022 14:15
Re: [bug#60042] Julia dependency on Git
(name . Ludovic Courtès)(address . ludo@gnu.org)
87bknlkp72.fsf@gmail.com
Hi Ludo,

On Sat, 24 Dec 2022 at 00:51, Ludovic Courtès <ludo@gnu.org> wrote:

Toggle quote (5 lines)
> Oh right. I found that ‘julia-documenter’ depends on ‘git-minimal’; I
> changed it to depend on ‘git-minimal/fixed’. (The purpose of ‘/fixed’
> variants, such as ‘guile-3.0/fixed’, is to avoid rebuilds of unrelated
> sub-graphs.) A few other packages were in a similar situation:

Two things are really hard in computer science: naming and cache
invalidation. :-)

Here, the suffix /fixed is confusing because it is used for the both
cases:

1) You use fixed to describe something which stays the same and does not
or cannot vary.
2) If you fix a problem or a bad situation, you deal with it and make it
satisfactory.


For instance, it is the meaning #2,

Toggle snippet (10 lines)
(define gnupg/fixed
(package
(inherit gnupg)
(source (origin
(inherit (package-source gnupg))
(patches
(append (origin-patches (package-source gnupg))
(search-patches "gnupg-CVE-2022-34903.patch")))))))

therefore, I expect that the package gnupg is replaced (grafted). And
indeed,

Toggle snippet (12 lines)
(define-public gnupg
(package
(name "gnupg")
;; Note: The 2.2.X releases are Long Term Support (LTS), so stick to it
;; for our stable 'gnupg'.
;; Note2: 2.2.33 currently suffers from regressions, so do not update to it
;; (see: https://dev.gnupg.org/T5742).
(version "2.2.32")
(replacement gnupg/fixed)


Well, the situation looks like:

version-control.scm:673:(define-public git-minimal/fixed #1 stable
onc-rpc.scm:91: (define libtirpc/fixed #2
gnupg.scm:257: (define libksba/fixed #2
gnupg.scm:369: (define gnupg/fixed #2
linux.scm:2164: (define-public util-linux/fixed #2
linux.scm:7674: (define-public libnftnl/fixed #1 stable
tls.scm:601: (define openssl/fixed #2
samba.scm:295: (define-public samba/fixed #1 stable
xml.scm:159: (define expat/fixed #2
compression.scm:1890: (define unzip/fixed #2
guile.scm:424: (define-public guile-3.0/fixed #1 stable


Therefore, to avoid the confusion I would suggest to use /pinned instead
of /fixed for this stable meaning. Hence, 4 renaming. WDYT?


Cheers,
simon
L
L
Leo Famulari wrote on 3 Jan 18:59 +0100
(name . zimoun)(address . zimon.toutoune@gmail.com)
Y7RtCAI/u7RKgKlu@jasmine.lan
On Fri, Dec 30, 2022 at 02:15:29PM +0100, zimoun wrote:
Toggle quote (3 lines)
> Therefore, to avoid the confusion I would suggest to use /pinned instead
> of /fixed for this stable meaning. Hence, 4 renaming. WDYT?

I agree we should improve this confusing situation.

An alternative approach would be to replace meaning #2 with /grafted

I don't have a preference either way.
L
L
Ludovic Courtès wrote on 6 Jan 23:55 +0100
What to call pinned package versions
(name . zimoun)(address . zimon.toutoune@gmail.com)
878rifxogc.fsf_-_@gnu.org
zimoun <zimon.toutoune@gmail.com> skribis:

Toggle quote (8 lines)
> Here, the suffix /fixed is confusing because it is used for the both
> cases:
>
> 1) You use fixed to describe something which stays the same and does not
> or cannot vary.
> 2) If you fix a problem or a bad situation, you deal with it and make it
> satisfactory.

I know, English… :-)

The first instance of this pattern was ‘guile/fixed’, probably 10 years
ago, so I guess it takes precedence.

But maybe we could agree on ‘/pinned’ instead and adjust code
accordingly?

Ludo’.
S
S
Simon Tournier wrote on 9 Jan 11:32 +0100
(name . Ludovic Courtès)(address . ludo@gnu.org)
87h6x0yp57.fsf@gmail.com
Hi,

On ven., 06 janv. 2023 at 23:55, Ludovic Courtès <ludo@gnu.org> wrote:

Toggle quote (16 lines)
>> Here, the suffix /fixed is confusing because it is used for the both
>> cases:
>>
>> 1) You use fixed to describe something which stays the same and does not
>> or cannot vary.
>> 2) If you fix a problem or a bad situation, you deal with it and make it
>> satisfactory.
>
> I know, English… :-)
>
> The first instance of this pattern was ‘guile/fixed’, probably 10 years
> ago, so I guess it takes precedence.
>
> But maybe we could agree on ‘/pinned’ instead and adjust code
> accordingly?

Sorry, I miss your suggestion. :-)

From my understanding:

+ Option a.

version-control.scm:673:(define-public git-minimal/fixed -> git-minimal/pinned
linux.scm:7674: (define-public libnftnl/fixed -> libnftnl/pinned
samba.scm:295: (define-public samba/fixed -> samba/pinned
guile.scm:424: (define-public guile-3.0/fixed -> guile-3.0/pinned

+ Option b.

onc-rpc.scm:91: (define libtirpc/fixed -> libtirpc/grafted
gnupg.scm:257: (define libksba/fixed -> libksba/grafted
gnupg.scm:369: (define gnupg/fixed -> gnupg/grafted
linux.scm:2164: (define-public util-linux/fixed -> util-linux/grafted
tls.scm:601: (define openssl/fixed -> openssl/grafted
xml.scm:159: (define expat/fixed -> expat/grafted
compression.scm:1890: (define unzip/fixed -> unzip/grafted

+ Option c. = option a. + option b. (remove reference to /fixed)


From my point of view, option a. is the less “disruptive” because for
instance we use the term “Fixes“ in commit message when a bug is indeed
fixed.

WDYT?

Cheers,
simon
S
S
Simon Tournier wrote on 11 Jan 14:19 +0100
(name . Ludovic Courtès)(address . ludo@gnu.org)
86h6wx5huf.fsf@gmail.com
Hi,

On Mon, 09 Jan 2023 at 11:32, Simon Tournier <zimon.toutoune@gmail.com> wrote:

Toggle quote (4 lines)
> + Option a.
>
> version-control.scm:673:(define-public git-minimal/fixed -> git-minimal/pinned

[...]


Toggle quote (4 lines)
> + Option b.
>
> onc-rpc.scm:91: (define libtirpc/fixed -> libtirpc/grafted

[...]


Toggle quote (7 lines)
> + Option c. = option a. + option b. (remove reference to /fixed)
>
>
> From my point of view, option a. is the less “disruptive” because for
> instance we use the term “Fixes“ in commit message when a bug is indeed
> fixed.

Well, we also have another option:

+ Option d.: the version in the symbol; as in htslib-1.14.

Considering the initial example,

git-minimal/fixed -> git-minimal-2.33.1


This option d. appears to me the best:

+ it avoids ambiguity.

+ it is explicit – no need to grep for finding which version
git-minimal/pinned refers to when reading Julia package recipes.

+ we are already doing that for multi-version packages.

Moreover, a ’default’ property could be also assigned to default
version (here the package defined by the symbol git-minimal). And it
would allow to have less surprise when some multi versions package are
exported or incorrectly hidden. See #60200 [1].

WDYT?

If we agree on Option d., then I could prepare a patch set and document
in the manual. Let me know. :-)



Cheers,
simon
L
L
Ludovic Courtès wrote on 11 Jan 18:26 +0100
(name . Simon Tournier)(address . zimon.toutoune@gmail.com)
87fschkmo9.fsf@gnu.org
Hi,

Simon Tournier <zimon.toutoune@gmail.com> skribis:

Toggle quote (41 lines)
> On ven., 06 janv. 2023 at 23:55, Ludovic Courtès <ludo@gnu.org> wrote:
>
>>> Here, the suffix /fixed is confusing because it is used for the both
>>> cases:
>>>
>>> 1) You use fixed to describe something which stays the same and does not
>>> or cannot vary.
>>> 2) If you fix a problem or a bad situation, you deal with it and make it
>>> satisfactory.
>>
>> I know, English… :-)
>>
>> The first instance of this pattern was ‘guile/fixed’, probably 10 years
>> ago, so I guess it takes precedence.
>>
>> But maybe we could agree on ‘/pinned’ instead and adjust code
>> accordingly?
>
> Sorry, I miss your suggestion. :-)
>
> From my understanding:
>
> + Option a.
>
> version-control.scm:673:(define-public git-minimal/fixed -> git-minimal/pinned
> linux.scm:7674: (define-public libnftnl/fixed -> libnftnl/pinned
> samba.scm:295: (define-public samba/fixed -> samba/pinned
> guile.scm:424: (define-public guile-3.0/fixed -> guile-3.0/pinned
>
> + Option b.
>
> onc-rpc.scm:91: (define libtirpc/fixed -> libtirpc/grafted
> gnupg.scm:257: (define libksba/fixed -> libksba/grafted
> gnupg.scm:369: (define gnupg/fixed -> gnupg/grafted
> linux.scm:2164: (define-public util-linux/fixed -> util-linux/grafted
> tls.scm:601: (define openssl/fixed -> openssl/grafted
> xml.scm:159: (define expat/fixed -> expat/grafted
> compression.scm:1890: (define unzip/fixed -> unzip/grafted
>
> + Option c. = option a. + option b. (remove reference to /fixed)

I’m for Option a.

Would you like to submit a patch?

Ludo’.
L
L
Ludovic Courtès wrote on 11 Jan 18:27 +0100
(name . Simon Tournier)(address . zimon.toutoune@gmail.com)
87bkn5kmlu.fsf@gnu.org
Simon Tournier <zimon.toutoune@gmail.com> skribis:

Toggle quote (8 lines)
> Well, we also have another option:
>
> + Option d.: the version in the symbol; as in htslib-1.14.
>
> Considering the initial example,
>
> git-minimal/fixed -> git-minimal-2.33.1

That would require us to update all the users of this package anytime we
change versions, so to me that’s much less convenient that
‘git-minimal/fixed’. It also fails to convey the intent, which is to
pin to a version, whichever that is.

Ludo’.
Z
?