Re: bug#77805: new snapshot available: m4-1.4.19.60-6ebfc.tar.xz

El 21/4/25 a las 22:42, Karl Berry escribió: A patch to mdate-sh might take the form of checking (possibly only when a command-line option is also specified) if $SOURCE_DATE_EPOCH is set in the environment, and if so favoring that timestamp over the mdate of its target file.

Re: bug#77805: new snapshot available: m4-1.4.19.60-6ebfc.tar.xz

A patch to mdate-sh might take the form of checking (possibly only when a command-line option is also specified) if $SOURCE_DATE_EPOCH is set in the environment, and if so favoring that timestamp over the mdate of its target file. That sounds doable. Thanks. I don't think an extra

Re: bug#77805: new snapshot available: m4-1.4.19.60-6ebfc.tar.xz

I'm stumped. > by ALL packages affected by the same problem will I still don't understand what the "problem" is. I.e., how the mtime gets changed in the first place. In general, it seems unfortunate to me to eliminate useful information from the manual because of a repro

Re: bug#77805: new snapshot available: m4-1.4.19.60-6ebfc.tar.xz

On Tue, Apr 15, 2025 at 07:55:08PM +0200, Santiago Vila wrote: > El 15/4/25 a las 14:52, Eric Blake escribió: > > I'm not sure the exact process Debian uses to do downstream builds, > > but my guess is that it involves a downstream git repository for their > > patches to be applied on top of the up

Re: bug#77805: new snapshot available: m4-1.4.19.60-6ebfc.tar.xz

El 15/4/25 a las 14:52, Eric Blake escribió: I'm not sure the exact process Debian uses to do downstream builds, but my guess is that it involves a downstream git repository for their patches to be applied on top of the upstream tarball - and it is the very act of applying those patches from git

Re: bug#77805: new snapshot available: m4-1.4.19.60-6ebfc.tar.xz

the documentation of $SOURCE_DATE_EPOCH, the environment variable that is most commonly used to pin timestamps during a reproducible build. > > Then, manuals could continue to use @value{UPDATED}, > > Well, that is clearly desirable. I looked at the bug-m4 thread from > https:/

Re: bug#77805: new snapshot available: m4-1.4.19.60-6ebfc.tar.xz

think of "epoch" as meaning 1970-01-01, in our world. Not as a value to be specified. Then, manuals could continue to use @value{UPDATED}, Well, that is clearly desirable. I looked at the bug-m4 thread from https://lists.gnu.org/archive/html/bug-m4/2025-04/msg00043.html but I'

Re: bug formatting a .h function extern declaration with attribute macros

Eric Blake writes: > On Fri, Apr 04, 2025 at 02:16:03PM +0200, Simon Josefsson wrote: >> Eric Blake writes: >> >> >> # define G_GNUC_IDN2_ATTRIBUTE_PURE __attribute__ ((pure)) >> ... >> >> extern _IDN2_API const char *idn2_check_version (const char >> >> *req_version) >> >> G_GNUC_IDN2_

Re: bug formatting a .h function extern declaration with attribute macros

On Fri, Apr 04, 2025 at 02:16:03PM +0200, Simon Josefsson wrote: > Eric Blake writes: > > >> # define G_GNUC_IDN2_ATTRIBUTE_PURE __attribute__ ((pure)) > ... > >> extern _IDN2_API const char *idn2_check_version (const char *req_version) > >> G_GNUC_IDN2_ATTRIBUTE_PURE; > > > > Figuring out

Re: bug formatting a .h function extern declaration with attribute macros

Eric Blake writes: >> # define G_GNUC_IDN2_ATTRIBUTE_PURE __attribute__ ((pure)) ... >> extern _IDN2_API const char *idn2_check_version (const char *req_version) >> G_GNUC_IDN2_ATTRIBUTE_PURE; > > Figuring out how to write the __attribute__-hiding macros conditional > on compiler version w

Re: bug formatting a .h function extern declaration with attribute macros

On Fri, Apr 04, 2025 at 12:23:55PM +0200, Simon Josefsson wrote: > Eric Blake writes: > > > I'm trying to run indent on the GNU M4 source code base before a > > release (it looks like gnulib added the ability to run make indent > > since the last time I made an m4 release). But one change that i

Re: bug formatting a .h function extern declaration with attribute macros

Eric Blake writes: > I'm trying to run indent on the GNU M4 source code base before a > release (it looks like gnulib added the ability to run make indent > since the last time I made an m4 release). But one change that indent > is insisting on is wrong: > > -extern void m4_error (int, int, cons

bug formatting a .h function extern declaration with attribute macros

I'm trying to run indent on the GNU M4 source code base before a release (it looks like gnulib added the ability to run make indent since the last time I made an m4 release). But one change that indent is insisting on is wrong: -extern void m4_error (int, int, const char *, ...) - ATTRIBUTE_COLD

Fwd: Bug#1097346: m4: ftbfs with GCC-15

Hello. I received the following report from the Debian BTS. m4 fails to build from source with gcc 15. For the Debian package, I'm going to add -std=c17 to CFLAGS in the meantime, but a new official release would be nice. Thanks. Mensaje reenviado Asunto: Bug#109734

Potential bug on riscv32

Hi! I am porting riscv32 to Debian in a downstream way[0]. Now it has a basic demo can be run on qemu system. Next we plan to build more riscv32 packages but unfortunately it is blocked by m4(IIRC), when I am trying to build dh-exec[1] the log is below: ``` /usr/share/aclocal-1.16/vala.m4:23: war

Re: Bug in m4

m4:Alan+Roger+Davin-2014.hts:10: ERROR: end of file in argument list > make[2]: *** [../../Makefile.mk:149: m4-inner] Error 1 So m4 is reporting that there is a syntax error in your file Alan+Roger+Davin-2014.hts. That's not a bug in m4, but in your file. Without knowing the contents of th

Re: Bug in m4

webs-com Can you give more details? What error messages are you getting? Why do you think it is a bug in m4, rather than in the Peblic sources? -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org

Re: Bug in m4

Apologies for missing the following hyperlink in the previous email to you. -- Sincerely and kindest regards, *Davin Pearson* http://davin.50webs.com On Sun, 2 Apr 2023 at 13:25, Davin Pearson wrote: > The following archive Peblic-20230

Re: Bug in m4

Try the following FTP download... > -- -- Sincerely and kindest regards, *Davin Pearson* http://davin.50webs.com On Sun, 2 Apr 2023 at 13:28, Davin Pearson wrote: > Apologies for missi

Bug in m4

The following archive Peblic-20230402-131204.tar.gz when extracted fails to build the following targets. The code takes an X.hts (stands for HTml Source) file and converts it to an X.html file using GNU m4. $cd ~/Peblic/Makefile && make m4-test $cd ~/Peblic/sources/Makefile && make m4

RE: AIX stackoverflow detection hang [was: Reporting m4 bug]

Hi Bruno and Eric, Thanks for the reply, I will wait for the next build and will check if I am still seeing hang issue or not. -Original Message- From: Bruno Haible Sent: Monday, 11 July, 2022 3:05 AM To: Neha Jain33 Cc: Eric Blake ; bug-m4@gnu.org; Srirama R Kucherlapati Subject

Re: AIX stackoverflow detection hang [was: Reporting m4 bug]

Thanks for the report. And thanks for the CC, Eric. > > stopped in is_mapped at line 621 in file "" > > is_mapped(addr = 9), line 621 in "stackvma.c" > > is_unmapped(addr1 = 4, addr2 = 15), line 768 in "stackvma.c" > > mincore_is_near_this(addr = 10, vma = 0x000111001fb8), line 793 in > > "st

Re: AIX stackoverflow detection hang [was: Reporting m4 bug]

On Tue, Jun 28, 2022 at 01:10:54PM +, Neha Jain33 wrote: > Hi, > > I am trying to build m4 package but its hanging during testcase validation Thanks for the report. I'm adding in Bruno, as one of the authors of the libsigsegv library that the code in lib/stackvma.c is derived from; perhaps h

Reporting m4 bug

Hi, I am trying to build m4 package but its hanging during testcase validation Package details m4 1.4.19 Machine details operating system: AIX/PPC oslevel: 7.1.0.0 what is the issue: one of the testcase is hanging hanged after this PASS: test-sigsegv-catch-segv1 PASS: test-sigsegv-catch-segv2

Re: Bug in dumpdef's documentation

On Tue, Oct 26, 2021 at 07:45:06PM +0200, Patrice Dumas wrote: > > @c @tabchar{} > > @c -- > > @c The testsuite expects literal tab output in some examples, but > > @c literal tabs in texinfo lead to formatting issues. > > @macro tabchar > > @ @c > > @end macro > > > > So maybe the p

Re: Bug in dumpdef's documentation

;) > @error{}foo:@tabchar{}`Hello world.' > @result{} > dumpdef(`define') > @error{}define:@tabchar{} > @result{} > @end example > > My initial guess is that there is a bug in the texi -> html conversion > where @tabchar{} gets eaten incorrectly, resulting in the

Re: Bug in dumpdef's documentation

doc/m4.texi, there is: @example $ @kbd{m4 -d} define(`foo', `Hello world.') @result{} dumpdef(`foo') @error{}foo:@tabchar{}`Hello world.' @result{} dumpdef(`define') @error{}define:@tabchar{} @result{} @end example My initial guess is that there is a bug in the texi

Bug in dumpdef's documentation

The output documented is not what you get from executing the m4 commands as documented. See https://www.gnu.org/software/m4/manual/m4.html#Dumpdef

Re: also in C11 mode I get a bug

make: *** [Makefile:2317: check] Error 2 > > > Not sure what to make of that. You truncated the log, not showing the actual failure at the time test 198 was run. However, I suspect that you have hit this known issue: https://lists.gnu.org/archive/html/bug-m4/2021-06/msg9.html an

also in C11 mode I get a bug

With std9899:2011 we compile fine but testsuite fails : . . . Checking ./stackovf.test Stack soft limit set to 300K Pass Skipped checks were: ./125.changeword ./126.changeword ./127.changeword ./128.changeword ./129.changeword ./130.changeword Failed checks were: ./198.sysval:err gmake[3]:

Re: Bug

> configure: WARNING: sys/bitypes.h: section "Present But Cannot Be > Compiled" > configure: WARNING: sys/bitypes.h: proceeding with the compiler's result > configure: WARNING: ## - ## > configure: WARNING: ## Report this

bug with M4-1.4.18

when I configured with ./configure --prefix=/usr \ --host=$BulgarianOS_Target \ --target=$BulgarianOS_Target \ --build=$(build-aux/config.guess) [image: image.png] [image: image.png] why is "x86_64-linux-gnu" when i configured with --target=$BulgarianOS_Target = x86_64-bulgarianos-linux

Bug

piled" configure: WARNING: sys/bitypes.h: proceeding with the compiler's result configure: WARNING: ## - ## configure: WARNING: ## Report this to bug-m4@gnu.org ## configure: WARNING: ## - ##

Re: BUG PROBLEM-> recursive macro inplace substitution

On 9/30/20 5:03 AM, hhmm wrote: > please see this reference > > https://stackoverflow.com/questions/64066166/how-to-rescan-m4-data-for-recursive-macro-inplace-substitution/64066869?noredirect=1#comment113299085_64066869 Better yet, ask your question directly here, instead of making every reader c

BUG PROBLEM-> recursive macro inplace substitution

please see this reference https://stackoverflow.com/questions/64066166/how-to-rescan-m4-data-for-recursive-macro-inplace-substitution/64066869?noredirect=1#comment113299085_64066869 thnx

Re: Bug

[CCing bug-m4] Hi, Rahmad Alamsyah Nazaruddin wrote: > I got this issue '#error "please port gnulib freadhead.c to your platform! > Look at the definition of fflush, fread, ungetc on your system' > How can i fix this ? I fail install on M4 Thank you for reporting this

Re: Minor documentation bug: license section numbering

ml#GNU-Free-Documentation-License > shows "1. PREAMBLE", but > info coreutils 'GNU Free Documentation License' > shows "0. PREAMBLE" > > So this smells like a makeinfo bug, in that it is unable to properly render > @enumerate 0 into something that

Re: Minor documentation bug: license section numbering

[adding bug-texinfo] On 2/22/20 5:24 AM, Aa 123456789 wrote: Good evening, I was reading the m4 documentation you have posted at https://www.gnu.org/savannah-checkouts/gnu/m4/manual/m4-1.4.18/m4.html, and I noticed that there's a very minor bug with the included copy of the GPLv

Minor documentation bug: license section numbering

Good evening, I was reading the m4 documentation you have posted at https://www.gnu.org/savannah-checkouts/gnu/m4/manual/m4-1.4.18/m4.html, and I noticed that there's a very minor bug with the included copy of the GPLv3 (in appendix A). The original GPLv3 text numbers its sections starting f

Re: Bug math.h?

Hi Eric, Of course, even beyond the wasted bandwidth, you are right to expect a poster to provide a clear explanation, not just attach an image. Sorry you had to waste your time transcribing text from an image. Just voicing a little support for you. BTW, I do not currently use m4. I used it

Re: Bug math.h?

On 2/3/20 8:02 AM, Arthur Armand wrote: Hello This is my screen error... [image: image.png] Attaching an image is poor use of bandwidth (the mail server has to replicate the image to every subscriber, and some subscribers may have data limits that make downloading an image expensive); if an

RE: Potential bug with my --synclines

. Thanks, Laura -Original Message- From: Eric Blake Sent: Thursday, June 6, 2019 3:46 PM To: Laura Wills ; bug-m4@gnu.org Subject: Re: Potential bug with my --synclines On 6/6/19 2:47 PM, Laura Wills wrote: > Hi, > > I am running into an issue with m4 synclines. I ha

Re: Potential bug with my --synclines

On 6/6/19 2:47 PM, Laura Wills wrote: > Hi, > > I am running into an issue with m4 synclines. I have a list of m4 files which > point to child m4 files. This reaches a hierarchy level of 12. When I write > out a list of these m4 files and one at a time read them with m4 synclines I > am able to

Potential bug with my --synclines

Hi, I am running into an issue with m4 synclines. I have a list of m4 files which point to child m4 files. This reaches a hierarchy level of 12. When I write out a list of these m4 files and one at a time read them with m4 synclines I am able to read them without an issue. When I put this into

bug: quote include makes patsubst no longer handle ^ correctly

hello fine m4 developers, i may have found a bug in m4: quoting include makes patsubst no longer recognize ^ (beginning of line) in the text apart from the first line. observe: $ cat textnocomma some text. with sentences. and no commas. $ cat includenocomma foo

Re: bug#20941: Fwd: installation of automake, autoconf, m4 error

ball, Unless something fishy happened in the distribution process, Automake should not be required. Maybe you were trying to build m4 from the git repository? I have successfully built m4-1.4.18 tarball on my system without requiring Automake. Thanks for the bug report. -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37

Re: Bug reporting for M4

On 17 Aug 2016 15:21, Spyder wrote: > As I was building my LFS in Ubuntu I found an bug. The bug is in > test-update-copyright.sh. it failed its check thanks for the report. the file in question is copied from another project (gnulib), and the issue has been fixed there. in order to fix

Bug reporting for M4

To whom it may concern, As I was building my LFS in Ubuntu I found an bug. The bug is in test-update-copyright.sh. it failed its check Thank you Spencer Garner

Make bug unexpected EOF while looking for matching

Hello! OS: Windows 7 64bit Compiler: MinGW 4.9.2 Make: GNU Make 3.81 (built for i386-pc-mingw32) Error while running make command: . -e 's|@''REPLACE_TRUNCL''@|0|g' \ -e '/definitions of _GL_FUNCDECL_RPL/r c++defs.h' \ -e '/definition of _GL_AR

Re: Bug#808917: [la...@debian.org: Bug#808917: m4: FTBFS: FAIL: test-update-copyright.sh]

On 24 Dec 2015 20:19, Santiago Vila wrote: > On Thu, Dec 24, 2015 at 01:47:57PM -0500, Mike Frysinger wrote: > > the person building the release just needs to update their gnulib snap > > next time they roll a tarball. hopefully they aren't using Debian as > > the gnulib snap there is ancient ;).

Re: Bug#808917: [la...@debian.org: Bug#808917: m4: FTBFS: FAIL: test-update-copyright.sh]

On Thu, Dec 24, 2015 at 01:47:57PM -0500, Mike Frysinger wrote: > On 24 Dec 2015 19:04, Santiago Vila wrote: > > Fortunately, it has been easy to diagnose and fix: New perl (5.22) > > makes test-update-copyright.sh to give a deprecation warning because > > there are unescaped braces in build-aux/up

Re: [la...@debian.org: Bug#808917: m4: FTBFS: FAIL: test-update-copyright.sh]

On 24 Dec 2015 19:04, Santiago Vila wrote: > Fortunately, it has been easy to diagnose and fix: New perl (5.22) > makes test-update-copyright.sh to give a deprecation warning because > there are unescaped braces in build-aux/update-copyright. > The warning message makes the test to fail, which in t

[la...@debian.org: Bug#808917: m4: FTBFS: FAIL: test-update-copyright.sh]

Greetings. I've received this report from the Debian bug system. Fortunately, it has been easy to diagnose and fix: New perl (5.22) makes test-update-copyright.sh to give a deprecation warning because there are unescaped braces in build-aux/update-copyright. The warning message makes the te

Re: Possibly a bug?

On 10/09/2015 11:49 AM, Donald Allen wrote: > Sorry, false alarm. Pilot error -- a quoting problem. > > /Don Allen > > On Fri, Oct 9, 2015 at 8:57 AM, Donald Allen wrote: >> /tmp/testit.m4: >> define(`First', index($1,`@')) In case someone else reading doesn't readily spot the quoting error, th

Re: Possibly a bug?

Sorry, false alarm. Pilot error -- a quoting problem. /Don Allen On Fri, Oct 9, 2015 at 8:57 AM, Donald Allen wrote: > /tmp/testit.m4: > define(`First', index($1,`@')) > First(`foo@bar@baz') > index(`foo@bar@baz',`@') > > > dca@franz:/tmp$ m4 testit.m4 > > -1 > 3 > dca@franz:/tmp$ > > I'm stumpe

Possibly a bug?

/tmp/testit.m4: define(`First', index($1,`@')) First(`foo@bar@baz') index(`foo@bar@baz',`@') dca@franz:/tmp$ m4 testit.m4 -1 3 dca@franz:/tmp$ I'm stumped as to why the index call in First returns -1, whereas the direct call returns the correct index. In trying to understand this, I've defined

Re: [bug-gettext] Bug#764580: m4 eats memory for breakfast (fwd)

Eric Blake writes: > Meanwhile, this is the patch I recommend for gettext; and since this is > a build-breaker, I recommend that gettext push a new release soon > (distros can backport the fix without waiting for the release; but the > fact that the build system is BROKEN because of a flaw in get

Re: Bug#764580: m4 eats memory for breakfast (fwd)

[adding bug-gettext; this is a flaw in gettext, not m4. Two patches below; one for util-linux, one for gettext] On 10/09/2014 02:14 PM, Eric Blake wrote: > On 10/09/2014 01:36 PM, Eric Blake wrote: > >> In particular, autom4te --verbose shows this is the runaway command line: >&

Re: Bug#764580: m4 eats memory for breakfast (fwd)

On 10/09/2014 01:36 PM, Eric Blake wrote: > In particular, autom4te --verbose shows this is the runaway command line: > > /usr/bin/m4 --nesting-limit=1024 --gnu --include=/usr/share/autoconf > --debug=aflq --fatal-warning --debugfile=/tmp/am4tSXlU7J/traces.0t > --trace=AM_GNU_GETTEXT_VERSION --tr

Re: Bug#764580: m4 eats memory for breakfast (fwd)

gt;>autopoint: /usr/bin/autopoint (GNU gettext-tools) 0.19.2 > > Okay, I am repeating the setup on my Fedora 20 system, with autopoint > 0.18.3 and m4 1.4.16; and I can reproduce that running 'autopoint > --force' is the step in ./autogen.sh that causes m4 to run away wi

Re: Bug#764580: m4 eats memory for breakfast (fwd)

ting the setup on my Fedora 20 system, with autopoint 0.18.3 and m4 1.4.16; and I can reproduce that running 'autopoint --force' is the step in ./autogen.sh that causes m4 to run away with memory. At this point, I'm suspecting an autopoint bug. > > Most likely, this is not a

Re: Bug#764580: m4 eats memory for breakfast (fwd)

;automake: automake (GNU automake) 1.14.1 >libtoolize: libtoolize (GNU libtool) 2.4.2 > ^C > Most likely, this is not a memory leak in m4, so much as a bug in util-linux' configure.ac that is causing m4 to go into an infinite loop. When you mention a git bisect, is that of the util-

Bug#764580: m4 eats memory for breakfast (fwd)

Hello. I received the following report from the Debian bug system: -- Forwarded message -- From: Andreas Henriksson To: Debian Bug Tracking System Date: Thu, 9 Oct 2014 11:21:12 +0200 Subject: Bug#764580: m4 eats memory for breakfast Package: m4 Version: 1.4.17-4 Severity

Re: Bug report - bootstrap script not compatible with git submodules

Hi, I've noticed that if the gnulib git tree is used as a submodule for a different project, the git detection in the bootstrap script will not work properly. This is because it checks for the existence of a .git directory, whereas for submodules .git will be a file. The fix is trivial, patch bel

Re: Example code bug

On 08/16/2014 08:35 AM, Eric Blake wrote: > > existing: >> define(`_forloop', `$4'`ifelse($1, `$3', `', `define(`$1', >> incr($1))$0($@)')') Oops, I think the bug is on YOUR end, for mis-transcribing what is already in the manual. The

Re: Example code bug

On 08/16/2014 08:20 AM, Florian Mayer wrote: > Hello m4 team, [rearranging your mail a bit] > > I hope that it is an actual bug this time... Not a bug per se, since, as you point out... > > I am aware of the existence of forloop2, which is listed in the example > code >

Example code bug

Hello m4 team, I hope that it is an actual bug this time... There is a sample listing for a simple for- loop in the manual at chapter 6.4. The corresponging lines are ==m4code== $ m4 -I examples [...] # forloop(var, from, to, stmt) - simple version define(`forloop', `pushdef(`$1', `$2

Re: Little documentation bug

On 08/13/2014 06:06 PM, Florian Mayer wrote: > Hello m4 Team, > > i think i have found a little bug in the latest > version of the m4 manual! > Thanks for the report. However... > define(`foo', `Macro `FOO'.') > ⇒ > changequote(`', `')

Little documentation bug

Hello m4 Team, i think i have found a little bug in the latest version of the m4 manual! (see http://www.gnu.org/software/m4/manual/m4.html#Changequote the pdf version contains it as well) The bug is located in chapter 8.2 inside of the third code example. ==m4code== define(`foo', `Macro

Re: Bug#748361: m4: build tests are failing on ppc64el

On 05/16/2014 05:00 PM, Eric Blake wrote: > adding gnulib, as m4 merely borrows the content from gnulib. > > On 05/16/2014 09:52 AM, Santiago Vila wrote: >> Hello. >> >> I received the following report from the Debian bug system. >> [ Please keep th

Re: Bug#748361: m4: build tests are failing on ppc64el

adding gnulib, as m4 merely borrows the content from gnulib. On 05/16/2014 09:52 AM, Santiago Vila wrote: > Hello. > > I received the following report from the Debian bug system. > [ Please keep the Cc: lines when replying. Thanks ]. > > - Forwarded message

Re: Bug#748361: m4: build tests are failing on ppc64el

Note: This is a gnulib issue having two different ways to be fixed. The patch from Alan Modra: https://lists.gnu.org/archive/html/bug-gnulib/2013-12/msg00104.html and the patch from Ulrich Weigand: https://lists.gnu.org/archive/html/bug-gnulib/2013-12/msg00107.html but I did "git blame

Bug#748361: m4: build tests are failing on ppc64el

Hello. I received the following report from the Debian bug system. [ Please keep the Cc: lines when replying. Thanks ]. - Forwarded message from Erwan Prioul - Date: Fri, 16 May 2014 16:56:11 +0200 From: Erwan Prioul To: Debian Bug Tracking System Subject: Bug#748361: m4: build tests

Re: bug#12877: Autoconf, GNU m4 and POSIXLY_CORRECT

[adding bug-m4] On 11/14/2012 04:09 AM, Sebastian Freundt wrote: >>> (GNU) m4 when being called with the variable POSIXLY_CORRECT behaves >>> differently as all GNU extensions will be suppressed. >>> >> Modern autoconf versions used with modern GNU m4 versions

Re: report Bug

On 09/14/2012 07:31 AM, 藤田 一秀 wrote: > === > 1 of 119 tests failed > (11 tests were not run) > See tests/test-suite.log > Please report to bug-m4@gnu.org > === Thanks for the report. Can you please provide more det

report Bug

=== 1 of 119 tests failed (11 tests were not run) See tests/test-suite.log Please report to bug-m4@gnu.org === test-suite.log Description: Binary data

Re: reporting a bug

On Tuesday 03 April 2012 12:27:33 vr tech labs wrote: > i am getting the bug by typing the following command for m4 package > "make check" please post the full output of `make check` and the .log file produced. the snippet you posted doesn't include any useful information.

Re: reporting a bug

On 04/03/2012 10:27 AM, vr tech labs wrote: > i am getting the bug by typing the following command for m4 package > "make check" Thanks for the report. However, > > > the error is > make[6]: *** [test-suite.log] Error 1 That is not the error. It is the stuff t

reporting a bug

i am getting the bug by typing the following command for m4 package "make check" the error is make[6]: *** [test-suite.log] Error 1 make[6]: Leaving directory `/mnt/lfs/sources/m4-1.4.16/tests' make[5]: *** [check-TESTS] Error 2 make[5]: Leaving directory `/mnt/lfs/sources/m4-1.4

Re: bug in $(wildcard) with trailing slash

On 03/02/2012 06:53 AM, Eric Blake wrote: > Make fails to restrict output to just directories when a wildcard > contains both a trailing slash and internal slashes, even though it does > the right thing with no internal slashes. Sorry about that; I meant bug-make, but my mailer autocom

bug in $(wildcard) with trailing slash

Make fails to restrict output to just directories when a wildcard contains both a trailing slash and internal slashes, even though it does the right thing with no internal slashes. $ mkdir /tmp/example $ cd /tmp/example/ $ touch a $ mkdir b $ printf 'all:\n\t@echo $(wildcard */)' | make -f - b/ $

Re: Bug#630902: m4: FTBFS: FAIL: test-readlink

x7fff370e7340, 80) = -1 ENOENT (No such file or > > directory) > > readlink("", 0x7fff370e7340, 80)= -1 EINVAL (Invalid argument) > > There's the bug. This is failing with EINVAL instead of ENOENT, which is > contrary to POSIX. However, this kernel bug h

Re: Bug#630902: m4: FTBFS: FAIL: test-readlink

On 07/26/2011 07:50 AM, Santiago Vila wrote: Yes, most likely this is a kernel and/or glibc bug. POSIX requires readlinkat(dfd, "", buf, size) to fail with ENOENT, if dfd is either AT_FDCWD or open on a directory. Which does strace say about the syscall made just before the g

Re: Bug#630902: m4: FTBFS: FAIL: test-readlink

k, so we are outside of > > POSIX scope here. For fchownat() and fstatat() we allow AT_EMPTY_PATH; > > let the caller explicitly ask for such behaviour. > > > > Signed-off-by: Al Viro > > Yes, most likely this is a kernel and/or glibc bug. POSIX r

Re: Bug#630902: m4: FTBFS: FAIL: test-readlink

[adding bug-gnulib] On 06/18/2011 12:05 PM, Santiago Vila wrote: > I can't reproduce the failure on Debian "testing" (currently using > linux-image-2.6.38-2-amd64). > > I can reproduce it, however, on the same Debian testing system if I > use the kernel currently

Re: Bug#630902: m4: FTBFS: FAIL: test-readlink

For the record, this is what "git bisect" says: 65cfc6722361570bfe255698d9cd4dccaf47570d is the first bad commit commit 65cfc6722361570bfe255698d9cd4dccaf47570d Author: Al Viro Date: Sun Mar 13 15:56:26 2011 -0400 readlinkat(), fchownat() and fstatat() with empty relative pathnames

Re: Bug#630902: m4: FTBFS: FAIL: test-readlink

Hi. I confirm that m4 builds ok using vanilla 2.6.38.8 from kernel.org, and it fails using vanilla 2.6.39.1 from kernel.org.

Bug#630902: m4: FTBFS: FAIL: test-readlink (fwd)

Hello. I have just received this from the Debian bug system. I can't reproduce the failure on Debian "testing" (currently using linux-image-2.6.38-2-amd64). I can reproduce it, however, on the same Debian testing system if I use the kernel currently available on "unstable&qu

Re: bug in autoconf-2.64

describe 5e763da' in m4.git states: > > v1.4.15-3-g5e763da > > That is, no released version of m4 has this commit (only m4 built from > git). Unfortunately, you resolved to gnulib commit c823199d, which is > not related to the bug uncovered this week. Right. git bisect only

Re: bug in autoconf-2.64

v1.4.15-3-g5e763da That is, no released version of m4 has this commit (only m4 built from git). Unfortunately, you resolved to gnulib commit c823199d, which is not related to the bug uncovered this week. > memmem, strstr, strcasestr: fix bug with long periodic needle >

[PATCH] strstr: revert patches that introduced bug and pessimization

Jim's one-liner solved the bug by pessimizing speed, making the algorithm shift less per iteration and thus perform more repeated comparisons. The real reason for the bug is that my supposed "optimizations" actually resulted in cases on certain periodic needles where critica

Re: bug in autoconf-2.64

FYI, Here's a much-reduced test case for the short-needle case: const char *needle = ".d."; const char *haystack = "..d."; const char* p = strstr (haystack, needle); ASSERT (p && p - haystack == 1); Interestingly, it doesn't trigger a failure in glibc's slightly different impleme

Re: bug in autoconf-2.64

Jim Meyering wrote: > Jim Meyering wrote: > >> Ralf Wildenhues wrote: >> >>> [ this is http://thread.gmane.org/gmane.comp.sysutils.autoconf.bugs/7834 >>> from http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01480.html >>> adding bug-gnulib; foll

Re: bug in autoconf-2.64

Jim Meyering wrote: > Ralf Wildenhues wrote: > >> [ this is http://thread.gmane.org/gmane.comp.sysutils.autoconf.bugs/7834 >> from http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01480.html >> adding bug-gnulib; followups can elide bug-autoconf ] >> >> *

Re: bug in autoconf-2.64

Ralf Wildenhues wrote: > [ this is http://thread.gmane.org/gmane.comp.sysutils.autoconf.bugs/7834 > from http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01480.html > adding bug-gnulib; followups can elide bug-autoconf ] > > * Ralf Wildenhues wrote on Thu, Feb 24, 2011 at 07:24:3

Re: bug in autoconf-2.64

[ this is http://thread.gmane.org/gmane.comp.sysutils.autoconf.bugs/7834 from http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01480.html adding bug-gnulib; followups can elide bug-autoconf ] * Ralf Wildenhues wrote on Thu, Feb 24, 2011 at 07:24:35AM CET: > IOW, it looks like the replacement c

Re: bug in autoconf-2.64

o to M4_LIBOBJS), removing lib/string.h, rerunning config.status and make. IOW, it looks like the replacement code in strstr.c and str-two-way.h has a bug (or glibc strchr, which seems rather unlikely). Besides copyright year bumps, these two files have not been updated since in gnulib. Cheers, Ralf

Re: bug in autoconf-2.64

On Feb 23, 2011, at 1:37 PM, Eric Blake wrote: > Are you on a machine with SSE4.2 instructions? Core 2 Duo. darwin10 (aka SnowLeopard). No glibc.

Re: bug in autoconf-2.64

> Author: Eric Blake > Date: Tue Oct 5 16:39:32 2010 -0600 > > memmem, strstr, strcasestr: fix bug with long periodic needle Are you on a machine with SSE4.2 instructions? glibc 2.12 has the interesting problem of a strstr that is quadratic if you have SSE4.2, but linear if

Re: bug in autoconf-2.64

3fd19ff534e362 to > b86f488e783121f54dbd44e17741fa3b29e9be9b. That converged at this gnulib commit on Debian GNU/Linux with glibc 2.11.2 installed: commit c823199df2cc03b6bd70d0a2fef5999af82792fe Author: Eric Blake Date: Tue Oct 5 16:39:32 2010 -0600 memmem, strstr, strcasestr: fix bu

  1   2   3   >