On 12/12/17 at 02:12pm, Levi Morrison wrote: > On Mon, Dec 11, 2017 at 2:11 PM, Jelle van der Waa <je...@vdwaa.nl> wrote: > > Hi all, > > > > Debian, Arch Linux and other distro's are trying to get full > > reproducible builds. There are some issues in PHP's codebase which makes > > builds unreproducible. Reprodicuble builds are currently reproduced in > > Arch Linux by building PHP twice, and in two different env's, varying > > hostname, system time, etc. [1] > > > > Once issue is the PHP_BUILD_DATE, which makes the build > > non-reproducible. I've made a PR which uses SOURCE_DATE_EPOCH which is > > set in the reprodiculbe build env. This should keep the current > > functionality intact, while adding support for reproducible builds. [2] > > [3] > > It looks good to me. > > > Another issue is the php_uname functions which contains the > > hostname, since the hostname is varied per build this makes it > > non-reproducible. This is caused by the following line: > > > > configure.ac:PHP_UNAME=`uname -a | xargs` required in: > > ext/standard/info.c: php_uname = PHP_UNAME; > > > > Which is there as fallback as the php.net documentation describes: > > > > "On some older UNIX platforms, it may not be able to determine the > > current OS information in which case it will revert to displaying the OS > > PHP was built on. This will only happen if your uname() library call > > either doesn't exist or doesn't work.". > > > > I would argue that this is strange unexpected behaviour, and maybe it > > should throw an exception instead? Or can it show only "Linux" as > > fallback? basically PHP_OS. Ideas? > > I wouldn't throw an exception here. It seems PHP_OS is > under-documented; maybe PHP_OS_FAMILY is better:
PHP_OS and PHP_OS_FAMILY is a strange difference indeed. I'll have to do some further digging. > > > The operating system family PHP was built for. Either of 'Windows', 'BSD', > > 'Darwin', 'Solaris', 'Linux' or 'Unknown'. Available as of PHP 7.2.0. > > However, I really don't think we should change this for already > released PHP versions. We should our maintainers how they feel about > changing it in a x.y.NEXT patch. My inclination is to do this for PHP > 7.3 and beyond and accept that official PHP sources of earlier > versions will not produce reproducible builds. Indeed, as an Arch Linux developer I'm fine with these changes adding up in the next release and no backporting. > > The last issue is phar.phar being non-reproducible of which I am not > > sure what the issue would be. I'm not sure how the binary data in the > > phar.phar is generated. > > Phars are like `tars` that are also valid PHP files. This means there > are probably modification times, etc, set in there. Not sure what else > would need to be changed. Thanks for the information, I'll see if I can do some more digging. -- Jelle van der Waa -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
