Spec URL: https://raphgro.fedorapeople.org/review/misc/gl4es.spec SRPM URL: https://raphgro.fedorapeople.org/review/misc/gl4es-1.1.2-1.20200106git2f61f71.fc30.src.rpm Description: b'This is a library provide OpenGL 2.x functionality for GLES2.0 accelerated\nHardware (and of course also support OpenGL 1.5 function, sometimes better then\nwhen using GLES 1.1 backend) There is also support for GLES 1.1 Hardware,\nemulating OpenGL 1.5, and some OpenGL 2.x+ extensions.'
This package built on koji: https://koji.fedoraproject.org/koji/taskinfo?taskID=40206084
- Don't repeat the name of the package in the Summary: Summary: OpenGL 2.1/1.5 to GL ES 2.0/1.1 translation library - Requires: %{name} = %{version} → Requires: %{name}%{?_isa} = %{version}-%{release} - Remove executable bits in %prep and send a patch upstream: gl4es.x86_64: W: spurious-executable-perm /usr/share/doc/gl4es/CHANGELOG.md gl4es.x86_64: W: spurious-executable-perm /usr/share/doc/gl4es/MEDIA.md gl4es.x86_64: W: spurious-executable-perm /usr/share/doc/gl4es/README.md gl4es.x86_64: W: spurious-executable-perm /usr/share/doc/gl4es/USAGE.md - Own this directory: [!]: Package requires other packages for directories it uses. Note: No known owner of /usr/lib64/gl4es - Remove rpath: gl4es.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/gl4es/libGL.so.1 ['/builddir/build/BUILD/gl4es-2f61f71b0e75ee3e67da01d2eb1d949d1db8f5d3/build/lib', '/opt/vc/lib'] %cmake .. \ -DBCMHOST=1 -DNOEGL=1 -DNOX11=1 -DDEFAULT_ES=2 -DUSE_CLOCK=ON -DCMAKE_SKIP_BUILD_RPATH=TRUE Package Review ============== Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated [ ] = Manual review needed ===== MUST items ===== C/C++: [x]: Package does not contain kernel modules. [x]: Package contains no static executables. [!]: Rpath absent or only used for internal libs. Note: See rpmlint output [x]: If your application is a C or C++ application you must list a BuildRequires against gcc, gcc-c++ or clang. [x]: Header files in -devel subpackage, if present. [x]: Package does not contain any libtool archives (.la) [x]: Development (unversioned) .so files in -devel subpackage, if present. Generic: [x]: Package is licensed with an open-source compatible license and meets other legal requirements as defined in the legal section of Packaging Guidelines. [x]: License field in the package spec file matches the actual license. Note: Checking patched sources after %prep for licenses. Licenses found: "Unknown or generated", "Expat License", "Khronos License", "SGI Free Software License B (v2.0)", "GNU Lesser General Public License (v2 or later)", "*No copyright* SGI Free Software License B". 207 files have unknown license. Detailed output of licensecheck in /home/bob/packaging/review/gl4es/review-gl4es/licensecheck.txt [x]: License file installed when any subpackage combination is installed. [!]: Package requires other packages for directories it uses. Note: No known owner of /usr/lib64/gl4es [x]: %build honors applicable compiler flags or justifies otherwise. [x]: Package contains no bundled libraries without FPC exception. [x]: Changelog in prescribed format. [x]: Sources contain only permissible code or content. [-]: Package contains desktop file if it is a GUI application. [x]: Development files must be in a -devel package [x]: Package uses nothing in %doc for runtime. [x]: Package consistently uses macros (instead of hard-coded directory names). [x]: Package is named according to the Package Naming Guidelines. [x]: Package does not generate any conflict. [x]: Package obeys FHS, except libexecdir and /usr/target. [-]: If the package is a rename of another package, proper Obsoletes and Provides are present. [x]: Requires correct, justified where necessary. [x]: Spec file is legible and written in American English. [-]: Package contains systemd file(s) if in need. [x]: Useful -debuginfo package or justification otherwise. [x]: Package is not known to require an ExcludeArch tag. [-]: Large documentation must go in a -doc subpackage. Large could be size (~1MB) or number of files. Note: Documentation size is 40960 bytes in 4 files. [x]: Package complies to the Packaging Guidelines [x]: Package successfully compiles and builds into binary rpms on at least one supported primary architecture. [x]: Package installs properly. [x]: Rpmlint is run on all rpms the build produces. Note: There are rpmlint messages (see attachment). [x]: 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 %license. [x]: Package does not own files or directories owned by other packages. [x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT [x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the beginning of %install. [x]: Macros in Summary, %description expandable at SRPM build time. [x]: Dist tag is present. [x]: Package does not contain duplicates in %files. [x]: Permissions on files are set properly. [x]: Package use %makeinstall only when make install DESTDIR=... doesn't work. [x]: Package is named using only allowed ASCII characters. [x]: Package does not use a name that already exists. [x]: Package is not relocatable. [x]: Sources used to build the package match the upstream source, as provided in the spec URL. [x]: Spec file name must match the spec package %{name}, in the format %{name}.spec. [x]: File names are valid UTF-8. [x]: Packages must not store files under /srv, /opt or /usr/local ===== SHOULD items ===== Generic: [-]: 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]: Final provides and requires are sane (see attachments). [!]: Fully versioned dependency in subpackages if applicable. Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in gl4es- devel [?]: Package functions as described. [x]: Latest version is packaged. [x]: Package does not include license text files separate from upstream. [-]: Sources are verified with gpgverify first in %prep if upstream publishes signatures. Note: gpgverify is not used. [-]: Description and summary sections in the package spec file contains translations for supported Non-English languages, if available. [x]: Package should compile and build into binary rpms on all supported architectures. [-]: %check is present and all tests pass. [x]: Packages should try to preserve timestamps of original installed files. [x]: Reviewer should test that the package builds in mock. [x]: Buildroot is not present [x]: Package has no %clean section with rm -rf %{buildroot} (or $RPM_BUILD_ROOT) [x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin. [x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file [x]: Sources can be downloaded from URI in Source: tag [x]: SourceX is a working URL. [x]: Spec use %global instead of %define unless justified. ===== EXTRA items ===== Generic: [x]: Rpmlint is run on debuginfo package(s). Note: No rpmlint messages. [x]: Rpmlint is run on all installed packages. Note: There are rpmlint messages (see attachment). [x]: Large data in /usr/share should live in a noarch subpackage if package is arched. [x]: Spec file according to URL is the same as in SRPM. Rpmlint ------- Checking: gl4es-1.1.2-1.20200106git2f61f71.fc32.x86_64.rpm gl4es-devel-1.1.2-1.20200106git2f61f71.fc32.x86_64.rpm gl4es-debuginfo-1.1.2-1.20200106git2f61f71.fc32.x86_64.rpm gl4es-debugsource-1.1.2-1.20200106git2f61f71.fc32.x86_64.rpm gl4es-1.1.2-1.20200106git2f61f71.fc32.src.rpm gl4es.x86_64: W: name-repeated-in-summary C GL4ES gl4es.x86_64: E: binary-or-shlib-defines-rpath /usr/lib64/gl4es/libGL.so.1 ['/builddir/build/BUILD/gl4es-2f61f71b0e75ee3e67da01d2eb1d949d1db8f5d3/build/lib', '/opt/vc/lib'] gl4es.x86_64: W: spurious-executable-perm /usr/share/doc/gl4es/CHANGELOG.md gl4es.x86_64: W: spurious-executable-perm /usr/share/doc/gl4es/MEDIA.md gl4es.x86_64: W: spurious-executable-perm /usr/share/doc/gl4es/README.md gl4es.x86_64: W: spurious-executable-perm /usr/share/doc/gl4es/USAGE.md gl4es-devel.x86_64: W: only-non-binary-in-usr-lib gl4es-devel.x86_64: W: no-documentation gl4es.src: W: name-repeated-in-summary C GL4ES 5 packages and 0 specfiles checked; 1 errors, 8 warnings.
Thanks for the hints. I'll continue asap due to limited time. This request is mainly a preparation to give to the emulator box86 a chance and to get into Fedora with packaging: "Most x86 Games need OpenGL, so on ARM platforms, a solution like gl4es is probably needed." https://ameridroid.com/blogs/ameriblogs/how-to-run-x86-linux-applications-on-arm-linux-with-box86
tbc.
Spec URL: https://raphgro.fedorapeople.org/review/misc/gl4es.spec SRPM URL: https://raphgro.fedorapeople.org/review/misc/gl4es-1.1.2-2.20200106git2f61f71.fc31.src.rpm There's already the 1.1.4 release but it does not produce any binary for me.
There is an issue if you have a package that will provides libGL.so.1. Of course that will not be able to override mesa-libGL if already installed (or the libglvnd related package), but it will break compose or even install the wrong libGL.so.1 on i686. The usual way of doing is to exclude the libGL.so.1 from RPM dependency computation. (have a look at libglvnd conditional). Best would be to port this application to libglvnd so it don't have to override libGL.so.1 For information, which use case is behind this package ? I guess you will rely on a proprietary GLES implementation that lacks libGL.so (like some arm devices)? I wonder if this package shouldn't be best in a copr repository...
(In reply to Raphael Groner from comment #5) > Spec URL: https://raphgro.fedorapeople.org/review/misc/gl4es.spec > SRPM URL: > https://raphgro.fedorapeople.org/review/misc/gl4es-1.1.2-2. > 20200106git2f61f71.fc31.src.rpm > > There's already the 1.1.4 release but it does not produce any binary for me. Address the comment of Kwizart and I'll finish the review. %global __provides_exclude_from %{_libdir}/%{name} %global __requires_exclude_from %{_libdir}/%{name} Needinfo me cause I'm deep into Golang packaging and I'm not checking any other stuff right now.
(In reply to Nicolas Chauvet (kwizart) from comment #6) > There is an issue if you have a package that will provides libGL.so.1. True. Maybe rename this file and let clients explicitly link to the other library name? … > Best would be to port this application to libglvnd so it don't have to > override libGL.so.1 Can you please guide me how to do? > For information, which use case is behind this package ? I guess you will > rely on a proprietary GLES implementation that lacks libGL.so (like some arm > devices)? Please read the full context, a possible use case is box86, see comment #3 and depending bug for another review request (but still as placeholder, will continue that there when this here is approved). > I wonder if this package shouldn't be best in a copr repository... Why? NO doubt, copr is a general useful tool but I'd like to see a package in official repository.
What do you think about renaming the library binary (libGL)? There's actually one known use case with box86 and it could explicitly depend on the new library name.
(In reply to Raphael Groner from comment #3) > Thanks for the hints. I'll continue asap due to limited time. > > This request is mainly a preparation to give to the emulator box86 a chance > and to get into Fedora with packaging: > "Most x86 Games need OpenGL, so on ARM platforms, a solution like gl4es is > probably needed." > https://ameridroid.com/blogs/ameriblogs/how-to-run-x86-linux-applications-on- > arm-linux-with-box86 As Fedora is concerned, arm (and aarch64) FLOSS drivers are using mesa and plain libGL already. The only use case where this would be useful would be the PI downstream driver (not provided by Fedora) or Mali drivers (not provided by Fedora), and few others. So if you want box86 on arm with plain libGL and the related mesa drivers (vc4/v3d for PI and lima for Mali), nothing hold. If you are interested in downstream drivers for PI, then I'm trying to "federate" various userspace in a dedicated rpi namespace in rpmfusion. The reason why it has to be dedicated is because a ffmpeg built with bcmhost enabled (PI downstream driver) would make the whole build PI specific. So my guess is that gl4es, once built with -DBCMHOST=1 would be also specific and not useful at all on Lima cases and others. So that's the reason why I expect this build to be on copr. As I don't expect a generic build to be anything useful. At least can you submit a box86 review, so we can any if anything hold ?
(In reply to Raphael Groner from comment #8) > (In reply to Nicolas Chauvet (kwizart) from comment #6) > > There is an issue if you have a package that will provides libGL.so.1. ... > > Best would be to port this application to libglvnd so it don't have to > > override libGL.so.1 > > Can you please guide me how to do? There is an upstream report about this. https://github.com/ptitSeb/gl4es/issues/125 That been said I'm not sure how this can be done if the proprietary GLES libraries has no support for libglvnd in the first step.
Commented in the upstream issue, thanks. Let's wait and see what they answer.
Propably better for bug #1800429: (In reply to Nicolas Chauvet (kwizart) from comment #10) > (In reply to Raphael Groner from comment #3) > > Thanks for the hints. I'll continue asap due to limited time. > > > > This request is mainly a preparation to give to the emulator box86 a chance > > and to get into Fedora with packaging: > > "Most x86 Games need OpenGL, so on ARM platforms, a solution like gl4es is > > probably needed." > > https://ameridroid.com/blogs/ameriblogs/how-to-run-x86-linux-applications-on- > > arm-linux-with-box86 > > As Fedora is concerned, arm (and aarch64) FLOSS drivers are using mesa and > plain libGL already. > > The only use case where this would be useful would be the PI downstream > driver (not provided by Fedora) or Mali drivers (not provided by Fedora), > and few others. > So if you want box86 on arm with plain libGL and the related mesa drivers > (vc4/v3d for PI and lima for Mali), nothing hold. > > If you are interested in downstream drivers for PI, then I'm trying to > "federate" various userspace in a dedicated rpi namespace in rpmfusion. > The reason why it has to be dedicated is because a ffmpeg built with bcmhost > enabled (PI downstream driver) would make the whole build PI specific. So my > guess is that gl4es, once built with -DBCMHOST=1 would be also specific and > not useful at all on Lima cases and others. > > So that's the reason why I expect this build to be on copr. As I don't > expect a generic build to be anything useful. > At least can you submit a box86 review, so we can any if anything hold ?
(In reply to Raphael Groner from comment #3) > Thanks for the hints. I'll continue asap due to limited time. > > This request is mainly a preparation to give to the emulator box86 a chance > and to get into Fedora with packaging: > "Most x86 Games need OpenGL, so on ARM platforms, a solution like gl4es is > probably needed." > https://ameridroid.com/blogs/ameriblogs/how-to-run-x86-linux-applications-on- > arm-linux-with-box86 I don't see a direct needs for gl4s on dox86, I've submitted a review from https://bugzilla.redhat.com/show_bug.cgi?id=1901665 Tested on arm with Toshiba AC100 using mesa libGL.
Thanks. Should I close bug #1800429 as a duplicate of bug #1901665 then? There's already some interest for review mentioned in the original request.
Vulkan 1.0 is integrated into Mesa upstream, also planned for Raspian and requires OpenGL ES 3.1: https://www.raspberrypi.org/blog/vulkan-update-now-with-added-source-code/
Another alternative option seems found to package box86 (improved review in bug #1901665) as initially thought dependency. Therefore I fail to see any reason to continue this package request. Please feel free to open a new request if you think this is still useful.