[bug#43427] [PATCH] gnu: zstd: Update to 1.4.5.

[bug#43427] [PATCH] gnu: zstd: Update to 1.4.5.

[Greg Hogan]

[-- Attachment #1: Type: text/plain, Size: 2193 bytes --]

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(-)

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
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"
-- 
2.28.0

[-- Attachment #2: Type: text/html, Size: 2853 bytes --]

bug#43427: [PATCH] gnu: zstd: Update to 1.4.5.

[Mathieu Othacehe]

Hello Greg,

The update is already present on core-updates branch, see:
386457b7bda963be9f0119a785b71bc64e0c105e.

Thanks for the patch anyway.

Mathieu

[bug#43427] [PATCH] gnu: zstd: Update to 1.4.5.

[Tobias Geerinckx-Rice via Guix-patches via]

[-- Attachment #1: Type: text/plain, Size: 973 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

[bug#43427] [PATCH] gnu: zstd: Update to 1.4.5.

[Greg Hogan]

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