On 6/6/24 15:20, Christoph Grüninger wrote:
I think we should apply for the Bug Resilience Program with their Direct
Contributions option. This is not funding, rather a company is hired to
do the mentioned things. It is easier to apply for and if granted should
improve the situation.
Would it b
On 2024-06-06 10:48, Christoph Grüninger wrote:
Citing from the application you linked, I am referring to "direct
contribution":
> Direct Contributions will be provided by Neighborhoodie GmbH
> and entails direct code and non-code contributions, such
> as triaging, sorting and fixing known i
On 2024-06-06 08:10, Zack Weinberg wrote:
On Thu, Jun 6, 2024, at 10:37 AM, Dan Kegel wrote:
That's a really good idea. Automake and Autotools in general underpin
a fair amount of key open source software, but is taken for granted.
Ideas for making the case for funding:
As near as I can make
e.From 713d9822bbfb2923115065efaefed34a0113f8a1 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Sat, 1 Apr 2023 16:44:03 -0700
Subject: [PATCH] Fix timing bug on high-speed builds
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Problem reported by Bogdan via Jacob Bachmeyer in:
On 2/14/22 20:03, Mike Frysinger wrote:
are the corner cases known ?
I don't know of a catalog, no.
These days you might have better luck with "find ... -exec ... {} +".
Although standardized more recently than xargs, my vague impression is
that there's less variation among implementations.
On 2/14/22 19:45, Mike Frysinger wrote:
how portable is xargs ?
It can be a porting problem, unfortunately. There are several corner
cases that various implementations don't get right. I expect this is why
the GNU Coding Standards exclude xargs from the list of programs that
'configure' and
On 3/9/21 12:26 PM, Paul Eggert wrote:
On 3/9/21 11:09 AM, Karl Berry wrote:
I fully disagree. (Along with, it seems, everyone else except
you and Ben.)
Ben is the main person to convince here, since he's the maintainer.
Oh, my mistake. Ben has stepped down, so I should have written
On 3/9/21 11:09 AM, Karl Berry wrote:
I fully disagree. (Along with, it seems, everyone else except
you and Ben.)
Ben is the main person to convince here, since he's the maintainer.
I am a bit disenheartened to see that Ben hasn't sent any email to this
list since he installed the change in
On 3/9/21 5:57 AM, Bob Friesenhahn wrote:
It seems that config.guess and Autotools packages are picking winners
and losers. It is not clear where the bar has been set.
I prefer to draw the line at systems that are no longer supported by
their own suppliers. For Solaris, that means I worry on
On 3/8/21 3:00 PM, Dmitry V. Levin wrote:
The only rationale provided by the previous maintainer so far is a short
message in config-patches mailing list [1].
The config maintainer Ben Elliston has wanted to get rid of the
old-fashioned accent graves for many years. In November 2017 he
instal
On 1/29/21 12:03 PM, Zack Weinberg wrote:
Perl 5.18.0 was released in May 2013. (Perl 5.6.0 was released in
March 2000.) I selected it as the minimum because the Perl
maintainers recommend all users of older interpreters upgrade to at
least this version, due to security fixes (see
https://perl
On 1/28/21 10:34 AM, Zack Weinberg wrote:
we could instead use the
battle-tested technique used by Emacs: symlink sentinels. (See
https://git.savannah.gnu.org/cgit/emacs.git/tree/src/filelock.c .)
Although that Emacs code is battle-tested, one of the things it does is
fall back on regular fi
On 1/21/21 8:01 AM, Zack Weinberg wrote:
I know that
at least one person has tried to write a set of GNU Make library files
intended to replace it altogether, but I've never seen anyone *finish*
that project. I'd very much like to see someone give that another go.
GNU Emacs never used Automake
On 10/6/20 10:31 AM, Zack Weinberg wrote:
Seems reasonable. What do you think of the patches below?
Those Autoconf patches look good to me, thanks.
On 9/10/20 11:48 AM, Zack Weinberg wrote:
I’m wondering whether it would make
sense to merge this distributor’s patch to avoid supplying -Wcross to
automake -- perhaps generalized to arbitrary warning categories. What
do you think?
Yes, we can't assume that both packages are of the same vintag
On 7/27/20 2:24 PM, Karl Berry wrote:
https://lists.gnu.org/r/bug-bison/2020-07/msg00042.html
I can understand increasing permissions to allow +rx on installation
directories, but why force 755, thus disallowing group writability?
I've never understood this forcing of 755.
I expect it was
y patching Automake master's
install-sh and mkinstalldirs files, resulting in the attached Gnulib patch which
I've installed into Gnulib master. Hope this helps.
>From 1990797800153088f32029877f503f3157aad9ed Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Sun, 26 Jul 2020 15:17:4
Mathieu Lirzin wrote:
According to ‘git blame’ I appear to not have touch this file, so if you
think that I am eligible, I am volunteering on this rewriting task.
Thanks for volunteering. Eric, do you think it would save time overall if you
sent him the part of install-sh that you are sure is
My kneejerk reaction is that Python would be a good language
for Autoconf to deal with. The hard part would probably
be writing the documentation -- is that something you
could do? The idea would be to come up with a patch
to the Autoconf sources.
Eric Blake <[EMAIL PROTECTED]> writes:
> + /* This warning must not kill m4 -E, or it will break autoconf. */
> + if (text && strstr (text, "${"))
> +M4ERROR ((0, 0, "Warning: raw `${' in defn of %s will change semantics",
> + name));
This warning will generate a lot of false pos
Benoit Sigoure <[EMAIL PROTECTED]> writes:
> http://lists.gnu.org/archive/html/automake-patches/2006-10/msg00070.html
I installed the following to Automake install-sh to implement
"install-sh -C", which is the second part of that patch.
2006-12-25 Paul Eggert
Thomas Schwinge <[EMAIL PROTECTED]> writes:
> This brings up the following question: if `-C' shall be used a) by
> default in Autoconf's `AC_PROG_INSTALL' if available or b) if requested
> by the programmer through setting some flag, and `install-sh' supports
> `-C', but the system's `install' exe
anup part. It shouldn't change any
behavior. I installed this. I'll look into the -C part shortly.
2006-12-24 Paul Eggert <[EMAIL PROTECTED]>
* lib/install-sh: Fix typo in previous patch for handling --.
Use more-consistent style for ';;'.
Pref
Benoit Sigoure <[EMAIL PROTECTED]> writes:
> http://lists.gnu.org/archive/html/automake-patches/2006-10/msg00070.html
Sorry, I missed that one. The idea looks reasonable, but that solves
the problem for install-sh only, right? GNU 'install' still wouldn't
support -C.
Also, the updated patch pr
I like the basic idea for this.
The patches would have to be contributed by someone who's signed
the appropriate papers, since it's a nontrivial change.
We're happy to announce the release of Autoconf 2.61a. This is a test
version, meant to shake out bugs in our switch from 'sed' to 'awk' to
implement 'configure'-time substitutions, and (if 'printf' is
available) from 'echo' to 'printf' to output strings containing
special characters. There is al
We're happy to announce the release of Autoconf 2.61.
Please grab it from one of the gnu.org mirror sites.
The important changes since 2.60 are listed below. The BIN_SH change
may require special attention by installers on some older-style
platforms, but as far as we know this affects only Unixwa
We're happy to announce the release of Autoconf 2.60b. This is a test
version. It is mostly a bug-fix release since 2.60. We hope to
generate Autoconf 2.61 soon, based on feedback from this test version.
The important changes since Autoconf 2.60a are listed below.
The sources and GPG detached
We're happy to announce the release of Autoconf 2.60a. This is a test
version. It is mostly a bug-fix release since 2.60. We hope to
generate Autoconf 2.61 soon, based on feedback from this test version.
The important changes since Autoconf 2.60 are listed below.
The sources (1.4 MB) and GPG d
ERL, AC_ERLANG_CHECK_LIB, AC_ERLANG_SUBST_ROOT_DIR,
AC_ERLANG_SUBST_LIB_DIR.
New macros for configuring installation of Erlang libraries:
AC_ERLANG_SUBST_INSTALL_LIB_DIR, AC_ERLANG_SUBST_INSTALL_LIB_SUBDIR.
** The manual now mentions Gnulib more prominently.
** New macros to support Objective C.
AC_PRO
Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> * doc/install.texi (Compilers and Options): Weaken the
> suggestion to use GNU make for VPATH builds.
Thanks, I installed that.
Ralf Corsepius <[EMAIL PROTECTED]> writes:
> The sub-sentence I consider to be wrong is this:
>
> INSTALL now suggests VPATH builds (e.g., "sh ../srcdir/configure")
> only if you use GNU make.
This is merely a sentence taken from the NEWS file for Autoconf. It
isn't a constraint on Autoconf'
Ralf Corsepius <[EMAIL PROTECTED]> writes:
> => If automake doesn't hold what it promises, it's a bug in automake
At the very least there is a documentation problem in Automake,
because nowhere does it say that you can't have a test named 'test' --
a situation that caused coreutils 'make check' t
should stay away from
Solaris 'make' for VPATH builds is still sound. See, for example,
<http://lists.gnu.org/archive/html/bug-coreutils/2006-06/msg00033.html>.
(It's not so much an Automake regression as an undocumented minefield. :-)
I installed the following patch.
2006
ondition on POSIX conforming
hosts. On older hosts there's no hope that I can see in general, but
it's not worth worrying about these ancient hosts at this point. I
hope this addresses Ralf's concerns.
2006-04-24 Paul Eggert <[EMAIL PROTECTED]>
* lib/install-sh: C
Stepan Kasal <[EMAIL PROTECTED]> writes:
> I think it is more practical to have $(mkdir_p) set to 'mkdir -p --'.
Yes, that is a possibility.
> And you can often write
> $(mkdir_p) $(directory_list)
> without knowing exactly the names of the directories. It's natural to
> forget that the d
business a
while ago, it was being used in a different context; but now that
$(mkdir_p) is intended to mean 'mkdir -p' I think it's more consistent
for the expansion to not include the '--'.
Here's a proposed Automake patch to implement this. I noticed that
install-sh
Stepan Kasal <[EMAIL PROTECTED]> writes:
> I second this proposal. I think this could be added right now, even though
> we are in a freeze.
I tend to agree, since it's taken from Automake. Assuming my minor
patch to Automake for leading "-" is accepted I'd like that change put
into Autoconf as
Keith Marshall <[EMAIL PROTECTED]> writes:
> This requirement is reflected in the SunOS man page, (from SunOS 5.5.4,
> IIRC)
Hmmm, "SunOS 5.5.4"? There's no such version.
The Sun 'sed' pages that I looked at (from SunOS 5.8 and SunOS 5.10)
don't require that _every_ command be separated by new
Stepan Kasal <[EMAIL PROTECTED]> writes:
> semicolons cannot be used inside
> curly braces, so you have to write, for example:
>
> sed '/datarootdir/{
> p
> q
> }'
>
> IIRC, Autoconf was recently fixed to obey this rule,
Yes, here:
http://lists.gnu.org/archive/html/autoconf-patch
Stepan Kasal <[EMAIL PROTECTED]> writes:
> --- lib/Automake/FileUtils.pm 2006-04-14 09:25:00.0 +0200
> +++ lib/Automake/FileUtils.pm 2006-04-14 09:45:44.0 +0200
> @@ -73,6 +73,9 @@
>$optional = 1
> if $file_name =~ s/\?$//;
>
> + return "-"
> +if $file_name eq "-";
Bruno Haible <[EMAIL PROTECTED]> writes:
> That appears to be obsolete. As far as I see, there are no users of this
> macro which don't also bundle regex.c.
Yes, that sounds right. I installed this patch into gnulib, and then
reindented.
2005-08-23 Paul Eggert
Bruno Haible <[EMAIL PROTECTED]> writes:
> You are right, the presence of $(ARGZ_H) in $(BUILT_SOURCES) makes this
> rule unnecessary. (Historically, the rule predates the use of BUILT_SOURCES.)
> Thanks for the hint. I propose this patch in gnulib.
Thanks; I installed that. At the same time I c
> On Fri, Feb 04, 2005 at 02:49:29PM +0100, Ralf Corsepius wrote:
>> So adding $(SHELL) might not be wrong.
But SHELL might disagree with CONFIG_SHELL; the latter is used to run
config.status. So adding $(SHELL) might be wrong.
Noah Misch <[EMAIL PROTECTED]> writes:
> I suspect more systems sti
t, and added a proper cross reference and
some index entries, and installed the following.
2005-02-01 Paul Eggert <[EMAIL PROTECTED]>
* doc/autoconf.texi (autoreconf Invocation): Mention autopoint,
with a cross reference. Derived from a suggestion by Bruce Korb.
--- autoconf
Noah Misch <[EMAIL PROTECTED]> writes:
> 2005-01-04 Noah Misch <[EMAIL PROTECTED]>
>
> * lib/autoconf/programs.m4 (AC_PROG_MAKE_SET): If the Make program does
> not seem to work, assume it does set $(MAKE).
> * doc/autoconf.texi (AC_PROG_MAKE_SET): Update.
Thanks; I installed
Noah Misch <[EMAIL PROTECTED]> writes:
> 2005-01-04 Noah Misch <[EMAIL PROTECTED]>
>
> * lib/autoconf/programs.m4 (AC_PROG_MAKE_SET): If the Make program does
> not seem to work, assume it does set $(MAKE). Make `MAKE' precious.
> * doc/autoconf.texi (AC_PROG_MAKE_SET): Update
"Gary V. Vaughan" <[EMAIL PROTECTED]> writes:
> Now for the note to the FSF that explains why we need it... here
> is a first cut to get the ball rolling:
That looks fine to me. Thanks.
Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
> "or any derived output" is a lame attempt to allow tools such as
> aclocal (without singling out aclocal) to preprocess the file,
> as long as the intent is to build a configure script.
I like the idea, but how about if we generalize it to allo
"Gary V. Vaughan" <[EMAIL PROTECTED]> writes:
> Was anybody unhappy with the exception wording in my last post in the
> thread? If not we can start from there.
I worry that it's too generous, because it means that if the package
uses the .m4 file as input to autoconf, then the package can also u
"Gary V. Vaughan" <[EMAIL PROTECTED]> writes:
> However, even though our intentions are good, and we are merely
> clarifying the existing spirit of the exception clauses we have used
> all along, is it okay to just edit the license of existing files without
> explicit permission from the authors?
Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
Some ideas:
>
> 1. prefix all the m4/*.m4 licenses with `##' so aclocal
> omit them from aclocal.m4 (leaving only the "unlimited
> permission to ..." license added by aclocal)
>
> 2. add an exception to all the m4/*.m4 files similar
GNU Autoconf test version 2.59b is now available.
This version is numbered 2.59b because I've heard of some "2.59a"
versions floating around the net, and I wanted to distinguish it.
This is an "early beta" release. I expect it to have several
problems, particularly porting problems on hosts other
Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
> I've prepared this. However I'm not really proud of the name
> `filenames-99'. Maybe someone can suggest some nicer name?
I don't know what the rules are for Automake option spelling, but how
about "filename-length-max=99"? This is because the
Eric Sunshine <[EMAIL PROTECTED]> writes:
> Autoconf could, for example, publish a macro such as the following:
>
> AS_SELECT_SHELL([features], [action-if-found], [action-if-not-found])
I like this basic idea approach (though of course it would take some
hacking).
Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
> I'd say it would be useful that @SHELL@ be the most POSIX compliant
> shell that does not require any configuration code (such as
> _AS_BOURNE_COMPATIBLE) to work. CONFIG_SHELL would allow shell that
> require such extra code.
Yes, I like this i
Thanks for writing that. Some minor points:
Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] selects the new pax format defined by POSIX
> +1003.1-2001. It supports filenames with up to 65535 characters.
Hmm, where did that "65535" come from? I don't know of any limit of
6
Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
> Paul> tar --format=ustar
> Paul> tar
> Paul> pax -x ustar
>
> This looks satisfactory when GNU tar 1.13.93 is installed, or
> when GNU tar is not installed. However, on most GNU/Linux
> setups, which have GNU tar 1.13.25 installed, my understa
Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
> How about this scheme:
In the light of later discussion, how about this scheme instead?
Use the first of the following commands that works:
tar --format=ustar
tar
pax -x ustar
I wouldn't bother with POSIXLY_CORRECT=1 or "tar -o",
Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
> 1. The --format=posix options is a GNU Tar option, which means `make dist'
>can no longer be run with other make implementations.
Presumably you meant "tar implementations" and not "make
implementations"? But this is already the case, as the
Autoconf 2.59 is now available from the following URLs:
ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.59.tar.gz
ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.59.tar.bz2
Here are the MD5 checksums:
d4d45eaa1769d45e59dcb131a4af17a0 autoconf-2.59.tar.gz
1ee40f7a676b3cfdc0e3f7cd81551b5f autoconf-2.59.tar.
"Paul Smith" <[EMAIL PROTECTED]> writes:
> The verification is complete for almost all the code, but Ben Elliston
> (who, according to the FSF folks I talked to, owns these particular
> files) has not responded to requests for help in verifying these files.
That could be because he moved from Red
The GNU FTP server has been frozen since late July; nothing new has
appeared on it. I don't know what the holdup is.
I suggest that we find a new home for config.guess and config.sub in
the meantime.
gnulib currently keeps copies of several files like that in one
convenient place. It slurps the
[EMAIL PROTECTED] writes:
> I want to follow correct GNU style but this ChangeLog file just seems like
> too much work. Doesn't everyone agree?
No. ChangeLogs take work, but it's generally useful work if done right.
I often refer to ChangeLogs to figure out what happened and why.
You don't want
"John W. Eaton" <[EMAIL PROTECTED]> writes:
> even Ultrix had another shell, /bin/sh5, if I remember correctly,
> that did support shell functions, and it would not have been too
> difficult for configure to attempt to find it
Recent versions of Autoconf generate "configure" scripts that do just
Alex Hornby <[EMAIL PROTECTED]> writes:
> On a related note, does the restriction of not using shell functions in
> autoconf macros still remain,
For Autoconf itself, we still avoid shell functions. But of course
you can use shell functions in your own macros, if you don't care
about porting to
"Dr. David Kirkby" <[EMAIL PROTECTED]> writes:
> although you are saying it is still an operating system supported by
> Sun
"Support" is a relative term. If you find a new bug in SunOS 4.1.4,
Sun will not fix it for you, even if you have purchased a standard
software maintenance contract from Su
"Dr. David Kirkby" <[EMAIL PROTECTED]> writes:
> SunOs 4.1.4
Sun has been withdrawing support for that OS. Since September 2000
Sun has not issued patches for new bugs in that operating system. On
September 30, Sun will further transition SunOS 4.1.4 to "custom
quote" level, which means you wil
The Autoconf team -- Akim, Alexandre, Jim, Paul, and Tom -- is happy
to announce the birth of Autoconf 2.57, a bugfix release.
- Where can I find it?
ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.57.tar.gz (1.1 MB)
ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.57.tar.bz2(811 kB)
and soon
In testing my patch I managed to find a old version of GNU m4 that
illustrates the limitation that you mentioned; and my patch tickled
that limitation as well. So it looks like your "less conservative
patch" is better after all. So I installed your patch instead,
as follows. Thanks.
2002-12-02
ts around.
Thanks for the detailed bug report, and for the patch.
I installed the following patch instead; it's a bit more conservative.
2002-12-02 Paul Eggert <[EMAIL PROTECTED]>
* bin/autom4te.in (handle_traces): [^ *\(.*\) *$] ->
[^ *\(.*[^ ]\)? *]. The old regular exp
> From: [EMAIL PROTECTED]
> Date: 08 Nov 2002 09:40:21 +
>
> Would the auto* tool maintainers be interested in hearing more about
> automakejar's functionality? Perhaps with a view to implementing
> similar functionality in automake?
Maybe. Do you have a URL or brief summary explaining the a
> From: "Eric Lemings" <[EMAIL PROTECTED]>
> Date: Thu, 7 Nov 2002 14:23:28 -0700
>
> After reading through Section 11.4 of the Automake Manual, I was just =
> curious about how well future releases of Automake (and Autoconf) are =
> going to support distributions with Java source code. Just for
> From: Tom Lord <[EMAIL PROTECTED]>
> Date: Sun, 13 Oct 2002 09:30:13 -0700 (PDT)
>
> I would expect these forks to be very stable,
> tending mostly to be simplified over time.
I don't expect that. On the contrary, many of the macros recently
added to Autoconf (and even-newer macros stacked up
> From: Akim Demaille <[EMAIL PROTECTED]>
> Date: 25 Sep 2002 12:03:42 +0200
>
> Please, install!
OK, done. I did find some errors in my proposed text (it didn't give
the obvious workaround, and it credited the wrong people for the patch
-- ouch!), so I installed the following patch instead.
> From: Akim Demaille <[EMAIL PROTECTED]>
> Date: 24 Sep 2002 13:33:43 +0200
>
> So as was kindly suggested by TED, we should have autoreconf work
> around Libtool problems.
I missed that suggestion somewhere in my mailbox (currently with 2035
messages to read, sigh); if you think it preferable
> From: Alexandre Duret-Lutz <[EMAIL PROTECTED]>
> Date: Thu, 27 Jun 2002 10:09:22 +0200
>
> I don't get it. The issue that you and the Autoconf manual
> describe is that `-a' and `-o' cannot be used *together*.
It's more complicated than that, due to combinations with other
operators. For exa
llowing patch to the Autoconf sources, to fix this
issue along with some more minor POSIX portability issues that I
noticed at the same time.
2002-06-27 Paul Eggert <[EMAIL PROTECTED]>
* config/install-sh: Quote $src. Prefer || to test's -o option,
as per "Limitati
> Date: Tue, 02 Apr 2002 22:41:50 -0800
> From: Dan Kegel <[EMAIL PROTECTED]>
>
> Clearly, one would also want cp --clean.
"rm --clean" would be far more useful. I've often wanted that,
usually right after I've removed the wrong thing.
(Sorry, Akim, couldn't resist)
> From: Akim Demaille <[EMAIL PROTECTED]>
> Date: 02 Apr 2002 18:57:05 +0200
>
> it makes no sense at all the distclean a single directory, as anyway you
> need to rerun config.status to re-enable this directory. Of course,
> knowledgeable people will answer that ./config.status foo/Makefile
> d
> From: Akim Demaille <[EMAIL PROTECTED]>
> Date: 26 Mar 2002 10:53:35 +0100
>
> * configure or config.status?
>
> It seems much simpler to do that in config.status, since, for a start,
> it knows exactly what files were created. configure should run in
> full before knowing what were the creat
> From: Per Bothner <[EMAIL PROTECTED]>
> Date: Fri, 22 Feb 2002 17:24:24 -0800
>
> I found a problem when trying to configure rhug with srcdir=".".
> It would try to mkdir /.deps. The reason was (it seemed) to be a bug
> in configure. Since configure is generated by autoconf, I took a
> look a
> From: "Tim Van Holder" <[EMAIL PROTECTED]>
> Date: Fri, 21 Sep 2001 18:44:43 +0200
>
> bash's behaviour with regards to the 'set' builtin has changed in 2.05
> This apparently lead to a broken config.cache when using bash 2.05
> > ! ac_cv_path_install=${ac_cv_path_install='ginstall -c'
> From: Sascha Schumann <[EMAIL PROTECTED]>
> Date: Tue, 18 Sep 2001 16:00:11 +0200 (CEST)
>
> '{}' can only be used portably, if it is a separate argument.
It's worse than that. Not only must '{}' be separate and not part of
any other argument, it must not be followed by another argument '
84 matches
Mail list logo
