On Sun, Jun 23, 2024, at 10:23 PM, Zack Weinberg wrote:
> I'm thinking of making AC_RUN_LOG, which has existed forever but is
> undocumented, an official documented macro under the new name
> AC_LOG_CMD. I'm renaming it because I also want to add AC_LOG_FILE, a
> generalization of _AC_MSG_LOG_CONF
Subject: RFC: Add public macros AC_LOG_CMD and AC_LOG_FILE.
FWIW, it sounds good to me. To my mind, logging is one of the most
important features of autoconf, so I'm all for macros to support it
further. --thanks, karl.
On 2024-06-24 10:04, Zack Weinberg wrote:
> On Mon, Jun 24, 2024, at 2:56 AM, Nick Bowler wrote:
>> I think at the same time it would be worth documenting the AS_LINENO
>> functionality, which is the main internal functionality of these
>> macros that (unless you just
On Mon, Jun 24, 2024, at 2:56 AM, Nick Bowler wrote:
> On 2024-06-23 22:23, Zack Weinberg wrote:
>> I'm thinking of making AC_RUN_LOG, which has existed forever but is
>> undocumented, an official documented macro ...
>
> Yes, please!
>
> I will note that Auto
On 2024-06-23 22:23, Zack Weinberg wrote:
> I'm thinking of making AC_RUN_LOG, which has existed forever but is
> undocumented, an official documented macro ...
Yes, please!
I will note that Autoconf has a lot of "run and log a command" internal
macros with various comments
details of why some test got
the result it did in config.log; AC_COMPILE_IFELSE and friends have been
able to do this forever, but hand-written tests of the shell environment
or of interpreters can't without reaching into autoconf's guts.
Automake has been carrying around its own copy of A
[[[ 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'm currently looking at adding support for this to
> https://
[[[ 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 we can ensure
[[[ 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. ]]]
> To avoid false positives if this test is used, we might want to add a
age. This is something distribution
> > maintainers could do without cooperation from upstream. If
> > m4/build-to-host.m4 had been recognized as coming from gnulib and
> > compared to the copy in gnulib, the nonempty diff would have been
> > suspicious.
I hav
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 s
[[[ 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. ]]]
> > Can anyone think of a feasible way to prevent this sort of at
; > sources before building a package. This is something distribution
>> > > maintainers could do without cooperation from upstream. If
>> > > m4/build-to-host.m4 had been recognized as coming from gnulib and
>> > > compared to the copy in gnulib, t
ge. This is something distribution
> > > maintainers could do without cooperation from upstream. If
> > > m4/build-to-host.m4 had been recognized as coming from gnulib and
> > > compared to the copy in gnulib, the nonempty diff would have been
> > >
[[[ 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. ]]]
> > Now for a bit of speculation. I speculate that a cracker w
[[[ 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 would like to clarify that my purpose in starting this thread wasn&
[[[ 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. ]]]
> > Another related check that /would/ have caught this attem
[[[ 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 trivia
lzip maintainer might be interested?
It is also obvious that having GNU distributions available through
only a SINGLE compression format, when that format may be vulnerable,
The xz format is not vulnerable, or at least has not been shown to be so
in the sense of security risks, and only xz-utils
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 re
cooperation from upstream. If
m4/build-to-host.m4 had been recognized as coming from gnulib and
compared to the copy in gnulib, the nonempty diff would have been
suspicious.
True.
Note, however, that there would be some false positives:
True; all of these are Free Software, so a non-empty diff
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 bin
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 dis
On Tue, Apr 2, 2024 at 6:05 PM Karl Berry wrote:
>
> I'm also wondering whether the GNU system should recommend using zstd
> instead of or in addition to xz for compression purposes.
>
> I'm not sure GNU explicitly recommends anything. Although the tarball
> ex
On 4/2/24 16:42, 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
I'm also wondering whether the GNU system should recommend using zstd
instead of or in addition to xz for compression purposes.
I'm not sure GNU explicitly recommends anything. Although the tarball
examples in standards.texi and maintain.texi all use gz, I don't t
ich has the benefit of a very
small implementation and more compact coding than xz uses.
I stopped distributing anything but xz format since that is what almost
everyone was choosing to download.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen
[[[ 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 for un
[[[ 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 trivial attac
[[[ 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. ]]]
> There is not much one can do when a maintainer with signing/release
[[[ 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. ]]]
> There is not much one can do when a maintainer with signing/release
[[[ 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 to pro
[adding in coreutils, for some history]
On Sat, Mar 30, 2024 at 12:55:35PM -0400, Eric Gallager wrote:
> I was recently reading about the backdoor announced in xz-utils the
> other day, and one of the things that caught my attention was how
> (ab)use of the GNU build system played
rom upstream. If
> m4/build-to-host.m4 had been recognized as coming from gnulib and
> compared to the copy in gnulib, the nonempty diff would have been
> suspicious.
True.
Note, however, that there would be some false positives: libtool.m4
is often shipped modified,
a) if the main
> 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
t caught by such
a check, but I want to ensure that we do not end up thinking that we
have a solution and the problem is solved and everyone is happy ... and
then we get caught out when it happens again.
I should clarify also that I think that this proposal *is* a good idea,
but we should remai
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 re
t; > 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 added files.
> >
>
> From what I understand, the xz backdoor would have passed this check.
> The backdoor dropper was hidden in t
Jacob Bachmeyer writes:
> The m4 files were not checked into the repository, instead being added
> (presumably by running autogen.sh with a rigged local m4 file
> collection) while preparing the release.
Ah, yes, I think you are correct. For some reason I thought the
legitimate build-to-host.m4
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, st
Git tag only in the form of added files.
From what I understand, the xz backdoor would have passed this check.
The backdoor dropper was hidden in test data files that /were/ in the
repository, and required code in the modified build-to-host.m4 to
activate it. The m4 files were not c
the three (and counting) malicious patches that they barefacedly
submitted to *other* software and got accepted because the malice was
subtle enough to pass through code review.)
Exactly. :-/
That said, the whole thing looks to me like the attackers were trying to
/not/ hit the more (what i
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
[[[ 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
Eric Gallager wrote:
> What about a 3rd one of these prefixes: "novcs", to teach automake
> about which files belong in VCS or not? i.e. then you might have a
> variable name like:
> dist_novcs_DATA = foo bar baz
> ...which would indicate that foo, bar, and baz are data
On Mon, Apr 1, 2024 at 2:26 PM 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 dis
nario is that the embedded M4 files are not the latest version
> and that the code in configure.ac is not compatible with newer versions that
> might be installed. Setting the --install flag and make every developer
> bootstrap with 'aclocal --install' or anyone trying to bootst
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, sta
"Zack Weinberg" writes:
> I have been thinking about this incident and this thread all weekend and
> have seen a lot of people saying things like "this is more proof that
> tarballs are a thing of the past and everyone should just build straight
> from git". Ther
bout automake's `distcheck`
>> target, whose entire purpose is to make it easier to verify that a
>> distribution tarball can be rebuilt from itself and contains all the
>> things it ought to contain.
>
> The problem is that a release tarball is a freestanding object, with no
&g
> 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.
>>>>
>
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,
assumi
something else, instead of packaging it in the release. The xz-utils
backdoor was smuggled into the repository wrapped in compressed test data.
With a reproducible build system, multiple maintainers can "make dist"
and compare the output to cross-check for erroneous / malicious dist
en
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
ter to put `--install` in
`ACLOCAL_AMFLAGS` or not? Or would such a recommendation be a better
fit for the `automake` manual (since that's where `aclocal` comes
from)?
A common scenario is that the embedded M4 files are not the latest
version and that the code in configure.ac is not compatible with
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 hard
On Sun, Mar 31, 2024 at 3:54 PM Russ Allbery wrote:
>
> Eric Gallager writes:
>
> > Well, other people besides the maintainers can also run `make dist` and
> > `make distcheck`. My idea was to get end-users in the habit of running
> > `make distcheck` themselves befo
Eric Gallager writes:
> Well, other people besides the maintainers can also run `make dist` and
> `make distcheck`. My idea was to get end-users in the habit of running
> `make distcheck` themselves before installing stuff. And if that's too
> much to ask of end users, I'
; >>> these checks as well, then?
> >>
> >> The first mentioned check can not be automated. ...
> >>
> >> The second mentioned check could be done by the maintainer, ...
> >
> >
> > I agree that distcheck is good but not a cure all. An
> [...]
>> 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 t
tered, automake or not, would not have mattered. The individual
could have sneaked in code changes into the release tar-ball just as
well -- Github presented two sets of files one could download (direct
from git, and "release").
The deviousness of this backdoor should not be understated, it was
> It is not yet clear if the
> maintainer intentionally did this, or if the changes were introduced via
> a compromise of his computer.
I think it is pretty clear by now. [1][2][3]
There is a bit more to it all than just this -- the maintainer wasn't
responsible (Lasse Collin), the
something intentionally wrong.
My GraphicsMagick oss-fuzz builds include xz and are still working (but
with a few security issues open due to problems in xz). The URL used is
https://github.com/xz-mirror/xz. When I visit that URL, I see this
message "This repository has been archived by the
Bob Friesenhahn wrote:
> It is not yet clear if the
> maintainer intentionally did this, or if the changes were introduced via
> a compromise of his computer.
I think it is pretty clear by now. [1][2][3]
[1] https://boehs.org/node/everything-i-know-about-the-xz-backdoor
[2] https://news.ycombin
oot
off secure media and then use the tools in it to look for the rootkit in
the potentially-compromised system, *without* handing control over to
it.
I am on the oss-security mailing list where this issue was perhaps first
publicly reported, and has been discussed/analyzed furiously.
My fi
y the maintainer, ...
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 that data. In this case,
ify that a
distribution tarball can be rebuilt from itself and contains all the
things it ought to contain.
The problem is that a release tarball is a freestanding object, with no
dependency on the repository from which it was produced. In this case,
the attacker added a bogus "update" of b
On Mar 30, 2024, Eric Gallager wrote:
> automake's `distcheck` target, whose entire purpose is to make it
> easier to verify that a distribution tarball can be rebuilt from
> itself and contains all the things it ought to contain.
> Recommending the `distcheck` target to a
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.
With a reproducible build system, multiple maintainers can "make dist"
and compare the output to cross-check for erroneous / malicious dist
environm
` target be updated to perform
> these checks as well, then?
The first mentioned check can not be automated. It can only be done by the
maintainer / release manager, reviewing the list of added files and matching
them against the list of added features or tests since the last release.
The s
On Sat, Mar 30, 2024 at 5:41 PM Bruno Haible wrote:
>
> Eric Gallager wrote:
> > Recommending the `distcheck` target to a wider variety of users would
> > help more projects catch mismatches between things a distribution
> > tarball is supposed to contain, and things
Eric Gallager wrote:
> Recommending the `distcheck` target to a wider variety of users would
> help more projects catch mismatches between things a distribution
> tarball is supposed to contain, and things that it isn't.
While 'make distcheck' detects some of these mismat
hat's still rms (for anything
substantive)
FWIW, I expect that few users would actually run make distcheck,
regardless of anything in the GCS. And of those that do, I suspect
there would be many failures because make distcheck is a complex target
that is not, so far as I understand it, intended to
I was recently reading about the backdoor announced in xz-utils the
other day, and one of the things that caught my attention was how
(ab)use of the GNU build system played a role in allowing the backdoor
to go unnoticed: https://openwall.com/lists/oss-security/2024/03/29/4
Specifically, what
x27;s ok.
I have not systematically looked for typos in any of the
"New in ..." sections older than 1.17.
I ran a spell checker and nothing obvious showed up. Not that that's
conclusive, but it will have to do :). --thanks, karl.
upported, a new line `Features: subsecond-mtime' is printed by
-automake --version (and autom4mte --version). (bug#64756, bug#67670)
+automake --version (and autom4te --version). (bug#64756, bug#67670)
- The default value of $ARFLAGS is now "cr" instead of "cru",
On Saturday 2022-11-19 09:11, madmurphy wrote:
>I guess it does make sense. But then what might be missing to Automake are
>libXXX_la_AM_CFLAGS, libXXX_la_AM_CPPFLAGS and libXXX_la_AM_LDFLAGS
>variables, in which the global AM_CFLAGS, AM_CPPFLAGS and AM_LDFLAGS are
>automatically pas
I guess it does make sense. But then what might be missing to Automake are
libXXX_la_AM_CFLAGS, libXXX_la_AM_CPPFLAGS and libXXX_la_AM_LDFLAGS
variables, in which the global AM_CFLAGS, AM_CPPFLAGS and AM_LDFLAGS are
automatically pasted (whereas the corresponding versions without the AM_
prefix
On Friday 2022-11-18 22:57, Russ Allbery wrote:
>madmurphy writes:
>
>> However, if at the same time I set also the libfoo_la_CPPFLAGS variable (no
>> matter the content), as in the following example,
>
>> AM_CPPFLAGS = \
>> "-DLIBFOO_BUILD_MESSAGE=\"correctly defined via AM_CPPFLAGS\""
>>
_CPPFLAGS = \
>"-DLIBFOO_DUMMY=\"This is just a dummy text\""
> the AM_CPPFLAGS variable will be completely overwritten by the
> libfoo_la_CPPFLAGS variable, and invoking libfoo_func() will print
> Message from the build system: undefined
While this is ofte
quot; LIBFOO_BUILD_MESSAGE "\n");
return 0;
}
and then I set the LIBFOO_BUILD_MESSAGE preprocessor macro via Makefile.am,
AM_CPPFLAGS = \
"-DLIBFOO_BUILD_MESSAGE=\"correctly defined via AM_CPPFLAGS\""
invoking libfoo_func() from a linked program will correc
Hello Alex,
On 28.03.2022 4:55, Alex Ameen wrote:
This is a message I meant send to "all", I'm sending again for the wider
discussion.
Please let me know if my understanding of include order is incorrect.
Essentially I'm more concerned about relative placement of `AM_CPPF
ep is to write bug-standa...@gnu.org and suggest
clarifying the status of CPPFLAGS, its relationship to CFLAGS, etc.
Definitely makes sense.
I'll write to the standards list.
We could consider changing automake to follow autoconf even if the GCS
is not changed, but it would be better if th
This is a message I meant send to "all", I'm sending again for the wider
discussion.
Please let me know if my understanding of include order is incorrect.
Essentially I'm more concerned about relative placement of `AM_CPPFLAGS'
and `CPPFLAGS' in any future changes.
ample descriptions where CPPFLAGS comes after CFLAGS/FFLAGS/etc.,
and sometimes reversed.
I think that this is because it was always assumed that the order does
not matter.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,
r otherwise,
at least that's the way make comes across. Some software will just
break on `make CFLAGS=-O3` and others will work to compile.
As for automake, AM_CPPFLAGS was introduced at the same time as AM_CFLAGS as
per the git log. So CPPFLAGS always was a user variable.
>[more on CFLAGS
iables
does not clearly state it one way or another. But its example shows
CFLAGS after CPPFLAGS.
Thus I think a prior step is to write bug-standa...@gnu.org and suggest
clarifying the status of CPPFLAGS, its relationship to CFLAGS, etc.
We could consider changing automake to follow autoconf even if
Hello,
This discussion was started initially in the autoconf list. [1]
Automake and autoconf use compiler and preprocessor flags in different
order.
Within 'configure' scripts, compile checks/tests are performed as [2]:
$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&AS_M
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_tweak emits ListOf/Glob.
This works in the usual case because the shell implicitly converts Glob
-> ListOf/File a
FWIW, commandline length limits are a real thing, I've run into them
with Make, CMake, and Meson.
I did some work to help address them in Meson, see e.g.
https://github.com/mesonbuild/meson/issues/7212
And just for fun, here's a vaguely related changelog entry from long
ago, back when t
$(am__base_list) | \
> It seems that the problem is that am__base_list expects ListOf/File (and
> produces ChunkedListOf/File) but am__pep3147_tweak emits ListOf/Glob.
> This works in the usual case because the shell implicitly converts Glob
> -> ListOf/File and implicitly fl
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 ChunkedLis
If anyone who weighed in on the Python prefix stuff (or didn't, for that
matter) has a chance to try the new pretest at
https://meyering.net/automake/automake-1.16g.tar.xz
that'd be great. It'd be nice not to have to do another patch-up release.
Thanks,
Karl
hon values.
The --with-python_[exec_]prefix options are still present and
unchanged, setting the prefixes explicitly.
It would be really fantastic if there could be some testing of this by
other people before we push out another problematic release.
Jim, could you roll a test release please? --th
I think we need an easy way to set a default for this behaviour
from within configure.ac, similar to AC_PREFIX_DEFAULT(), so that
the end-user doesn't have to pass a bunch of options to configure
just to get the build to work sensibly.
I have nothing against the idea, but my immedi
On 21-08-25 10:00, Karl Berry wrote:
| yf> Would keeping PYTHON_PREFIX but changing its default to the
| "classical" value be a working solution for this ?
|
| Yes, I think we should. And I think I should have been smart enough to
| realize that changing the default
yf> Would keeping PYTHON_PREFIX but changing its default to the
"classical" value be a working solution for this ?
Yes, I think we should. And I think I should have been smart enough to
realize that changing the default behavior was too risky in the first
place. Apologies
On 2021-8-25 10:14 , Karl Berry wrote:
Ok, I guess we'll have to revert the Python change and make another
release. I was worried about the change. But I am not sure of how best
to deal with the intended benefits.
Joshua, can you please take a look at these reports and advise?
Hello,
Would keeping PYTHON_PREFIX but changing its default to the "classical" value
be a working solution for this ?
Best regards,
Yvan
Le 25 août 2021 07:08, j...@macports.org a écrit :
On 2021-8-25 10:14 , Karl Berry wrote:
> Ok, I guess we'll have to revert the Pyth
Ok, I guess we'll have to revert the Python change and make another
release. I was worried about the change. But I am not sure of how best
to deal with the intended benefits.
Joshua, can you please take a look at these reports and advise?
https://lists.gnu.org/archive/html/automake/20
1 - 100 of 2185 matches
Mail list logo
