[PATCH] gnu: zstd: Update to 1.4.5.

  • Done
  • quality assurance status badge
Details
3 participants
  • Greg Hogan
  • Tobias Geerinckx-Rice
  • Mathieu Othacehe
Owner
unassigned
Submitted by
Greg Hogan
Severity
normal
G
G
Greg Hogan wrote on 15 Sep 2020 17:11
(address . guix-patches@gnu.org)
CA+3U0Zn02yBrPjLxbceKMbMpCe9YJ_Kf-bpR7swC44xcN3X3ZA@mail.gmail.com
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(-)

Toggle diff (41 lines)
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: file
M
M
Mathieu Othacehe wrote on 22 Sep 2020 11:08
(name . Greg Hogan)(address . code@greghogan.com)(address . 43427-done@debbugs.gnu.org)
87wo0myy9j.fsf@gnu.org
Hello Greg,

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

Thanks for the patch anyway.

Mathieu
Closed
T
T
Tobias Geerinckx-Rice wrote on 22 Sep 2020 11:59
Re: bug#43427: [PATCH] gnu: zstd: Update to 1.4.5.
(name . Greg Hogan)(address . code@greghogan.com)(address . 43427@debbugs.gnu.org)
87sgbaw2ri.fsf@nckx
Greg,

Mathieu Othacehe ???
Toggle quote (2 lines)
> 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
-----BEGIN PGP SIGNATURE-----

iIMEARYKACsWIQT12iAyS4c9C3o4dnINsP+IT1VteQUCX2nLAQ0cbWVAdG9iaWFz
LmdyAAoJEA2w/4hPVW157aUBAInRT8JXW99yTIVtnr7ZcJ30wQv6Pw2DIH1mqhxu
/NsuAP46vmZ/9+KTKMG0EcMxVvSczC1k1OWUY0GZW6ucH3TtBQ==
=Vhfo
-----END PGP SIGNATURE-----

G
G
Greg Hogan wrote on 22 Sep 2020 13:22
(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)(address . 43427@debbugs.gnu.org)
F4A7ABC2-7BFB-43DF-9C61-AA1102B2949B@greghogan.com
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

Toggle quote (22 lines)
> 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
?