| Summary: | lyx: 'make check' FAIL: tests/test_filetools bogus | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Rex Dieter <rdieter> | ||||
| Component: | lyx | Assignee: | Rex Dieter <rdieter> | ||||
| Status: | CLOSED UPSTREAM | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | rawhide | CC: | itamar, jamatos, jreznik, kevin, ltinkl, pmachata, rdieter, rnovacek, smparrish, than | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2011-07-25 18:42:27 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Attachments: |
|
||||||
|
Description
Rex Dieter
2011-07-21 15:19:52 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? 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. |