This reply should have been sent to the autoconf list rather than
directly to Eric. The below is what I sent to Eric:
On Thu, 1 Mar 2012, Eric Blake wrote:
The Autoconf team is considering releasing only .xz files for 2.69; if
this would be a hardship for you, and you need the .gz or .bz2
Hi!
On 03/02/2012 05:45 AM, Eric Blake wrote:
The Autoconf team is considering releasing only .xz files for 2.69;
if this would be a hardship for you, and you need the .gz or .bz2
release, please speak up now.
I want to second Bob Friesenhahn's opinion that it would be nice to keep
at least
Bob Friesenhahn wrote:
This reply should have been sent to the autoconf list rather than
directly to Eric. The below is what I sent to Eric:
On Thu, 1 Mar 2012, Eric Blake wrote:
The Autoconf team is considering releasing only .xz files for 2.69; if
this would be a hardship for you, and
On Fri, 2 Mar 2012, Jim Meyering wrote:
If you can demonstrate a portability problem, please provide details.
From what I've heard (distributing xz-only compressed tarballs of
coreutils, grep, diffutils, parted, etc.) there have been no
problems building xz from source on the few systems for
Bob Friesenhahn wrote:
On Fri, 2 Mar 2012, Jim Meyering wrote:
If you can demonstrate a portability problem, please provide details.
From what I've heard (distributing xz-only compressed tarballs of
coreutils, grep, diffutils, parted, etc.) there have been no
problems building xz from source
On Fri, 2 Mar 2012, Jim Meyering wrote:
It does not successfully build using GCC on my Solaris 10 system, and
not even with the workaround described in the INSTALL file.
Did you report it?
Yes.
I've been building xz on sparc Solaris 10 with gcc since
back when the program was called lzma.
On 03/02/2012 05:45 AM, Eric Blake wrote:
The Autoconf team is considering releasing only .xz files for 2.69;
if this would be a hardship for you, and you need the .gz or .bz2
release, please speak up now.
Would only having xz introduce a chicken-and-egg bootstrapping
problem? I notice
On 03/02/2012 10:24 AM, Jim Meyering wrote:
Bob Friesenhahn wrote:
On Fri, 2 Mar 2012, Bob Friesenhahn wrote:
I tried to test how much peak memory 'xz' uses to decompress the
autoconf tarball but was (apparently) defeated by the strange way
that 'xz' is linked. I will try again with a
Jim Meyering wrote:
Bob Friesenhahn wrote:
On Fri, 2 Mar 2012, Bob Friesenhahn wrote:
I tried to test how much peak memory 'xz' uses to decompress the
autoconf tarball but was (apparently) defeated by the strange way
that 'xz' is linked. I will try again with a different tool this
weekend.
On 03/02/2012 09:54 AM, Bob Friesenhahn wrote:
the available computers might be donated computers
from the late '90s or early 2000s
Well, I dunno, I doubt whether this is much of a
third-world issue; it's more of an backwater
first-world issue. Let me try to explain.
At UCLA we often get
On Friday 02 March 2012 11:09:13 Olaf Lenz wrote:
On 03/02/2012 05:45 AM, Eric Blake wrote:
The Autoconf team is considering releasing only .xz files for 2.69;
if this would be a hardship for you, and you need the .gz or .bz2
release, please speak up now.
I want to second Bob
Bob Friesenhahn wrote:
On Fri, 2 Mar 2012, Jim Meyering wrote:
It does not successfully build using GCC on my Solaris 10 system, and
not even with the workaround described in the INSTALL file.
Did you report it?
Yes.
Since it involves Solaris' ld, it's harder to reproduce
and work
On Fri, 2 Mar 2012, Mike Frysinger wrote:
uhh, Sabayon does have xz-utils and has for quite a long time now. after
all,
it's simply Gentoo at its core, and Gentoo has had xz-utils for a long time.
openSUSE has had xz-utils since 11.2. before that, they had lzma-utils.
so do you have
On Friday 02 March 2012 16:41:24 Tim Rice wrote:
On Fri, 2 Mar 2012, Mike Frysinger wrote:
uhh, Sabayon does have xz-utils and has for quite a long time now. after
all, it's simply Gentoo at its core, and Gentoo has had xz-utils for a
long time.
openSUSE has had xz-utils since 11.2.
On Thu, 1 Mar 2012, Eric Blake wrote:
The Autoconf team is considering releasing only .xz files for 2.69;
What problem are y'all trying to solve here? Is gnu.org running out of
disk space or bandwidth?
I hope you're not just trying to save disk space. I did a little math
here and it
On Fri, 2 Mar 2012, Mike Frysinger wrote:
i don't think that matters. bzip2 is often not installed by default, nor is
gcc or g++ or any other development program. i find it hard to swallow that
this is even a small obstacle to someone who is installing autoconf manually
by fetching the
On 03/02/2012 04:48 PM, Warren Young wrote:
On Thu, 1 Mar 2012, Eric Blake wrote:
The Autoconf team is considering releasing only .xz files for 2.69;
What problem are y'all trying to solve here? Is gnu.org running out of
disk space or bandwidth?
No, space and bandwidth are not the primary
Eric Blake ebl...@redhat.com wrote on Fri, 2 Mar 2012
at 17:10:17 -0700 in 4f516169.9010...@redhat.com:
Actually, this really is part of the reason - since xz is technically
superior to gzip (better compression, same decompression speeds), we are
doing users a favor by getting xz installed
On 3/2/2012 5:10 PM, Eric Blake wrote:
we are
doing users a favor by getting xz installed and commonly available in
more places.
I went through both the .Z - .gz and .gz - .bz2 transitions. I recall
a longer overlap period where major archive sites had everything in both
the new and
Warren Young war...@etr-usa.com writes:
I went through both the .Z - .gz and .gz - .bz2 transitions. I recall
a longer overlap period where major archive sites had everything in both
the new and previous forms.
At least in my corner of the software world, no .gz - .bz2 transition
never
Let's see if these are the right lists
It's partly autoconf because autoconf stages dummy dependency files
so the make include function won't choke. It is partly make because
I find it a bit tricky getting the dependencies just right. It is,
I think, mostly an automake question since I
On Fri, 02 Mar 2012 16:48:07 -0700
Warren Young war...@etr-usa.com wrote:
I still use systems[*] that don't have tar -J, and am likely to
continue doing so for many years to come. Installing xz isn't a big
deal, but typing the longer commands needed for separate
decompression and untarring
On Friday 02 March 2012 20:08:54 James K. Lowden wrote:
On Fri, 02 Mar 2012 16:48:07 -0700 Warren Young wrote:
I still use systems[*] that don't have tar -J, and am likely to
continue doing so for many years to come. Installing xz isn't a big
deal, but typing the longer commands needed for
On 03/02/2012 08:53 AM, Paul Eggert wrote:
The symptoms are:
$ cd tests; make check TESTSUITEFLAGS=75
make check-local
/bin/bash ./testsuite 75
## -- ##
## GNU Autoconf 2.68b test suite. ##
## -- ##
75: Configure re-execs self
Hi Paul, Eric.
Paul Eggert wrote:
Solaris 8 ships with Perl 5.005_03. This satisfies Autoconf 'configure',
which requires only 5.005_03 or better. But
lib/Autom4te/Getopt.pm and lib/Autom4te/General.pm
require 5.006_002.
As I can test with at most with perl 5.6.2 (and no older versions),
Hi Eric.
On 03/02/2012 04:08 PM, Eric Blake wrote:
On 03/02/2012 07:15 AM, Stefano Lattarini wrote:
Also, note that the workaround removed in c3797b86ccbd9 was severely
broken to begin with (that is explained in the commit message);
re-introducing it only to make autoconf buildable out-of-the
On 03/02/2012 07:08 AM, Eric Blake wrote:
Paul, would it be okay if for autoconf we
borrow the same configure check as automake is using, and globally bump
the requirement to be consistent across the autotools?
Sure. If I understand things correctly, that means
'configure' will complain that
On Thu, 1 Mar 2012, Eric Blake wrote:
The GNU Autoconf team is pleased to announce the beta release of
Autoconf 2.68b. Autoconf is an extensible package of M4 macros that
[snip]
On my UnixWare 7.1.4 box, the tests get stuck on
75: Configure re-execs self with CONFIG_SHELL
Here are the
28 matches
Mail list logo
