Message ID | d02fff8168a225aa7cdcd1a513f5a0beef4fe0b9.1670956476.git.code@greghogan.com |
---|---|
State | New |
Headers | show |
Series | [bug#60042] gnu: git: Update to 2.39.0. | expand |
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
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
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’.
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
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.
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’.
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’.
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
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.
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’.
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
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
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’.
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’.
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
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
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’.
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)