- User Since
- Dec 17 2014, 10:23 PM (213 w, 4 d)
Fri, Jan 18
Thu, Jan 17
Wed, Jan 16
Thanks for checking that @bshah.
It's used for Gitlab, not sure why it would be invalid now, they must have changed their key.
Tue, Jan 15
Sun, Jan 13
Sat, Jan 12
Fri, Jan 11
Thu, Jan 10
People inquired on IRC as to why they weren't able to access the diff - it does no harm in it's current form of abandoned.
Visibility restored to public per request of the Community.
Wed, Jan 9
The files have now been released as requested.
Tue, Jan 8
Mon, Jan 7
Sun, Jan 6
Cool, i've now made that change to remove it.
Many thanks for enabling surfaceless in those packages Fabian - very much appreciated.
I can confirm that has fixed the issue with KWin tests - https://build.kde.org/job/Plasma/job/kwin/job/kf5-qt5%20SUSEQt5.11/
Sat, Jan 5
Martin and Vlad, could you please file the relevant bug? I'm not familiar enough with Mesa to provide all the information which they may need.
Luca and Fabian, what's the best way of getting this rectified? Filing a bug against Mesa at SUSE?
@graesslin Should I remove the VGem device as well? It seems the tests still fail after setting that environment variable.
Cool, this can go in then from my perspective :)
Note that per the investigation by @zzag above, it looks like this is only triggered in scenarios where VGem is present, so it's likely most environments wouldn't see this.
I'll ask our OpenSUSE packagers if something can be done. Given that the packaging for the older version is still around it should hopefully be fairly straight forward for them to provide something.
I would love to, but unfortunately Tumbleweed has already withdrawn the older versions of Mesa from it's repositories, so we're unable to do so :(
The only repositories containing older Mesa's for Tumbleweed now are people's personal home:* repositories (per https://software.opensuse.org/package/Mesa)
I've done some research and from what I can tell, having multiple PDB files for a given file is not possible (it's strictly one per dll/exe)
Fri, Jan 4
Guess that confirms it's a Mesa regression - will you and Martin handle sorting it with the Mesa devs?
That would seem to support the theory that Mesa has a regression with regards to VGem support...
Okay. The CI system is currently using Mesa 18.3.1 - how does this compare to your local system?
When you try to reproduce locally, are you using the docker images we ship at Dockerhub, or a SUSE VM?
Thu, Jan 3
So it's not liking connecting to our Xvfb instance?
Thanks for reporting. It would appear the latest round of PHP updates shot us in the foot....
This has now been corrected and Nextcloud should be up and running again.
Wed, Jan 2
I've now re-run the builds - does that output give any clues?
The CMake version bump is fine from my perspective given that Frameworks requires a higher version than what you're bumping it to.
It would appear this is our cause:
MESA-LOADER: failed to retrieve device information gbm: failed to open any driver (search paths /usr/lib64/dri) gbm: Last dlopen error: /usr/lib64/dri/vgem_dri.so: cannot open shared object file: No such file or directory failed to load driver: vgem
Tue, Jan 1
I've investigated this and it appears shortly before this regression occurred, we did a rebuild of our SUSE images.
So it would seem that this regression is due to something in the software stack (probably Mesa/X/Wayland)