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

e go away. http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=dc446909 -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

uld work around things while we wait for the kernel and/or glibc to bring things back into POSIX spec compliance, or to determine that test-readlink was over-strict and can be relaxed to allow the new behavior. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature

Bug#557632: broken test for mmap

K to apply and add Michal > to THANKS? Yes, this looks reasonable. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment

Bug#385720: m4: INTERNAL ERROR: recursive push_string (fwd)

to the testsuite that don't end in newline, so instead I used changequote to allow newline in a macro name to trigger a similar failure in the 'make distcheck' testsuite, to ensure we don't regress again. 2006-09-04 Eric Blake <[EMAIL PROTECTED]> * src/input.c (peek_

Bug#385720: m4: INTERNAL ERROR: recursive push_string (fwd)

g is only triggered when you are violating POSIX. On the other hand, as a quality of implementation issue, I totally agree that this is not good practice for GNU software. In the meantime, perhaps Autoconf should document that all autom4te input files should always end in newline. - -- Life

Bug#329358: [bug #14619] find -perm +... broken in 4.2.25

Follow-up Comment #10, bug #14619 (project findutils): You had a slight typo in comment #9 - with umask 0022, the mode "+r" evaluates as 0200 (or perhaps you meant umask 0002, to get 0220), from the point of view of chmod. But your doc patch looked nice. See my note 1 at the end of comment #3.

Bug#329358: [bug #14619] find -perm +... broken in 4.2.25

Follow-up Comment #8, bug #14619 (project findutils): Might I suggest the following documentation approach for the man and info pages: -perm mode: exact match of set and unset bits in symbolic or numeric mode; includes symbolic modes with leading '+' but not with leading '-' -perm -mode: match

Bug#329358: [bug #14619] find -perm +... broken in 4.2.25

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ph. Marek on 10/7/2005 12:10 AM: > On Thursday 06 October 2005 17:49, Eric Blake wrote: > >>Follow-up Comment #4, bug #14619 (project findutils): >> >>I don't think the original poster has discovered

Bug#329358: [bug #14619] find -perm +... broken in 4.2.25

Follow-up Comment #5, bug #14619 (project findutils): $ touch 000 100 111 777 $ for f in * ; do touch $f $f ; done ^ Obviously, that should be a chmod. ___ Reply to this item at:

Bug#329358: [bug #14619] find -perm +... broken in 4.2.25

Follow-up Comment #4, bug #14619 (project findutils): I don't think the original poster has discovered any bugs, rather just their misunderstanding of the (admittedly confusing) POSIX requirements. I have, however, found a bug in 4.2.25: $ touch 000 100 111 777 $ for f in * ; do touch $f $f ; d

Bug#329358: [bug #14619] find -perm +... broken in 4.2.25

Follow-up Comment #3, bug #14619 (project findutils): The POSIX rules are that -perm mode only returns true on files that exactly match mode, if mode is a valid POSIX mode without a leading -; and the POSIX grammar for valid modes includes leading +. The old findutils behavior were often incompa