Bug 723938 - lyx: 'make check' FAIL: tests/test_filetools bogus
Summary: lyx: 'make check' FAIL: tests/test_filetools bogus
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: lyx
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Rex Dieter
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-07-21 15:19 UTC by Rex Dieter
Modified: 2011-07-25 19:58 UTC (History)
10 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2011-07-25 18:42:27 UTC
Type: ---
Embargoed:


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

Description Rex Dieter 2011-07-21 15:19:52 UTC
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.org
========================================

Comment 1 Petr Machata 2011-07-22 10:44:46 UTC
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 04:24:29 UTC
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 11:55:00 UTC
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 16:50:28 UTC
Thanks!

Comment 5 Rex Dieter 2011-07-25 17:01:36 UTC
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 17:01:57 UTC
(sorry, qt-4.7.4 should've been qt-4.7.3)

Comment 7 Rex Dieter 2011-07-25 17:06:25 UTC
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 17:09:25 UTC
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 17:24:26 UTC
making 'make check' non-fatal for now, need to poke lyx upstream about the errant test code.

Comment 10 Rex Dieter 2011-07-25 18:42:27 UTC
bug sent upstream,
http://www.lyx.org/trac/ticket/7695

Comment 11 Petr Machata 2011-07-25 19:58:17 UTC
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.