Bug 1788327 - Review Request: gl4es - OpenGL to GL ES translation library [NEEDINFO]
Summary: Review Request: gl4es - OpenGL to GL ES translation library
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1800429
TreeView+ depends on / blocked
 
Reported: 2020-01-06 23:05 UTC by Raphael Groner
Modified: 2020-11-30 16:36 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: ---
projects.rg: needinfo? (zebob.m)


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Github ptitSeb gl4es issues 125 None open libglvnd support 2020-12-27 21:07:39 UTC

Description Raphael Groner 2020-01-06 23:05:56 UTC
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.'

Comment 1 Raphael Groner 2020-01-06 23:05:59 UTC
This package built on koji:  https://koji.fedoraproject.org/koji/taskinfo?taskID=40206084

Comment 2 Robert-André Mauchin 🐧 2020-01-08 03:49:38 UTC
 - 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.

Comment 3 Raphael Groner 2020-01-13 08:37:32 UTC
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

Comment 4 Raphael Groner 2020-07-23 10:02:42 UTC
tbc.

Comment 5 Raphael Groner 2020-07-23 10:21:12 UTC
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.

Comment 6 Nicolas Chauvet (kwizart) 2020-07-26 18:37:57 UTC
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...

Comment 7 Robert-André Mauchin 🐧 2020-07-26 20:20:26 UTC
(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.

Comment 8 Raphael Groner 2020-07-28 06:47:49 UTC
(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.

Comment 9 Raphael Groner 2020-07-28 06:50:13 UTC
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.

Comment 10 Nicolas Chauvet (kwizart) 2020-07-28 07:22:10 UTC
(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 ?

Comment 11 Nicolas Chauvet (kwizart) 2020-07-28 07:31:27 UTC
(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.

Comment 12 Raphael Groner 2020-07-28 11:31:12 UTC
Commented in the upstream issue, thanks. Let's wait and see what they answer.

Comment 13 Raphael Groner 2020-07-28 11:33:13 UTC
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 ?

Comment 14 Nicolas Chauvet (kwizart) 2020-11-25 18:44:18 UTC
(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.

Comment 15 Raphael Groner 2020-11-25 20:02:15 UTC
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.

Comment 16 Raphael Groner 2020-11-30 16:36:54 UTC
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/


Note You need to log in before you can comment on or make changes to this bug.