Re: [PATCH 0/2] use AM_TESTS_ENVIRONMENT Automake variable

2016-07-11 Thread Mathieu Lirzin
Paul Eggert writes: > On 07/11/2016 02:42 PM, Eric Blake wrote: >> RHEL/CentOS 6 is still a common development target, and I strongly feel >> that we should continue to support it out of the box. RHEL 5 is >> starting to fade, though, so we may finally be able to bump to something >> newer than

Re: [PATCH 0/2] use AM_TESTS_ENVIRONMENT Automake variable

2016-07-11 Thread Paul Eggert
On 07/11/2016 02:42 PM, Eric Blake wrote: RHEL/CentOS 6 is still a common development target, and I strongly feel that we should continue to support it out of the box. RHEL 5 is starting to fade, though, so we may finally be able to bump to something newer than autoconf 2.59 and automake 1.9.6.

Re: [PATCH 0/2] use AM_TESTS_ENVIRONMENT Automake variable

2016-07-11 Thread Eric Blake
On 07/11/2016 04:25 AM, Mathieu Lirzin wrote: > Karl Berry writes: > >> RHEL 7 >> >> Vast numbers of people run RHEL/CentOS/whatever < 7. > > Relying on these stable distributions generally means not wanting to > mess with unstable development versions. Requiring a newer Automake > version

Re: ‘mktime’ replacement on glibc systems

2016-07-11 Thread Ludovic Courtès
Paul Eggert skribis: > On 07/04/2016 09:53 AM, Ludovic Courtès wrote: >> the conditional does not prevent >> mktime-internal’s configure snippet from being run. >> >> Any idea how to address it? > Perhaps your bootstrap script is calling gnulib-tool without the > --conditional-dependencies option

Re: [PATCH 0/2] use AM_TESTS_ENVIRONMENT Automake variable

2016-07-11 Thread Mathieu Lirzin
Karl Berry writes: > RHEL 7 > > Vast numbers of people run RHEL/CentOS/whatever < 7. Relying on these stable distributions generally means not wanting to mess with unstable development versions. Requiring a newer Automake version in Gnulib will only affect those. In the specific cases wher