Bruno Haible wrote:
Jacob Bachmeyer wrote:
under what conditions can "checking that
generated files are newer than configure" actually fail?
I mentioned two such conditions in [1]:
- Skewed clocks. (I see this regularly on VMs that have 1 or 2 hours
of skew.)
Zack Weinberg wrote:
On Tue, Jun 18, 2024, at 12:02 AM, Jacob Bachmeyer wrote:
[...]
Wait... all of configure's non-system dependencies are in the release
tarball and presumably (if "make dist" worked correctly) backdated
older than configure when the tarball is unpacke
Zack Weinberg wrote:
On Mon, Jun 17, 2024, at 10:30 PM, Jacob Bachmeyer wrote:
...
Don't have enough brain right now to comment on any of the rest of your
suggestions, but:
once conftest.file is newer than configure, surely
config.status, which is produced after all tests are run,
Nick Bowler wrote:
On 2024-06-16 21:35, Jacob Bachmeyer wrote:
I think we might best be able to avoid this by using AC_CONFIG_COMMANDS_POST
to touch config.status if neccessary, instead of trying to decide
whether to sleep before writing config.status.
If the problem is simply that we
Karl Berry wrote:
make(1) in AM_SANITY_CHECK seems to be a logic error, since the user
may want to build with a different $MAKE,
You're right. Crap. It never ends.
In practice it probably doesn't matter, though. Although in theory one
can imagine that "make" succeeds while $MAKE fails,
Karl Berry wrote:
Find here attached a revised proposed patch.
Ok on the reorg, but sorry, I remain confused. This whole thing started
with Mike Vapier's change in Feb 2022 (commit 720a11531):
https://lists.gnu.org/archive/html/automake-commit/2022-02/msg9.html
As I read it now, his goa
Karl Berry wrote:
Jacob,
[*sigh*]
You said it. About this whole thing. I rather wish this bright idea had
never come to pass. It has delayed the release by months. Oh well.
Still, could we use make(1) for *all* of the testing and not use `ls -t`
I guess it is technically possible, b
Dan Kegel wrote:
Does automake have a policy on when to stop supporting a CPU, operating
system, or compiler?
I am pondering the size of the matrix of supported operating systems, cpus,
and compilers, and wonder where a policy like
"Automake drops support 20 years after the release of a CPU, ope
Karl Berry wrote:
Does BSD ls(1) support "--time=ctime --time-style=full-iso"?
BSD ls does not support any --longopts. Looking at the man page,
I don't see "millisecond" or "subsecond" etc. mentioned, though I could
easily be missing it. E.g.,
https://man.freebsd.org/cgi/man.cgi?ls
Even
dherr...@tentpost.com wrote:
At some point, it becomes unreasonable to burden common platforms with
delays that only support relatively obscure and obsolete platforms.
Configure scripts already have a bad reputation for wasting time.
Even if they are faster than editing a custom makefile, the
Karl Berry wrote:
[...]
> and reduce technical debt.
I don't know what that means. I instinctively shy away from such
vague buzzwords.
Essentially, "technical debt" means "stuff on the TODO list" and more
specifically the accumulation of "good enough for now; fix it later"
that tend
Karl Berry wrote:
bh> Seen e.g. on NetBSD 10.0.
Which doesn't support subsecond mtimes?
jb> Maybe the best answer is to test for subsecond timestamp
granularity first, and then only do the slow test to distinguish
between 1-second and 2-second granularity if the subsecond
gr
Bruno Haible wrote:
Hi Jacob,
AFAIU, the 4x sleep 0.1 are to determine whether
am_cv_filesystem_timestamp_resolution should be set to 0.1 or to 1.
OK, so be it.
But the 6x sleep 1 are to determine whether
am_cv_filesystem_timestamp_resolution should be set to 1 or 2.
2 is known to be the ca
Bruno Haible wrote:
[I'm writing to automake@gnu.org because bug-autom...@gnu.org
appears to be equivalent to /dev/null: no echo in
https://lists.gnu.org/archive/html/bug-automake/2024-06/threads.html
nor in https://debbugs.gnu.org/cgi/pkgreport.cgi?package=automake,
even after several hours.]
I
Jacob Bachmeyer wrote:
[...] The preliminary reports that it was an RCE backdoor that would
pass commands smuggled in public key material in SSH certificates to
system(3) (as root of course, since that is sshd's context at that
stage) are inconsistent with the slowdown that cause
Zack Weinberg wrote:
On Tue, Apr 9, 2024, at 11:35 PM, Jacob Bachmeyer wrote:
Jan Engelhardt wrote:
On Tuesday 2024-04-09 05:37, Jacob Bachmeyer wrote:
In principle it could be posible to output something different to
describe this stramge situation explicitly. For instance
Jan Engelhardt wrote:
On Tuesday 2024-04-09 05:37, Jacob Bachmeyer wrote:
In principle it could be posible to output something different to
describe this stramge situation explicitly. For instance, output "via
stdin" as a comment, or output `stdin/../filename' as the file
Alan D. Salewski wrote:
On 2024-04-08 22:37:50, Jacob Bachmeyer spake thus:
Richard Stallman wrote:
[...]
In principle it could be posible to output something different to
describe this stramge situation explicitly. For instance, output "via
stdin" as a comment, or output `stdin/.
Richard Stallman wrote:
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> While it does not /prevent/ cracks, there is something
Bruno Haible wrote:
Richard Stallman commented on Jacob Bachmeyer's idea:
> > Another related check that /would/ have caught this attempt would be
> > comparing the aclocal m4 files in a release against their (meta)upstream
> > sources before building a package. This is something dist
Richard Stallman wrote:
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
[...]
When considering any such change, we still should co
Eric Blake wrote:
[adding in coreutils, for some history]
[...]
At any rate, it is now obvious (in hindsight) that zstd has a much
larger development team than xz, which may alter the ability of zstd
being backdoored in the same way that xz was, merely by social
engineering of a lone maintainer
Richard Stallman wrote:
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> My first thought was that Autoconf is a relatively triv
Bruno Haible wrote:
Jacob Bachmeyer wrote:
Another related check that /would/ have caught this attempt would be
comparing the aclocal m4 files in a release against their (meta)upstream
sources before building a package. This is something distribution
maintainers could do without
Richard Stallman wrote:
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> The issue seems to be releases containing binary data f
Richard Stallman wrote:
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> What would be helpful is if `make dist' would guarantee
Eric Gallager wrote:
On Tue, Apr 2, 2024 at 12:04 AM Jacob Bachmeyer wrote:
Russ Allbery wrote:
[...] I think one useful principle that's
emerged that doesn't disrupt the world *too* much is that the release
tarball should differ from the Git tag only in the form of a
Richard Stallman wrote:
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> `distcheck` target's prominence to recommend it in
Richard Stallman wrote:
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> I was recently reading about the backdoor announced in
Zack Weinberg wrote:
On Mon, Apr 1, 2024, at 2:04 PM, Russ Allbery wrote:
"Zack Weinberg" writes:
It might indeed be worth thinking about ways to minimize the
difference between the tarball "make dist" produces and the tarball
"git archive" produces, starting from the same clean git ch
Russ Allbery wrote:
[...]
There is extensive ongoing discussion of this on debian-devel. There's no
real consensus in that discussion, but I think one useful principle that's
emerged that doesn't disrupt the world *too* much is that the release
tarball should differ from the Git tag only in the
Zack Weinberg wrote:
[...] but I do think there's a valid point here: the malicious xz
maintainer *might* have been caught earlier if they had committed the
build-to-host.m4 modification to xz's VCS.
That would require someone to notice that xz.git has a build-to-host.m4
that does not exist an
Bruno Haible wrote:
Jacob Bachmeyer wrote:
Essentially, this would be an automated release building service: upon
request, make a Git checkout, run autogen.sh or equivalent, make dist,
and publish or hash the result. The problem is that an attacker who
manages to gain commit access to a
Bruno Haible wrote:
Jacob Bachmeyer wrote:
some of the blame for this needs to fall on the
systemd maintainers and their "katamari" architecture. There is no good
reason for notifications of daemon startup to pull in liblzma, but using
libsystemd for that purpose does exactly
Jose E. Marchesi wrote:
Jose E. Marchesi wrote:
[...]
I agree that distcheck is good but not a cure all. Any static
system can be attacked when there is motive, and unit tests are
easily gamed.
The issue seems to be releases containing binary data for unit
Tomas Volf wrote:
On 2024-03-31 14:50:47 -0400, Eric Gallager wrote:
With a reproducible build system, multiple maintainers can "make dist"
and compare the output to cross-check for erroneous / malicious dist
environments. Multiple signatures should be harder to compromise,
assuming each is
Eric Gallager wrote:
On Sun, Mar 31, 2024 at 3:20 AM Jacob Bachmeyer wrote:
dherr...@tentpost.com wrote:
[...]
The issue seems to be releases containing binary data for unit tests,
instead of source or scripts to generate that data. In this case, that
binary data was used to smuggle
Jose E. Marchesi wrote:
[...]
I agree that distcheck is good but not a cure all. Any static
system can be attacked when there is motive, and unit tests are
easily gamed.
The issue seems to be releases containing binary data for unit tests,
instead of source or scripts to generate t
dherr...@tentpost.com wrote:
On 2024-03-30 18:25, Bruno Haible wrote:
Eric Gallager wrote:
Hm, so should automake's `distcheck` target be updated to perform
these checks as well, then?
The first mentioned check can not be automated. ...
The second mentioned check could be done by the mainta
Eric Gallager wrote:
Specifically, what caught my attention was how the release tarball
containing the backdoor didn't match the history of the project in its
git repository. That made me think about automake's `distcheck`
target, whose entire purpose is to make it easier to verify that a
distri
Zack Weinberg wrote:
On Mon, Dec 4, 2023, at 7:26 PM, Jacob Bachmeyer wrote:
Now that I have seen the actual patch, yes, this test should be
accurate. The test in the main autom4te script will also work, even
if there is a mismatch between the script and its library
Good.
This
Zack Weinberg wrote:
On Mon, Dec 4, 2023, at 7:14 PM, Jacob Bachmeyer wrote:
Zack Weinberg wrote:
[snip everything addressed in the other thread]
Yes, there was a bit of confusion here; not only is the FileUtils
module synchronized between autom4te and automake
Thanks for
Zack Weinberg wrote:
The Automake test suite wants this in order to know if it’s safe to
reduce the length of various delays for the purpose of ensuring files
in autom4te.cache are newer than the corresponding source files.
* lib/Autom4te/FileUtils.pm: Provide (but do not export) a flag
$subse
Zack Weinberg wrote:
On Sun, Dec 3, 2023, at 4:49 PM, Karl Berry wrote:
There would not need to be much parsing, just "automake --version | grep
> HiRes" in that case, or "case `automake --version` in *HiRes*) ...;;
> easc" to avoid running grep if you want.
I specifical
Karl Berry wrote:
> There would not need to be much parsing, just "automake --version | grep
> HiRes" in that case, or "case `automake --version` in *HiRes*) ...;;
> easc" to avoid running grep if you want.
I specifically want to hear what Karl thinks.
I lean towards Jacob's v
Mike Frysinger wrote:
On 02 Dec 2023 17:07, Jacob Bachmeyer wrote:
Mike Frysinger wrote:
On 06 Apr 2023 21:29, Jacob Bachmeyer wrote:
Karl Berry wrote:
jb> a more thorough test would locate the autom4te script and grep it
for the perllibdir that
Zack Weinberg wrote:
On Sat, Dec 2, 2023, at 7:33 PM, Jacob Bachmeyer wrote:
Zack Weinberg wrote:
Would it help if we added a command line option to autom4te that made
it report whether it thought it could use high resolution timestamps?
Versions of autom4te that didn't recognize
Zack Weinberg wrote:
On Sat, Dec 2, 2023, at 6:37 PM, Karl Berry wrote:
The best way to check if high-resolution
timestamps are available to autom4te is to have perl load
Autom4te::FileUtils and check if that also loaded Time::HiRes.
The problem with that turned out to be that Time
Mike Frysinger wrote:
On 06 Apr 2023 21:29, Jacob Bachmeyer wrote:
Karl Berry wrote:
jb> a more thorough test would locate the autom4te script and grep it
for the perllibdir that was substituted when autoconf was
configured.
I guess that would work.
Challe
Jan Engelhardt wrote:
Given
a_SOURCES = aprog/main.c aprog/foo.c aprog/bar.c aprog/baz.c ...
The more source files there are to be listed, the longer that line gets,
the bigger the Makefile.am fragment becomes, etc. I am thinking about
how to cut that repetition down. Current automake
Karl Berry wrote:
Hi Jacob,
The guess was the two most probable locations: /usr/share/autoconf and
/usr/local/share/autoconf.
Wouldn't have worked on my own system :).
Challenge accepted.
Thanks!
if $PERL -I${autom4te_perllibdir:-$(sed -n \
'/autom4te_
Karl Berry wrote:
jb> The test also guesses the location of autoconf's Perl libraries;
I'm skeptical that any "guessing" of library locations would be reliable
enough.
The guess was the two most probable locations: /usr/share/autoconf and
/usr/local/share/autoconf.
jb> a more
Bogdan wrote:
Jacob Bachmeyer , Mon Apr 03 2023 06:16:53
GMT+0200 (Central European Summer Time)
Karl Berry wrote:
[...]
What can we do about this?
As for automake: can we (you :) somehow modify the computation of the
sleep value to determine if autom4te can handle the HiRes testing or
Karl Berry wrote:
[...]
What can we do about this?
As for automake: can we (you :) somehow modify the computation of the
sleep value to determine if autom4te can handle the HiRes testing or not
(i.e., has the patch installed)? And then use the longer sleep in
automake testing if needed.
A quick introduction to the situation for the Autoconf list:
The Automake maintainers have encountered a bizarre issue with sporadic
random test failures, seemingly due to "disk writes not taking effect"
(as Karl Berry mentioned when starting the thread). Bogdan appears to
have traced the iss
Bogdan wrote:
[...]
Probably Nick's suggestion (a new option to ./configure or the
AC_HEADER_ASSERT macro) would be the most future-proof, but it
requires running ./configure each time you wish to change the build
type (which maybe is not a bad idea, it depends).
That would probably be a ve
Dmitry Goncharov wrote:
On Thursday, February 9, 2023, Tom Tromey wrote:
It's been a long time since I worked on automake, but the dependency
tracking in automake is designed not to need to rebuild or pre-build dep
files. Doing that means invoking the compiler twice, which is slow.
Instead,
Karl Berry wrote:
Hi Jan,
As for GNU/Linux, what was the rationale to only permit [0-9ln]?
No idea. Maybe just didn't think about "m", or maybe it didn't exist at
that time? Jim, Paul, anyone?
Should automake be relaxed?
I see no harm in allowing more (any) letters, if that's what y
Travis Pressler via Discussion list for automake wrote:
Hi,
I'm learning how to make an autotools project and have created a test project
to work with. I ran make with a directory `nested` and then deleted it and
deleted the reference to it in my `Makefile.am`.
Now I'm running ./configure &&
Mike Frysinger wrote:
On 15 Feb 2022 21:17, Jacob Bachmeyer wrote:
Mike Frysinger wrote:
context: https://bugs.gnu.org/53340
Looking at the highlighted line in the context:
thanks for getting into the weeds with me
You are welcome.
echo "$$py_
Mike Frysinger wrote:
context: https://bugs.gnu.org/53340
Looking at the highlighted line in the context:
> echo "$$py_files" | $(am__pep3147_tweak) | $(am__base_list) | \
It seems that the problem is that am__base_list expects ListOf/File (and
produces ChunkedListOf/File) but am__pep3147
Dan Kegel wrote:
Meson is a candidate for such a next-gen config system. It is in python,
which does not quite qualify as usable during early uplift/bootstrap, but
there are C ports in progress, see e.g. https://sr.ht/~lattis/muon/
*Please* do not introduce a dependency on Python; they do n
Billa Surendra wrote:
On Sun, 21 Nov, 2021, 2:28 am Nick Bowler, wrote:
On 20/11/2021, Billa Surendra wrote:
I have RISC-V native compiler on target image, but when I am compiling
automake on target image it needs automake on target. This is the main
problem.
Automake should n
Billa Surendra wrote:
Thanks for your reply. I have installed perl on target system but target
image and build system perl version were different. And second, thing I
have noticed that in aclocal script very first line is #! /bin/perl
A simple workaround is to find perl on the target system
Jim Meyering wrote:
[...]
Even a sample fix for one of the currently-failing tests would be helpful.
This is the first draft; this patch breaks 1.6.1 because versions of
DejaGnu prior to 1.6.3 require srcdir to point exactly to the testsuite,
while 1.6.3 allows the testsuite to be in ${src
Daniel Herring wrote:
It seems fragile for DejaGnu to probe for a testsuite directory and
change its behavior as you describe. For example, I could have a
project without the testsuite dir, invoke the tester, and have it find
and run some unrelated files in the parent directory. Unexpected
b
Karl Berry wrote:
DejaGnu has always required a DejaGnu testsuite to be rooted at a
"testsuite" directory
If something was stated in the documentation, but not enforced by the
code, hardly surprising that "non-conformance" is widespread.
It is not widespread -- all of the toolchain
Jim Meyering wrote:
On Sun, Jul 11, 2021 at 9:03 PM Jacob Bachmeyer wrote:
[...]
The affected tests are: check12, dejagnu3, dejagnu4, dejagnu5,
dejagnu6, dejagnu7, dejagnu-absolute-builddir, dejagnu-relative-srcdir,
dejgnu-siteexp-extend, dejagnu-siteexp-useredit.
[...]
Thank you
I was planning to find a solution with a complete patch before
mentioning this, but since a release is imminent I will just state the
problem: several tests in the Automake testsuite misuse DejaGnu and
fail with the 1.6.3 DejaGnu release as a result.
DejaGnu has always required a DejaGnu test
Bob Friesenhahn wrote:
It is possible to insert additional dependency lines in Makefile.am so
software is always built in the desired order, but this approach might
only work if you always build using the top level Makefile.
This should actually work here: the problem is that a target in doc/
70 matches
Mail list logo
