tir. 8. okt. 2019 kl. 19:19 skrev Alexey Semenyuk < alexey.semen...@oracle.com>:
> > > On 10/8/2019 12:43 PM, Sverre Moe wrote: > > Some comments about the jpackage+1-49 update. > > > > 1) It has become a lot more verbose since jpackage+1-35. Makes using the > > verbose argument difficult to actually see relevant output, like the > actual > > rpmbuild/dpkg command output. > > > It is running a lot of ldd commands, is that necessary? They are > extremely > > verbose. > ldd is used in building a list of prerequisite packages. ldd is applied > to every shared library and binary in app's image, that is why it is > invoked so many times. > > Is this new in jpackage+1-49? It was not part of the verbose output using jpackage+1-35. > > Perhaps jpackage needs different verbosity levels if anyone is actually > > interested in all these ldd outputs. > > > > The dpkg command fails a lot with IOException. > > dpkg-query: no path found matching pattern /usr/lib64/libX11.so.6 > > java.io.IOException: command [dpkg, -s, /usr/lib64/libX11.so.6] exited > with > > 1 code > The command tries to locate a package providing /usr/lib64/libX11.so.6 > needed by one of binaries in app image and fails. Does > /usr/lib64/libX11.so.6 exist? > > All the files it tries to locate does exist, but it still fails with an Exception. Running [dpkg, -S, /usr/lib64/libXrender.so.1] dpkg-query: no path found matching pattern /usr/lib64/libXrender.so.1 java.io.IOException: Command [dpkg, -S, /usr/lib64/libXrender.so.1] exited with 1 code at jdk.jpackage/jdk.jpackage.internal.Executor.executeExpectSuccess(Executor.java:68) at jdk.jpackage/jdk.jpackage.internal.LinuxDebBundler.lambda$initLibProvidersLookup$13(LinuxDebBundler.java:239) at jdk.jpackage/jdk.jpackage.internal.LibProvidersLookup.lambda$execute$1(LibProvidersLookup.java:64) at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195) at java.base/java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1694) at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474) at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913) at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578) at jdk.jpackage/jdk.jpackage.internal.LibProvidersLookup.execute(LibProvidersLookup.java:75) at jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.getListOfNeededPackages(LinuxPackageBundler.java:210) at jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.createDefaultReplacementData(LinuxPackageBundler.java:236) at jdk.jpackage/jdk.jpackage.internal.LinuxPackageBundler.execute(LinuxPackageBundler.java:175) at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:627) at jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:513) at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:98) at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:51) Could the error message from dpkg be because I am not running on a Debian type distribution. > dpkg-query: no path found matching pattern /usr/lib64/libXrender.so.1 Building an DEB package has not been a problem before on a RedHat type distribution. > 2) Previous resources for RPM are no longer used: > > The resources for application.desktop and application.png is no longer > used > > with building RPM. > > Have these been removed? Nothing in the changes listed since previous > build > > has any mention that this has been removed. > > > > With jpackage+1-35 > > Using default package resource java32,png [menu icon] (add > application.png > > to the resource-dir to customize) > > Using default package resource template,desktop [Menu shortcut > descriptor] > > (add application.desktop to the resource-dir to customize) > > Using default package resource template.spec [RPM spec file] (add > > application.spec to the resource-dir to customize) > > > > With jpackage+1-49 > > Using default package resource template.spec [RPM spec file] (add > > application.spec to the resource-dir to customize) > We don't add desktop integration in the package by default unless there > is one of `--icon` `--file-associations` options on jpackage command line. > To force adding desktop integration in the package you need to specify > `--linux-shortcut` option. See [1] > > - Alexey > > [1] https://bugs.openjdk.java.net/browse/JDK-8229779 > > Thanks, adding the --linux-shortcut solves that problem. However it seems to be a regression there in choosing the desktop resource file. Using default package resource template.desktop [Menu shortcut descriptor] (add application-application.desktop to the resource-dir to customize) It should be just "application.desktop", not "application-application.desktop". /Sverre