Karl Berry writes:
> For GNU packages, dvi and pdf will normally be tested anyway as part of
> a release, due to the need to upload the new manuals to www.gnu.org.
> Perhaps we should remove dvi from there ... -k
Yes, as a start, could we drop linking to DVI manuals from gnulib's
gendocs_templat
Bruno Haible via Gnulib discussion list writes:
> Having said that, I would be in favour of retiring the DVI format from
> the GNU Coding Standards. The DVI format was commonplace in the 1990ies,
> but lost popularity to the PDF format starting 2008 (when PDF became an
> open standard). Nowadays,
Karl Berry writes:
> Given Bruno's experience, ok, let's try. I won't be surprised if
> problems come out of the woodwork, but maybe it will be fine.
>
> I think the change below is all that's needed to implement this?
> I pushed it. Let me know if something more comes to mind.
Thank you!
>
nd only if a package uses some feature
(like >255 long filenames) that require PAX then it would be enabled,
otherwise it will remain ustar-compatible.
Discussion on the gnulib list suggests that at least ustar ought to be
safe to use these days.
/Simon
Bruno Haible via Gnulib discussion
severity 48113 wishlist
retitle 48113 Self-test timeout functionality
thanks
Karl Berry writes:
> What do bug-automake people think?
>
> For myself, I have no objection to sprinkling timeout commands through
> the Automake test infrastructure wherever appropriate. It's not ever
> going to ri
Marc Nieper-Wißkirchen writes:
> Moreover, use cases for a baked-in timeout are not restricted to tests. For
> example, I may want to restrict the build time of certain components in
> situations where a logical error may lead to infinite build times (a simple
> example is that of a Scheme compil
Bruno Haible writes:
> So, I don't think the "let's treat timeout like valgrind" approach is going
> to work. Instead, you need to design a way to deal with timeouts,
> independently.
Hi! I think Marc's request for functionality to introduce timeouts for
self-tests is a good one. However I re
Stefano Lattarini writes:
> On 08/14/2012 03:38 PM, Peter Rosin wrote:
>> On 2012-08-14 15:14, Simon Josefsson wrote:
>>> Hi. It builds and passes self-checks except for the
>>> t/distcheck-override-infodir test. Output below.
>>>
>>> /Simon
>&g
Hi. It builds and passes self-checks except for the
t/distcheck-override-infodir test. Output below.
/Simon
FAIL: t/distcheck-override-infodir
==
distcheck-override-infodir: running makeinfo --version
makeinfo (GNU texinfo) 4.13
Copyright © 2008 Free Software F
Stefano Lattarini writes:
> severity 11532 minor
> tags 11532 + moreinfo
> thanks
>
> Reference:
> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11532>
>
> On 05/21/2012 02:24 PM, Simon Josefsson wrote:
>> Hi! I got two failures on my Ubuntu 12.04 LTS system,
Hi! I got two failures on my Ubuntu 12.04 LTS system, see output below.
Testsuite summary for GNU Automake 1.12.0b
# TOTAL: 2921
# PASS: 2781
sön 2012-05-13 klockan 13:24 +0200 skrev Stefano Lattarini:
> On 05/12/2012 08:44 AM, Stefano Lattarini wrote:
> > tags 11452 + patch
> > severity 11452 minor
> > thanks
> >
> > Hi Simon, thanks for the report.
> >
> > On 05/11/2012 10:45 AM, Si
I got two self-test failures with automake 1.12 on Ubuntu 12.04 LTS.
The first was the 'lex-clean' issue that was already reported. The
other I couldn't find any report for, so please find test-suite.log
output for the failing test below.
/Simon
FAIL: t/parallel-tests-fork-bomb
=
Ralf Wildenhues writes:
> [ adding libtool-patches, in case anyone wants to disagree ]
>
> * Karl Berry wrote on Wed, Mar 17, 2010 at 10:50:38PM CET:
>> I'm okay with changing the m4 and autoconf manuals with
>> s/@acronym{GNU}/GNU/
>>
>> s/@acronym{(.*)}/\1/
>
> So the preferred color
Yes, score=5.4 required=5.0
tests=DATE_IN_FUTURE_24_48,RDNS_DYNAMIC,SPF_FAIL,WEIRD_PORT autolearn=no
version=3.2.5 (2008-06-10) host=yxa-v.extundo.com
--- Begin Message ---
Hi! I installed automake 1.11 without any problems except that one
self-test failed, see snippet from tests/test-suite.lo
Hi.
My libidn.texi file uses @include and @verbatiminclude to get files
stored in other directories (examples, and auto-generated *.texi
snippets found in builddir), I need to pass some -I flags to makeinfo:
AM_MAKEINFOFLAGS = -I $(top_builddir)/doc -I $(top_srcdir)/examples
AM_MAKEINFOHTMLFLAGS
Hi! We received a bug report recently:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=424253
The problem seems to be that I want to make 'shishi.ps' part of the
distribution archive (to provide easier access to the manual), and this
works poorly with automake's default rules. In doc/Makefile.
Simon Josefsson <[EMAIL PROTECTED]> writes:
> Ralf Wildenhues <[EMAIL PROTECTED]> writes:
>
>> I think the fix is to drop the AC_LIBOBJ line from getdate.m4. But
>> Automake also could warn against this (it warns in a slightly simpler
>> setting not involvi
Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> I think the fix is to drop the AC_LIBOBJ line from getdate.m4. But
> Automake also could warn against this (it warns in a slightly simpler
> setting not involving built sources). For this however, gnulib-tool
> should use $(LIBOBJS) instead of @LIBOB
Ralf Corsepius <[EMAIL PROTECTED]> writes:
> On Mon, 2006-01-23 at 21:51 +0100, Bruno Haible wrote:
>> [For the automake people: The problem is that a Makefile.am snippet like
>>
>> TESTS = test-lock
>> check_PROGRAMS = test-lock
>> test_LOCK_LDFLAGS = -lmyspeciallib
>>
>> when cr
The following message is a courtesy copy of an article
that has been posted to gmane.comp.lib.gnulib.bugs as well.
Ralf Wildenhues <[EMAIL PROTECTED]> writes:
>> You need mingw to provoke the bug,
>
> Not quite. You need to cross-compile to MinGW on a non-.exe system to
> provoke the bug.
Right
21 matches
Mail list logo
