From: "Eric S. Raymond"
To: Bruce Korb
Cc: "Eric S. Raymond"
Subject: Re: How to do a bootstrap build?
Bruce Korb :
> Uploaded with the correct fix:
> http://autogen.sourceforge.net/data/autogen-5.18.6pre5.tar.xz
Successful build and install confirmed.
--
On 06/06/15 10:10, Andreas Metzler wrote:
On 2015-06-06 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.
[...]
FWIW, it also works for me on sid (bot
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
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 tha
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 uploade
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 <<<=== co
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 agai
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 wrote:
Source: autogen
Version: 5.18.3~pre34
[...]
Hello,
When attempting to
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 ano
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/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 `/tmp/AUTOGEN/autogen-5.16.2/autoopts
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="../.."
${d
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=detail&atid=103593&aid=3531608&group_id=3593
autogen 5.16 F
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
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 th
On 06/05/11 09:45, Bruce Korb wrote:
It failed on hurd with this message:
i486-gnu-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I.. -I../autoopts -g -O2 -O2
-MT autogen-ag.o -MD -MP -MF .deps/autogen-ag.Tpo -c -o autogen-ag.o `test -f
'ag.c' || echo './'`ag.c
In file inc
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 "${ldop
On 06/11/11 14:16, Kurt Roeckx wrote:
Package: autogen
Version: 1:5.11.9-0.2
Severity: serious
Hi,
I'm getting this:
$ autoopts-config --ldflags
-Wl,-R/usr/lib -L/usr/lib -lopts
So things using autoopts-config now set an rpath to /usr/lib/, and
it really shouldn't do that for things that are
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 dig
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 f
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 rele
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.
--
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
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 debian-bugs-rc-
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
thanks to Ryan Hill
* autoopts/test/cond.test (undefining SECOND): adapt to new GCC
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
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 va
On Mon, Nov 9, 2009 at 5:50 PM, Daniel Schepler 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
> dh_install: us
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
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 fix
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 fix
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 what'
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 note
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
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
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.
42 matches
Mail list logo
