GNU bug report logs -
#19692
"rm -f" without file operands specified displays error and exits with status 1 on QNX 6.3.2
Previous Next
To reply to this bug, email your comments to 19692 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-automake <at> gnu.org
:
bug#19692
; Package
automake
.
(Mon, 26 Jan 2015 16:47:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Matt Kraai <kraai <at> ftbfs.org>
:
New bug report received and forwarded. Copy sent to
bug-automake <at> gnu.org
.
(Mon, 26 Jan 2015 16:47:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi,
When "rm -f" is run without any file operands on QNX 6.3.2, it outputs
the following message and exits with status 1:
rm: Must specify file[s] for removal.
My $PATH is
/sbin:/usr/sbin:/bin:/usr/bin:/usr/photon/bin:/usr/photon/appbuilder:/opt/X11R6/bin:/usr/X11R6/bin:/usr/local/bin:/opt/bin:/opt/sbin:/usr/qnx632/host/qnx6/x86/usr/bin:/usr/qnx632/host/qnx6/x86/usr/sbin:/usr/qnx632/host/qnx6/x86/sbin:/usr/qnx632/host/qnx6/x86/bin:/usr/qnx632/host/qnx6/x86/usr/photon/appbuilder
--
Matt
Added indication that bug 19692 blocks10828
Request was from
Mike Frysinger <vapier <at> gentoo.org>
to
control <at> debbugs.gnu.org
.
(Fri, 10 Dec 2021 05:45:02 GMT)
Full text and
rfc822 format available.
Added tag(s) pending.
Request was from
Mike Frysinger <vapier <at> gentoo.org>
to
control <at> debbugs.gnu.org
.
(Fri, 10 Dec 2021 05:52:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-automake <at> gnu.org
:
bug#19692
; Package
automake
.
(Thu, 25 Jan 2024 21:54:01 GMT)
Full text and
rfc822 format available.
Message #12 received at 19692 <at> debbugs.gnu.org (full text, mbox):
Hi Matt - back in 2015
(https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19692, sorry for the
delayed reply) you reported that your system failed the rm -f test.
For the next automake release, we've removed this test and tried to
accept any rm. (More info: https://bugs.gnu.org/10828.)
If you have a chance to try an automake pretest to confirm this
(downloadable from https://alpha.gnu.org/gnu/automake-1.16j.tar.gz),
that would be great. --thanks, karl.
Information forwarded
to
bug-automake <at> gnu.org
:
bug#19692
; Package
automake
.
(Sun, 28 Jan 2024 04:31:02 GMT)
Full text and
rfc822 format available.
Message #15 received at 19692 <at> debbugs.gnu.org (full text, mbox):
Hi Karl,
I was able to bootstrap, configure, build and install automake-1.16j. Is there any other testing I should do?
Matt
> On Jan 25, 2024, at 1:52 PM, Karl Berry <karl <at> freefriends.org> wrote:
>
> Hi Matt - back in 2015
> (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=19692, sorry for the
> delayed reply) you reported that your system failed the rm -f test.
>
> For the next automake release, we've removed this test and tried to
> accept any rm. (More info: https://bugs.gnu.org/10828.)
>
> If you have a chance to try an automake pretest to confirm this
> (downloadable from https://alpha.gnu.org/gnu/automake-1.16j.tar.gz),
> that would be great. --thanks, karl.
Information forwarded
to
bug-automake <at> gnu.org
:
bug#19692
; Package
automake
.
(Sun, 28 Jan 2024 23:37:02 GMT)
Full text and
rfc822 format available.
Message #18 received at 19692 <at> debbugs.gnu.org (full text, mbox):
I was able to bootstrap, configure, build and install
automake-1.16j.
Great!
Is there any other testing I should do?
If you're up for it, you could run make -j8 check (or -jwhatever) just
to see if other tests fail. (It will take several hours to run without
the -j, although unfortunately the -j might also induce spurious
failures. Always looking for more data about this to try to make things
more robust.)
Thanks,
Karl
Information forwarded
to
bug-automake <at> gnu.org
:
bug#19692
; Package
automake
.
(Mon, 29 Jan 2024 14:14:02 GMT)
Full text and
rfc822 format available.
Message #21 received at 19692 <at> debbugs.gnu.org (full text, mbox):
Hi Karl,
When I run ‘make check’, it fails after passing t/pm/Wrap.pl with the following error:
sh: >&3 : bad file descriptor
tap-driver.sh: fatal: I/O or internal error
Matt
> On Jan 28, 2024, at 3:36 PM, Karl Berry <karl <at> freefriends.org> wrote:
>
> I was able to bootstrap, configure, build and install
> automake-1.16j.
>
> Great!
>
> Is there any other testing I should do?
>
> If you're up for it, you could run make -j8 check (or -jwhatever) just
> to see if other tests fail. (It will take several hours to run without
> the -j, although unfortunately the -j might also induce spurious
> failures. Always looking for more data about this to try to make things
> more robust.)
>
> Thanks,
> Karl
>
Information forwarded
to
bug-automake <at> gnu.org
:
bug#19692
; Package
automake
.
(Mon, 29 Jan 2024 23:02:02 GMT)
Full text and
rfc822 format available.
Message #24 received at 19692 <at> debbugs.gnu.org (full text, mbox):
When I run ‘make check’, it fails after
passing t/pm/Wrap.pl with the following error:
sh: >&3 : bad file descriptor
tap-driver.sh: fatal: I/O or internal error
Thanks for trying, though sorry to see that result. It's not clear to me
what test is failing or what the environment is. File descriptor 3 is
used in tap-driver.sh, but seemingly not in a complicated way.
If you have time, please try running (without any -j, for simplicity):
make VERBOSE=1 TESTS_ENVIRONMENT='echo RUNNING: "$$f";' check >chkout 2>&1
And, assuming it still fails, send the resulting
chkout and test-suite.log files (gzipped is best).
The TESTS_ENVIRONMENT value should print "RUNNING: <testname>" when a test
is begun, as well as the usual report when a test is finished. --thanks, karl.
This bug report was last modified 1 year and 138 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.