VirtualGL failed to build from source in Fedora rawhide/f33 https://koji.fedoraproject.org/koji/taskinfo?taskID=47926074 For details on the mass rebuild see: https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild Please fix VirtualGL at your earliest convenience and set the bug's status to ASSIGNED when you start fixing it. If the bug remains in NEW state for 8 weeks, VirtualGL will be orphaned. Before branching of Fedora 34, VirtualGL will be retired, if it still fails to build. For more details on the FTBFS policy, please visit: https://fedoraproject.org/wiki/Fails_to_build_from_source
This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle. Changing version to 33.
Propably duplication of bug #1799136 (F32 FTBFS).
I'd like to try to fix this if I can. I made a rpm for version 2.6.3. I could upload it but it won't build in mock on rawhide. Let me copy the output and the spec file so you could look at it. If you can help me troubleshoot what I'm doing wrong that would be so helpful. It works in fedora 32 I think but not fedora 33 or rawhide. Let me get that ready.
Yes, I'm interested. Maybe you can add me as co-maintainer? Broken builds are generally no issue at all in rawhide and quite common though. So we'd not worry that much.
*** Bug 1799136 has been marked as a duplicate of this bug. ***
Needs fix in rawhide/F34, F33, F32 (in case not EOL'ed before).
Yes. Co maintainer would be awesome. Thank you for your kind offer. https://people.engr.ncsu.edu/gsgatlin/VirtualGL.spec https://people.engr.ncsu.edu/gsgatlin/error.txt The problem is that it started saying as an error: make: *** No targets specified and no makefile found. Stop.
Also, I tried adding BuildRequires: make but I still get the same error.
> make: *** No targets specified and no makefile found. Stop. That means cmake fails to create any Makefile. Please share the full output of cmake for better debug purpose, see below for a snippet. > BuildRequires: make Yes please explicitly add this line as it's generally requested on devel mailing list. DEBUG: Executing command: ['btrfs', 'subv', 'list', '/var/lib/mock'] with env {'TERM': 'vt100', 'SHELL': '/bin/sh', 'HOME': '/builddir', 'HOSTNAME': 'mock', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'LANG': 'C.UTF-8'} and shell False DEBUG: ERROR: not a btrfs filesystem: /var/lib/mock DEBUG: ERROR: can't access '/var/lib/mock' ... maybe is there a general issue with your builder machine? Please try to build within official koji or copr to have a proper base system.
Ok. Let me try to build that in koji. Sorry about that.
Ok. I am on a fedora 32 system. It builds ok with fedpkg local but gives me the same problem with fedpkg mockbuild make: *** No targets specified and no makefile found. Stop. Trying a scratch build. https://koji.fedoraproject.org/koji/taskinfo?taskID=59908518 Thanks for any ideas you might have.
From build.log: -- Could NOT find FLTK (missing: FLTK_FLUID_EXECUTABLE) Obviously missing BuildRequires: fltk-fluid You may have successfully installed the fltk-fluid subpackage locally but that's not explicitly referenced in spec file for mock and koji.
I did not have fltk-fluid installed locally but I am trying again with it installed to make srpm. https://koji.fedoraproject.org/koji/taskinfo?taskID=59909121 Thanks a lot.
%cmake macro got changed for out-of-source builds. You may need to migrate: https://fedoraproject.org/wiki/Changes/CMake_to_do_out-of-source_builds#Migration
Thanks a lot. Trying another build now. https://koji.fedoraproject.org/koji/taskinfo?taskID=59914388
Ok. I started installing a box here I can use to test this version of the software. I should know more within 1-2 hours. Its installing the packages now. I'll upload this if it tests out ok.
Sorry. Had to make some slight changes for epel. Now it builds in mock on fedora 32,33,34 and el7,el8. Re-trying. Like there is no fltk-fluid rpm in epel 8 but it still builds ok. So I made a conditional. Also still had to use make for el7. But my test machine has fedora on it. I will test rhel 7 and 8 after I verify fedora works. https://koji.fedoraproject.org/koji/taskinfo?taskID=59920304
Ok, cool. I'm happy to can help. Do you know if VirtualGL package works in combination with xpra? Or for what applications do you use it?
I don't use it very much any longer but mainly I was using it with hybrid graphics. When I did use it I used it with java minecraft a lot. I have a faculty member that wanted to use it with Agisoft Metashape. I am unsure if it could work with Xpra. I am almost finished with testing the package. I will push the new version up after I finish the test on el8 server and sleep. It has worked as expected so far with glxgears on el7 and fedora. Thank you so much for getting me past this build problem.
> Agisoft Metashape Looks interesting, thanks for the hint. I'm working for a faculty, too.
FEDORA-2021-73b44548b5 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-73b44548b5
FEDORA-2021-73b44548b5 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-73b44548b5` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-73b44548b5 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
There's a pull request for new version 2.6.5 and to drop the mesa patch: https://src.fedoraproject.org/rpms/VirtualGL/pull-request/2
Hi. I'm hoping to work on this later tonight or tomorrow. I had to get some other stuff finished yesterday. I feel an obligation to test any changes with a VirtualGL server and a VirtualGL client with the changes to 2.6.5. Which I need to do with real PCs and not vms. I will set up my lab again this afternoon. But Have to re-install the PC which currently has another OS on it.
No worries, please take your time. Thanks for caring.
FEDORA-2021-73b44548b5 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.