Hi Alexandre,
I'm cc:ing you often these days.
It's nice to be included :).
The discussion is about introducing a `make html' target to Automake.
Good.
AFAICT `makeinfo --html --no-split' creates file named `mumble.html',
while `makeinfo --html' creates a directory named
comes from the Gnits standards.
There is no such thing as Gnits standards. I was/am a founding member
of gnits (which was just a few friends talking informally), and I can
state this authoritatively :).
Before automake existed, there were various
autoconf/installation/etc. conventions that
Perhaps you should tell the people behind:
The gnit-picker gang, like I said, was a few friends, not an official
group of any kind. I was one of them.
http://www.amath.washington.edu/~lf/tutorials/autoconf/gnits/gnits.html
Ah. It's been enough years that I'd forgotten that François
| This is TeX, Version 3.14159 (C version 6.1) (format=tex 98.7.5) 21 AUG 2003
20:18
Yes, this version of TeX predates --help and the like, so TeX just takes
the string as input.
If you feel like updating your TeX installation, check
http://tug.org/tetex or http://tug.org/texlive.
So
Doesn't pretty much every distribution use /usr/share/doc for this and
other package documentation at this point?
Sure, many distributions do this, on a per-package per-version basis as
far as I know. /usr/share/doc/emacs-21.2, etc. The distribution makers
do it all themselves, it's
I wonder if tools similar to gettext exist for manuals?
FWIW, I have never seen any. Something based on wdiff might be better
than straight diff.
E.g., does `info' supports several translated versions of a manual?
There is no special support for translations in the Texinfo system.
John Darrington (cc'd here), who maintains the GNUbik package, made this
suggestion:
With the new ftp upload procedures, shouldn't the automake targets be
changed appropriately? In particular:
The dist target should generate the package.tar.gz.asc file and the
dist-check target should
gnupload --help has this example:
gnupload ...
--to alpha.gnu.org:automake \\
...
I suggest changing it to:
--to alpha.gnu.org:gnu/automake \\
Otherwise, there is a possible confusion that gnupload puts in the
gnu/ for you. (This confused me for a while,
Personally, I'd be happy if gnits disappeared from automake completely,
except for being invisibly implemented as a synonym for `gnu'. Does it
really serve a purpose any more?
Even those of us who were/are part of the actual gnits group no longer
use that option.
Thanks,
Karl
I've been looking through the manuals and code, but not finding a
definitive answer: is there a canonical/recommended ordering of running
the autotools, including automake?
I've been using aclocal - autoheader - automake - autoconf for years,
but have no idea any more where I got that ordering.
+You may be tempted to use @code{install-data-local} to install a file
+to some hard-coded location, but you should avoid this.
+(@pxref{Hard-Coded Install Paths})
Shouldn't the period be moved from after this to after the closing
parenthesis?
Yes.
+With the
Hi Ralf and everyone,
I received a suggestion to mention gnupload in the GNU maintainers
manual, since it's the easiest way (that I know of, anyway) to upload
files to ftp.gnu.org and alpha.gnu.org.
However, there is one issue I felt should be mentioned to do so: the
dependency on ncftpput.
1) do you have any interest in eliminating the dependency on ncftpput?
Sure.
So perhaps the best outcome would be for gnupload to use ftp itself,
instead of ncftpput? Ie, this stuff could become a function in
gnupload?
Failing that, perhaps gnupload could use a variable, e.g.,
:
Not sure whether ftp is universally available, though.
A lot more universally than ncftpput, I expect.
If you want me to prepare a patch, I'll try. If you'd rather not bother
with it, I'll just write about putting the replacement script into
gnulib. I don't have strong feelings about it
Just to resolve this ...
I guess I'll just upload my ncftpput replacement script elsewhere.
It's not worth any of our time to prolong the discussion.
Thanks,
k
Karl, what do you think about this rewording
The second hunk adds real information, so I'll go ahead and install that.
The first hunk, though, I just can't agree with, and I feel pretty sure
that rms would not approve of such a change either. Helpless is a
good description of people faced
it addresses an issue that
some people may not know about, so maybe it would be good to briefly
explain further?
I agree, thanks. I changed the text to look like this:
By default, the Make rules should compile and link with @samp{-g}, so
that executable programs have debugging
- The long-obsolete (since automake 1.10) AM_PROG_MKDIR m4 macro will
next major Automake version (1.13):
Yes, well, speaking of AM_PROG_MKDIR. We don't use it explicitly in
Texinfo. But I get the warning about it every time I rerun
automake, because our configure.ac includes the
Stefano and all,
It would be nice to able to list directories in EXTRA_DIST. It is
painful and unnecessary overhead to list every file in a contrib
directory individually just to avoid including VC files. (As explained
at
that every tar (except maybe really ancient ones, can't remember, but we
don't care) supports the -style.
It would be nice to verify this claim on as much systems as possible
Certainly POSIX has always required supporting -options, which is some
15 years old at least. Or do I mean
That is already possible:
http://www.gnu.org/software/automake/manual/automake.html#The-dist-Hook
I see. Given this, I propose merely changing the definition of am__tar
to use variables. Something like:
am__tar = $(TAR) $(TAR_OPTIONS) - $$tardir
where the actual definitions of TAR and
OTOH, what about distribution tarballs in '.zip' format? They don't
use tar at all ... Time to deprecate them maybe? Is anybody actually
using them? And while at it, what about the even more obscure 'shar'
format?
FWIW, I think they should still be supported. I see recent
Especially for packages which run make check in several subdirectories
(e.g., texinfo), Nelson Beebe made the suggestion that it would be
helpful if there was an overall textual report of success or failure,
and not just the exit status. Something like ALL TESTS PASSED
vs. FAILED TESTS. Leaving
This would require to change the 'check-recursive' targets not to
share the same code with the other '*-recursive' targets. I really
don't want to go there.
Totally reasonable :).
The best solution is on the user-side IMHO: fix the build system to
use less (ideally none)
With a non-recursive, top level Makefile. Quick example:
So, replace a nicely separated source setup with munging together the
information about everything in one place? Thanks for the suggestion,
but that seems like a major step backwards in maintainability to me, so
I'll decline. Life
1.00rc0
Personally, when I see a version number like that, I'm never sure what
it means. Probably the first rc leading up to 1.00, but maybe it is an
rc for 1.01 after 1.00. And suffixes sort badly in long lists (see,
e.g., http://ftp.isc.org/isc/bind9/). Anyway. Not trying to change
your
Question: how best to respect --program-suffix, --program-prefix,
--program-transform-name in user-defined rules for installing?
Details: For Texinfo, I install makeinfo as a symlink to texi2any in the
install-exec-hook (like the example in the Extending node of the
automake manual):
Hello Automake folks,
The last Automake release was not that long ago (December 2013), but
Stefano (Lattarini) has mentioned that his time for Automake has become
extremely limited; likewise with the other two current maintainers, Ralf
Wildenhues and Jim Meyering.
So we're hoping that some
>I might be missing something, but I get that behavior in my automatic
>builds by calling 'make check VERBOSE=1'.
This does not appear to have any effect when using the TAP framework.
So it seems. From grepping the installed automake, I see VERBOSE used
in exactly one line of
I might be missing something, but I get that behavior in my automatic
builds by calling 'make check VERBOSE=1'.
Yes! Thank you!!
After make check runs, if there were any failures, I'm wishing for a way
to have automake to automatically show the relevant test-suite.log.
The post at https://stackoverflow.com/questions/20961959 suggests that
the only way to do this is to modify the test-driver script. Is that correct?
There
It seems the VERBOSE variable is documented in only two places in
automake.texi, and neither place gives examples:
In Parallel Test Harness
If the variable @samp{VERBOSE} is set, this
file is output after the summary.
In Overview of Custom Test Drivers Support:
use of @code{VERBOSE}
The automake test t/txinfo-vtexi4.sh failed when localtime and UTC were
on different days, resulting in the GREPDATE for the @UPDATED@ string
not matching (among possible others).
mdate-sh always uses TZ=UTC0. This tiny change makes the test do the
same thing.
I wondered if there were other
Hi Jefferson,
Thanks for this suggestion from May 2018 (oops).
Date: Thu, 31 May 2018 22:44:45 +
From: Jefferson Carpenter
To: automake-patc...@gnu.org
Subject: minor docs alteration
-The build tree is rooted in the directory in which @file{configure}
+The build tree
Hi Mathieu - I'm glad you replied. I saw in the ChangeLog that you
created AUTOMAKE_UNINSTALLED :). The general idea was clear, but all the
implications, not so much.
Here is a patch that seem to fix the issue, I have added some clutter to
AM_TESTS_ENVIRONMENT
Thanks! make distcheck now
The aclocal-print-acdir.sh test fails at the make installcheck step of
make distcheck (it succeeds in the normal make check, and it succeeds at
the make check of make distcheck; only fails in the make installcheck).
This is because AUTOMAKE_UNINSTALLED is (correctly) set in the
environment at
Looking at the automake-patches that have accumulated, I saw one to
improve the error message if dependency tracking fails. Copied below.
It seems generally sensible to me, though I would change the wording a
little, and there is a spurious "the", so, revising the proposed text:
Hi Zack - in addition to the other replies, how do you prefer to do the
sync? (which it seems like we might as well do asap.) From am to ac, or
from ac to am?
I don't think it makes much difference, and am happy with either
direction. I admit I'm also not sure offhand how to integrate it with
The second set, applicable to automake, is additional tweaks I needed
to make to the automake testsuite to get it to pass 100%.
Thanks much (again and again), Zack. Certainly looks fine to me. Please
go ahead and commit to automake at your convenience. --happy hacking, karl.
The use of automake per se has no dependency to coreutils, does it?
No.
There is any way to obtain the path of one directory relative to
another in automake without adding a new dependency? "realpath"
implemented as a m4 macro, maybe?
Sorry, I'm clueless. Anyone else out there
suggests that it can be scripted in portable shell (
So it seems, although:
current="${2:+"$1"}"
target="${2:-"$1"}"
... etc...
all these myriad fancy variable substitutions would have to be replaced
with sed, or something ... --thanks, karl.
./configure: line 2489: Report: command not found
./configure: line 2490: _ACEOF: command not found
./configure: line 2492: syntax error near unexpected token `fi'
./configure: line 2492: `fi'
Evidently this is something about this project's configure.in. I don't
see it offhand
Hi Marius,
Makefile.am:86: warning: pkglibdir was already defined in condition
TRUE, which includes condition USE_VERSION_LINKS ...
All I can think of to do is introduce a new variable in each branch, and
define the "built-in" variables outside the conditional. Unfortunately
this means
Guess the macro never really worked?
AC_CONFIG_AUX_DIR is used in almost every package. For example,
Texinfo's configure.ac starts as below. As the comment there says,
maybe you were using it after AM_INIT_AUTOMAKE?
AC_INIT([wifidog], [1.3.0])
...
AC_INIT(src/common.h)
You're calling AC_INIT twice. That doesn't seem like it can be good,
althogh I'm not sure it is the cause of the error. (Seems like it would
be too easy.)
Also:
AM_INIT_AUTOMAKE# (wifidog,$WIFIDOG_VERSION)
Don't put #
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 don't think Zack plans to release a new Automake.
Hi Tom,
Using this:
As shown in the Texinfo example, I think the order of the init and
config macros is important. Admittedly this is not clearly documented.
AC_INIT([...
AC_CONFIG_AUX_DIR([...
AM_INIT_AUTOMAKE([...
AC_CONFIG_HEADERS([...
AC_CONFIG_SRCDIR([...
Some variations are possible,
Hi - sorry for the absurdly delayed reply. Almost a year ago, you wrote
to this list about prepending a + to link lines:
Date: Tue, 18 Feb 2020 16:47:05 +0100
From: "R. Diez"
To: automake@gnu.org
Subject: Prepending '+' to the recipe line when linking with GCC's
They all appear to be cases of autoconf and/or aclocal
getting run when the test suite does not expect them to be run. I am
stumped as to why
In short: because the 2.70 autom4te decided not to update configure.
I don't know why not, but I have a guess: maybe the new autom4te ignores
The attached patch fixes two of the problems:
Thanks, I pushed that.
There are still four testsuite failures on my dev box,
After applying your patch, running make -j12 check against autoconf 2.70,
I get those failures and several more (as in your case, they don't
appear with 2.69):
FAIL: t/distcheck-missing-m4.sh
FAIL: t/distcheck-outdated-m4.sh
FAIL: t/libobj-basic.sh
FAIL: t/remake-not-after-make-dist.sh
FAIL: t/vala-non-recursive-setup.sh
Whoops, I see the vala test is the only one you didn't also get,
the rest are duplicates. Sorry for the noise.
raise the minimum version requirement for Perl to 5.18.0
Sounds sensible to me, for the reasons you outlined.
But, I think it would be wise to give users a way to override the
requirement, of course with the caveat "don't blame us if it doesn't
work", unless there are true requirements such
I'd just like to suggest that in the event of future significant
development on a new automake, or a revamped build system in whatever
way, that the new system not be called "autoconf" or "automake".
It seems inevitable to me that any such new system would have
incompatibilities with the old, and
I think automake really needs to support this soon.
Sounds reasonable to me, but to be clear, Automake will only support
things that volunteers care enough about to actually dig into the
code and write patches for. New developers/maintainers are needed.
As I previously explained(*) /
Hi Yvan - sorry for the delayed reply.
While configure/automale/libtool seem to be designed to work together,
Yes, they were. It seems your major issues are with libtool. I can
(uselessly) sympathize, but unfortunately that's all I can do. Libtool
is currently unmaintained (according to GNU
Hi Johan,
make --dry-run --always-make
I'm somehow amazed these two options work together at all. They seem
mutually unintelligible. In any case, it's the first time I've heard of
this, so I don't have a best (or any) practice to suggest. Sorry.
Maybe someone else here has some ideas.
I
So I beleive the conclusion here is that "--always-make" is not
really compatible with autotools at the moment (or perhaps
self-referential makefiles in general?)
Sounds plausible to me.
I'll add a note in the automake manual about this. Can't think of
anything else feasible to do.
I imagined an option to specify files that are not distributed by
default.
Sounds reasonable. Such an option doesn't sound too hard to implement,
if you or anyone are up for writing a patch. Unfortunately, I'm not
likely to get to it any time soon, if ever :(. --thanks, karl.
Would it make sense only to include this file if a _TEXINFOS variable
e.g. info_TEXINFOS is set in Makefile.am?
It sounds sensible, although I admit trying to discern whether any
_TEXINFOS var is set anywhere in the source tree is something I've never
looked into. So it's nothing I'm
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.
Anyway, it seems like an unfriendly requirement for users. And even
For about the last year, I've been the main person applying bug fixes to
(or at least reading bug reports for) Automake. My pace has been quite
slow, but since maintenance was almost completely lacking for some years
before that, I've been doing what I could. Mainly, going through the old
bug
1. $(...) breaks Solaris 10 /bin/sh.
2. Solaris 10 is still supported by the vendor, and people still use it
with GNU tools.
3. There is no technical benefit to $(...) in config.*.
What's the harm in using `...` a few more years in config.*?
Answer, as far as I can see: none. -k
At some point, failing to support $(...) is in the same ballpark
FWIW, I fully disagree. (Along with, it seems, everyone else except
you and Ben.)
1) There is no actual benefit to using $(...) over `...`.
It is purely cosmetic. In other scripts, fine. In config.*, no.
2) Using $(...)
Hi Dmitry,
I tried to reach the author of that change [2], but, unfortunately,
received no response.
Ben's lack of response is no reason not to revert this
unportability. After all, one steps down from maintainership in order
not to spend time thinking about it any more.
Clearly Ben had
Hi Laurence - sorry, but I can't imagine how to automatically correct
version mismatches. The possible problems are both unpredictable and
endless, seems to me. Maybe others here have some more useful
idea. --best, karl.
Hi Nick - thanks for the reply on this. It all sounds sensible.
Finally this issue could also probably be solved by changing GNU make
itself: providing another mechanism to keep jobserver fds open in rules.
Clearly that would be great.
On the Automake side, I just don't have the desire
I think the right thresholds are 5.10 for absolute minimum and 5.16
for 'we aren't going to test with anything older than this'
I appreciate the effort to increase compatibility with old versions.
I imagine you could provide Digest::SHA "internally", or test for it as
Nick suggested, but
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
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?
Subject: [PATCH v2] automake: add install dep on install-libLTLIBRARIES to
all
targets
Thanks. Have you run make check? (In practice, make -j12 check or similar.)
Always good to make sure nothing old breaks ... -k
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 for that.
My
Hi Jan and all.
depending on install-libLTLIBRARIES not just for bin_PROGRAMS, but
all PROGRAMS and LTLIBRARIES.
I installed your patch (for the record: the thread starts at
https://lists.gnu.org/archive/html/automake/2021-08/msg00016.html).
Thanks much.
(Now, on another and unrelated
Regarding PYTHON_PREFIX setting in automake, I've pushed a change that
(I hope) reverts to the previous behavior of using the usual GNU prefix
variables by default. It's attached.
The new configure option --with-python-sys-prefix yields the
the 1.16.4 behavior of using the sys.* Python values.
Hi Nick, Jan, all,
nick> I think all that should be needed is to list the .l (or .y) file in
_SOURCES normally
Thanks much. I was thinking I should avoid that since the .[ly] are not
ultimate sources, but if it works, fine with me.
jan>
BUILT_SOURCES = foo.y
foo.y: foo.cweb
Redoing the tests with 1.16g I now have 9 failed tests, the
testsuite.log is attached.
Thanks much for giving it a whirl right away.
But are those failures anything new?
FAIL: t/fn99subdir
FAIL: t/lex-clean-cxx
FAIL: t/lex-depend-cxx
FAIL: t/test-extensions-empty
FAIL: t/subpkg
FAIL:
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
Suppose I want to generate a lex or yacc input file from another file,
e.g., a CWEB literate program. Is there a way to tell Automake about
this so that the ultimately-generated parser/lexer [.ch] files are saved
in srcdir, as happens when [.ly] are direct sources, listed in *_SOURCES?
I should
Does anyone here use or know of an active system where plain
rm -f
with no arguments fails? I mean, exits with bad status?
We are considering changing Automake to assume this works,
although we'd provide for a workaround just in case, something like
make RM_F="rm -f nosuchfile"
But if there
bf> I thought that systems deriving from OpenSolaris (e.g. Illumos,
...
However, testing in an empty directory on a system without the
upated ksh93 this looks ok to me:
Bob, what you wrote before (approx. a year ago) is here:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42529
It seems the basic inconsistency is whether CPPFLAGS is considered a
"user variable" or not. In earlier eras, it wasn't, but from your msg,
I gather it is now.
The GNU standards node about it, that you mentioned,
https://www.gnu.org/prep/standards/standards.html#Command-Variables
does not
Hi Mike,
https://www.gnu.org/software/automake/manual/index-full.html
It looks nice, but the plethora of versions becomes rather an
undifferentiated mass. Maybe make each major release its own
, as in:
Automake 1.16 releases:
1.16* versions
Automake 1.15 releases:
1.15* versions
Just
per your request, the default is unchanged.
I understand (and thanks), but my question was about the "table"
(whether it's actually a or not):
* (Feb 2018) GNU Automake 1.16 (HTML PDF)
* (Dec 2014) GNU Automake 1.15 (HTML PDF)
* (Jun 2013) GNU Automake 1.14 (HTML PDF)
On what page were
* i'm assuming that we don't want to modify lib/gendocs_template
since it's synced with upstream gnulib
For sure.
so the default manual/ landing page & manual will be unchanged from today
other than having a link to the full versioned index
What url/filename are you
> https://www.gnu.org/software/automake/manual/index-full.html
It's better, but how about a non-blank line?
(does obey table cells? I'm never sure.)
Obviously we're getting down to trivialities, feel free to ignore :).
so i guess once gnulib merges my update,
If nothing happens
i was planning on the full index being maintained here:
https://www.gnu.org/software/automake/manual/index-full.html
Sounds good.
>>See the [full version index] for other versions of the manual.
Good. Maybe something like:
>>See the [full version index] for the manual for
Having multiple versions of the manual online sounds all to the good to
me. As long as it's being done at all, I wouldn't hesitate to put up
the manuals for every release, not just the major releases. For 1.16.x,
I'm afraid I rather broke the previous rules for major releases anyway.
Hi Mike,
the ACLOCAL_PATH functionality is useful (adding search dirs after -I),
but a bit unwieldy as an env var. any reason we can't add a command line
option for this ?
Seems like a fine idea to me.
call it --aclocal-path ? or --extra-system-acdir ?
Reading the doc, my
* the current page, but with an entry/link like "For older manuals,
please see this index."
Agreed this is preferable. Not a fan of the gcc index page.
changes to the manual the rename or reorder chapters, we're breaking
those historical links.
Reordering isn't a problem; that
i would like to help coordinate these downstream distros so they don't have
to keep all repeating the same work. basically:
Sounds sensible to me.
* commits are on a volunteer/request basis -- there is no
expectation that people working on master/whatever think about
Hi Anton - thanks for the report.
https://github.com/HDFGroup/hdf5/issues/366
with the solution that "-Wl," must be prepended somehow to "-soname".
Why do you think this is not a libtool issue? Isn't it libtool's job to
figure out the arguments that need to be passed? The fact that the
While libtool has a new maintainer (Alex Ameen), essentially nothing
happens, which is quite unfortunate...
1) libtool 2.4.7 was released in March 2022 (I don't know if Alex did
it), which isn't so terribly long ago. Sure, maintainers should at least
confirm bug reports and patches, even
Fancy doing it? Jim agreed :)
Yeah, sorry. Other priority things have intervened :(.
I have a mild hope of getting to it by tomorrow.
If someone else wants to make the commit, certainly fine by me :). -k
I was going to bisect but if it doesn't fail for me in the first place... :(
Thanks. Indeed, reconfiguring etc. got rid of those errors.
Now a bunch (12) of the Python tests are failing for me, presumably
because of previous Python changes not playing nicely with my older
Python version
Unrelated to Jan's depend.am change, but it turns out that a previous
change broke make distcheck (768 failures). I don't feel right about
committing anything else until that is fixed.
Error below. Jim (or anyone), can you easily advise? I haven't delved
into this part of things before. (Not sure
automake --verbose --warnings=all --add-missing --copy
Since you're talking about cron, I'm guessing the terminal output is
being redirected to a file? Because if it's going to an actual tty, that
can consume a surprising amount of time.
Is there a way to speed 'automake' up?
Only real
- @echo '# dummy' >$@-t && $(am__mv) $@-t $@
+ @: >>$@
1) does it actually speed anything up?
2) without the mv I fear we are no longer noticing write failure. -k
I see no reason why mv would be so crucial.
Hmm, I guess you're right. Thanks for the analysis.
The purpose of the stamp files is to avoid partial files being written
(and screwing up future makes), but if the file is zero bytes, it seems
that problem cannot happen.
Jim, do you agree? I'll
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 you mean.
When
The appended patch should address both issues.
Thanks Zack!! I installed the changes (separately).
Note that I have only tested it with Python 2.7 and 3.6. It _may_
not be correct for Python in the 3.0--3.3 (inclusive) range
I didn't test any of those versions either. Certainly
Is anyone up for debugging some Python-related test failures on
RHEL-based systems?
Mike Vapier from gentoo made many improvements to the Python support.
(Mike, if you're still out there, would love to hear back.)
Unfortunately, the end result is that 13 tests (listed below) now fail
for me on
1 - 100 of 645 matches
Mail list logo
