[PR PATCH] gperftools: refresh patches

[PR PATCH] gperftools: refresh patches

[chexum]

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

There is a new pull request by chexum against master on the void-packages repository

https://github.com/chexum/void-packages gperftools
https://github.com/void-linux/void-packages/pull/37816

gperftools: refresh patches
Package no longer builds with the patch whitespace changes.

The patches which had any looseness have been regenerated
to ensure clean build.

Let me note that there are new recent versions.  As I can't
test most of those releases on the rest of Void architectures,
I'd rather have a clean build of the current state.

<!-- Uncomment relevant sections and delete options which are not applicable -->

#### Testing the changes
- I tested the changes in this PR: **briefly**

#### Local build testing
- I built this PR locally for my native architecture, (x86_64-glibc)
- no code changes are expected, just to make sure the patches
  apply cleanly with stricter options

A patch file from https://github.com/void-linux/void-packages/pull/37816.patch is attached

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: github-pr-gperftools-37816.patch --]
[-- Type: text/x-diff, Size: 6194 bytes --]

From 79c7e84f524a92a5509f7fdb670e478c41d89aa0 Mon Sep 17 00:00:00 2001
From: J Farkas <chexum+git@gmail.com>
Date: Sun, 3 Jul 2022 14:54:17 +0000
Subject: [PATCH] gperftools: refresh patches

Package no longer builds with the patch whitespace changes.

The patches which had any looseness have been regenerated
to ensure clean build.

Let me note that there are new recent versions.  As I can't
test most of those releases on the rest of Void architectures,
I'd rather have a clean build of the current state.
---
 srcpkgs/gperftools/patches/armv6.patch        | 12 ++++-----
 .../patches/elf-mem-image-musl.patch          |  5 ++--
 srcpkgs/gperftools/patches/ppc-musl.patch     | 27 ++++++++++---------
 3 files changed, 24 insertions(+), 20 deletions(-)

diff --git a/srcpkgs/gperftools/patches/armv6.patch b/srcpkgs/gperftools/patches/armv6.patch
index ef3fa9181872..1471c0351a0c 100644
--- a/srcpkgs/gperftools/patches/armv6.patch
+++ b/srcpkgs/gperftools/patches/armv6.patch
@@ -1,9 +1,9 @@
-diff -urN src/base/atomicops.h src/base/atomicops.h
---- a/src/base/atomicops.h	2013-07-30 03:12:11.000000000 -0600
-+++ b/src/base/atomicops.h	2013-08-22 16:40:55.204885730 -0600
-@@ -101,7 +101,7 @@
- // TODO(csilvers): match piii, not just __i386.  Also, match k8
- #if defined(__MACH__) && defined(__APPLE__)
+diff -urpN gperftools-2.8/src/base/atomicops.h gperftools-2.8/src/base/atomicops.h
+--- gperftools-2.8/src/base/atomicops.h	2020-02-10 06:17:29.000000000 +0000
++++ gperftools-2.8/src/base/atomicops.h	2022-07-03 07:50:52.287409612 +0000
+@@ -112,7 +112,7 @@
+ #include "base/atomicops-internals-gcc.h"
+ #elif defined(__MACH__) && defined(__APPLE__)
  #include "base/atomicops-internals-macosx.h"
 -#elif defined(__GNUC__) && defined(ARMV6)
 +#elif defined(__GNUC__) && defined(ARMV7)
diff --git a/srcpkgs/gperftools/patches/elf-mem-image-musl.patch b/srcpkgs/gperftools/patches/elf-mem-image-musl.patch
index dba8b3d9ea74..e1e137ac7a38 100644
--- a/srcpkgs/gperftools/patches/elf-mem-image-musl.patch
+++ b/srcpkgs/gperftools/patches/elf-mem-image-musl.patch
@@ -1,7 +1,8 @@
 This relies on link.h, which is present in musl as well as glibc.
 
---- a/src/base/elf_mem_image.h
-+++ b/src/base/elf_mem_image.h
+diff -urpN gperftools-2.8/src/base/elf_mem_image.h gperftools-2.8/src/base/elf_mem_image.h
+--- gperftools-2.8/src/base/elf_mem_image.h	2020-02-10 06:17:15.000000000 +0000
++++ gperftools-2.8/src/base/elf_mem_image.h	2022-07-03 07:52:35.619310086 +0000
 @@ -43,7 +43,7 @@
  
  // Maybe one day we can rewrite this file not to require the elf
diff --git a/srcpkgs/gperftools/patches/ppc-musl.patch b/srcpkgs/gperftools/patches/ppc-musl.patch
index bbeb4cd39312..1be5855da256 100644
--- a/srcpkgs/gperftools/patches/ppc-musl.patch
+++ b/srcpkgs/gperftools/patches/ppc-musl.patch
@@ -1,26 +1,27 @@
 Compatibility fixes for musl.
 
---- a/m4/pc_from_ucontext.m4
-+++ b/m4/pc_from_ucontext.m4
-@@ -31,6 +31,7 @@ AC_DEFUN([AC_PC_FROM_UCONTEXT],
+diff -urpN gperftools-2.8/m4/pc_from_ucontext.m4 gperftools-2.8/m4/pc_from_ucontext.m4
+--- gperftools-2.8/m4/pc_from_ucontext.m4	2020-02-23 20:15:47.000000000 +0000
++++ gperftools-2.8/m4/pc_from_ucontext.m4	2022-07-03 07:51:47.779893192 +0000
+@@ -32,6 +32,7 @@ AC_DEFUN([AC_PC_FROM_UCONTEXT],
     pc_fields="$pc_fields uc_mcontext.gregs[[R15]]"     # Linux (arm old [untested])
     pc_fields="$pc_fields uc_mcontext.arm_pc"           # Linux (arm arch 5)
     pc_fields="$pc_fields uc_mcontext.gp_regs[[PT_NIP]]"  # Suse SLES 11 (ppc64)
 +   pc_fields="$pc_fields uc_mcontext.gregs[[PT_NIP]]"
     pc_fields="$pc_fields uc_mcontext.mc_eip"           # FreeBSD (i386)
+    pc_fields="$pc_fields uc_mcontext.mc_srr0"          # FreeBSD (powerpc, powerpc64)
     pc_fields="$pc_fields uc_mcontext.mc_rip"           # FreeBSD (x86_64 [untested])
-    pc_fields="$pc_fields uc_mcontext.__gregs[[_REG_EIP]]"  # NetBSD (i386)
-@@ -55,7 +56,8 @@ AC_DEFUN([AC_PC_FROM_UCONTEXT],
+@@ -66,7 +67,8 @@ AC_DEFUN([AC_PC_FROM_UCONTEXT],
                          pc_field_found=true)
         elif test "x$ac_cv_header_sys_ucontext_h" = xyes; then
           AC_TRY_COMPILE([#define _GNU_SOURCE 1
--                         #include <sys/ucontext.h>],
+-                        #include <sys/ucontext.h>],
 +                         #include <sys/ucontext.h>
 +                         #include <asm/ptrace.h>],
                          [ucontext_t u; return u.$pc_field == 0;],
                          AC_DEFINE_UNQUOTED(PC_FROM_UCONTEXT, $pc_field,
                                             How to access the PC from a struct ucontext)
-@@ -63,7 +65,8 @@ AC_DEFUN([AC_PC_FROM_UCONTEXT],
+@@ -74,7 +76,8 @@ AC_DEFUN([AC_PC_FROM_UCONTEXT],
                          pc_field_found=true)
         elif test "x$ac_cv_header_ucontext_h" = xyes; then
           AC_TRY_COMPILE([#define _GNU_SOURCE 1
@@ -30,9 +31,10 @@ Compatibility fixes for musl.
                          [ucontext_t u; return u.$pc_field == 0;],
                          AC_DEFINE_UNQUOTED(PC_FROM_UCONTEXT, $pc_field,
                                             How to access the PC from a struct ucontext)
---- a/src/getpc.h
-+++ b/src/getpc.h
-@@ -65,6 +65,9 @@
+diff -urpN gperftools-2.8/src/getpc.h gperftools-2.8/src/getpc.h
+--- gperftools-2.8/src/getpc.h	2020-02-23 20:15:47.000000000 +0000
++++ gperftools-2.8/src/getpc.h	2022-07-03 07:51:47.780893201 +0000
+@@ -68,6 +68,9 @@
  typedef ucontext ucontext_t;
  #endif
  
@@ -42,8 +44,9 @@ Compatibility fixes for musl.
  
  // Take the example where function Foo() calls function Bar().  For
  // many architectures, Bar() is responsible for setting up and tearing
---- a/src/stacktrace_powerpc-linux-inl.h
-+++ b/src/stacktrace_powerpc-linux-inl.h
+diff -urpN gperftools-2.8/src/stacktrace_powerpc-linux-inl.h gperftools-2.8/src/stacktrace_powerpc-linux-inl.h
+--- gperftools-2.8/src/stacktrace_powerpc-linux-inl.h	2020-02-10 06:49:04.000000000 +0000
++++ gperftools-2.8/src/stacktrace_powerpc-linux-inl.h	2022-07-03 07:51:47.780893201 +0000
 @@ -186,7 +186,7 @@ static int GET_STACK_TRACE_OR_FRAMES {
            ucontext_t uc;
          // We don't care about the rest, since the IP value is at 'uc' field.

Re: gperftools: refresh patches

[paper42]

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

New comment by paper42 on void-packages repository

https://github.com/void-linux/void-packages/pull/37816#issuecomment-1173141187

Comment:
Please drop the patch refreshes as they don't affect "cleanness" of the build and only fix the whitespace.

Re: gperftools: refresh patches

[chexum]

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

New comment by chexum on void-packages repository

https://github.com/void-linux/void-packages/pull/37816#issuecomment-1173142095

Comment:
The inability to rebuild a package does affect me when I'm trying to recompile parts of Void for reproducibility (and/or local testing/hosting), and I believe it's useful to have a current set of buildable and re-buildable distribution for testing infrastructure like toolchain upgrades.

Otherwise, understood.

Re: gperftools: refresh patches

[paper42]

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

New comment by paper42 on void-packages repository

https://github.com/void-linux/void-packages/pull/37816#issuecomment-1173143882

Comment:
> The inability to rebuild a package does affect me when I'm trying to recompile parts of Void for reproducibility (and/or local testing/hosting), and I believe it's useful to have a current set of buildable and re-buildable distribution for testing infrastructure like toolchain upgrades.

Definitely, but if the patches are off by a few lines (like here), the packages will still be build-able. The reason why this package didn't build for you was the whitespace issue that was triggered by us disabling loose whitespace matching in patch (we now use `patch` without `-l`).

Try applying this minimal patch and the package will build fine without the rest of the changes.

```patch
diff --git a/srcpkgs/gperftools/patches/ppc-musl.patch b/srcpkgs/gperftools/patches/ppc-musl.patch
index bbeb4cd393..d192ea6127 100644
--- a/srcpkgs/gperftools/patches/ppc-musl.patch
+++ b/srcpkgs/gperftools/patches/ppc-musl.patch
@@ -14,7 +14,7 @@ Compatibility fixes for musl.
                          pc_field_found=true)
         elif test "x$ac_cv_header_sys_ucontext_h" = xyes; then
           AC_TRY_COMPILE([#define _GNU_SOURCE 1
--                         #include <sys/ucontext.h>],
+-                        #include <sys/ucontext.h>],
 +                         #include <sys/ucontext.h>
 +                         #include <asm/ptrace.h>],
                          [ucontext_t u; return u.$pc_field == 0;],
```

Re: gperftools: refresh patches

[chexum]

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

New comment by chexum on void-packages repository

https://github.com/void-linux/void-packages/pull/37816#issuecomment-1173145718

Comment:
What I've attempted here is to make sure that the content (including line numbers) matches the original source, so that perhaps(!) it could survive more source upgrades in a safer way.  I specifically excluded the fourth patch, as it still applied cleanly with no line numbering issues.   It looks the current patches were for different versions originally - IMHO more lax patches have the danger of matching the wrong line and result in hard-to-trace issues.

Perhaps some method to revert to the original patch white-space behaviour could be nicer to avoid retouching old templates?

But I'm glad that templates are expected to be able to (re)build any arbitrary package if the binary package is lost, that means so much for reproducibility (even if not for the bit-for-bit meaning).

Re: gperftools: refresh patches

[paper42]

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

New comment by paper42 on void-packages repository

https://github.com/void-linux/void-packages/pull/37816#issuecomment-1173147347

Comment:
> Perhaps some method to revert to the original patch white-space behaviour could be nicer to avoid retouching old templates?

No, lax whitespace matching should have been always turned off, imo it was a mistake that we had it on, we can easily fix the patches.

> What I've attempted here is to make sure that the content (including line numbers) matches the original source, so that perhaps(!) it could survive more source upgrades in a safer way. I specifically excluded the fourth patch, as it still applied cleanly with no line numbering issues. It looks the current patches were for different versions originally - IMHO more lax patches have the danger of matching the wrong line and result in hard-to-trace issues.

In practice I have never seen this happen.

Re: [PR PATCH] [Updated] gperftools: refresh patches

[chexum]

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

There is an updated pull request by chexum against master on the void-packages repository

https://github.com/chexum/void-packages gperftools
https://github.com/void-linux/void-packages/pull/37816

gperftools: refresh patches
Package no longer builds with the patch whitespace changes.

The patches which had any looseness have been regenerated
to ensure clean build.

Let me note that there are new recent versions.  As I can't
test most of those releases on the rest of Void architectures,
I'd rather have a clean build of the current state.

<!-- Uncomment relevant sections and delete options which are not applicable -->

#### Testing the changes
- I tested the changes in this PR: **briefly**

#### Local build testing
- I built this PR locally for my native architecture, (x86_64-glibc)
- no code changes are expected, just to make sure the patches
  apply cleanly with stricter options

A patch file from https://github.com/void-linux/void-packages/pull/37816.patch is attached

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: github-pr-gperftools-37816.patch --]
[-- Type: text/x-diff, Size: 1042 bytes --]

From 0296176ea44528570d2ea099144f43380576f031 Mon Sep 17 00:00:00 2001
From: J Farkas <chexum+git@gmail.com>
Date: Sun, 3 Jul 2022 18:20:49 +0000
Subject: [PATCH] gperftools: tweak patch whitespace to build again

---
 srcpkgs/gperftools/patches/ppc-musl.patch | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/srcpkgs/gperftools/patches/ppc-musl.patch b/srcpkgs/gperftools/patches/ppc-musl.patch
index bbeb4cd39312..d192ea612797 100644
--- a/srcpkgs/gperftools/patches/ppc-musl.patch
+++ b/srcpkgs/gperftools/patches/ppc-musl.patch
@@ -14,7 +14,7 @@ Compatibility fixes for musl.
                          pc_field_found=true)
         elif test "x$ac_cv_header_sys_ucontext_h" = xyes; then
           AC_TRY_COMPILE([#define _GNU_SOURCE 1
--                         #include <sys/ucontext.h>],
+-                        #include <sys/ucontext.h>],
 +                         #include <sys/ucontext.h>
 +                         #include <asm/ptrace.h>],
                          [ucontext_t u; return u.$pc_field == 0;],

Re: gperftools: refresh patches

[chexum]

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

New comment by chexum on void-packages repository

https://github.com/void-linux/void-packages/pull/37816#issuecomment-1173149509

Comment:
> In practice I have never seen this happen.

Fair enough - now that I think about it, it could just as well happen with updated patches.

I pushed a minimized change for the patch to build gperftools as you suggested (in case you want to use it).

Re: [PR PATCH] [Updated] gperftools: refresh patches

[paper42]

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

There is an updated pull request by paper42 against master on the void-packages repository

https://github.com/chexum/void-packages gperftools
https://github.com/void-linux/void-packages/pull/37816

gperftools: refresh patches
Package no longer builds with the patch whitespace changes.

The patches which had any looseness have been regenerated
to ensure clean build.

Let me note that there are new recent versions.  As I can't
test most of those releases on the rest of Void architectures,
I'd rather have a clean build of the current state.

<!-- Uncomment relevant sections and delete options which are not applicable -->

#### Testing the changes
- I tested the changes in this PR: **briefly**

#### Local build testing
- I built this PR locally for my native architecture, (x86_64-glibc)
- no code changes are expected, just to make sure the patches
  apply cleanly with stricter options

A patch file from https://github.com/void-linux/void-packages/pull/37816.patch is attached

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: github-pr-gperftools-37816.patch --]
[-- Type: text/x-diff, Size: 1025 bytes --]

From 6c1192cbf166698932030c2e3de71db1885a572d Mon Sep 17 00:00:00 2001
From: J Farkas <chexum+git@gmail.com>
Date: Sun, 3 Jul 2022 18:20:49 +0000
Subject: [PATCH] gperftools: fix patch whitespace

---
 srcpkgs/gperftools/patches/ppc-musl.patch | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/srcpkgs/gperftools/patches/ppc-musl.patch b/srcpkgs/gperftools/patches/ppc-musl.patch
index bbeb4cd39312..d192ea612797 100644
--- a/srcpkgs/gperftools/patches/ppc-musl.patch
+++ b/srcpkgs/gperftools/patches/ppc-musl.patch
@@ -14,7 +14,7 @@ Compatibility fixes for musl.
                          pc_field_found=true)
         elif test "x$ac_cv_header_sys_ucontext_h" = xyes; then
           AC_TRY_COMPILE([#define _GNU_SOURCE 1
--                         #include <sys/ucontext.h>],
+-                        #include <sys/ucontext.h>],
 +                         #include <sys/ucontext.h>
 +                         #include <asm/ptrace.h>],
                          [ucontext_t u; return u.$pc_field == 0;],

Re: [PR PATCH] [Merged]: gperftools: refresh patches

[paper42]

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

There's a merged pull request on the void-packages repository

gperftools: refresh patches
https://github.com/void-linux/void-packages/pull/37816

Description:
Package no longer builds with the patch whitespace changes.

The patches which had any looseness have been regenerated
to ensure clean build.

Let me note that there are new recent versions.  As I can't
test most of those releases on the rest of Void architectures,
I'd rather have a clean build of the current state.

<!-- Uncomment relevant sections and delete options which are not applicable -->

#### Testing the changes
- I tested the changes in this PR: **briefly**

#### Local build testing
- I built this PR locally for my native architecture, (x86_64-glibc)
- no code changes are expected, just to make sure the patches
  apply cleanly with stricter options