Re: bug#11347: the remake rules in the automake test suite are too greedy

tags 11347 + patch close 11347 thanks On 04/26/2012 04:28 PM, Eric Blake wrote: > On 04/26/2012 07:10 AM, Stefano Lattarini wrote: >> And here is a patch. The change itself is obvious, but I'd like a review >> on the long-winded commit message. >> > [SNIP] useful review > I've addressed all you n

Re: [PATCH] {maint} news: break up in two files, one for maint, one for master

On 04/26/2012 05:17 PM, Eric Blake wrote: > On 04/26/2012 09:14 AM, Stefano Lattarini wrote: >> Now that we only have 'master' and 'maint' as long-lived branches >> (ok, there's 'ng/master' as well, but there we have a separated >> file 'NG-NEWS'), the NEWS changes should merge and sync easily and

Re: [FYI] {master} refactor: use modern semantics of 'open'

[SNIP] Eric Blake wrote: >>> >>> Alas, my perl-fu is weak enough that I'm not sure how good my >>> unit-testing attempts would be. But moving the files to a common >>> repository seems doable (how about gnulib?). I replied: >> >> This could be a good "interim" solution, as I the paperwork in pla

Re: [PATCH] {maint} news: break up in two files, one for maint, one for master

On 04/26/2012 09:14 AM, Stefano Lattarini wrote: > Now that we only have 'master' and 'maint' as long-lived branches > (ok, there's 'ng/master' as well, but there we have a separated > file 'NG-NEWS'), the NEWS changes should merge and sync easily and > cleanly. > > So I wish to take back my propo

Re: [PATCH] {maint} news: break up in two files, one for maint, one for master

Hi Eric, thanks for the feedback. On 04/26/2012 04:17 PM, Eric Blake wrote: > On 04/26/2012 03:30 AM, Stefano Lattarini wrote: >> This will avoid a lot of useless conflicts or botched merges in the >> NEWS file. These have already happened many times with our old setup >> where there was just one

Re: bug#11347: the remake rules in the automake test suite are too greedy

On 04/26/2012 07:10 AM, Stefano Lattarini wrote: >> > > And here is a patch. The change itself is obvious, but I'd like a review > on the long-winded commit message. I will push by tomorrow if there is no > review by then. > > > The described situation could hinder hinder on-field testing or

Re: [FYI] {master} refactor: use modern semantics of 'open'

On 04/26/2012 05:12 AM, Stefano Lattarini wrote: > Hi Eric, sorry for the delay. > > On 04/25/2012 01:25 AM, Eric Blake wrote: >> >> Actually, this appears to make _all_ the XFile uses work; all that >> remains broken is places such as bin/autoupdate.in calling raw open >> instead of using XFile.

Re: [PATCH] {maint} news: break up in two files, one for maint, one for master

On 04/26/2012 03:30 AM, Stefano Lattarini wrote: > This will avoid a lot of useless conflicts or botched merges in the > NEWS file. These have already happened many times with our old setup > where there was just one NEWS files. > > * NEWS: Removed, split into ... > * NEWS.maint, old/NEWS: ... th

[SPAM] Re: ObjC++ integration (was: Re: bug#11346: automake-1.12 - one test fails (due to truncated timestamp)

On Thu, 26 Apr 2012, Stefano Lattarini wrote: On 04/26/2012 01:56 PM, Peter Breitenlohner wrote: but could also apply them to the current git version and send you these. Please do. If they are not-invasive, they could appear in 1.12.1. Hi Stefano, attached are six patches. The first four

Re: bug#11347: the remake rules in the automake test suite are too greedy

On 04/26/2012 12:10 PM, Stefano Lattarini wrote: > Severity: minor > > Reference: > > On 04/22/2012 08:10 PM, Bruno Haible wrote: >> >> [SNIP] >> >> Modifying a test apparently requires me to have the same exact Autoconf >> version (2.68) as

ObjC++ integration (was: Re: bug#11346: automake-1.12 - one test fails (due to truncated timestamp)

[dropping bug-automake, adding automake-patches] On 04/26/2012 01:56 PM, Peter Breitenlohner wrote: > On Thu, 26 Apr 2012, Stefano Lattarini wrote: > >>> because you should still have the paperwork from the ObjC++ integration. >>> >> I wasn't involved in the project yet back then, so I wasn't awa

Re: [FYI] {master} refactor: use modern semantics of 'open'

Hi Eric, sorry for the delay. On 04/25/2012 01:25 AM, Eric Blake wrote: > > Actually, this appears to make _all_ the XFile uses work; all that > remains broken is places such as bin/autoupdate.in calling raw open > instead of using XFile. > >>> >>> diff --git i/lib/Autom4te/XFile.pm w/lib/Autom4t

Re: 1.12 bugfix: unset local var to prevent env influence

() Stefano Lattarini () Thu, 26 Apr 2012 12:33:08 +0200 Do you have an environment variable named 'd'? I like minimalism, but this seems a little over-the-top ;-) I live in Emacs and ‘C-x C-f $ d RET’ is a nice way to get there quickly. Attached is ~/.directory-env-vars just so you see h

Re: 1.12 bugfix: unset local var to prevent env influence

Hi Thien-Thi, thanks for the report and the patch. On 04/26/2012 11:45 AM, Thien-Thi Nguyen wrote: > Automake 1.12 "make check" reported only one FAIL, which I traced > to a strange value for var 'd' in t/remake11.sh, leaking in from > the environment. > Do you have an environment variable named '

1.12 bugfix: unset local var to prevent env influence

Automake 1.12 "make check" reported only one FAIL, which i traced to a strange value for var 'd' in t/remake11.sh, leaking in from the environment. You can probably guess its value from this test-suite.log excerpt: test-suite.log-EXCERPT Description: Binary data Anyway, here's the trivial patc

[PATCH] {maint} news: break up in two files, one for maint, one for master

This will avoid a lot of useless conflicts or botched merges in the NEWS file. These have already happened many times with our old setup where there was just one NEWS files. * NEWS: Removed, split into ... * NEWS.maint, old/NEWS: ... these two files. * NEWS.master: New file, still empty (it will

[FYI] {master} build: require autoconf 2.69

It is only from version 2.69 that the 'AC_PROG_FC' macro has started to set the '$GFC' variable to "yes" if the selected Fortran compiler is a GNU compiler. Since we use this variable in our configure.ac, we better require autoconf 2.69 explicitly. * configure.ac (AC_PRERQ): Require autoconf >= 2

[FYI] {maint} build: don't require minimal automake version in AM_INIT_AUTOMAKE

* configure.ac (AM_INIT_AUTOMAKE): Don't explicitly require a minimal automake version number. Since the Automake build system is only meant to work with the bleeding-edge automake, that requirement was redundant and misleading. Signed-off-by: Stefano Lattarini --- configure.ac |2 +- 1 fil