[bug#60042] [PATCH] gnu: git: Update to 2.39.0.

[bug#60042] [PATCH] gnu: git: Update to 2.39.0.

[Greg Hogan]

* gnu/packages/version-control.scm (git): Update to 2.39.0.
---
 gnu/packages/version-control.scm | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

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

[bug#60042] [PATCH] gnu: git: Update to 2.39.0.

[zimoun]

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

bug#60042: [PATCH] gnu: git: Update to 2.39.0.

[Greg Hogan]

On Thu, Dec 15, 2022 at 6:39 AM zimoun <zimon.toutoune@gmail.com> wrote:
>
> 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

[bug#60042] [PATCH] gnu: git: Update to 2.39.0.

[Ludovic Courtès]

Hi,

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

> 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’.

[bug#60042] [PATCH] gnu: git: Update to 2.39.0.

[Simon Tournier]

Hi Ludo,

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

> 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.

1: <http://ci.guix.gnu.org/eval/54803/dashboard>
2: <http://ci.guix.gnu.org/eval/54803/dashboard?system=i686-linux>
3: <https://data.guix.gnu.org/repository/1/branch/master/package/freecad/output-history>

Cheers,
simon

[bug#60042] [PATCH] gnu: git: Update to 2.39.0.

[Greg Hogan]

On Tue, Dec 20, 2022 at 9:52 AM Ludovic Courtès <ludo@gnu.org> wrote:
> 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.

[bug#60042] Julia dependency on Git

[Ludovic Courtès]

Hi Simon,

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

> 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’.

[bug#60042] [PATCH] gnu: git: Update to 2.39.0.

[Ludovic Courtès]

Hi,

Greg Hogan <code@greghogan.com> skribis:

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

Oh good.

> 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:

  https://issues.guix.gnu.org/49334

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

Thanks,
Ludo’.

[bug#60042] Julia dependency on Git

[zimoun]

Hi Ludo,

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

> 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,

--8<---------------cut here---------------start------------->8---
(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")))))))
--8<---------------cut here---------------end--------------->8---

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

--8<---------------cut here---------------start------------->8---
(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)
--8<---------------cut here---------------end--------------->8---


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

[bug#60042] Julia dependency on Git

[Leo Famulari]

On Fri, Dec 30, 2022 at 02:15:29PM +0100, zimoun wrote:
> 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.

[bug#60042] What to call pinned package versions

[Ludovic Courtès]

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

> 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’.

[bug#60042] What to call pinned package versions

[Simon Tournier]

Hi,

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)


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

[bug#60042] What to call pinned package versions

[Simon Tournier]

Hi,

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

>  + Option a.
>
> version-control.scm:673:(define-public git-minimal/fixed -> git-minimal/pinned

[...]


>  + Option b.
>
> onc-rpc.scm:91:         (define libtirpc/fixed          -> libtirpc/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.

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. :-)

1: <http://issues.guix.gnu.org/msgid/Y6LQs9+in964glaz@noor.fritz.box>


Cheers,
simon

[bug#60042] What to call pinned package versions

[Ludovic Courtès]

Hi,

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

> 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’.

[bug#60042] What to call pinned package versions

[Ludovic Courtès]

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

> 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’.

[bug#60042] What to call pinned package versions

[zimoun]

Hi,

On Wed, 11 Jan 2023 at 18:26, Ludovic Courtès <ludo@gnu.org> wrote:

> Would you like to submit a patch?

Done with <http://issues.guix.gnu.org/issue/61078>.

Cheers,
simon

[bug#60042] open branches with target merge dates (was Re: [bug#60042] [PATCH] gnu: git: Update to 2.39.0.)

[Simon Tournier]

Hi,

On dim., 25 déc. 2022 at 17:18, Ludovic Courtès <ludo@gnu.org> wrote:

> Yes, I agree.  I once proposed adding a web page that would list open
> branches with target merge dates:
>
>   https://issues.guix.gnu.org/49334
>
> Perhaps it’s time to pick it up?  The difficulty here will be to honor
> the time windows.

Does this proposal still make sense in the frame of feature branch as
discussed in <https://yhetil.org/guix/Y+Tk0OKTyKKDqqlm@jurong>?

Cheers,
simon

[bug#60042] open branches with target merge dates (was Re: [bug#60042] [PATCH] gnu: git: Update to 2.39.0.)

[Ludovic Courtès]

Hi Simon,

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

> On dim., 25 déc. 2022 at 17:18, Ludovic Courtès <ludo@gnu.org> wrote:
>
>> Yes, I agree.  I once proposed adding a web page that would list open
>> branches with target merge dates:
>>
>>   https://issues.guix.gnu.org/49334
>>
>> Perhaps it’s time to pick it up?  The difficulty here will be to honor
>> the time windows.
>
> Does this proposal still make sense in the frame of feature branch as
> discussed in <https://yhetil.org/guix/Y+Tk0OKTyKKDqqlm@jurong>?

Not so much, except perhaps for ‘core-updates’?

Ludo’.