Spec URL: http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora17/spec/1/VirtualGL.spec SRPM URL: http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora17/SRPMS/VirtualGL-2.3-2.fc17.src.rpm Description: VirtualGL is a toolkit that allows most Unix/Linux OpenGL applications to be remotely displayed with hardware 3D acceleration to thin clients, regardless of whether the clients have 3D capabilities, and regardless of the size of the 3D data being rendered or the speed of the network. Using the vglrun script, the VirtualGL "faker" is loaded into an OpenGL application at run time. The faker then intercepts a handful of GLX calls, which it reroutes to the server's X display (the "3D X Server", which presumably has a 3D accelerator attached.) The GLX commands are also dynamically modified such that all rendering is redirected into a Pbuffer instead of a window. As each frame is rendered by the application, the faker reads back the pixels from the 3D accelerator and sends them to the "2D X Server" for compositing into the appropriate X Window. VirtualGL can be used to give hardware-accelerated 3D capabilities to VNC or other X proxies that either lack OpenGL support or provide it through software rendering. In a LAN environment, VGL can also be used with its built-in high-performance image transport, which sends the rendered 3D images to a remote client (vglclient) for compositing on a remote X server. VirtualGL also supports image transport plugins, allowing the rendered 3D images to be sent or captured using other mechanisms. VirtualGL is based upon ideas presented in various academic papers on this topic, including "A Generic Solution for Hardware-Accelerated Remote Visualization" (Stegmaier, Magallon, Ertl 2002) and "A Framework for Interactive Hardware Accelerated Remote 3D-Visualization" (Engel, Sommer, Ertl 2000.) Fedora Account System Username: gsgatlin.edu
Hello. This package was actually created by Robin Lee. It is a dependency for https://bugzilla.redhat.com/show_bug.cgi?id=827167 This is one of the first packages I have submitted and I need a sponsor.
Couple initial comments: - Please update to 2.3.1 - Blank lines between changelog entries - mesa-libGLU-devel will bring in libX11-devel, libXext-devel, and mesa-libGL-devel, so no need to list them. - The -devel Requires need %{?_isa} added - You need to use %cmake28 in EPEL6 - I would change the cmake conditional to: %if 0%{?rhel} == 6 BuildRequires: cmake28 %else BuildRequires: cmake %endif and %if 0%{?rhel} == 6 %cmake28 -DTJPEG_INCLUDE_DIR=%{_includedir} \ %else %cmake -DTJPEG_INCLUDE_DIR=%{_includedir} \ %endif As that is the exceptional condition. - I recommend doing out of tree builds for cmake, but this isn't necessary. rpmlint: VirtualGL.x86_64: E: invalid-soname /usr/lib64/libdlfaker.so libdlfaker.so VirtualGL.x86_64: E: invalid-soname /usr/lib64/librrfaker.so librrfaker.so VirtualGL.x86_64: E: invalid-soname /usr/lib64/libgefaker.so libgefaker.so These get preloaded via the vglrun wrapper script. I think they should go into %{_libdir}/VirtualGL. VirtualGL.x86_64: W: shared-lib-calls-exit /usr/lib64/librrfaker.so exit.5 can be ignored VirtualGL.x86_64: E: incorrect-fsf-address /usr/share/doc/VirtualGL-2.3/LGPL.txt contact upstream and tell them to fix that.
Your comment was: Ok. It seems there are problems.... Atrtempt #2 which is currently broken and unuseable. :( http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora17/spec/2/VirtualGL.spec http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora17/SRPMS/VirtualGL-2.3.1-1.fc17.src.rpm [gsgatlin@nom0047567 ~]$ optirun glxgears ERROR: ld.so: object 'libdlfaker.so' from LD_PRELOAD cannot be preloaded: ignored. ERROR: ld.so: object 'librrfaker.so' from LD_PRELOAD cannot be preloaded: ignored. Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 341 frames in 5.0 seconds = 67.903 FPS runs like crap. Admitedly I did not try rebooting yet. So moving libdlfaker.so, at least in the way I did broke it. So I am guessing It must be changed back in order to fix the app. ? How can I do this in terms a noob would understand please. (If cmake puts it in the wrong place how can I put it in the right place without "mv" in the specfile? since mv breaks the app) Also, %if 0%{?rhel} == 6 %cmake28 -DTJPEG_INCLUDE_DIR=%{_includedir} \ -DTJPEG_LIBRARY=%{_libdir}/libturbojpeg.so \ -DVGL_USESSL=ON -DVGL_LIBDIR=%{_libdir} \ -DVGL_DOCDIR=%{_docdir}/%{name}-%{version}/ \ -DVGL_FAKELIBDIR=%{_libdir}/fakelib/ . %else %cmake -DTJPEG_INCLUDE_DIR=%{_includedir} \ -DTJPEG_LIBRARY=%{_libdir}/libturbojpeg.so \ -DVGL_USESSL=ON -DVGL_LIBDIR=%{_libdir} \ -DVGL_DOCDIR=%{_docdir}/%{name}-%{version}/ \ -DVGL_FAKELIBDIR=%{_libdir}/fakelib/ . %endif make %{?_smp_mflags} results in this on rhel 6... [gsgatlin@localhost specs]$ rpmbuild -ba VirtualGL.spec Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.PIMqn5 + umask 022 + cd /home/gsgatlin/redhat/BUILD + LANG=C + export LANG + unset DISPLAY + cd /home/gsgatlin/redhat/BUILD + rm -rf VirtualGL-2.3.1 + /bin/tar -xf - + /usr/bin/gzip -dc /home/gsgatlin/redhat/SOURCES/VirtualGL-2.3.1.tar.gz + STATUS=0 + '[' 0 -ne 0 ']' + cd VirtualGL-2.3.1 + /bin/chmod -Rf a+rX,u+w,g-w,o-w . + exit 0 Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.ekgvFk + umask 022 + cd /home/gsgatlin/redhat/BUILD + cd VirtualGL-2.3.1 + LANG=C + export LANG + unset DISPLAY + %cmake28 -DTJPEG_INCLUDE_DIR=/usr/include -DTJPEG_LIBRARY=/usr/lib64/libturbojpeg.so -DVGL_USESSL=ON -DVGL_LIBDIR=/usr/lib64 -DVGL_DOCDIR=/usr/share/doc/VirtualGL-2.3.1/ -DVGL_FAKELIBDIR=/usr/lib64/fakelib/ . /var/tmp/rpm-tmp.ekgvFk: line 33: fg: no job control error: Bad exit status from /var/tmp/rpm-tmp.ekgvFk (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.ekgvFk (%build) So I changed that back for RHEL 6. Any advice appriciated.
You need to patch the vglrun script to point to the correct location of the libraries when setting LD_PRELOAD.
Sorry. Thank you for your help. I am trying to wrap my head around this vglrun script. I tried to make this edit: http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora17/spec/vglrun/vglrun.broke This is the original script: http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora17/spec/vglrun/vglrun.orig With my dumb edits, I get this error: gsgatlin@nom0047567 gsgatlin]$ optirun glxgears ERROR: ld.so: object 'VirtualGL/libdlfaker.so' from LD_PRELOAD cannot be preloaded: ignored. ERROR: ld.so: object 'VirtualGL/librrfaker.so' from LD_PRELOAD cannot be preloaded: ignored. Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 341 frames in 5.0 seconds = 67.934 FPS 300 frames in 5.0 seconds = 59.704 FPS 300 frames in 5.0 seconds = 59.703 FPS Do I need absolute paths? Should I be setting LD_PRELOAD earlier at the beginning of the script? Should I make massive edits to get rid of the /opt stuff and instead relace with /usr/lib64/VirtualGL/blah.so and /usr/lib/VirtualGL/blah.so ? I aplogize if these are stupid questions. I know I how to make a patch if I can get the script working... But I am unsure how to proceed on the vglrun script itself. Thanks again for any ideas anyone might have?
You need full paths. You don't need to do it any earlier. It might be easier to just write a new version from scratch that drops all of the /opt crap.
Greetings. Attempt #3 with paths patch added. http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora17/spec/3/VirtualGL.spec http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora17/SRPMS/VirtualGL-2.3.1-2.fc17.src.rpm Further question... /usr/share/doc/VirtualGL-2.3.1/LGPL.txt the address listed is: 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA What should I ask the VirtualGL developers to change that to? Or was some other address mentioned such as an email address? (I do not see one in the file) I did not see that in the output when I ran rpmlint. Thank you. Please let me know if further changes are required to meet packaging guidelines?
Looks like they updated the address from 2.3->2.3.1 so that is all set.
I think you need use the output of uname -i to determine architecture instead of existence of /usr/lib64. I actually have a /usr/lib64 on my 32-bit machine from rubygems (although that may be a packaging error). Or perhaps test for /usr/lib64/VirtualGL.
Greetings, Here is attempt #4. http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora17/spec/4/VirtualGL.spec http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora17/SRPMS/VirtualGL-2.3.1-3.fc17.src.rpm I did find that I had to use the %cmake28 macro on rhel 6 with cmake28 from epel. So thanks for helping with that. If fixed that in this latest version. Since I eat my own dog food, last night I have identified a problem in a game called minecraft I am somewhat addicted to. With VirtualGL 2.3 if you press "Quit" on the splash screen the minecraft application quits normally and the window closes. If you upgrade to VirtualGL 2.3.1, when you hit the quit button the window turns black, locks up, and this error occurs on the console output: Stopping! SoundSystem shutting down... Author: Paul Lamb, www.paulscode.com Exception in thread "Minecraft main thread" org.lwjgl.LWJGLException: X Error - disp: 0x7fdea400f760 serial: 2678 error: BadWindow (invalid Window parameter) request_code: 15 minor_code: 0 at org.lwjgl.opengl.LinuxDisplay.globalErrorHandler(LinuxDisplay.java:268) at org.lwjgl.opengl.LinuxDisplay.nDestroyWindow(Native Method) at org.lwjgl.opengl.LinuxDisplay.destroyWindow(LinuxDisplay.java:484) at org.lwjgl.opengl.Display.destroyWindow(Display.java:352) at org.lwjgl.opengl.Display.destroy(Display.java:967) at net.minecraft.client.Minecraft.d(SourceFile:527) at net.minecraft.client.Minecraft.run(SourceFile:688) at java.lang.Thread.run(Thread.java:662) If the app is windowed you can close the window by left clicking the close widget, at least in GNOME 3. (And GNOME 2 in RHEL 6) I belive this error also occours with "Stella" a Atari 2600 emulator. It is worse there because it is harder to exit full screen mode without rebooting. I am going to test that after hitting submit on this bugzilla comment. Both of these problems happen when using the integrated intel display with both programs but bumblebee/virtualGL had worked around the issue for me. It is troubling to see it come back with the new VirtualGL. But perhaps other people won't care? After some tests is for sure something in VirtualGL 2.3.1 and not something I am doing like moving libraries or changing wrappers. However, I see nothing obvious. In the changelog for version 2.3.1 it mentions that: ------------------------------------------------------------------------------- [2] VirtualGL now properly handles implicit deletion of windows/subwindows via XCloseDisplay(), implicit deletion of subwindows via XDestroyWindow(), and explicit deletion of subwindows via XDestroySubwindows(). This specifically addresses BadDrawable errors that occurred when running certain applications in WINE 1.3.34 and later. ------------------------------------------------------------------------------- But perhaps this fix has actually made things worse for me? I can always run an old version myself but I wonder if this will mess other people up? I am not sure if I am clever enough to figure out what is going on here. hmnn... I will give it some more thought over the next few days. Perhaps I could use strace or something to figure out why this is hapenning.
Update, stella is not affected. Bug seems to only affect minecraft so far. :)
Sorry, don't mean to spam but perhaps this isn't as bad as I first thought. It seems to only affect minecraft in windowed mode. So I don't see it crashing a display like stella did with intel. Let me know if further changes are needed.
Gary - You're going to need to work with upstream I think to resolve your runtime issues. Starting to look further, looks like we have some bundled libraries: server/fltk common/glx.h common/glxext.h You'll want to remove these in %prep and see what you need to do to build with the system versions. glxdemos - this is tricky as they add and install glxspheres{.c}. But the other files are part of the glx package. Need to try to build glxsperes with the system glx stuff.
Here is my attempt to use system fltk and glx headers http://www.cora.nwra.com/~orion/fedora/VirtualGL-2.3.1-3.fc17.src.rpm
I would just not ship glxinfo at all.
So, if that didn't break anything (test it out and let me know), that should take care of the bundling.
Package Review ============== Key: - = N/A x = Pass ! = Fail ? = Not evaluated ==== C/C++ ==== [x]: MUST Header files in -devel subpackage, if present. [x]: MUST Package does not contain any libtool archives (.la) [x]: MUST Package does not contain kernel modules. [x]: MUST Package contains no static executables. [x]: MUST Rpath absent or only used for internal libs. [x]: MUST Package is not relocatable. [!]: MUST Development (unversioned) .so files in -devel subpackage, if present. Note: VirtualGL-2.3.1-2.fc17.i686.rpm : /usr/lib/VirtualGL/libdlfaker.so VirtualGL-2.3.1-2.fc17.i686.rpm : /usr/lib/VirtualGL/libgefaker.so VirtualGL-2.3.1-2.fc17.i686.rpm : /usr/lib/VirtualGL/librrfaker.so VirtualGL-2.3.1-2.fc17.i686.rpm : /usr/lib/fakelib/libGL.so These are okay. ==== Generic ==== [x]: EXTRA Rpmlint is run on all installed packages. Note: There are rpmlint messages (see attachment). [x]: EXTRA Spec file according to URL is the same as in SRPM. [X]: MUST Package is licensed with an open-source compatible license and meets other legal requirements as defined in the legal section of Packaging Guidelines. Assuming the removing of bundling is okay, this is all set. [x]: MUST Package successfully compiles and builds into binary rpms on at least one supported primary architecture. Note: Using prebuilt rpms [x]: MUST %build honors applicable compiler flags or justifies otherwise. [x]: MUST All build dependencies are listed in BuildRequires, except for any that are listed in the exceptions section of Packaging Guidelines. Note: Using prebuilt rpms. [x]: MUST Buildroot is not present Note: Unless packager wants to package for EPEL5 this is fine [x]: MUST Package contains no bundled libraries. [x]: MUST Changelog in prescribed format. I added blank lines between entries... [x]: MUST Package has no %clean section with rm -rf %{buildroot} (or $RPM_BUILD_ROOT) Note: Clean would be needed if support for EPEL is required [x]: MUST Sources contain only permissible code or content. [x]: MUST Each %files section contains %defattr if rpm < 4.4 Note: Note: defattr macros not found. They would be needed for EPEL5 [ ]: MUST Macros in Summary, %description expandable at SRPM build time. [ ]: MUST Package contains desktop file if it is a GUI application. [x]: MUST Package requires other packages for directories it uses. I fixed owning %{_libdir}/VirtualGL/ [ ]: MUST Package uses nothing in %doc for runtime. [ ]: MUST Package is not known to require ExcludeArch. [x]: MUST Permissions on files are set properly. [x]: MUST Package does not contain duplicates in %files. [x]: MUST Fully versioned dependency in subpackages, if present. [x]: MUST Package complies to the Packaging Guidelines [!]: MUST Spec file lacks Packager, Vendor, PreReq tags. Note: Found : Vendor: The VirtualGL Project [x]: MUST Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the beginning of %install. Note: rm -rf would be needed if support for EPEL5 is required [ ]: MUST Large documentation files are in a -doc subpackage, if required. [!]: MUST If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package is included in %doc. [x]: MUST License field in the package spec file matches the actual license. Note: Checking original sources for licenses Licenses found: "LGPL (v2 or later)", "LGPL (v2 or later) GENERATED FILE", "*No copyright* UNKNOWN", "UNKNOWN", "*No copyright* Public domain", "MIT/X11 (BSD like)" For detailed output of licensecheck see file: /export/home/orion/redhat/VirtualGL-2.3.1/VirtualGL/licensecheck.txt [x]: MUST License file installed when any subpackage combination is installed. [ ]: MUST Package consistently uses macros (instead of hard-coded directory names). [x]: MUST Package is named using only allowed ascii characters. [x]: MUST Package is named according to the Package Naming Guidelines. [x]: MUST Package does not generate any conflict. [x]: MUST Package obeys FHS, except libexecdir and /usr/target. [x]: MUST Package must own all directories that it creates. [x]: MUST Package does not own files or directories owned by other packages. [x]: MUST Package installs properly. Note: Using prebuilt rpms [x]: MUST Requires correct, justified where necessary. [x]: MUST Rpmlint is run on all rpms the build produces. Note: There are rpmlint messages (see attachment). [x]: MUST Sources used to build the package match the upstream source, as provided in the spec URL. [ ]: MUST Spec file is legible and written in American English. [x]: MUST Spec file name must match the spec package %{name}, in the format %{name}.spec. [ ]: MUST Package contains systemd file(s) if in need. [x]: MUST File names are valid UTF-8. [x]: MUST Useful -debuginfo package or justification otherwise. [x]: SHOULD Reviewer should test that the package builds in mock. [ ]: SHOULD If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. [x]: SHOULD Dist tag is present. [x]: SHOULD No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin. [x]: SHOULD Final provides and requires are sane (rpm -q --provides and rpm -q --requires). [x]: SHOULD Package functions as described. [x]: SHOULD Latest version is packaged. [x]: SHOULD Package does not include license text files separate from upstream. [ ]: SHOULD Patches link to upstream bugs/comments/lists or are otherwise justified. [ ]: SHOULD Scriptlets must be sane, if used. [!]: SHOULD SourceX / PatchY prefixed with %{name}. Note: Source0: http://downloads.sourceforge.net/project/virtualgl/VirtualGL/%{version}/VirtualGL-%{version}.tar.gz (VirtualGL-%{version}.tar.gz) Patch0: VirtualGL-2.3.1-redhatpathsfix.patch (VirtualGL-2.3.1-redhatpathsfix.patch) Patch1: VirtualGL-fltk.patch (VirtualGL-fltk.patch) Patch2: VirtualGL-glx.patch (VirtualGL-glx.patch) I don't like using %{name} for patches. Up to you for this. [x]: SHOULD SourceX is a working URL. [ ]: SHOULD Description and summary sections in the package spec file contains translations for supported Non-English languages, if available. [ ]: SHOULD Package should compile and build into binary rpms on all supported architectures. [ ]: SHOULD %check is present and all tests pass. [ ]: SHOULD Packages should try to preserve timestamps of original installed files. [x]: SHOULD Spec use %global instead of %define. Issues: [!]: MUST Spec file lacks Packager, Vendor, PreReq tags. Note: Found : Vendor: The VirtualGL Project This needs to get removed. [!]: MUST If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package is included in %doc. See: http://fedoraproject.org/wiki/Packaging/LicensingGuidelines#License_Text This is okay, license is installed in %docdir. [!]: MUST Development (unversioned) .so files in -devel subpackage, if present. Note: VirtualGL-2.3.1-2.fc17.i686.rpm : /usr/lib/VirtualGL/libdlfaker.so VirtualGL-2.3.1-2.fc17.i686.rpm : /usr/lib/VirtualGL/libgefaker.so VirtualGL-2.3.1-2.fc17.i686.rpm : /usr/lib/VirtualGL/librrfaker.so VirtualGL-2.3.1-2.fc17.i686.rpm : /usr/lib/fakelib/libGL.so See: http://fedoraproject.org/wiki/Packaging/Guidelines#DevelPackages False positive, these are okay. Rpmlint ------- Checking: VirtualGL-2.3.1-2.fc17.i686.rpm VirtualGL-2.3.1-3.fc17.src.rpm VirtualGL-debuginfo-2.3.1-2.fc17.i686.rpm VirtualGL.i686: W: spelling-error %description -l en_US compositing -> composting, com positing, com-positing VirtualGL.i686: W: no-manual-page-for-binary vglconfig VirtualGL.i686: W: no-manual-page-for-binary nettest VirtualGL.i686: W: no-manual-page-for-binary vglrun VirtualGL.i686: W: no-manual-page-for-binary glxspheres VirtualGL.i686: W: no-manual-page-for-binary vglclient VirtualGL.i686: W: no-manual-page-for-binary vgllogin VirtualGL.i686: W: no-manual-page-for-binary vglxinfo VirtualGL.i686: W: no-manual-page-for-binary cpustat VirtualGL.i686: W: no-manual-page-for-binary vglgenkey VirtualGL.i686: W: no-manual-page-for-binary vglserver_config VirtualGL.i686: W: no-manual-page-for-binary tcbench VirtualGL.i686: W: no-manual-page-for-binary vglconnect VirtualGL.src: W: spelling-error %description -l en_US vglrun VirtualGL.src: W: spelling-error %description -l en_US compositing -> composting, com positing, com-positing VirtualGL.src: W: spelling-error %description -l en_US vglclient -> clientele 3 packages and 0 specfiles checked; 0 errors, 16 warnings. Requires -------- VirtualGL-2.3.1-2.fc17.i686.rpm (rpmlib, GLIBC filtered): /bin/sh /sbin/ldconfig libGL.so.1 libGLU.so.1 libX11.so.6 libXext.so.6 libXv.so.1 libc.so.6 libcrypto.so.10 libdl.so.2 libm.so.6 libpthread.so.0 libssl.so.10 libstdc++.so.6 libstdc++.so.6(CXXABI_1.3) libturbojpeg.so libturbojpeg.so(TURBOJPEG_1.0) libturbojpeg.so(TURBOJPEG_1.1) rtld(GNU_HASH) VirtualGL-debuginfo-2.3.1-2.fc17.i686.rpm (rpmlib, GLIBC filtered): Provides -------- VirtualGL-2.3.1-2.fc17.i686.rpm: VirtualGL = 2.3.1-2.fc17 VirtualGL(x86-32) = 2.3.1-2.fc17 libdlfaker.so libgefaker.so librrfaker.so VirtualGL-debuginfo-2.3.1-2.fc17.i686.rpm: VirtualGL-debuginfo = 2.3.1-2.fc17 VirtualGL-debuginfo(x86-32) = 2.3.1-2.fc17 MD5-sum check ------------- /export/home/orion/redhat/VirtualGL-2.3.1/VirtualGL/upstream/VirtualGL-2.3.1.tar.gz : MD5SUM this package : 6c7dcfce0541df7f5bd8a07d4c480fb1 MD5SUM upstream package : 6c7dcfce0541df7f5bd8a07d4c480fb1 Generated by fedora-review 0.2.0git External plugins:
Greetings, Attempt #5. Thanks so much for your help Orion. http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora17/spec/5/VirtualGL.spec http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora17/SRPMS/VirtualGL-2.3.1-4.fc17.src.rpm So far this version seems to work fine with the system libraries instead of the bundled libraries. I will test further this evening with more apps.
Okay, with the final change this package is approved and I will sponsor you. One more change you could make, you can do: %if 0%{?rhel} == 6 %cmake28 \ %else %cmake \ %endif -DTJPEG_INCLUDE_DIR=%{_includedir} \ .... If you'd rather. Keeps a single set of options.
What is your FAS account name?
Nevermind, found it )gsgatlin) and sponsored you.
Greetings, Here was a final edit before submission. http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora17/spec/6/VirtualGL.spec http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora17/SRPMS/VirtualGL-2.3.1-5.fc17.src.rpm This contains the change to the cmake macro. One thing that may be a problem that I didn't think about is that the turbojpeg dependency is missing from epel. I had been using a turbojpeg-1.1.1-3 rebuilt from fedora and it seemed to work ok on rhel 6. But I can go ahead and begin submitting this for fedora. Hmnn, it seems I cannot build in koji from scratch. I get: [gsgatlin@y470 virtualgl]$ koji build --scratch f17 /home/gsgatlin/virtualgl/VirtualGL-2.3.1-5.fc17.src.rpm Uploading srpm: /home/gsgatlin/virtualgl/VirtualGL-2.3.1-5.fc17.src.rpm [====================================] 100% 00:00:06 2.62 MiB 426.90 KiB/sec Created task: 4237130 Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=4237130 Watching tasks (this may be safely interrupted)... 4237130 build (f17, VirtualGL-2.3.1-5.fc17.src.rpm): free 4237130 build (f17, VirtualGL-2.3.1-5.fc17.src.rpm): free -> open (x86-01.phx2.fedoraproject.org) 4237132 buildArch (VirtualGL-2.3.1-5.fc17.src.rpm, i686): free 4237131 buildArch (VirtualGL-2.3.1-5.fc17.src.rpm, x86_64): free 4237131 buildArch (VirtualGL-2.3.1-5.fc17.src.rpm, x86_64): free -> open (x86-05.phx2.fedoraproject.org) 4237132 buildArch (VirtualGL-2.3.1-5.fc17.src.rpm, i686): free -> open (x86-06.phx2.fedoraproject.org) 4237132 buildArch (VirtualGL-2.3.1-5.fc17.src.rpm, i686): open (x86-06.phx2.fedoraproject.org) -> closed 0 free 2 open 1 done 0 failed 4237131 buildArch (VirtualGL-2.3.1-5.fc17.src.rpm, x86_64): open (x86-05.phx2.fedoraproject.org) -> closed 0 free 1 open 2 done 0 failed 4237130 build (f17, VirtualGL-2.3.1-5.fc17.src.rpm): open (x86-01.phx2.fedoraproject.org) -> FAILED: BuildError: mismatch when analyzing VirtualGL-devel-2.3.1-5.fc17.noarch.rpm, rpmdiff output was: removed REQUIRES VirtualGL(x86-64) = 2.3.1-5.fc17 removed REQUIRES libXv-devel(x86-64) removed REQUIRES mesa-libGLU-devel(x86-64) removed REQUIRES openssl-devel(x86-64) removed REQUIRES turbojpeg-devel(x86-64) added REQUIRES VirtualGL(x86-32) = 2.3.1-5.fc17 added REQUIRES libXv-devel(x86-32) added REQUIRES mesa-libGLU-devel(x86-32) added REQUIRES openssl-devel(x86-32) added REQUIRES turbojpeg-devel(x86-32) 0 free 0 open 2 done 1 failed 4237130 build (f17, VirtualGL-2.3.1-5.fc17.src.rpm) failed Trying to figure out how to look at the build.log in the koji cli because I cannot access the koji web site even after importing the ~/fedora-browser-cert.p12 file. Seems to be some kind of problem in the "devel" rpm with 64bit vs 32 bit. But the devel rpm package is actually noarch. hmnn.
Don't make -devel noarch, that should fix this.
Greetings, http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora17/spec/7/VirtualGL.spec http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora17/SRPMS/VirtualGL-2.3.1-6.fc17.src.rpm Ok. taking out the -devel being noarch fixed things with koji scratch builds for fedora 17 and fedora 16. I did think it was kind of odd the devel was noarch but I didn't give it much thought. I think I am doing epel correctly, but it fails. It seems there were different values for epel dist-6E-epel-testing-candidate and dist-6E-epel This is from mock from the web interface to koji: Getting requirements for VirtualGL-2.3.1-6.el6.src --> cmake28-2.8.8-4.el6.i686 --> fltk-devel-1.1.10-1.el6.i686 --> openssl-devel-1.0.0-20.el6_2.5.i686 Error: No Package found for turbojpeg-devel So I guess my question is can I submit my New Package SCM Request with el6 in it even if it fails in koji ? I know it is failing becuase of the BuildRequires: turbojpeg-devel where turbojpeg-devel is in fedora but I think turbojpeg-devel and turbojpeg are missing in epel at this time. So I guess I need to request that turbojpeg be added to epel first? Sorry about this process being so new to me. I was hoping this could be made availible through epel as well as fedora? It also seems to fail with f18 but not sure why. It gets to the 53% mark and goes and craps out: [ 53%] Built target sharedtex_mt Linking CXX executable ../bin/fakerut cd /builddir/build/BUILD/VirtualGL-2.3.1/server && /usr/bin/cmake -E cmake_link_script CMakeFiles/fakerut.dir/link.txt --verbose=1 /usr/bin/c++ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -O3 -DNDEBUG -Wl,-z,relro -L/builddir/build/BUILD/VirtualGL-2.3.1/staticlib -static-libgcc CMakeFiles/fakerut.dir/fakerut.cpp.o -o ../bin/fakerut -rdynamic -z now /usr/lib64/libGL.so -lGLU -z now /usr/lib64/libX11.so -ldl -lpthread make[2]: Leaving directory `/builddir/build/BUILD/VirtualGL-2.3.1' /usr/bin/cmake -E cmake_progress_report /builddir/build/BUILD/VirtualGL-2.3.1/CMakeFiles 5 [ 53%] Built target fakerut make[1]: Leaving directory `/builddir/build/BUILD/VirtualGL-2.3.1' make: *** [all] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.RxFZsk (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.RxFZsk (%build) Child returncode was: 1 EXCEPTION: Command failed. See logs for output. # ['bash', '--login', '-c', 'rpmbuild -bb --target x86_64 --nodeps builddir/build/SPECS/VirtualGL.spec'] Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/mockbuild/trace_decorator.py", line 70, in trace result = func(*args, **kw) File "/usr/lib/python2.6/site-packages/mockbuild/util.py", line 352, in do raise mockbuild.exception.Error, ("Command failed. See logs for output.\n # %s" % (command,), child.returncode) Error: Command failed. See logs for output. # ['bash', '--login', '-c', 'rpmbuild -bb --target x86_64 --nodeps builddir/build/SPECS/VirtualGL.spec'] LEAVE do --> EXCEPTION RAISED Pretty weird. Is that a show stopper if it fails in koji scratch build for f18?
Yeah, we'll need to get turbojpeg into EPEL 6 before you can build there, but go ahead and request an el6 branch. You're not capturing the real error message for the rawhide build above. We can probably sort that out easier after you check it in and are doing real builds.
New Package SCM Request ======================= Package Name: VirtualGL Short Description: A toolkit for displaying OpenGL applications to thin clients Owners: gsgatlin Branches: f16 f17 el6 InitialCC:
Git done (by process-git-requests).
Things seem to go bad around here in rawhide with fedpkg build command. [ 17%] Building CXX object server/CMakeFiles/fakerut.dir/fakerut.cpp.o cd /builddir/build/BUILD/VirtualGL-2.3.1/server && /usr/bin/c++ -D__VERSION=\"2.3.1\" -D__BUILD=\"20120714\" -D__APPNAME=\"VirtualGL\" -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DUSESSL -DUSEXV -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -O3 -DNDEBUG -I/builddir/build/BUILD/VirtualGL-2.3.1/include -I/builddir/build/BUILD/VirtualGL-2.3.1/server -I/builddir/build/BUILD/VirtualGL-2.3.1/server/../common -static-libgcc -fPIC -o CMakeFiles/fakerut.dir/fakerut.cpp.o -c /builddir/build/BUILD/VirtualGL-2.3.1/server/fakerut.cpp /usr/bin/ld: /lib64/libglapi.so.0: undefined reference to symbol 'pthread_once@@GLIBC_2.2.5' /usr/bin/ld: note: 'pthread_once@@GLIBC_2.2.5' is defined in DSO /lib64/libpthread.so.0 so try adding it to the linker command line /lib64/libpthread.so.0: could not read symbols: Invalid operation collect2: error: ld returned 1 exit status make[2]: Leaving directory `/builddir/build/BUILD/VirtualGL-2.3.1' make[2]: *** [bin/glreadtest] Error 1 make[1]: *** [util/CMakeFiles/glreadtest.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs.... Linking CXX static library ../lib/librrglframe.a cd /builddir/build/BUILD/VirtualGL-2.3.1/client && /usr/bin/cmake -P CMakeFiles/rrglframe.dir/cmake_clean_target.cmake cd /builddir/build/BUILD/VirtualGL-2.3.1/client && /usr/bin/cmake -E cmake_link_script CMakeFiles/rrglframe.dir/link.txt --verbose=1 /usr/bin/ar cr ../lib/librrglframe.a CMakeFiles/rrglframe.dir/rrglframe.cpp.o /usr/bin/ranlib ../lib/librrglframe.a make[2]: Leaving directory `/builddir/build/BUILD/VirtualGL-2.3.1' /usr/bin/cmake -E cmake_progress_report /builddir/build/BUILD/VirtualGL-2.3.1/CMakeFiles 47 [ 17%] Built target rrglframe Linking C executable ../bin/dlfakerut cd /builddir/build/BUILD/VirtualGL-2.3.1/server && /usr/bin/cmake -E cmake_link_script CMakeFiles/dlfakerut.dir/link.txt --verbose=1 /usr/bin/gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -O3 -DNDEBUG -Wl,-z,relro -L/builddir/build/BUILD/VirtualGL-2.3.1/staticlib -static-libgcc CMakeFiles/dlfakerut.dir/dlfakerut.c.o -o ../bin/dlfakerut -rdynamic -lX11 -ldl make[2]: Leaving directory `/builddir/build/BUILD/VirtualGL-2.3.1' /usr/bin/cmake -E cmake_progress_report /builddir/build/BUILD/VirtualGL-2.3.1/CMakeFiles 4 [ 17%] Built target dlfakerut /builddir/build/BUILD/VirtualGL-2.3.1/server/fakerut.cpp: In function 'int mttest(int)': /builddir/build/BUILD/VirtualGL-2.3.1/server/fakerut.cpp:1550:6: warning: variable 'dpyw' set but not used [-Wunused-but-set-variable] /builddir/build/BUILD/VirtualGL-2.3.1/server/fakerut.cpp:1550:12: warning: variable 'dpyh' set but not used [-Wunused-but-set-variable] Linking CXX executable ../bin/fakerut cd /builddir/build/BUILD/VirtualGL-2.3.1/server && /usr/bin/cmake -E cmake_link_script CMakeFiles/fakerut.dir/link.txt --verbose=1 /usr/bin/c++ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -O3 -DNDEBUG -Wl,-z,relro -L/builddir/build/BUILD/VirtualGL-2.3.1/staticlib -static-libgcc CMakeFiles/fakerut.dir/fakerut.cpp.o -o ../bin/fakerut -rdynamic -z now /usr/lib64/libGL.so -lGLU -z now /usr/lib64/libX11.so -ldl -lpthread make[2]: Leaving directory `/builddir/build/BUILD/VirtualGL-2.3.1' /usr/bin/cmake -E cmake_progress_report /builddir/build/BUILD/VirtualGL-2.3.1/CMakeFiles 5 [ 17%] Built target fakerut make[1]: Leaving directory `/builddir/build/BUILD/VirtualGL-2.3.1' make: *** [all] Error 2 RPM build errors: error: Bad exit status from /var/tmp/rpm-tmp.6TPOwr (%build) Bad exit status from /var/tmp/rpm-tmp.6TPOwr (%build) Child return code was: 1 EXCEPTION: Command failed. See logs for output. # ['bash', '--login', '-c', 'rpmbuild -bb --target x86_64 --nodeps builddir/build/SPECS/VirtualGL.spec'] Traceback (most recent call last): File "/usr/lib/python2.6/site-packages/mockbuild/trace_decorator.py", line 70, in trace result = func(*args, **kw) File "/usr/lib/python2.6/site-packages/mockbuild/util.py", line 352, in do raise mockbuild.exception.Error, ("Command failed. See logs for output.\n # %s" % (command,), child.returncode) Error: Command failed. See logs for output. # ['bash', '--login', '-c', 'rpmbuild -bb --target x86_64 --nodeps builddir/build/SPECS/VirtualGL.spec'] LEAVE do --> EXCEPTION RAISED This bit right here is what I think is a issue: /usr/bin/ld: /lib64/libglapi.so.0: undefined reference to symbol 'pthread_once@@GLIBC_2.2.5' /usr/bin/ld: note: 'pthread_once@@GLIBC_2.2.5' is defined in DSO /lib64/libpthread.so.0 so try adding it to the linker command line /lib64/libpthread.so.0: could not read symbols: Invalid operation collect2: error: ld returned 1 exit status Perhaps it will help if I make a rawhide kvm vm to test this in? I will work on that today. So far, I only have development vms for 32 bit and 64 bit rhel 6, fedora 16, and fedora 17. Not really sure how to fix adding "it" to the linker command line. Any ideas appriciated. I will look into it further once I can get rawhide kvm vms installed and fully updated if I can duplicate locally.
Tried adding BuildRequires: mxml-devel based on some googling: http://comments.gmane.org/gmane.linux.mageia.devel/16913 Did not help. Had no success building a rawhide vm today. (there are too many broken dependencies trying to yum update from fedora 17 to rawhide) I will try to create a rawhide vm on Monday using some other new method if possible if there is time. Sorry this isn't turing out to be too easy to figure out.
I filed bug 839060 against mesa for this issue.
Looks like this has been built. Have you added it to comps? After that we can close this I think.
Hello. I'm sorry. I did not push out an update via Bodhi. I hesitated to do that before due to the upstream developer wanting me to do some things I cannot do. http://sourceforge.net/mailarchive/forum.php?thread_name=504C1D48.8080104%40users.sourceforge.net&forum_name=virtualgl-devel But upstream also wanted some changes for multilib support that maybe I can do... However, since he mentions that his rpms will overwrite ours, I am cool with pushing out an update via Bodhi if you think its ok to do that? Sorry I didn't do anything about this until now. But I had to have surgery on my rear and back and I couldn't sit down until recently which is why I've been pretty out of it. But I've started back working now and can work on a computer again. Do you know what group VirtualGL should go in in comps? Thanks a lot.
Sorry you had to have surgery, hope you recover quickly. Anyway, while it is somewhat disappointing that upstream has taken a bit of an adversarial position to use packaging it, it meets our guidelines and should be shipped. As for comps, I'm not sure, there doesn't seem to be a great fit. Perhaps just system-tools (which is where the vnc client is).
VirtualGL-2.3.1-8.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/VirtualGL-2.3.1-8.fc18
VirtualGL-2.3.1-8.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/VirtualGL-2.3.1-8.fc17
VirtualGL-2.3.1-8.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/VirtualGL-2.3.1-8.fc16
VirtualGL-2.3.1-8.fc18 has been pushed to the Fedora 18 testing repository.
VirtualGL-redhatpathsfix.patch is breaking multiarch. In the standard VirtualGL rpm, the LD_PRELOAD for librrfaker.so and friends searches automatically in LD_LIBRARY_PATH which contains both 32-bit and 64-bit libraries. In this RPM, the patch predetermines which libraries to load depending on uname and the result is that the patch is breaking 32-bit programs running on 64-bit systems. 32-bit Wine, for example, is completely broken for me using this RPM as I am running on a 64-bit OS. I recommend that librrfaker.so and others be placed back in /usr/lib and /usr/lib64, and that VirtualGL-redhatpathsfix.patch be removed.
I have a proposed fix for this problem that requires re-doing the patch. Here is the fixed up script: http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora18/spec/vglrun/vglrun Unfortunately, it causes some error messages if you have both 32 and 64 bit packages installed. Running 64 bit openGL app: [gsgatlin@y470b ~]$ optirun glxgears ERROR: ld.so: object '/usr/lib/VirtualGL/libdlfaker.so' from LD_PRELOAD cannot be preloaded: ignored. ERROR: ld.so: object '/usr/lib/VirtualGL/librrfaker.so' from LD_PRELOAD cannot be preloaded: ignored. Running 32 bit app: optirun ./Shatter.bin.x86 ERROR: ld.so: object '/usr/lib64/VirtualGL/libdlfaker.so' from LD_PRELOAD cannot be preloaded: ignored. ERROR: ld.so: object '/usr/lib64/VirtualGL/librrfaker.so' from LD_PRELOAD cannot be preloaded: ignored. Notice how whichever one isn't being used is being warned about... Orion, Do you think these error messages would be a problem? Or could we ignore them and consider this a fix for this bug? Evidently wine is a 32 bit app which is why this is coming up.
Created attachment 632299 [details] Updated .spec - fixes vglrun for 32-bit binaries on 64-bit OS
Moving the lib*faker libraries back will cause rpmlint to give errors. I believe having those in libdir is going against fedora packaging guidelines. https://fedoraproject.org/wiki/Common_Rpmlint_issues#invalid-soname So we weren't just doing that for fun. ;)
Thanks for your hard work Gary.. I've been using your Bumblebee RPMs for the last few months and they are great. Took a looked at your patched script. Have you thought about using adding /usr/lib/VirtualGL and /usr/lib64/VirtualGL in the LD_LIBRARY_PATH immediately before the LD_PRELOAD? Then you don't need to specify the full path of each libXXfaker.so and no preload errors would appear.
Thank you. I tried this one: http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora18/spec/vglrun/2/vglrun-new But I get errors and it doesn't seem to ever open a window... optirun ./Shatter.bin.x86 : ======================= LOG INITIALISED ======================= : Name : Shatter ( SH ) : Build: 12091801 ( pc ) : MabCore v1.0 Initialised. ( $Id: MabCoreLib.h 108864 2011-12-01 01:07:59Z rgreen $ ) Error: signal: 11 ./Shatter.bin.x86(_Z13crash_handleri+0x2b)[0x8392e3b] [0x6f0400] [gsgatlin@nom0060038 ~]$ optirun glxgears Error: couldn't get an RGB, Double-buffered visual But perhaps I did not understand what you were suggesting correctly and so my script is wrong. Please let me know if there is anything I could change to get it working. If we do end up having to go with the first script I think the messages are mostly harmless...
Created attachment 632470 [details] Updated vglrun script
I think there was a typo in the LD_LIBRARY_PATH lines in that one. A simplified one that works for me is attached. I did a little testing and no error messages as far as I can see in 32 or 64-bit binaries.
Yup. That works! Thanks so much Andy. That makes it super easy. http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora18/spec/1/VirtualGL.spec http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora18/SRPMS/VirtualGL-2.3.1-9.fc18.src.rpm I'll be pushing these out asap. The new patch is called VirtualGL-redhatpathsmultilibfix.patch
Created attachment 632679 [details] Updated vglrun script - fixed lib64 test This is an updated version of the script that does the lib and lib64 detection separately and should be more correct.
Sorry Gary, I made a mistake in the script and added /usr/lib64/VirtualGL into the library path even when the 64-bit directory is not detected. It still works but the code isn't right. I've just uploaded an new version of the script that does the lib and lib64 detection separately and should be more correct, which you can include in your next version of the package. Many thanks.
Current fedora rpms did not work very for 32 bit apps. The rpms from the site above (comment 46) work fine (though the bumblebee rpm there could use some better configuration (location of nvidia libs, xorg modules and a screen section in xorg.conf files). Hope we can see an update of virtualgl for fedora 18.
Sorry. Will try to push 2.3.2 to testing either late tonight or tomorrow.
VirtualGL-2.3.2-2.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/VirtualGL-2.3.2-2.fc16
VirtualGL-2.3.2-2.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/VirtualGL-2.3.2-2.fc17
VirtualGL-2.3.2-2.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/VirtualGL-2.3.2-2.fc18
This problem remains for me in 2.3.2-2. Tested with wine and games from HIBs (32 and 64bits). ERROR: ld.so: object 'libdlfaker.so' from LD_PRELOAD cannot be preloaded: ignored. ERROR: ld.so: object 'librrfaker.so' from LD_PRELOAD cannot be preloaded: ignored.
If I edit the file, /etc/yum.repos.d/fedora-updates-testing.repo and change all the lines enabled=0 to enabled=1 and do a yum install VirtualGL on a freshly installed fedora 18 box I get No package VirtualGL available. Error: Nothing to do I can test the version I personally built but I am not sure how to test the one in the build system that you are possibly looking at Andrej. Anyone have any ideas what I am doing wrong? Thanks a lot.
Gary, I think it's still not pushed in testing because status is still "pending" [1]. "PENDING - Your update has not yet been pushed to the testing or stable repositories." [2] But never the less, it's not working for me for 32-bit apps. [1] https://admin.fedoraproject.org/updates/VirtualGL [2] http://fedoraproject.org/wiki/Bodhi#Pending
I am unable to duplicate this bug on fedora 18 with the package I built myself in my private yum repository. I am able to run: optirun ./glxgears32-f18 Where glxgears32-f18 is a glxgears executable which has been scp'ed from a fedora 18 kvm i686 virtual machine running inside of my centOS 6 box. I have been using this very rpm on my CentOS 6 box for a couple of days and I can play 32 and 64 bit games. (The main 32 bit game I play is "shatter" from the humble indie bundles which seems to lock up my intel card for some reason so I run it through optirun to get around that problem) [gsgatlin@y470 ~]$ file ./glxgears32-f18 ./glxgears32-f18: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0xeb1d904956a38a266aa710c2103615efc9bc2daa, stripped On fedora 18, this only works for me when using kernel 3.6.10-4.fc18.x86_64. When using the latest kernel, I cannot load certain third party out of tree kernel modules that are required for me to test bumblebee/VirtualGL. I understand these third party kernel modules are bad/evil/wrong and I cannot expect to get help from the fedora community in trying to troubleshoot that particular issue... So I am on my own. :( So I'm not sure what to do next. I will work on figuring out how to push these from "pending" to "testing," but I gather perhaps from item #3 on this page" https://fedoraproject.org/wiki/Package_update_HOWTO?rd=PackageMaintainers/UpdatingPackageHowTo#Submit_your_update_to_Bodhi That I must wait for a Release Engineer to approve that... I don't see anything obvious on how to change that in the web interface. I'll keep looking tonight when I have more time. If people want to see what I am trying to do with hybrid graphics on fedora / red hat you can look at the somewhat epic thread at: https://github.com/Bumblebee-Project/Bumblebee/issues/153 I have not had much luck with fedora 18 so far with the latest kernel and I am not sure what to do. Maybe I should take them down in a week or so if I can't get this to work like it worked with older fedoras... I'm going to keep working on this all weekend so I haven't given up yet. I have copied a vglrun script from VirtualGL-2.3.2-2.el6.x86_64 to a place on the web. http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/test/vglrun Is this one different than the one you installed? How did you download this VirtualGL-2.3.2-2 rpm? What version of fedora are you using? (If fedora 17/16 I can re-install my spare laptop with that distro so we are on the same page) Thanks,
One other thing I though of while in the shower... If you downloaded these from my private testing repo, make sure you did: yum install VirtualGL.i686 to get the 32 bit package. If you are experimenting with primus, you also need to install the 32 bit version for 32 bit apps: yum install primus.i686 If you got VirtualGL from the build system, just make sure you install the 32 bit rpm package also. Let me know what you find out.
I downloaded VirtualGL from Koji (your package which is on "pending"). I'm using Fedora 18 with lateset kernel: 3.7.2-201.fc18.x86_64, and Optimus hardware is HD4000 and GeForce 620M: 01:00.0 3D controller: NVIDIA Corporation Device 1140 (rev ff) 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) Bumblebee is working (i can use both graphics cards), but problem is with 32-bit apps. I did try with 32-bit glxgears taken from here [1] but still can't get it working on NVIDIA: $ optirun ./glxgears-x86 ERROR: ld.so: object 'libdlfaker.so' from LD_PRELOAD cannot be preloaded: ignored. ERROR: ld.so: object 'librrfaker.so' from LD_PRELOAD cannot be preloaded: ignored. Diff between yours and mine vglrun is zero. Installing both VirtualGL arch doesn't make sanse because files will overlap so I don't understand how can you install/run both... I don't use primus for now... [1] http://mirror.aarnet.edu.au/pub/fedora/linux/releases/18/Everything/i386/os/Packages/g/glx-utils-7.10-8.20101028.fc18.i686.rpm
I'm sorry. You have to have the 32 bit package also installed. That is Where the /usr/lib/VirtualGL/ files live. So VirtualGL.x86_64 has: /usr/lib64/VirtualGL/* and VirtualGL.i686 has: /usr/lib/VirtualGL/* Hope that helps. Cheers,
Sorry, so the command would be: rm -ivh /path/to/VirtualGL-2.3.2-2.fcXX.i686.rpm /path/to/VirtualGL-2.3.2-2.fcXX.x86_64.rpm Where fcxx is your version of fedora.
Sorry, one more comment. If you use the rpm command, I think VirtualGL depends on a jpeg package. turbojpeg. So you will need to install it and all its 32 bit dependencies. Do a yum install turbojpeg.i686 first I think. Let me know if that works for you?
I can confirm it's working now when I used yours RPMs for bbswitch, bumblebee and bumblebee-nvidia. I can run on NVIDIA both, 32bits and 64bits.
I have verified that the VirtualGL.x86_64 and VirtualGL.i686 work correctly from koji and fedora-updates-testing on fedora 18. The nature of my test, glxgears from a 32 bit vm, required installing libGLEW.i686 and mesa-dri-drivers.i686 on a 64 bit OS. I installed VirtualGL (64 bit) and VirtualGL.i686 via yum so it handled all the dependencies for itself.
VirtualGL-2.3.2-2.fc17 has been pushed to the Fedora 17 stable repository.
VirtualGL-2.3.2-2.fc18 has been pushed to the Fedora 18 stable repository.
VirtualGL-2.3.2-2.fc16 has been pushed to the Fedora 16 stable repository.
Package Change Request ====================== Package Name: VirtualGL New Branches: el6 Owners: gsgatlin Would like this software to be availible in EPEL el6.
Branch for EL-6 already exists.