On 06/06/15 10:10, Andreas Metzler wrote:
On 2015-06-06 Nikos Mavrogiannopoulos n...@gnutls.org wrote:
On Fri, 2015-06-05 at 18:19 -0700, Bruce Korb wrote:
export AUTOGEN_TRACE=everything AUTOGEN_TRACE_OUT='/tmp/ag-log.txt'
Log is attached.
[...]
FWIW, it also works for me on sid (both
From: Eric S. Raymond e...@thyrsus.com
To: Bruce Korb bruce.k...@gmail.com
Cc: Eric S. Raymond e...@snark.thyrsus.com
Subject: Re: How to do a bootstrap build?
Bruce Korb bruce.k...@gmail.com:
Uploaded with the correct fix:
http://autogen.sourceforge.net/data/autogen-5.18.6pre5.tar.xz
byte arrays, i.e.
traditional strings.
I'll have a look again next weekend. :( Sorry.
On Sun, Jun 28, 2015 at 11:26 PM, Nikos Mavrogiannopoulos
n...@gnutls.org wrote:
On Sun, 2015-06-28 at 17:18 -0700, Bruce Korb wrote:
On 06/28/15 04:26, Nikos Mavrogiannopoulos wrote:
http
On 06/28/15 04:26, Nikos Mavrogiannopoulos wrote:
http://autogen.sourceforge.net/data/autogen-5.18.5pre20.tar.xz
That version works for me.
OK, then, I've now unwound all the Guile wrapper macro removals from top of
tree.
http://autogen.sourceforge.net/data/autogen-5.18.6pre3.tar.xz
If
On 06/06/15 10:10, Andreas Metzler wrote:
FWIW, it also works for me on sid (both amd64 and i386).
FWIW, it appears to be related to the disablement of Guile 1.6.
I may have to unwind that until I can figure out how Guile 1.6
support causes regex execution problems
Meanwhile, I've
On 06/07/15 06:33, Nikos Mavrogiannopoulos wrote:
I've compiled and run the attached version of that program and it
succeeds (no valgrind warnings either).
So the isolated case works, but the same expression embedded in autogen fails.
The more interesting environment settings might be the LC_*
On 06/05/15 23:33, Nikos Mavrogiannopoulos wrote:
On Fri, 2015-06-05 at 18:19 -0700, Bruce Korb wrote:
export AUTOGEN_TRACE=everything AUTOGEN_TRACE_OUT='/tmp/ag-log.txt'
Log is attached.
In that log, I find:
Compiling '[ -~]' with bits 0x1 === compiled as extended RE
CASE no match: `c
On 06/05/15 13:18, Nikos Mavrogiannopoulos wrote:
Severity: grave
Tags: upstream
Justification: renders package unusable
Dear Maintainer,
* What led up to the situation?
Trying to run autogen on my def files fails consistently after upgrading
5.18.5. Downgrading to the .4 version works
On 05/29/14 12:57, Hector Oron wrote:
Apologies for delay. Find attached file.
Enough of a delay has gone by that the final 5.18.3 version is now out.
I believe it addresses the experienced issue.
To the best I can determine, this code:
die() {
echo Killing AutoGen ${AG_pid}
On 05/12/14 05:38, Hector Oron wrote:
I am attaching failed log found in buildd, but did not get uploaded as it
never finished building.
Unfortunately, the build logs do not have enough information. The automake
automated testing
redirects all output to a log file and reports SUCCESS or
On 05/10/14 03:20, Andreas Metzler wrote:
Control: forwarded 747592 http://sourceforge.net/p/autogen/bugs/161/
Control: tags 747592 confirmed upstream
Control: severity 747592 serious
On 2014-05-10 Hector Oron zu...@debian.org wrote:
Source: autogen
Version: 5.18.3~pre34
[...]
Hello,
On 08/17/12 10:27, Andreas Metzler wrote:
usually my /bin/sh is dash. However I have just changed my setup and
made bash /bin/sh and reran the test. It failed on the 5th invocation.
Do you have any idea why the error requires several tries to
reproduce?
Only an obvious guess: something or
On 08/14/12 23:53, Andreas Metzler wrote:
rm -rf FAILURES testdir ; VERBOSE=true ; export VERBOSE ; \
make check TESTS=errors.test
make[1]: Entering directory `/tmp/AUTOGEN/autogen-5.16.2/autoopts/test'
make check-TESTS
make[2]: Entering directory
Hi Andreas,
Thank you. I now have enough information to diagnose the issue.
It fails in the invocation of autogen with ${AG_L} below:
case ${BASH_VERSION} in
not-good-enough )
echo You are running Solaris without bash available.
echo duplicate option flags cannot be tested.
;;
* )
On 08/12/12 09:01, Andreas Metzler wrote:
I do not think this warrants a release,
No, but it is in source now.
Anyway, with the patch a testsuite error appeared:
---
PASS: equiv.test
/bin/bash: line 5: 17976 Killed TERM='' top_builddir=../..
On 06/04/12 15:24, Lucas Nussbaum wrote:
Source: autogen
Version: 1:5.12-0.1
Severity: serious
Going out on a limb, I am going to guess that when the ia64 issue is fixed,
this will be fixed, too:
https://sourceforge.net/tracker/?func=detailatid=103593aid=3531608group_id=3593
autogen 5.16
On 07/10/11 08:42, Kurt Roeckx wrote:
fmemopen.c:752:10: error: '_IOT__IOTBASE_fmemc_get_buf_addr_t' undeclared
That means that hurd has a non-standard definition for _IOWR.
#ifdef HURD
#define _IOT__IOTBASE_fmemc_get_buf_addr_t sizeof(fmemc_get_buf_addr_t)
#endif
5.12 still failed with
On 07/11/11 10:14, Kurt Roeckx wrote:
That means that hurd has a non-standard definition for _IOWR.
#ifdef HURD
#define _IOT__IOTBASE_fmemc_get_buf_addr_t sizeof(fmemc_get_buf_addr_t)
#endif
5.12 still failed with the same error message.
Then HURD is not #defined in hurd. I had to read
And, yes, I was typing and firing off a test at the same time.
autoopts-config.in should be patched thus:
static_libs=${libdir}/libopts.a
cflags=-I${includedir}
case ${libdir} in
/lib | /lib64 | /usr/lib | /usr/lib64 )
ldopts=''
ldflags=-lopts
;;
* )
test -n ${ldopts} \
Hi Kurt,
Thank you.
On 06/05/11 02:53, Kurt Roeckx wrote:
I applied your patch and it build on most arches now.
Excellent! Thank you! I still need to chase down why it would
have failed with a non-directory for HOME. It should not have,
but that should not be crucial.
I'm still waiting
On 06/05/11 02:53, Kurt Roeckx wrote:
It failed on hurd with this message:
i486-gnu-gcc -std=gnu99 -DHAVE_CONFIG_H -I. .
In file included from ag.c:35:0:
fmemopen.c: In function 'ag_fmemioctl':
fmemopen.c:752:10: error: '_IOT__IOTBASE_fmemc_get_buf_addr_t' undeclared
I've done some more
On 06/03/11 13:47, Kurt Roeckx wrote:
Source: autogen
Version: 1:5.11.9-0.1
Severity: serious
catastrophic? Seems odd that it fails everywhere.
I have several test platforms that all work: Solaris, Free BSD and Linux.
Can I get access to these build platforms and poke around? Thanks.
--
On 06/03/11 15:06, Kurt Roeckx wrote:
catastrophic? Seems odd that it fails everywhere.
I have several test platforms that all work: Solaris, Free BSD and Linux.
Can I get access to these build platforms and poke around? Thanks.
serious just means that this is a blocker for the next
FAILURE: warning diffs: 1c1
#warning undefining SECOND due to option name conflict [-Wcpp]
---
#warning undefining SECOND due to option name conflict
GCC warning format changed. autogen test needs to change, too. This was fixed
months ago.
--
To UNSUBSCRIBE, email to
also see Bug #624755
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
On 05/01/11 04:04, Matthias Klose wrote:
patch at
http://launchpadlibrarian.net/70844378/autogen_1%3A5.10-1.1_1%3A5.10-1.1ubuntu1.diff.gz
Fix in pending release
2011-04-07 Bruce Korb bk...@gnu.org
thanks to Ryan Hill dirtye...@gentoo.org
* autoopts/test/cond.test
Kurt Roeckx wrote:
Hi,
I've NMU'd your package. Please find the patch that I used
attached.
Some comments:
- You might want to use something like:
dh_makeshlibs -V libopts25 (= 1:5.10)
This would require that you update this properly on new release.
I've just used -V would would
If you generate the option code with new templates and run against old
library, you will have a conflict. The library will reject the new code.
The new library will accept a program generated against old templates
and linked against the old library. Or, I should say it is supposed to.
I do not
On Mon, Nov 9, 2009 at 5:50 PM, Daniel Schepler dschep...@gmail.com wrote:
Package: autogen
Version: 1:5.9.9-1
Severity: serious
From my pbuilder build log:
...
rm -f /tmp/buildd/autogen-5.9.9/debian/tmp/usr/share/autogen/*.tar.gz
dh_testdir
dh_testroot
dh_install --fail-missing
Matt Kraai wrote:
Howdy,
AutoGen 5.8.3 built libopts.so.25. AutoGen 5.8.8 built
libopts.so.24. This change was made in version 4.71 of VERSION, whose
comment was
test warning stuff
:) Is this just a mistake? Should I decrement AO_AGE to 2 so that it
builds libopts.so.25 again?
Daniel Schepler wrote:
Le Mardi 31 Janvier 2006 17:35, vous avez écrit :
Daniel Schepler wrote:
I got:
[EMAIL PROTECTED]:~/test$ ./mmap-test
Successfully mapped NUL page at 0xb7fe9000 (is 0)
THANK YOU. I now have complete confidence that adding 1 (one) to the
initial mmap
Daniel Schepler wrote:
Le Mardi 31 Janvier 2006 17:35, vous avez écrit :
Daniel Schepler wrote:
I got:
[EMAIL PROTECTED]:~/test$ ./mmap-test
Successfully mapped NUL page at 0xb7fe9000 (is 0)
THANK YOU. I now have complete confidence that adding 1 (one) to the
initial mmap
Matt Kraai wrote:
On Fri, Jan 27, 2006 at 04:43:16PM +0100, Daniel Schepler wrote:
Le Vendredi 27 Janvier 2006 16:14, Matt Kraai a écrit :
On Fri, Jan 27, 2006 at 11:08:48AM +0100, Daniel Schepler wrote:
I see the build is somehow succeeding on the buildd's, though... but I
don't know
Daniel Schepler wrote:
Just a quick note that I've been able to reproduce the failure on the
license.test test on an i386 system as well, so it's apparently not
alpha-specific. I just ran pbuilder on the 1:5.7.3-1 source package twice in
a row, and it failed both times.
Another quick
Hi Matt,
According to my reading of the doc for mmap, this should work. It does
work on other platforms. It also seg faults instead of returning ((void*)-1).
Now, what? :-(
If you don't want to require that users use a kernel that doesn't
misbehave like this, shouldn't you add an autoconf
On Thursday 01 December 2005 08:11 am, Bruce Korb wrote:
The call to scm_makstr() is faulting (every time for me):
Hi all,
I have now been able to recreate the failure on this call fairly
often, but I have not found a cause. Nevertheless, this call is
only useful if you use SCM_CHARS
The call to scm_makstr() is faulting (every time for me):
$ uname -a
Linux juist 2.6.13.2 #2 Fri Sep 23 18:45:17 CEST 2005 alpha GNU/Linux
$ gdb ../../autogen
(gdb) set args --trace=everything -b license --no-def -T license.tpl
(gdb) run
Starting program: /home/bkorb/autogen-5.7.3/agen5/autogen
On Tuesday 29 November 2005 07:33 pm, Matt Kraai wrote:
I wasn't able to reproduce this problem with autogen 1:5.7.3-1 in the
unstable chroot on escher.debian.org. Falk, would you try to
reproduce the problem and let me know whether or not you are able to?
I was able to reproduce it
1. the test used a POSIX-ism that failed if the shell did not
grok POSIX extensions to Bourne.
2. If the license file size was a multiple of pagesize, then
strlen() would seg fault.
OTOH, neither of these would affect the pseudo macro processing:
It also fails with autogen 1:5.7.2-1
On Thursday 31 March 2005 05:30 pm, Santiago Vila wrote:
On Thu, 31 Mar 2005, Bruce Korb wrote:
Wrong assumption. It was announced on info-gnu.
May I suggest that sharutils 4.3.77 and 4.3.78 are not put in directories
named 4.3.77 and REL-4.3.78, then? The current layout is a little
bit
40 matches
Mail list logo
