Re: [8]: help on PKCS#11 tests build
There are 6 dlls in the test directory ./jdk/test/sun/security/pkcs11/nss/lib/windows-i586/libnspr4.dll ./jdk/test/sun/security/pkcs11/nss/lib/windows-i586/libplc4.dll ./jdk/test/sun/security/pkcs11/nss/lib/windows-i586/libplds4.dll ./jdk/test/sun/security/pkcs11/nss/lib/windows-i586/nss3.dll ./jdk/test/sun/security/pkcs11/nss/lib/windows-i586/nssckbi.dll ./jdk/test/sun/security/pkcs11/nss/lib/windows-i586/softokn3.dll Francis Le 05/12/2013 03:16, Bradford Wetmore a écrit : IIRC, and in case it wasn't clear from reading the responses, the permission changes are done by the Makefiles (e.g. jdk/test/Makefile:193), and not by JTREG itself. I agree with Jon's comment, perhaps a .dll copy to the temporary working directory is in order. That would save people trying to figure out why their tests are failing when running under a .hg directory with the makefiles, or when using JTREG directly. I'm not sure how many .dlls there are in the test dirs (including closed where most probably live), but should probably be done all together instead of by functional area. Brad On 12/4/2013 10:40 AM, Jonathan Gibbons wrote: It should also be the case that the tests should run if the entire test/ directory (all files and directories) were readonly, so if code is modifying files in place or creating new files anywhere in the test directory, that should be regarded as a Bad Thing and fixed. -- Jon On 12/04/2013 10:27 AM, Francis ANDRE wrote: Agreed with Magnus the setting of the executable bits should be made explicitly somewhere to avoid such error... Francis Le 04/12/2013 19:05, Magnus Ihse Bursie a écrit : So at least you find a likely cause for the issues Francis are seeing. :) It feels a bit weird juggling around with permissions like that, but maybe there was no clear use-case for running this from hg? /Magnus 4 dec 2013 kl. 16:38 skrev Mike Duigou : On Dec 4 2013, at 06:06 , Magnus Ihse Bursie wrote: On 2013-11-22 10:12, Mike Duigou wrote: the jdk/test/Makefile is normally responsible for setting the executable flags on those files but only does so before running the tests. If you are executing jtreg directly then the files aren't being made executable. Hm, are you saying jtreg is setting executable flags for file in the hg repo? Isn't that a risk that it will be checked in if you're not careful? I just checked and discovered that the executable bits setting is done only if the hg directory is absent. So setting the executable bits is likely only being done only on oracle's internal test machines which get their test source as a tarball rather than via an hg clone. I am not familiar enough with the history to know what is expected to happen when tests are run from an hg clone. It looks like the choices are to temporarily or permanently set the executable flags to allow the tests to run. Mike /Magnus Mike On Nov 21 2013, at 20:49 , Francis ANDRE wrote: Hi Running TestInterop from the PKCS#11 test suite on a WXP/Cygwin/VS2010 platform, one gets this exception Caused by: java.io.IOException: Accès refusé.Z:\JDK\jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\softokn3.dll This exception appears because all dlls in the directory jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\ are not executable. I looked at the various makefile for fixing this issue but did not found a relevant makefile. In which makefile(s) those dlls like softtokn3.dll are build/copied ? Francis Beginning test run TestInterop... Exception in thread "main" java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java: 57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorIm pl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:408) at PKCS11Test.getSunPKCS11(PKCS11Test.java:70) at PKCS11Test.testNSS(PKCS11Test.java:356) at PKCS11Test.main(PKCS11Test.java:89) at TestInterop.main(TestInterop.java:141) Caused by: java.security.ProviderException: Initialization failed at sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:376) at sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:103) ... 8 more Caused by: java.io.IOException: Accès refusé. Z:\JDK\jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\softokn3.dll at sun.security.pkcs11.wrapper.PKCS11.connect(Native Method) at sun.security.pkcs11.wrapper.PKCS11.(PKCS11.java:138) at sun.security.pkcs11.wrapper.PKCS11.getInstance(PKCS11.java:151) at sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:313) ... 9 more
How to create PDB files
Hi, How do I get a debug build to create PDB debug symbol files? -Pete
DIZ files
For each DLL built I also see a DIZ file. What are those? -Pete
Re: [8]: help on PKCS#11 tests build
IIRC, and in case it wasn't clear from reading the responses, the permission changes are done by the Makefiles (e.g. jdk/test/Makefile:193), and not by JTREG itself. I agree with Jon's comment, perhaps a .dll copy to the temporary working directory is in order. That would save people trying to figure out why their tests are failing when running under a .hg directory with the makefiles, or when using JTREG directly. I'm not sure how many .dlls there are in the test dirs (including closed where most probably live), but should probably be done all together instead of by functional area. Brad On 12/4/2013 10:40 AM, Jonathan Gibbons wrote: It should also be the case that the tests should run if the entire test/ directory (all files and directories) were readonly, so if code is modifying files in place or creating new files anywhere in the test directory, that should be regarded as a Bad Thing and fixed. -- Jon On 12/04/2013 10:27 AM, Francis ANDRE wrote: Agreed with Magnus the setting of the executable bits should be made explicitly somewhere to avoid such error... Francis Le 04/12/2013 19:05, Magnus Ihse Bursie a écrit : So at least you find a likely cause for the issues Francis are seeing. :) It feels a bit weird juggling around with permissions like that, but maybe there was no clear use-case for running this from hg? /Magnus 4 dec 2013 kl. 16:38 skrev Mike Duigou : On Dec 4 2013, at 06:06 , Magnus Ihse Bursie wrote: On 2013-11-22 10:12, Mike Duigou wrote: the jdk/test/Makefile is normally responsible for setting the executable flags on those files but only does so before running the tests. If you are executing jtreg directly then the files aren't being made executable. Hm, are you saying jtreg is setting executable flags for file in the hg repo? Isn't that a risk that it will be checked in if you're not careful? I just checked and discovered that the executable bits setting is done only if the hg directory is absent. So setting the executable bits is likely only being done only on oracle's internal test machines which get their test source as a tarball rather than via an hg clone. I am not familiar enough with the history to know what is expected to happen when tests are run from an hg clone. It looks like the choices are to temporarily or permanently set the executable flags to allow the tests to run. Mike /Magnus Mike On Nov 21 2013, at 20:49 , Francis ANDRE wrote: Hi Running TestInterop from the PKCS#11 test suite on a WXP/Cygwin/VS2010 platform, one gets this exception Caused by: java.io.IOException: Accès refusé.Z:\JDK\jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\softokn3.dll This exception appears because all dlls in the directory jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\ are not executable. I looked at the various makefile for fixing this issue but did not found a relevant makefile. In which makefile(s) those dlls like softtokn3.dll are build/copied ? Francis Beginning test run TestInterop... Exception in thread "main" java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java: 57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorIm pl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:408) at PKCS11Test.getSunPKCS11(PKCS11Test.java:70) at PKCS11Test.testNSS(PKCS11Test.java:356) at PKCS11Test.main(PKCS11Test.java:89) at TestInterop.main(TestInterop.java:141) Caused by: java.security.ProviderException: Initialization failed at sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:376) at sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:103) ... 8 more Caused by: java.io.IOException: Accès refusé. Z:\JDK\jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\softokn3.dll at sun.security.pkcs11.wrapper.PKCS11.connect(Native Method) at sun.security.pkcs11.wrapper.PKCS11.(PKCS11.java:138) at sun.security.pkcs11.wrapper.PKCS11.getInstance(PKCS11.java:151) at sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:313) ... 9 more
Re: [8]: help on PKCS#11 tests build
It should also be the case that the tests should run if the entire test/ directory (all files and directories) were readonly, so if code is modifying files in place or creating new files anywhere in the test directory, that should be regarded as a Bad Thing and fixed. -- Jon On 12/04/2013 10:27 AM, Francis ANDRE wrote: Agreed with Magnus the setting of the executable bits should be made explicitly somewhere to avoid such error... Francis Le 04/12/2013 19:05, Magnus Ihse Bursie a écrit : So at least you find a likely cause for the issues Francis are seeing. :) It feels a bit weird juggling around with permissions like that, but maybe there was no clear use-case for running this from hg? /Magnus 4 dec 2013 kl. 16:38 skrev Mike Duigou : On Dec 4 2013, at 06:06 , Magnus Ihse Bursie wrote: On 2013-11-22 10:12, Mike Duigou wrote: the jdk/test/Makefile is normally responsible for setting the executable flags on those files but only does so before running the tests. If you are executing jtreg directly then the files aren't being made executable. Hm, are you saying jtreg is setting executable flags for file in the hg repo? Isn't that a risk that it will be checked in if you're not careful? I just checked and discovered that the executable bits setting is done only if the hg directory is absent. So setting the executable bits is likely only being done only on oracle's internal test machines which get their test source as a tarball rather than via an hg clone. I am not familiar enough with the history to know what is expected to happen when tests are run from an hg clone. It looks like the choices are to temporarily or permanently set the executable flags to allow the tests to run. Mike /Magnus Mike On Nov 21 2013, at 20:49 , Francis ANDRE wrote: Hi Running TestInterop from the PKCS#11 test suite on a WXP/Cygwin/VS2010 platform, one gets this exception Caused by: java.io.IOException: Accès refusé.Z:\JDK\jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\softokn3.dll This exception appears because all dlls in the directory jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\ are not executable. I looked at the various makefile for fixing this issue but did not found a relevant makefile. In which makefile(s) those dlls like softtokn3.dll are build/copied ? Francis Beginning test run TestInterop... Exception in thread "main" java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java: 57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorIm pl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:408) at PKCS11Test.getSunPKCS11(PKCS11Test.java:70) at PKCS11Test.testNSS(PKCS11Test.java:356) at PKCS11Test.main(PKCS11Test.java:89) at TestInterop.main(TestInterop.java:141) Caused by: java.security.ProviderException: Initialization failed at sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:376) at sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:103) ... 8 more Caused by: java.io.IOException: Accès refusé. Z:\JDK\jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\softokn3.dll at sun.security.pkcs11.wrapper.PKCS11.connect(Native Method) at sun.security.pkcs11.wrapper.PKCS11.(PKCS11.java:138) at sun.security.pkcs11.wrapper.PKCS11.getInstance(PKCS11.java:151) at sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:313) ... 9 more
Re: RFR: JDK-8029512 : webrev.ksh: fix parsing of parent repo paths from hgrc file
OK, I will revise to use a variant of this awk line.
Mike
On Dec 4 2013, at 04:28 , Dave Pointon wrote:
> Oooops ,
>
> On Wed, 2013-12-04 at 11:48 +, Dave Pointon wrote:
>
>>
>> I concur with you Erik, character classes are only proven to work
>> with/in perl 5 across all platforms. I suggest that the need to parse
>> whitespace can be eliminated entirely by using awk(1) with a
>> field-delimiter of '=' thus realizing a simpler solution all together,
>> viz ...
>>
>> if [[ -z "$OUTPWS" ]]; then
>>OUTPWS=`awk -F'=' '/^default(-push)/{print $NF}' .hg/hgrc ||
>> $FILTER`
>> fi
>>
>>
>> Rgds ,
>>
>
> With the benefit of hindsight, the above isn't quite correct since the
> printed value will retain any leading whitespace, so it s/b ...
>
> if [[ -z "$OUTPWS" ]]; then
> OUTPWS=`awk -F'=' '/^default(-push)?/{sub(/^\t */,'',$NF);print
> $NF}' .hg/hgrc || $FILTER`
> fi
>
> Note the additional use of sub() to strip leading whitespace from the
> path before printing it.
>
> Rgds ,
>
> --
> Dave Pointon FIAP MBCS
>
> Now I saw, tho' too late, the folly of beginning a work before we count
> the cost and before we we judge rightly of our strength to go thro'
> with it - Robinson Crusoe
>
Re: [8]: help on PKCS#11 tests build
Agreed with Magnus the setting of the executable bits should be made explicitly somewhere to avoid such error... Francis Le 04/12/2013 19:05, Magnus Ihse Bursie a écrit : So at least you find a likely cause for the issues Francis are seeing. :) It feels a bit weird juggling around with permissions like that, but maybe there was no clear use-case for running this from hg? /Magnus 4 dec 2013 kl. 16:38 skrev Mike Duigou : On Dec 4 2013, at 06:06 , Magnus Ihse Bursie wrote: On 2013-11-22 10:12, Mike Duigou wrote: the jdk/test/Makefile is normally responsible for setting the executable flags on those files but only does so before running the tests. If you are executing jtreg directly then the files aren't being made executable. Hm, are you saying jtreg is setting executable flags for file in the hg repo? Isn't that a risk that it will be checked in if you're not careful? I just checked and discovered that the executable bits setting is done only if the hg directory is absent. So setting the executable bits is likely only being done only on oracle's internal test machines which get their test source as a tarball rather than via an hg clone. I am not familiar enough with the history to know what is expected to happen when tests are run from an hg clone. It looks like the choices are to temporarily or permanently set the executable flags to allow the tests to run. Mike /Magnus Mike On Nov 21 2013, at 20:49 , Francis ANDRE wrote: Hi Running TestInterop from the PKCS#11 test suite on a WXP/Cygwin/VS2010 platform, one gets this exception Caused by: java.io.IOException: Accès refusé.Z:\JDK\jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\softokn3.dll This exception appears because all dlls in the directory jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\ are not executable. I looked at the various makefile for fixing this issue but did not found a relevant makefile. In which makefile(s) those dlls like softtokn3.dll are build/copied ? Francis Beginning test run TestInterop... Exception in thread "main" java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java: 57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorIm pl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:408) at PKCS11Test.getSunPKCS11(PKCS11Test.java:70) at PKCS11Test.testNSS(PKCS11Test.java:356) at PKCS11Test.main(PKCS11Test.java:89) at TestInterop.main(TestInterop.java:141) Caused by: java.security.ProviderException: Initialization failed at sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:376) at sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:103) ... 8 more Caused by: java.io.IOException: Accès refusé. Z:\JDK\jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\softokn3.dll at sun.security.pkcs11.wrapper.PKCS11.connect(Native Method) at sun.security.pkcs11.wrapper.PKCS11.(PKCS11.java:138) at sun.security.pkcs11.wrapper.PKCS11.getInstance(PKCS11.java:151) at sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:313) ... 9 more
Re: [8]: help on PKCS#11 tests build
So at least you find a likely cause for the issues Francis are seeing. :) It feels a bit weird juggling around with permissions like that, but maybe there was no clear use-case for running this from hg? /Magnus > 4 dec 2013 kl. 16:38 skrev Mike Duigou : > > >> On Dec 4 2013, at 06:06 , Magnus Ihse Bursie >> wrote: >> >>> On 2013-11-22 10:12, Mike Duigou wrote: >>> the jdk/test/Makefile is normally responsible for setting the executable >>> flags on those files but only does so before running the tests. If you are >>> executing jtreg directly then the files aren't being made executable. >> >> Hm, are you saying jtreg is setting executable flags for file in the hg >> repo? Isn't that a risk that it will be checked in if you're not careful? > > I just checked and discovered that the executable bits setting is done only > if the hg directory is absent. So setting the executable bits is likely only > being done only on oracle's internal test machines which get their test > source as a tarball rather than via an hg clone. > > I am not familiar enough with the history to know what is expected to happen > when tests are run from an hg clone. It looks like the choices are to > temporarily or permanently set the executable flags to allow the tests to run. > > Mike > >> /Magnus >> >>> >>> Mike >>> On Nov 21 2013, at 20:49 , Francis ANDRE wrote: Hi Running TestInterop from the PKCS#11 test suite on a WXP/Cygwin/VS2010 platform, one gets this exception Caused by: java.io.IOException: Accès refusé.Z:\JDK\jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\softokn3.dll This exception appears because all dlls in the directory jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\ are not executable. I looked at the various makefile for fixing this issue but did not found a relevant makefile. In which makefile(s) those dlls like softtokn3.dll are build/copied ? Francis Beginning test run TestInterop... Exception in thread "main" java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java: 57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorIm pl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:408) at PKCS11Test.getSunPKCS11(PKCS11Test.java:70) at PKCS11Test.testNSS(PKCS11Test.java:356) at PKCS11Test.main(PKCS11Test.java:89) at TestInterop.main(TestInterop.java:141) Caused by: java.security.ProviderException: Initialization failed at sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:376) at sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:103) ... 8 more Caused by: java.io.IOException: Accès refusé. Z:\JDK\jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\softokn3.dll at sun.security.pkcs11.wrapper.PKCS11.connect(Native Method) at sun.security.pkcs11.wrapper.PKCS11.(PKCS11.java:138) at sun.security.pkcs11.wrapper.PKCS11.getInstance(PKCS11.java:151) at sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:313) ... 9 more >
Re: RFR: JDK-8029512 : webrev.ksh: fix parsing of parent repo paths from hgrc file
On Dec 4 2013, at 09:25 , Dmitry Samersoff wrote: > Mike, > > Do you thing hg path default and hg path default-push is still buggy? I > think it's better to use hg when possible. I suspect the bug was fixed at some point (It works on the 2.2 and 1.9 versions I tried) but I can't be certain that it won't still be broken on some versions The problem is that some Solaris 10 machines are still running hg 0.95 (ugh!) and other systems are running versions 1.1-1.3. > > Also, you can replace part before = to just .* like > > sed -n -e '/^default/s/.*=[\s\t]*\(.*\)$/\1/p' Heh, it would seem that for every sed expression has a more concise form that does the same thing! Mike > > -Dmitry > > > On 2013-12-04 09:16, Mike Duigou wrote: >> Hello all; >> >> This change addresses a problem discovered by Dave Pointon. >> >> http://cr.openjdk.java.net/~mduigou/JDK-8029512/0/webrev/ >> >> If the .hg/hgrc file contains (perfectly legal) spaces around the = sign of >> an assignment then the current script will fail to correctly read the path >> definition. This patch corrects the parsing of the hgrc file and also >> protects against empty results. >> >> I plan to commit this to the JDK 9 repo first but expect that it should be >> backported to JDK 8 and JDK 7 repos. >> >> Mike >> > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources.
Re: RFR: JDK-8029512 : webrev.ksh: fix parsing of parent repo paths from hgrc file
Mike, Do you thing hg path default and hg path default-push is still buggy? I think it's better to use hg when possible. Also, you can replace part before = to just .* like sed -n -e '/^default/s/.*=[\s\t]*\(.*\)$/\1/p' -Dmitry On 2013-12-04 09:16, Mike Duigou wrote: > Hello all; > > This change addresses a problem discovered by Dave Pointon. > > http://cr.openjdk.java.net/~mduigou/JDK-8029512/0/webrev/ > > If the .hg/hgrc file contains (perfectly legal) spaces around the = sign of > an assignment then the current script will fail to correctly read the path > definition. This patch corrects the parsing of the hgrc file and also > protects against empty results. > > I plan to commit this to the JDK 9 repo first but expect that it should be > backported to JDK 8 and JDK 7 repos. > > Mike > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources.
Re: RFR: JDK-8029512 : webrev.ksh: fix parsing of parent repo paths from hgrc file
On Wed, 2013-12-04 at 08:51 -0800, Kelly O'Hair wrote: > Or maybe > > tr -d '[:space:]' > > ??? > > -kto > Hmmm, not unsurprisingly, that character class usage doesn't work on Solaris either ... $ uname -a ; echo a b c | tr -d '[:space:]' ; echo a b c | tr -d ' ' SunOS duke.hursley.ibm.com 5.10 Generic_142910-17 i86pc i386 i86pc Bad string abc Rgds , -- Dave Pointon FIAP MBCS Now I saw, tho' too late, the folly of beginning a work before we count the cost and before we we judge rightly of our strength to go thro' with it - Robinson Crusoe
Re: JDK-8028531: Need review of a make change for the JAB - for a backport into 7u60
Looks good to me as well. Tim On 12/ 4/13 01:38 AM, Erik Joelsson wrote: Looks good to me. /Erik On 2013-12-03 19:02, Pete Brunet wrote: Please review the following 8 to 7u backport change for the make of the Java Access Bridge. This change was needed due to build differences between 8 and 7u. http://cr.openjdk.java.net/~ptbrunet/JDK-8028531/ The change has already been privately reviewed but an open review is also needed. Thanks, Pete
Re: RFR: JDK-8029512 : webrev.ksh: fix parsing of parent repo paths from hgrc file
Or maybe
tr -d '[:space:]'
???
-kto
On Dec 4, 2013, at 3:48 AM, Dave Pointon wrote:
> On Wed, 2013-12-04 at 10:45 +0100, Erik Joelsson wrote:
>> Hello Mike,
>>
>> I think sed on some platforms doesn't support the [[:space:]]
>> expression. I tried the line on a Solaris machine and it didn't work.
>>
>> /Erik
>>
>
>
> I concur with you Erik, character classes are only proven to work
> with/in perl 5 across all platforms. I suggest that the need to parse
> whitespace can be eliminated entirely by using awk(1) with a
> field-delimiter of '=' thus realizing a simpler solution all together,
> viz ...
>
> if [[ -z "$OUTPWS" ]]; then
>OUTPWS=`awk -F'=' '/^default(-push)/{print $NF}' .hg/hgrc ||
> $FILTER`
> fi
>
>
> Rgds ,
>
> --
> Dave Pointon FIAP MBCS
>
> Now I saw, tho' too late, the folly of beginning a work before we count
> the cost and before we we judge rightly of our strength to go thro'
> with it - Robinson Crusoe
>
Re: [8]: help on PKCS#11 tests build
On Dec 4 2013, at 06:06 , Magnus Ihse Bursie wrote: > On 2013-11-22 10:12, Mike Duigou wrote: >> the jdk/test/Makefile is normally responsible for setting the executable >> flags on those files but only does so before running the tests. If you are >> executing jtreg directly then the files aren't being made executable. > > Hm, are you saying jtreg is setting executable flags for file in the hg repo? > Isn't that a risk that it will be checked in if you're not careful? I just checked and discovered that the executable bits setting is done only if the hg directory is absent. So setting the executable bits is likely only being done only on oracle's internal test machines which get their test source as a tarball rather than via an hg clone. I am not familiar enough with the history to know what is expected to happen when tests are run from an hg clone. It looks like the choices are to temporarily or permanently set the executable flags to allow the tests to run. Mike > /Magnus > >> >> Mike >> >> On Nov 21 2013, at 20:49 , Francis ANDRE >> wrote: >> >>> Hi >>> >>> Running TestInterop from the PKCS#11 test suite on a WXP/Cygwin/VS2010 >>> platform, one gets this exception >>> >>> Caused by: java.io.IOException: Accès >>> refusé.Z:\JDK\jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\softokn3.dll >>> >>> This exception appears because all dlls in the directory >>> jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\ are not executable. >>> I looked at the various makefile for fixing this issue but did not found a >>> relevant makefile. >>> >>> In which makefile(s) those dlls like softtokn3.dll are build/copied ? >>> >>> Francis >>> >>> Beginning test run TestInterop... >>> Exception in thread "main" java.lang.reflect.InvocationTargetException >>>at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native >>> Method) >>>at >>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java: >>> 57) >>>at >>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorIm >>> pl.java:45) >>>at java.lang.reflect.Constructor.newInstance(Constructor.java:408) >>>at PKCS11Test.getSunPKCS11(PKCS11Test.java:70) >>>at PKCS11Test.testNSS(PKCS11Test.java:356) >>>at PKCS11Test.main(PKCS11Test.java:89) >>>at TestInterop.main(TestInterop.java:141) >>> Caused by: java.security.ProviderException: Initialization failed >>>at sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:376) >>>at sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:103) >>>... 8 more >>> Caused by: java.io.IOException: Accès refusé. >>> Z:\JDK\jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\softokn3.dll >>>at sun.security.pkcs11.wrapper.PKCS11.connect(Native Method) >>>at sun.security.pkcs11.wrapper.PKCS11.(PKCS11.java:138) >>>at sun.security.pkcs11.wrapper.PKCS11.getInstance(PKCS11.java:151) >>>at sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:313) >>>... 9 more >>> >
Re: Improving the management and accessibility of the handling of JDK variants
Hiya Magnus , On Wed, 2013-12-04 at 15:08 +0100, Magnus Ihse Bursie wrote: > David, > > Is this IBM variant of OpenJDK something that is publically available? > If so, I'd like to take a peek at it. > > /Magnus > I have sought advice as to the public availability and will keep you posted ... but essentially, it [the IBM OJDK variant] is based on building OpenJDK using a pre-built IBM JVM. HTH , Rgds , -- Dave Pointon FIAP MBCS Now I saw, tho' too late, the folly of beginning a work before we count the cost and before we we judge rightly of our strength to go thro' with it - Robinson Crusoe
Re: Improving the management and accessibility of the handling of JDK variants
On 2013-11-25 13:06, Dave Pointon wrote: I believe that this piece of work belongs in the infrastructure in as much as I'm merely ( :-) ) attempting to adapt the IBM JDK build and all the accompanying niceties, more into line with the OpenJDK approach such that the additional effort necessary to run the IBM variant of the OpenJDK build is minimised, if not removed entirely; David, Is this IBM variant of OpenJDK something that is publically available? If so, I'd like to take a peek at it. /Magnus
Re: [8]: help on PKCS#11 tests build
On 2013-11-22 10:12, Mike Duigou wrote: the jdk/test/Makefile is normally responsible for setting the executable flags on those files but only does so before running the tests. If you are executing jtreg directly then the files aren't being made executable. Hm, are you saying jtreg is setting executable flags for file in the hg repo? Isn't that a risk that it will be checked in if you're not careful? /Magnus Mike On Nov 21 2013, at 20:49 , Francis ANDRE wrote: Hi Running TestInterop from the PKCS#11 test suite on a WXP/Cygwin/VS2010 platform, one gets this exception Caused by: java.io.IOException: Accès refusé.Z:\JDK\jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\softokn3.dll This exception appears because all dlls in the directory jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\ are not executable. I looked at the various makefile for fixing this issue but did not found a relevant makefile. In which makefile(s) those dlls like softtokn3.dll are build/copied ? Francis Beginning test run TestInterop... Exception in thread "main" java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java: 57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorIm pl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:408) at PKCS11Test.getSunPKCS11(PKCS11Test.java:70) at PKCS11Test.testNSS(PKCS11Test.java:356) at PKCS11Test.main(PKCS11Test.java:89) at TestInterop.main(TestInterop.java:141) Caused by: java.security.ProviderException: Initialization failed at sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:376) at sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:103) ... 8 more Caused by: java.io.IOException: Accès refusé. Z:\JDK\jdk8\jdk\test\sun\security\pkcs11\nss\lib\windows-i586\softokn3.dll at sun.security.pkcs11.wrapper.PKCS11.connect(Native Method) at sun.security.pkcs11.wrapper.PKCS11.(PKCS11.java:138) at sun.security.pkcs11.wrapper.PKCS11.getInstance(PKCS11.java:151) at sun.security.pkcs11.SunPKCS11.(SunPKCS11.java:313) ... 9 more
Re: RFR: JDK-8027963: Create unlimited policy jars.
On 2013-11-28 11:31, Erik Joelsson wrote: Hello Brad, New review posted: http://cr.openjdk.java.net/~erikj/8027963/webrev.03/ Looks good to me. /Magnus
Re: RFR: JDK-8029512 : webrev.ksh: fix parsing of parent repo paths from hgrc file
Oooops ,
On Wed, 2013-12-04 at 11:48 +, Dave Pointon wrote:
>
> I concur with you Erik, character classes are only proven to work
> with/in perl 5 across all platforms. I suggest that the need to parse
> whitespace can be eliminated entirely by using awk(1) with a
> field-delimiter of '=' thus realizing a simpler solution all together,
> viz ...
>
> if [[ -z "$OUTPWS" ]]; then
> OUTPWS=`awk -F'=' '/^default(-push)/{print $NF}' .hg/hgrc ||
> $FILTER`
> fi
>
>
> Rgds ,
>
With the benefit of hindsight, the above isn't quite correct since the
printed value will retain any leading whitespace, so it s/b ...
if [[ -z "$OUTPWS" ]]; then
OUTPWS=`awk -F'=' '/^default(-push)?/{sub(/^\t */,'',$NF);print
$NF}' .hg/hgrc || $FILTER`
fi
Note the additional use of sub() to strip leading whitespace from the
path before printing it.
Rgds ,
--
Dave Pointon FIAP MBCS
Now I saw, tho' too late, the folly of beginning a work before we count
the cost and before we we judge rightly of our strength to go thro'
with it - Robinson Crusoe
Re: RFR: JDK-8029512 : webrev.ksh: fix parsing of parent repo paths from hgrc file
On Wed, 2013-12-04 at 10:45 +0100, Erik Joelsson wrote:
> Hello Mike,
>
> I think sed on some platforms doesn't support the [[:space:]]
> expression. I tried the line on a Solaris machine and it didn't work.
>
> /Erik
>
I concur with you Erik, character classes are only proven to work
with/in perl 5 across all platforms. I suggest that the need to parse
whitespace can be eliminated entirely by using awk(1) with a
field-delimiter of '=' thus realizing a simpler solution all together,
viz ...
if [[ -z "$OUTPWS" ]]; then
OUTPWS=`awk -F'=' '/^default(-push)/{print $NF}' .hg/hgrc ||
$FILTER`
fi
Rgds ,
--
Dave Pointon FIAP MBCS
Now I saw, tho' too late, the folly of beginning a work before we count
the cost and before we we judge rightly of our strength to go thro'
with it - Robinson Crusoe
Re: RFR: JDK-8029512 : webrev.ksh: fix parsing of parent repo paths from hgrc file
Hello Mike, I think sed on some platforms doesn't support the [[:space:]] expression. I tried the line on a Solaris machine and it didn't work. /Erik On 2013-12-04 06:16, Mike Duigou wrote: Hello all; This change addresses a problem discovered by Dave Pointon. http://cr.openjdk.java.net/~mduigou/JDK-8029512/0/webrev/ If the .hg/hgrc file contains (perfectly legal) spaces around the = sign of an assignment then the current script will fail to correctly read the path definition. This patch corrects the parsing of the hgrc file and also protects against empty results. I plan to commit this to the JDK 9 repo first but expect that it should be backported to JDK 8 and JDK 7 repos. Mike
Re: JDK-8028531: Need review of a make change for the JAB - for a backport into 7u60
Looks good to me. /Erik On 2013-12-03 19:02, Pete Brunet wrote: Please review the following 8 to 7u backport change for the make of the Java Access Bridge. This change was needed due to build differences between 8 and 7u. http://cr.openjdk.java.net/~ptbrunet/JDK-8028531/ The change has already been privately reviewed but an open review is also needed. Thanks, Pete
