Description of problem: Builds based on same sources: f28: https://koji.fedoraproject.org/koji/taskinfo?taskID=27362591 f29: https://koji.fedoraproject.org/koji/taskinfo?taskID=27363834 However f29 fails with (f28's pass): /builddir/build/BUILDROOT/java-openjdk-10.0.1.10-6.fc29.x86_64/usr/share/applications/java-10-openjdk-10.0.1.10-6.fc29.x86_64-jconsole.desktop: error: value "%{_jvmdir}/java-10-openjdk-10.0.1.10-6.fc29.x86_64/bin/jconsole" for key "Exec" in group "Desktop Entry" contains an invalid field code "%{" Error on file "jconsole.desktop": Failed to validate the created desktop file Which clearly is not expanded macro in java-openjdk.spec: # Prepare desktop files for suffix in %{build_loop} ; do for file in %{SOURCE9}; do FILE=`basename $file | sed -e s:\.in$::g` EXT="${FILE##*.}" NAME="${FILE%.*}" OUTPUT_FILE=$NAME$suffix.$EXT sed -e s:#JAVA_HOME#:%{sdkbindir -- $suffix}:g $file > $OUTPUT_FILE sed -i -e s:#JRE_HOME#:%{jrebindir -- $suffix}:g $OUTPUT_FILE sed -i -e s:#ARCH#:%{version}-%{release}.%{_arch}$suffix:g $OUTPUT_FILE sed -i -e s:#JAVA_MAJOR_VERSION#:%{majorver}:g $OUTPUT_FILE done done for: cat jconsole.desktop.in [Desktop Entry] Name=OpenJDK #JAVA_MAJOR_VERSION# Monitoring & Management Console #ARCH# Comment=Monitor and manage OpenJDK #JAVA_MAJOR_VERSION# applications for #ARCH# Exec=#JAVA_HOME#/jconsole Icon=java-#JAVA_MAJOR_VERSION#-#JAVA_VENDOR# Terminal=false Type=Application StartupWMClass=sun-tools-jconsole-JConsole Categories=Development;Monitor;Java; Version=1.0 Note, that unquoted #STUFF is correctly used by sed, f28's cat java-10-openjdk-10.0.1.10-6.fc28.x86_64-jconsole.desktop [Desktop Entry] Name=OpenJDK 10 Monitoring & Management Console 10.0.1.10-6.fc28.x86_64 Comment=Monitor and manage OpenJDK applications for 10.0.1.10-6.fc28.x86_64 Exec=/usr/lib/jvm/java-10-openjdk-10.0.1.10-6.fc28.x86_64/bin/jconsole Icon=java-10 Terminal=false Type=Application StartupWMClass=sun-tools-jconsole-JConsole Categories=Development;Monitor;Java; Version=1.0 X-Desktop-File-Install-Version=0.23 Name[en_US]=java-10-openjdk-10.0.1.10-6.fc28.x86_64-jconsole is correct When checking root.logs, the rpm could be bad component, as rpm si in same version 4.14.1-9 (only f29 instead of f28) Also bash is same (4.4.19-2 (again only fc29 isntead of 28)) and sed. On contrary: binutils got bumped 2.29->2.30 coreutil jumped from 8.29-6.fc28 to 8.29-12.fc29 Still, it is unexpanded macro... Maybe some f29 rpm patch only revoking macro expansion behid hash?
Rpm in F28 and F29 is exactly the same, except for dist tag in release. So unless there's a gcc/glibc change causing rpm to misbehave on F29, it's something else.
Do you have any suggestion what? I mean what you know from top of head RPM can be calling on its way form spec's scriplet to script and to its execution?
So it's %{_jvmdir} that's not getting expanded. Let's see... It's not defined in the spec, so where is it defined? [pmatilai@sopuli ~]$ grep _jvmdir /usr/lib/rpm/macros.d/* /usr/lib/rpm/macros.d/macros.jpackage:%_jvmdir %{_prefix}/lib/jvm [pmatilai@sopuli ~]$ rpm -qf /usr/lib/rpm/macros.d/macros.jpackage javapackages-tools-5.0.0-14.fc28.noarch So there's a build-depdnency on javapackages-tools, but it's not listed as BuildRequires - there's your bug. Comparing the root logs between F28 and F29, something causes it to be pulled into the root on F28 but not so in F29.
Thanx. Then the issue is when we mover *requires* from javapackages-tools to javapackages-filesystem or default buildroot have chnaged. As there was recent clean up of java buildroot, second is more likely. Again, sorry for noise Mikolai, may you confirm?
hm. NVM. The buildrequires of javapackages-filesystem will solve it anyway.
(In reply to jiri vanek from comment #5) > hm. NVM. The buildrequires of javapackages-filesystem will solve it anyway. This should be BuildRequires: javapackages-tools, right? However, this will then drag in java-1.8.0-openjdk again for a JDK 10 build. Bug 1500288 all over again. So what I'd think would be a better approach is to move the directory macros from /usr/lib/rpm/macros.d/macros.jpackage to javapackages-filesystem. E.g. %_jvmdir %{_prefix}/lib/jvm Macros which use java functions may stay in a separate macro file which then may require java-1.8.0-openjdk. Thoughts?
(In reply to Severin Gehwolf from comment #6) > Macros which use java functions may stay in a separate macro file which then > may require java-1.8.0-openjdk. Thoughts? We can do that. Please open an issue at M$ GitHub at https://github.com/fedora-java/javapackages
(In reply to Mikolaj Izdebski from comment #7) > (In reply to Severin Gehwolf from comment #6) > > Macros which use java functions may stay in a separate macro file which then > > may require java-1.8.0-openjdk. Thoughts? > > We can do that. Please open an issue at M$ GitHub at > https://github.com/fedora-java/javapackages Here you go: https://github.com/fedora-java/javapackages/issues/57
Severin, Mikolai Thank you. Heaving another jdks in buildroot of jdk itself is not so tragic so I wonted to let it be (until it bites, if ever) Still, heaving the macros in jpt-fs would be much more confortable. TY! Reopening until it is fixed.
I believe that this bug is fixed in javapackages-tools-5.2.0-1, which is available in Fedora Rawhide, so I am closing this bug now. The build containing the fix can be found at Koji: http://koji.fedoraproject.org/koji/buildinfo?buildID=1088932