Bug 9797 - test_parselogs failed on AIGLX error: dlopen of swrast_dri.so failed
Summary: test_parselogs failed on AIGLX error: dlopen of swrast_dri.so failed
Status: VERIFIED DUPLICATE of bug 9717
Alias: None
Product: OE-Core
Classification: Build System, Metadata & Runtime
Component: graphics (show other bugs)
Version: 2.2
Hardware: x86 Multiple
: Medium+ normal
Target Milestone: 2.2 M2
Assignee: Ross Burton
QA Contact: Jose Perez C
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2016-06-17 07:55 UTC by Maxin B. John
Modified: 2016-07-29 16:10 UTC (History)
4 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: Don't know


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Maxin B. John 2016-06-17 07:55:47 UTC
Machine:qemux86-64
Build system:x86_64-linux
Target system:x86_64-poky-linux

Details available here:
http://errors.yoctoproject.org/Errors/Details/69467/

| ======================================================================
| FAIL: test_parselogs (oeqa.runtime.parselogs.ParseLogsTest)
| ----------------------------------------------------------------------
| Traceback (most recent call last):
|   File "/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/meta/lib/oeqa/utils/decorators.py", line 109, in wrapped_f
|     return func(*args, **kwargs)
|   File "/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/meta/lib/oeqa/utils/decorators.py", line 97, in wrapped_f
|     return f(*args, **kwargs)
|   File "/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-multilib/build/meta/lib/oeqa/runtime/parselogs.py", line 277, in test_parselogs
|     self.assertEqual(errcount, 0, msg=self.msg)
| AssertionError: 1 != 0 : Log: Xorg.0.log
| -----------------------
| Central error: [1441851.901] (EE) AIGLX error: dlopen of /usr/lib64/dri/swrast_dri.so failed (/usr/lib64/dri/swrast_dri.so: cannot open shared object file: No such file or directory)
| ***********************
| [1441851.606] (II) Unloading fbdevhw
| [1441851.611] (--) Depth 24 pixmap format is 32 bpp
| [1441851.616] (II) vmware(0): Initialized VMWARE_CTRL extension version 0.2
| [1441851.616] (II) vmware(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0
| [1441851.866] (==) vmware(0): Backing store enabled
| [1441851.866] (==) vmware(0): Silken mouse enabled
| [1441851.880] (WW) vmware(0): Option "DPMS" is not used
| [1441851.884] (==) RandR enabled
| [1441851.897] (II) AIGLX: Screen 0 is not DRI2 capable
| [1441851.898] (EE) AIGLX: reverting to software rendering
| [1441851.901] (EE) AIGLX error: dlopen of /usr/lib64/dri/swrast_dri.so failed (/usr/lib64/dri/swrast_dri.so: cannot open shared object file: No such file or directory)
| [1441851.901] (EE) GLX: could not load software renderer
| [1441851.901] (II) GLX: no usable GL providers found for screen 0
| [1441852.963] (II) Using input driver 'evdev' for 'Generic Keyboard'
| [1441852.968] (**) Option "CoreKeyboard"
| [1441852.968] (**) Generic Keyboard: always reports core events
| [1441852.968] (**) evdev: Generic Keyboard: Device: "/dev/input/by-path/platform-i8042-serio-0-event-kbd"
| [1441852.971] (--) evdev: Generic Keyboard: Vendor 0x1 Product 0x1
| [1441852.975] (--) evdev: Generic Keyboard: Found keys
| [1441852.976] (II) evdev: Generic Keyboard: Configuring as keyboard
| [1441852.976] (II) XINPUT: Adding extended input device "Generic Keyboard" (type: KEYBOARD, id 6)
| 
| ***********************
| 1 errors found in logs.
Comment 1 Jussi Kukkonen 2016-06-18 14:00:14 UTC
Moving to graphics on the assumption that it might actually be a bug.

Maxin: if the test failure looks like it might be legitimate (as in not a test bug), I think it's better to put it in some other component than automated-runtime testing: otherwise we may lose 1-7 days (before triage moves it somewhere).
Comment 2 Jussi Kukkonen 2016-06-19 20:36:23 UTC
nightly-multilib configuration 2 (rpm) fails but configuration 3 (ipk) succeeds. 

I assume mesa-megadriver should end up on the image based on RRECOMMENDS by other mesa packages. I can't reproduce the problem locally: a core-image-sato with rpm  does contain the driver.

Based on autobuilder logs the failure seems to have happened between f14b196ee635b7d3ff1a28099566b2b44ea42c30..2a85038dd03463774fb787b655887297ec4f0a04 . This is 143 commits, including the gtk3 patches. Nothing rpm related as far as I can see.
Comment 3 Ross Burton 2016-06-23 14:43:19 UTC
This is likely an artifact of the broken multilib ordering that was resolved as 9717.

*** This bug has been marked as a duplicate of bug 9717 ***
Comment 4 Jose Perez C 2016-07-29 16:10:46 UTC
Duplicated bug