Message ID | 20201025103508.6845-1-mail@cbaines.net |
---|---|
State | Accepted |
Headers | show |
Series | Update netcdf. | expand |
Context | Check | Description |
---|---|---|
cbaines/issue | success | View issue |
cbaines/comparison | success | View comparision |
cbaines/git branch | success | View Git branch |
cbaines/applying patch | success | View Laminar job |
cbaines/issue | success | View issue |
cbaines/comparison | success | View comparision |
cbaines/git branch | success | View Git branch |
cbaines/applying patch | success | View Laminar job |
On 25.10.20 11:35, Christopher Baines wrote: > This will fix an issue building qgis. > > * gnu/packages/maths.scm (netcdf): Update to 4.7.4. > [source]: Remove the netcdf-tst_h_par.patch. > [inputs]: Update hdf5 and add curl. > * gnu/packages/patches/netcdf-tst_h_par.patch: Delete. > * gnu/local.mk (dist_patch_DATA): Remove deleted patch. > --- [...] > (source > (origin > (method url-fetch) > - (uri (string-append "ftp://ftp.unidata.ucar.edu/pub/netcdf/" > - "netcdf-" version ".tar.gz")) > + (uri (string-append > + "https://www.unidata.ucar.edu/downloads/netcdf/ftp/" > + "netcdf-c-" version ".tar.gz")) Do we usually mention such changes in the commit message?
Hi, Christopher Baines <mail@cbaines.net> skribis: > This will fix an issue building qgis. > > * gnu/packages/maths.scm (netcdf): Update to 4.7.4. > [source]: Remove the netcdf-tst_h_par.patch. > [inputs]: Update hdf5 and add curl. > * gnu/packages/patches/netcdf-tst_h_par.patch: Delete. > * gnu/local.mk (dist_patch_DATA): Remove deleted patch. Great, the whole series LGTM, thanks! How to find it at <https://data.guix-patches.cbaines.net/>? Ludo’.
Hi, On Sun, 25 Oct 2020 at 21:26, Jonathan Brielmaier <jonathan.brielmaier@web.de> wrote: > On 25.10.20 11:35, Christopher Baines wrote: >> * gnu/packages/maths.scm (netcdf): Update to 4.7.4. >> [source]: Remove the netcdf-tst_h_par.patch. >> [inputs]: Update hdf5 and add curl. >> * gnu/packages/patches/netcdf-tst_h_par.patch: Delete. >> * gnu/local.mk (dist_patch_DATA): Remove deleted patch. > Do we usually mention such changes in the commit message? Why not? For example, recently I dug in Julia history and these would have saved some time (read “git log” and not the diff themselves). Well, my poor opinion. :-) All the best, simon
Jonathan Brielmaier <jonathan.brielmaier@web.de> writes: > On 25.10.20 11:35, Christopher Baines wrote: >> This will fix an issue building qgis. >> >> * gnu/packages/maths.scm (netcdf): Update to 4.7.4. >> [source]: Remove the netcdf-tst_h_par.patch. >> [inputs]: Update hdf5 and add curl. >> * gnu/packages/patches/netcdf-tst_h_par.patch: Delete. >> * gnu/local.mk (dist_patch_DATA): Remove deleted patch. >> --- > [...] >> (source >> (origin >> (method url-fetch) >> - (uri (string-append "ftp://ftp.unidata.ucar.edu/pub/netcdf/" >> - "netcdf-" version ".tar.gz")) >> + (uri (string-append >> + "https://www.unidata.ucar.edu/downloads/netcdf/ftp/" >> + "netcdf-c-" version ".tar.gz")) > > Do we usually mention such changes in the commit message? Assuming you were referring to the change in name for the source tarball, I've now added a bit about that in to the commit message. I don't really have that much information to add though, just that new releases seem to have a different name.
Ludovic Courtès <ludo@gnu.org> writes: > Hi, > > Christopher Baines <mail@cbaines.net> skribis: > >> This will fix an issue building qgis. >> >> * gnu/packages/maths.scm (netcdf): Update to 4.7.4. >> [source]: Remove the netcdf-tst_h_par.patch. >> [inputs]: Update hdf5 and add curl. >> * gnu/packages/patches/netcdf-tst_h_par.patch: Delete. >> * gnu/local.mk (dist_patch_DATA): Remove deleted patch. > > Great, the whole series LGTM, thanks! Cool, I've pushed this as 952c62762d3bc8750dfd61a33b13d19ec9d775f7 now. > How to find it at <https://data.guix-patches.cbaines.net/>? I'd always start at Patchwork, so https://patchwork.cbaines.net/ . You might be able to spot it in the list, but you can also search by clicking on "Show patches with" in the top left [1]. 1: https://patchwork.cbaines.net/project/guix-patches/list/?series=&submitter=&state=&q=44208&archive=&delegate= There's a few issues with the processing of this series, it was processed twice, with the first attempt missing a patch. Also, the check linking to issues.guix.info is broken. I think I've fixed both of the underlying issues with the relevant scripts now, so these issues should be fixed for future series.
Hi, Christopher Baines <mail@cbaines.net> skribis: > I'd always start at Patchwork, so https://patchwork.cbaines.net/ . You > might be able to spot it in the list, but you can also search by > clicking on "Show patches with" in the top left [1]. > > 1: https://patchwork.cbaines.net/project/guix-patches/list/?series=&submitter=&state=&q=44208&archive=&delegate= OK, this one is now empty, but I guess that’s expected. Of the 5 “checks” that appear on each page, ‘cbaines/applying patch’ is really just about applying the patch to ‘master’, right? And ‘cbaines/submitting builds’ is about actually building things? It’s surprising because when you go the comparison page, sometimes you can see that builds are scheduled, so we don’t yet whether it has succeeded. But my understanding is that the Patchwork UI will only display whether a build has been submitted, not whether it has succeeded, correct? We need a hands-on session. :-) Thanks, Ludo’.
Ludovic Courtès <ludo@gnu.org> writes: > Hi, > > Christopher Baines <mail@cbaines.net> skribis: > >> I'd always start at Patchwork, so https://patchwork.cbaines.net/ . You >> might be able to spot it in the list, but you can also search by >> clicking on "Show patches with" in the top left [1]. >> >> 1: https://patchwork.cbaines.net/project/guix-patches/list/?series=&submitter=&state=&q=44208&archive=&delegate= > > OK, this one is now empty, but I guess that’s expected. > > Of the 5 “checks” that appear on each page, ‘cbaines/applying patch’ is > really just about applying the patch to ‘master’, right? And > ‘cbaines/submitting builds’ is about actually building things? Yeah, the applying patch check reflects something about Git's success at applying the patch, which happens in the Laminar job which is linked to. Sometimes the check will fail, but a branch is still created, and sometimes it'll fail and no branch will be created. Applying patches is a hard problem. As for the submitting builds check, that's reported by the script that submits the builds to the coordinator instance being used. So yes, it'll appear when the builds are submitted, and hopefully it doesn't take too long for the builds to happen. > It’s surprising because when you go the comparison page, sometimes you > can see that builds are scheduled, so we don’t yet whether it has > succeeded. But my understanding is that the Patchwork UI will only > display whether a build has been submitted, not whether it has > succeeded, correct? Indeed. It's possible to feed information about the build results back in to Patchwork, but that'll require polling/watching the build results as they're fed back to the Guix Data Service, I'm also not sure how flexible Patchwork checks are. > We need a hands-on session. :-) Yeah, next on my list of things is to actually send an email out about the recent changes, but I can hopefully do more with this patch review stuff over the next month or two. My innovation for today is including some indication of build statuses on the package derivation comparision page, and excitingly builds are starting to happen for patches that I'm looking at (like [1] and [2]). 1: https://data.guix-patches.cbaines.net/compare/package-derivations?base_commit=c15509682f931f8afbe2d71ccdef278454c53774&target_commit=d9a510a2b972b90f8efed9172608f8e0d22768d1&locale=en_US.UTF-8 2: https://data.guix-patches.cbaines.net/compare/package-derivations?base_commit=1c6d98533153bc8e0e36236e7fbcf1eb5e178d26&target_commit=8335d68660ce8813b6bbf515e40ed01cae4e7fb7&locale=en_US.UTF-8
Hi! Christopher Baines <mail@cbaines.net> skribis: > Yeah, next on my list of things is to actually send an email out about > the recent changes, but I can hopefully do more with this patch review > stuff over the next month or two. Neat. > My innovation for today is including some indication of build statuses > on the package derivation comparision page, and excitingly builds are > starting to happen for patches that I'm looking at (like [1] and [2]). > > 1: https://data.guix-patches.cbaines.net/compare/package-derivations?base_commit=c15509682f931f8afbe2d71ccdef278454c53774&target_commit=d9a510a2b972b90f8efed9172608f8e0d22768d1&locale=en_US.UTF-8 > 2: https://data.guix-patches.cbaines.net/compare/package-derivations?base_commit=1c6d98533153bc8e0e36236e7fbcf1eb5e178d26&target_commit=8335d68660ce8813b6bbf515e40ed01cae4e7fb7&locale=en_US.UTF-8 Very nice! #2 is giving me “unknown commit”, maybe because the branch has now vanished or something? Thanks, Ludo’.
Ludovic Courtès <ludo@gnu.org> writes: > Hi! > > Christopher Baines <mail@cbaines.net> skribis: > >> Yeah, next on my list of things is to actually send an email out about >> the recent changes, but I can hopefully do more with this patch review >> stuff over the next month or two. > > Neat. > >> My innovation for today is including some indication of build statuses >> on the package derivation comparision page, and excitingly builds are >> starting to happen for patches that I'm looking at (like [1] and [2]). >> >> 1: https://data.guix-patches.cbaines.net/compare/package-derivations?base_commit=c15509682f931f8afbe2d71ccdef278454c53774&target_commit=d9a510a2b972b90f8efed9172608f8e0d22768d1&locale=en_US.UTF-8 >> 2: https://data.guix-patches.cbaines.net/compare/package-derivations?base_commit=1c6d98533153bc8e0e36236e7fbcf1eb5e178d26&target_commit=8335d68660ce8813b6bbf515e40ed01cae4e7fb7&locale=en_US.UTF-8 > > Very nice! #2 is giving me “unknown commit”, maybe because the branch > has now vanished or something? Yeah, to try and keep the Guix Data Service database from growing indefinitely, the branches for patches are automatically deleted when the Debbugs issue is closed, and then there's some code to remove the relevant data from the Guix Data Service. The last bit still needs some more work to happen automatically, and I realised yesterday that I may need to also automate cancelling builds to coincide with the derivations being removed from the Guix Data Service (otherwise when the build comes around, the agents can't fetch the derivation, also it's probably good not to waste time on these builds).
diff --git a/gnu/local.mk b/gnu/local.mk index 1a01360d72..0ada3b727b 100644 --- a/gnu/local.mk +++ b/gnu/local.mk @@ -1355,7 +1355,6 @@ dist_patch_DATA = \ %D%/packages/patches/m4-gnulib-libio.patch \ %D%/packages/patches/ncompress-fix-softlinks.patch \ %D%/packages/patches/netcdf-date-time.patch \ - %D%/packages/patches/netcdf-tst_h_par.patch \ %D%/packages/patches/netpbm-CVE-2017-2586.patch \ %D%/packages/patches/netpbm-CVE-2017-2587.patch \ %D%/packages/patches/netsurf-message-timestamp.patch \ diff --git a/gnu/packages/maths.scm b/gnu/packages/maths.scm index f7565dd885..d2631501aa 100644 --- a/gnu/packages/maths.scm +++ b/gnu/packages/maths.scm @@ -1538,17 +1538,17 @@ similar to MATLAB, GNU Octave or SciPy.") (define-public netcdf (package (name "netcdf") - (version "4.4.1.1") + (version "4.7.4") (source (origin (method url-fetch) - (uri (string-append "ftp://ftp.unidata.ucar.edu/pub/netcdf/" - "netcdf-" version ".tar.gz")) + (uri (string-append + "https://www.unidata.ucar.edu/downloads/netcdf/ftp/" + "netcdf-c-" version ".tar.gz")) (sha256 (base32 - "1blc7ik5yin7i0ls2kag0a9xjk12m0dzx6v1x88az3ras3scci2d")) - (patches (search-patches "netcdf-date-time.patch" - "netcdf-tst_h_par.patch")))) + "1a2fpp15a2rl1m50gcvvzd9y6bavl6vjf9zzf63sz5gdmq06yiqf")) + (patches (search-patches "netcdf-date-time.patch")))) (build-system gnu-build-system) (native-inputs `(("m4" ,m4) @@ -1556,10 +1556,8 @@ similar to MATLAB, GNU Octave or SciPy.") ("graphviz" ,graphviz))) (inputs `(("hdf4" ,hdf4-alt) - - ;; XXX: The 'tst_nccopy4.sh' test fails when using hdf5-1.10. - ("hdf5" ,hdf5-1.8) - + ("hdf5" ,hdf5) + ("curl" ,curl) ("zlib" ,zlib) ("libjpeg" ,libjpeg-turbo))) (arguments diff --git a/gnu/packages/patches/netcdf-date-time.patch b/gnu/packages/patches/netcdf-date-time.patch index a4e7925aa1..0bdfc55299 100644 --- a/gnu/packages/patches/netcdf-date-time.patch +++ b/gnu/packages/patches/netcdf-date-time.patch @@ -3,9 +3,9 @@ @@ -13,7 +13,7 @@ #endif - /* Tell the user the version of netCDF. */ + /** @internal The version string for the library, used by + * nc_inq_libvers(). */ -static const char nc_libvers[] = PACKAGE_VERSION " of "__DATE__" "__TIME__" $"; -+static const char nc_libvers[] = PACKAGE_VERSION" $"; ++static const char nc_libvers[] = PACKAGE_VERSION " $"; /** - \defgroup lib_version Library Version diff --git a/gnu/packages/patches/netcdf-tst_h_par.patch b/gnu/packages/patches/netcdf-tst_h_par.patch deleted file mode 100644 index ac14a4c0a2..0000000000 --- a/gnu/packages/patches/netcdf-tst_h_par.patch +++ /dev/null @@ -1,21 +0,0 @@ -From a83702834938b23cc2e843589aa223e2024a7e6f Mon Sep 17 00:00:00 2001 -From: Orion Poplawski <orion@cora.nwra.com> -Date: Tue, 29 Nov 2016 11:48:01 -0700 -Subject: [PATCH] Add missing #include "err_macros.h" to tst_h_par.c - ---- - h5_test/tst_h_par.c | 1 + - 1 file changed, 1 insertion(+) - -diff --git a/h5_test/tst_h_par.c b/h5_test/tst_h_par.c -index c3da7f4..a419d55 100644 ---- a/h5_test/tst_h_par.c -+++ b/h5_test/tst_h_par.c -@@ -11,6 +11,7 @@ - $Id: tst_h_par.c,v 1.15 2010/05/25 13:53:04 ed Exp $ - */ - #include <nc_tests.h> -+#include "err_macros.h" - #include <hdf5.h> - - /* Defining USE_MPE causes the MPE trace library to be used (and you