Bug 499657 - Bogus testsuite failures due to permissions
Bogus testsuite failures due to permissions
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: systemtap (Show other bugs)
All Linux
low Severity medium
: rc
: ---
Assigned To: Frank Ch. Eigler
Depends On:
Blocks: 513654
  Show dependency treegraph
Reported: 2009-05-07 11:10 EDT by Petr Muller
Modified: 2016-09-19 22:05 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 513654 (view as bug list)
Last Closed: 2009-09-02 06:01:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Petr Muller 2009-05-07 11:10:30 EDT
Description of problem:
Three of the testcases in systemtap-testsuite rpm are treated as executables, but the are not in fact. This brings bogus failures to the results of the testsuite. They are:

a) systemtap.base/bz10078.stp
b) buildko/two.stp
c) buildok/thirty.stp

Version-Release number of selected component (if applicable):
# rpm -q systemtap-testsuite

How reproducible:

Steps to Reproduce:
1. for a) runtest --tool=systemtap systemtap.base/bz10078.exp
2. for b) runtest --tool=systemtap systemtap.pass1-4/buildko.exp
3. for c) runtest --tool=systemtap systemtap.pass1-4/buildok.exp
Actual results:
ERROR: tcl error sourcing ./systemtap.base/bz10078.exp
ERROR: couldn't execute "./systemtap.base/bz10078.stp": permission denied

ERROR: tcl error sourcing ./systemtap.pass1-4/buildko.exp.
ERROR: couldn't execute "./buildko/two.stp": permission denied

ERROR: tcl error sourcing ./systemtap.pass1-4/buildok.exp.
ERROR: couldn't execute "./buildok/thirty.stp": permission denied

Expected results:
After chmod a+x -ing, I see no such ERRORs and get some relevant results.

Additional info:
This manifests even when runnning the whole testsuite with 'make installcheck'
Comment 1 Frank Ch. Eigler 2009-05-07 11:26:42 EDT
Thanks, fixed upstream.  It wouldn't be worth respinning just for this,
but we could easily lump it into the next incidental respin.

Since permissions can't be changed with a plain .patch file,
fixing this in the rhel 0.9.7 build would take a few explicit chmod's
in the spec file.
Comment 3 Petr Muller 2009-05-11 08:33:39 EDT
Comment 8 errata-xmlrpc 2009-09-02 06:01:15 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.