Bug 723938 - lyx: 'make check' FAIL: tests/test_filetools bogus
lyx: 'make check' FAIL: tests/test_filetools bogus
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: lyx (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Rex Dieter
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-07-21 11:19 EDT by Rex Dieter
Modified: 2011-07-25 15:58 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-07-25 14:42:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Reproducer (536 bytes, text/plain)
2011-07-25 07:55 EDT, Petr Machata
no flags Details

  None (edit)
Description Rex Dieter 2011-07-21 11:19:52 EDT
Seems to be failing in 'make check':

make  check-TESTS
make[5]: Entering directory `/builddir/build/BUILD/lyx-2.0.0/src/support'
PASS: tests/test_convert
FAIL: tests/test_filetools
PASS: tests/test_lstrings
========================================
1 of 3 tests failed
Please report to lyx-devel@lists.lyx.org
========================================
Comment 1 Petr Machata 2011-07-22 06:44:46 EDT
This works for me in mock chroot (on x86_64).  Is that reproducible?  Or maybe it's the result of my boost::throw_exception fix.  In any case, would you re-try with boost-1.47.0-2.fc16 in build root?
Comment 2 Rex Dieter 2011-07-23 00:24:29 EDT
still failing in koji against boost-1.47.0-2.fc16

https://koji.fedoraproject.org/koji/taskinfo?taskID=3224589
Comment 3 Petr Machata 2011-07-25 07:55:00 EDT
Created attachment 515021 [details]
Reproducer

This reproduces the problem without boost.  When I run this in x86_64 mock, it works as expected:

mock-chroot> g++ ../../../x.cc -I /usr/include/QtCore/ -lQtCore
mock-chroot> ./a.out 
/bar

But in i386, it fails the same way that the test case in LyX fails:

mock-chroot> g++ ../../../x.cc -I /usr/include/QtCore/ -lQtCore
mock-chroot> ./a.out 
/foo/../bar

The reproducer captures the way that lyx-2.0.0/src/support/FileName.cpp is used by check_filetools.cpp.  I don't think boost is the cause here.
Comment 4 Rex Dieter 2011-07-25 12:50:28 EDT
Thanks!
Comment 5 Rex Dieter 2011-07-25 13:01:36 EDT
Yep, interestingly, I can reproduce the errant behavior on my x86_64 box with qt-4.8 installed.

qt-4.7.4 output:
/bar

same binary, run against qt-4.8.0-beta1:
/foo/../bar
(recompiling doesn't help or change output).
Comment 6 Rex Dieter 2011-07-25 13:01:57 EDT
(sorry, qt-4.7.4 should've been qt-4.7.3)
Comment 7 Rex Dieter 2011-07-25 13:06:25 EDT
As this is not a lyx problem, I'll reassign this to qt, and let lyx consider that failed test non-fatal to the build.

Now, to decide if this is QFileInfo absoluteFilePath bug/regresssion or an invalid assumption in lyx testsuite code.
Comment 8 Rex Dieter 2011-07-25 13:09:25 EDT
My reading of,
http://doc.qt.nokia.com/4.7/qfileinfo.html#absoluteFilePath

seems that lyx code is invalid,

In contrast to canonicalFilePath(), symbolic links or redundant "." or ".." elements are not necessarily removed.
Comment 9 Rex Dieter 2011-07-25 13:24:26 EDT
making 'make check' non-fatal for now, need to poke lyx upstream about the errant test code.
Comment 10 Rex Dieter 2011-07-25 14:42:27 EDT
bug sent upstream,
http://www.lyx.org/trac/ticket/7695
Comment 11 Petr Machata 2011-07-25 15:58:17 EDT
Duh, my two mocks were init'ed with different qt versions--4.7.3 vs. 4.8 beta. Hence the change in behavior across arches.

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