[-- 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 --]
Hello Greg, The update is already present on core-updates branch, see: 386457b7bda963be9f0119a785b71bc64e0c105e. Thanks for the patch anyway. Mathieu
[-- 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 --]
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