| Message ID | CA+3U0Zn02yBrPjLxbceKMbMpCe9YJ_Kf-bpR7swC44xcN3X3ZA@mail.gmail.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [bug#43427] gnu: zstd: Update to 1.4.5. | expand |
| Context | Check | Description |
|---|---|---|
| cbaines/applying patch | fail | View Laminar job |
Hello Greg, The update is already present on core-updates branch, see: 386457b7bda963be9f0119a785b71bc64e0c105e. Thanks for the patch anyway. Mathieu
Greg,
Mathieu Othacehe 写道：
> The update is already present on core-updates branch,
Sorry for the duplicate work! How were you to've known this, you
ask?
$ guix refresh --list-dependent PACKAGE
or ‘-l’ for short will list the number of rebuilds that a hash
change in PACKAGE would trigger.
If it's higher than 300, the patch belongs on the ‘staging’ or
‘core-updates’ branches instead of ‘master’. The exact numbers
are in the ‘Submitting Patches’ section of the Guix manual.
In practice, it's not always clear-cut. A patch that rebuilds
fewer than 300 packages but includes IceCat, Ungoogled Chromium,
and LibreOffice probably belongs on ‘staging’ regardless. A patch
that rebuilds 350 (fast-building) Perl packages might be OK for
master.
It's good practice to include the branch name (e.g., ‘[PATCH
core-updates]’) when submitting patches not suitable for master.
Kind regards,
T G-R
Thanks, T-G-R. I will endeavor to tag for staging and core-updates going forward. Not sure how I missed the prior commit. I may have been looking among patches. Not sure how I missed the git log, and in the future I will be certain to simply check the latest version from each branch. Would it be feasible to have `guix refresh` consider staging and core-updates when reporting available updates? Greg > On Sep 22, 2020, at 5:59 AM, Tobias Geerinckx-Rice <me@tobias.gr> wrote: > > Greg, > > Mathieu Othacehe 写道： >> The update is already present on core-updates branch, > > Sorry for the duplicate work! How were you to've known this, you ask? > > $ guix refresh --list-dependent PACKAGE > > or ‘-l’ for short will list the number of rebuilds that a hash change in PACKAGE would trigger. > > If it's higher than 300, the patch belongs on the ‘staging’ or ‘core-updates’ branches instead of ‘master’. The exact numbers are in the ‘Submitting Patches’ section of the Guix manual. > > In practice, it's not always clear-cut. A patch that rebuilds fewer than 300 packages but includes IceCat, Ungoogled Chromium, and LibreOffice probably belongs on ‘staging’ regardless. A patch that rebuilds 350 (fast-building) Perl packages might be OK for master. > > It's good practice to include the branch name (e.g., ‘[PATCH core-updates]’) when submitting patches not suitable for master. > > Kind regards, > > T G-R
diff --git a/gnu/packages/compression.scm b/gnu/packages/compression.scm index 97f254ff6e..7f4662dc8b 100644 --- a/gnu/packages/compression.scm +++ b/gnu/packages/compression.scm @@ -1383,14 +1383,14 @@ or junctions, and always follows hard links.") (define-public zstd (package (name "zstd") - (version "1.4.4") + (version "1.4.5") (source (origin (method url-fetch) (uri (string-append " https://github.com/facebook/zstd/releases/download/" "v" version "/zstd-" version ".tar.gz")) (sha256 - (base32 "05ckxap00qvc0j51d3ci38150cxsw82w7s9zgd5fgzspnzmp1vsr")))) + (base32 "17nf0r20360i80689bg5ipxbk2413b2dn3z7wj8byqpiddy1rscq")))) (build-system gnu-build-system) (outputs '("out" ;1.2MiB executables and
From 3875f9c53d6aa9a3c97e0187ab614f44fcf04acf Mon Sep 17 00:00:00 2001 From: Greg Hogan <code@greghogan.com> Date: Tue, 15 Sep 2020 14:06:48 +0000 Subject: [PATCH] gnu: zstd: Update to 1.4.5. * gnu/packages/compression.scm (zstd): Update to 1.4.5. set pkg-config paths in make-flags (see zstd@e668c9b5). --- gnu/packages/compression.scm | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) documentation "lib" ;1.2MiB shared library and headers @@ -1425,6 +1425,11 @@ or junctions, and always follows hard links.") (string-append "PREFIX=" (assoc-ref %outputs "out")) (string-append "LIBDIR=" (assoc-ref %outputs "lib") "/lib") (string-append "INCLUDEDIR=" (assoc-ref %outputs "lib") "/include") + ;; Hard-code the relative paths written to the pkg-config file. + ;; zstd's lib/Makefile expects the exec path ("out" output) to + ;; be a parent path of the library path ("lib" output). + (string-append "PCLIBDIR=" "lib") + (string-append "PCINCDIR=" "include") ;; Skip auto-detection of, and creating a dependency on, the build ;; environment's ‘xz’ for what amounts to a dubious feature anyway. "HAVE_LZMA=0"