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&resid=8OXNGKIW2IKU5CKH%26778&authkey=vCmaTNJXbwpz-NlOn 10/14/15 16:15, Dmitry Smirnov wrote:
> Package: autogen
> Ve
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 subshell.
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.
* m4/s
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 t
--- 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
suf
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 e
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 wor
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 like
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 to be of
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 @$SOURCE_DATE_EPOC
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 1
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 comma
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 b
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 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
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 architect
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
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 scr
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 -Werror=format-security
On 04/26/14 23:11, Rob Browning wrote:
Bruce Korb 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&
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 UNSUBSCRIBE
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 lib
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? Cont
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.
*
Hi,
On Tue, Jul 16, 2013 at 9:58 AM, Andreas Metzler
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
> let the autobuilders chew
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)
fputs(zambig_list_ms
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 warnin
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 te
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 ot
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 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 debian-bugs-dist-requ...@lists.debia
ode/csh_002fzsh-caveat.html
html_section/START_005fOPT.html
html_section/autogen-source_002dtime.html
html_section/csh_002fzsh-caveat.html
$
What version are you talking about? Current is 5.12.
I switched to the gnulib script some time back.
On 07/25/11 12:18, Regid Ichira wrote:
From: Bruce Korb
Sub
* /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 debian-bugs-dist-requ...@lists.debi
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-dist-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-dis
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
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:
> 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[0x7f78a4f64d5
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
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 +45
FILE ... is a list of files to send
However, for "find-mailer" sometime between:
> Tue Jun 7 00:05:11 1994 Francois Pinard (pin...@icule)
and when I got ahold of it:
> 2004-09-05 Bruce Korb
the program disappeared. All I know about it is:
> @node Invoking find-maile
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 nev
Hi Barry,
On Thu, Jun 11, 2009 at 9:28 AM, Barry deFreese 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 compilation
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 columni
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 UN
would you please be willing
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')
Arc
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 Bruc
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.3
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 W
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 s
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
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
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 is
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 no
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
top_bui
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
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 -
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 i
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 exc
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
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
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' func
Hmm. Interesting problem. The "realpath(3C)" documentation specifically
references PATH_MAX:
> NAME
>realpath - return the canonicalized absolute pathname
>
> SYNOPSIS
>#include
>#include
>char *realpath(const char *path, char *resolved_path);
> [...]
> ERRORS
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 Wednesd
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.
98 matches
Mail list logo
