Spec URL: coming soon SRPM URL: coming soon Description: OpenJDK Runtime Environment in implementation of java 9 specification Fedora Account System Username: jvanek
The srpm/spec are now missing, as they are work in progress. This bug was added to: https://fedoraproject.org/wiki/Changes/Java9TechPreview The jdk9 packages will be based on https://copr.fedorainfracloud.org/coprs/omajid/openjdk9/package/java-9-openjdk/ Although the copr state is failed, the packages are in better state then they look - the scratch builds passes outside copr ( == in koji) for f25 and up
https://pagure.io/copy_jdk_configs/c/ac945b7e2c6ea321c47f4d7568159a72fc9f1a77?branch=master needed for multiple installs
Spec URL: https://jvanek.fedorapeople.org/openjdk9Review/V3/java-9-openjdk.spec SRPM URL: https://jvanek.fedorapeople.org/openjdk9Review/V3/java-9-openjdk-9.0.0.163-2.fc24.src.rpm Description: OpenJDK Runtime Environment in implementation of java 9 specification Fedora Account System Username: jvanek For record: * https://jvanek.fedorapeople.org/openjdk9Review/V1 is original Omair's work * https://jvanek.fedorapeople.org/openjdk9Review/V2 is broken base merge with openjdk * finally V3 is a bit sane (Still work in progress, will publish scratch builds) * #c2 patch for copy-jdk-configs is needed to properly process config files in case of multiple installs (not yet tested * unlike java-1.8.0-openjdk bundled NSS is used * unlike java-1.8.0-openjdk various export dirs (useless in jdk8) were removed * jre symlink is based only for backwardcomaptibility, as jre and sdk is now dereferenced only by splitting few binaries * shenandoah hotspot is not yet used, butI hope to integrate it before review ends * the src tarballs generating scripts are also missing, as they require already pushed package (will bedoen after the review) * policy tool is still cripled - man page and slave in headless, binary and desktop icon in head-full (default one) * priority of packages is 1, and debug subpackages 0 * system tap and desktop integration was not (yet) tested at all
ok. That built for me: 21M 29 java-9-openjdk-javadoc-9.0.0.163-2.fc24.noarch.rpm 21M 29 java-9-openjdk-javadoc-debug-9.0.0.163-2.fc24.noarch.rpm 49M 29 java-9-openjdk-javadoc-zip-9.0.0.163-2.fc24.noarch.rpm 49M 30 java-9-openjdk-javadoc-zip-debug-9.0.0.163-2.fc24.noarch.rpm 219K 24 java-9-openjdk-9.0.0.163-2.fc24.x86_64.rpm 6.8K 30 java-9-openjdk-accessibility-9.0.0.163-2.fc24.x86_64.rpm 6.5K 30 java-9-openjdk-accessibility-debug-9.0.0.163-2.fc24.x86_64.rpm 217K 24 java-9-openjdk-debug-9.0.0.163-2.fc24.x86_64.rpm 130M 31 java-9-openjdk-debuginfo-9.0.0.163-2.fc24.x86_64.rpm 1.3M 28 java-9-openjdk-demo-9.0.0.163-2.fc24.x86_64.rpm 1.3M 28 java-9-openjdk-demo-debug-9.0.0.163-2.fc24.x86_64.rpm 3.4M 25 java-9-openjdk-devel-9.0.0.163-2.fc24.x86_64.rpm 3.4M 25 java-9-openjdk-devel-debug-9.0.0.163-2.fc24.x86_64.rpm 39M 25 java-9-openjdk-headless-9.0.0.163-2.fc24.x86_64.rpm 40M 25 java-9-openjdk-headless-debug-9.0.0.163-2.fc24.x86_64.rpm 224M 27 java-9-openjdk-jmods-9.0.0.163-2.fc24.x86_64.rpm 173M 28 java-9-openjdk-jmods-debug-9.0.0.163-2.fc24.x86_64.rpm 53M 28 java-9-openjdk-src-9.0.0.163-2.fc24.x86_64.rpm 53M 28 java-9-openjdk-src-debug-9.0.0.163-2.fc24.x86_64.rpm f25 https://koji.fedoraproject.org/koji/taskinfo?taskID=19079859 f26 https://koji.fedoraproject.org/koji/taskinfo?taskID=19079872 f24 https://koji.fedoraproject.org/koji/taskinfo?taskID=19079856 f27 https://koji.fedoraproject.org/koji/taskinfo?taskID=19079857
I have forget to add s390x to jit arches. WIll be fixed in next iteration.
Tracking bug: https://bugzilla.redhat.com/show_bug.cgi?id=1447237
New scratch build for F26 x86_64 as old built artifacts expired: https://koji.fedoraproject.org/koji/taskinfo?taskID=19617138
First round of review: Package Review ============== Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated [ ] = Manual review needed Issues: ======= - No %config files under /usr. Note: %config(noreplace) /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64/lib/security/default.policy%config(noreplace) /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64/lib/security/blacklisted.certs%config(noreplace) /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64/conf/security/policy/limited/exempt_local.policy%config(noreplace) /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64/conf/security/policy/limited/default_local.policy%config(noreplace) /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64/conf/security/policy/limited/default_US_export.policy%config(noreplace) /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64/conf/security/policy/unlimited/default_local.policy%config(noreplace) /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64/conf/security/policy/unlimited/default_US_export.policy%config(noreplace) /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64/conf/security/java.policy%config(noreplace) /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64/conf/security/java.security%config(noreplace) /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64/conf/logging.properties%config(noreplace) /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64/conf/security/nss.cfg%config(noreplace) /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64/conf/management/jmxremote.access%config /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64/conf/management/jmxremote.password.template%config(noreplace) /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64/conf/management/management.properties%config(noreplace) /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64/conf/net.properties%config(noreplace) /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64/conf/sound.properties%config /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64/lib/accessibility.properties See: http://fedoraproject.org/wiki/Packaging/Guidelines#Configuration_files Perhaps symlink config files from /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64/conf to /etc/java-9-openjdk/java-9-openjdk-9.0.0.163-2.fc26.x86_64/ accessibility.properties seems to come from the spec. Would accessibility still work if placed in conf/accessibility.properties? - Some directories are not owned by the package, but should be: /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64/conf/management, /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64/lib/security, /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64/conf, /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64/conf/security - /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64/lib/accessibility.properties Should probably move to conf directory since the new layout has an explicit directory for configuration files. Not sure if there will be changes needed in the accessibility bridge (java-atk-wrapper). - Shenandoah GC not yet supported. You mentioned that it'll be included once review completes. Consider this a TODO list item :) $ java -XX:+UseShenandoahGC -version Unrecognized VM option 'UseShenandoahGC' Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. $ java -version openjdk version "9-ea" OpenJDK Runtime Environment (build 9-ea+163) OpenJDK 64-Bit Server VM (build 9-ea+163, mixed mode) - Latest available snapshot should be packaged. Latest EA build is: jdk-9+170. See: http://jdk.java.net/9/ ===== MUST items ===== C/C++: [x]: Package does not contain kernel modules. [?]: Package contains no static executables. [x]: Rpath absent or only used for internal libs. Note: See rpmlint output I see many rpmlint errors related to $ORIGIN and rpath. All of them seem to be internal libs. java-1.8.0-openjdk shows similar issues. [x]: Development (unversioned) .so files in -devel subpackage, if present. Note: Unversioned so-files in private %_libdir subdirectory (see attachment). Verify they are not in ld path. All so files are internal OpenJDK libraries and are not in the ld path as far as I can tell. [x]: Header files in -devel subpackage, if present. [x]: Package does not contain any libtool archives (.la) Generic: [x]: Package successfully compiles and builds into binary rpms on at least one supported primary architecture. Packager provided scratch build links which showed packages building. Reviewer submitted scratch build for SRPM on x86_64 which built fine. [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. It's a combination of various licenses. NOTE: LGPL+ is unknown to rpmlint??! [?]: License file installed when any subpackage combination is installed. [?]: If the package is under multiple licenses, the licensing breakdown must be documented in the spec. [!]: Package requires other packages for directories it uses. Note: No known owner of /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64/conf/management, /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64/lib/security, /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64/conf, /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64/conf/security [!]: Package must own all directories that it creates. Note: Directories without known owners: /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64/conf, /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64/lib/security, /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64/conf/management, /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64/conf/security, [x]: %build honors applicable compiler flags or justifies otherwise. [x]: All build dependencies are listed in BuildRequires, except for any that are listed in the exceptions section of Packaging Guidelines. [x]: Package contains no bundled libraries without FPC exception. Jar files in sources [x]: Changelog in prescribed format. [x]: Sources contain only permissible code or content. [!]: %config files are marked noreplace or the reason is justified. Note: No (noreplace) in %config /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64/conf/management/jmxremote.password.template This is a passwords template file. %config /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64/lib/accessibility.properties Should this be %config(noreplace) in addition to being moved to conf? --^ [x]: Each %files section contains %defattr if rpm < 4.4 Note: %defattr present but not needed. Same spec is used on older rpm versions. OK. [x]: Development files must be in a -devel package Note: In addition to -devel subpackage there is a jmods-devel package for creating custom images. [?]: 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. [?]: gtk-update-icon-cache is invoked in %postun and %posttrans if package contains icons. Note: icons in java-9-openjdk [x]: Useful -debuginfo package or justification otherwise. [x]: Package is not known to require an ExcludeArch tag. [x]: Package complies to the Packaging Guidelines [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]: Package contains desktop file if it is a GUI application. [x]: Package installs a %{name}.desktop using desktop-file-install or desktop-file-validate if there is such a file. [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]: Large documentation must go in a -doc subpackage. Large could be size (~1MB) or number of files. There are variants of -javadoc subpackages. [x]: Packages must not store files under /srv, /opt or /usr/local ===== SHOULD items ===== Generic: [x]: Reviewer should test that the package builds in mock. [-]: 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). [x]: Fully versioned dependency in subpackages if applicable. [x]: Package functions as described. [!]: Latest version is packaged. Latest EA build is: jdk-9+170. See: http://jdk.java.net/9/ [?]: Package does not include license text files separate from upstream. [x]: Patches link to upstream bugs/comments/lists or are otherwise justified. [?]: Scriptlets must be sane, if used. [x]: SourceX tarball generation or download is documented. Script + documentation will follow after dist-git gets created. [?]: 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. [?]: Packages should try to preserve timestamps of original installed files. [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]: Uses parallel make %{?_smp_mflags} macro. [x]: SourceX is a working URL. [x]: Spec use %global instead of %define unless justified. ===== EXTRA items ===== Generic: [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]: Package should not use obsolete m4 macros [x]: Spec file according to URL is the same as in SRPM.
Correction: [x]: Package contains no bundled libraries without FPC exception. Jar files in sources are a) development aids not being shipped b) test artifacts for testing the JDK
Created attachment 1281077 [details] Full review document including rpmlint output (which I've trimmed for noise)
(In reply to jiri vanek from comment #3) > * unlike java-1.8.0-openjdk bundled NSS is used Can we actually do this? I don't think so. Otherwise why would we remove that code from source in the generate-source-tarball script for JDK 8? Actually comparing ./jdk/src/jdk.crypto.ec/share/native/libsunec/impl from JDK 9 and ./jdk/src/share/native/sun/security/ec/impl from JDK 8 yields no difference for me.
(In reply to Severin Gehwolf from comment #11) > (In reply to jiri vanek from comment #3) > > * unlike java-1.8.0-openjdk bundled NSS is used > > Can we actually do this? I don't think so. Otherwise why would we remove > that code from source in the generate-source-tarball script for JDK 8? > Actually comparing ./jdk/src/jdk.crypto.ec/share/native/libsunec/impl from > JDK 9 and ./jdk/src/share/native/sun/security/ec/impl from JDK 8 yields no > difference for me. Tahts surprising. I did not do work on that. That means that all patches form 8 are upstreamed, and it is default choice in OJDK.... (see the make call)
- No %config files under /usr. Note: %config(noreplace) /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64/lib/security/default.policy%config(noreplace) ... /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64/lib/accessibility.properties See: http://fedoraproject.org/wiki/Packaging/Guidelines#Configuration_files Perhaps symlink config files from /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64/conf to /etc/java-9-openjdk/java-9-openjdk-9.0.0.163-2.fc26.x86_64/ Well.. why? i dont see a reason for this change. java config files are quite specific, and always lied in java_home. Every config file we ever moved outised was casuing some not expected behavior (cacerts, etc/java). To symlink, seems like just bending over knee to make guideliens happy. If you isnists, I will do as you advice. But I really think it is unnecessary work which will help nothing.
> - Shenandoah GC not yet supported. You mentioned that it'll be included once review completes. > Consider this a TODO list item :) > $ java -XX:+UseShenandoahGC -version > Unrecognized VM option 'UseShenandoahGC' > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > $ java -version > openjdk version "9-ea" > OpenJDK Runtime Environment (build 9-ea+163) > OpenJDK 64-Bit Server VM (build 9-ea+163, mixed mode) Yup, I hope to do so. Please dont insists on it. Stability of shenandoah in jdk9 is currently discussed issue. > - Latest available snapshot should be packaged. > Latest EA build is: jdk-9+170. See: http://jdk.java.net/9/ Yes, in next iteration I will update. Tahnx!
> accessibility.properties seems to come from the spec. Would accessibility still work if placed in conf/accessibility.properties? > - /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64 lib/accessibility.properties > Should probably move to conf directory since the new layout has an explicit directory for configuration files. Not sure if there will be changes needed in the accessibility bridge (java-atk-wrapper). I dont know. Accessibility is painful. I doubt it even works with 9. But probably worhty of moving. Will fix. > Some directories are not owned by the package, but should be: > /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64/conf/management, > /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64/lib/security, > /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64/conf, > /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64/conf/security Hmm.. Will be fixed.
(In reply to jiri vanek from comment #13) > - No %config files under /usr. > Note: %config(noreplace) > > /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64/lib/security/default. > policy%config(noreplace) > ... > > /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64/lib/accessibility. > properties > See: > http://fedoraproject.org/wiki/Packaging/Guidelines#Configuration_files > Perhaps symlink config files from > /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64/conf to > /etc/java-9-openjdk/java-9-openjdk-9.0.0.163-2.fc26.x86_64/ > > Well.. why? i dont see a reason for this change. java config files are > quite specific, and always lied in java_home. > > Every config file we ever moved outised was casuing some not expected > behavior (cacerts, etc/java). > > To symlink, seems like just bending over knee to make guideliens happy. > > If you isnists, I will do as you advice. But I really think it is > unnecessary work which will help nothing. There are several valid reasons for keeping config files in /etc: - /usr may be read-only, but users should be allowed to edit config files - /usr may be shared between many machines, may use different Java config - if config is in /etc then you need to back up only this directory, /usr is supposed to be restorable from package contents From FHS: "/usr is shareable, read-only data. That means that /usr should be shareable between various FHS-compliant hosts and must not be written to. Any information that is host-specific or varies with time is stored elsewhere". So yes, config files definitely don't belong in /usr
(In reply to jiri vanek from comment #12) > (In reply to Severin Gehwolf from comment #11) > > (In reply to jiri vanek from comment #3) > > > * unlike java-1.8.0-openjdk bundled NSS is used > > > > Can we actually do this? I don't think so. Otherwise why would we remove > > that code from source in the generate-source-tarball script for JDK 8? > > Actually comparing ./jdk/src/jdk.crypto.ec/share/native/libsunec/impl from > > JDK 9 and ./jdk/src/share/native/sun/security/ec/impl from JDK 8 yields no > > difference for me. > > Tahts surprising. I did not do work on that. That means that all patches > form 8 are upstreamed, and it is default choice in OJDK.... (see the make > call) I don't understand what you are saying. Can you clarify what "That" in "That means ..." is? Originally you've said that bundled NSS is being used. That's for EC support, right? However, I believe we cannot use a source tarball with the internal NSS fork of openjdk included, can we? Wouldn't we need to go down a similar path as with openjdk 8. Remove internal NSS fork from sources, use system NSS. Or, alternatively, don't support EC.
(In reply to Severin Gehwolf from comment #17) > (In reply to jiri vanek from comment #12) > > (In reply to Severin Gehwolf from comment #11) > > > (In reply to jiri vanek from comment #3) > > > > * unlike java-1.8.0-openjdk bundled NSS is used > > > > > > Can we actually do this? I don't think so. Otherwise why would we remove > > > that code from source in the generate-source-tarball script for JDK 8? > > > Actually comparing ./jdk/src/jdk.crypto.ec/share/native/libsunec/impl from > > > JDK 9 and ./jdk/src/share/native/sun/security/ec/impl from JDK 8 yields no > > > difference for me. > > > > Tahts surprising. I did not do work on that. That means that all patches > > form 8 are upstreamed, and it is default choice in OJDK.... (see the make > > call) > > I don't understand what you are saying. Can you clarify what "That" in "That > means ..." is? Should be "system nss": USage of system nss is surprising. I did not do work on that. System nss used by ddefault means that all patches form 8 are upstreamed, and it is default choice in OJDK.... (see the call to make ) Better? Sorry. > > Originally you've said that bundled NSS is being used. That's for EC > support, right? However, I believe we cannot use a source tarball with the > internal NSS fork of openjdk included, can we? Wouldn't we need to go down a > similar path as with openjdk 8. Remove internal NSS fork from sources, use > system NSS. Or, alternatively, don't support EC. Sure, removal of the sources iss deffinitley thing to do.
(In reply to Mikolaj Izdebski from comment #16) > (In reply to jiri vanek from comment #13) > > - No %config files under /usr. > > Note: %config(noreplace) > > > > /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64/lib/security/default. > > policy%config(noreplace) > > ... > > > > /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64/lib/accessibility. > > properties > > See: > > http://fedoraproject.org/wiki/Packaging/Guidelines#Configuration_files > > Perhaps symlink config files from > > /usr/lib/jvm/java-9-openjdk-9.0.0.163-2.fc26.x86_64/conf to > > /etc/java-9-openjdk/java-9-openjdk-9.0.0.163-2.fc26.x86_64/ > > > > Well.. why? i dont see a reason for this change. java config files are > > quite specific, and always lied in java_home. > > > > Every config file we ever moved outised was casuing some not expected > > behavior (cacerts, etc/java). > > > > To symlink, seems like just bending over knee to make guideliens happy. > > > > If you isnists, I will do as you advice. But I really think it is > > unnecessary work which will help nothing. > > There are several valid reasons for keeping config files in /etc: > - /usr may be read-only, but users should be allowed to edit config files > - /usr may be shared between many machines, may use different Java config > - if config is in /etc then you need to back up only this directory, /usr > is supposed to be restorable from package contents Any config file is, isnt? Even if it is in etc... > > From FHS: "/usr is shareable, read-only data. That means that /usr should be > shareable between various FHS-compliant hosts and must not be written to. > Any information that is host-specific or varies with time is stored > elsewhere". So yes, config files definitely don't belong in /usr Thanx for wring this down. I see two issues - all javas up to now had configs in java_home, which in /usr/lib/jvm/theJdk - so if your concerns are applicable, then they have to be revisited - config files were decided to be in jdk, as they are supposed to be jdk x cluster specific. So this is fundametnal chage to java in fedora/rhel. Still it may be good idea to allow per machine setup. If we agreed on this, are you ok with simply symlinks?
(In reply to jiri vanek from comment #19) > (In reply to Mikolaj Izdebski from comment #16) > > - if config is in /etc then you need to back up only this directory, /usr > > is supposed to be restorable from package contents > > Any config file is, isnt? Even if it is in etc... If you modify config file, then how are you going to restore your (modified) config from package contents? > I see two issues > - all javas up to now had configs in java_home, which in /usr/lib/jvm/theJdk > - so if your concerns are applicable, then they have to be revisited Have to? Theoretically older Javas could use existing (non-FHS compliant) location, but Java 9 could use the new location. > - config files were decided to be in jdk, as they are supposed to be jdk x > cluster specific. So this is fundametnal chage to java in fedora/rhel. I don't see any fundamental change here. You would just move config files from /usr to /etc and leave symlinks where config files used to be. No functional changes, but you gain FHS compliance. > If we agreed on this, are you ok with simply symlinks? Yes, symlinks are perfectly fine.
(In reply to Mikolaj Izdebski from comment #20) > (In reply to jiri vanek from comment #19) > > (In reply to Mikolaj Izdebski from comment #16) > > > - if config is in /etc then you need to back up only this directory, /usr > > > is supposed to be restorable from package contents > > > > Any config file is, isnt? Even if it is in etc... > > If you modify config file, then how are you going to restore your (modified) > config from package contents? I see,you wont to restore it also with custom changes. That do not have much sense, does it? It requires different layer of backuping I was speaking about restoring the original file. That something yo do simply by rpm reinstall. > > > I see two issues > > - all javas up to now had configs in java_home, which in /usr/lib/jvm/theJdk > > - so if your concerns are applicable, then they have to be revisited > > Have to? Theoretically older Javas could use existing (non-FHS compliant) > location, but Java 9 could use the new location. Should. It is strange to have each JDK having different apporaches. > > > - config files were decided to be in jdk, as they are supposed to be jdk x > > cluster specific. So this is fundametnal chage to java in fedora/rhel. > > I don't see any fundamental change here. You would just move config files > from /usr to /etc and leave symlinks where config files used to be. No > functional changes, but you gain FHS compliance. it is quite hard to imagine. In this case, if you use fs with different /etc and, jdk may have those configs missing. Some of them are fundamental for its work and it will not survive theirs absence... > > > If we agreed on this, are you ok with simply symlinks? > > Yes, symlinks are perfectly fine.
> > > > > If we agreed on this, are you ok with simply symlinks? > > > > Yes, symlinks are perfectly fine. Just to ensure convention, those are links, where source (target) is lying inside jdk, and the link is in /etc/java-9-openjdk/NVRA So whe somebody will change configuration, he will nee to change target of those links.
(In reply to jiri vanek from comment #22) > > > > > > > If we agreed on this, are you ok with simply symlinks? > > > > > > Yes, symlinks are perfectly fine. > > Just to ensure convention, those are links, where source (target) is lying > inside jdk, and the link is in /etc/java-9-openjdk/NVRA It should be the other way round: ls -l /usr/lib/jvm/java-9-openjdk-NVRA/conf /usr/lib/jvm/java-9-openjdk-NVRA/conf -> /etc/java-9-openjdk/NVRA > So whe somebody will change configuration, he will nee to change target of > those links. Of course.
(In reply to Severin Gehwolf from comment #23) > (In reply to jiri vanek from comment #22) > > > > > > > > > If we agreed on this, are you ok with simply symlinks? > > > > > > > > Yes, symlinks are perfectly fine. > > > > Just to ensure convention, those are links, where source (target) is lying > > inside jdk, and the link is in /etc/java-9-openjdk/NVRA > > It should be the other way round: > > ls -l /usr/lib/jvm/java-9-openjdk-NVRA/conf > > /usr/lib/jvm/java-9-openjdk-NVRA/conf -> /etc/java-9-openjdk/NVRA I thought so, but, I might be missing something about /etc mounting in education... So rpm installs: /etc/java-9-openjdk/NVR/some_conf and creates /usr/lib/jvm/java-9-openjdk-NVRA/some_conf -> /etc/java-9-openjdk/NVRA/some_conf Now you mount different /etc, and the /etc/java-9-openjdk/NVRA/some_conf willl be missing, and /usr/lib/jvm/java-9-openjdk-NVRA/some_conf will become broken. What now? usually it is not easy to write those (eg java.security) config files and java will not start without them.. Or is somehow guaranted, that all my /etcS are affected by rpm install? I doubt. I doubt even more by introducing NVRA in etc. > > > So whe somebody will change configuration, he will nee to change target of > > those links. > > Of course. In the more logical vice versa then mine world (yours one), this would not work in described way.
(In reply to jiri vanek from comment #24) > (In reply to Severin Gehwolf from comment #23) > > (In reply to jiri vanek from comment #22) > > > > > > > > > > > If we agreed on this, are you ok with simply symlinks? > > > > > > > > > > Yes, symlinks are perfectly fine. > > > > > > Just to ensure convention, those are links, where source (target) is lying > > > inside jdk, and the link is in /etc/java-9-openjdk/NVRA > > > > It should be the other way round: > > > > ls -l /usr/lib/jvm/java-9-openjdk-NVRA/conf > > > > /usr/lib/jvm/java-9-openjdk-NVRA/conf -> /etc/java-9-openjdk/NVRA > > I thought so, but, I might be missing something about /etc mounting in > education... To quote Mikolaj: """" There are several valid reasons for keeping config files in /etc: - /usr may be read-only, but users should be allowed to edit config files - /usr may be shared between many machines, may use different Java config - if config is in /etc then you need to back up only this directory, /usr is supposed to be restorable from package contents From FHS: "/usr is shareable, read-only data. That means that /usr should be shareable between various FHS-compliant hosts and must not be written to. Any information that is host-specific or varies with time is stored elsewhere". So yes, config files definitely don't belong in /usr """" It's not /etc that's shared between machines. It's /usr which sometimes gets mounted. In that scenario it's expected for /etc/java-9-openjdk/ to contain every NVRAs config that are installed via mounted /usr/lib/jvm. /etc would have to get replicated across all machines. But yes, in the mounted /usr scenario, if there is a mismatch between /etc and what's installed via the /usr mount then things break. That's expected. The common use-case for such set-ups is for the NFS-shared host to do RPM installs and consumers of the NFS-share get config synchronized via version control. I.e. they don't install via RPM directly.
Spec URL: https://jvanek.fedorapeople.org/openjdk9Review/V4/java-9-openjdk.spec SRPM URL: https://jvanek.fedorapeople.org/openjdk9Review/V4/java-9-openjdk-9.0.0.178-1.fc24.src.rpm Description: OpenJDK Runtime Environment in implementation of java 9 specification Fedora Account System Username: jvanek All should be fixed, except: * the config files are still in jdk. I need to resolve few more issues in https://pagure.io/copy_jdk_configs/ before move with them (you can see that work in progress) * also I need to find if to link whole conf dir, or individual configs. * it seems that crypto has changed between those two source tarbhalls, and there is newly ../lib/libsunec.so The linked srpm passed for me locally: 223610 Jul 18 11:45 java-9-openjdk-9.0.0.178-1.fc24.x86_64.rpm 6878 Jul 18 11:49 java-9-openjdk-accessibility-9.0.0.178-1.fc24.x86_64.rpm 6582 Jul 18 11:49 java-9-openjdk-accessibility-debug-9.0.0.178-1.fc24.x86_64.rpm 221534 Jul 18 11:45 java-9-openjdk-debug-9.0.0.178-1.fc24.x86_64.rpm 119179042 Jul 18 11:50 java-9-openjdk-debuginfo-9.0.0.178-1.fc24.x86_64.rpm 614878 Jul 18 11:48 java-9-openjdk-demo-9.0.0.178-1.fc24.x86_64.rpm 615810 Jul 18 11:48 java-9-openjdk-demo-debug-9.0.0.178-1.fc24.x86_64.rpm 3503706 Jul 18 11:46 java-9-openjdk-devel-9.0.0.178-1.fc24.x86_64.rpm 3504478 Jul 18 11:46 java-9-openjdk-devel-debug-9.0.0.178-1.fc24.x86_64.rpm 42696374 Jul 18 11:45 java-9-openjdk-headless-9.0.0.178-1.fc24.x86_64.rpm 43759982 Jul 18 11:46 java-9-openjdk-headless-debug-9.0.0.178-1.fc24.x86_64.rpm 241491838 Jul 18 11:47 java-9-openjdk-jmods-9.0.0.178-1.fc24.x86_64.rpm 187679398 Jul 18 11:48 java-9-openjdk-jmods-debug-9.0.0.178-1.fc24.x86_64.rpm 58877670 Jul 18 11:48 java-9-openjdk-src-9.0.0.178-1.fc24.x86_64.rpm 58876934 Jul 18 11:49 java-9-openjdk-src-debug-9.0.0.178-1.fc24.x86_64.rpm But failed strangely in koji. New built at: https://koji.fedoraproject.org/koji/taskinfo?taskID=20595078
> > But failed strangely in koji. New built at: > https://koji.fedoraproject.org/koji/taskinfo?taskID=20595078 found the issue. Will respin as V4. Feel free to proceed with review.
updated: Spec URL: https://jvanek.fedorapeople.org/openjdk9Review/V4/java-9-openjdk.spec SRPM URL: https://jvanek.fedorapeople.org/openjdk9Review/V4/java-9-openjdk-9.0.0.178-1.fc24.src.rpm Description: OpenJDK Runtime Environment in implementation of java 9 specification Fedora Account System Username: jvanek https://koji.fedoraproject.org/koji/taskinfo?taskID=20597202 now should pass.
(In reply to jiri vanek from comment #28) > updated: > > Spec URL: > https://jvanek.fedorapeople.org/openjdk9Review/V4/java-9-openjdk.spec > SRPM URL: > https://jvanek.fedorapeople.org/openjdk9Review/V4/java-9-openjdk-9.0.0.178-1. > fc24.src.rpm > Description: OpenJDK Runtime Environment in implementation of java 9 > specification > Fedora Account System Username: jvanek > > https://koji.fedoraproject.org/koji/taskinfo?taskID=20597202 now should pass. Faield too. https://koji.fedoraproject.org/koji/taskinfo?taskID=20607323 have correct aot_arches, still, failed on aarch64 (imho not rpm bug, but dscovering in progress)
Indeed, needed fix to aarch64 hotspot: https://koji.fedoraproject.org/koji/taskinfo?taskID=20720992 finally passed. Spec URL: https://jvanek.fedorapeople.org/openjdk9Review/V6/java-9-openjdk.spec SRPM URL: https://jvanek.fedorapeople.org/openjdk9Review/V6/java-9-openjdk-9.0.0.178-1.fc24.src.rpm
(In reply to jiri vanek from comment #30) > Indeed, needed fix to aarch64 hotspot: > https://koji.fedoraproject.org/koji/taskinfo?taskID=20720992 > finally passed. It failed on arm32: ^ /builddir/build/BUILD/java-9-openjdk-9.0.0.178-1.fc26.arm/openjdk/build-debug/bootcycle-build/support/gensrc/java.base/java/nio/DirectByteBufferR.java:846: error: ';' expected # A fatal error has been detected by the Java Runtime Environment: ^ /builddir/build/BUILD/java-9-openjdk-9.0.0.178-1.fc26.arm/openjdk/build-debug/bootcycle-build/support/gensrc/java.base/java/nio/DirectByteBufferR.java:846: error: ';' expected # A fatal error has been detected by the Java Runtime Environment: ^ /builddir/build/BUILD/java-9-openjdk-9.0.0.178-1.fc26.arm/openjdk/build-debug/bootcycle-build/support/gensrc/java.base/java/nio/DirectByteBufferR.java:846: error: ';' expected # A fatal error has been detected by the Java Runtime Environment: ^ Generating source file: MenuBarPainter.java/builddir/build/BUILD/java-9-openjdk-9.0.0.178-1.fc26.arm/openjdk/build-debug/bootcycle-build/support/gensrc/java.base/java/nio/DirectByteBufferR.java:846: error: ';' expected # A fatal error has been detected by the Java Runtime Environment: ^ Generating /builddir/build/BUILD/java-9-openjdk-9.0.0.178-1.fc26.arm/openjdk/build-debug/images/docs/api/java/awt/GridBagLayout.html... /builddir/build/BUILD/java-9-openjdk-9.0.0.178-1.fc26.arm/openjdk/build-debug/bootcycle-build/support/gensrc/java.base/java/nio/DirectByteBufferR.java:846: error: <identifier> expected # A fatal error has been detected by the Java Runtime Environment: ^ /builddir/build/BUILD/java-9-openjdk-9.0.0.178-1.fc26.arm/openjdk/build-debug/bootcycle-build/support/gensrc/java.base/java/nio/DirectByteBufferR.java:847: error: illegal character: '#' # ^ /builddir/build/BUILD/java-9-openjdk-9.0.0.178-1.fc26.arm/openjdk/build-debug/bootcycle-build/support/gensrc/java.base/java/nio/DirectByteBufferR.java:848: error: illegal character: '#' # SIGSEGV (0xb) at pc=0xb656d00c, pid=10309, tid=10322 ^ /builddir/build/BUILD/java-9-openjdk-9.0.0.178-1.fc26.arm/openjdk/build-debug/bootcycle-build/support/gensrc/java.base/java/nio/DirectByteBufferR.java:848: error: invalid method declaration; return type required # SIGSEGV (0xb) at pc=0xb656d00c, pid=10309, tid=10322 ^ /builddir/build/BUILD/java-9-openjdk-9.0.0.178-1.fc26.arm/openjdk/build-debug/bootcycle-build/support/gensrc/java.base/java/nio/DirectByteBufferR.java:848: error: illegal start of type # SIGSEGV (0xb) at pc=0xb656d00c, pid=10309, tid=10322 ^ /builddir/build/BUILD/java-9-openjdk-9.0.0.178-1.fc26.arm/openjdk/build-debug/bootcycle-build/support/gensrc/java.base/java/nio/DirectByteBufferR.java:849: error: illegal character: '#' # ^ /builddir/build/BUILD/java-9-openjdk-9.0.0.178-1.fc26.arm/openjdk/build-debug/bootcycle-build/support/gensrc/java.base/java/nio/DirectByteBufferR.java:850: error: illegal character: '#' # JRE version: OpenJDK Runtime Environment (9.0+178) (slowdebug build 9-ea+178) ^ Generating source file: MenuBarMenuPainter.java/builddir/build/BUILD/java-9-openjdk-9.0.0.178-1.fc26.arm/openjdk/build-debug/bootcycle-build/support/gensrc/java.base/java/nio/DirectByteBufferR.java:851: error: illegal character: '#' # Java VM: OpenJDK Server VM (slowdebug 9-ea+178, mixed mode, serial gc, linux-) ^ /builddir/build/BUILD/java-9-openjdk-9.0.0.178-1.fc26.arm/openjdk/build-debug/bootcycle-build/support/gensrc/java.base/java/nio/DirectByteBufferR.java:852: error: illegal character: '#' # Problematic frame: ^ /builddir/build/BUILD/java-9-openjdk-9.0.0.178-1.fc26.arm/openjdk/build-debug/bootcycle-build/support/gensrc/java.base/java/nio/DirectByteBufferR.java:853: error: illegal character: '#' # V [libjvm.so+0xb8500c] ^
Second round of review: Package Review ============== Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated [ ] = Manual review needed Issues: ======= - Spec has this: # PPC/PPC64 needs -fno-tree-vectorize since -O3 would # otherwise generate wrong code producing segfaults. %ifarch %{power64} ppc EXTRA_CFLAGS="$EXTRA_CFLAGS -fno-tree-vectorize" I believe this is because of an old GCC bug, which is no longer an issue. At least not for Fedora. See https://bugzilla.redhat.com/show_bug.cgi?id=1146897 We should no longer pass '-fno-tree-vectorize' on PPC64. - In order to match upstream, 'java -version' should output openjdk version "9". I.e. no '-ea' suffix any more. $ java -version openjdk version "9-ea" OpenJDK Runtime Environment (build 9-ea+178) OpenJDK 64-Bit Server VM (build 9-ea+178, mixed mode) See: http://mail.openjdk.java.net/pipermail/quality-discuss/2017-July/000706.html - Note: No known owner of /usr/lib/jvm/java-9-openjdk-9.0.0.178-1.fc26.x86_64/lib/server/classes.jsa - Please move config files to /etc/ and link them to /etc in /usr/lib/jvm/java-9-openjdk-9.0.0.178-1.fc26.x86_64/conf/ - Latest available snapshot should be packaged. Latest EA build is: jdk-9+180. See: http://jdk.java.net/9/ I'll not point this out in the next review since this is going to change soon again. I trust you'll update to latest available build once approved. - Some config files are not in conf: It's likely an upstream issue as I see them in lib for an upstream build too. Please report a bug. $ rpm -Vv java-9-openjdk-headless | grep ' c ' | grep lib/security ......... c /usr/lib/jvm/java-9-openjdk-9.0.0.178-1.fc26.x86_64/lib/security/blacklisted.certs ......... c /usr/lib/jvm/java-9-openjdk-9.0.0.178-1.fc26.x86_64/lib/security/default.policy ===== MUST items ===== C/C++: [x]: Package does not contain kernel modules. [?]: Package contains no static executables. [x]: Rpath absent or only used for internal libs. Note: See rpmlint output I see many rpmlint errors related to $ORIGIN and rpath. All of them seem to be internal libs. java-1.8.0-openjdk shows similar issues. [x]: Development (unversioned) .so files in -devel subpackage, if present. Note: Unversioned so-files in private %_libdir subdirectory (see attachment). Verify they are not in ld path. All so files are internal OpenJDK libraries and are not in the ld path as far as I can tell. [x]: Header files in -devel subpackage, if present. [x]: Package does not contain any libtool archives (.la) Generic: [x]: Package successfully compiles and builds into binary rpms on at least one supported primary architecture. Packager provided scratch build links which showed packages building. Reviewer submitted scratch build for SRPM on x86_64 which built fine. [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. It's a combination of various licenses. NOTE: LGPL+ is unknown to rpmlint??! [?]: License file installed when any subpackage combination is installed. [?]: If the package is under multiple licenses, the licensing breakdown must be documented in the spec. [!]: Package requires other packages for directories it uses. Note: No known owner of /usr/lib/jvm/java-9-openjdk-9.0.0.178-1.fc26.x86_64/lib/server/classes.jsa [x]: Package must own all directories that it creates. [x]: %build honors applicable compiler flags or justifies otherwise. [x]: All build dependencies are listed in BuildRequires, except for any that are listed in the exceptions section of Packaging Guidelines. [x]: Package contains no bundled libraries without FPC exception. Jar files in sources [x]: Changelog in prescribed format. [x]: Sources contain only permissible code or content. [x]: %config files are marked noreplace or the reason is justified. [x]: Each %files section contains %defattr if rpm < 4.4 Note: %defattr present but not needed. Same spec is used on older rpm versions. OK. [x]: Development files must be in a -devel package Note: In addition to -devel subpackage there is a jmods-devel package for creating custom images. [?]: 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. [?]: gtk-update-icon-cache is invoked in %postun and %posttrans if package contains icons. Note: icons in java-9-openjdk [x]: Useful -debuginfo package or justification otherwise. [x]: Package is not known to require an ExcludeArch tag. [x]: Package complies to the Packaging Guidelines [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]: Package contains desktop file if it is a GUI application. [x]: Package installs a %{name}.desktop using desktop-file-install or desktop-file-validate if there is such a file. [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]: Large documentation must go in a -doc subpackage. Large could be size (~1MB) or number of files. There are variants of -javadoc subpackages. [x]: Packages must not store files under /srv, /opt or /usr/local ===== SHOULD items ===== Generic: [x]: Reviewer should test that the package builds in mock. [-]: 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). [x]: Fully versioned dependency in subpackages if applicable. [x]: Package functions as described. [!]: Latest version is packaged. Latest EA build is: jdk-9+180. See: http://jdk.java.net/9/ [?]: Package does not include license text files separate from upstream. [x]: Patches link to upstream bugs/comments/lists or are otherwise justified. [?]: Scriptlets must be sane, if used. [x]: SourceX tarball generation or download is documented. Script + documentation will follow after dist-git gets created. [?]: 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. [?]: Packages should try to preserve timestamps of original installed files. [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]: Uses parallel make %{?_smp_mflags} macro. [x]: SourceX is a working URL. [x]: Spec use %global instead of %define unless justified. ===== EXTRA items ===== Generic: [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]: Package should not use obsolete m4 macros [x]: Spec file according to URL is the same as in SRPM.
(In reply to Severin Gehwolf from comment #31) > (In reply to jiri vanek from comment #30) > > Indeed, needed fix to aarch64 hotspot: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=20720992 > > finally passed. > > It failed on arm32: FWIW, I'd be fine with disabling the slowdebug build on arm32 until this is fixed.
Spec URL: https://jvanek.fedorapeople.org/openjdk9Review/V7/java-9-openjdk.spec SRPM URL: https://jvanek.fedorapeople.org/openjdk9Review/V7/java-9-openjdk-9.0.0.181-1.fc24.src.rpm https://koji.fedoraproject.org/koji/taskinfo?taskID=21044824 > > Issues: > ======= > - Spec has this: > # PPC/PPC64 needs -fno-tree-vectorize since -O3 would > # otherwise generate wrong code producing segfaults. > %ifarch %{power64} ppc > EXTRA_CFLAGS="$EXTRA_CFLAGS -fno-tree-vectorize" > removed! ... > http://mail.openjdk.java.net/pipermail/quality-discuss/2017-July/000706.html > - Note: No known owner of > /usr/lib/jvm/java-9-openjdk-9.0.0.178-1.fc26.x86_64/lib/server/classes.jsa Fixed > - Please move config files to /etc/ and link them to /etc in > /usr/lib/jvm/java-9-openjdk-9.0.0.178-1.fc26.x86_64/conf/ See at bottom > - Latest available snapshot should be packaged. > Latest EA build is: jdk-9+180. See: http://jdk.java.net/9/ > I'll not point this out in the next review since this is going to change > soon > again. I trust you'll update to latest available build once approved. Moved to u181 with CPU patches > - Some config files are not in conf: It's likely an upstream issue > as I see them in lib for an upstream build too. Please report a bug. > $ rpm -Vv java-9-openjdk-headless | grep ' c ' | grep lib/security > ......... c > /usr/lib/jvm/java-9-openjdk-9.0.0.178-1.fc26.x86_64/lib/security/blacklisted. > certs > ......... c > /usr/lib/jvm/java-9-openjdk-9.0.0.178-1.fc26.x86_64/lib/security/default. > policy > If the file is not in expected location, jdk will not find it I can move them to conf and link to original location, but as /etc is still in play, then I would rather not touch it. If you insists, I will move them, and link them. ... > > It failed on arm32: > > FWIW, I'd be fine with disabling the slowdebug build on arm32 until this is > fixed. done Config files in etc. I really wont to move them. However it will not be an easy task from point of view of multiple installs and copy-jdk-configs. I would like to not block this review on it. I have already started to work on c-j-c to support this, but there is still some longer way to go.
(In reply to jiri vanek from comment #34) > > - Some config files are not in conf: It's likely an upstream issue > > as I see them in lib for an upstream build too. Please report a bug. > > $ rpm -Vv java-9-openjdk-headless | grep ' c ' | grep lib/security > > ......... c > > /usr/lib/jvm/java-9-openjdk-9.0.0.178-1.fc26.x86_64/lib/security/blacklisted. > > certs > > ......... c > > /usr/lib/jvm/java-9-openjdk-9.0.0.178-1.fc26.x86_64/lib/security/default. > > policy > > > > If the file is not in expected location, jdk will not find it > I can move them to conf and link to original location, but as /etc is still > in play, then I would rather not touch it. > If you insists, I will move them, and link them. My point was that we should ask *upstream* whether or not this is intentional. It's one of the odd balls. Everything else is in conf upstream already. Thus, we should file a bug/ask upstream whether or not this should be in conf upstream. That's all that's to do here. Thank you! > Config files in etc. I really wont to move them. However it will not be an > easy task from point of view of multiple installs and copy-jdk-configs. > I would like to not block this review on it. I have already started to work > on c-j-c to support this, but there is still some longer way to go. OK. This should be fine. I'm glad to hear this will be worked on. Builds failed: + cp -a openjdk/build/bundles/jdk-9-ea+181-docs.zip /builddir/build/BUILDROOT/java-9-openjdk-9.0.0.181-1.fc26.x86_64/usr/share/javadoc/java-9-openjdk-9.0.0.181-1.fc26.zip cp: cannot stat 'openjdk/build/bundles/jdk-9-ea+181-docs.zip': No such file or directory This in the spec file should be the culprit: cp -a %{buildoutputdir $suffix}/bundles/jdk-%{majorver}-ea+%{buildver}-docs.zip $RPM_BUILD_ROOT%{_javadocdir}/%{uniquejavadocdir $suffix}.zip No 'ea' anymore in the version.
Yah. I noted. Already respined: https://koji.fedoraproject.org/koji/taskinfo?taskID=21048132
... > > My point was that we should ask *upstream* whether or not this is > intentional. It's one of the odd balls. Everything else is in conf upstream > already. Thus, we should file a bug/ask upstream whether or not this should > be in conf upstream. That's all that's to do here. Thank you! fired: http://mail.openjdk.java.net/pipermail/build-dev/2017-August/019587.html > > > Config files in etc. I really wont to move them. However it will not be an > > easy task from point of view of multiple installs and copy-jdk-configs. > > I would like to not block this review on it. I have already started to work > > on c-j-c to support this, but there is still some longer way to go. > > OK. This should be fine. I'm glad to hear this will be worked on. Thank you for trust. And thank you for careful review.
(In reply to jiri vanek from comment #36) > Yah. I noted. Already respined: > https://koji.fedoraproject.org/koji/taskinfo?taskID=21048132 and updated V7
(In reply to Severin Gehwolf from comment #35) > (In reply to jiri vanek from comment #34) > > > - Some config files are not in conf: It's likely an upstream issue > > > as I see them in lib for an upstream build too. Please report a bug. > > > $ rpm -Vv java-9-openjdk-headless | grep ' c ' | grep lib/security > > > ......... c > > > /usr/lib/jvm/java-9-openjdk-9.0.0.178-1.fc26.x86_64/lib/security/blacklisted. > > > certs > > > ......... c > > > /usr/lib/jvm/java-9-openjdk-9.0.0.178-1.fc26.x86_64/lib/security/default. > > > policy > > > > > > > If the file is not in expected location, jdk will not find it > > I can move them to conf and link to original location, but as /etc is still > > in play, then I would rather not touch it. > > If you insists, I will move them, and link them. > > My point was that we should ask *upstream* whether or not this is > intentional. It's one of the odd balls. Everything else is in conf upstream > already. Thus, we should file a bug/ask upstream whether or not this should > be in conf upstream. That's all that's to do here. Thank you! explained: http://mail.openjdk.java.net/pipermail/build-dev/2017-August/019589.html > > > Config files in etc. I really wont to move them. However it will not be an > > easy task from point of view of multiple installs and copy-jdk-configs. > > I would like to not block this review on it. I have already started to work > > on c-j-c to support this, but there is still some longer way to go. > > OK. This should be fine. I'm glad to hear this will be worked on. > Suport for linked resources added: https://pagure.io/copy_jdk_configs/commits/master Now it will need hours and hours of testing.
(In reply to jiri vanek from comment #36) > Yah. I noted. Already respined: > https://koji.fedoraproject.org/koji/taskinfo?taskID=21048132 BuildError: The following noarch package built differently on different architectures: java-9-openjdk-javadoc-zip-9.0.0.181-1.fc26.noarch.rpm Not sure what do do about this. Make javadoc-zip archful?
(In reply to Severin Gehwolf from comment #40) > (In reply to jiri vanek from comment #36) > > Yah. I noted. Already respined: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=21048132 > > BuildError: The following noarch package built differently on different > architectures: java-9-openjdk-javadoc-zip-9.0.0.181-1.fc26.noarch.rpm > > Not sure what do do about this. Make javadoc-zip archful? Note that aot is x86_64 Linux only. So that might be the reason why this happens.
(In reply to Severin Gehwolf from comment #41) > (In reply to Severin Gehwolf from comment #40) > > (In reply to jiri vanek from comment #36) > > > Yah. I noted. Already respined: > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=21048132 > > > > BuildError: The following noarch package built differently on different > > architectures: java-9-openjdk-javadoc-zip-9.0.0.181-1.fc26.noarch.rpm > > > > Not sure what do do about this. Make javadoc-zip archful? > > Note that aot is x86_64 Linux only. So that might be the reason why this > happens. Yes, that would be the reason. So There are only two options - to disable aot, or make javadocs arch dependent:(
(In reply to jiri vanek from comment #42) > (In reply to Severin Gehwolf from comment #41) > > (In reply to Severin Gehwolf from comment #40) > > > (In reply to jiri vanek from comment #36) > > > > Yah. I noted. Already respined: > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=21048132 > > > > > > BuildError: The following noarch package built differently on different > > > architectures: java-9-openjdk-javadoc-zip-9.0.0.181-1.fc26.noarch.rpm > > > > > > Not sure what do do about this. Make javadoc-zip archful? > > > > Note that aot is x86_64 Linux only. So that might be the reason why this > > happens. > > Yes, that would be the reason. So There are only two options - to disable > aot, or make javadocs arch dependent:( The latter, please.
I'm approving this request. Jiri will make the javadoc-zips an archful package to account for the jaot differences which is an x86_64 only Linux feature upstream at this point.
(In reply to Severin Gehwolf from comment #44) > I'm approving this request. Jiri will make the javadoc-zips an archful > package to account for the jaot differences which is an x86_64 only Linux > feature upstream at this point. Ty. + move configs to /etc once Ihave it fully tested.
(fedrepo-req-admin): The Pagure repository was created at https://src.fedoraproject.org/rpms/java-9-openjdk
...and building...
f27+ spec needed huge macro usage adaptation for rpmbuild 4.14 f28 https://koji.fedoraproject.org/koji/buildinfo?buildID=958063 f27 https://koji.fedoraproject.org/koji/buildinfo?buildID=955944 for record, unchanged build with original mcros usage: f26 https://koji.fedoraproject.org/koji/buildinfo?buildID=956299
as all the builds passed, and bodhi updates are still not enabled for f27, and noupdate planned for f26 (just builds), closing.
Config files have been moved to /etc for rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=980379 https://src.fedoraproject.org/rpms/java-9-openjdk/c/1bb464c38fd49870bc7bbbfddc87a1dd0c3b0b12?branch=master (+ https://src.fedoraproject.org/rpms/java-9-openjdk/c/3dc22048bc2cbe6eae1863eaf3519932d59691c4?branch=master https://src.fedoraproject.org/rpms/java-9-openjdk/c/b0b21164adf4ab8da5712ff741aeb35ffbbbe6ca?branch=master https://src.fedoraproject.org/rpms/java-9-openjdk/c/8afd2c2cd3bac4e0d96a9059f56e0ed3321842c3?branch=master
(In reply to jiri vanek from comment #54) > Config files have been moved to /etc for rawhide: Thank you!
Nobody noticed that %changelog has wrong versions: %changelog * Tue Oct 10 2017 Jiri Vanek <jvanek> - 1:1.9.0.0-9.b163 - now owning dir etcjavasubdir * Tue Oct 10 2017 Jiri Vanek <jvanek> - 1:1.9.0.0-8.b163 - EC no longer built * Tue Oct 10 2017 Jiri Vanek <jvanek> - 1:1.9.0.0-7.b163 - now owning dir etcjavadir * Thu Oct 05 2017 Jiri Vanek <jvanek> - 1:1.9.0.0-4.b163 - config files moved to etc * Tue Aug 29 2017 Michal Vala <mvala> - 1:1.9.0.0-3.b163 - changed archinstall to i686 - added ownership of lib/client/ while package versions are: 9.0.0.181-1.fc28 9.0.0.181-2.fc28 ... 9.0.0.181-9.fc28 Where are the %changelog entries for -1, -2, -5 and -6? You could also have dropped the Epoch: from the package, since it's a completely new package and kept it only in the virtual Provides:. Actually, the use of Epoch: in a NEW package must be justified in the review. It wasn't. See https://fedoraproject.org/wiki/Packaging:Versioning . Requires: xorg-x11-fonts-Type1 Seriously? Does Java 9 still require legacy Type1 fonts in 2017? # Require jpackage-utils for ownership of /usr/lib/jvm/ Requires: jpackage-utils jpackage-utils was renamed to javapackages-tools in 2012, why are you still using the old name? Patches are not accompanied by links to Fedora or upstream bug reports. I'd argue that the spec file fails the spec legibility rule. There are many macros whose purpose isn't obvious. For example: %global aarch64 aarch64 arm64 armv8 ... #images stub %global jdkimage jdk It's also full of typos and unintelligible comments, for example: # elfutils ony are ok for built without AOT I have no idea what the above means. Or this: # Zero-assembler build requirement. Comments are supposed to explain something. The one above doesn't. See: https://fedoraproject.org/wiki/Packaging:Guidelines#Spec_Legibility . This package would not have passed review as-is if I was the reviewer. Sorry to be blunt, but it looks like a bad copy and paste from older openjdk spec file.
(In reply to Dominik 'Rathann' Mierzejewski from comment #56) > Nobody noticed that %changelog has wrong versions: > > %changelog > * Tue Oct 10 2017 Jiri Vanek <jvanek> - 1:1.9.0.0-9.b163 > - now owning dir etcjavasubdir > > * Tue Oct 10 2017 Jiri Vanek <jvanek> - 1:1.9.0.0-8.b163 > - EC no longer built > > * Tue Oct 10 2017 Jiri Vanek <jvanek> - 1:1.9.0.0-7.b163 > - now owning dir etcjavadir > > * Thu Oct 05 2017 Jiri Vanek <jvanek> - 1:1.9.0.0-4.b163 > - config files moved to etc > > * Tue Aug 29 2017 Michal Vala <mvala> - 1:1.9.0.0-3.b163 > - changed archinstall to i686 > - added ownership of lib/client/ > > while package versions are: > 9.0.0.181-1.fc28 > 9.0.0.181-2.fc28 > ... > 9.0.0.181-9.fc28 > > Where are the %changelog entries for -1, -2, -5 and -6? IIRC those were only bumps of releases to allow testing of new config files. > > You could also have dropped the Epoch: from the package, since it's a > completely new package and kept it only in the virtual Provides:. Actually, > the use of Epoch: in a NEW package must be justified in the review. It > wasn't. See https://fedoraproject.org/wiki/Packaging:Versioning . I do not see reason to diverge from jdk8. We keep epoch injdk packages since jdk5. I would be afraid to lower it. Maybe my fear is vain, but it would need proof. > > Requires: xorg-x11-fonts-Type1 > Seriously? Does Java 9 still require legacy Type1 fonts in 2017? Seriously, yes. Java is depnding on X11 for now. Although work has been initiated, its not sure when we will see X-impl-independent port. > > # Require jpackage-utils for ownership of /usr/lib/jvm/ > Requires: jpackage-utils > jpackage-utils was renamed to javapackages-tools in 2012, why are you still > using the old name? > Have you noted that it is using javapackages-tools in all except one place? Thats obvious overlook. Patch/bugreport or any other "let me know" is welcomed. I fixed it now for jdk8 and 9. > Patches are not accompanied by links to Fedora or upstream bug reports. > > I'd argue that the spec file fails the spec legibility rule. There are many > macros whose purpose isn't obvious. For example: > %global aarch64 aarch64 arm64 armv8 Whats wrong with it? Its all versions of arm64 self identifications I ever encountered in all places I was rebuilding this SRPM. > ... > #images stub > %global jdkimage jdk What do you see against this macro? > > It's also full of typos and unintelligible comments, for example: Please, contribute. Fix welcomed. > # elfutils ony are ok for built without AOT > I have no idea what the above means. s/ony/only > Or this: > # Zero-assembler build requirement. > Comments are supposed to explain something. The one above doesn't. It does, if you know what is Zero. > > See: https://fedoraproject.org/wiki/Packaging:Guidelines#Spec_Legibility . > > This package would not have passed review as-is if I was the reviewer. Sorry > to be blunt, but it looks like a bad copy and paste from older openjdk spec > file. Unluckily, you weren't. Be sure that non of the nits, you spotted were left intentionally or with evil purposes. I will fix everything you see invalid. Probably except the linking of usptream patches which is mess to do