Re: Integrated: 8257434: jpackage fails to create rpm on Fedora Linux

On Tue, 1 Dec 2020 23:54:11 GMT, Alexey Semenyuk wrote: > Add missing quotes to `%if` expressions in spec template. Required by > rpmbuild 4.16.0 looks good - Marked as reviewed by herrick (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1551

Re: [jdk18] RFR: 8278907: JPackage test - SigningPackageTest is failed with runtime exception

On Fri, 17 Dec 2021 03:28:12 GMT, Alexander Matveev wrote: > This is regression from JDK-8263155. MacHelper.java is now calling test > verification callback with all content in DMG root. SigningPackageTest > expects only path with app name in it and thus it fails when trying to verify > app

Re: [jdk18] RFR: 8278233: [macos] tools/jpackage tests timeout due to /usr/bin/osascript

On Tue, 14 Dec 2021 06:10:51 GMT, Alexander Matveev wrote: > This is regression from JDK-8276837. exec() was passing INFINITE_TIMEOUT > instead of actual value of timeout variable. Execution of osascript was > running without timeout and thus several tests timeout. Osascript hang during >

Integrated: JDK-8276837: [macos]: Error when signing the additional launcher

On Wed, 1 Dec 2021 21:35:01 GMT, Andy Herrick wrote: > - We need to unsign all executables and libraries in the app-image before > signing. (not just those in the runtime). > - Clean up excessive output by executing the individual file sign and > unsigning commands in quiet mo

RFR: JDK-8276837: [macos]: Error when signing the additional launcher

- We need to unsign all executables and libraries in the app-image before signing. (not just those in the runtime). - Clean up excessive output by executing the individual file sign and unsigning commands in quiet mode. - Add conditions in SigningAppImageTest to test signing of additional

Re: RFR: JDK-8276837: [macos]: Error when signing the additional launcher

On Wed, 1 Dec 2021 14:25:52 GMT, Andy Herrick wrote: > Before signing, unsign all executables and libraries (not just those in > runtime). > Also, run individual file sign and unsign commands in quiet mode. > Also, add test case to SigningAppImageTest to test that signing

Withdrawn: JDK-8276837: [macos]: Error when signing the additional launcher

On Wed, 1 Dec 2021 14:25:52 GMT, Andy Herrick wrote: > Before signing, unsign all executables and libraries (not just those in > runtime). > Also, run individual file sign and unsign commands in quiet mode. > Also, add test case to SigningAppImageTest to test that signing

Re: RFR: JDK-8276837: [macos]: Error when signing the additional launcher [v2]

validly signed launcher and > additional launcher (original reported problem). Andy Herrick has updated the pull request incrementally with 85 additional commits since the last revision: - JDK-8276837: [macos]: Error when signing the additional launcher - 8277797: Remove undefined/un

Re: RFR: JDK-8276837: [macos]: Error when signing the additional launcher

On Wed, 1 Dec 2021 19:59:57 GMT, Alexey Semenyuk wrote: >> Before signing, unsign all executables and libraries (not just those in >> runtime). >> Also, run individual file sign and unsign commands in quiet mode. >> Also, add test case to SigningAppImageTest to test that signing app that has

RFR: JDK-8276837: [macos]: Error when signing the additional launcher

Before signing, unsign all executables and libraries (not just those in runtime). Also, run individual file sign and unsign commands in quiet mode. Also, add test case to SigningAppImageTest to test that signing app that has additional launcher works, and results in validly signed launcher and

Re: RFR: 8277647: [REDO] JDK-8277507 Add jlink.debug system property while launching jpackage tests to help diagonize recent intermittent failures

java code and the System Property "jlink.debug" is already set to true by then. /Andy On 11/24/2021 8:35 AM, Andy Herrick wrote: Wait - the original change, 'addArgument("-J-Djlink.debug=true");' adds "-D-J..." as a jpackage arg.  This is not a supporte

Re: RFR: 8277647: [REDO] JDK-8277507 Add jlink.debug system property while launching jpackage tests to help diagonize recent intermittent failures

Wait - the original change, 'addArgument("-J-Djlink.debug=true");' adds "-D-J..." as a jpackage arg.  This is not a supported command line option, I'm not sure why it is not throwing an error all the time, but you need to use addArgument("--java-option -Djlink.debug=true" ); instead. I'll

Re: RFR: 8277429: Conflicting jpackage static library name

On Sat, 20 Nov 2021 03:26:51 GMT, Alexey Semenyuk wrote: > 8277429: Conflicting jpackage static library name Marked as reviewed by herrick (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6485

Integrated: JDK-8276150: Quarantined jpackage apps are labeled as "damaged"

On Mon, 15 Nov 2021 19:56:28 GMT, Andy Herrick wrote: > JDK-8276150: Quarantined jpackage apps are labeled as "damaged" This pull request has now been integrated. Changeset: 936f7ff4 Author: Andy Herrick URL: https://git.openjdk.java.n

RFR: JDKJDK-8276150: Quarantined jpackage apps are labeled as "damaged"

JDKJDK-8276150: Quarantined jpackage apps are labeled as "damaged" - Commit messages: - JDKJDK-8276150: Quarantined jpackage apps are labeled as "damaged" Changes: https://git.openjdk.java.net/jdk/pull/6396/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6396=00

Re: RFR: 8276084: Linux DEB Bundler: release number in outputted .deb file should be optional

On Thu, 11 Nov 2021 04:07:18 GMT, Alexey Semenyuk wrote: > 8276084: Linux DEB Bundler: release number in outputted .deb file should be > optional Marked as reviewed by herrick (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6345

Re: RFR: 8274856: Failing jpackage tests with fastdebug/release build

On Fri, 5 Nov 2021 19:58:01 GMT, Alexey Semenyuk wrote: > The fix is to isolate C++ calls in the separate forked child process on > Linux. > This change requires the passing of JLI command line arguments and values of > environment variables between two processes. Marked as reviewed by

Integrated: JDK-8276562: Fix to JDK-8263155 left out the help text changes

On Fri, 5 Nov 2021 17:21:01 GMT, Andy Herrick wrote: > JDK-8276562: Fix to JDK-8263155 left out the help text changes This pull request has now been integrated. Changeset: 71c4b195 Author: Andy Herrick URL: https://git.openjdk.java.net/jdk/com

RFR: JDK-8276562: Fix to JDK-8263155 left out the help text changes

JDK-8276562: Fix to JDK-8263155 left out the help text changes - Commit messages: - JDK-8276562: Fix to JDK-8263155 left out the help text changes Changes: https://git.openjdk.java.net/jdk/pull/6281/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=6281=00 Issue:

Integrated: JDK-8263155: Allow additional contents for DMG

On Tue, 12 Oct 2021 16:47:04 GMT, Andy Herrick wrote: > JDK-8263155: Allow additional contents for DMG This pull request has now been integrated. Changeset: b2128a96 Author: Andy Herrick URL: https://git.openjdk.java.net/jdk/commit/b2128a96670daeca93aca84ee7613b2b337ddfa4 St

Re: RFR: JDK-8263155: Allow additional contents for DMG [v2]

> JDK-8263155: Allow additional contents for DMG Andy Herrick has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - Merge branch 'master' into JDK-8263155 - Merge branch 'master' into JDK-8263155 - JDK-8263155: Al

Integrated: 8274346: Support for additional content in an app-image.

On Thu, 30 Sep 2021 18:51:49 GMT, Andy Herrick wrote: > 8274346: Support for additional content in an app-image. This pull request has now been integrated. Changeset: d548f2fc Author: Andy Herrick URL: https://git.openjdk.java.net/jdk/commit/d548f2fc0dbc9e7864dd1701873bbf3d12a75

Re: RFR: JDK-8263155: Allow additional contents for DMG

On Tue, 12 Oct 2021 16:47:04 GMT, Andy Herrick wrote: > JDK-8263155: Allow additional contents for DMG This enhancement adds a command line option "--mac-dmg-content" that can be used to add any other content to a dmg image. The default DMGsetup.scpt is modified to show all t

RFR: JDK-8263155: Allow additional contents for DMG

JDK-8263155: Allow additional contents for DMG - Commit messages: - JDK-8263155: Allow additional contents for DMG - JDK-8263155: Allow additional contents for DMG - JDK-8263155: Allow additional contents for DMG Changes: https://git.openjdk.java.net/jdk/pull/5912/files Webrev:

Re: RFR: 8274346: Support for additional content in an app-image. [v2]

> 8274346: Support for additional content in an app-image. Andy Herrick has updated the pull request incrementally with one additional commit since the last revision: JDK-8274346: Support for additional content in an app-image. - Changes: - all: https://git.openjdk.java.

Re: RFR: 8274346: Support for additional content in an app-image.

On Thu, 30 Sep 2021 18:51:49 GMT, Andy Herrick wrote: > 8274346: Support for additional content in an app-image. CSR is at: https://bugs.openjdk.java.net/browse/JDK-8274717 - PR: https://git.openjdk.java.net/jdk/pull/5780

RFR: 8274346: Support for additional content in an app-image.

8274346: Support for additional content in an app-image. - Commit messages: - JDK-8274346: Support for additional content in an app-image. - JDK-8274346: Support for additional content in an app-image. - JDK-8274346: Support for additional content in an app-image. Changes:

Integrated: JDK-8274087: Windows DLL path not set correctly.

On Thu, 23 Sep 2021 20:03:29 GMT, Andy Herrick wrote: > JDK-8274087: Windows DLL path not set correctly. This pull request has now been integrated. Changeset: f36a2bbd Author: Andy Herrick URL: https://git.openjdk.java.net/jdk/commit/f36a2bbd15d94d4371c2117ce08b7f04a0d59da4 St

RFR: JDK-8274087: Windows DLL path not set correctly.

JDK-8274087: Windows DLL path not set correctly. - Commit messages: - JDK-8274087: Windows DLL path not set correctly. Changes: https://git.openjdk.java.net/jdk/pull/5663/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5663=00 Issue:

Re: [External] : Re: What causes java.lang.InternalError: platform encoding not initialized ?

ry path, with error: Can't find dependent libraries Module java.instrument may be missing from runtime image. /Andy On 9/22/2021 11:44 AM, Scott Palmer wrote: On Sep 22, 2021, at 11:22 AM, Andy Herrick <mailto:andy.herr...@oracle.com>> wrote: I still don't get the error your report.  Is th

Re: [External] : Re: What causes java.lang.InternalError: platform encoding not initialized ?

g.gradle.java.installations.paths=C:\Tools\jdk-17 clean build I still reproduce the error. Though the assertion in native JVM code that you are getting looks like yet another bug! So perhaps it is good that it is discovered as well. Scott On Sep 22, 2021, at 9:54 AM, Andy Herrick wrote: I can'

Re: [External] : Re: What causes java.lang.InternalError: platform encoding not initialized ?

sed (instead of the actual runtime path, which may be different) is the line in WinLauncher.cpp to call SetDllDirectory(). This should be fixed - but would like a way to reproduce the problem it causes first. /Andy On 9/21/2021 12:12 PM, Andy Herrick wrote: I thought I could create

Re: [External] : Re: What causes java.lang.InternalError: platform encoding not initialized ?

capture the new location.  If you are still having trouble reproducing I will have the code cleaned up for the bug report soon... Regards, Scott On Sep 21, 2021, at 12:12 PM, Andy Herrick <mailto:andy.herr...@oracle.com>> wrote: I thought I could create a reproduction scenario by usi

Re: [External] : Re: What causes java.lang.InternalError: platform encoding not initialized ?

I thought I could create a reproduction scenario by using an app with "-splash:" arg then moving the jre as you did, but I have not yet been able make it fail. /Andy On 9/21/2021 11:43 AM, Scott Palmer wrote: On Sep 21, 2021, at 11:40 AM, Alan Bateman wrote: On 21/09/2021 1

Re: [External] : Re: What causes java.lang.InternalError: platform encoding not initialized ?

I filed:     JDK-8274087: Windows DLL path not set correctly. for this, and will work on a fix for JDK18 and backport to JDK17.0.2. /Andy On 9/21/2021 10:54 AM, Andy Herrick wrote: I found the problem in open/src/jdk.jpackage/windows/native/applauncher/WinLauncher.cpp we call

Re: [External] : Re: What causes java.lang.InternalError: platform encoding not initialized ?

the initial deployment or run different jobs with different JREs.  I was trying to make a smaller tool/demo that used the JRE from where it would be in our "plugin" folder. Regards, Scott On Tue, Sep 21, 2021 at 9:22 AM Andy Herrick <mailto:andy.herr...@oracle.com>> wrote

Re: What causes java.lang.InternalError: platform encoding not initialized ?

I don't see anything wrong with this offhand. the runtime should be able to be anywhere if the cfg files "app.runtime" line points to it. Is this on windows ? Is the the released JDK17 used both for the jlinked runtime and the jpackage tool ? Are there any libraries in $APPDIR (which is

Re: RFR: 8272815: jpackage --type rpm produces an error: Invalid or unsupported type: [null]

On Tue, 14 Sep 2021 17:21:29 GMT, Alexey Semenyuk wrote: > Fix jpackage error output when "--type" CLI option is missing and jpackage > detects that it can't build native packages in the environment. Marked as reviewed by herrick (Reviewer). - PR:

Integrated: JDK-8273040: Turning off JpAllowDowngrades (or Upgrades)

On Tue, 14 Sep 2021 13:38:42 GMT, Andy Herrick wrote: > JDK-8273040: Turning off JpAllowDowngrades (or Upgrades) This pull request has now been integrated. Changeset: 22a7191f Author: Andy Herrick URL: https://git.openjdk.java.net/jdk/commit/22a7191f700c6966c59dcd12476f014522435

RFR: JDK-8273040: Turning off JpAllowDowngrades (or Upgrades)

JDK-8273040: Turning off JpAllowDowngrades (or Upgrades) - Commit messages: - JDK-8273040: Turning off JpAllowDowngrades (or Upgrades) - JDK-8273040: Turning off JpAllowDowngrades (or Upgrades) Changes: https://git.openjdk.java.net/jdk/pull/5509/files Webrev:

Re: RFR: 8273595: tools/jpackage tests do not work on apt-based Linux distros like Debian

On Fri, 10 Sep 2021 12:03:48 GMT, Ao Qi wrote: > A similar issue on Ubuntu has been fixed by > [JDK-8238953](https://bugs.openjdk.java.net/browse/JDK-8238953). However, > tools/jpackage tests do not work on Debian Linux or other apt-based Linux, > when rpm package is installed. This issue

[jdk17] Integrated: JDK-8273592: Backout JDK-8271868

On Fri, 10 Sep 2021 13:18:49 GMT, Andy Herrick wrote: > JDK-8271868 was pushed to JDK17 instead of jdk17u. > This change is to back it out This pull request has now been integrated. Changeset: 4afbcaf5 Author: Andy Herrick URL: https://git.openjdk.java.net/jdk17/

[jdk17] RFR: JDK-8273592: Backout JDK-8271868

JDK-8271868 was pushed to JDK17 instead of jdk17u. This change is to back it out - Commit messages: - JDK-8273592: Backout JDK-8271868 Changes: https://git.openjdk.java.net/jdk17/pull/307/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17=307=00 Issue:

[jdk17] RFR: JDK-8272639: jpackaged applications using microphone on mac

backport from jdk-18 - Commit messages: - JDK-8272639: jpackaged applications using microphone on mac Changes: https://git.openjdk.java.net/jdk17/pull/306/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17=306=00 Issue:

[jdk17] Integrated: 8271868: Warn user when using mac-sign option with unsigned app-image.

On Thu, 9 Sep 2021 16:36:44 GMT, Andy Herrick wrote: > This is a backport from JDK-18 This pull request has now been integrated. Changeset: a37254c7 Author: Andy Herrick URL: https://git.openjdk.java.net/jdk17/commit/a37254c79fa5973465d90f4b52ab88fe68016c9f Stats: 65 lines i

[jdk17] RFR: 8271868: Warn user when using mac-sign option with unsigned app-image.

This is a backport from JDK-18 - Commit messages: - JDK-8271868: Warn user when using mac-sign option with unsigned app-image. Changes: https://git.openjdk.java.net/jdk17/pull/305/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk17=305=00 Issue:

Re: [External] : Re: JPackage and ask for microphone permissions broken on OSX...

On 8/25/2021 9:40 AM, Alan Snyder wrote: On Aug 24, 2021, at 6:52 AM, Andy Herrick <mailto:andy.herr...@oracle.com>> wrote: One final thing to note, MacOS keeps track of what you have ever previously granted microphone permission to (and will never ask again) based on the ma

Integrated: JDK-8272639: jpackaged applications using microphone on mac

On Thu, 19 Aug 2021 14:12:00 GMT, Andy Herrick wrote: > JDK-8272639: jpackaged applications using microphone on mac This pull request has now been integrated. Changeset: b17b821a Author: Andy Herrick URL: https://git.openjdk.java.net/jdk/com

Re: JPackage and ask for microphone permissions broken on OSX...

removed. /Andy Thank You, Ben S. Date: Wed, 18 Aug 2021 08:43:08 -0400 From: Andy Herrick To: core-libs-dev@openjdk.java.net Subject: Re: JPackage and ask for microphone permissions broken on OSX... Message-ID: <1534b02b-262a-f338-aae5-d1693d007...@oracle.com> Content-Type: text/plain;

Re: RFR: JDK-8272639: jpackaged applications using microphone on mac [v2]

> JDK-8272639: jpackaged applications using microphone on mac Andy Herrick has updated the pull request incrementally with one additional commit since the last revision: JDK-8272639: jpackaged applications using microphone on mac - Changes: - all: https://git.openjdk.java.

Re: RFR: JDK-8272639: jpackaged applications using microphone on mac

On Thu, 19 Aug 2021 22:46:18 GMT, Sergey Bylokhov wrote: >> JDK-8272639: jpackaged applications using microphone on mac > > src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/Info-lite.plist.template > line 37: > >> 35: true >> 36: NSMicrophoneUsageDescription >> 37: The

RFR: JDK-8272639: jpackaged applications using microphone on mac

JDK-8272639: jpackaged applications using microphone on mac - Commit messages: - JDK-8272639: jpackaged applications using microphone on mac Changes: https://git.openjdk.java.net/jdk/pull/5186/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5186=00 Issue:

Re: JPackage and ask for microphone permissions broken on OSX...

OK - I have reproduced this problem, filed an issue, and found the fix. You can see the issue in https://bugs.openjdk.java.net/browse/JDK-8272639. Basically another key is needed in application plist to cause application to ask for microphone access. It is far to late to get any fix into

Re: RFR: 8272328: java.library.path is not set properly by Windows jpackage app launcher

On Wed, 11 Aug 2021 17:52:57 GMT, Alexey Semenyuk wrote: > Restart window app launcher to make changes made to `PATH` env variable > visible to JLI code in > https://github.com/openjdk/jdk/blob/master/src/hotspot/os/windows/os_windows.cpp#L347 Marked as reviewed by herrick (Reviewer).

Re: RFR: 8271170: Add unit test for what jpackage app launcher puts in the environment [v2]

On Mon, 9 Aug 2021 18:19:03 GMT, Alexey Semenyuk wrote: >> Added jtreg test to verify jpackage launcher adds app dir to >> `java.library.path` system property. >> Removed unused test/jdk/tools/jpackage/apps/installer/Hello.java. >> Moved test/jdk/tools/jpackage/apps/image/Hello.java to >>

Integrated: 8271868: Warn user when using mac-sign option with unsigned app-image.

On Wed, 4 Aug 2021 20:00:37 GMT, Andy Herrick wrote: > 8271868: Warn user when using mac-sign option with unsigned app-image. This pull request has now been integrated. Changeset: 0aca4f72 Author: Andy Herrick URL: https://git.openjdk.java.net/jdk/com

Re: RFR: 8271868: Warn user when using mac-sign option with unsigned app-image. [v2]

On Thu, 5 Aug 2021 17:07:13 GMT, Andy Herrick wrote: >> 8271868: Warn user when using mac-sign option with unsigned app-image. > > Andy Herrick has updated the pull request incrementally with one additional > commit since the last revision: > > JDK-8271868: Warn use

Re: RFR: 8271868: Warn user when using mac-sign option with unsigned app-image. [v2]

On Thu, 5 Aug 2021 17:07:13 GMT, Andy Herrick wrote: >> 8271868: Warn user when using mac-sign option with unsigned app-image. > > Andy Herrick has updated the pull request incrementally with one additional > commit since the last revision: > > JDK-8271868: Warn use

Re: RFR: 8271868: Warn user when using mac-sign option with unsigned app-image. [v2]

> 8271868: Warn user when using mac-sign option with unsigned app-image. Andy Herrick has updated the pull request incrementally with one additional commit since the last revision: JDK-8271868: Warn user when using mac-sign option with unsigned app-image. - Changes: -

Re: RFR: 8271868: Warn user when using mac-sign option with unsigned app-image.

On Wed, 4 Aug 2021 20:56:46 GMT, Alexander Matveev wrote: >> 8271868: Warn user when using mac-sign option with unsigned app-image. > > src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacBaseInstallerBundler.java > line 142: > >> 140: // is not allready signed. >> 141:

Re: RFR: 8271868: Warn user when using mac-sign option with unsigned app-image.

On Wed, 4 Aug 2021 20:00:37 GMT, Andy Herrick wrote: > 8271868: Warn user when using mac-sign option with unsigned app-image. The purpose of this change is to catch the case (and emit a warning) when user creates an app-image w/o using --mac-sign, and then uses that app image to build a

RFR: 8271868: Warn user when using mac-sign option with unsigned app-image.

8271868: Warn user when using mac-sign option with unsigned app-image. - Commit messages: - JDK-8271868: Warn user when using mac-sign option with unsigned app-image. - JDK-8271868: Warn user when using mac-sign option with unsigned app-image. - JDK-8271868: Warn user when using

Integrated: JDK-8271344: Windows product version issue

On Mon, 2 Aug 2021 13:45:17 GMT, Andy Herrick wrote: > JDK-8271344: Windows product version issue This pull request has now been integrated. Changeset: 0199b03e Author: Andy Herrick URL: https://git.openjdk.java.net/jdk/commit/0199b03eb3bd9ffe79b5193ff1792144b5c488f1 Stats:

Re: [External] : Re: jpackage MacOS Notarization

OK - took me a while to see what you are doing. The problem is you are signing the pkg but building it from an unsigned app-image. If you are building in two phases (app-image, then installer package) you need the --mac-sign option on both phases. /Andy On 8/3/2021 10:37 AM, Andy Herrick

Re: [External] : Re: jpackage MacOS Notarization

d to add your credentials which I do not know. Hope this clarifies things, -- Daniel On Thu, Jul 29, 2021 at 3:29 PM Andy Herrick mailto:andy.herr...@oracle.com>> wrote: The 'build.gradle' in this branch has --mac-signing-key-user-

RFR: JDK-8271344: Windows product version issue

JDK-8271344: Windows product version issue - Commit messages: - JDK-8271344: Windows product version issue Changes: https://git.openjdk.java.net/jdk/pull/4958/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4958=00 Issue:

Re: [External] : Re: jpackage MacOS Notarization

not know. Hope this clarifies things, -- Daniel On Thu, Jul 29, 2021 at 3:29 PM Andy Herrick <mailto:andy.herr...@oracle.com>> wrote: The 'build.gradle' in this branch has --mac-signing-key-user-name commented out.     installerOptions += [   

Re: [External] : Re: jpackage MacOS Notarization

The 'build.gradle' in this branch has --mac-signing-key-user-name commented out.     installerOptions += [     '--mac-sign',     // '--mac-s'SIGNING_KEY_USER_NAME'igning-key-user-name', System.getenv('SIGNING_KEY_USER_NAME'),     //

Re: jpackage MacOS Notarization

Not really enough info given here to act on.  Exactly what java version/build are you using?   As Kevin suggested it best to try JDK17 EA first, but I can notarize simple test app with JDK16 , staple the notarization, and then download it and run it on other machines without the quarantine

Re: [jdk17] RFR: 8271155: Wrong path separator in env variable

On Thu, 22 Jul 2021 19:35:59 GMT, Alexey Semenyuk wrote: > Replace `";"` with `FileUtils::pathSeparator` in the expression adding 'app' > dir to env variable in jpackage app launcher. Marked as reviewed by herrick (Reviewer). - PR: https://git.openjdk.java.net/jdk17/pull/271

Re: jpackage on MacOS - ./Contents/Contents/app/myapp.cfg file not found

Looks like an instance of: JDK-8260335 : [macos] Running app using relative path causes problems (fixed in jdk17 build b09) you can try builds from https://jdk.java.net/17/ to confirm fix. /Andy On 7/21/2021 4:46 PM, Bruno Borges wrote: Hi

Integrated: JDK-8269387: jpackage --add-launcher should have option to not create shortcuts for additional launchers

On Thu, 8 Jul 2021 19:25:33 GMT, Andy Herrick wrote: > JDK-8269387: jpackage --add-launcher should have option to not create > shortcuts for additional launchers This pull request has now been integrated. Changeset: 057992f2 Author: Andy Herrick URL: https://git.openjdk.ja

Re: RFR: JDK-8269387: jpackage --add-launcher should have option to not create shortcuts for additional launchers [v4]

> JDK-8269387: jpackage --add-launcher should have option to not create > shortcuts for additional launchers Andy Herrick has updated the pull request incrementally with one additional commit since the last revision: JDK-8269387: jpackage --add-launcher should have option to not

Re: RFR: JDK-8269387: jpackage --add-launcher should have option to not create shortcuts for additional launchers [v3]

> JDK-8269387: jpackage --add-launcher should have option to not create > shortcuts for additional launchers Andy Herrick has updated the pull request incrementally with one additional commit since the last revision: JDK-8269387: jpackage --add-launcher should have option to not

Re: RFR: JDK-8269387: jpackage --add-launcher should have option to not create shortcuts for additional launchers [v2]

> JDK-8269387: jpackage --add-launcher should have option to not create > shortcuts for additional launchers Andy Herrick has updated the pull request incrementally with one additional commit since the last revision: JDK-8269387: jpackage --add-launcher should have option to not

RFR: JDK-8269387: jpackage --add-launcher should have option to not create shortcuts for additional launchers

JDK-8269387: jpackage --add-launcher should have option to not create shortcuts for additional launchers - Commit messages: - JDK-8269387: jpackage --add-launcher should have option to not create shortcuts for additional launchers - JDK-8269387: jpackage --add-launcher should

Re: RFR: 8268974: GetJREPath() JLI function fails to locate libjava.so if not standard Java launcher is used [v3]

On Wed, 7 Jul 2021 18:54:23 GMT, Alexey Semenyuk wrote: >> GetApplicationHomeFromDll() fails if the path to libjli.so contains "bin" >> component (/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so). TruncatePath() >> looks for "/bin/" first in "/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so" >>

Re: [jdk17] RFR: 8269185: Directories in /opt/runtimepackagetest and /path/to/jdk-17 are different

On Fri, 2 Jul 2021 22:17:09 GMT, Alexey Semenyuk wrote: > Disable stripping to prevent rpmbuild from modifying executables Marked as reviewed by herrick (Reviewer). - PR: https://git.openjdk.java.net/jdk17/pull/207

Re: [jdk17] RFR: 8269403: Fix jpackage tests to gracefully handle jpackage app launcher crashes

On Fri, 25 Jun 2021 22:41:10 GMT, Alexey Semenyuk wrote: > jpackage app launcher randomly crashes JVM at termination in EMS enabled JDK > builds. > Until the root cause of the issue is understood and fixed let's add a > workaround to jpackage tests to run test app few more times if the first

Re: [jdk17] RFR: 8269036: tools/jpackage/share/AppImagePackageTest.java failed with "hdiutil: create failed - Resource busy"

On Tue, 22 Jun 2021 21:59:43 GMT, Alexander Matveev wrote: > Looks like another "Resource busy" issue similar to recent fixes for "hdiutil > convert" and "hdiutil detach". Workaround in same way by repeating "create" > command. Modified RetryExecutor to pass write to file flag, otherwise >

[jdk17] Integrated: JDK-8268404: [TESTBUG] tools/jpackage/windows/WinInstallerIconTest.java failed "AssertionError: Failed: Check icon"

On Mon, 21 Jun 2021 20:21:58 GMT, Andy Herrick wrote: > …t.java failed "AssertionError: Failed: Check icon" This pull request has now been integrated. Changeset: 35e4c272 Author: Andy Herrick URL: https://git.openjdk.java.net/jdk17/commit/35e4c2720df64ea6cb68ba8fb62

Re: [jdk17] RFR: JDK-8268404: [TESTBUG] tools/jpackage/windows/WinInstallerIconTest.java failed "AssertionError: Failed: Check icon" [v2]

On Mon, 21 Jun 2021 22:56:32 GMT, Andy Herrick wrote: >> test/jdk/tools/jpackage/windows/WinInstallerIconTest.java line 75: >> >>> 73: >>> 74: // Create another installer with custom icon. >>> 75: long size3 = createInstaller(customIc

Re: [jdk17] RFR: JDK-8268404: [TESTBUG] tools/jpackage/windows/WinInstallerIconTest.java failed "AssertionError: Failed: Check icon" [v2]

> …t.java failed "AssertionError: Failed: Check icon" Andy Herrick has updated the pull request incrementally with one additional commit since the last revision: JDK-8268404: [TESTBUG] tools/jpackage/windows/WinInstallerIconTest.java failed "AssertionError:

Re: [jdk17] RFR: JDK-8268404: [TESTBUG] tools/jpackage/windows/WinInstallerIconTest.java failed "AssertionError: Failed: Check icon"

On Mon, 21 Jun 2021 20:42:54 GMT, Alexey Semenyuk wrote: >> …t.java failed "AssertionError: Failed: Check icon" > > test/jdk/tools/jpackage/windows/WinInstallerIconTest.java line 75: > >> 73: >> 74: // Create another installer with custom icon. >> 75: long size3 =

[jdk17] RFR: JDK-8268404: [TESTBUG] tools/jpackage/windows/WinInstallerIconTest.java failed "AssertionError: Failed: Check icon"

…t.java failed "AssertionError: Failed: Check icon" - Commit messages: - JDK-8268404: [TESTBUG] tools/jpackage/windows/WinInstallerIconTest.java failed "AssertionError: Failed: Check icon" Changes: https://git.openjdk.java.net/jdk17/pull/111/files Webrev:

Re: RFR: 8268974: jpackage fails to handle --dest option containing "bin" folder

On Fri, 18 Jun 2021 22:46:24 GMT, Alexey Semenyuk wrote: > GetApplicationHomeFromDll() fails if the path to libjli.so contains "bin" > component (/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so). TruncatePath() > looks for "/bin/" first in "/tmp/bin/HelloWorld/lib/runtime/lib/libjli.so" >

Re: [jdk17] RFR: 8268971: ProblemList tools/jpackage/windows/WinInstallerIconTest.java on win-x64

On Thu, 17 Jun 2021 16:32:52 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList tools/jpackage/windows/WinInstallerIconTest.java > on win-x64. Marked as reviewed by herrick (Reviewer). - PR: https://git.openjdk.java.net/jdk17/pull/90

Integrated: JDK-8267764: jpackage cannot handle window screensaver files when EXE renamed as SCR

On Wed, 2 Jun 2021 13:48:47 GMT, Andy Herrick wrote: > JDK-8267764: jpackage cannot handle window screensaver files when EXE renamed > as SCR This pull request has now been integrated. Changeset: 51e8201e Author: Andy Herrick URL: https://git.openjdk.java.net/jdk/

Re: RFR: 8264144: Add handling of "--about-url" CLI parameter for RPM/DEB packages [v2]

On Tue, 8 Jun 2021 17:25:46 GMT, Alexey Semenyuk wrote: >> …ages > > Alexey Semenyuk has updated the pull request with a new target base due to a > merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains two

Re: RFR: JDK-8267764: jpackage cannot handle window screensaver files when EXE renamed as SCR [v2]

> JDK-8267764: jpackage cannot handle window screensaver files when EXE renamed > as SCR Andy Herrick has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request co

Re: RFR: JDK-8267764: jpackage cannot handle window screensaver files when EXE renamed as SCR

On Wed, 2 Jun 2021 13:48:47 GMT, Andy Herrick wrote: > JDK-8267764: jpackage cannot handle window screensaver files when EXE renamed > as SCR as suggested added a simple test to verify an app on windows can continue to run after ".exe" is renamed to any other extension -

Integrated: JDK-8267598: jpackage removes system libraries from java.library.path

On Wed, 26 May 2021 11:26:24 GMT, Andy Herrick wrote: > JDK-8267598: jpackage removes system libraries from java.library.path This pull request has now been integrated. Changeset: af3df630 Author: Andy Herrick URL: https://git.openjdk.java.net/jdk/com

Re: RFR: JDK-8267598: jpackage removes system libraries from java.library.path [v2]

> JDK-8267598: jpackage removes system libraries from java.library.path Andy Herrick has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additio

Re: RFR: JDK-8268150: tier2: test/jdk/tools/jpackage/junit/junit.java needs updating for jtreg 6

On Thu, 3 Jun 2021 00:47:45 GMT, Jonathan Gibbons wrote: > Please review a small test fix, to include hamcrest.jar, as required by the > latest version of JUnit in jtreg 6. looks fine - PR: https://git.openjdk.java.net/jdk/pull/4328

RFR: JDK-8267764: jpackage cannot handle window screensaver files when EXE renamed as SCR

JDK-8267764: jpackage cannot handle window screensaver files when EXE renamed as SCR - Commit messages: - JDK-8267764: jpackage cannot handle window screensaver files when EXE renamed as SCR Changes: https://git.openjdk.java.net/jdk/pull/4306/files Webrev:

RFR: JDK-8267598: jpackage removes system libraries from java.library.path

JDK-8267598: jpackage removes system libraries from java.library.path - Commit messages: - JDK-8267598: jpackage removes system libraries from java.library.path - JDK-8267598: jpackage removes system libraries from java.library.path - JDK-8267598: jpackage removes system libraries

Re: RFR: 8267403: tools/jpackage/share/FileAssociationsTest.java#id0 failed with "Error: Bundler "Mac PKG Package" (pkg) failed to produce a package"

On Fri, 21 May 2021 04:34:22 GMT, Alexander Matveev wrote: > Looks like another issue similar to hdiutil (JDK-8249395) when process is > gone, but we still waiting for it. I was not able to reproduce this issue by > running test or pkgbuild separately and conclusion was made based on logs. >

Integrated: JDK-8267423: Fix copyrights in jpackage tests

On Fri, 21 May 2021 12:22:16 GMT, Andy Herrick wrote: > JDK-8267423: Fix copyrights in jpackage tests This pull request has now been integrated. Changeset: a5467ae7 Author: Andy Herrick URL: https://git.openjdk.java.net/jdk/commit/a5467ae7bb5780f34728ad073c5c4158894c7c4b St

RFR: JDK-8267423: Fix copyrights in jpackage tests

JDK-8267423: Fix copyrights in jpackage tests - Commit messages: - JDK-8267423: Fix copyrights in jpackage tests - JDK-8267423: Fix copyrights in jpackage tests - JDK-8267423: Fix copyrights in jpackage tests - JDK-8267423: Fix copyrights in jpackage tests Changes:

Re: RFR: 8267056: tools/jpackage/share/RuntimePackageTest.java fails with NoSuchFileException [v2]

On Thu, 20 May 2021 22:25:10 GMT, Alexander Matveev wrote: >> For debug build on macOS, runtime which used for test fill be located in >> /path/jdk-17/fastdebug and /path/jdk-17 will not contain any other files >> except fastdebug and in this case our check to decide if we need to copy app

  1   2   3   4   5   6   7   8   9   >