Hi Eric
The creation of the blacklisted.certs file looks like this now:
$(BLACKLISTED_CERTS_DST): $(BLACKLISTED_CERTS_SRC)
$(MKDIR) -p $(@D)
$(CAT) $^ | $(SED) '/^$$/d' | $(SORT) | $(UNIQ) > $@.tmp
$(GREP) -i Algorithm $@.tmp > $@
$(GREP) -iv Algorithm $@.tmp >> $
On 10/09/2013 7:17 AM, Naoto Sato wrote:
Hi David,
With this change, rt.jar would contain all the supported English locales
in java.text and java.util packages (cf.
http://www.oracle.com/technetwork/java/javase/javase7locales-334809.html#util-text),
whereas US English is the only supported local
Hi David,
With this change, rt.jar would contain all the supported English locales
in java.text and java.util packages (cf.
http://www.oracle.com/technetwork/java/javase/javase7locales-334809.html#util-text),
whereas US English is the only supported locale at the moment w/o
localedata.jar.
On 07/24/2013 02:33 PM, Alan Bateman wrote:
> On 10/07/2013 12:01, Omair Majid wrote:
>> On 07/09/2013 03:40 AM, Erik Joelsson wrote:
>>> I would like to see a comment explaining why the option was needed. Is
>>> this a bug in gcc or has the checking just become better?
>> -Werror is not a great de
Omair,
I'm OK with latest webrev.
-Dmitry
On 2013-09-09 21:34, Omair Majid wrote:
> Hi,
>
> On 09/05/2013 05:43 AM, Dmitry Samersoff wrote:
>> It might make sense to set
>>
>> VAR_CPU to ESA_390
>>
>> VAR_CPU_ARCH to ESA_390 or ever to ESA_3xx
>>
>> for both s390 and s390x.
>>
>> s370 diverge
On 09/05/2013 05:10 AM, Magnus Ihse Bursie wrote:
> On 2013-09-04 21:26, Omair Majid wrote:
>> Over in Fedora-land, we are trying to build OpenJDK (using zero) on
>> s390(x) [1]. One of the changes needed is updating the platform.m4 file
>> to teach it about s390(x). The following webrev does that:
Hi,
On 09/05/2013 05:43 AM, Dmitry Samersoff wrote:
> It might make sense to set
>
> VAR_CPU to ESA_390
>
> VAR_CPU_ARCH to ESA_390 or ever to ESA_3xx
>
> for both s390 and s390x.
>
> s370 diverged over time to a variety of more or less compatible series
> and it's possible the same happens
Phil,
I've tested it on the clean Windows 7 virtual machine with only VS2010
installed as well on a number of configurations with and without DXSDK
(even on my VS2012 only setup).
Thanks,
Vadim
On 09.09.2013 19:49, Phil Race wrote:
Seems fine to me given that the versions are identical acros
As part of my effort to fix my build times I am trying to upgrade to the
latest cygwin. There is now a 32 bit and 64 bit installer (for
1.7.25). However, I see that procps/free.exe is not in the 64 bit
packages. Does that mean that we can't use the 64 bit version? Or do I
need to install free s
Seems fine to me given that the versions are identical across all SDKs
we might use.
Also since this simply removes a required build component, there should
be no
'flag day' where people need to be given notice to install a new build
component.
I think you said that you didn't have the standalon
Here's what's missing in the 64 bit version as of Aug 5.
http://comments.gmane.org/gmane.os.cygwin/141569
Besides free.exe is there anything else on the list that is needed?
For now I'll remove the 64 bit version and install the 32 bit version.
Pete
On 9/9/13 10:56 AM, Pete Brunet wrote:
> As p
On 09/09/2013 16:12, Kumar Srinivasan wrote:
Alan, are the nio changes acceptable? Let me know if you need more
time to go over all
the changes.
It looks fine (sorry I should have made that clearer). I skimmed over
the other tests too (the launcher tests in particular) and don't see any
oth
Hi David,
Hi Kumar,
This is still dead code in
src/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java
String os_arch = System.getProperty("os.arch");
Ah, I will take care of it. Thanks for spotting this.
Also:
test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/sol
Hi Magnus,
thanks again for the review. Please see my comments inline:
On Mon, Sep 9, 2013 at 12:23 PM, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:
> Hi Volker,
>
> Some more comments inlined.
>
> OK, common/autoconf/build-aux/autoconf-config.guess was too old and
> didn't knew
Our local copy of config.guess (autoconf-config.guess) is very much
outdated.
Now that we require autoconf 2.69, we should also have a config.guess
from that version of autoconf.
This is a blocker for the proper solution needed to integrate AIX build
changes.
Webrev is here, but it does no
On 2013-09-06 18:47, Kumar Srinivasan wrote:
Hello,
Please review the changes to remove Solaris 32-bit binaries from JDK8
distros,
at this time the dual mode support in the launcher is being disabled.
Message regarding this:
http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-September/00315
On 2013-09-06 22:21, Vadim Pakhnushev wrote:
Hi all,
Please review the fix for this bug:
http://bugs.sun.com/view_bug.do?bug_id=8008022
http://cr.openjdk.java.net/~vadim/8008022/webrev.00/
The new build part of the change looks good. (I have not looked at the
old build files.)
Always nice
On 09/09/2013 04:28, David Holmes wrote:
:
Also:
test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-amd64/libLauncher.so
I know this already exist but I thought binaries were disallowed in
the open repo?
Right, we don't want binary files checked in. The test needs to
18 matches
Mail list logo
