Allow defining of uname value for reproducible builds

[jelly]

Extend configure.ac to accept PHP_UNAME as env variable to set the value of the
PHP_UNAME define in a reproducible manner. This allows distributions to set a
fixed value for php_uname and keep the default behaviour if PHP_UNAME is not
set.

Motivation: https://reproducible-builds.org/

[jelly]

It's currently not reproducible due to the recording of uname:

│ │  /* uname -a output */
│ │ -#define PHP_UNAME "Linux pierre 5.6.11-arch1-1 #1 SMP PREEMPT Wed, 06 May 2020 17:32:37 +0000 x86_64 GNU/Linux"                                                                                      
│ │ +#define PHP_UNAME "Linux php29646 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5+deb10u1 (2019-07-19) x86_64 GNU/Linux"                                                                                      

Also note that Debian carries this patch for a while which would become obsolete. https://salsa.debian.org/php-team/php/-/blob/master-7.2/debian/patches/0036-php-5.4.9-fixheader.patch

[Girgias]

I am no expert in build systems, but is this the only thing preventing from getting reproducible builds?
I would imagine that there are more things blocking the road to this.

Anyway I'm all for getting reproducible builds for php-src. :)

[jelly]

It's one of the last issues, another issue is phar.phar containing timestamps which should adhere to SOURCE_DATE_EPOCH. See this diff. https://tests.reproducible-builds.org/debian/rb-pkg/buster/amd64/diffoscope-results/php7.3.html

[Girgias]

It's one of the last issues, another issue is phar.phar containing timestamps which should adhere to SOURCE_DATE_EPOCH. See this diff. https://tests.reproducible-builds.org/debian/rb-pkg/buster/amd64/diffoscope-results/php7.3.html

Well that's somewhat good to hear that we're mostly there to get reproducible builds then. :)

[remicollet]

+1 as we also use the same patch in CentOS / Fedora / RHEL for years.