Bug#801825: autogen: non-free file "doc/gendocs_template" (CC-BY-ND-3.0)
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: 1:5.18.6-3 > Severity: important > > File "doc/gendocs_template" contains the following at line 82: > > This page is licensed under a . > > Please investigate. > This file comes from gnulib.
Bug#990338: autogen: reproducible-builds: embeds /bin/sh or /bin/bash in autoopts-config
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. If you do stuff in a subshell,
the information stashed in variables is invisible. I think the "-u"
option is a couple of decades old now. I wonder what the POSIX point of
resistance is on that feature.
I believe Andreas' solution should be correct: force CONFIG_SHELL to a
shell that supports "read -u".
It is possible the dependence on "-u" can be removed, if my scan over
the code is correct. It looks like the templates I use use that option
only to avoid an otherwise unnecessary fork() call. If so, the loops
involved can be fixed up with a "done <&4" at the end and removing the
"-u" option.
There's still the issue of "mk-unlocked-io.sh" tho:
do_stdio() {
while read -u4 line
do
[[ "$line" =~ $extern_line ]] || continue
[[ "$line" =~ $close_decl ]] || {
read -u4 args || die "no close for $line"
line+="$args"
}
ct=$(sed 's/.*( *//;s/ *).*//' <<<"$line")
if (( ${#ct} > 0 )) && [[ "$ct" != "void" ]]
then
ct=$(sed 's/[^,]//g' <<<"$ct")
ct=$(( (${#ct} * 3) + 2 ))
args='_w,_x,_y,_z'
args=${args:$(( ${#args} - ct )):$ct}
else
args='' ct=0
fi
do_func "$line" "$args"
done
}
That may be trickier, but I am uncertain of its use anymore. :) (I
stopped being a programmer 6 years ago now. I'm retired. It's been a
long time.) I think that is an AutoGen developer only script for
fabricating an "autoopts/unlocked-io.h" header. It should not be
relevant to reproducible builds. But I cannot be certain anymore.
Cheers - Bruce
Bug#978772: autogen: ftbfs with autoconf 2.70
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/std-gnu11.m4: Disable the entire file if Autoconf >= 2.70 is in use. --- cu Andreas Andreas, This means a re-release with current gnulib fixes the issue?
Bug#941025: autogen FTCBFS: multiple regressions
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 to have bit-rotted in the interim. :(
Bug#838148: autogen: FTBFS on hurd-i386
--- 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
suffixed with a PID number.
Bug#823448: autogen: Breaks if rebuilt using gcc-6 and glibc 2.23
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 exactly what is going on on yours. Sorry. :( - Bruce On 05/04/16 12:55, Daniel Schepler wrote: Source: autogen Version: 1:5.18.7-3 Severity: important I'm running a test rebuild of the Debian archive against gcc-defaults and glibc from experimental, using a bootstrapping process that "eats its own dog food". In gnutls28, I got this error: ... make[6]: Entering directory '/build/gnutls28-3.4.11/src' autogen srptool-args.def fserr 2: cannot map data file options: No such file or directory Makefile:2232: recipe for target 'srptool-args.c' failed make[6]: [srptool-args.c] Error 2 (ignored) /bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H [] gcc: error: srptool-args.c: No such file or directory gcc: fatal error: no input files compilation terminated. [...] (It's possible that the actual problem is in one of the dependencies such as guile-2.0.)
Bug#801825: autogen: non-free file "doc/gendocs_template" (CC-BY-ND-3.0)
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 United States License. Please investigate. This file comes from gnulib.
Bug#784337: usb: [29493.628253] hub 1-0:1.0: unable to enumerate USB device on port 6
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 world that my Linux 3.11 kernel doesn't know about. > $ dmesg | grep -v DROP-DEFLT | tail -n 20 > [... boot stuff elided] > [ 7231.954610] hub 9-0:1.0: Cannot enable port 4. Maybe the USB cable is bad? > [ 7232.913815] hub 9-0:1.0: Cannot enable port 4. Maybe the USB cable is bad? > [ 7233.873051] hub 9-0:1.0: Cannot enable port 4. Maybe the USB cable is bad? > [ 7234.832363] hub 9-0:1.0: Cannot enable port 4. Maybe the USB cable is bad? > [ 7234.832376] hub 9-0:1.0: unable to enumerate USB device on port 4 > $ ls -l ; lspci|fgrep USB ; lsusb > total 0 > lrwxrwxrwx 1 root root 0 Sep 1 07:17 :00:12.2 -> ../../../../devices/pci:00/:00:12.2 > lrwxrwxrwx 1 root root 0 Sep 1 07:17 :00:13.2 -> ../../../../devices/pci:00/:00:13.2 > lrwxrwxrwx 1 root root 0 Sep 1 07:17 :00:16.2 -> ../../../../devices/pci:00/:00:16.2 > --w--- 1 root root 4096 Sep 1 07:17 bind > --w--- 1 root root 4096 Sep 1 07:17 new_id > --w--- 1 root root 4096 Sep 1 07:17 remove_id > --w--- 1 root root 4096 Sep 1 07:15 uevent > --w--- 1 root root 4096 Sep 1 07:17 unbind > 00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller > 00:12.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller > 00:13.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller > 00:13.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller > 00:14.5 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI2 Controller > 00:16.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB OHCI0 Controller > 00:16.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller > 02:00.0 USB controller: Etron Technology, Inc. EJ168 USB 3.0 Host Controller (rev 01) > 06:00.0 USB controller: Etron Technology, Inc. EJ168 USB 3.0 Host Controller (rev 01) > Bus 002 Device 003: ID 03f0:0e2a Hewlett-Packard > Bus 009 Device 002: ID 046d:c068 Logitech, Inc. G500 Laser Mouse > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > [...] > Bus 011 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > $ uname -a > Linux bach 3.11.10-29-desktop #1 SMP PREEMPT Thu Mar 5 16:24:00 UTC 2015 (338c513) x86_64 x86_64 x86_64 GNU/Linux
Bug#794892: autogen: please make the build reproducible (cpu, locale, timestamps)
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 documentation and not just documentation of the autogen sources. Therefore, it makes more sense to me to use MAN_PAGE_DATE and drop references to SOURCE. So I will not be using anything that is pretty much exclusively tied to environment variables used by the Debian release process. Please set and export MAN_PAGE_DATE according to your needs and it will be inserted exactly thus (without any fiddling) into the generated docs. Well, will be come pre13 or my final release. I am trying to polish some kinks that affect the NTP project before bumping out a final release. Thank you for your help and consideration. Regards, Bruce -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794892: autogen: please make the build reproducible (cpu, locale, timestamps)
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 interest to all binary No problem. Maybe I should also scale up the factor of 10? Its purpose really is only for error detection. I also decided to fiddle it so that you can specify the man page date stamp, too. The -d @ thingy is really unworkable, but if you export SOURCE_DATE, whatever it contains will be the date stamp. pre12. Since this is still preliminary, I'm open to other variable names. SOURCE_DATE seems too likely to conflict. Maybe, MAN_PAGE_SOURCE_DATE? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794892: autogen: please make the build reproducible (cpu, locale, timestamps)
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 command invocation that references the time stamp
on a source file, please feel free. All the world is not GNU.
-d @${TIME_IN_SECONDS} is not portable.
http://pubs.opengroup.org/onlinepubs/009604599/utilities/date.html
I would recommend some post-processing step of some sort if you want
to have man pages be stamped with a date different from the current date.
And you missed a few:
$ grep -E 'shell.*date' *.tpl
agman-cmd.tpl: (shell date '+%d %b %Y') package-text section-name) ))
agman-file.tpl: (shell date '+%d %b %Y') package-text section-name) ))
agmdoc-cmd.tpl: .Dd (shell date '+%B %e %Y' | sed 's/ */ /g')
agmdoc-file.tpl: .Dd (shell date '+%B %e %Y' | sed 's/ */ /g')
def2pot.tpl:# Copyright (C) [= (shell date +%Y) =][=
def2pot.tpl:POT-Creation-Date: [= (shell date +\%F %R%z\) =]\n
So in theory, producing a byte-for-byte repeatable build sounds nice,
but first there are practical problems that must be resolved.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794892: autogen: please make the build reproducible (cpu, locale, timestamps)
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 second is sufficient on a given platform, but I would not expect a human being to become impatient before 5 seconds have elapsed. The value needs to indicate that at that amount of time there is highly likely some problem, and it ought not be so long that folks get impatient. I do not expect impatience in less than 5 seconds. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794892: autogen: please make the build reproducible (cpu, locale, timestamps)
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_EPOCH'' option for reasons stated earlier. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#794892: autogen: please make the build reproducible (cpu, locale, timestamps)
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 builds” effort [1], we have noticed that autogen could not be built reproducibly. The attached patch fixes the following issues: * run time of ./configure affects a preprocessor constant This is necessary. Perhaps if you build on one platform and run on another, you might have issues, but the problem boils down to trying to understand when some template has wandered out into the weeds. I can pick an arbitrary Oh, I'm certain that doing thus-and-so will _never_ take longer than X. but that doesn't scale very well. So, I just take a rough measure based on configure time and then add in a factor of 10 on the theory that it's close enough and can be overridden anyway. So, proposal: allow a config flag that specifies the default timeout time. You specify that, you get reproducibility. Otherwise, it is speed-of-build- machine adaptable. * locale-dependant sort That should be fixed. I abhor and hate and despise locale-dependent sorting. It was a really stupid idea to foist that onto the computing world as a default. If you want to change the way things work, then invent new interfaces. Improving an older interfaces is amazingly stupid. * timezone-dependant date Unclear what part of the patch addresses this. Thank you! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787866: autogen: after upgrade to 5.18.5 autogen no longer works
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 amd64 and i386).
cu Andreas
Hi Guys,
Eric Raymond and I poked around long enough to find the problem:
It's this:
--- a/agen5/autogen.c
+++ b/agen5/autogen.c
@@ -26,6 +26,7 @@
#ifdef HAVE_SYS_RESOURCE_H
#include sys/resource.h
#endif
+#include locale.h
typedef void (void_main_proc_t)(int, char **);
@@ -120,6 +121,7 @@ inner_main(void * closure, int argc, char ** argv)
int
main(int argc, char ** argv)
{
+setlocale(LC_ALL, );
setup_signals(ignore_signal, SIG_DFL, catch_sig_and_bail);
optionSaveState(autogenOptions);
trace_fp = stderr;
I was told by the Guile folks that to make strings be and stay as ASCII strings,
I needed to do this. By backing out the setlocale call, all becomes well again
-- UNLESS -- you happen to use some locale that makes Guile strings go berserk.
Changing the behavior of Guile strings was a completely stupid idea.
If you change semantics, for God's sake, change the interface name.
So for the short term: remove the setlocale call and be certain to never
run autogen unless the environment variable LC_ALL is set to C. :(
Maybe the fix is to do a getenv for LC_ALL and re-exec with the right value
if there is a problem?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787866: autogen: after upgrade to 5.18.5 autogen no longer works
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 Successful build and install confirmed. -- a href=http://www.catb.org/~esr/;Eric S. Raymond/a -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787866: autogen: after upgrade to 5.18.5 autogen no longer works
Then I guessed at the wrong part of the patch. I believe that the problem is that a single character string is morphing into some weirdo multi-byte character because the Guile library thinks that it is the right thing to do. I do wish the Guile folks had not removed all support for NUL terminated 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://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 that one works for you, then I'll promote it next weekend. Thank you both for your help! I'm not able to compile this version. The error message follows. make[2]: Entering directory '/tmp/autogen-5.18.6pre3/xml2ag' top_srcdir=.. top_builddir=.. PATH=`cd ../columns;pwd`:$PATH CLexe=../columns/columns ../agen5/autogen -MF.deps/stamp-opts.d -MTstamp-opts -MP -L../autoopts/tpl -L../autoopts/tpl --definition=./xmlopts.def Error in template ../autoopts/tpl/optlib.tlib, line 780 DEFINITIONS ERROR in ../autoopts/tpl/optlib.tlib line 780 for xmlopts.h: Error: value for opt output is `O' must be single char or 'NUMBER' Failing Guile command: = = = = = (error (sprintf Error: value for opt %s is `%s'\nmust be single char or 'NUMBER' (get name) (get value))) = Makefile:903: recipe for target 'stamp-opts' failed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787866: autogen: after upgrade to 5.18.5 autogen no longer works
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 that one works for you, then I'll promote it next weekend. Thank you both for your help! Regards, Bruce -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787866: autogen: after upgrade to 5.18.5 autogen no longer works
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 uploaded a pre20 which contains everything between pre7 (which worked) and pre21 (which did not) *except* the Guile changes. Presuming that that works, I can focus my attention on the Guile interface stuff. http://autogen.sourceforge.net/data/autogen-5.18.5pre20.tar.xz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787866: autogen: after upgrade to 5.18.5 autogen no longer works
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_* variables, if that has any effect on regcomp/regexec. Since it is not documented as having an effect, I'd be more than a little surprised if it actually did. I guess another possibility would be pointer misusage clobbering data. To investigate, I'd need to step through it with gdb on an affected platform. gdb b Select_Match_Full if ((sample[0] == 'c') (sample[1] == 0)) but the problem is almost certainly with the data that the regcomp/regexec routines are seeing. From the trace, I can see that the regex is being compiled on this first pass through the arguments. (-c is the first option.) Nikos, I am stumped here. Oh, wait -- what version of Guile? 2.0.[0123] are broken. I've stopped choking on newer versions of 2.0.x that I've not seen, but history says that problems do sneak in in micro releases. (Way back whenever, I personally verified each micro release before I enabled it for AutoGen.) So, what version, please? Probably *not* an issue, but just to know time passes == I finished reviewing every patch between v4-18-4 and v4.18.5 (I should learn to be consistent). There are a few changes in the agen5 code, but every one I looked at looked innocuous to me. Changing a copyright date or being more scrupulous about stripping qualifiers from pointers. But I also pulled support for Guile 1.6. It's long enough in the tooth. That simplified a lot of the Guile function wrappers. If there were a way for me to bisect the code and pin down the issue, I'd do that. There were 22 patches, but many are simply version bumps or strictly commentary. It would probably take 4 tries in any case to find the failing patch. If it works for you, contact me directly and I'll send my public key. Thanks! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787866: autogen: after upgrade to 5.18.5 autogen no longer works
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' MATCH_FULL vs. `[ -~]'
I think there is a RE library problem. The code is as follows:
/*
* On the first call for this macro, compile the expression
*/
if (cur_macro-md_pvt == NULL) {
void *mat = VOIDP(pattern);
regex_t * re = AGALOC(sizeof(*re), select match full re);
if (OPT_VALUE_TRACE TRACE_EXPRESSIONS) {
fprintf(trace_fp, TRACE_SEL_MATCH_FULL,
pattern, cur_macro-md_res);
The Compiling '...' message is printed here. The following compile_re
function WILL NOT RETURN if there is a problem.
}
compile_re(re, mat, (int)cur_macro-md_res);
cur_macro-md_pvt = re;
}
if (regexec((regex_t *)cur_macro-md_pvt, sample, (size_t)2, m, 0)
sample points to the NUL terminated, single character string: c.
!= 0)
return FAILURE;
if ( (m[0].rm_eo != (int)strlen( sample ))
|| (m[0].rm_so != 0))
return FAILURE;
return SUCCESS;
This function returns FAILURE, and that is incorrect.
This code has not changed in many years (16).
Last January, I changed the casting of 'pattern' to coerce it into a void *
without any const attributes, but functionally no changes for 16 years.
The following program should replicate the same test that fails in AutoGen.
If this succeeds, then the question is, what is different in the execution
env?
If this fails, on the other hand, then you need to look to the regcomp library.
#define VOIDP(_p) ((void *)(unsigned long)(_p))
static void
compile_re(regex_t * re, char const * pat, int flags)
{
int rerr = regcomp(re, VOIDP(pat), flags);
if (rerr != 0) {
char erbf[ 1024 ];
regerror(rerr, re, erbf, sizeof(erbf));
fprintf(stderr, BAD_RE_FMT, rerr, erbf, pat);
abort();
}
}
static bool
check_full_match(char const * sample, char const * pattern)
{
regmatch_t m[2];
regex_t * md_pvt;
/*
* On the first call for this macro, compile the expression
*/
{
void *mat = VOIDP(pattern);
regex_t * re = malloc(sizeof(*re));
compile_re(re, mat, 1);
md_pvt = re;
}
// In this function, the RE must match the entire string.
//
if (regexec((regex_t *)cur_macro-md_pvt, sample, (size_t)2, m, 0)
!= 0)
return false;
if ( (m[0].rm_eo != (int)strlen( sample ))
|| (m[0].rm_so != 0))
return false;
return true;
}
int main(int argc, char ** argv) {
if (! check_full_match(c, [ -~]))
printf(FAILED\n);
return 0;
}
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787866: autogen: after upgrade to 5.18.5 autogen no longer works
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 again. I guess it is best to back it out until diagnosed. * What exactly did you do (or not do) that was effective (or ineffective)? $ autogen ocpasswd-args.def Works for me: $ autogen ocpasswd-args.def $ ls -gotr total 1140 -rw-r--r-- 1 2296 Jun 5 18:05 ocpasswd-args.def -r--r--r-- 1 7366 Jun 5 18:06 ocpasswd-args.h -r--r--r-- 1 32633 Jun 5 18:06 ocpasswd-args.c $ Mileage varies. * What was the outcome of this action? Error in template /usr/share/autogen/optlib.tlib, line 780 DEFINITIONS ERROR in /usr/share/autogen/optlib.tlib line 780 for ocpasswd-args.h: Error: value for opt passwd is `c' must be single char or 'NUMBER' Failing Guile command: = = = = = (error (sprintf Error: value for opt %s is `%s'\nmust be single char or 'NUMBER' (get name) (get value))) The complete context: CASE value=][= !E =][= (get-value-idx) =][= == '=]'\''[= == \\ =]'\\'[= ~~ [ -~]=]'[=value=]'[= =* num=][= (if (= number-opt-index 0) (error only one number option is allowed) ) (set! number-opt-index flag-index) (get-value-idx) =][= * =][=(error (sprintf Error: value for opt %s is `%s'\nmust be single char or 'NUMBER' (get name) (get value)))=][= ESAC=][= and that mumbo-jumbo basically matches the value of value against a number of expressions. It *SHOULD* match the [ -~] regular expression. The fact that it does not is troubling. I need to reproduce this, but, as noted, it works for me. If this can be reproduced with a either the following options or environment variables: export AUTOGEN_TRACE=everything AUTOGEN_TRACE_OUT='/tmp/ag-log.txt' --trace=every --trace-out='/tmp/ag-log.txt' then in theory I should have a shot at figuring out what is wrong by looking at ag-log.txt. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771904: unshar manpage: Pp (fwd)
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 lot of improvements to the way man pages get generated. Improvements -- bugs (until they get fixed). I fixed the missing newline, too. Thanks. I'll bump out a new release soon. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762019: make autogen:ARCH1 and libopts25-dev:ARCH2 co-installable
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 architectures happen exactly simultaneously, dpkg will error out during installation. Can you let me know which view you prefer? Use the latest wherein I was convinced to remove the timestamps? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747592: autogen: build hangs on testsuite (amd64)
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}
echo FAILURE REASON: $*
kill -15 ${AG_pid}
kill -1 ${AG_pid}
kill -2 ${AG_pid}
exit 1
} 8
sends out kill signals too quickly causing the kernel to get all confused.
Using this code instead:
die() {
echo Killing AutoGen ${AG_pid}
echo FAILURE REASON: $*
kill -15 ${AG_pid}
sleep 1
kill -1 ${AG_pid}
sleep 1
kill -2 ${AG_pid}
sleep 1
kill -9 ${AG_pid}
exit 1
} 8
seems to resolve the problem. Please retest. Thank you.
http://ftp.gnu.org/gnu/autogen/rel5.18.3/autogen-5.18.3.tar.xz
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747592: autogen: build hangs on testsuite (amd64)
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 FAIL. Reporting these problems needs to include the log files and other detritus left behind. tar cJf /tmp/failure.tar.gz /«PKGBUILDDIR»/autoopts/test should do the job. (Just grab everything.) Thank you -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747592: autogen: build hangs on testsuite (amd64)
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, When attempting to build autogen version from experimental, the build locks in the errors.test test. From information supplied by Andreas, I have determined that the shell process being run by autogen is trying to tell autogen to die with several kill signals. It is not dying. It would be interesting to know exactly which platforms show this problem. I saw an email of the issue on a Debian kfreebsd build. (What is that? Is it Debian or FreeBSD?) https://buildd.debian.org/fetch.cgi?pkg=autogenarch=kfreebsd-i386ver=1%3A5.18.3%7Epre34-1stamp=1399469529file=log Anyway, the new die function will wait a full second and finally use kill -9, if autogen hangs around through 3 kills (TERM, INT and HUP) and 3 seconds. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745990: autogen: please migrate to guile-2.0
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 sure the critical bugs in guile 2.0.{0,1,2} remain fixed, but I've not
tried 2.0.{9,10,11}, so no guarantee. But much more likely than not,
it should work.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745990: Info received (Bug#745990: autogen: please migrate to guile-2.0)
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 \ -Wall -Wno-format-contains-nul -c -o autogen-ag.o \ `test -f 'ag.c' || echo './'`ag.c In file included from /usr/include/guile/2.0/libguile/array-handle.h:28:0, from /usr/include/guile/2.0/libguile.h:34, from autogen.h:60, from ag.c:7: /usr/include/guile/2.0/libguile/error.h:40:24: error: expected ')' before '__attribute__' /usr/include/guile/2.0/libguile/error.h:40:24: error: expected ',' or ';' before ')' token and then from error.h (I had to download a copy): 39 SCM_API void scm_error (SCM key, const char *subr, const char *message, 40 SCM args, SCM rest) SCM_NORETURN; and finally, __scm.h: 79 #ifdef __GNUC__ 80 #define SCM_NORETURN __attribute__ ((noreturn)) 81 #else 82 #define SCM_NORETURN 83 #endif I've added a script called, fix-guile.sh that is _supposed_ to replace ((noreturn)) with ((__noreturn__)) and stash the result locally. I am not able to tell what happens in your build. I need to use the gl_STDNORETURN_H macro from gnulib. That module winds up creating a #define for noreturn thus: #ifndef noreturn #if 1200 = _MSC_VER # define noreturn /*empty*/ #else # define noreturn _Noreturn #endif #endif /* noreturn */ There are two fixes: 1. find out why __scm.h is not fixed (It is supposed to be...) 2. get a more recent Guile that uses __noreturn__ instead of noreturn. (Guile 2.0.11 fixes the noreturn problem.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745990: autogen: please migrate to guile-2.0
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 script assumed the old standard. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745990: autogen: please migrate to guile-2.0
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, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#728817: autogen: libopts-xx.x.x.tar.gz is not included
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 libsrc /usr/share/autogen/libopts-40.0.15.tar.gz (see http://autogen.sourceforge.net/doc/Licensing.html#Licensing) However this file is not shipped with debian. A full configure make make install of autogen will, indeed, install this file. I know that there are complaints about the amount of data in /usr/share/autogen, but still this tarball needs to be installed when the option processing templates get installed. (I also do not know how Debian slices and dices the various packages out of the autogen package, but if the option processing templates are installed in libopts-devel, then so should the library tarball. Essentially, that tarball is part of the code that gets emitted.) Thank you. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726150: linux-source-3.2: mmio address 0xbafe00 already in use
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. * What outcome did you expect instead? A faster boot. I get these messages on the boot console: [5.530004] SP5100 TCO timer: SP5100 TCO WatchDog Timer Driver v0.01 [5.530054] SP5100 TCO timer: mmio address 0xbafe00 already in use and then a long pause and timeout messages that do not appear in the dmesg output. I guess I'll poison the watch dog timer, but I don't feel good about doing stuff like that. Thanks for any suggested fixes or hackarounds! -- System Information: Debian Release: 7.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /bin/bash Versions of packages linux-source-3.2 depends on: ii binutils 2.22-8 ii bzip2 1.0.6-4 Versions of packages linux-source-3.2 recommends: ii gcc 4:4.7.2-1 ii libc6-dev [libc-dev] 2.13-38 ii make 3.81-8.2 Versions of packages linux-source-3.2 suggests: ii libncurses5-dev [ncurses-dev] 5.9-10 ii libqt4-dev 4:4.8.2+dfsg-11 ii pkg-config 0.26-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726150: Acknowledgement (linux-source-3.2: mmio address 0xbafe00 already in use)
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? Contact listmas...@lists.debian.org
Bug#715311: autogen built wilthout -Wno-format-contains-nul
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 let the autobuilders chew on it. May as well get the next release: 5.18 I don't have a huge parallel development operation, so I wind up bumping that second number when it feels like enough has changed since 5.17. Anyway, I think the pre14 and 5.18 are substantially the same. Cheers - Bruce -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#715955: PATCH: listing ambiguous entries must ignore doc options
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_msg, stderr);
do {
+if (pOD-pz_Name == NULL)
+continue; /* doc option */
+
if (strneqvcmp(name, pOD-pz_Name, nm_len) == 0)
fprintf(stderr, zambig_file, hyph, pOD-pz_Name);
@@ -375,7 +378,7 @@ opt_find_long(tOptions * opts, char const
* opt_name, tOptState * state)
booldisable = false;
int ct;
-if (nm_len = 0) {
+if (nm_len = 1) {
fprintf(stderr, zInvalOptName, opts-pzProgName, opt_name);
(*opts-pUsageProc)(opts, EXIT_FAILURE);
/* NOTREACHED */
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#715311: autogen built wilthout -Wno-format-contains-nul
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 warning from the other formatting warnings in GCC. Please suppress it. I don't use Debian, but I got a build failure report for MIPS: https://buildd.debian.org/fetch.cgi?pkg=autogenarch=mipsver=1%3A5.17.4-2stamp=1373223863file=log libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I.. -I../autoopts -D_FORTIFY_SOURCE=2 -DPKGDATADIR=\/usr/share/autogen\ -g -O2 -Wformat -Werror=format-security -Wall -c libopts.c -fPIC -DPIC -o .libs/libopts_la-libopts.o In file included from libopts.c:24:0: enum.c: In function 'enum_err': enum.c:114:13: warning: embedded '\0' in format [-Wformat-contains-nul] fprintf(option_usage_fp, ENUM_ERR_LINE, *(paz_names++)); ^ enum.c:137:9: warning: embedded '\0' in format [-Wformat-contains-nul] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702644: usage.test keeps running beyond package build completion
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 have kill_delay=3), resulting in the watchdog part waiting for up to 510 seconds, which generally is far longer than the remaining package build takes. As a result, files remain open and the package build cannot complete properly when working in a chroot (and waiting to umount the build directory). Most likely it suffices to reduce the kill_delay for usage.test, but a proper implementation would terminate the watchdog whenever the test itself has ended properly. Makes sense. I did something quick and dirty because I've had stuff hang forever and this was easy to do. I'm open to suggestions -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702644: usage.test keeps running beyond package build completion
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
kill_delay to 10 seconds (all others have kill_delay=3), resulting in the
watchdog part waiting for up to 510 seconds, which generally is far longer
than
the remaining package build takes.
As a result, files remain open and the package build cannot complete properly
when working in a chroot (and waiting to umount the build directory).
Ah. The process should cd to / then, too?
Most likely it suffices to reduce the kill_delay for usage.test, but a proper
implementation would terminate the watchdog whenever the test itself has
ended properly.
Makes sense. I did something quick and dirty because I've had stuff hang
forever and this was easy to do. I'm open to suggestions
Maybe this? AG_TIMEOUT is an adjustment for the platform speed.
51 is a pretty high number for that.
diff --git a/autoopts/test/defs.in b/autoopts/test/defs.in
index cf000eb..f797d64 100644
--- a/autoopts/test/defs.in
+++ b/autoopts/test/defs.in
@@ -343,14 +343,19 @@ trap failure 'test ${testname} killed on timeout'
15
( ( exec /dev/null 21 /dev/null
test -z ${kill_delay} kill_delay=3
kill_delay=`expr $kill_delay '*' $AG_TIMEOUT`
-sleep ${kill_delay}
-ps -p $$ || exit
+while test ${kill_delay} -gt 0
+do sleep 1
+ps -p $$ || exit 0
+kill_delay=`expr $kill_delay - 1`
+done
kill -15 $$
sleep 1
ps -p $$ || exit
-test -d ${builddir}/FAILURES || \
- mkdir ${builddir}/FAILURES
-mv -f `dirname $logfile` ${builddir}/FAILURES/.
+test -d $builddir {
+ test -d ${builddir}/FAILURES || \
+mkdir ${builddir}/FAILURES
+ mv -f `dirname $logfile` ${builddir}/FAILURES/.
+}
kill -9 $$
)
)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629142: Processed: unarchiving 629142
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 another is left around that causes the successive run to fail. Please don't ask anything silly like, What might that be? (I'd have a patch, if I knew. ;) Sorry for the cheeky answer. I _do_ wish I knew. Pretty clearly, the autogen process is, indeed, shot dead. What might cause it to die without a death rattle though? SIGTERM, SIGHUP and SIGINT should all be catchable and I have signal handlers for all signals that can be caught. What if we add some delays into the signal emissions? It feels like grasping at straws. The best answer is for me to be able to reproduce the problem. I am not able, however. It works for me. :( -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629142: Processed: unarchiving 629142
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/test'
...
errors- logfile=/tmp/AUTOGEN/autogen-5.16.2/autoopts/test/testdir/errors.log
errors- exec
/bin/bash: line 5: 6139 Killed TERM='' top_builddir=../..
${dir}$tst
FAIL: errors.test
1 of 1 test failed
That exec line is redirecting everything to:
/tmp/AUTOGEN/autogen-5.16.2/autoopts/test/testdir/errors.log
Is that file available?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629142: Processed: unarchiving 629142
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.
;;
* )
${SED} '/ value /s/Y/X/;s/ ifndef =.*//' ${testname}.def ${testname}-2.def
${AG_L} ${testname}-2.def \
failure AutoGen processed conflicting flag values
;;
esac
The ${testname}-2.def is deliberately incorrect and it is expected to fail.
The problem is that I wrote the script expecting to continue past the
failure command when ${AG_L} fails. I see this in the
errors-aglog-ao-12479.log file:
ag die 'duplicate option value characters:' X
die echo 'Killing AutoGen 12961'
Killing AutoGen 12961
die echo 'FAILURE REASON: duplicate option value characters: X'
FAILURE REASON: duplicate option value characters: X
die kill -15 12961
die kill -1 12961
die kill -2 12961
die exit 1
The kill -* 12961 commands are sending kill signals to the autogen process.
That should cause it to exit non-zero, resulting in this text in errors.log:
errors-run_ag /old-home/bkorb/ag/ag/agen5/autogen
-L/old-home/bkorb/ag/ag/autoopts/tpl -L/old-home/bkorb/ag/ag/autoopts/tpl --trace=every
'--trace-out=errors-aglog-ao-9174.log' errors-2.def
AutoGen aborting on signal 2 (Interrupt) in state EMITTING
processing template /old-home/bkorb/ag/ag/autoopts/tpl/optlib.tlib
on line 59
for function EXPR (14)
errors- cleanup
Instead the AutoGen aborting on signal X message is missing.
The file ERR/autoopts/test/FAILED-errors/errors.log ends abruptly.
=
That's the cause. Now, how to fix it? I know I cannot perform
this test with certain not-good-enough shells, so perhaps
my test for not good enough is not good enough? What is the /bin/sh
program? If not bash, I'll have to tweak the defs.in file
to ensure it is not running in whatever shell it is that is inadequate.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629142: Processed: unarchiving 629142
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=../..
${dir}$tst
FAIL: errors.test
---
Sadly I cannot provide more info on this...
Sadly, I cannot imagine how a change that can only affect the compilability
of a single module can possibly affect a test. :(
Ah, wait, before it didn't compile and never got to a test.
Now it compiles and fails in a test. All the more reason
for not quickly pushing a change. I will definitely need
all the test detritus to piece together the failure.
It would be especially helpful with:
cd $top_builddir/autoopts/test
make verbose TESTS=errors.test
because it will yield the exact reason the script shot down
its invoking autogen process. line 5 is going to be pretty
early on -- as in the SHELL_INIT_STR string.
Anyway, I'll be waiting for whatever you can gather.
Thanks - Bruce
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676115: autogen: FTBFS: make[2]: *** No rule to make target `invoke-xml2ag.texi'. Stop.
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 FTBFS on ia64: https://buildd.debian.org/status/fetch.php?pkg=autogenarch=ia64ver=1%3A5.16-1stamp=1338699057 Somewhere buried in there should be a little more information about: MAKE=/usr/bin/make ./mk-agen-texi.sh mk-agen-texi FAILED: MAKE of /ëPKGBUILDDIRû/xml2ag/invoke-xml2ag.texi failed. and that will reveal what actually failed. But let's avoid tail chasing and wait until we know the exact cause of the ia64 failure. (but you could add a set -x command early in the mk-agen-texi.sh script, if you like.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661355: autogen: New upstream version 5.14
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.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#635311: /usr/share/doc/autogen/html/*: please enumerate the files starting from 1
* /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.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#635311: /usr/share/doc/autogen/html/*: please enumerate the files starting from 1
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 that they get from an upstream. I've forgotten the name of the ultimate project for these scripts, but I think that's where the problem lies (unless I've misused the script in some way, but I think the make rule is fairly straight forward. But I cannot even see your problem in my setup anyway. The rule: gnudocs : $(srcdir)/gendocs_template agdoc.texi title=`sed -n 's/^@title *//p' agdoc.texi` ; \ opts='--texi2html' ; \ $(POSIX_SHELL) $(srcdir)/gendocs.sh $$opts autogen $$title And the source of the files (from my perspective): $ find gnulib-base -name 'gendoc*' gnulib-base/modules/gendocs gnulib-base/doc/gendocs_template_min gnulib-base/doc/gendocs_template gnulib-base/build-aux/gendocs.sh The results I see: $ find * -type f -name '*_0*.html' html_chapter/START_005fOPT.html html_chapter/autogen-source_002dtime.html html_chapter/SCM-out_002dswitch.html html_chapter/OPT_005fVALUE_005fname.html [...] html_chapter/csh_002fzsh-caveat.html html_node/START_005fOPT.html html_node/autogen-source_002dtime.html html_node/SCM-out_002dswitch.html [...] html_node/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 Korbbk...@gnu.org Subject: Re: Bug#635311: /usr/share/doc/autogen/html/*: please enumerate the files starting from 1 To: Regid Ichiraregi...@yahoo.com, 635...@bugs.debian.org Date: Monday, July 25, 2011, 4:00 PM * /usr/share/doc/autogen/html/* files are enumerated starting from 0, -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629142: autogen: FTBFS: Various aborts
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 the same error message. Then HURD is not #defined in hurd. I had to read glibc source code to tease out that name, but I guess I read wrong. What _is_ the #define that says the compile is for hurd? On other platforms, the _IOWR macro just works. HURD itself is broken. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629142: autogen: FTBFS: Various aborts
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 glibc/gcc source code to tease out that name, but I guess I read wrong. What _is_ the #define that says the compile is for hurd? On other platforms, the _IOWR macro just works. HURD itself is broken. I've been told it's __GNU__ I would surely hope not. The reason being is that there is this campaign on to get everyone to use GNU/Linux as the name of the platform commonly referred to as Linux. If __GNU__ were used to mean GNU/Hurd, then it would severely muddy the waters about what is meant by GNU. So, please tell me the marker is __hurd__ (or some variation) and not __GNU__. It would be _so_ wrong. Perhaps it is __gnu_hurd__ ?? It would be *really* *cool* if there were a page lying around somewhere that one could reference. Here are the results of grepping the entire gcc compiler source tree: $ find * -type f|fgrep -v '/.svn/' | xargs egrep -i $'^[ \t]*#[ \t]*if.*hurd' boehm-gc/include/private/gcconfig.h:# ifdef HURD boehm-gc/os_dep.c:#if defined(IRIX5) || defined(OSF1) || defined(HURD) boehm-gc/os_dep.c:# if defined(IRIX5) || defined(OSF1) || defined(HURD) boehm-gc/os_dep.c:# ifdef HURD boehm-gc/os_dep.c:# if defined(HURD) boehm-gc/os_dep.c:# if defined (IRIX5) || defined(OSF1) || defined(HURD) boehm-gc/os_dep.c:# if defined(_sigargs) || defined(HURD) || !defined(SA_SIGINFO) boehm-gc/os_dep.c:# if defined(HPUX) || defined(LINUX) || defined(HURD) \ boehm-gc/os_dep.c:# if defined(HURD) gcc/testsuite/gcc.dg/cpp/assert4.c:#if defined __gnu_hurd__ It takes a long time. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629142: autogen: FTBFS: Various aborts
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: fmemopen.c: In function 'ag_fmemioctl': fmemopen.c:752:10: error: '_IOT__IOTBASE_fmemc_get_buf_addr_t' undeclared That means that hurd has a non-standard definition for _IOWR. Very, very *VERY* non standard. Ick! Phew! #ifdef HURD #define _IOT__IOTBASE_fmemc_get_buf_addr_t sizeof(fmemc_get_buf_addr_t) #endif Fixed in coming release. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630176: autogen: Sets rpath to /usr/lib
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 in the
default search path.
There really is no portable way to determine if a particular path
is in the default search path or not. Especially since some distros
like /lib others like /lib64 on top of the /usr/lib variations.
That not withstanding, the change of the cleanup code in the script from this:
test -n ${ldopts} {
ldflags=${ldopts}${libdir} ${ldflags}
libs=${ldflags}
}
to this:
case ${libdir} in
/lib | /lib64 | /usr/lib | /usr/lib64 )
ldopts=''
ldflags=-lopts
;;
* )
test -n ${ldopts} \
ldflags=${ldopts}${libdir} ${ldflags}
;;
esac
}
libs=${ldflags}
should work until someone claims that one of those four directories
is not on *their* default search path so they are broken. You cannot
go mucking around in /etc/ld.so.conf both because it isn't portable
and because it may not actually match what ld.so is doing.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630176: Info received (Bug#630176: autogen: Sets rpath to /usr/lib)
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} \
ldflags=${ldopts}${libdir} ${ldflags}
;;
esac
libs=${ldflags}
test ${includedir} = /usr/include cflags=
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629142: autogen: FTBFS: Various aborts
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 for a few results, ... 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: fmemopen.c: In function 'ag_fmemioctl': fmemopen.c:752:10: error: '_IOT__IOTBASE_fmemc_get_buf_addr_t' undeclared That means that hurd has a non-standard definition for _IOWR. By the time the compiler sees this: _IOWR(FMEMC_IOCTL_BASE, FMEMC_GET_BUF_ADDR, fmemc_get_buf_addr_t) the result should be a number. Looks like hurd just token pastes stuff. It turns out that it is only used in code that is never called, The simplest fix is to #if 0 the code (the ag_fmemioctl() function). Neither fopencookie nor funopen really make for a fully funcional FILE* return type, so I wrote my own layer over that that is somewhat more usable. It includes a fake ioctl for getting the current address of the buffer. Not used here. Probably too much information. Sorry. Anyway, just #if 0-away that function and all is fine. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629142: autogen: FTBFS: Various aborts
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 digging. Hurd presumes that it can make requirements on the arguments to the _IOWR() macro. This flys in the face of decades of UNIX history. glibc documents this weirdo-ness in an obscure header: /* Standard flavors of ioctls. _IOT_foobar is defined either in this file, or where struct foobar is defined. */ [...] #define _IOWR(g, n, t) _IOC (IOC_INOUT, (g), (n), _IOC_ENCODE_TYPE (t)) /* These macros do some preprocessor gymnastics to turn a TYPESPEC of `struct foobar' into the identifier `_IOT_foobar', which is generally defined using `_IOT' (above) in whatever file defines `struct foobar'. For a TYPESPEC that does not begin with `struct' produces a different identifier: `int' produces `_IOT__IOTBASE_int'. These identifiers are defined for the basic C types above. */ #define _IOC_ENCODE_TYPE(typespec) _IOC_ENCODE_TYPE_1(_IOTBASE_##typespec) #define _IOTBASE_struct #define _IOC_ENCODE_TYPE_1(typespec)_IOC_ENCODE_TYPE_2(typespec) #define _IOC_ENCODE_TYPE_2(typespec)_IOT_##typespec glibc for Hurd is wrong. Hurd should use alternate macros for creating ioctl id numbers (_IOWRT ?). I doubt Mr. Glibc would agree, however. The next release will be fixed for Hurd with: #ifdef HURD #define _IOT__IOTBASE_fmemc_get_buf_addr_t sizeof(fmemc_get_buf_addr_t) #endif I don't particularly want to keep the fmemopen.c file out of sync with my private library. Elsewhere, I *do* use the fake ioctl. *sigh*. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629142: autogen: FTBFS: Various aborts
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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629142: autogen: FTBFS: Various aborts
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 release,
and so the version as it is will probably not make it to testing.
I'd say not. I was really describing my perspective :)
I can atleast reproduce the hang on my own machine using:
export HOME=/non-existing
Works for me. Works for me on the build boxes at ntp.org, too.
Some environmental thing, which is why I'd have preferred to
examine the failure more closely. Setting HOME to a bogus directory
should not cause things to fall over. It should cause things to
be not found and the process should continue.
I can run various tests for you if you want. I should have access
to all those arches that failed. I don't know exactly what the policy
is for giving other people access, but I'm also not sure it's
needed at this time.
I am sure all would be overkill. Once the cause is determined,
my guess one fix will fix 'em all.
There were a few suspicious things in the build-the-doc template that
seemed a little dodgy. I reworked them and it still works correctly
for me. I don't think I've touched this stuff in a really long time...
diff --git a/doc/auto-opts.tpl b/doc/auto-opts.tpl
index 5211e60..b062c89 100644
--- a/doc/auto-opts.tpl
+++ b/doc/auto-opts.tpl
@@ -200,16 +200,16 @@ Yields a program which, when run with @file{--help},
prints out:
@example
[= (out-push-new) \=]
set -x
-log_file=${HOME}/default-test-log.txt
+log_file=${tmp_dir}/ao-doc-log
exec 72 ; exec 2 ${log_file}
-
TOPDIR=`cd ${top_builddir} /dev/null ; pwd`
OPTDIR=${TOPDIR}/autoopts
{
cd ${tmp_dir}
+ chmod 666 *.def
echo 'config-header = config.h;' default-test.def
- HOME='' run_ag default-test.def
+ HOME=${tmp_dir} run_ag default-test.def
test -f default-test.c || die 'NO default-test.c PROGRAM'
opts=-o default-test -DTEST_DEFAULT_TEST_OPTS ${INCLUDES}
@@ -218,9 +218,13 @@ OPTDIR=${TOPDIR}/autoopts
test -x ./default-test || die 'NO default-test EXECUTABLE'
} 2
-test $? -eq 0 || die Check log file ${log_file}
+test $? -eq 0 || {
+ printf '\n\ncannot build default test\n'
+ cat $log_file
+ die cannot build AutoOpts doc
+} 27 17
-HOME='$HOME/.default_testrc' ${tmp_dir}/default-test --help | \
+HOME=${tmp_dir} ${tmp_dir}/default-test --help | \
sed 's, ,,g;s,\([@{}]\),@\1,g'
exec 27 7-
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628316: autogen: FTBFS: tests failed
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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628316: autogen: FTBFS: tests failed
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
Bug#624755: autogen FTBFS with GCC 4.6
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 (undefining SECOND): adapt to new GCC. 5.10 is a little long in the tooth: January, 2010. Please use 5.11.9 when I release it in a couple of days. Thank you. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#619791: autogen: ftbfs with dash as /bin/sh (bashism in autoopts 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 subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562791: Bug#562607: Patch for NMU
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 just base it on the upstream version. Probably something to always do. I'm not a Debian packaging person, so I don't really know what dh_makeshlibs does. - I've just removed some code from autoopts-config.in. It says it's autogenerated, but I can't find the source for that. Upstream probably added this code for some reason, so might want a better patch. In any case, there is no reason to add the rpath on a Debian system since it's configured for /usr/lib and that's always in the dynamic linker's search path. I didn't remove the -L/usr/lib because it doesn't hurt anything. That stuff is there because without it, when you run a build and make check, the executables will link against the installed version. Sometimes it causes breakage, but most times it silently tests the installed libraries instead of what you think you're testing. I need a reliable way to ensure that make check finds the autoopts/.libs/... stuff before any installed versions. Portably. Not just for Debian. :( Thanks -Bruce -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#567711: autogen: free(): invalid pointer in testsuite
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]
../rc[0x40a4f1]
../rc[0x40b6d1]
../rc[0x401da3]
/lib/libc.so.6(__libc_start_main+0xfd)[0x7f78a4f12abd]
../rc[0x401cb9]
=== Memory map:
[...]
With a core file this looks like:
#4 0x0040a511 in doPrognameEnv (pOpts=0x613220, type=ENV_IMM)
at environment.c:106
That value is obtained from ao_string_tokenize( pczOptStr );
Memory management structures have become corrupt.
In chasing this a bit, I did discover a bug I introduced:
This assert became obsolete in longOptionFind():
do {
if (SKIP_OPT(pOD)) {
if ( (pOD-fOptState != (OPTST_OMITTED | OPTST_NO_INIT))
|| (pOD-pz_Name == NULL))
continue;
}
else assert(pOD-pz_Name != NULL);
It now means that the entry should be ignored. The correct form is now:
do {
/*
* If option disabled or a doc option, skip to next
*/
if (pOD-pz_Name == NULL)
continue;
if ( SKIP_OPT(pOD)
(pOD-fOptState != (OPTST_OMITTED | OPTST_NO_INIT)))
continue;
If this fixes the problem, I'll be a happy camper and not chase it any more. :)
Thanks -Bruce
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562791: libopts25: didn't bump shlibs or soname.
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 validate this every time. It has worked previously and I've not invalidated any data structures in a long time. On Sun, Dec 27, 2009 at 3:57 PM, Kurt Roeckx k...@roeckx.be wrote: Package: libopts25 Version: 5.10-1 Severity: serious Hi, I build a program in unstable and tried to run it in stable, and got this: called AutoOpts function with structure version 33:0:0. This exceeds the compiled library version: failed! Either the shlibs should have been bumped so that I got a 5.10 version or the soname should be changed to reflect that older structures aren't supported anymore. Kurt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#555500: autogen: FTBFS: usr/share/info/dir exists in debian/tmp but is not installed to anywhere
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 dh_install: usr/share/info/dir exists in debian/tmp but is not installed to anywhere dh_install: missing files, aborting make: *** [binary-arch] Error 1 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2 Thanks for the CC. I'm not an autoconf guru, so I don't know the fix. I believe that file gets created when the .info files get installed. It isn't anything that I do directly. I've you've got some hints about what can be done, I'd appreciate. Thanks - Bruce -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#324785: remsync.info.gz: empty sections
RE: message #6: ``All of these are empty. One will never be able to find out what TYPE is.'' It doesn't take too much digging: $ mailshar --help;mail-files --help Usage: mailshar [OPTION...] DEST FILE ... with OPTION in: --help display this help and exit --version output version information and exit -S SUBJECT use shar: SUBJECT as subject line -s SIZE decide size of each part in Kb, default 60 -M decide how to send each file separately -T avoid calling compress, gzip, bzip2 nor uuencode -B force calling uuencode -z force calling gzip and uuencode -j force calling bzip2 and uuencode -Z force calling compress and uuencode -x trace script If none of -MTBzjZ are given, -z is automatically selected if *none* of the FILEs have an .arc, .exz, .gif, .z, .gz, .bz2, .Z, .zip, .tgz or .zoo suffix. Usage: mail-files [OPTION] DESTIN TYPE SUBJECT FILE ... Where: OPTION is: --help display this help and exit --version output version information and exit -x trace script DESTINis a list of email addresses TYPE is a subject introduction word or short phrase SUBJECT is a longer description of the contents 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 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...@lists.debian.org
Bug#411261: doc patch as applied
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,28 @@ .I Uuencode and .I uudecode -are used to transmit binary files over transmission mediums -that do not support other than simple -ASCII -data. +are used to transmit binary files over channels that support only +simple ASCII data. .PP .I Uuencode reads .I file -(or by default the standard input) and writes an encoded version -to the standard output. -The encoding uses only printing -ASCII -characters and includes the -mode of the file and the operand +(or by default the standard input) and writes an encoded version to +the standard output, using only printable ASCII characters. +The encoded output begins with a header, for use by +.IR uudecode , +which records the mode of the input file and suggests .I name -for use by -.I uudecode. -If +for the decoded file that will be created. (If .I name is .I /dev/stdout -the result will be written to standard output. By default the standard -UU encoding format will be used. If the option +then +.I uudecode +will decode to standard output.) The encoding has the format +documented at uuencode(5), unless the option .I \-m -is given on the command line +is given, when .B base64 encoding is used instead. .PP @@ -96,8 +93,8 @@ .I name is /dev/stdout the result will be written to standard output. .I Uudecode -ignores any leading and trailing lines. The program can automatically decide -which of the two supported encoding schemes are used. +ignores any leading and trailing lines. The program determines from the +header which of the two supported encoding schemes was used. .SH EXAMPLES The following example packages up a source tree, compresses it, uuencodes it and mails it to a user on another system. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532791: autogen: FTBFS on Debian GNU/Hurd [Patch]
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 compilation issue that causes the cast to be a problem? It very much looks like something added to solve another problem that would re-emerge were this cast removed. So, instead of fixing it so just GNU/Hurd works, I need to know the cause. Thank you - Bruce -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#532791: autogen: FTBFS on Debian GNU/Hurd [Patch]
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 never gotten to reworking the stuff based on gnulib. So, is the cast necessary? I don't know. I (or my co-conspiritor at the time) probably had some reason at the time. Don't know if it is still valid. Anyway, . but here is the error if it is left in: libtool: compile: i486-gnu-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -I.. -I../autoopts -DPKGDATADIR=\/usr/share/autogen\ -g -O2 -O2 -MT libopts_la-libopts.lo -MD -MP -MF .deps/libopts_la-libopts.Tpo -c libopts.c -fPIC -DPIC -o .libs/libopts_la-libopts.o In file included from libopts.c:10: autoopts.h:48:40: error: missing binary operator before token 4096 Making sure that size_t has been defined anywhere these macros get used should do the trick. missing binary operator means the compiler thinks that size_t is a variable name instead of a data type. That should be the correct fix. Again, thank you for raising the issue. Regards, Bruce -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508657: autogen/autooptns is broken on powerpc
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
output 8 spaces. The macro representing the executable seems to
have disappeared.
$ fgrep CLexe opt*.tpl
optcode.tpl:${CLexe} --fill \\_EOF_\n tmp-text \n_EOF_)))
opthead.tpl: CLexe=${1}
opthead.tpl: test_exe ${CLexe} || \
optlib.tpl:for f in %s ; do echo %s${f} ; done | ${CLexe} -I4 --spread=3
--sep=,
optlib.tpl:${CLexe} -I16 --fill --first='/* TRANSLATORS:' \\_EOF_
optmain.tpl:${CLexe} --spread=1 -I4
_EOProcs_\n%s\n_EOProcs_ )
optmain.tpl: (shellf ${CLexe} -I8 --spread=2 _EOF_\n%s\n_EOF_
optmain.tpl: ${CLexe} -I8 --spread=2 --sep=',' -f'\%s\' _EOF_\n
optmain.tpl: ${CLexe} -I8 --spread=2 --sep=',' -f'\%s\' _EOF_\n
The opthead.tpl code looks in several places to find the right one.
I suspect it does that and something triggers the server shell change.
I'll chase that down. It must be fixed. Meanwhile:
SHELL=/bin/sh autogen checkoptn.def
ought to work around the issue. Terribly sorry. It is very
difficult to work around the various quirks of default shells
that I don't even have access to. I have to rely on kind people
to give excruciatingly precise information about the details of
the failure. In this case:
autogen --trace=everything --trace-out=command-not-found.log checkoptn.def
should most likely provide me with enough information to diagnose
the issue. Thank you.
Regards, Bruce
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#469479: newer smartmontools for another reason
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, Yes, I was putting it into our smartd.conf file. For myself, whenever I design a configurable into a program, it is always selectable by either command line or config file. So I tend to use configurable and option interchangeably. (See: http://www.gnu.org/software/autogen/autoopts.html ) I have this same incredible lag time problem even with my own little tool. I fixed a config file parsing issue about 2.0 years ago, but the etch version has an autogen from 2.1 years ago. Here, I'm just trying to encourage Debian folks to hasten the cycle a little bit for smartmontools, though I'd surely appreciate an autogen refresh, too. :) Cheers, Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499533: etch-backports desperately needs an autogen refresh
Package: autogen Version: 1:5.9.1-1 Severity: important Many months before the etch package list was frozen, a fix went into autogen for parsing complex values in config files. (Actually, in the libopts library code.) However, it turned out that the last autogen version promoted into testing was promoted just a little while before the autogen fix. The consequence is that the recently released Debian-etch has an autogen from over two years ago. Certain folks here where I work would rather not be using my private sources, even though they are published. So, 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') Architecture: i386 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-amd64 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- no debconf information This email and any attachments thereto may contain private, confidential, and privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#469479: newer smartmontools for another reason
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 UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#469479: newer smartmontools for another reason
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 2008-05-08 21:56 [x86_64-unknown-linux-gnu] (local build) Copyright (C) 2002-8 by Bruce Allen, http://smartmontools.sourceforge.net Also, the version that announces itself as 5.38 does *not* parse -R. My primary concern, of course, is that the completely up-to-date etch variation be able to report temperature correctly. :) Thanks -Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#469479: newer smartmontools for another reason
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 WORST columns, where it should instead pay attention to RAW_VALUE for the drive temperature. Resolution (from web): The solution is to change the drive specifier lines in /etc/smartd.conf. This hint is from a web page and from the man page man smartd.conf. The appropriate lines from /ect/smartd.conf read: /dev/hda -a -R 194 /dev/sda -a -d ata -R 194 Unfortunately, you have to upgrade to 5.39 to parse that option. Please? Thank you. Regards, Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#496932: Error message is insufferably obtuse
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 shared system, so shutting it down on 30 or 40 developers is impractical 3. The actual problem is the existence if a hidden, secretive, undocumented file CF: On Thu, Apr 26, 2007 at 09:28:03PM +0200, Gregory Colpart wrote: Hi, I have same problem here with deleting lock file and nfs:/home. My strange workaround is: % mv ~/.mozilla ~/foo % mv ~/foo ~/.mozilla Oops, sorry, I'm confused. The problem was presence of '.parent.lock' file. I knew 'lock' file but not other Mozilla lock files like '.parent.lock' or '.parentlock'... So, for God's sake, augment the message with some information about that horrid little secret file so it won't be a secret any more. Two hours of messing around fixing a config problem that iceweasel created for itself is, well, pretty nutty. Thank you. P.S. another little problem, I am always getting warned over and over and over about entering an encrypted site. The only option the popup gives me is to always warn about it in the future. Since I am always warned and I do not seem to be able to turn it off, how about adding an option to make the warning shut up? [ ] please keep bothering me about this [ ] leave me alone. do not bother me about this any more ever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#409056: libopts version number
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? The more likely scenario is that I intended to bump both version age, or else I meant to bump the revision and bumped AO_AGE instead. Either way, something needs a fix. Next release will clean it up, but meanwhile please use your debian patch the original stuff to decrement the age. Sorry. :( Thanks! Regards, Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#373666: autogen: FTBFS: bashisms in build commands
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 much more restrictive. This is the code in question: if test -z $top_srcdir || test ! -d $top_srcdir; then echo NOTICE: Setting top_srcdir to .. 2 top_srcdir=.. fi if test ! -f $top_srcdir/VERSION ; then echo error $top_srcdir/VERSION file missing 2 kill -TERM $AG_pid fi f=`egrep '^AG_' $top_srcdir/VERSION` eval $f /dev/null echo $AG_VERSION I've built dash and then run an experiment: $ export top_srcdir=$PWD $ cd agen5/ $ $dash \_EOF_ set -x if test -z $top_srcdir || test ! -d $top_srcdir; then echo NOTICE: Setting top_srcdir to .. 2 top_srcdir=.. fi if test ! -f $top_srcdir/VERSION ; then echo error $top_srcdir/VERSION file missing 2 kill -TERM $AG_pid fi f=`egrep '^AG_' $top_srcdir/VERSION` eval $f /dev/null echo $AG_VERSION _EOF_ + test -z /home/bkorb/ag/rel/rel5.8.4/autogen-5.8.4 + test ! -d /home/bkorb/ag/rel/rel5.8.4/autogen-5.8.4 + test ! -f /home/bkorb/ag/rel/rel5.8.4/autogen-5.8.4/VERSION + egrep ^AG_ /home/bkorb/ag/rel/rel5.8.4/autogen-5.8.4/VERSION + f=AG_MAJOR_VERSION=5 AG_MINOR_VERSION=8 AG_REVISION=$AG_MAJOR_VERSION.$AG_MINOR_VERSION AG_PATCHLEVEL=.4 AG_VERSION=$AG_REVISION$AG_PATCHLEVEL + eval AG_MAJOR_VERSION=5 AG_MINOR_VERSION=8 AG_REVISION=$AG_MAJOR_VERSION.$AG_MINOR_VERSION AG_PATCHLEVEL=.4 AG_VERSION=$AG_REVISION$AG_PATCHLEVEL + AG_MAJOR_VERSION=5 + AG_MINOR_VERSION=8 + AG_REVISION=5.8 + AG_PATCHLEVEL=.4 + AG_VERSION=5.8.4 + echo 5.8.4 5.8.4 So, you are having some sort of problem, but it has been mischaracterized. It is not due to shell script syntax. Regards, Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#373666: [EMAIL PROTECTED]: Log for failed build of autogen_1:5.8.3-2 (dist=unstable)]
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 initial extraction. The syntax of that fragment is Bourne (and hence POSIX) compliant. The question is, ``Why did the shell die?'' If there is a core file left around, it could be debugged. Another option is to modify the autogen package so that in the file autogen*/agen5/opts.def the line: version = ` is changed to read: version = ` set -x if the set -x does not fire, then your dash thingey has trouble behaving as a server shell (stdin/stdout redirected to a pair of pipes to another process). If it does fire, you'll see the shell trace in stderr and it should be obvious what is going awry. The code in agen5/agShell.c has the code for managing a server shell. FYI: $ (export SHELL=$dash top_builddir=.. top_srcdir=.. PATH=`cd ../columns;pwd`:$PATH ; export top_builddir top_srcdir PATH ; /home/bkorb/ag/ag/agen5/autogen -L../autoopts --definition=./xmlopts.def) Changing server shell from /home/bkorb/tools/dash/dash-0.5.3/_i/bin/dash to /bin/sh $ ls -l /bin/sh lrwxrwxrwx 1 root bin 45 Jun 17 10:29 /bin/sh - /home/bkorb/tools/dash/dash-0.5.3/_i/bin/dash It is not dash. I have to go now. Thanks for your help. Regards, Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#373666: autogen: FTBFS: bashisms in build commands
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 BASH (or one that understands ``set -o posix''). This should not cause a problem for building the product. The code fragment below is Bourne-compatible, so I think you were using a non-Bourne-compatible shell. Don't do that. *A* shell is required, as are a rudamentary make and an ANSI-cc compiler. Aren't these assumed dependencies? Cheers - Bruce Last command issued: cd /build/buildd/autogen-5.8.3/xml2ag if test -z $top_srcdir || test ! -d $top_srcdir; then echo NOTICE: Setting top_srcdir to .. 2 top_srcdir=.. fi if test ! -f $top_srcdir/VERSION ; then echo error $top_srcdir/VERSION file missing 2 kill -TERM $AG_pid fi f=`egrep '^AG_' $top_srcdir/VERSION` eval $f /dev/null echo $AG_VERSION -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#373666: autogen: FTBFS: bashisms in build commands
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_builddir top_srcdir PATH ; /build/buildd/autogen-5.8.3/agen5/autogen -L../autoopts --definition=./xmlopts.def Closing server: Broken pipe signal (13) received Last command issued: cd /build/buildd/autogen-5.8.3/xml2ag if test -z $top_srcdir || test ! -d $top_srcdir; then echo NOTICE: Setting top_srcdir to .. 2 top_srcdir=.. fi if test ! -f $top_srcdir/VERSION ; then echo error $top_srcdir/VERSION file missing 2 kill -TERM $AG_pid fi f=`egrep '^AG_' $top_srcdir/VERSION` eval $f /dev/null echo $AG_VERSION echo echo ShElL-OuTpUt-HaS-bEeN-cOmPlEtEd - 2 Closing server: Broken pipe signal (13) received [...] FSM Error: in state 6 (need_value), event 8 (;) is invalid invalid transition: in /build/buildd/autogen-5.8.3/agen5/opts.def on line 65 token in error: `;' [[...error-text]] #ifndef XML2AG include = - _END_INCLUDE #include autogen. Likely causes: a mismatched quote, a value that needs quoting, or a missing semi-colon Test fails with dash as /bin/sh Please fix this or build-depends on bash I must be blinded by staring at this too long. What is it about this script fragment that is Bourne-incompatible? Looks pretty vanilla to these tired eyes... Thanks - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340851: Still FTBFS under pbuilder
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 fixes the mmap issues on the alpha. Umm, just to make it clear, all the results I sent were on my Pentium laptop, not on alpha. Sorry if I somehow gave the impression these were alpha results. Thanks. I have just verified it on an Alpha, just to be certain. 5.8.3 works on an alpha machine that was failing before. Thanks - Bruce
Bug#340851: Still FTBFS under pbuilder
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 fixes the mmap issues on the alpha. Umm, just to make it clear, all the results I sent were on my Pentium laptop, not on alpha. Sorry if I somehow gave the impression these were alpha results. Oops. Yes, that's right. Nevertheless, alpha had the same issue, only more reliably. As soon as I have a round tuit, I'll make a check on an alpha I was just granted access to. Thanks! - Bruce
Bug#340851: Still FTBFS under pbuilder
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's different. Would you please compile and run the attached program on your system and let me know what the result is? Running kernel 2.6.15-1-686 (version 2.6.15-3) on my laptop, I got: [EMAIL PROTECTED]:~/test$ ./mmap-test char at 0xb7fc is 0 did not fault dereferencing 0xB7FC (Although I got several warnings from -Wall.) Thanks for doing this. Bruce, is this what you expected? Hi Guys, It is not what I expected, but it is not necessarily invalid. mmap implementations are described as *trying* to map the data between between some unmapped pages just so that you can try to extend the mapping. Given that this program is not doing anything else, it really *ought* to be the case that the reference faults. There should be lots of unused virtual address space available. Cheers - Bruce P.S. I should not always rely on Open Group docs. I just saw this in Linux docs: MAP_ANONYMOUS The mapping is not backed by any file; the fd and offset argu- ments are ignored. This flag in conjunction with MAP_SHARED is implemented since Linux 2.4. which means my original version ought to have always worked, but was not portable. Well, now with MAP_PRIVATE, it should be portable, too. :) Anyway, here is some POSIX verbiage that actually implies that the above reference really should fault (though it is colored optional): The system shall always zero-fill any partial page at the end of an object. Further, the system shall never write out any modified portions of the last page of an object which are beyond its end. [MPR] [Option Start] References within the address range starting at pa and continuing for len bytes to whole pages following the end of an object shall result in delivery of a SIGBUS signal. [Option End] An implementation may generate SIGBUS signals when a reference would cause an error in the mapped object, such as out-of-space condition. I suppose I could wrap the anonymous mmap call in sigbus protection, but holy moly, just how friggin hard should it be to mmap a bloody text file anyways? Sheesh!!!
Bug#340851: autogen also FTBFS on i386 now
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: the cause is due to use of a deprecated Guile interface. By not using scm_makstr() the problem goes away. That problem is bypassed in 5.8, but the libtool used is broken. The libtool released last night fixes that issue, but I haven't rolled a new release yet. 5.8.1 will be the one you want (in a day or two). It will be just 5.8 with a new libtool. Regards, Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340851: 5.7.3 failure
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 test that checks for this behavior and falls back to some other method? Yes. Very logical. I was feeling tired, exasperated and lazy all at the same time. ;) It is not an easy test, of course, so it is easier to be lazy. I am just so surprised and disappointed to find it failing. Short term: simply disable mmap for page sized files. Dumb and all, but it is also what I do for fixincludes. *sigh*. Cheers - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340851: 5.7.3 failure
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() and that has been so strongly
deprecated that the current development releases (1.7.x) of
Guile emit warnings when it is used. Rather than fight it, I have
removed all usage of either of these for all variations of AutoGen.
(Each version of Guile causes me to rewrite some portion of
AutoGen. 1.7 is the worst yet, causing me several days of work.)
Upshot: I now (finally) have a 1.7.x-ready version of AutoGen.
Problem: still seg faults on Alpha Linux 2.2. The issue: mmap
Details:
When I mmap a file, I have to test for it being a multiple of the
page size. My license.test forces this for both the template
and for the license text. Both of these files get mmapped, so
I use this test to verify proper functioning of mmap, too.
My mapping descriptor structure shows this:
(gdb) print *pMI
$2 = {txt_data = 0x201c000, txt_size = 8192, txt_full_size = 16384,
txt_fd = 7, txt_zero_fd = -1, txt_errno = 0, txt_prot = 0, txt_flags = 0,
txt_alloc = 0}
Immediately before this call:
pNuls = mmap(
(void*)(((char*)pMI-txt_data) + pMI-txt_size),
pgsz,
PROT_READ|PROT_WRITE,
MAP_ANONYMOUS|MAP_FIXED|MAP_SHARED, 0, 0 );
The address passed is:
(gdb) print 0x201c000+8192
$5 = 0x201e000
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? :-(
I have a new pre release:
http://autogen.sourceforge.net/data/autogen-5.8pre8.tar.gz
that has these changes.
Regards, Bruce
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340851: 5.7.3 failure
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 --trace=everything -b license --no-def -T license.tpl [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 648)] Starting test template Text (11) in license.tpl at line 2 /* EXPR ( B) in license.tpl at line 3 (license license license Au Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 648)] 0x02008a4c in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2 (gdb) bt #0 0x02008a4c in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2 #1 0x02008efc in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2 #2 0x0200c540 in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2 #3 0x0200c058 in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2 #4 0x000120014654 in ag_scm_license (license=0x24e2820, prog_name=0x24e27d0, owner=0x24e2790, prefix=0x24e2720) at expFormat.c:593 #5 0x02082bd4 in scm_gsubr_apply () from /usr/lib/libguile.so.12 #6 0x02068aa4 in scm_dapply () from /usr/lib/libguile.so.12 #7 0x02067a90 in scm_deval () from /usr/lib/libguile.so.12 #8 0x0206395c in scm_i_eval_x () from /usr/lib/libguile.so.12 #9 0x0206a810 in scm_primitive_eval_x () from /usr/lib/libguile.so.12 #10 0x000120014d0c in ag_scm_c_eval_string_from_file_line ( pzExpr=0x1200cf499 (license \license\ \license\ \Auto-Gen\ \ * \ ), pzFile=0x1200cf488 license.tpl, line=3) at expGuile.c:99 #11 0x00012001e224 in ag_eval ( pzStr=0x1200cf499 (license \license\ \license\ \Auto-Gen\ \ * \ )) at autogen.h:485 #12 0x000120025bd4 in evalExpression (pMustFree=0x11ff47748) at funcEval.c:242 #13 0x000120026068 in mFunc_Expr (pT=0x1200cf3a0, pMac=0x1200cf428) at funcEval.c:413 #14 0x0001200292b4 in generateBlock (pT=0x1200cf3a0, pMac=0x1200cf428, pEnd=0x1200cf488) at tpProcess.c:85 #15 0x00012002982c in processTemplate (pTF=0x1200cf3a0) at tpProcess.c:208 #16 0x0001200076b8 in inner_main (argc=7, argv=0x11ff478f8) at autogen.c:78 #17 0x020790a0 in gh_call3 () from /usr/lib/libguile.so.12 #18 0x020873b4 in scm_boot_guile () from /usr/lib/libguile.so.12 #19 0x020790e4 in gh_enter () from /usr/lib/libguile.so.12 #20 0x0001200077a4 in main (argc=7, argv=0x11ff478f8) at autogen.c:104 590 /* 591 * Create our output buffer and insert the first prefix 592 */ 593 res= scm_makstr( out_size, 0 ); 594 pzOut = SCM_CHARS( res ); -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340851: 5.7.3 fixed two license test bugs
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 within pbuilder's chroot, but not outside (both sid). Weird. If anybody wants to debug this, I can try to set up an environment where it can be reproduced and provide an account. If you can give me access to an environment where I can reproduce it, I'll investigate further. Me, too!! :) It would be nice to nail it before I make 5.8 official. (It still needs work, though. I am upgrading the Guile interface to the new, improved 1.7 flavor. Not easy. :-( ) Cheers - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340851: 5.7.3 fixed two license test bugs
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 from sid: [EMAIL PROTECTED]:/var/cache/pbuilder/build/5817/tmp/autogen-5.7.3/agen5/test/FAILURES# \ autogen -b license --no-def -T license.tpl AutoGen aborting on signal 10 (Bus error) in state LOAD_TPL processing template NULL file name on line 0 for function pseudo-macro (-1) zsh: abort (core dumped) autogen -b license --no-def -T license.tpl It does appear though that once you have a failing example, it fails regularly. (You caused this by typing in the command, yes?). Maybe I can debug the issue with the contents of the FAILURES directory? Any help would be appreciated. Thanks - Bruce P.S. I'm curious: Package: autogen Version: 1:5.7.2-1 Severity: serious Justification: no longer builds from source yet I just noticed the autogen-5.7.3 element in the path above. If you were using 5.7.3 and encountered this problem, then the fixes noted above are already in the sources you were working with -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324784: sharutils: each man page should say how to report a bug
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 read the README. Not only the readme, but ``--help'' and ``--version'' will emit the bug reporting e-address. Well many of $ dlocate -man sharutils 1 shar 1 unshar 1 uuencode 1 mailshar 5 uuencode 1 uudecode 1 mail-files 1 remsync seem hardly to admit their relation to the GNU project, even though the README does say to send bugs to [EMAIL PROTECTED] Maybe upstream could spiff these up. The upstream was promised, _promised_ that sharutils was a low maintenance project that would merely need a tweaking now and then. :-D. The GNU man pages one is used to all mention GNU somewhere. Remember: 1. this stuff was derived from the BSD stuff. They don't mention GNU. That's the lame excuse. :) 2. people keep saying over and over that nobody uses it anyway. 3. I would be completely delighted to receive a patch with suggested places for adding GNU. Thanks - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324784: sharutils isn't GNU...
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 the next drop: Index: ansi2knr.1 === RCS file: /cvsroot/sharutils/sharutils/doc/ansi2knr.1,v retrieving revision 1.1.1.1 diff -b -B -u -p -r1.1.1.1 ansi2knr.1 --- ansi2knr.1 24 Jun 2002 15:16:38 - 1.1.1.1 +++ ansi2knr.1 27 Aug 2005 21:25:57 - @@ -17,3 +17,9 @@ The following constructs will confuse it - Any other construct that starts at the left margin and follows the above syntax (such as a macro or function call). .br - Macros that tinker with the syntax of the function header. +.SH REPORTING BUGS +Report bugs to [EMAIL PROTECTED]. Please put +.I sharutils +or +.I ansi2knr +in the subject line. It helps to spot the message. Index: shar.1 === RCS file: /cvsroot/sharutils/sharutils/doc/shar.1,v retrieving revision 1.4 diff -b -B -u -p -r1.4 shar.1 --- shar.1 4 Aug 2005 04:06:11 - 1.4 +++ shar.1 27 Aug 2005 21:25:57 - @@ -243,3 +243,9 @@ The shar and unshar programs is the coll Many people contributed by reporting problems, suggesting various improvements or submitting actual code. A list of these people is in the THANKS file in the sharutils distribution. +.SH REPORTING BUGS +Report bugs to [EMAIL PROTECTED]. Please put +.I sharutils +or +.I uuencode +in the subject line. It helps to spot the message. Index: unshar.1 === RCS file: /cvsroot/sharutils/sharutils/doc/unshar.1,v retrieving revision 1.2 diff -b -B -u -p -r1.2 unshar.1 --- unshar.11 Jul 2005 13:41:06 - 1.2 +++ unshar.127 Aug 2005 21:25:57 - @@ -54,3 +54,7 @@ The shar and unshar programs is the coll Many people contributed by reporting problems, suggesting various improvements or submitting actual code. A list of these people is in the THANKS file in the sharutils distribution. +.SH REPORTING BUGS +Report bugs to [EMAIL PROTECTED]. Please put +.I sharutils +in the subject line. It helps to spot the message. 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 - 1.3 +++ uuencode.1 27 Aug 2005 21:25:57 - @@ -120,6 +120,12 @@ in the encoded files are the same the re .PP The encoded form of the file is expanded by 37% for UU encoding and by 35% for base64 encoding (3 bytes become 4 plus control information). +.SH REPORTING BUGS +Report bugs to [EMAIL PROTECTED]. Please put +.I sharutils +or +.I uuencode +in the subject line. It helps to spot the message. .SH HISTORY The .I uuencode -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#49021: buffered input for uuencode
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 - 1.3 +++ uuencode.1 27 Aug 2005 22:33:34 - @@ -73,6 +73,12 @@ is given on the command line .B base64 encoding is used instead. .PP +.B Note: +.I uuencode +uses buffered input and assumes that it is not hand typed from a tty. +The consequence is that at a tty, you may need to hit Ctl-D several times +to terminate input. +.PP .I Uudecode transforms uuencoded @@ -120,6 +126,12 @@ in the encoded files are the same the re .PP The encoded form of the file is expanded by 37% for UU encoding and by 35% for base64 encoding (3 bytes become 4 plus control information). +.SH REPORTING BUGS +Report bugs to [EMAIL PROTECTED]. Please put +.I sharutils +or +.I uuencode +in the subject line. It helps to spot the message. .SH HISTORY The .I uuencode -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#319911: autogen: FTBFS on hurd-i386: Unconditionalized use of optional-by-POSIX system limitation variable
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 two minor nits:
1. After it calls canonicalize_file_name, shouldn't optionMakePath
check that the length of the result is less than bufSize instead of
less than MAXPATHLEN?
It is filling in a buffer passed by address and that buffer is
(and already was) guaranteed to be MAXPATHLEN+1 bytes long.
Since the buffer size is not also passed, the function must
rely on the caller providing a buffer of that size. (It is
internal and not callable by library users.)
2. Since realpath expects a buffer of size PATH_MAX, if PATH_MAX isn't
defined, shouldn't realpath not be used at all?
realpath(3C) should not be implemented without PATH_MAX defined,
so I think you are right. That should probably be done in libc,
but I should guard against it, too. So I have. In configure.in:
AC_DEFUN([AG_RUN_REALPATH],[
AC_MSG_CHECKING([whether we have a functional realpath(3C)])
AC_CACHE_VAL([ag_cv_run_realpath],[
AC_TRY_RUN([EMAIL PROTECTED]:@include limits.h
@%:@include stdlib.h
int main (int argc, char** argv) {
@%:@ifndef PATH_MAX
choke me!!
@%:@else
char zPath@:@PATH_MAX+1@:@;
@%:@endif
char *pz = realpath(argv@:@0@:@, zPath);
return (pz == zPath) ? 0 : 1;
}],
[ag_cv_run_realpath=yes],[ag_cv_run_realpath=no],[ag_cv_run_realpath=no]
) # end of TRY_RUN
]) # end of AC_CACHE_VAL for ag_cv_run_realpath
AC_MSG_RESULT([${ag_cv_run_realpath}])
if test X${ag_cv_run_realpath} != Xno
then
AC_DEFINE([HAVE_REALPATH],[1],
[Define this if we have a functional realpath(3C)])
fi
]) # end of AC_DEFUN of AG_RUN_REALPATH
Thanks - Bruce
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#319911: autogen: FTBFS on hurd-i386: Unconditionalized use of optional-by-POSIX system limitation variable
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); [...] ERRORS [...] ENAMETOOLONG A component of a path name exceeded NAME_MAX characters, or an entire path name exceeded PATH_MAX characters. and the code in question is only compiled in if realpath is known to be in the library. And, yes, I know about the extended GNU doc: BUGS Never use this function. It is broken by design since it is impossible to determine a suitable size for the output buffer. According to POSIX a buffer of size PATH_MAX suffices, but PATH_MAX need not be a defined constant, and may have to be obtained using pathconf(). And asking pathconf() does not really help, since on the one hand POSIX warns that the result of pathconf() may be huge and unsuitable for mallocing mem- ory. And on the other hand pathconf() may return -1 to signify that PATH_MAX is not bounded. but since no viable alternative is suggested, it leaves one in a difficult spot. Especially since virtually all normal paths are under a few hundred bytes and PATH_MAX is typically 1024. If someone wants to promote an realnpath call, I'd be a happy camper :). Anyway, I'll replace PATH_MAX with MAXPATHLEN and now define it thus: #ifndef MAXPATHLEN # ifdef PATH_MAX #define MAXPATHLEN PATH_MAX # else #define MAXPATHLEN 4096 # endif #else # if defined(PATH_MAX) (PATH_MAX MAXPATHLEN) # undef MAXPATHLEN # define MAXPATHLEN PATH_MAX # endif #endif Ugly stuff Thank you. Regards, Bruce On Monday 25 July 2005 09:29 am, Michael Banck wrote: Package: autogen Severity: important Version: 5.7-4 Tags: patch Sorry, I should have checked this before filing the last bug. Due to a PATH_MAX occurance in autoopts/load.c, autogen FTBFS: gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../autoopts -O2 -MT libopts.lo -MD -MP -MF .deps/libopts.Tpo -c libopts.c -fPIC -DPIC -o .libs/libopts.o In file included from libopts.c:15: load.c: In function 'optionMakePath': load.c:225: error: 'PATH_MAX' undeclared (first use in this function) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#319911: autogen: FTBFS on hurd-i386: Unconditionalized use of optional-by-POSIX system limitation variable
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 returns the absolute name of the file named by NAME which contains no `.', `..' components nor any repeated path separators (`/') or symlinks. The result is passed back as the return value of the function in a block of memory allocated with `malloc'. If the result is not used anymore the memory should be freed with a call to `free'. I don't much about this though, so maybe this is bad advise. Excellent advice. You just need to know about such functions. The person who went to the trouble to say, Never use this function. should also go to the trouble to add, See Also: canonicalize_file_name Oh, well. Thank you. Since I am still futzing with the 5.7.2 release, this will be very quickly added in. Regards, Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#319911: autogen: FTBFS on hurd-i386: Unconditionalized use of optional-by-POSIX system limitation variable
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 PROTECTED]
Bug#315387: autogen: FTBFS on hurd-i386: Unsatisfiable Build-Depends: procps
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 Wednesday 22 June 2005 07:21 am, Matt Kraai wrote: On Wed, Jun 22, 2005 at 11:30:13AM +0200, Michael Banck wrote: E: Failed to satisfy Build-Depends dependency for autogen: procps Is procps really required for building autogen? Yes, agen5/test/daemon.test uses ps to determine whether the autogen daemon is still running. Is there a way to do this on the Hurd? If not, could this please be conditionalized, like procps [!hurd-i386]. I'm afraid that this will just cause the test, and hence the build, to fail. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#302412: exploitable temporary file race in unshar (fwd)
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 misleading. The first was a typo that I didn't notice until my script was already running. It is my intention to release in REL-x subdirectories. It reduces clutter. These new issues will get faster action with a suggested patch :-). Ok, here is a patch that maybe you can accept: Looks fine to me. It may be a couple of weeks tho, taxes and my day job take priority. :) This patch tries not to break the MSDOS stuff. Thanks. I tend to forget that MSDOS exists ;) Regards, Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
