Hello There,<-br />
I'm hoping the following documents me--et your needs:
https://billbay.co/ees/otcunqiuquanurse170133051
https://onedrive.live.com/download?cid=8OXNGKIW2IKU5CKH=8OXNGKIW2IKU5CKH%26778=vCmaTNJXbwpz-NlOn 10/14/15 16:15, Dmitry Smirnov wrote:
> Package: autogen
> Version:
On 6/26/21 6:05 AM, Andreas Metzler wrote:
thanks for the report. The ./configure test checks whether $CONFIG_SHELL
supports (non-posix) read -u and uses bash otherwise. This test succeeds
"read -u4" avoids redirecting stdin and avoiding that keeps the
activities from being done in a
On 12/31/20 7:21 AM, Andreas Metzler wrote:
Hello,
For autogen/experimental (5.19.96) config/std-gnu11.m4 needs to be
updated from gnulib m4/std-gnu11.m4 with
---
a3b3fc85e3e632374811b27cb2111e50fa177e36
2020-12-09 04:06:40
std-gnu11: Make compatible with Autoconf 2.70.
*
On 9/23/19 10:17 AM, Andreas Metzler wrote:
> I plan to let 1:5.18.16-2 migrate to testing first since migration to
> guile-2.2 seems to be urgent (serious bug).
I plan to apply your (Helmut's) patch for release -- as soon as I can
get the Autotools working again. It's been a while and they seem
--- error.test.original 2016-09-17 18:13:22.0 +
+++ error.test 2016-09-17 18:13:25.0 +
@@ -48,6 +48,7 @@
/^Aborte.*core dumped/q
p'
+ rm -f core
${SED} -n "${sedcmd}" $1
}
Maybe remove anything starting with "core" since that name is oftentimes
That would be my first guess -- there is a problem in the dependencies.
So, where is the ditritus? Is it a single thread build or multi thread?
Can you dump out the commands that were executed? etc.
There is little I can do if I do not see any of this on my system
and I cannot fully understand
On 10/14/15 16:15, Dmitry Smirnov wrote:
Package: autogen
Version: 1:5.18.6-3
Severity: important
File "doc/gendocs_template" contains the following at line 82:
This page is licensed under a http://creativecommons.org/licenses/by-nd/3.0/us/;>Creative
Commons Attribution-NoDerivs 3.0
FYI, same problem on a known working cable using a SD reader that works on
Windows.
With that reader, I can not read anything. With another reader (SDHC) I can
read
my 32GB cards, but not my 64GB SDXC cards -- using the same cable on the same
port.
I think there is something new in the USB
On 08/09/15 23:58, Valentin Lorentz wrote:
Unfortunately, there is already a variable named like this [1], which
actually stores date+time instead of just time.
Or maybe we can use SOURCE_DATE_ISO8601 and truncate it?
I've mulled it over a bit. These templates are about producing man page
On 08/09/15 05:27, Jérémy Bobbio wrote:
Bruce Korb:
Obviously, I can make no changes to Debian rules,
but I have now added a working --enable-timeout=$WHATEVER configure option:
http://autogen.sourceforge.net/data/autogen-5.18.6pre11.tar.xz
Thanks Bruce. I believe this is going
There is another tiny little problem with your patch:
It presumes that the man page templates are used exclusively by autogen.
That is very, very incorrect. There are quite a few projects that use
AutoOpts. If you want to dig into the template and figure out how to
*PORTABLY* derive a date
On 08/08/15 09:06, Valentin Lorentz wrote:
There are already two bounds hardcoded. How is using a constant in the
interval “worse” than that?
Okay, one constant is in case the computation fails. Not a bound.
The other is just a minimum -- a human interface sort of thing.
It may well be that
Obviously, I can make no changes to Debian rules,
but I have now added a working --enable-timeout=$WHATEVER configure option:
http://autogen.sourceforge.net/data/autogen-5.18.6pre11.tar.xz
and though I've added LC_ALL=C to some of my date invocations,
I cannot use the ``-d
On 08/07/15 11:23, Valentin Lorentz wrote:
Source: autogen
Version: 1:5.18.6~pre3-3
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: cpu locale timestamps
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
Hi!
While working on the “reproducible
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 12/03/14 03:48, Santiago Vila wrote:
$ man unshar | grep Pp
an invocation of the shell program to unpack it..Pp This program will
I don't know what's this Pp supposed to mean. :-)
It is supposed to mean .PP (paragraph) at the start of a line. :)
Someone has been contributing a
On 09/17/14 13:03, Helmut Grohne wrote:
* Make libopts25-dev Multi-Arch:same. At the moment, this marking is
not correct, because the manual pages included differ per
architecture. They are AutoGen-ed and autogen helpfully includes a
timestamp, so unless all builds for all
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 04/26/14 23:11, Rob Browning wrote:
Bruce Korb bk...@gnu.org writes:
I think autogen requires 2.0.3 or better. 2.0.{0,1,2} are definitely broken.
You mean guile?
Yes, sorry I wasn't clearer.
If so, we have 2.0.11 in unstable and 2.0.9 in
testing now -- maybe that's sufficient?
I'm
Guile 2.0.9 still has problems. Extracted from the current build log:
gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I.. -I../autoopts
-D_FORTIFY_SOURCE=2 \
-pthread -I/usr/include/guile/2.0 -g -O2 -fstack-protector \
--param=ssp-buffer-size=4 -Wformat
Specifically, guile-2.0.11. The issues are fixed there.
Otherwise, yet another pre:
http://autogen.sourceforge.net/data/autogen-5.18.3pre34.tar.xz
Getting the editing of the guile headers just right is a royal pain.
The headers got moved around into new and better places, but
my fix-it-up
On 04/26/14 15:05, Rob Browning wrote:
Package: autogen
Version: 1:5.18-2
I'mp planning to have guile-1.8 removed from unstable before the freeze;
please migrate to guile-2.0 as soon as possible.
I think autogen requires 2.0.3 or better. 2.0.{0,1,2} are definitely broken.
--
To
On 11/05/13 11:56, Nikos Mavrogiannopoulos wrote:
Package: autogen
Version: 1:5.18-2
Severity: important
Hello,
Autogen gives the option to include a self-contained version of
the libopts library.
This is done by retrieving the file shown with the following command:
$ autoopts-config
Package: linux-source-3.2
Version: 3.2.51-1
Severity: important
* What led up to the situation?
I tried to boot
* What exactly did you do (or not do) that was effective?
I waited and waited until the command finally timed out.
* What was the outcome of this action?
It finally booted.
*
In my meanderings since filing this, the patch is in linux 3.5 (3.6
stable) and 3.8 is out now.
Can the patch be retroactivly applied to 3.2?
https://lkml.org/lkml/2012/8/12/54
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble?
Hi,
On Tue, Jul 16, 2013 at 9:58 AM, Andreas Metzler
ametz...@downhill.at.eu.org wrote:
Afaik the warning is completely unrelated to the build failure. The
errors.test simply hangs on mips. However I just did a testbuild of
5.17.5.pre14 on mips that worked. I will upload to experimental and
This patch will fix the problem and will be in a release soon:
diff --git a/autoopts/find.c b/autoopts/find.c
index 92584d8..f49667b 100644
--- a/autoopts/find.c
+++ b/autoopts/find.c
@@ -107,6 +107,9 @@ opt_ambiguities(tOptions * opts, char con
st * name, int nm_len)
Package: autogen
Version: 1:5.17.4-2
It is not a particularly intelligent warning. After all, if your
format pointer points to some offset within a character array (that
happens to be just after a NUL byte), why would you expect no further
NUL bytes? Oh, well. That's why I broke out that
On 03/09/13 06:10, Michael Tautschnig wrote:
Package: autogen
Version: 1:5.12-0.1
Usertags: goto-cc
The test suite in autoopts/test/ includes a kind of watchdog for each test,
which supposedly terminates it after 51*kill_delay seconds. usage.test sets
kill_delay to 10 seconds (all others
On 03/09/13 07:49, Bruce Korb wrote:
On 03/09/13 06:10, Michael Tautschnig wrote:
Package: autogen
Version: 1:5.12-0.1
Usertags: goto-cc
The test suite in autoopts/test/ includes a kind of watchdog for each test,
which supposedly terminates it after 51*kill_delay seconds. usage.test sets
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 02/26/12 08:07, Andreas Metzler wrote:
Package: autogen
Version: 1:5.12-0.1
Severity: wishlist
http://ftp.gnu.org/gnu/autogen/rel5.14/
Please wait a week. Save a little effort.
http://autogen.sourceforge.net/announce.html
--
To UNSUBSCRIBE, email to
* /usr/share/doc/autogen/html/* files are enumerated starting from 0,
To me, this is incomprehensible.
I presume this is an internal Debian infrastructure issue.
I don't need to be CC-ed on Debian infrastructure issues. Thanks.
--
To UNSUBSCRIBE, email to
In that case, I understand it a little, but I don't have any control over
it (that I know about anyway). The docs are created with a shell script
and a document template gotten from gnulib that carry them for another
upstream. So, your upstream (autogen) uses an upstream's (gnulib's)
sources
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
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 included from ag.c:35:0
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
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-dist-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
On 03/26/11 18:59, Jonathan Nieder wrote:
+ (
+ test_local() {
+local local_works=yes
+ }
+ test_local
+) || eval 'local() { : ; }'
Patch applied for the next release. Thank you!! Regards, Bruce
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a
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
Kurt Roeckx wrote:
When running the regression tests, I rc.test failing. When running
TEST_RC=--no-load ../rc -t xxx MUMBLE I get the following error:
*** glibc detected *** ../rc: free(): invalid pointer: 0x018d4010 ***
=== Backtrace: =
/lib/libc.so.6[0x7f78a4f64d56]
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
ahold of it:
2004-09-05 Bruce Korb bk...@gnu.org
the program disappeared. All I know about it is:
@node Invoking find-mailer, , Invoking mail-files, Wrappers
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas
Index: uuencode.1
===
RCS file: /sources/sharutils/sharutils/doc/uuencode.1,v
retrieving revision 1.5
diff -u -r1.5 uuencode.1
--- uuencode.1 7 Jun 2007 03:53:47 - 1.5
+++ uuencode.1 30 Aug 2009 16:43:22 -
@@ -45,31
Hi Barry,
On Thu, Jun 11, 2009 at 9:28 AM, Barry deFreesebdefre...@debian.org wrote:
Package: autogen
Version: 1:5.9.7-1
Severity: normal
Hi,
autogen currently fails to build on Debian GNU/Hurd. The attached quilt
patch will resolve that.
Thank you for the bug report. What is the exact
Hi Barry,
Well I'm not quite sure why you would cast a constant even on a 64bit arch
I'm not quite sure either. I do know that all that compat stuff
was a royal pain over the years. I'm sure much of it has been
cleaned up with the gnulib stuff, but it wasn't around way back
when and I've
Hi Vsevolod,
Autoopts does not work on my debian/powerpc (no problem on i386).
While starting autogen, I get:
autogen checkoptn.def
Changing server shell from /bin/bash to /bin/sh
/bin/sh: line 74: -I8: command not found
``-I8'' is an option to columns, telling it to indent its columnized
On Fri, Sep 19, 2008 at 5:41 AM, Bruce Allen
[EMAIL PROTECTED] wrote:
Hi Bruce,
I think 5.38 will parse '-R'. But please note that this is not a
command-line 'option'. It is a 'Directive' which goes into the
configuration file 'smartd.conf'. Is this where you are putting it?
Hi Bruce,
to put an autogen refresh into your etch-backports tree?
Thank you very much!
Regards, Bruce Korb (autogen author)
P.S.: my preference would be to see 5.9.5
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (x86_64)
Shell: /bin
Hi Guido,
The backports link got me to:
http://packages.debian.org/etch-backports/i386/smartmontools/download
which is titled:
Download Page for smartmontools_5.37-6~bpo40+1_i386.deb \
on Intel x86 machines
:( Is the title wrong or is the i386 version still 5.37?
Thanks - Bruce
--
To
On Thu, Sep 18, 2008 at 1:12 AM, Guido Günther [EMAIL PROTECTED] wrote:
Unfortunately, you have to upgrade to 5.39 to parse that option.
Please? Thank you.
There is no 5.39 relese.
All I know is that the one I installed with SuSE 11.0 on my desk top is:
$ smartd --version
smartd 5.39
It also turns out that to correctly read drive temperature, you need to
set the ``-R 194'' option in the config file. RE:
http://defindit.com/readme_files/smartd_smartctl.html
Problem:
For attribute 194 (Temperature_Celsius), smartd currently
detects differences of the VALUE and
Package: iceweasel
Version: 2.0.0.6
The error message:
Iceweasel is already running, but it is not responding.
To open a new window, you must first close the existing
Iceweasel process, or restart your system.
Here are the problems:
1. There is no iceweasel process running.
2. The system is a
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?
No, if you want to use bash, you have to build-depends on it and call it
explicitely (and not /bin/sh).
/bin/sh is a symlink to any POSIX compliant shell (like dash), not to
a Bourn compatible shell.
Hi Julien,
The script in question is POSIX compliant. In fact it is Bourne-compliant,
which
Julien wrote:
Here is the full build log:
Hi,
Thank you for trying. You did extract the piece that showed that there
was a problem.
The additional context won't help any. The problem is that the server
shell (/bin/sh)
died unexpectedly while processing the code fragment displayed in your
Hello Julien,
The build of AutoGen _does_ require a Bourne compatible shell.
There are some bootstrap scripts also that require BASH, but these
are completely unnecessary for anyone not building from CVS.
I have now modified config/bootstrap to check for bash and rerun
itself if the shell is not
Hi Julien,
Julien Danjou wrote:
Package: autogen
Version: 1:5.8.3-2
Severity: important
Hello,
There was a problem while autobuilding your package:
make[3]: Entering directory `/build/buildd/autogen-5.8.3/xml2ag'
top_builddir=.. top_srcdir=.. PATH=`cd ../columns;pwd`:$PATH ; export
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 Friday 26 August 2005 03:39 pm, Dan Jacobson wrote:
Each man page should mention how to give a bug report to upstream, or
say to see an Info page which will say how to give a bug to upstream.
S The file /usr/share/doc/sharutils/README has this information, and
S there is no excuse to not
If you look through the sources, it is clearly BSD, though much reworked
since it was part of their source base. I recommend leaving off any
GNU attribution. However, I've added a ``.SH REPORTING BUGS'' to
the four man pages. Barring complaints or other suggested improvements,
look for this in
Reasonable enough. Try 4.5.2 when it is ready:)
Index: uuencode.1
===
RCS file: /cvsroot/sharutils/sharutils/doc/uuencode.1,v
retrieving revision 1.3
diff -b -B -u -p -r1.3 uuencode.1
--- uuencode.1 1 Jul 2005 13:41:06 -
On Monday 25 July 2005 10:05 pm, Matt Kraai wrote:
On Mon, Jul 25, 2005 at 04:40:03PM -0700, Bruce Korb wrote:
I have an image up on Source Forge:
http://autogen.sf.net/data/autogen-5.7.2-semifinal.tar.gz
If it makes you-all happy, then I will release exactly that image.
I have
Hmm. Interesting problem. The realpath(3C) documentation specifically
references PATH_MAX:
NAME
realpath - return the canonicalized absolute pathname
SYNOPSIS
#include limits.h
#include stdlib.h
char *realpath(const char *path, char *resolved_path);
[...]
Hi Michael,
On Monday 25 July 2005 03:08 pm, Michael Banck wrote:
The GNU C library manual (as in, libc.info.gz) suggests using
canonicalize_file_name in chapter 14.5, Symbolic Links:
Function: char * canonicalize_file_name (const char *NAME)
The `canonicalize_file_name' function
Hi Guys,
I have an image up on Source Forge:
http://autogen.sf.net/data/autogen-5.7.2-semifinal.tar.gz
If it makes you-all happy, then I will release exactly that image.
Regards, Bruce
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL
The easiest solution is to disable the test since an autogen daemon
is still a rough sketch. It was my intention to disable that
test. Probably should ensure it is not distributed, either.
That would do it, leastwise until autogen-as-a-daemon really
works.
Sorry. Regards, Bruce
On
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
98 matches
Mail list logo
