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 ========================================
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?
still failing in koji against boost-1.47.0-2.fc16 https://koji.fedoraproject.org/koji/taskinfo?taskID=3224589
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.
Thanks!
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).
(sorry, qt-4.7.4 should've been qt-4.7.3)
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.
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.
making 'make check' non-fatal for now, need to poke lyx upstream about the errant test code.
bug sent upstream, http://www.lyx.org/trac/ticket/7695
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.