Fix flatpak builds (catering for their uncompressed manual pages)

...see
<https://docs.fedoraproject.org/en-US/flatpak/troubleshooting/#_uncompressed_manual_pages>
for details

Fix flatpak builds

...after 19065a8b01585a1aa5f22e38e99fc0c47c597074 "Temporarily move x86 to use
Zero in order to get a working build":

When building the

>       if ${run_bootstrap} ; then

branch for suffix='' and loop='-main', the second

>           buildjdk ${builddir} $(pwd)/${bootinstalldir}/images/%{jdkimage} "${maketargets}" ${debugbuild} ${link_opt}

uses the JDK (`$(pwd)/${bootinstalldir}/images/%{jdkimage}`) from the installjdk
on the previous line.  But installjdk does

>       rm ${imagepath}/lib/tzdb.dat
>       ln -s %{_datadir}/javazi-1.8/tzdb.dat ${imagepath}/lib/tzdb.dat

which made that JDK's tzdb.dat link to /app/share/javazi-1.8/tzdb.dat in a
flatpak build (rather than the usual /usr/share/javazi-1.8/tzdb.dat in a non-
flatpak build) which is not present at build-time (but will be present at
runtime in at least the LibreOffice flatpak, which bundles tzdata-java built for
the flatpak /app prefix).  So using that JDK's compiler during the build kept
failing due to java.io.FileNotFoundException for its lib/tzdb.dat.

(This was not an issue prior to 19065a8b01585a1aa5f22e38e99fc0c47c597074, as
installjdk's modification of lib/tzdb.dat used to be done only for the "Final
setup on the main image" at the very end of the build, not during the build for
JDKs that are themselves used later during the build.)

The easiest workaround for this issue appears to be to just not bootstrap_build
in the flatpak case, avoiding the situation that a JDK whose lib/tzdb.dat has
been modified through installjdk is used during the build.

Resolves: rhbz#2102726
This commit is contained in:
Andrew Hughes 2022-08-29 18:01:22 +01:00
parent 674cdfbcb9
commit 75d8e4a02b
1 changed files with 16 additions and 7 deletions

View File

@ -190,11 +190,15 @@
%global staticlibs_loop %{nil}
%endif
%if 0%{?flatpak}
%global bootstrap_build false
%else
%ifarch %{bootstrap_arches}
%global bootstrap_build true
%else
%global bootstrap_build false
%endif
%endif
%if %{include_staticlibs}
# Extra target for producing the static-libraries. Separate from
@ -353,7 +357,7 @@
%global top_level_dir_name %{origin}
%global top_level_dir_name_backup %{top_level_dir_name}-backup
%global buildver 1
%global rpmrelease 3
%global rpmrelease 4
# Priority must be 8 digits in total; up to openjdk 1.8, we were using 18..... so when we moved to 11, we had to add another digit
%if %is_system_jdk
# Using 10 digits may overflow the int used for priority, so we combine the patch and build versions
@ -933,7 +937,7 @@ exit 0
%ifarch %{sa_arches}
%ifnarch %{zero_arches}
%{_jvmdir}/%{sdkdir -- %{?1}}/bin/jhsdb
%{_mandir}/man1/jhsdb-%{uniquesuffix -- %{?1}}.1.gz
%{_mandir}/man1/jhsdb-%{uniquesuffix -- %{?1}}.1*
%endif
%endif
%{_jvmdir}/%{sdkdir -- %{?1}}/bin/jinfo
@ -972,11 +976,11 @@ exit 0
%{_mandir}/man1/jstat-%{uniquesuffix -- %{?1}}.1*
%{_mandir}/man1/jstatd-%{uniquesuffix -- %{?1}}.1*
%{_mandir}/man1/serialver-%{uniquesuffix -- %{?1}}.1*
%{_mandir}/man1/jdeprscan-%{uniquesuffix -- %{?1}}.1.gz
%{_mandir}/man1/jlink-%{uniquesuffix -- %{?1}}.1.gz
%{_mandir}/man1/jmod-%{uniquesuffix -- %{?1}}.1.gz
%{_mandir}/man1/jshell-%{uniquesuffix -- %{?1}}.1.gz
%{_mandir}/man1/jfr-%{uniquesuffix -- %{?1}}.1.gz
%{_mandir}/man1/jdeprscan-%{uniquesuffix -- %{?1}}.1*
%{_mandir}/man1/jlink-%{uniquesuffix -- %{?1}}.1*
%{_mandir}/man1/jmod-%{uniquesuffix -- %{?1}}.1*
%{_mandir}/man1/jshell-%{uniquesuffix -- %{?1}}.1*
%{_mandir}/man1/jfr-%{uniquesuffix -- %{?1}}.1*
%if %{with_systemtap}
%dir %{tapsetroot}
@ -2577,6 +2581,11 @@ cjc.mainProgram(args)
%endif
%changelog
* Mon Aug 29 2022 Stephan Bergmann <sbergman@redhat.com> - 1:17.0.4.1.1-4
- Fix flatpak builds (catering for their uncompressed manual pages)
- Fix flatpak builds by exempting them from bootstrap
- Resolves: rhbz#2102726
* Mon Aug 29 2022 Andrew Hughes <gnu.andrew@redhat.com> - 1:17.0.4.1.1-3
- Update FIPS support to bring in latest changes
- * RH2104724: Avoid import/export of DH private keys