Mir tests fail in mock build (Fedora 27)

[Conan-Kudo]

When trying to build Mir 0.28.1 for Fedora 27 with the tests enabled, one of the tests fail:

17: [ RUN ] MesaGraphicsPlatform.connection_ipc_package
17: [2017-11-02 14:54:39.357042] mesa-kms: Using DRM device /dev/dri/card1
17: [2017-11-02 14:54:39.357132] mesa-kms: Using DRM device /dev/dri/card0
17: unknown file: Failure
17: 
17: Unexpected mock function call - returning default value.
17: Function call: drmAuthMagic(8, 32659)
17: Returns: 0
17: Google Mock tried the following 1 expectation, but it didn't match:
17: 
17: /builddir/build/BUILD/mir-0.28.1/tests/unit-tests/platforms/mesa/kms/test_platform.cpp:108: EXPECT_CALL(mock_drm, drmAuthMagic(mtd::IsFdOfDevice("/dev/dri/card0"),_))...
17: Expected arg #0: Is an fd of DRM device /dev/dri/card0 (one of: { 10 })
17: Actual: 8
17: Expected: to be called once
17: Actual: never called - unsatisfied and active
17: /builddir/build/BUILD/mir-0.28.1/tests/unit-tests/platforms/mesa/kms/test_platform.cpp:108: Failure
17: Actual function call count doesn't match EXPECT_CALL(mock_drm, drmAuthMagic(mtd::IsFdOfDevice("/dev/dri/card0"),_))...
17: Expected: to be called once
17: Actual: never called - unsatisfied and active
17: [ FAILED ] MesaGraphicsPlatform.connection_ipc_package (7 ms)

[AlanGriffiths]

@Conan-Kudo just this one test failed? (Not sure what could cause that.) Is the full log available?

[AlanGriffiths]

BTW you can run the test in isolation:

LD_PRELOAD=libumockdev-preload.so.0 build/bin/mir_unit_tests_mesa-kms --gtest_filter=MesaGraphicsPlatform.connection_ipc_package

(It's working for me on F26, need to set up F27)

[Conan-Kudo]

Here's the complete build log: mir-build-log-f27.txt

[Conan-Kudo]

@AlanGriffiths Yes, it's the only test that fails, all the rest work inside the mock build environment.

[AlanGriffiths]

@Conan-Kudo there's something different between what I'm doing and what you're doing.

I grabbed an F27 ISO...

$ sudo dnf install bzr cmake gcc-c++ boost-devel mesa-libEGL-devel
mesa-libGLES-devel glm-devel protobuf-lite-devel protobuf-compiler
capnproto-devel capnproto glog-devel gflags-devel systemd-devel
glib2-devel wayland-devel mesa-libgbm-devel libepoxy-devel nettle-devel
libinput-devel libxml++-devel libuuid-devel libxkbcommon-devel
freetype-devel lttng-ust-devel libatomic qterminal qt5-qtwayland
python3-pillow libevdev-devel umockdev-devel gtest-devel gmock-devel
$ bzr branch lp:mir/0.28 mir
$ mkdir mir/build
$ cd mir/build
$ cmake ..
$ make -j2 all test
...
100% tests passed, 0 tests failed out of 21

Total Test time (real) = 181.50 sec

[Conan-Kudo]

@AlanGriffiths I'm doing it in a mock build, it's an systemd-nspawn container of Fedora 27.

[AlanGriffiths]

I don't know how to reproduce that.

[AlanGriffiths]

I'm not going to have time to guess how to reproduce this week.

[Conan-Kudo]

@AlanGriffiths I've prepared a reproducer for you:

1. Install and setup Mock per the instructions
2. Download the Source RPM
3. Run mock -r fedora-27-x86_64 mir-0.28.1-0.fc28.1.src.rpm

It will reproducibly fail exactly the same way every time.

[AlanGriffiths]

thanks @Conan-Kudo

[AlanGriffiths]

@Conan-Kudo I followed the instructions, but got no error. :(

build.log

[Conan-Kudo]

@AlanGriffiths What's your graphical environment like? Mine is Plasma 5, and I ran the mock command inside of Konsole.

[AlanGriffiths]

I don't see why graphical environment should matter but it is clearly something that differs between our setups.

I'm using LXQT & I ran the commands in qterminal. I've also installed the mir dependencies listed in https://community.ubuntu.com/t/mir-running-on-fedora/893/4 and built Mir since creating the VM.

[Conan-Kudo]

@AlanGriffiths At this point, I'm trying to figure out why this happens for me but not you...

[AlanGriffiths]

@Conan-Kudo Yes, it is weird.

AFAICS the only thing that touches the system in that test is umockdev (which creates nodes in /tmp). But if that's broken, the other tests that use it should exhibit problems too.

[Conan-Kudo]

@AlanGriffiths nspawn creates a private /tmp, so that shouldn't be broken?

[Conan-Kudo]

I'm going to see if I can reproduce this on another system...

[Conan-Kudo]

So, this is madness. It's only broken on one of my computers. I don't know why, and it works fine everywhere else.

As this will just lead me to go down a rabbit hole that isn't worth it right now, I'm closing this. If it comes up again somewhere else by me or someone else, feel free to reopen.