* [PR PATCH] python3: fix lto build
@ 2024-03-08 16:38 Piraty
2024-03-08 16:39 ` [PR PATCH] [Updated] " Piraty
2024-03-08 18:20 ` [PR PATCH] [Merged]: " Piraty
0 siblings, 2 replies; 3+ messages in thread
From: Piraty @ 2024-03-08 16:38 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 1366 bytes --]
There is a new pull request by Piraty against master on the void-packages repository
https://github.com/Piraty/void-packages autoconf-fix-lto
https://github.com/void-linux/void-packages/pull/49194
python3: fix lto build
<!-- Uncomment relevant sections and delete options which are not applicable -->
#### Testing the changes
- I tested the changes in this PR: **YES**
<!--
#### New package
- This new package conforms to the [package requirements](https://github.com/void-linux/void-packages/blob/master/CONTRIBUTING.md#package-requirements): **YES**|**NO**
-->
<!-- Note: If the build is likely to take more than 2 hours, please add ci skip tag as described in
https://github.com/void-linux/void-packages/blob/master/CONTRIBUTING.md#continuous-integration
and test at least one native build and, if supported, at least one cross build.
Ignore this section if this PR is not skipping CI.
-->
<!--
#### Local build testing
- I built this PR locally for my native architecture, (ARCH-LIBC)
- I built this PR locally for these architectures (if supported. mark crossbuilds):
- aarch64-musl
- armv7l
- armv6l-musl
-->
`autoreconf` can be dropped once upstream generates configure from the not-yet-released autoconf-archive
ping @ahesford
A patch file from https://github.com/void-linux/void-packages/pull/49194.patch is attached
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: github-pr-autoconf-fix-lto-49194.patch --]
[-- Type: text/x-diff, Size: 8933 bytes --]
From 527159aa63c63d8573e7074eb0a3e547f05c54b4 Mon Sep 17 00:00:00 2001
From: Piraty <mail@piraty.dev>
Date: Fri, 8 Mar 2024 17:30:24 +0100
Subject: [PATCH 1/2] autoconf-archive: add upstream patch to fix building with
lto
fixes building python3 with -flto
checking whether float word ordering is bigendian... unknown
---
..._BIGENDIAN-Fix-bug-AX_C_FLOAT_WORDS_.patch | 138 ++++++++++++++++++
srcpkgs/autoconf-archive/template | 2 +-
2 files changed, 139 insertions(+), 1 deletion(-)
create mode 100644 srcpkgs/autoconf-archive/patches/0001-AX_C_FLOAT_WORDS_BIGENDIAN-Fix-bug-AX_C_FLOAT_WORDS_.patch
diff --git a/srcpkgs/autoconf-archive/patches/0001-AX_C_FLOAT_WORDS_BIGENDIAN-Fix-bug-AX_C_FLOAT_WORDS_.patch b/srcpkgs/autoconf-archive/patches/0001-AX_C_FLOAT_WORDS_BIGENDIAN-Fix-bug-AX_C_FLOAT_WORDS_.patch
new file mode 100644
index 00000000000000..6f39caefaf5897
--- /dev/null
+++ b/srcpkgs/autoconf-archive/patches/0001-AX_C_FLOAT_WORDS_BIGENDIAN-Fix-bug-AX_C_FLOAT_WORDS_.patch
@@ -0,0 +1,138 @@
+From 23be7ccd7f306fbc73b3f33e2f5ead716d120eef Mon Sep 17 00:00:00 2001
+From: Dan Amelang <dan@amelang.net>
+Date: Fri, 19 May 2023 14:13:37 -0700
+Subject: [PATCH] AX_C_FLOAT_WORDS_BIGENDIAN: Fix bug
+ "AX_C_FLOAT_WORDS_BIGENDIAN fails whenever interprocedural optimization is
+ enabled."
+
+Previous versions of this macro would not work when interprocedural
+optimization (via link-time optimization) was enabled. This would happen
+when, say, the GCC/clang "-flto" flag, or the ICC "-ipo" flag was used, for
+example. The problem was that under these conditions, the compiler did not
+allocate for and write the special float value in the data segment of the
+test object file. Thus, the special value (in platform-dependent binary form)
+could not be found, and the macro would fail.
+
+The solution to the above problem was to:
+
+ 1) Compile and link a whole test program rather than just compile an
+ object file.
+
+ 2) Add code that requires the compiler to write the special value to
+ the data segment of the program executable.
+
+For further details, refer to the documentation in the macro source file. Note
+that this change already increments the serial number of the file.
+
+This change resolves the following issues:
+
+CPython issue #89640
+ https://github.com/python/cpython/issues/89640
+
+Gentoo bug #700012
+ https://bugs.gentoo.org/700012
+
+Cairo issue #459
+ https://gitlab.freedesktop.org/cairo/cairo/-/issues/459
+
+Poky (Yocto Project) #12699
+ https://lists.yoctoproject.org/g/poky/topic/89131836
+---
+ m4/ax_c_float_words_bigendian.m4 | 61 ++++++++++++++++++++++++++++----
+ 1 file changed, 55 insertions(+), 6 deletions(-)
+
+diff --git a/m4/ax_c_float_words_bigendian.m4 b/m4/ax_c_float_words_bigendian.m4
+index 216b90d..5203684 100644
+--- a/m4/ax_c_float_words_bigendian.m4
++++ b/m4/ax_c_float_words_bigendian.m4
+@@ -27,32 +27,81 @@
+ # If neither value is found, the user is instructed to specify the
+ # ordering.
+ #
++# Early versions of this macro (i.e., before serial 12) would not work
++# when interprocedural optimization (via link-time optimization) was
++# enabled. This would happen when, say, the GCC/clang "-flto" flag, or the
++# ICC "-ipo" flag was used, for example. The problem was that under
++# these conditions, the compiler did not allocate for and write the special
++# float value in the data segment of the object file, since doing so might
++# not prove optimal once more context was available. Thus, the special value
++# (in platform-dependent binary form) could not be found in the object file,
++# and the macro would fail.
++#
++# The solution to the above problem was to:
++#
++# 1) Compile and link a whole test program rather than just compile an
++# object file. This ensures that we reach the point where even an
++# interprocedural optimizing compiler writes values to the data segment.
++#
++# 2) Add code that requires the compiler to write the special value to
++# the data segment, as opposed to "optimizing away" the variable's
++# allocation. This could be done via compiler keywords or options, but
++# it's tricky to make this work for all versions of all compilers with
++# all optimization settings. The chosen solution was to make the exit
++# code of the test program depend on the storing of the special value
++# in memory (in the data segment). Because the exit code can be
++# verified, any compiler that aspires to be correct will produce a
++# program binary that contains the value, which the macro can then find.
++#
++# How does the exit code depend on the special value residing in memory?
++# Memory, unlike variables and registers, can be addressed indirectly at run
++# time. The exit code of this test program is a result of indirectly reading
++# and writing to the memory region where the special value is supposed to
++# reside. The actual memory addresses used and the values to be written are
++# derived from the the program input ("argv") and are therefore not known at
++# compile or link time. The compiler has no choice but to defer the
++# computation to run time, and to prepare by allocating and populating the
++# data segment with the special value. For further details, refer to the
++# source code of the test program.
++#
++# Note that the test program is never meant to be run. It only exists to host
++# a double float value in a given platform's binary format. Thus, error
++# handling is not included.
++#
+ # LICENSE
+ #
+-# Copyright (c) 2008 Daniel Amelang <dan@amelang.net>
++# Copyright (c) 2008, 2023 Daniel Amelang <dan@amelang.net>
+ #
+ # Copying and distribution of this file, with or without modification, are
+ # permitted in any medium without royalty provided the copyright notice
+ # and this notice are preserved. This file is offered as-is, without any
+ # warranty.
+
+-#serial 11
++#serial 12
+
+ AC_DEFUN([AX_C_FLOAT_WORDS_BIGENDIAN],
+ [AC_CACHE_CHECK(whether float word ordering is bigendian,
+ ax_cv_c_float_words_bigendian, [
+
+ ax_cv_c_float_words_bigendian=unknown
+-AC_COMPILE_IFELSE([AC_LANG_SOURCE([[
++AC_LINK_IFELSE([AC_LANG_SOURCE([[
+
+-double d = 90904234967036810337470478905505011476211692735615632014797120844053488865816695273723469097858056257517020191247487429516932130503560650002327564517570778480236724525140520121371739201496540132640109977779420565776568942592.0;
++#include <stdlib.h>
++
++static double m[] = {9.090423496703681e+223, 0.0};
++
++int main (int argc, char *argv[])
++{
++ m[atoi (argv[1])] += atof (argv[2]);
++ return m[atoi (argv[3])] > 0.0;
++}
+
+ ]])], [
+
+-if grep noonsees conftest.$ac_objext >/dev/null ; then
++if grep noonsees conftest$EXEEXT >/dev/null ; then
+ ax_cv_c_float_words_bigendian=yes
+ fi
+-if grep seesnoon conftest.$ac_objext >/dev/null ; then
++if grep seesnoon conftest$EXEEXT >/dev/null ; then
+ if test "$ax_cv_c_float_words_bigendian" = unknown; then
+ ax_cv_c_float_words_bigendian=no
+ else
+--
+2.44.0
+
diff --git a/srcpkgs/autoconf-archive/template b/srcpkgs/autoconf-archive/template
index 7229da59a8e7e2..68a71b00a4d83e 100644
--- a/srcpkgs/autoconf-archive/template
+++ b/srcpkgs/autoconf-archive/template
@@ -1,7 +1,7 @@
# Template file for 'autoconf-archive'
pkgname=autoconf-archive
version=2023.02.20
-revision=1
+revision=2
build_style=gnu-configure
hostmakedepends="texinfo"
depends="autoconf"
From 84a46dd35182119878f99a0749cdeed030b76502 Mon Sep 17 00:00:00 2001
From: Piraty <mail@piraty.dev>
Date: Fri, 8 Mar 2024 17:32:55 +0100
Subject: [PATCH 2/2] python3: use patched autoconf-archive to fix lto build
https://github.com/python/cpython/issues/89640
no revbump as Void's default build configuration is not affected
---
srcpkgs/python3/template | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/srcpkgs/python3/template b/srcpkgs/python3/template
index d3342dda925a8c..48bcc646077ed2 100644
--- a/srcpkgs/python3/template
+++ b/srcpkgs/python3/template
@@ -11,7 +11,7 @@ configure_args="--enable-shared --enable-ipv6 --enable-optimizations
--with-dbmliborder=gdbm:ndbm --with-system-expat --with-system-ffi
--without-ensurepip ac_cv_working_tzset=yes"
pycompile_dirs="usr/lib/python${version%.*}"
-hostmakedepends="pkgconf"
+hostmakedepends="pkgconf autoconf-archive automake"
makedepends="libffi-devel readline-devel gdbm-devel openssl-devel
expat-devel sqlite-devel bzip2-devel zlib-devel liblzma-devel"
depends="ca-certificates"
@@ -64,6 +64,11 @@ post_patch() {
fi
}
+# https://github.com/python/cpython/issues/89640
+pre_configure() {
+ autoreconf -vfi
+}
+
do_configure() {
# If these are set, distutils will default to cc and attempt to pass
# `-R<path>` to the compiler for every compiled extension that sets an
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PR PATCH] [Updated] python3: fix lto build
2024-03-08 16:38 [PR PATCH] python3: fix lto build Piraty
@ 2024-03-08 16:39 ` Piraty
2024-03-08 18:20 ` [PR PATCH] [Merged]: " Piraty
1 sibling, 0 replies; 3+ messages in thread
From: Piraty @ 2024-03-08 16:39 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 1371 bytes --]
There is an updated pull request by Piraty against master on the void-packages repository
https://github.com/Piraty/void-packages autoconf-fix-lto
https://github.com/void-linux/void-packages/pull/49194
python3: fix lto build
<!-- Uncomment relevant sections and delete options which are not applicable -->
#### Testing the changes
- I tested the changes in this PR: **YES**
<!--
#### New package
- This new package conforms to the [package requirements](https://github.com/void-linux/void-packages/blob/master/CONTRIBUTING.md#package-requirements): **YES**|**NO**
-->
<!-- Note: If the build is likely to take more than 2 hours, please add ci skip tag as described in
https://github.com/void-linux/void-packages/blob/master/CONTRIBUTING.md#continuous-integration
and test at least one native build and, if supported, at least one cross build.
Ignore this section if this PR is not skipping CI.
-->
<!--
#### Local build testing
- I built this PR locally for my native architecture, (ARCH-LIBC)
- I built this PR locally for these architectures (if supported. mark crossbuilds):
- aarch64-musl
- armv7l
- armv6l-musl
-->
`autoreconf` can be dropped once upstream generates configure from the not-yet-released autoconf-archive
ping @ahesford
A patch file from https://github.com/void-linux/void-packages/pull/49194.patch is attached
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: github-pr-autoconf-fix-lto-49194.patch --]
[-- Type: text/x-diff, Size: 8885 bytes --]
From 527159aa63c63d8573e7074eb0a3e547f05c54b4 Mon Sep 17 00:00:00 2001
From: Piraty <mail@piraty.dev>
Date: Fri, 8 Mar 2024 17:30:24 +0100
Subject: [PATCH 1/2] autoconf-archive: add upstream patch to fix building with
lto
fixes building python3 with -flto
checking whether float word ordering is bigendian... unknown
---
..._BIGENDIAN-Fix-bug-AX_C_FLOAT_WORDS_.patch | 138 ++++++++++++++++++
srcpkgs/autoconf-archive/template | 2 +-
2 files changed, 139 insertions(+), 1 deletion(-)
create mode 100644 srcpkgs/autoconf-archive/patches/0001-AX_C_FLOAT_WORDS_BIGENDIAN-Fix-bug-AX_C_FLOAT_WORDS_.patch
diff --git a/srcpkgs/autoconf-archive/patches/0001-AX_C_FLOAT_WORDS_BIGENDIAN-Fix-bug-AX_C_FLOAT_WORDS_.patch b/srcpkgs/autoconf-archive/patches/0001-AX_C_FLOAT_WORDS_BIGENDIAN-Fix-bug-AX_C_FLOAT_WORDS_.patch
new file mode 100644
index 00000000000000..6f39caefaf5897
--- /dev/null
+++ b/srcpkgs/autoconf-archive/patches/0001-AX_C_FLOAT_WORDS_BIGENDIAN-Fix-bug-AX_C_FLOAT_WORDS_.patch
@@ -0,0 +1,138 @@
+From 23be7ccd7f306fbc73b3f33e2f5ead716d120eef Mon Sep 17 00:00:00 2001
+From: Dan Amelang <dan@amelang.net>
+Date: Fri, 19 May 2023 14:13:37 -0700
+Subject: [PATCH] AX_C_FLOAT_WORDS_BIGENDIAN: Fix bug
+ "AX_C_FLOAT_WORDS_BIGENDIAN fails whenever interprocedural optimization is
+ enabled."
+
+Previous versions of this macro would not work when interprocedural
+optimization (via link-time optimization) was enabled. This would happen
+when, say, the GCC/clang "-flto" flag, or the ICC "-ipo" flag was used, for
+example. The problem was that under these conditions, the compiler did not
+allocate for and write the special float value in the data segment of the
+test object file. Thus, the special value (in platform-dependent binary form)
+could not be found, and the macro would fail.
+
+The solution to the above problem was to:
+
+ 1) Compile and link a whole test program rather than just compile an
+ object file.
+
+ 2) Add code that requires the compiler to write the special value to
+ the data segment of the program executable.
+
+For further details, refer to the documentation in the macro source file. Note
+that this change already increments the serial number of the file.
+
+This change resolves the following issues:
+
+CPython issue #89640
+ https://github.com/python/cpython/issues/89640
+
+Gentoo bug #700012
+ https://bugs.gentoo.org/700012
+
+Cairo issue #459
+ https://gitlab.freedesktop.org/cairo/cairo/-/issues/459
+
+Poky (Yocto Project) #12699
+ https://lists.yoctoproject.org/g/poky/topic/89131836
+---
+ m4/ax_c_float_words_bigendian.m4 | 61 ++++++++++++++++++++++++++++----
+ 1 file changed, 55 insertions(+), 6 deletions(-)
+
+diff --git a/m4/ax_c_float_words_bigendian.m4 b/m4/ax_c_float_words_bigendian.m4
+index 216b90d..5203684 100644
+--- a/m4/ax_c_float_words_bigendian.m4
++++ b/m4/ax_c_float_words_bigendian.m4
+@@ -27,32 +27,81 @@
+ # If neither value is found, the user is instructed to specify the
+ # ordering.
+ #
++# Early versions of this macro (i.e., before serial 12) would not work
++# when interprocedural optimization (via link-time optimization) was
++# enabled. This would happen when, say, the GCC/clang "-flto" flag, or the
++# ICC "-ipo" flag was used, for example. The problem was that under
++# these conditions, the compiler did not allocate for and write the special
++# float value in the data segment of the object file, since doing so might
++# not prove optimal once more context was available. Thus, the special value
++# (in platform-dependent binary form) could not be found in the object file,
++# and the macro would fail.
++#
++# The solution to the above problem was to:
++#
++# 1) Compile and link a whole test program rather than just compile an
++# object file. This ensures that we reach the point where even an
++# interprocedural optimizing compiler writes values to the data segment.
++#
++# 2) Add code that requires the compiler to write the special value to
++# the data segment, as opposed to "optimizing away" the variable's
++# allocation. This could be done via compiler keywords or options, but
++# it's tricky to make this work for all versions of all compilers with
++# all optimization settings. The chosen solution was to make the exit
++# code of the test program depend on the storing of the special value
++# in memory (in the data segment). Because the exit code can be
++# verified, any compiler that aspires to be correct will produce a
++# program binary that contains the value, which the macro can then find.
++#
++# How does the exit code depend on the special value residing in memory?
++# Memory, unlike variables and registers, can be addressed indirectly at run
++# time. The exit code of this test program is a result of indirectly reading
++# and writing to the memory region where the special value is supposed to
++# reside. The actual memory addresses used and the values to be written are
++# derived from the the program input ("argv") and are therefore not known at
++# compile or link time. The compiler has no choice but to defer the
++# computation to run time, and to prepare by allocating and populating the
++# data segment with the special value. For further details, refer to the
++# source code of the test program.
++#
++# Note that the test program is never meant to be run. It only exists to host
++# a double float value in a given platform's binary format. Thus, error
++# handling is not included.
++#
+ # LICENSE
+ #
+-# Copyright (c) 2008 Daniel Amelang <dan@amelang.net>
++# Copyright (c) 2008, 2023 Daniel Amelang <dan@amelang.net>
+ #
+ # Copying and distribution of this file, with or without modification, are
+ # permitted in any medium without royalty provided the copyright notice
+ # and this notice are preserved. This file is offered as-is, without any
+ # warranty.
+
+-#serial 11
++#serial 12
+
+ AC_DEFUN([AX_C_FLOAT_WORDS_BIGENDIAN],
+ [AC_CACHE_CHECK(whether float word ordering is bigendian,
+ ax_cv_c_float_words_bigendian, [
+
+ ax_cv_c_float_words_bigendian=unknown
+-AC_COMPILE_IFELSE([AC_LANG_SOURCE([[
++AC_LINK_IFELSE([AC_LANG_SOURCE([[
+
+-double d = 90904234967036810337470478905505011476211692735615632014797120844053488865816695273723469097858056257517020191247487429516932130503560650002327564517570778480236724525140520121371739201496540132640109977779420565776568942592.0;
++#include <stdlib.h>
++
++static double m[] = {9.090423496703681e+223, 0.0};
++
++int main (int argc, char *argv[])
++{
++ m[atoi (argv[1])] += atof (argv[2]);
++ return m[atoi (argv[3])] > 0.0;
++}
+
+ ]])], [
+
+-if grep noonsees conftest.$ac_objext >/dev/null ; then
++if grep noonsees conftest$EXEEXT >/dev/null ; then
+ ax_cv_c_float_words_bigendian=yes
+ fi
+-if grep seesnoon conftest.$ac_objext >/dev/null ; then
++if grep seesnoon conftest$EXEEXT >/dev/null ; then
+ if test "$ax_cv_c_float_words_bigendian" = unknown; then
+ ax_cv_c_float_words_bigendian=no
+ else
+--
+2.44.0
+
diff --git a/srcpkgs/autoconf-archive/template b/srcpkgs/autoconf-archive/template
index 7229da59a8e7e2..68a71b00a4d83e 100644
--- a/srcpkgs/autoconf-archive/template
+++ b/srcpkgs/autoconf-archive/template
@@ -1,7 +1,7 @@
# Template file for 'autoconf-archive'
pkgname=autoconf-archive
version=2023.02.20
-revision=1
+revision=2
build_style=gnu-configure
hostmakedepends="texinfo"
depends="autoconf"
From 52d032413130a40a6f5292b0355022df0d210111 Mon Sep 17 00:00:00 2001
From: Piraty <mail@piraty.dev>
Date: Fri, 8 Mar 2024 17:32:55 +0100
Subject: [PATCH 2/2] python3: use patched autoconf-archive to fix lto build
no revbump as Void's default build configuration is not affected
---
srcpkgs/python3/template | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/srcpkgs/python3/template b/srcpkgs/python3/template
index d3342dda925a8c..48bcc646077ed2 100644
--- a/srcpkgs/python3/template
+++ b/srcpkgs/python3/template
@@ -11,7 +11,7 @@ configure_args="--enable-shared --enable-ipv6 --enable-optimizations
--with-dbmliborder=gdbm:ndbm --with-system-expat --with-system-ffi
--without-ensurepip ac_cv_working_tzset=yes"
pycompile_dirs="usr/lib/python${version%.*}"
-hostmakedepends="pkgconf"
+hostmakedepends="pkgconf autoconf-archive automake"
makedepends="libffi-devel readline-devel gdbm-devel openssl-devel
expat-devel sqlite-devel bzip2-devel zlib-devel liblzma-devel"
depends="ca-certificates"
@@ -64,6 +64,11 @@ post_patch() {
fi
}
+# https://github.com/python/cpython/issues/89640
+pre_configure() {
+ autoreconf -vfi
+}
+
do_configure() {
# If these are set, distutils will default to cc and attempt to pass
# `-R<path>` to the compiler for every compiled extension that sets an
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PR PATCH] [Merged]: python3: fix lto build
2024-03-08 16:38 [PR PATCH] python3: fix lto build Piraty
2024-03-08 16:39 ` [PR PATCH] [Updated] " Piraty
@ 2024-03-08 18:20 ` Piraty
1 sibling, 0 replies; 3+ messages in thread
From: Piraty @ 2024-03-08 18:20 UTC (permalink / raw)
To: ml
[-- Attachment #1: Type: text/plain, Size: 1208 bytes --]
There's a merged pull request on the void-packages repository
python3: fix lto build
https://github.com/void-linux/void-packages/pull/49194
Description:
<!-- Uncomment relevant sections and delete options which are not applicable -->
#### Testing the changes
- I tested the changes in this PR: **YES**
<!--
#### New package
- This new package conforms to the [package requirements](https://github.com/void-linux/void-packages/blob/master/CONTRIBUTING.md#package-requirements): **YES**|**NO**
-->
<!-- Note: If the build is likely to take more than 2 hours, please add ci skip tag as described in
https://github.com/void-linux/void-packages/blob/master/CONTRIBUTING.md#continuous-integration
and test at least one native build and, if supported, at least one cross build.
Ignore this section if this PR is not skipping CI.
-->
<!--
#### Local build testing
- I built this PR locally for my native architecture, (ARCH-LIBC)
- I built this PR locally for these architectures (if supported. mark crossbuilds):
- aarch64-musl
- armv7l
- armv6l-musl
-->
`autoreconf` can be dropped once upstream generates configure from the not-yet-released autoconf-archive
ping @ahesford
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2024-03-08 18:20 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-03-08 16:38 [PR PATCH] python3: fix lto build Piraty
2024-03-08 16:39 ` [PR PATCH] [Updated] " Piraty
2024-03-08 18:20 ` [PR PATCH] [Merged]: " Piraty
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).