On Sun, Jan 14, 2024 at 3:13 AM Karl Berry wrote:
> With Python 3.12 out now, and 3.13 out in ~9 months, the existing
> runway
> is running out. Bump up to 3.20 for the next Automake release.
>
> Applied, thanks.
>
> Not proposing to try anything for our upcoming release, but I wonder
On Fri, Dec 29, 2023 at 6:14 PM Karl Berry wrote:
> The GNU Automake 1.16j development snapshot is now available. Download
> here:
>
> https://alpha.gnu.org/gnu/automake/automake-1.16j.tar.xz
> https://alpha.gnu.org/gnu/automake/automake-1.16j.tar.gz
>
> Hello,
No major issue found during
On Mon, Dec 18, 2023 at 10:32 PM Karl Berry wrote:
> We are pleased to announce the GNU Automake 1.16i development snapshot.
> We intend for automake 1.17 to be released soon, essentially with only
> bug fixes for whatever is found in this pretest. So please do test if at
> all possible.
>
>
Hello,
I spent some more time on testing, and I could reproduce the issue on
Fedora rawhide, which gives more freedom for reproduction.
Regarding what I said earlier, since that wasn't clear enough, I couldn't
reproduce `make check` failures with the 1.16.5 official taball in a mock
environment,
Oh, and I forgot, regarding autoconf: the RHEL 8 image I tested with had
autoconf 2.69. Failures could be detected with automake trunk, not with
official tarball (at least so far).
On Mon, Mar 6, 2023 at 11:19 PM Frederic Berat wrote:
> Hello,
>
> I spent some more time on testing, an
Hello,
For the record, I made a first run of testing on a rhel 8 system.
While building the trunk directly led to check failures, rebuilding the RPM
in a mock environment didn't.
I'll likely spend more time next week to perform more testing. It may
simply be an environment problem: I noticed the
Yes, they got separated bug IDs, next time I should probably consider
modifying the patch headers so that they are sent in reply to the cover
letter.
The first patch has been merged (
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59992).
The second has been divided in 2:
case foo.o is consistently rebuilt,
while not in the other.
On Fri, Jan 13, 2023 at 10:57 AM Frederic Berat wrote:
> Ok, I'll try to figure out why this test passes on 1.16.5 but not on HEAD
> with the same patch.
>
> On Fri, Jan 13, 2023 at 9:47 AM Mike Frysinger wrote:
>
>&
I probably won't be able to do so before next week at least.
If you happen to have time (and be willing) to do it earlier, don't
hesitate ;)
On Fri, Jan 13, 2023 at 7:31 AM Mike Frysinger wrote:
> On Mon, 12 Dec 2022 15:20:46 -0500, Zack Weinberg wrote:
> > On 2022-12-12 2:07 AM, Frede
Ok, I'll try to figure out why this test passes on 1.16.5 but not on HEAD
with the same patch.
On Fri, Jan 13, 2023 at 9:47 AM Mike Frysinger wrote:
> On 13 Jan 2023 09:14, Frederic Berat wrote:
> > I made one more build with a different patchset list, could it be that
> the
>
I made one more build with a different patchset list, could it be that the
failure you encounter is with "t/subobj.sh" ?
In my tests run this failure is fixed by:
https://lists.gnu.org/archive/html/automake-patches/2022-12/msg1.html
On Fri, Jan 13, 2023 at 8:57 AM Frederic Be
That's strange, although I tested it on top of automake-1.16.5, I don't
have any failure on `make check` with this one here [1].
May you provide more details ?
[1]
Testsuite summary for GNU Automake 1.16.5
From: Frédéric Bérat
Hello,
There is ongoing work from both GCC and Clang community to set the C99 standard
as the default one.
In this context, Fedora packages were rebuilt with some warnings turned as
errors to simulate the change. This leads to failures in Automake, that are
attempted to be
From: Frédéric Bérat
Changes from v1:
Modifications to "t/ax/depcomp.sh" have been moved to a dedicated patch
-- 8< --
This is related to an effort to prepare Automake for future GCC/Clang
versions which set c99 as default standard to be used.
Function should be properly declared prior to
From: Frédéric Bérat
No modifications from v1
-- 8< --
This is related to an effort to prepare Automake for future GCC/Clang
versions which set c99 as default standard to be used.
Not properly declaring main as "int main(...)" is rejected since c99.
---
t/link_cond.sh | 2 +-
1 file changed,
From: Frédéric Bérat
Changes from v1:
Split from [PATCH 2/2]
-- 8< --
In depcomp.sh, the following occurs:
1. Files are created so that headers and units are available in
subdirectories
2. Multiple "make" are executed, while modifying the content of the
headers, some should fail,
On Mon, Dec 12, 2022 at 9:19 PM Zack Weinberg wrote:
>
> On 2022-12-12 2:05 AM, Frederic Berat wrote:
> > This is related to an effort to prepare Automake for future GCC/Clang
> > versions which set c99 as default standard to be used.
> > Function should be properly declar
:5:13: error: expected type-specifier before ‘;’ token
5 | return new;
| ^
On Tue, Dec 13, 2022 at 7:35 AM Frederic Berat wrote:
>
> On Mon, Dec 12, 2022 at 9:15 PM Zack Weinberg wrote:
> >
> > On 2022-12-12 2:05 AM, Frederic Berat wrote:
> > >
I'll separe this one in a dedicated patch and give it a more
detailed/specific explanation.
On Tue, Dec 13, 2022 at 10:02 PM Zack Weinberg wrote:
>
> On Tue, Dec 13, 2022, at 1:30 AM, Frederic Berat wrote:
> > On Mon, Dec 12, 2022 at 9:19 PM Zack Weinberg wrote:
> >> &g
On Mon, Dec 12, 2022 at 9:19 PM Zack Weinberg wrote:
>
> On 2022-12-12 2:05 AM, Frederic Berat wrote:
> > This is related to an effort to prepare Automake for future GCC/Clang
> > versions which set c99 as default standard to be used.
> > Function should be properly declar
On Mon, Dec 12, 2022 at 9:15 PM Zack Weinberg wrote:
>
> On 2022-12-12 2:05 AM, Frederic Berat wrote:
> > This is related to an effort to prepare Automake for future GCC/Clang
> > versions which set c99 as default standard to be used.
> > Not properly declaring main as &qu
Fine with me, thanks !
On Mon, Dec 12, 2022 at 11:52 PM Karl Berry wrote:
> Hi Frederic,
>
> Texinfo modified its behavior regarding apostrophes, which are now
> replaced by UTF-8 right single quotes by default.
>
> Sorry to hear it, but not surprised.
>
> -GNU's Not Unix.
>
From: Frédéric Bérat
While running automake tests with -std-gnu=c99, the compiler report
errors which lead to make to fail. Yet, these failures are ignored
during the tests, which considers them to be successful as stderror is
check for one specific pattern.
If make fails, investigation should
Hello,
There is ongoing work from both GCC and Clang community to set the C99 standard
as the default one, in an effort to improve security overall.
In this context, Fedora packages were rebuilt with some warnings turned as
errors to simulate the change. This leads to failures in Automake, that
From: Frédéric Bérat
This is related to an effort to prepare Automake for future GCC/Clang
versions which set c99 as default standard to be used.
Function should be properly declared prior to use in order to be
compatible with c99 standard.
This is valid for both local functions and standard
From: Frédéric Bérat
This is related to an effort to prepare Automake for future GCC/Clang
versions which set c99 as default standard to be used.
Not properly declaring main as "int main(...)" is rejected since c99.
---
t/link_cond.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
From: Frédéric Bérat
Hello,
This patch is mainly a proposal. While the macro can simply be removed
as explained below, another possibility it to add a flex option
"--never-interactive" to prevent flex to make use of "isatty".
-- 8< --
This is related to an effort to prepare Automake for
From: Frédéric Bérat
Texinfo modified its behavior regarding apostrophes, which are now
replaced by UTF-8 right single quotes by default.
It looks like this was supposed to be the default for few years already,
but this behavior was broken so far.
Use the @verb construct in order to ensure that
Hello,
I don't know if that will help, or if that is completely unrelated, but I'm
currently stumbling into a weird issue while working on a new package
release for autoconf on Fedora: about 200 tests are now failing, all
related to aclocal checks.
My current investigation shows that it would be
29 matches
Mail list logo
