You are not logged in.
Good idea!
It seems your builds depend now on lib32-lm_sensors (and same with the non 32b, but I already had the package there).
Installing it fixes the issue.
I guess this commit added the optional dependency:
https://cgit.freedesktop.org/mesa/mesa/ … d4e7f0db33
and it's not optional anymore since you added: "--enable-lmsensors --enable-gallium-extra-hud"
You made lib32-lm_sensors a makedepends but it is needed at runtime too
Last edited by gee (2016-10-12 23:48:04)
Offline
You can try to start steam with LIBGL_DEBUG=verbose
[amarildo@amarildo ~]$ LIBGL_DEBUG=verbose firejail steam
Reading profile /etc/firejail/steam.profile
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-programs.inc
Reading profile /etc/firejail/disable-devel.inc
Reading profile /etc/firejail/disable-passwdmgr.inc
Parent pid 11961, child pid 11962
Warning: /sbin directory link was not blacklisted
Warning: /usr/sbin directory link was not blacklisted
Child process initialized
/home/amarildo/.local/share/Steam/steam.sh: line 154: VERSION_ID: unbound variable
/home/amarildo/.local/share/Steam/steam.sh: line 154: VERSION_ID: unbound variable
Running Steam on arch 64-bit
/home/amarildo/.local/share/Steam/steam.sh: line 154: VERSION_ID: unbound variable
STEAM_RUNTIME is enabled automatically
Installing breakpad exception handler for appid(steam)/version(1474415843)
libGL: Can't open configuration file /home/amarildo/.drirc: No such file or directory.
libGL: pci id for fd 7: 1002:6810, driver radeonsi
libGL: OpenDriver: trying /usr/lib32/xorg/modules/dri/tls/radeonsi_dri.so
libGL: OpenDriver: trying /usr/lib32/xorg/modules/dri/radeonsi_dri.so
libGL: dlopen /usr/lib32/xorg/modules/dri/radeonsi_dri.so failed (libsensors.so.4: cannot open shared object file: No such file or directory)
libGL error: unable to load driver: radeonsi_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: radeonsi
libGL: pci id for fd 7: 1002:6810, driver radeonsi
libGL: OpenDriver: trying /usr/lib32/xorg/modules/dri/tls/radeonsi_dri.so
libGL: OpenDriver: trying /usr/lib32/xorg/modules/dri/radeonsi_dri.so
libGL: dlopen /usr/lib32/xorg/modules/dri/radeonsi_dri.so failed (libsensors.so.4: cannot open shared object file: No such file or directory)
libGL error: unable to load driver: radeonsi_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: radeonsi
libGL: OpenDriver: trying /usr/lib32/xorg/modules/dri/tls/swrast_dri.so
libGL: OpenDriver: trying /usr/lib32/xorg/modules/dri/swrast_dri.so
libGL: dlopen /usr/lib32/xorg/modules/dri/swrast_dri.so failed (libsensors.so.4: cannot open shared object file: No such file or directory)
libGL error: unable to load driver: swrast_dri.so
libGL error: failed to load driver: swrast
^C
Parent received signal 2, shutting down the child process...
Parent is shutting down, bye...
Child received signal 15, shutting down the sandbox...
The above is while using your repo. I'm compiling mesa-git from AUR now against llvm-svn and [core] and [extra] to see if it makes any difference.
EDIT: Compiling mesa-git and lib32-mesa-git from AUR solves the problem. Steam starts fine now.
Last edited by Amanda S (2016-10-12 23:59:01)
If it ain't broke, you haven't tweaked it enough...
Offline
See above for the explanation
Offline
Thanks gee, I haven't seen your post before making my own.
If it ain't broke, you haven't tweaked it enough...
Offline
You're welcome, and I had assumed so when I read your post
Offline
Good idea!
It seems your builds depend now on lib32-lm_sensors (and same with the non 32b, but I already had the package there).
Installing it fixes the issue.
You made lib32-lm_sensors a makedepends but it is needed at runtime too
Ooops, should be fixed now! thanks for tracking the problem
Offline
It's the least I can do as a user of you repo!
Offline
Thanks for this thread I been having this problem like two days ago hahaha (just fixed installing again the official mesa), but today I will try to update to check if I have this same problem. By the way can we make a thread been for report issues, I like the idea of first try with official mesa if happen the same is not problem of mesa git, thanks for the work update the repo.
Cheers.
Offline
LordHeavy, would you consider adding a patch that makes Mesa display OGL as 4.5 instead of 4.3? Both OGL 4.4 and 4.5 are already done in Mesa.
If it ain't broke, you haven't tweaked it enough...
Offline
LordHeavy, would you consider adding a patch that makes Mesa display OGL as 4.5 instead of 4.3? Both OGL 4.4 and 4.5 are already done in Mesa.
I am not really enthusiat with this idea, we can potentially expose bugs. One workaround is to use environment variables like MESA_GL_VERSION_OVERRIDE see http://www.mesa3d.org/envvars.html
Offline
I agree with Lordheavy, overriding something like this should be a user decision.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Agreed as well!
I remember when 4.3 was *done* but not flipped on yet, flipping it on with the override in /etc/environment would crash some apps.
Offline
Amarildo wrote:LordHeavy, would you consider adding a patch that makes Mesa display OGL as 4.5 instead of 4.3? Both OGL 4.4 and 4.5 are already done in Mesa.
I am not really enthusiat with this idea, we can potentially expose bugs.
Even though Intel's Mesa driver already does this for Broadwell and newer hardware? [1]
AFAIK Mesa developers are waiting to pass Khronos conformance test, that's the only reason upstream hasn't enabled this for everybody yet, I think.
But I completely understand your point of view.
One workaround is to use environment variables like MESA_GL_VERSION_OVERRIDE see http://www.mesa3d.org/envvars.html
Thanks, I've been using env variables for ~2 days I think https://www.wilderssecurity.com/threads … -3.389258/
Cheers
[1] https://www.phoronix.com/scan.php?page= … esa-GL-4.5
Last edited by Amanda S (2016-10-16 07:40:47)
If it ain't broke, you haven't tweaked it enough...
Offline
Offline
Does anyone have X-plane 10 and mesa-git? If so, can you confirm that setting "Real-world weather" crashes the sim?
Thanks
If it ain't broke, you haven't tweaked it enough...
Offline
I just uploaded a new version of AUR mesa-git .
Upstream had changed the name of some files and this broke the build.
The reason build broke was the fakeinstall / move to pkgdir method AUR mesa-git uses can't handle such a change.
(Stock mesa and LH mesa-git use the same method)
Since i took over AUR mesa-git from Krezji , I've come to dislike the fakeinstall method more and more .
I am considering switching AUR mesa-git from a split package to a single package .
My old mesa-R*-git packages were single packages also,so i know it can be done.
Please tell me what disadvantages / problems you think a single package mesa-git approach will have for users.
Last edited by Lone_Wolf (2016-10-23 15:37:20)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
I just uploaded a new version of AUR mesa-git .
Upstream had changed the name of some files and this broke the build.
The reason build broke was the fakeinstall / move to pkgdir method AUR mesa-git uses can't handle such a change.
(Stock mesa and LH mesa-git use the same method)
See:
http://pkgbuild.com/~lcarlier/mesa-git/ … t/PKGBUILD
http://pkgbuild.com/~lcarlier/mesa-git/ … t/PKGBUILD
throught every aur packages should be built in a chroot,
https://wiki.archlinux.org/index.php/De … ean_Chroot
Last edited by lordheavy (2016-10-23 16:54:09)
Offline
Almost same solution as I used.
The "fakeinstall / move to pkgdir method" has nothing to do with building in a changeroot or running system .
In the build() function there's this :
# fake installation
mkdir -p "${srcdir}"/fakeinstall
make DESTDIR="${srcdir}"/fakeinstall install
In the package_* functions files are then moved to $pkgdir .
I would very much prefer mesa as a single package with just one package() function (and "make install" in package() instead of build ).
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Anyone having problems starting Steam with today's update? I can't start it at all. Deleting libraries, using Steam's native runtime, using LD_PRELOAD.... nothing is working.
[amarildo@amarildo ~]$ LD_PRELOAD='/usr/$LIB/libstdc++.so.6 /usr/$LIB/libgcc_s.so.1 /usr/$LIB/libxcb.so.1 /usr/$LIB/libasound.so.2 '${LD_PRELOAD} steam
/home/amarildo/.local/share/Steam/steam.sh: line 154: VERSION_ID: unbound variable
/home/amarildo/.local/share/Steam/steam.sh: line 154: VERSION_ID: unbound variable
Running Steam on arch 64-bit
/home/amarildo/.local/share/Steam/steam.sh: line 154: VERSION_ID: unbound variable
STEAM_RUNTIME is enabled automatically
Installing breakpad exception handler for appid(steam)/version(1476379980)
libGL error: unable to load driver: radeonsi_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: radeonsi
libGL error: unable to load driver: radeonsi_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: radeonsi
libGL error: unable to load driver: swrast_dri.so
libGL error: failed to load driver: swrast
[amarildo@amarildo ~]$ find /home/amarildo/.steam/steam/ubuntu12_32/ \( -name "libgcc_s.so*" -o -name "libstdc++.so*" -o -name "libxcb.so*" -o -name "libgpg-error.so*" \) -print -delete
[amarildo@amarildo ~]$
[amarildo@amarildo ~]$ steam-native
/home/amarildo/.local/share/Steam/steam.sh: line 154: VERSION_ID: unbound variable
/home/amarildo/.local/share/Steam/steam.sh: line 154: VERSION_ID: unbound variable
Running Steam on arch 64-bit
STEAM_RUNTIME is disabled by the user
Installing breakpad exception handler for appid(steam)/version(1476379980)
libGL error: unable to load driver: radeonsi_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: radeonsi
libGL error: unable to load driver: radeonsi_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: radeonsi
libGL error: unable to load driver: swrast_dri.so
libGL error: failed to load driver: swrast
Last edited by Amanda S (2016-11-07 17:18:18)
If it ain't broke, you haven't tweaked it enough...
Offline
Anyone having problems starting Steam with today's update? I can't start it at all. Deleting libraries, using Steam's native runtime, using LD_PRELOAD.... nothing is working.
mesa-git is currently broken because of a recent llvm changed the C api. You must revert llvm-svn and lib32-llvm-svn to previous version.
edit: see https://bugs.freedesktop.org/show_bug.cgi?id=98627
Last edited by lordheavy (2016-11-07 17:23:10)
Offline
Damn, I don't recommend people to upgrade their git/svn packages today, they'll break EVERYTHING. I locked my system (Ctrl Alt L) and when I came back nothing was working.
Here, let me save you the work if some of you did the same as me
Go to /var/cache/pacman/pkg and do the following
pacman -U llvm-svn-286033-1-x86_64.pkg.tar.xz llvm-libs-svn-286033-1-x86_64.pkg.tar.xz lib32-llvm-libs-svn-286033-1-x86_64.pkg.tar.xz lib32-mesa-git-86285.84a74be-1-x86_64.pkg.tar.xz lib32-mesa-libgl-git-86285.84a74be-1-x86_64.pkg.tar.xz mesa-git-86285.84a74be-1-x86_64.pkg.tar.xz mesa-libgl-git-86285.84a74be-1-x86_64.pkg.tar.xz opencl-mesa-git-86285.84a74be-1-x86_64.pkg.tar.xz clang-svn-286033-1-x86_64.pkg.tar.xz clang-tools-extra-svn-286033-1-x86_64.pkg.tar.xz
If it ain't broke, you haven't tweaked it enough...
Offline
Amarildo wrote:Anyone having problems starting Steam with today's update? I can't start it at all. Deleting libraries, using Steam's native runtime, using LD_PRELOAD.... nothing is working.
mesa-git is currently broken because of a recent llvm changed the C api. You must revert llvm-svn and lib32-llvm-svn to previous version.
edit: see https://bugs.freedesktop.org/show_bug.cgi?id=98627
With this being the case, does it make sense to offer the troublesome llvm packages in your mesa-git repository before mesa gets tstellar's fixes?
Offline
lordheavy wrote:Amarildo wrote:Anyone having problems starting Steam with today's update? I can't start it at all. Deleting libraries, using Steam's native runtime, using LD_PRELOAD.... nothing is working.
mesa-git is currently broken because of a recent llvm changed the C api. You must revert llvm-svn and lib32-llvm-svn to previous version.
edit: see https://bugs.freedesktop.org/show_bug.cgi?id=98627
With this being the case, does it make sense to offer the troublesome llvm packages in your mesa-git repository before mesa gets tstellar's fixes?
yeah, i'm trying currently to build llvm with offending commit reverted, in case of failure i will downgrade llvm in the git repo
Last edited by lordheavy (2016-11-08 03:59:32)
Offline
Great!
Offline
..and it worked!
Thank you!
Offline