Bug 1997278 - Review Request: eclipse-swt - The Standard Widget Toolkit for GTK+
Summary: Review Request: eclipse-swt - The Standard Widget Toolkit for GTK+
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Mat Booth
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1981982 1996432 1996449
TreeView+ depends on / blocked
 
Reported: 2021-08-24 19:33 UTC by Nicolas De Amicis
Modified: 2021-09-28 18:50 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-09-28 18:50:27 UTC
Type: ---
Embargoed:
mat.booth: fedora-review+


Attachments (Terms of Use)

Description Nicolas De Amicis 2021-08-24 19:33:30 UTC
Spec URL: https://deamn.fedorapeople.org/eclipse-swt.spec
SRPM URL: https://deamn.fedorapeople.org/eclipse-swt-4.20-1.fc36.src.rpm
Description: SWT is an open source widget toolkit for Java designed to provide efficient, portable access to the user-interface facilities of the operating systems on which it is implemented.
Fedora Account System Username: deamn

Comment 1 Mat Booth 2021-08-27 08:51:57 UTC
I can take this one

Comment 2 Mat Booth 2021-08-27 13:53:57 UTC
What is the reason to bump the epoch?

Comment 3 Nicolas De Amicis 2021-08-27 14:01:37 UTC
I thought it was needed to update the package to newer version, but after your comment it's right that is not necessary. I will update the spec file

Comment 4 Nicolas De Amicis 2021-08-27 19:55:29 UTC
I updated the spec file, you could continue to review the package.

Comment 5 Nicolas De Amicis 2021-09-01 10:43:37 UTC
Are you waiting on something of my part? I updated last week the spec file.
Thanks for the review

Comment 6 Mat Booth 2021-09-03 14:41:52 UTC
Issues:
=======
- This section seems extremely wrong and will break SWT for s390x:

  %global eclipse_arch %{_arch}
  %ifarch s390x
   %global eclipse_arch x86_64
  %endif

  In the old eclipse package file, we took great care to correctly generate
  a s390x fragment for SWT, see this section lines 536-543:
  https://src.fedoraproject.org/rpms/eclipse/blob/f34/f/eclipse.spec#_536
  
  The script referenced there "utils/ensure_arch.sh" is available here:
  https://git.eclipse.org/c/linuxtools/org.eclipse.linuxtools.eclipse-build.git/tree/utils/ensure_arch.sh

  Obviously you only need to run it for the SWT fragment, not the equinox fragments.

  You will also need the SWT p2.inf part of this patch from the old eclipse package:
  https://src.fedoraproject.org/rpms/eclipse/blob/f34/f/eclipse-secondary-arches.patch#_69
  
  With out this patch, SWT deps cannot be correctly resolved by OSGi on s390x.

- Build does not honour Fedora standard compiler flags, but it looks like
  the old Eclipse package did not do so either. You can try setting CFLAGS
  appropriately, it looks like "make_linux.mak" may just pick it up.

- No debuginfo package -- the old eclipse package used to generate a
  debuginfo package, any idea what's happening here?

- Possibly related to debuginfo, the package no longer has the same
  generated requires/provides, compare with the old package here:
  https://koji.fedoraproject.org/koji/rpminfo?fileStart=600&rpmID=25833939&fileOrder=name&buildrootOrder=-id&buildrootStart=0

- No javadoc sub-package. Intentional? When SWT was shipped as part of
  Eclipse Platform, the javadoc was available in the Eclipse help system.
  Note: Shipping Javadocs is optional these days, so not a blocker.
  See: https://fedoraproject.org/wiki/Packaging:Java#Javadoc_installation

- No %license file in %files? You can use the NOTICE and LICENSE files
  from the root of the source tarball.

- Spec file your SRPM still contains epoch 2, please fix

- Please fix rpmlint issues "mixed-use-of-spaces-and-tabs" and
  "description-line-too-long"

- Please add comments/explaination for patch 1:
  "eclipse-swt-rm-eclipse-tasks-and-customize-build.patch"

- If you are using pure ant build, you don't need a BR on maven-local,
  just having a BR on javapackages-local is fine.

- No pom.xml installed, but I don't think the old eclipse package installed
  a pom for SWT either since it was part of the platform. I won't block
  the review on that -- SWT has no other Java deps, IIRC so it should be fine


Full package review tool output follows below.



Package Review
==============

Legend:
[x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated


===== MUST items =====

C/C++:
[-]: Package does not contain kernel modules.
[x]: Package contains no static executables.
[x]: If your application is a C or C++ application you must list a
     BuildRequires against gcc, gcc-c++ or clang.
[x]: Package does not contain any libtool archives (.la)
[x]: Rpath absent or only used for internal libs.

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.
[!]: 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]: License field in the package spec file matches the actual license.
[!]: %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.
[-]: 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.
[!]: Requires correct, justified where necessary.
[x]: Spec file is legible and written in American English.
[-]: Package contains systemd file(s) if in need.
[!]: Useful -debuginfo package or justification otherwise.
[-]: Package is not known to require an ExcludeArch tag.
[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]: Package requires other packages for directories it uses.
[x]: Package must own all directories that it creates.
[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 must not depend on deprecated() packages.
[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]: Large documentation must go in a -doc subpackage. Large could be size
     (~1MB) or number of files.
     Note: Documentation size is 0 bytes in 0 files.
[x]: Packages must not store files under /srv, /opt or /usr/local

Java:
[x]: Bundled jar/class files should be removed before build
[x]: Packages have proper BuildRequires/Requires on javapackages-tools
     (jpackage-utils)
     Note: Maven packages do not need to (Build)Require jpackage-utils. It
     is pulled in by maven-local

Maven:
[!]: If package contains pom.xml files install it (including metadata) even
     when building with ant
[x]: Maven packages should use new style packaging
[x]: Old add_to_maven_depmap macro is not being used

===== 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.
[!]: Final provides and requires are sane (see attachments).
[?]: Package functions as described.
[x]: Latest version is packaged.
[x]: Package does not include license text files separate from upstream.
[!]: Patches link to upstream bugs/comments/lists or are otherwise
     justified.
[-]: Sources are verified with gpgverify first in %prep if upstream
     publishes signatures.
     Note: gpgverify is not used.
[x]: Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[-]: %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]: Package should compile and build into binary rpms on all supported
     architectures.
[x]: Spec use %global instead of %define unless justified.

Java:
[x]: Packages are noarch unless they use JNI
     Note: eclipse-swt subpackage is not noarch. Please verify manually
[x]: Package uses upstream build method (ant/maven/etc.)

===== EXTRA items =====

Generic:
[!]: Spec file according to URL is the same as in SRPM.
     Note: Spec file as given by url is not the same as in SRPM (see
     attached diff).
     See: (this test has no URL)
[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.


Rpmlint
-------
eclipse-swt.x86_64: W: only-non-binary-in-usr-lib
eclipse-swt.x86_64: W: no-documentation
eclipse-swt.x86_64: E: no-binary
eclipse-swt.spec:4: W: mixed-use-of-spaces-and-tabs (spaces: line 1, tab: line 4)
eclipse-swt.src: E: description-line-too-long SWT is an open source widget toolkit for Java designed to provide efficient, portable access to the user-interface facilities of the operating systems on which it is implemented.
eclipse-swt.x86_64: E: description-line-too-long SWT is an open source widget toolkit for Java designed to provide efficient, portable access to the user-interface facilities of the operating systems on which it is implemented.


Source checksums
----------------
https://download.eclipse.org/eclipse/downloads/drops4/R-4.20-202106111600/eclipse-platform-sources-4.20.tar.xz :
  CHECKSUM(SHA256) this package     : 5c4b913828662c3d96270a3c282e074b93579be1f54981eb2f20eec184096698
  CHECKSUM(SHA256) upstream package : 5c4b913828662c3d96270a3c282e074b93579be1f54981eb2f20eec184096698


Requires
--------
eclipse-swt (rpmlib, GLIBC filtered):
    (java-headless or java-11-headless)
    gtk3
    java-11-openjdk
    javapackages-filesystem
    webkitgtk4



Provides
--------
eclipse-swt:
    eclipse-swt
    eclipse-swt(x86-64)
    mvn(org.eclipse.swt:org.eclipse.swt)
    mvn(org.eclipse.swt:swt)
    osgi(org.eclipse.swt)



Diff spec file in url and in SRPM
---------------------------------
--- /home/mbooth/fedora/1997278-eclipse-swt/srpm/eclipse-swt.spec	2021-09-03 13:30:41.930467674 +0100
+++ /home/mbooth/fedora/1997278-eclipse-swt/srpm-unpacked/eclipse-swt.spec	2021-08-24 12:35:39.000000000 +0100
@@ -1,3 +1,3 @@
-Epoch:                  1
+Epoch:                  2
 
 %global swtdir          eclipse-platform-sources-I20210611-1600
@@ -37,5 +37,5 @@
 BuildRequires:  mesa-libGLU-devel
 
-Provides:       eclipse-swt = 1:%{version}-%{release}
+Provides:       eclipse-swt = 2:%{version}-%{release}
 Obsoletes:      eclipse-swt <= 1:4.19-3

Comment 7 Nicolas De Amicis 2021-09-09 13:58:37 UTC
I updated the spec and rpms files to correct issues reported. I hope that I understand all your comments. I have these comments:
- I updated the s390x part like recommended expect for the p2 (osgi). I thought that I wouldn't include osgi. What do you think?
- I don't understand how I can build a debuginfo package. Which instructions I need to add...?

Comment 8 Mat Booth 2021-09-09 14:16:14 UTC
(In reply to Nicolas De Amicis from comment #7)
> I updated the spec and rpms files to correct issues reported. I hope that I
> understand all your comments. I have these comments:
> - I updated the s390x part like recommended expect for the p2 (osgi). I
> thought that I wouldn't include osgi. What do you think?

As long as nothing in Fedora that requires SWT breaks, I guess it's fine.

> - I don't understand how I can build a debuginfo package. Which instructions
> I need to add...?

It happens automatically. It looks like you are not shipping any of the *.so objects, (or they are shipped only inside the jar).

Comment 9 Nicolas De Amicis 2021-09-09 18:53:21 UTC
You are right, the *.so were inside the jar, I think no debuginfo package is required?

Thanks for your package reviews.

Comment 10 Mat Booth 2021-09-10 08:48:27 UTC
(In reply to Nicolas De Amicis from comment #9)
> You are right, the *.so were inside the jar, I think no debuginfo package is
> required?
> 
> Thanks for your package reviews.


From https://docs.fedoraproject.org/en-US/packaging-guidelines/Java/#JNI

"JNI shared objects MUST be placed in %{_libdir}/%{name}"

If you do this, then debuginfo and generated requires should Just Work™

Comment 11 Mat Booth 2021-09-10 09:03:24 UTC
BTW, 4.21RC2a will almost certainly be the 4.21 release, consider updating to that version: https://download.eclipse.org/eclipse/downloads/drops4/S-4.21RC2a-202109060500/

Comment 12 Nicolas De Amicis 2021-09-16 09:23:30 UTC
I switched to 4.21RC2a, it's ok.
For debuginfo, correct me if I'm wrong but the last package eclipse-swt for f34 doesn't provide debuginfo package? 
I'm trying without success to generate this. I have patched the script that run the makefile to include Fedora CFLAGS and LDFLAGS. The spec file copy the .so (that are included into the swt.jar) into %{_libdir}/%{name} like recommended:
install -d 755 %{buildroot}/%{_libdir}/%{name}
cp -a %{swtsrcdir}/*.so %{buildroot}/%{_libdir}/%{name}

But I have this error (it's correct because I don't package these files because they are included into the jar file) but I have no .debug, debugfiles.list, debuglinks.list,... files or debuginfo package build.

I propose that I update the spec and rpms with 4.21RC2a and you continue the review without debuginfo package? (but with javadoc package ;-) ), what do you think?

Comment 13 Mat Booth 2021-09-19 09:18:12 UTC
(In reply to Nicolas De Amicis from comment #12)
> I switched to 4.21RC2a, it's ok.
> For debuginfo, correct me if I'm wrong but the last package eclipse-swt for
> f34 doesn't provide debuginfo package? 6

The old eclipse package *did* provide debuginfo: https://koji.fedoraproject.org/koji/rpminfo?rpmID=25939944

Comment 14 Nicolas De Amicis 2021-09-22 19:17:00 UTC
I updated the spec file like asked. Please found here the new SRPM:
Spec URL: https://deamn.fedorapeople.org/eclipse-swt.spec
SRPM URL: https://deamn.fedorapeople.org/eclipse-swt-4.21-1.fc36.src.rpm

All points are corrected (javadoc, debuginfo, s390x, Fedora standard compiler flags, ...)

Thanks for the review.

Comment 15 Mat Booth 2021-09-24 17:49:37 UTC
Nice work so far :-)

I just see some more things I think should be fixed:



Line 3:

%global eclipse_tag     S-%{eclipse_rel}-202109060500

Should be:

%global eclipse_tag     R-%{eclipse_rel}-202109060500

(This shuts up rpmlint invalid Source0 URL errors)



Line 30:

You don't need explicit "R gtk3" since a requires should be auto-generated on libgtk-3.so.0



Line 31:

Don't "R webkitgtk4" -- this package is obsoleted by webkit2gtk3, so use "R webkit2gtk3" instead.



Line 40:

You don't need "BR gtk2-devel" if you're building gtk3 bindings only.



Line 48:

You still have this section:

%ifarch s390x
 %global eclipse_arch x86_64
%endif

Don't change the arch to something that is incorrect, the correct arch for s390x is "s390x" so you can remove this.





Did you know you can use "%javadoc_package" and "%mvn_install" macros to auto-generate the javadoc subpackage? You can remove a bunch of stuff from this spec file:

Replace lines 57-61 (the whole subpackage definition) with one line macro:

%javadoc_package

Then on line 133, tell "%mvn_install" where the javadoc is using -J flag, e.g.:

%mvn_install -J %{swtsrcdir}/docs/api/

Then you can delete lines 138 and 139 (creating dir and copying javadoc into place) and you can delete lines 148-151 (the whole "%files javadoc" section)

Comment 16 Nicolas De Amicis 2021-09-24 20:29:16 UTC
Hello Mat, thanks for your review. I applied your modifications.

Nice weekend

Comment 17 Mat Booth 2021-09-25 09:13:10 UTC
Did you try scratch building? It still fails on s390x:

https://kojipkgs.fedoraproject.org//work/tasks/1360/76261360/build.log

Looks like you are doing something in the wrong order:


Line 83 copying stuff from inside the bundle before you even create it. The bundle is created on line 91. The secondary fragment generation needs to be done first before you start copying stuff out of it.

Comment 18 Nicolas De Amicis 2021-09-26 19:40:00 UTC
I never build succeeded for the arch s390x. I always a JVM dump when I try to build it with mockbuild (and qemu-user-static package).

# Problematic frame:
# J 61 c1 java.lang.StringLatin1.indexOf([BII)I java.base.12 (61 bytes) @ 0x0000004019c7be40 [0x0000004019c7be40+0x0000000000000000]

I saw that you use koji to test my package, I could use koji too for s390x arch?

Nevertheless I updated the spec and srpm files like recommended.

Your reviews is appreciate and I perfect learning of package creation. Thanks

Comment 19 Mat Booth 2021-09-27 08:40:28 UTC
(In reply to Nicolas De Amicis from comment #18)
> I saw that you use koji to test my package, I could use koji too for s390x
> arch?
> 

Yes of course. You can do it like this:

$ koji build --scratch <buildroot_tag> <srpm_path>

For example:

$ koji build --scratch f35 /home/mbooth/fedora/eclipse-swt-4.21-1.fc35.src.rpm


--


Thanks for making the necessary changes.

I think now this package can be APPROVED. Please go ahead and request a repo.

Comment 20 Gwyn Ciesla 2021-09-27 20:16:05 UTC
(fedscm-admin):  The Pagure repository was created at https://src.fedoraproject.org/rpms/eclipse-swt


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