From dalibor.topic at oracle.com Thu Jul 2 14:14:26 2015 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 02 Jul 2015 16:14:26 +0200 Subject: JDK 7 Updates: Policy Changes In-Reply-To: <55912170.2050804@redhat.com> References: <55912170.2050804@redhat.com> Message-ID: <55954742.907@oracle.com> On 29.06.2015 12:44, Andrew Haley wrote: > Some of the content of the Wiki is out of date. In particular, the > "JDK 7 Update Project Proposal Q & A" is somewhat misleading. I have > lightly edited it, but as much of what it refers to has passed it > perhaps makes more sense to delete it or replace it with something > which reflects reality. I'd suggest deleting it. The Project proposal was successfully made in 2011. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From mail at alexkasko.com Fri Jul 3 11:24:31 2015 From: mail at alexkasko.com (Alex Kashchenko) Date: Fri, 03 Jul 2015 14:24:31 +0300 Subject: =?UTF-8?B?4oCLQ29tcGlsZSBvcGVuSkRLIEVSUk9SIEZyZWVUeXBlIHZlcnM=?= =?UTF-8?B?aW9uICAyLjMuMCAgb3IgaGlnaGVyIGlzIHJlcXVpcmVk?= In-Reply-To: <6263390a.e43a.14e48c59826.Coremail.kennedyhan@163.com> References: <6263390a.e43a.14e48c59826.Coremail.kennedyhan@163.com> Message-ID: <559670EF.8040009@alexkasko.com> Hi kennedy, On 07/01/2015 11:39 AM, kennedy wrote: > Compile openJDK 1.7 (x64) on Windows 7 (x64) I haven't reproduced it myself but it looks like the same problem as in this thread about jdk8 build [1]. FreeType binaries for jdk8 and jdk7 are the same, just in jdk7u you'll need to set ALT_FREETYPE_LIB_PATH and ALT_FREETYPE_HEADERS_PATH. If you'll want to build FreeType yourself and will have problems with it - I can write more details on its windows build. PS: CC'ing jdk7u-dev instead of build-dev, as it looks more relevant and has lower traffic. [1] http://mail.openjdk.java.net/pipermail/build-dev/2014-October/013530.html > > > and the error output: > > > ------ > ( cd ./jdk/make && \ > make sanity HOTSPOT_IMPORT_CHECK=false JDK_TOPDIR=E:/research/open/jdk7/jdk JDK_MAKE_SHARED_DIR=E:/research/open/jdk7/jdk/make/common/shared EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7 TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00 JDK_BUILD_NUMBER=b00 FULL_VERSION=1.7.0-internal-administrator_2015_07_01_16_07-b00 PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7 JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0 PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6 PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0 ANT_HOME="E:/APACHE~1.5" ALT_OUTPUTDIR=e:/research/open/output_amd64 ALT_LANGTOOLS_DIST=e:/research/open/output_amd64/langtools/dist ALT_CORBA_DIST=e:/research/open/output_amd64/corba/dist ALT_JAXP_DIST=e:/research/open/output_amd64/jaxp/dist ALT_JAXWS_DIST=e:/research/open/output_amd64/jaxws/dist ALT_HOTSPOT_IMPORT_PATH=e:/research/open/output_amd64/hotspot/import BUILD_HOTSPOT=true ; ) > make[1]: Entering directory '/cygdrive/e/research/open/jdk7/jdk/make' > make[2]: *** [e:/research/open/output_amd64/btbins/freetype_versioncheck.exe] Error 96 > make[1]: Leaving directory '/cygdrive/e/research/open/jdk7/jdk/make' > > > Build Machine Information: > build machine = GOBIXQR4SKSVROP > > > Build Directory Structure: > CWD = /cygdrive/e/research/open/jdk7 > TOPDIR = . > LANGTOOLS_TOPDIR = ./langtools > JAXP_TOPDIR = ./jaxp > JAXWS_TOPDIR = ./jaxws > CORBA_TOPDIR = ./corba > HOTSPOT_TOPDIR = ./hotspot > JDK_TOPDIR = ./jdk > > > Build Directives: > BUILD_LANGTOOLS = true > BUILD_JAXP = true > BUILD_JAXWS = true > BUILD_CORBA = true > BUILD_HOTSPOT = true > BUILD_JDK = true > DEBUG_CLASSFILES = > DEBUG_BINARIES = > > > Hotspot Settings: > HOTSPOT_BUILD_JOBS = 4 > HOTSPOT_OUTPUTDIR = e:/research/open/output_amd64/hotspot/outputdir > HOTSPOT_EXPORT_PATH = e:/research/open/output_amd64/hotspot/import > > > > > > > > Bootstrap Settings: > BOOTDIR = c:/jdk1.6 > ALT_BOOTDIR = c:/jdk1.6 > BOOT_VER = 1.6.0 [requires at least 1.6] > OUTPUTDIR = e:/research/open/output_amd64 > ALT_OUTPUTDIR = e:/research/open/output_amd64 > ABS_OUTPUTDIR = e:/research/open/output_amd64 > > Build Tool Settings: > SLASH_JAVA = J: > ALT_SLASH_JAVA = > VARIANT = OPT > JDK_DEVTOOLS_DIR = J:/devtools > ALT_JDK_DEVTOOLS_DIR = > ANT_HOME = E:/APACHE~1.5 > UNIXCOMMAND_PATH = /usr/bin/ > ALT_UNIXCOMMAND_PATH = > COMPILER_PATH = C:/PROGRA~2/MICROS~1.0/Common7/Tools/../../Vc/bin/amd64/ > ALT_COMPILER_PATH = > DEVTOOLS_PATH = /usr/bin/ > ALT_DEVTOOLS_PATH = > MSVCRNN_DLL_PATH = E:/research/jdkBuild/msvcr100 > ALT_MSVCRNN_DLL_PATH = e:/research/jdkBuild/msvcr100 > INCLUDE = e:\Microsoft Visual Studio 10.0\VC\INCLUDE;C:\Program Files (x86)\Microsoft SDKs\Windows7.0A\include > LIB = e:\Microsoft Visual Studio 10.0\VC\libmd64;C:\Program Files (x86)\Microsoft SDKs\Windows7.0A\lib > COMPILER_NAME = Microsoft Visual Studio 10 (16.00.30319.01) > COMPILER_VERSION = VS2010 > CC_VER = 16.00.40219.01 [requires at least 16.00.30319.01] > ZIP_VER = 3.0 [requires at least 2.2] > UNZIP_VER = 6.00 [requires at least 5.12] > LINK_VER = 10.00.40219.01 [requires at least 10.00.30319.01] > CC = C:/PROGRA~2/MICROS~1.0/Common7/Tools/../../Vc/bin/amd64/cl > LINK = C:/PROGRA~2/MICROS~1.0/Common7/Tools/../../Vc/bin/amd64/link > DUMPBIN = C:/PROGRA~2/MICROS~1.0/Common7/Tools/../../Vc/bin/amd64/dumpbin.exe > ANT_VER = 1.9.5 [requires at least 1.7.1] > TEMPDIR = e:/research/open/output_amd64/tmp > > Build Directives: > OPENJDK = true > USE_HOTSPOT_INTERPRETER_MODE = > PEDANTIC = > DEV_ONLY = > NO_DOCS = > NO_IMAGES = > TOOLS_ONLY = > INSANE = > COMPILE_APPROACH = normal > FASTDEBUG = > COMPILER_WARNINGS_FATAL = false > COMPILER_WARNING_LEVEL = 3 > SHOW_ALL_WARNINGS = false > INCREMENTAL_BUILD = false > CC_HIGHEST_OPT = > CC_HIGHER_OPT = > CC_LOWER_OPT = > CXXFLAGS = -O1 -Zi -nologo -MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB -Zc:wchar_t- -Fde:/research/open/output_amd64/tmp/obj64/.pdb -Fme:/research/open/output_amd64/tmp/obj64/.map -wd4800 -W3 -D _CRT_SECURE_NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE > CFLAGS = -O1 -Zi -nologo -MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB -Zc:wchar_t- -Fde:/research/open/output_amd64/tmp/obj64/.pdb -Fme:/research/open/output_amd64/tmp/obj64/.map -wd4800 -W3 -D _CRT_SECURE_NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE > BOOT_JAVA_CMD = c:/jdk1.6/bin/java -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput -Xmx512m -Xms512m -XX:PermSize=32m -XX:MaxPermSize=160m > BOOT_JAVAC_CMD = c:/jdk1.6/bin/javac -J-XX:ThreadStackSize=1536 -J-XX:-PrintVMOptions -J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput -J-Xmx512m -J-Xms512m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m -encoding ascii -source 6 -target 6 -XDignore.symbol.file=true > BOOT_JAR_CMD = c:/jdk1.6/bin/jar > BOOT_JARSIGNER_CMD = c:/jdk1.6/bin/jarsigner > > Build Platform Settings: > USER = Administrator > PLATFORM = windows > ARCH = amd64 > LIBARCH = amd64 > ARCH_FAMILY = amd64 > ARCH_DATA_MODEL = 64 > ARCHPROP = amd64 > PROCESSOR_ARCHITECTURE = AMD64 > PROCESSOR_IDENTIFIER = Intel64 Family 6 Model 60 Stepping 3, GenuineIntel > USING_CYGWIN = true > CYGWIN_VER = 6.1 [requires at least 4.0] > CYGPATH_CMD = cygpath -a -s -m > OS_VERSION = 5.0 [requires at least 5.2] > OS_VARIANT_NAME = Windows2000 > OS_VARIANT_VERSION = 5.0 > MB_OF_MEMORY = 16278 > > GNU Make Settings: > MAKE = make > MAKE_VER = 4.1 [requires at least 3.81] > MAKECMDGOALS = sanity > MAKEFLAGS = w > SHELL = /bin/sh > > Target Build Versions: > JDK_VERSION = 1.7.0 > MILESTONE = internal > RELEASE = 1.7.0-internal > FULL_VERSION = 1.7.0-internal-administrator_2015_07_01_16_07-b00 > BUILD_NUMBER = b00 > > External File/Binary Locations: > USRJDKINSTANCES_PATH = C:/PROGRA~1/Java > BUILD_JDK_IMPORT_PATH = J:/re/jdk/1.7.0/promoted/latest/binaries > ALT_BUILD_JDK_IMPORT_PATH = > JDK_IMPORT_PATH = C:/jdk1.6 > ALT_JDK_IMPORT_PATH = C:\jdk1.6 > LANGTOOLS_DIST = > ALT_LANGTOOLS_DIST = e:/research/open/output_amd64/langtools/dist > CORBA_DIST = > ALT_CORBA_DIST = e:/research/open/output_amd64/corba/dist > JAXP_DIST = > ALT_JAXP_DIST = e:/research/open/output_amd64/jaxp/dist > JAXWS_DIST = > ALT_JAXWS_DIST = e:/research/open/output_amd64/jaxws/dist > HOTSPOT_DOCS_IMPORT_PATH = /NO_DOCS_DIR > ALT_HOTSPOT_DOCS_IMPORT_PATH = > HOTSPOT_IMPORT_PATH = E:/research/open/output_amd64/hotspot/import > ALT_HOTSPOT_IMPORT_PATH = e:/research/open/output_amd64/hotspot/import > HOTSPOT_SERVER_PATH = E:/research/open/output_amd64/hotspot/import/jre/bin/server > ALT_HOTSPOT_SERVER_PATH = > HOTSPOT_LIB_PATH = E:/research/open/output_amd64/hotspot/import/lib > ALT_HOTSPOT_LIB_PATH = > DXSDK_VER = 0x0900 > DXSDK_PATH = E:/MICROS~1 > ALT_DXSDK_PATH = E:\Microsoft DirectX SDK > DXSDK_INCLUDE_PATH = E:/MICROS~1/Include > ALT_DXSDK_INCLUDE_PATH = > DXSDK_LIB_PATH = E:/MICROS~1/Lib/x64 > ALT_DXSDK_LIB_PATH = > WINDOWSSDKDIR = E:/MICROS~2/Windows/v7.1/ > ALT_WINDOWSSDKDIR = > RC = E:/MICROS~2/Windows/v7.1//Bin/x64/RC.Exe > REBASE = E:/MICROS~2/Windows/v7.1//Bin/x64/ReBase.Exe > CACERTS_FILE = ./../src/share/lib/security/cacerts > ALT_CACERTS_FILE = > > OpenJDK-specific settings: > FREETYPE_HEADERS_PATH = e:/freetype-2.4.7/include > ALT_FREETYPE_HEADERS_PATH = e:/freetype-2.4.7/include > FREETYPE_LIB_PATH = e:/freetype-2.4.7/objs/x64/vc2010 > ALT_FREETYPE_LIB_PATH = e:/freetype-2.4.7/objs/x64/vc2010 > > Previous JDK Settings: > PREVIOUS_RELEASE_PATH = USING-PREVIOUS_RELEASE_IMAGE > ALT_PREVIOUS_RELEASE_PATH = > PREVIOUS_JDK_VERSION = 1.6.0 > ALT_PREVIOUS_JDK_VERSION = > PREVIOUS_JDK_FILE = > ALT_PREVIOUS_JDK_FILE = > PREVIOUS_JRE_FILE = > ALT_PREVIOUS_JRE_FILE = > PREVIOUS_RELEASE_IMAGE = c:/jdk1.6 > ALT_PREVIOUS_RELEASE_IMAGE = > > > > > WARNING: To build Java 2 SDK 1.7.0 you need : > VS2010 - link.exe version '10.00.30319.01' > Specifically the Visual Studio 10 link.exe. > You appear to be using Linker version '10.00.40219.01' > > ERROR: FreeType version 2.3.0 or higher is required. > make[2]: Entering directory '/cygdrive/e/research/open/jdk7/jdk/make/tools/freetypecheck' > /usr/bin/mkdir -p e:/research/open/output_amd64/btbins > rm -f e:/research/open/output_amd64/btbins/freetype_versioncheck.exe > C:/PROGRA~2/MICROS~1.0/Common7/Tools/../../Vc/bin/amd64/cl /nologo /c -Ie:/freetype-2.4.7/include -Ie:/freetype-2.4.7/include/freetype2 -DREQUIRED_FREETYPE_VERSION=2.3.0 -Foe:/research/open/output_amd64/btbins/freetype_versioncheck.obj freetypecheck.c > freetypecheck.c > C:/PROGRA~2/MICROS~1.0/Common7/Tools/../../Vc/bin/amd64/link e:/freetype-2.4.7/objs/x64/vc2010/freetype.lib /manifest /OUT:e:/research/open/output_amd64/btbins/freetype_versioncheck.exe e:/research/open/output_amd64/btbins/freetype_versioncheck.obj > Microsoft (R) Incremental Linker Version 10.00.40219.01 > Copyright (C) Microsoft Corporation. All rights reserved. > > > LIBCMT.lib(crt0.obj) : error LNK2019: unresolved external symbol __imp_GetCommandLineA referenced in function __tmainCRTStartup > LIBCMT.lib(longjmp.obj) : error LNK2019: unresolved external symbol RtlUnwindEx referenced in function longjmp > LIBCMT.lib(jmpuwind.obj) : error LNK2001: unresolved external symbol RtlUnwindEx > LIBCMT.lib(malloc.obj) : error LNK2019: unresolved external symbol __imp_HeapAlloc referenced in function _heap_alloc > LIBCMT.lib(calloc_impl.obj) : error LNK2001: unresolved external symbol __imp_HeapAlloc > LIBCMT.lib(chsize.obj) : error LNK2001: unresolved external symbol __imp_HeapAlloc > LIBCMT.lib(osfinfo.obj) : error LNK2019: unresolved external symbol __imp_GetLastError referenced in function _set_osfhnd > LIBCMT.lib(commit.obj) : error LNK2001: unresolved external symbol __imp_GetLastError > LIBCMT.lib(open.obj) : error LNK2001: unresolved external symbol __imp_GetLastError > LIBCMT.lib(chsize.obj) : error LNK2001: unresolved external symbol __imp_GetLastError > LIBCMT.lib(write.obj) : error LNK2001: unresolved external symbol __imp_GetLastError > LIBCMT.lib(winsig.obj) : error LNK2001: unresolved external symbol __imp_GetLastError > LIBCMT.lib(rand_s.obj) : error LNK2001: unresolved external symbol __imp_GetLastError > LIBCMT.lib(inithelp.obj) : error LNK2001: unresolved external symbol __imp_GetLastError > LIBCMT.lib(read.obj) : error LNK2001: unresolved external symbol __imp_GetLastError > LIBCMT.lib(lseek.obj) : error LNK2001: unresolved external symbol __imp_GetLastError > LIBCMT.lib(wctomb.obj) : error LNK2001: unresolved external symbol __imp_GetLastError > LIBCMT.lib(lseeki64.obj) : error LNK2001: unresolved external symbol __imp_GetLastError > LIBCMT.lib(realloc.obj) : error LNK2001: unresolved external symbol __imp_GetLastError > LIBCMT.lib(free.obj) : error LNK2001: unresolved external symbol __imp_GetLastError > LIBCMT.lib(tidtable.obj) : error LNK2001: unresolved external symbol __imp_GetLastError > LIBCMT.lib(close.obj) : error LNK2001: unresolved external symbol __imp_GetLastError > LIBCMT.lib(realloc.obj) : error LNK2019: unresolved external symbol __imp_HeapReAlloc referenced in function realloc > LIBCMT.lib(free.obj) : error LNK2019: unresolved external symbol __imp_HeapFree referenced in function free > LIBCMT.lib(chsize.obj) : error LNK2001: unresolved external symbol __imp_HeapFree > LIBCMT.lib(chandler.obj) : error LNK2019: unresolved external symbol __imp_RtlUnwindEx referenced in function __C_specific_handler > LIBCMT.lib(_file.obj) : error LNK2019: unresolved external symbol __imp_EnterCriticalSection referenced in function _lock_file > LIBCMT.lib(stream.obj) : error LNK2001: unresolved external symbol __imp_EnterCriticalSection > LIBCMT.lib(mlock.obj) : error LNK2001: unresolved external symbol __imp_EnterCriticalSection > LIBCMT.lib(osfinfo.obj) : error LNK2001: unresolved external symbol __imp_EnterCriticalSection > LIBCMT.lib(_file.obj) : error LNK2019: unresolved external symbol __imp_LeaveCriticalSection referenced in function _unlock_file > LIBCMT.lib(mlock.obj) : error LNK2001: unresolved external symbol __imp_LeaveCriticalSection > LIBCMT.lib(osfinfo.obj) : error LNK2001: unresolved external symbol __imp_LeaveCriticalSection > LIBCMT.lib(rand_s.obj) : error LNK2001: unresolved external symbol __imp_DecodePointer > LIBCMT.lib(onexit.obj) : error LNK2001: unresolved external symbol __imp_DecodePointer > LIBCMT.lib(crtmboxw.obj) : error LNK2001: unresolved external symbol __imp_DecodePointer > LIBCMT.lib(outputs.obj) : error LNK2001: unresolved external symbol __imp_DecodePointer > LIBCMT.lib(outputp.obj) : error LNK2001: unresolved external symbol __imp_DecodePointer > LIBCMT.lib(hooks.obj) : error LNK2001: unresolved external symbol __imp_DecodePointer > LIBCMT.lib(winsig.obj) : error LNK2001: unresolved external symbol __imp_DecodePointer > LIBCMT.lib(output.obj) : error LNK2019: unresolved external symbol __imp_DecodePointer referenced in function _output_l > LIBCMT.lib(invarg.obj) : error LNK2001: unresolved external symbol __imp_DecodePointer > LIBCMT.lib(crt0dat.obj) : error LNK2001: unresolved external symbol __imp_DecodePointer > LIBCMT.lib(handler.obj) : error LNK2001: unresolved external symbol __imp_DecodePointer > LIBCMT.lib(invarg.obj) : error LNK2019: unresolved external symbol __imp_UnhandledExceptionFilter referenced in function _call_reportfault > LIBCMT.lib(gs_report.obj) : error LNK2001: unresolved external symbol __imp_UnhandledExceptionFilter > LIBCMT.lib(invarg.obj) : error LNK2019: unresolved external symbol __imp_SetUnhandledExceptionFilter referenced in function _call_reportfault > LIBCMT.lib(gs_report.obj) : error LNK2001: unresolved external symbol __imp_SetUnhandledExceptionFilter > LIBCMT.lib(unhandld.obj) : error LNK2001: unresolved external symbol __imp_SetUnhandledExceptionFilter > LIBCMT.lib(invarg.obj) : error LNK2019: unresolved external symbol __imp_IsDebuggerPresent referenced in function _call_reportfault > LIBCMT.lib(gs_report.obj) : error LNK2001: unresolved external symbol __imp_IsDebuggerPresent > LIBCMT.lib(invarg.obj) : error LNK2019: unresolved external symbol RtlVirtualUnwind referenced in function _call_reportfault > LIBCMT.lib(gs_report.obj) : error LNK2001: unresolved external symbol RtlVirtualUnwind > LIBCMT.lib(invarg.obj) : error LNK2019: unresolved external symbol RtlLookupFunctionEntry referenced in function _call_reportfault > LIBCMT.lib(gs_report.obj) : error LNK2001: unresolved external symbol RtlLookupFunctionEntry > LIBCMT.lib(invarg.obj) : error LNK2019: unresolved external symbol __imp_RtlCaptureContext referenced in function _call_reportfault > LIBCMT.lib(gs_report.obj) : error LNK2001: unresolved external symbol __imp_RtlCaptureContext > LIBCMT.lib(crtmboxw.obj) : error LNK2001: unresolved external symbol __imp_EncodePointer > LIBCMT.lib(hooks.obj) : error LNK2001: unresolved external symbol __imp_EncodePointer > LIBCMT.lib(winsig.obj) : error LNK2001: unresolved external symbol __imp_EncodePointer > LIBCMT.lib(rand_s.obj) : error LNK2001: unresolved external symbol __imp_EncodePointer > LIBCMT.lib(onexit.obj) : error LNK2019: unresolved external symbol __imp_EncodePointer referenced in function _onexit > LIBCMT.lib(invarg.obj) : error LNK2001: unresolved external symbol __imp_EncodePointer > LIBCMT.lib(tidtable.obj) : error LNK2001: unresolved external symbol __imp_EncodePointer > LIBCMT.lib(handler.obj) : error LNK2001: unresolved external symbol __imp_EncodePointer > LIBCMT.lib(cmiscdat.obj) : error LNK2001: unresolved external symbol __imp_EncodePointer > LIBCMT.lib(invarg.obj) : error LNK2019: unresolved external symbol __imp_TerminateProcess referenced in function _invoke_watson > LIBCMT.lib(gs_report.obj) : error LNK2001: unresolved external symbol __imp_TerminateProcess > LIBCMT.lib(invarg.obj) : error LNK2019: unresolved external symbol __imp_GetCurrentProcess referenced in function _invoke_watson > LIBCMT.lib(gs_report.obj) : error LNK2001: unresolved external symbol __imp_GetCurrentProcess > LIBCMT.lib(crt0dat.obj) : error LNK2019: unresolved external symbol __imp_GetProcAddress referenced in function __crtCorExitProcess > LIBCMT.lib(rand_s.obj) : error LNK2001: unresolved external symbol __imp_GetProcAddress > LIBCMT.lib(crtmboxw.obj) : error LNK2001: unresolved external symbol __imp_GetProcAddress > LIBCMT.lib(crt0dat.obj) : error LNK2019: unresolved external symbol __imp_GetModuleHandleW referenced in function __crtCorExitProcess > LIBCMT.lib(crt0dat.obj) : error LNK2019: unresolved external symbol __imp_ExitProcess referenced in function __crtExitProcess > LIBCMT.lib(crt0msg.obj) : error LNK2019: unresolved external symbol __imp_WriteFile referenced in function _NMSG_WRITE > LIBCMT.lib(write.obj) : error LNK2001: unresolved external symbol __imp_WriteFile > LIBCMT.lib(crt0msg.obj) : error LNK2019: unresolved external symbol __imp_GetStdHandle referenced in function _NMSG_WRITE > LIBCMT.lib(ioinit.obj) : error LNK2001: unresolved external symbol __imp_GetStdHandle > LIBCMT.lib(crt0msg.obj) : error LNK2019: unresolved external symbol __imp_GetModuleFileNameW referenced in function _NMSG_WRITE > LIBCMT.lib(stdargv.obj) : error LNK2019: unresolved external symbol __imp_GetModuleFileNameA referenced in function _setargv > LIBCMT.lib(a_env.obj) : error LNK2019: unresolved external symbol __imp_FreeEnvironmentStringsW referenced in function __crtGetEnvironmentStringsA > LIBCMT.lib(a_loc.obj) : error LNK2001: unresolved external symbol __imp_WideCharToMultiByte > LIBCMT.lib(a_env.obj) : error LNK2019: unresolved external symbol __imp_WideCharToMultiByte referenced in function __crtGetEnvironmentStringsA > LIBCMT.lib(wctomb.obj) : error LNK2001: unresolved external symbol __imp_WideCharToMultiByte > LIBCMT.lib(write.obj) : error LNK2001: unresolved external symbol __imp_WideCharToMultiByte > LIBCMT.lib(a_map.obj) : error LNK2001: unresolved external symbol __imp_WideCharToMultiByte > LIBCMT.lib(a_env.obj) : error LNK2019: unresolved external symbol __imp_GetEnvironmentStringsW referenced in function __crtGetEnvironmentStringsA > LIBCMT.lib(ioinit.obj) : error LNK2019: unresolved external symbol __imp_SetHandleCount referenced in function _ioinit > LIBCMT.lib(ioinit.obj) : error LNK2019: unresolved external symbol __imp_InitializeCriticalSectionAndSpinCount referenced in function _ioinit > LIBCMT.lib(stream.obj) : error LNK2001: unresolved external symbol __imp_InitializeCriticalSectionAndSpinCount > LIBCMT.lib(mlock.obj) : error LNK2001: unresolved external symbol __imp_InitializeCriticalSectionAndSpinCount > LIBCMT.lib(osfinfo.obj) : error LNK2001: unresolved external symbol __imp_InitializeCriticalSectionAndSpinCount > LIBCMT.lib(ioinit.obj) : error LNK2019: unresolved external symbol __imp_GetFileType referenced in function _ioinit > LIBCMT.lib(osfinfo.obj) : error LNK2001: unresolved external symbol __imp_GetFileType > LIBCMT.lib(open.obj) : error LNK2001: unresolved external symbol __imp_GetFileType > LIBCMT.lib(ioinit.obj) : error LNK2019: unresolved external symbol __imp_GetStartupInfoW referenced in function _ioinit > LIBCMT.lib(ioinit.obj) : error LNK2019: unresolved external symbol __imp_DeleteCriticalSection referenced in function _ioterm > LIBCMT.lib(closeall.obj) : error LNK2001: unresolved external symbol __imp_DeleteCriticalSection > LIBCMT.lib(mlock.obj) : error LNK2001: unresolved external symbol __imp_DeleteCriticalSection > LIBCMT.lib(tidtable.obj) : error LNK2019: unresolved external symbol __imp_FlsGetValue referenced in function __fls_getvalue > LIBCMT.lib(tidtable.obj) : error LNK2019: unresolved external symbol __imp_FlsSetValue referenced in function __fls_setvalue > LIBCMT.lib(tidtable.obj) : error LNK2019: unresolved external symbol __imp_FlsFree referenced in function _mtterm > LIBCMT.lib(tidtable.obj) : error LNK2019: unresolved external symbol __imp_SetLastError referenced in function _getptd_noexit > LIBCMT.lib(tidtable.obj) : error LNK2019: unresolved external symbol __imp_GetCurrentThreadId referenced in function _getptd_noexit > LIBCMT.lib(gs_support.obj) : error LNK2001: unresolved external symbol __imp_GetCurrentThreadId > LIBCMT.lib(tidtable.obj) : error LNK2019: unresolved external symbol __imp_GetCurrentThread referenced in function __threadhandle > LIBCMT.lib(tidtable.obj) : error LNK2019: unresolved external symbol __imp_FlsAlloc referenced in function _mtinit > LIBCMT.lib(heapinit.obj) : error LNK2019: unresolved external symbol __imp_HeapSetInformation referenced in function _heap_init > LIBCMT.lib(heapinit.obj) : error LNK2019: unresolved external symbol __imp_GetVersion referenced in function _heap_init > LIBCMT.lib(heapinit.obj) : error LNK2019: unresolved external symbol __imp_HeapCreate referenced in function _heap_init > LIBCMT.lib(heapinit.obj) : error LNK2019: unresolved external symbol __imp_HeapDestroy referenced in function _heap_term > LIBCMT.lib(gs_support.obj) : error LNK2019: unresolved external symbol __imp_QueryPerformanceCounter referenced in function __security_init_cookie > LIBCMT.lib(gs_support.obj) : error LNK2019: unresolved external symbol __imp_GetTickCount referenced in function __security_init_cookie > LIBCMT.lib(gs_support.obj) : error LNK2019: unresolved external symbol __imp_GetCurrentProcessId referenced in function __security_init_cookie > LIBCMT.lib(gs_support.obj) : error LNK2019: unresolved external symbol __imp_GetSystemTimeAsFileTime referenced in function __security_init_cookie > LIBCMT.lib(close.obj) : error LNK2019: unresolved external symbol __imp_CloseHandle referenced in function _close_nolock > LIBCMT.lib(open.obj) : error LNK2001: unresolved external symbol __imp_CloseHandle > LIBCMT.lib(initcon.obj) : error LNK2001: unresolved external symbol __imp_CloseHandle > LIBCMT.lib(read.obj) : error LNK2019: unresolved external symbol __imp_MultiByteToWideChar referenced in function _read_nolock > LIBCMT.lib(a_map.obj) : error LNK2001: unresolved external symbol __imp_MultiByteToWideChar > LIBCMT.lib(a_str.obj) : error LNK2001: unresolved external symbol __imp_MultiByteToWideChar > LIBCMT.lib(mbtowc.obj) : error LNK2001: unresolved external symbol __imp_MultiByteToWideChar > LIBCMT.lib(read.obj) : error LNK2019: unresolved external symbol __imp_ReadFile referenced in function _read_nolock > LIBCMT.lib(lseek.obj) : error LNK2019: unresolved external symbol __imp_SetFilePointer referenced in function _lseek_nolock > LIBCMT.lib(lseeki64.obj) : error LNK2001: unresolved external symbol __imp_SetFilePointer > LIBCMT.lib(crtheap.obj) : error LNK2019: unresolved external symbol __imp_Sleep referenced in function wait_a_bit > LIBCMT.lib(mlock.obj) : error LNK2019: unresolved external symbol __imp_FatalAppExitA referenced in function _lockerr_exit > LIBCMT.lib(mbctype.obj) : error LNK2019: unresolved external symbol __imp_GetCPInfo referenced in function "void __cdecl setSBUpLow(struct threadmbcinfostruct *)" (?setSBUpLow@@YAXPEAUthreadmbcinfostruct@@@Z) > LIBCMT.lib(initctyp.obj) : error LNK2001: unresolved external symbol __imp_GetCPInfo > LIBCMT.lib(mbctype.obj) : error LNK2019: unresolved external symbol __imp_GetACP referenced in function "int __cdecl getSystemCP(int)" (?getSystemCP@@YAHH at Z) > LIBCMT.lib(getqloc.obj) : error LNK2001: unresolved external symbol __imp_GetACP > LIBCMT.lib(mbctype.obj) : error LNK2019: unresolved external symbol __imp_GetOEMCP referenced in function "int __cdecl getSystemCP(int)" (?getSystemCP@@YAHH at Z) > LIBCMT.lib(mbctype.obj) : error LNK2019: unresolved external symbol __imp_IsValidCodePage referenced in function _setmbcp_nolock > LIBCMT.lib(getqloc.obj) : error LNK2001: unresolved external symbol __imp_IsValidCodePage > LIBCMT.lib(write.obj) : error LNK2019: unresolved external symbol __imp_GetConsoleCP referenced in function _write_nolock > LIBCMT.lib(write.obj) : error LNK2019: unresolved external symbol __imp_GetConsoleMode referenced in function _write_nolock > LIBCMT.lib(winsig.obj) : error LNK2019: unresolved external symbol __imp_SetConsoleCtrlHandler referenced in function signal > LIBCMT.lib(rand_s.obj) : error LNK2019: unresolved external symbol __imp_FreeLibrary referenced in function rand_s > LIBCMT.lib(rand_s.obj) : error LNK2019: unresolved external symbol __imp_LoadLibraryW referenced in function rand_s > LIBCMT.lib(crtmboxw.obj) : error LNK2001: unresolved external symbol __imp_LoadLibraryW > LIBCMT.lib(inithelp.obj) : error LNK2019: unresolved external symbol __imp_GetLocaleInfoW referenced in function __getlocaleinfo > LIBCMT.lib(a_loc.obj) : error LNK2001: unresolved external symbol __imp_GetLocaleInfoW > LIBCMT.lib(getqloc.obj) : error LNK2001: unresolved external symbol __imp_GetLocaleInfoW > LIBCMT.lib(osfinfo.obj) : error LNK2019: unresolved external symbol __imp_SetStdHandle referenced in function _set_osfhnd > LIBCMT.lib(commit.obj) : error LNK2019: unresolved external symbol __imp_FlushFileBuffers referenced in function _commit > LIBCMT.lib(open.obj) : error LNK2019: unresolved external symbol __imp_CreateFileA referenced in function _tsopen_nolock > LIBCMT.lib(a_map.obj) : error LNK2019: unresolved external symbol __imp_LCMapStringW referenced in function "int __cdecl __crtLCMapStringA_stat(struct localeinfo_struct *,unsigned long,unsigned long,char const *,int,char *,int,int,int)" (?__crtLCMapStringA_stat@@YAHPEAUlocaleinfo_struct@@KKPEBDHPEADHHH at Z) > LIBCMT.lib(a_str.obj) : error LNK2019: unresolved external symbol __imp_GetStringTypeW referenced in function "int __cdecl __crtGetStringTypeA_stat(struct localeinfo_struct *,unsigned long,char const *,int,unsigned short *,int,int,int)" (?__crtGetStringTypeA_stat@@YAHPEAUlocaleinfo_struct@@KPEBDHPEAGHHH at Z) > LIBCMT.lib(iswctype.obj) : error LNK2001: unresolved external symbol __imp_GetStringTypeW > LIBCMT.lib(putwch.obj) : error LNK2019: unresolved external symbol __imp_WriteConsoleW referenced in function _putwch_nolock > LIBCMT.lib(msize.obj) : error LNK2019: unresolved external symbol __imp_HeapSize referenced in function _msize > LIBCMT.lib(chsize.obj) : error LNK2019: unresolved external symbol __imp_SetEndOfFile referenced in function _chsize_nolock > LIBCMT.lib(chsize.obj) : error LNK2019: unresolved external symbol __imp_GetProcessHeap referenced in function _chsize_nolock > LIBCMT.lib(getqloc.obj) : error LNK2019: unresolved external symbol __imp_GetUserDefaultLCID referenced in function GetLcidFromDefault > LIBCMT.lib(getqloc.obj) : error LNK2019: unresolved external symbol __imp_GetLocaleInfoA referenced in function CountryEnumProc > LIBCMT.lib(getqloc.obj) : error LNK2019: unresolved external symbol __imp_EnumSystemLocalesA referenced in function GetLcidFromCountry > LIBCMT.lib(getqloc.obj) : error LNK2019: unresolved external symbol __imp_IsValidLocale referenced in function __get_qualified_locale > LIBCMT.lib(initcon.obj) : error LNK2019: unresolved external symbol __imp_CreateFileW referenced in function __initconout > e:/research/open/output_amd64/btbins/freetype_versioncheck.exe : fatal error LNK1120: 79 unresolved externals > Makefile:68: recipe for target 'e:/research/open/output_amd64/btbins/freetype_versioncheck.exe' failed > make[2]: Leaving directory '/cygdrive/e/research/open/jdk7/jdk/make/tools/freetypecheck' > Failed to build freetypecheck. > > > Exiting because of the above error(s). > > make/sanity-rules.gmk:71: recipe for target 'post-sanity' failed > make: *** [post-sanity] Error 1 > > > ------ > > > and this is my command: > > > --- > make ARCH_DATA_MODEL=64 \ > ALT_OUTPUTDIR=e:/research/open/output_amd64 \ > ALT_FREETYPE_LIB_PATH=e:/freetype-2.4.7/objs/x64/vc2010 \ > ALT_FREETYPE_HEADERS_PATH=e:/freetype-2.4.7/include \ > ALT_BOOTDIR=c:/jdk1.6 \ > ALT_DROPS_DIR=e:/research/open/ALT_DROPS_DIR \ > ALT_MSVCRNN_DLL_PATH=e:/research/jdkBuild/msvcr100 \ > HOTSPOT_BUILD_JOBS=4 \ > PARALLEL_COMPILE_JOBS=4 \ > 2>&1 | tee e:/research/open/output_amd64.log > -- -Alex From mail at alexkasko.com Mon Jul 6 13:13:40 2015 From: mail at alexkasko.com (Alex Kashchenko) Date: Mon, 06 Jul 2015 16:13:40 +0300 Subject: =?UTF-8?B?4oCLQ29tcGlsZSBvcGVuSkRLIEVSUk9SIEZyZWVUeXBlIHZlcnM=?= =?UTF-8?B?aW9uICAyLjMuMCAgb3IgaGlnaGVyIGlzIHJlcXVpcmVk?= In-Reply-To: <1d7c9b8f.19943.14e62970d01.Coremail.kennedyhan@163.com> References: <6263390a.e43a.14e48c59826.Coremail.kennedyhan@163.com> <559670EF.8040009@alexkasko.com> <1d7c9b8f.19943.14e62970d01.Coremail.kennedyhan@163.com> Message-ID: <559A7F04.9000108@alexkasko.com> Hi kennedy, On 07/06/2015 11:59 AM, kennedy wrote: > hi alex, > > > I had set the ALT_FREETYPE_LIB_PATH and ALT_FREETYPE_HEADERS_PATH, and tried the freetype_2.5.3_win_x86_64.zip > But it still doesn't work at all, with the same error. Could you please specify the exact paths where you placed FreeType headers and binaries and the exact values you set for ALT_FREETYPE_LIB_PATH and ALT_FREETYPE_HEADERS_PATH? ALT_FREETYPE_LIB_PATH should point to directory with the following files: - freetype.dll - freetype.exp - freetype.lib ALT_FREETYPE_HEADERS_PATH should point to ../freetype/include (freetype.h should be in that directory). PS: please keep jdk7u-dev in CC. > > At 2015-07-03 19:24:31, "Alex Kashchenko" wrote: >> Hi kennedy, >> >> On 07/01/2015 11:39 AM, kennedy wrote: >>> Compile openJDK 1.7 (x64) on Windows 7 (x64) >> >> I haven't reproduced it myself but it looks like the same problem as in >> this thread about jdk8 build [1]. FreeType binaries for jdk8 and jdk7 >> are the same, just in jdk7u you'll need to set ALT_FREETYPE_LIB_PATH and >> ALT_FREETYPE_HEADERS_PATH. >> >> If you'll want to build FreeType yourself and will have problems with it >> - I can write more details on its windows build. >> >> PS: CC'ing jdk7u-dev instead of build-dev, as it looks more relevant and >> has lower traffic. >> >> [1] >> http://mail.openjdk.java.net/pipermail/build-dev/2014-October/013530.html >> >>> >>> >>> and the error output: >>> >>> >>> ------ >>> ( cd ./jdk/make && \ >>> make sanity HOTSPOT_IMPORT_CHECK=false JDK_TOPDIR=E:/research/open/jdk7/jdk JDK_MAKE_SHARED_DIR=E:/research/open/jdk7/jdk/make/common/shared EXTERNALSANITYCONTROL=true SOURCE_LANGUAGE_VERSION=7 TARGET_CLASS_VERSION=7 MILESTONE=internal BUILD_NUMBER=b00 JDK_BUILD_NUMBER=b00 FULL_VERSION=1.7.0-internal-administrator_2015_07_01_16_07-b00 PREVIOUS_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7 JDK_MAJOR_VERSION=1 JDK_MINOR_VERSION=7 JDK_MICRO_VERSION=0 PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VERSION=6 PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=64 COOKED_BUILD_NUMBER=0 ANT_HOME="E:/APACHE~1.5" ALT_OUTPUTDIR=e:/research/open/output_amd64 ALT_LANGTOOLS_DIST=e:/research/open/output_amd64/langtools/dist ALT_CORBA_DIST=e:/research/open/output_amd64/corba/dist ALT_JAXP_DIST=e:/research/open/output_amd64/jaxp/dist ALT_JAXWS_DIST=e:/research/open/output_amd64/jaxws/dist ALT_HOTSPOT_IMPORT_PATH=e:/research/open/output_amd64/hotspot/import BUILD_HOTSPOT=true ; ) >>> make[1]: Entering directory '/cygdrive/e/research/open/jdk7/jdk/make' >>> make[2]: *** [e:/research/open/output_amd64/btbins/freetype_versioncheck.exe] Error 96 >>> make[1]: Leaving directory '/cygdrive/e/research/open/jdk7/jdk/make' >>> >>> >>> Build Machine Information: >>> build machine = GOBIXQR4SKSVROP >>> >>> >>> Build Directory Structure: >>> CWD = /cygdrive/e/research/open/jdk7 >>> TOPDIR = . >>> LANGTOOLS_TOPDIR = ./langtools >>> JAXP_TOPDIR = ./jaxp >>> JAXWS_TOPDIR = ./jaxws >>> CORBA_TOPDIR = ./corba >>> HOTSPOT_TOPDIR = ./hotspot >>> JDK_TOPDIR = ./jdk >>> >>> >>> Build Directives: >>> BUILD_LANGTOOLS = true >>> BUILD_JAXP = true >>> BUILD_JAXWS = true >>> BUILD_CORBA = true >>> BUILD_HOTSPOT = true >>> BUILD_JDK = true >>> DEBUG_CLASSFILES = >>> DEBUG_BINARIES = >>> >>> >>> Hotspot Settings: >>> HOTSPOT_BUILD_JOBS = 4 >>> HOTSPOT_OUTPUTDIR = e:/research/open/output_amd64/hotspot/outputdir >>> HOTSPOT_EXPORT_PATH = e:/research/open/output_amd64/hotspot/import >>> >>> >>> >>> >>> >>> >>> >>> Bootstrap Settings: >>> BOOTDIR = c:/jdk1.6 >>> ALT_BOOTDIR = c:/jdk1.6 >>> BOOT_VER = 1.6.0 [requires at least 1.6] >>> OUTPUTDIR = e:/research/open/output_amd64 >>> ALT_OUTPUTDIR = e:/research/open/output_amd64 >>> ABS_OUTPUTDIR = e:/research/open/output_amd64 >>> >>> Build Tool Settings: >>> SLASH_JAVA = J: >>> ALT_SLASH_JAVA = >>> VARIANT = OPT >>> JDK_DEVTOOLS_DIR = J:/devtools >>> ALT_JDK_DEVTOOLS_DIR = >>> ANT_HOME = E:/APACHE~1.5 >>> UNIXCOMMAND_PATH = /usr/bin/ >>> ALT_UNIXCOMMAND_PATH = >>> COMPILER_PATH = C:/PROGRA~2/MICROS~1.0/Common7/Tools/../../Vc/bin/amd64/ >>> ALT_COMPILER_PATH = >>> DEVTOOLS_PATH = /usr/bin/ >>> ALT_DEVTOOLS_PATH = >>> MSVCRNN_DLL_PATH = E:/research/jdkBuild/msvcr100 >>> ALT_MSVCRNN_DLL_PATH = e:/research/jdkBuild/msvcr100 >>> INCLUDE = e:\Microsoft Visual Studio 10.0\VC\INCLUDE;C:\Program Files (x86)\Microsoft SDKs\Windows7.0A\include >>> LIB = e:\Microsoft Visual Studio 10.0\VC\libmd64;C:\Program Files (x86)\Microsoft SDKs\Windows7.0A\lib >>> COMPILER_NAME = Microsoft Visual Studio 10 (16.00.30319.01) >>> COMPILER_VERSION = VS2010 >>> CC_VER = 16.00.40219.01 [requires at least 16.00.30319.01] >>> ZIP_VER = 3.0 [requires at least 2.2] >>> UNZIP_VER = 6.00 [requires at least 5.12] >>> LINK_VER = 10.00.40219.01 [requires at least 10.00.30319.01] >>> CC = C:/PROGRA~2/MICROS~1.0/Common7/Tools/../../Vc/bin/amd64/cl >>> LINK = C:/PROGRA~2/MICROS~1.0/Common7/Tools/../../Vc/bin/amd64/link >>> DUMPBIN = C:/PROGRA~2/MICROS~1.0/Common7/Tools/../../Vc/bin/amd64/dumpbin.exe >>> ANT_VER = 1.9.5 [requires at least 1.7.1] >>> TEMPDIR = e:/research/open/output_amd64/tmp >>> >>> Build Directives: >>> OPENJDK = true >>> USE_HOTSPOT_INTERPRETER_MODE = >>> PEDANTIC = >>> DEV_ONLY = >>> NO_DOCS = >>> NO_IMAGES = >>> TOOLS_ONLY = >>> INSANE = >>> COMPILE_APPROACH = normal >>> FASTDEBUG = >>> COMPILER_WARNINGS_FATAL = false >>> COMPILER_WARNING_LEVEL = 3 >>> SHOW_ALL_WARNINGS = false >>> INCREMENTAL_BUILD = false >>> CC_HIGHEST_OPT = >>> CC_HIGHER_OPT = >>> CC_LOWER_OPT = >>> CXXFLAGS = -O1 -Zi -nologo -MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB -Zc:wchar_t- -Fde:/research/open/output_amd64/tmp/obj64/.pdb -Fme:/research/open/output_amd64/tmp/obj64/.map -wd4800 -W3 -D _CRT_SECURE_NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE >>> CFLAGS = -O1 -Zi -nologo -MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB -Zc:wchar_t- -Fde:/research/open/output_amd64/tmp/obj64/.pdb -Fme:/research/open/output_amd64/tmp/obj64/.map -wd4800 -W3 -D _CRT_SECURE_NO_DEPRECATE -D _CRT_NONSTDC_NO_DEPRECATE >>> BOOT_JAVA_CMD = c:/jdk1.6/bin/java -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput -Xmx512m -Xms512m -XX:PermSize=32m -XX:MaxPermSize=160m >>> BOOT_JAVAC_CMD = c:/jdk1.6/bin/javac -J-XX:ThreadStackSize=1536 -J-XX:-PrintVMOptions -J-XX:+UnlockDiagnosticVMOptions -J-XX:-LogVMOutput -J-Xmx512m -J-Xms512m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m -encoding ascii -source 6 -target 6 -XDignore.symbol.file=true >>> BOOT_JAR_CMD = c:/jdk1.6/bin/jar >>> BOOT_JARSIGNER_CMD = c:/jdk1.6/bin/jarsigner >>> >>> Build Platform Settings: >>> USER = Administrator >>> PLATFORM = windows >>> ARCH = amd64 >>> LIBARCH = amd64 >>> ARCH_FAMILY = amd64 >>> ARCH_DATA_MODEL = 64 >>> ARCHPROP = amd64 >>> PROCESSOR_ARCHITECTURE = AMD64 >>> PROCESSOR_IDENTIFIER = Intel64 Family 6 Model 60 Stepping 3, GenuineIntel >>> USING_CYGWIN = true >>> CYGWIN_VER = 6.1 [requires at least 4.0] >>> CYGPATH_CMD = cygpath -a -s -m >>> OS_VERSION = 5.0 [requires at least 5.2] >>> OS_VARIANT_NAME = Windows2000 >>> OS_VARIANT_VERSION = 5.0 >>> MB_OF_MEMORY = 16278 >>> >>> GNU Make Settings: >>> MAKE = make >>> MAKE_VER = 4.1 [requires at least 3.81] >>> MAKECMDGOALS = sanity >>> MAKEFLAGS = w >>> SHELL = /bin/sh >>> >>> Target Build Versions: >>> JDK_VERSION = 1.7.0 >>> MILESTONE = internal >>> RELEASE = 1.7.0-internal >>> FULL_VERSION = 1.7.0-internal-administrator_2015_07_01_16_07-b00 >>> BUILD_NUMBER = b00 >>> >>> External File/Binary Locations: >>> USRJDKINSTANCES_PATH = C:/PROGRA~1/Java >>> BUILD_JDK_IMPORT_PATH = J:/re/jdk/1.7.0/promoted/latest/binaries >>> ALT_BUILD_JDK_IMPORT_PATH = >>> JDK_IMPORT_PATH = C:/jdk1.6 >>> ALT_JDK_IMPORT_PATH = C:\jdk1.6 >>> LANGTOOLS_DIST = >>> ALT_LANGTOOLS_DIST = e:/research/open/output_amd64/langtools/dist >>> CORBA_DIST = >>> ALT_CORBA_DIST = e:/research/open/output_amd64/corba/dist >>> JAXP_DIST = >>> ALT_JAXP_DIST = e:/research/open/output_amd64/jaxp/dist >>> JAXWS_DIST = >>> ALT_JAXWS_DIST = e:/research/open/output_amd64/jaxws/dist >>> HOTSPOT_DOCS_IMPORT_PATH = /NO_DOCS_DIR >>> ALT_HOTSPOT_DOCS_IMPORT_PATH = >>> HOTSPOT_IMPORT_PATH = E:/research/open/output_amd64/hotspot/import >>> ALT_HOTSPOT_IMPORT_PATH = e:/research/open/output_amd64/hotspot/import >>> HOTSPOT_SERVER_PATH = E:/research/open/output_amd64/hotspot/import/jre/bin/server >>> ALT_HOTSPOT_SERVER_PATH = >>> HOTSPOT_LIB_PATH = E:/research/open/output_amd64/hotspot/import/lib >>> ALT_HOTSPOT_LIB_PATH = >>> DXSDK_VER = 0x0900 >>> DXSDK_PATH = E:/MICROS~1 >>> ALT_DXSDK_PATH = E:\Microsoft DirectX SDK >>> DXSDK_INCLUDE_PATH = E:/MICROS~1/Include >>> ALT_DXSDK_INCLUDE_PATH = >>> DXSDK_LIB_PATH = E:/MICROS~1/Lib/x64 >>> ALT_DXSDK_LIB_PATH = >>> WINDOWSSDKDIR = E:/MICROS~2/Windows/v7.1/ >>> ALT_WINDOWSSDKDIR = >>> RC = E:/MICROS~2/Windows/v7.1//Bin/x64/RC.Exe >>> REBASE = E:/MICROS~2/Windows/v7.1//Bin/x64/ReBase.Exe >>> CACERTS_FILE = ./../src/share/lib/security/cacerts >>> ALT_CACERTS_FILE = >>> >>> OpenJDK-specific settings: >>> FREETYPE_HEADERS_PATH = e:/freetype-2.4.7/include >>> ALT_FREETYPE_HEADERS_PATH = e:/freetype-2.4.7/include >>> FREETYPE_LIB_PATH = e:/freetype-2.4.7/objs/x64/vc2010 >>> ALT_FREETYPE_LIB_PATH = e:/freetype-2.4.7/objs/x64/vc2010 >>> >>> Previous JDK Settings: >>> PREVIOUS_RELEASE_PATH = USING-PREVIOUS_RELEASE_IMAGE >>> ALT_PREVIOUS_RELEASE_PATH = >>> PREVIOUS_JDK_VERSION = 1.6.0 >>> ALT_PREVIOUS_JDK_VERSION = >>> PREVIOUS_JDK_FILE = >>> ALT_PREVIOUS_JDK_FILE = >>> PREVIOUS_JRE_FILE = >>> ALT_PREVIOUS_JRE_FILE = >>> PREVIOUS_RELEASE_IMAGE = c:/jdk1.6 >>> ALT_PREVIOUS_RELEASE_IMAGE = >>> >>> >>> >>> >>> WARNING: To build Java 2 SDK 1.7.0 you need : >>> VS2010 - link.exe version '10.00.30319.01' >>> Specifically the Visual Studio 10 link.exe. >>> You appear to be using Linker version '10.00.40219.01' >>> >>> ERROR: FreeType version 2.3.0 or higher is required. >>> make[2]: Entering directory '/cygdrive/e/research/open/jdk7/jdk/make/tools/freetypecheck' >>> /usr/bin/mkdir -p e:/research/open/output_amd64/btbins >>> rm -f e:/research/open/output_amd64/btbins/freetype_versioncheck.exe >>> C:/PROGRA~2/MICROS~1.0/Common7/Tools/../../Vc/bin/amd64/cl /nologo /c -Ie:/freetype-2.4.7/include -Ie:/freetype-2.4.7/include/freetype2 -DREQUIRED_FREETYPE_VERSION=2.3.0 -Foe:/research/open/output_amd64/btbins/freetype_versioncheck.obj freetypecheck.c >>> freetypecheck.c >>> C:/PROGRA~2/MICROS~1.0/Common7/Tools/../../Vc/bin/amd64/link e:/freetype-2.4.7/objs/x64/vc2010/freetype.lib /manifest /OUT:e:/research/open/output_amd64/btbins/freetype_versioncheck.exe e:/research/open/output_amd64/btbins/freetype_versioncheck.obj >>> Microsoft (R) Incremental Linker Version 10.00.40219.01 >>> Copyright (C) Microsoft Corporation. All rights reserved. >>> >>> >>> LIBCMT.lib(crt0.obj) : error LNK2019: unresolved external symbol __imp_GetCommandLineA referenced in function __tmainCRTStartup >>> LIBCMT.lib(longjmp.obj) : error LNK2019: unresolved external symbol RtlUnwindEx referenced in function longjmp >>> LIBCMT.lib(jmpuwind.obj) : error LNK2001: unresolved external symbol RtlUnwindEx >>> LIBCMT.lib(malloc.obj) : error LNK2019: unresolved external symbol __imp_HeapAlloc referenced in function _heap_alloc >>> LIBCMT.lib(calloc_impl.obj) : error LNK2001: unresolved external symbol __imp_HeapAlloc >>> LIBCMT.lib(chsize.obj) : error LNK2001: unresolved external symbol __imp_HeapAlloc >>> LIBCMT.lib(osfinfo.obj) : error LNK2019: unresolved external symbol __imp_GetLastError referenced in function _set_osfhnd >>> LIBCMT.lib(commit.obj) : error LNK2001: unresolved external symbol __imp_GetLastError >>> LIBCMT.lib(open.obj) : error LNK2001: unresolved external symbol __imp_GetLastError >>> LIBCMT.lib(chsize.obj) : error LNK2001: unresolved external symbol __imp_GetLastError >>> LIBCMT.lib(write.obj) : error LNK2001: unresolved external symbol __imp_GetLastError >>> LIBCMT.lib(winsig.obj) : error LNK2001: unresolved external symbol __imp_GetLastError >>> LIBCMT.lib(rand_s.obj) : error LNK2001: unresolved external symbol __imp_GetLastError >>> LIBCMT.lib(inithelp.obj) : error LNK2001: unresolved external symbol __imp_GetLastError >>> LIBCMT.lib(read.obj) : error LNK2001: unresolved external symbol __imp_GetLastError >>> LIBCMT.lib(lseek.obj) : error LNK2001: unresolved external symbol __imp_GetLastError >>> LIBCMT.lib(wctomb.obj) : error LNK2001: unresolved external symbol __imp_GetLastError >>> LIBCMT.lib(lseeki64.obj) : error LNK2001: unresolved external symbol __imp_GetLastError >>> LIBCMT.lib(realloc.obj) : error LNK2001: unresolved external symbol __imp_GetLastError >>> LIBCMT.lib(free.obj) : error LNK2001: unresolved external symbol __imp_GetLastError >>> LIBCMT.lib(tidtable.obj) : error LNK2001: unresolved external symbol __imp_GetLastError >>> LIBCMT.lib(close.obj) : error LNK2001: unresolved external symbol __imp_GetLastError >>> LIBCMT.lib(realloc.obj) : error LNK2019: unresolved external symbol __imp_HeapReAlloc referenced in function realloc >>> LIBCMT.lib(free.obj) : error LNK2019: unresolved external symbol __imp_HeapFree referenced in function free >>> LIBCMT.lib(chsize.obj) : error LNK2001: unresolved external symbol __imp_HeapFree >>> LIBCMT.lib(chandler.obj) : error LNK2019: unresolved external symbol __imp_RtlUnwindEx referenced in function __C_specific_handler >>> LIBCMT.lib(_file.obj) : error LNK2019: unresolved external symbol __imp_EnterCriticalSection referenced in function _lock_file >>> LIBCMT.lib(stream.obj) : error LNK2001: unresolved external symbol __imp_EnterCriticalSection >>> LIBCMT.lib(mlock.obj) : error LNK2001: unresolved external symbol __imp_EnterCriticalSection >>> LIBCMT.lib(osfinfo.obj) : error LNK2001: unresolved external symbol __imp_EnterCriticalSection >>> LIBCMT.lib(_file.obj) : error LNK2019: unresolved external symbol __imp_LeaveCriticalSection referenced in function _unlock_file >>> LIBCMT.lib(mlock.obj) : error LNK2001: unresolved external symbol __imp_LeaveCriticalSection >>> LIBCMT.lib(osfinfo.obj) : error LNK2001: unresolved external symbol __imp_LeaveCriticalSection >>> LIBCMT.lib(rand_s.obj) : error LNK2001: unresolved external symbol __imp_DecodePointer >>> LIBCMT.lib(onexit.obj) : error LNK2001: unresolved external symbol __imp_DecodePointer >>> LIBCMT.lib(crtmboxw.obj) : error LNK2001: unresolved external symbol __imp_DecodePointer >>> LIBCMT.lib(outputs.obj) : error LNK2001: unresolved external symbol __imp_DecodePointer >>> LIBCMT.lib(outputp.obj) : error LNK2001: unresolved external symbol __imp_DecodePointer >>> LIBCMT.lib(hooks.obj) : error LNK2001: unresolved external symbol __imp_DecodePointer >>> LIBCMT.lib(winsig.obj) : error LNK2001: unresolved external symbol __imp_DecodePointer >>> LIBCMT.lib(output.obj) : error LNK2019: unresolved external symbol __imp_DecodePointer referenced in function _output_l >>> LIBCMT.lib(invarg.obj) : error LNK2001: unresolved external symbol __imp_DecodePointer >>> LIBCMT.lib(crt0dat.obj) : error LNK2001: unresolved external symbol __imp_DecodePointer >>> LIBCMT.lib(handler.obj) : error LNK2001: unresolved external symbol __imp_DecodePointer >>> LIBCMT.lib(invarg.obj) : error LNK2019: unresolved external symbol __imp_UnhandledExceptionFilter referenced in function _call_reportfault >>> LIBCMT.lib(gs_report.obj) : error LNK2001: unresolved external symbol __imp_UnhandledExceptionFilter >>> LIBCMT.lib(invarg.obj) : error LNK2019: unresolved external symbol __imp_SetUnhandledExceptionFilter referenced in function _call_reportfault >>> LIBCMT.lib(gs_report.obj) : error LNK2001: unresolved external symbol __imp_SetUnhandledExceptionFilter >>> LIBCMT.lib(unhandld.obj) : error LNK2001: unresolved external symbol __imp_SetUnhandledExceptionFilter >>> LIBCMT.lib(invarg.obj) : error LNK2019: unresolved external symbol __imp_IsDebuggerPresent referenced in function _call_reportfault >>> LIBCMT.lib(gs_report.obj) : error LNK2001: unresolved external symbol __imp_IsDebuggerPresent >>> LIBCMT.lib(invarg.obj) : error LNK2019: unresolved external symbol RtlVirtualUnwind referenced in function _call_reportfault >>> LIBCMT.lib(gs_report.obj) : error LNK2001: unresolved external symbol RtlVirtualUnwind >>> LIBCMT.lib(invarg.obj) : error LNK2019: unresolved external symbol RtlLookupFunctionEntry referenced in function _call_reportfault >>> LIBCMT.lib(gs_report.obj) : error LNK2001: unresolved external symbol RtlLookupFunctionEntry >>> LIBCMT.lib(invarg.obj) : error LNK2019: unresolved external symbol __imp_RtlCaptureContext referenced in function _call_reportfault >>> LIBCMT.lib(gs_report.obj) : error LNK2001: unresolved external symbol __imp_RtlCaptureContext >>> LIBCMT.lib(crtmboxw.obj) : error LNK2001: unresolved external symbol __imp_EncodePointer >>> LIBCMT.lib(hooks.obj) : error LNK2001: unresolved external symbol __imp_EncodePointer >>> LIBCMT.lib(winsig.obj) : error LNK2001: unresolved external symbol __imp_EncodePointer >>> LIBCMT.lib(rand_s.obj) : error LNK2001: unresolved external symbol __imp_EncodePointer >>> LIBCMT.lib(onexit.obj) : error LNK2019: unresolved external symbol __imp_EncodePointer referenced in function _onexit >>> LIBCMT.lib(invarg.obj) : error LNK2001: unresolved external symbol __imp_EncodePointer >>> LIBCMT.lib(tidtable.obj) : error LNK2001: unresolved external symbol __imp_EncodePointer >>> LIBCMT.lib(handler.obj) : error LNK2001: unresolved external symbol __imp_EncodePointer >>> LIBCMT.lib(cmiscdat.obj) : error LNK2001: unresolved external symbol __imp_EncodePointer >>> LIBCMT.lib(invarg.obj) : error LNK2019: unresolved external symbol __imp_TerminateProcess referenced in function _invoke_watson >>> LIBCMT.lib(gs_report.obj) : error LNK2001: unresolved external symbol __imp_TerminateProcess >>> LIBCMT.lib(invarg.obj) : error LNK2019: unresolved external symbol __imp_GetCurrentProcess referenced in function _invoke_watson >>> LIBCMT.lib(gs_report.obj) : error LNK2001: unresolved external symbol __imp_GetCurrentProcess >>> LIBCMT.lib(crt0dat.obj) : error LNK2019: unresolved external symbol __imp_GetProcAddress referenced in function __crtCorExitProcess >>> LIBCMT.lib(rand_s.obj) : error LNK2001: unresolved external symbol __imp_GetProcAddress >>> LIBCMT.lib(crtmboxw.obj) : error LNK2001: unresolved external symbol __imp_GetProcAddress >>> LIBCMT.lib(crt0dat.obj) : error LNK2019: unresolved external symbol __imp_GetModuleHandleW referenced in function __crtCorExitProcess >>> LIBCMT.lib(crt0dat.obj) : error LNK2019: unresolved external symbol __imp_ExitProcess referenced in function __crtExitProcess >>> LIBCMT.lib(crt0msg.obj) : error LNK2019: unresolved external symbol __imp_WriteFile referenced in function _NMSG_WRITE >>> LIBCMT.lib(write.obj) : error LNK2001: unresolved external symbol __imp_WriteFile >>> LIBCMT.lib(crt0msg.obj) : error LNK2019: unresolved external symbol __imp_GetStdHandle referenced in function _NMSG_WRITE >>> LIBCMT.lib(ioinit.obj) : error LNK2001: unresolved external symbol __imp_GetStdHandle >>> LIBCMT.lib(crt0msg.obj) : error LNK2019: unresolved external symbol __imp_GetModuleFileNameW referenced in function _NMSG_WRITE >>> LIBCMT.lib(stdargv.obj) : error LNK2019: unresolved external symbol __imp_GetModuleFileNameA referenced in function _setargv >>> LIBCMT.lib(a_env.obj) : error LNK2019: unresolved external symbol __imp_FreeEnvironmentStringsW referenced in function __crtGetEnvironmentStringsA >>> LIBCMT.lib(a_loc.obj) : error LNK2001: unresolved external symbol __imp_WideCharToMultiByte >>> LIBCMT.lib(a_env.obj) : error LNK2019: unresolved external symbol __imp_WideCharToMultiByte referenced in function __crtGetEnvironmentStringsA >>> LIBCMT.lib(wctomb.obj) : error LNK2001: unresolved external symbol __imp_WideCharToMultiByte >>> LIBCMT.lib(write.obj) : error LNK2001: unresolved external symbol __imp_WideCharToMultiByte >>> LIBCMT.lib(a_map.obj) : error LNK2001: unresolved external symbol __imp_WideCharToMultiByte >>> LIBCMT.lib(a_env.obj) : error LNK2019: unresolved external symbol __imp_GetEnvironmentStringsW referenced in function __crtGetEnvironmentStringsA >>> LIBCMT.lib(ioinit.obj) : error LNK2019: unresolved external symbol __imp_SetHandleCount referenced in function _ioinit >>> LIBCMT.lib(ioinit.obj) : error LNK2019: unresolved external symbol __imp_InitializeCriticalSectionAndSpinCount referenced in function _ioinit >>> LIBCMT.lib(stream.obj) : error LNK2001: unresolved external symbol __imp_InitializeCriticalSectionAndSpinCount >>> LIBCMT.lib(mlock.obj) : error LNK2001: unresolved external symbol __imp_InitializeCriticalSectionAndSpinCount >>> LIBCMT.lib(osfinfo.obj) : error LNK2001: unresolved external symbol __imp_InitializeCriticalSectionAndSpinCount >>> LIBCMT.lib(ioinit.obj) : error LNK2019: unresolved external symbol __imp_GetFileType referenced in function _ioinit >>> LIBCMT.lib(osfinfo.obj) : error LNK2001: unresolved external symbol __imp_GetFileType >>> LIBCMT.lib(open.obj) : error LNK2001: unresolved external symbol __imp_GetFileType >>> LIBCMT.lib(ioinit.obj) : error LNK2019: unresolved external symbol __imp_GetStartupInfoW referenced in function _ioinit >>> LIBCMT.lib(ioinit.obj) : error LNK2019: unresolved external symbol __imp_DeleteCriticalSection referenced in function _ioterm >>> LIBCMT.lib(closeall.obj) : error LNK2001: unresolved external symbol __imp_DeleteCriticalSection >>> LIBCMT.lib(mlock.obj) : error LNK2001: unresolved external symbol __imp_DeleteCriticalSection >>> LIBCMT.lib(tidtable.obj) : error LNK2019: unresolved external symbol __imp_FlsGetValue referenced in function __fls_getvalue >>> LIBCMT.lib(tidtable.obj) : error LNK2019: unresolved external symbol __imp_FlsSetValue referenced in function __fls_setvalue >>> LIBCMT.lib(tidtable.obj) : error LNK2019: unresolved external symbol __imp_FlsFree referenced in function _mtterm >>> LIBCMT.lib(tidtable.obj) : error LNK2019: unresolved external symbol __imp_SetLastError referenced in function _getptd_noexit >>> LIBCMT.lib(tidtable.obj) : error LNK2019: unresolved external symbol __imp_GetCurrentThreadId referenced in function _getptd_noexit >>> LIBCMT.lib(gs_support.obj) : error LNK2001: unresolved external symbol __imp_GetCurrentThreadId >>> LIBCMT.lib(tidtable.obj) : error LNK2019: unresolved external symbol __imp_GetCurrentThread referenced in function __threadhandle >>> LIBCMT.lib(tidtable.obj) : error LNK2019: unresolved external symbol __imp_FlsAlloc referenced in function _mtinit >>> LIBCMT.lib(heapinit.obj) : error LNK2019: unresolved external symbol __imp_HeapSetInformation referenced in function _heap_init >>> LIBCMT.lib(heapinit.obj) : error LNK2019: unresolved external symbol __imp_GetVersion referenced in function _heap_init >>> LIBCMT.lib(heapinit.obj) : error LNK2019: unresolved external symbol __imp_HeapCreate referenced in function _heap_init >>> LIBCMT.lib(heapinit.obj) : error LNK2019: unresolved external symbol __imp_HeapDestroy referenced in function _heap_term >>> LIBCMT.lib(gs_support.obj) : error LNK2019: unresolved external symbol __imp_QueryPerformanceCounter referenced in function __security_init_cookie >>> LIBCMT.lib(gs_support.obj) : error LNK2019: unresolved external symbol __imp_GetTickCount referenced in function __security_init_cookie >>> LIBCMT.lib(gs_support.obj) : error LNK2019: unresolved external symbol __imp_GetCurrentProcessId referenced in function __security_init_cookie >>> LIBCMT.lib(gs_support.obj) : error LNK2019: unresolved external symbol __imp_GetSystemTimeAsFileTime referenced in function __security_init_cookie >>> LIBCMT.lib(close.obj) : error LNK2019: unresolved external symbol __imp_CloseHandle referenced in function _close_nolock >>> LIBCMT.lib(open.obj) : error LNK2001: unresolved external symbol __imp_CloseHandle >>> LIBCMT.lib(initcon.obj) : error LNK2001: unresolved external symbol __imp_CloseHandle >>> LIBCMT.lib(read.obj) : error LNK2019: unresolved external symbol __imp_MultiByteToWideChar referenced in function _read_nolock >>> LIBCMT.lib(a_map.obj) : error LNK2001: unresolved external symbol __imp_MultiByteToWideChar >>> LIBCMT.lib(a_str.obj) : error LNK2001: unresolved external symbol __imp_MultiByteToWideChar >>> LIBCMT.lib(mbtowc.obj) : error LNK2001: unresolved external symbol __imp_MultiByteToWideChar >>> LIBCMT.lib(read.obj) : error LNK2019: unresolved external symbol __imp_ReadFile referenced in function _read_nolock >>> LIBCMT.lib(lseek.obj) : error LNK2019: unresolved external symbol __imp_SetFilePointer referenced in function _lseek_nolock >>> LIBCMT.lib(lseeki64.obj) : error LNK2001: unresolved external symbol __imp_SetFilePointer >>> LIBCMT.lib(crtheap.obj) : error LNK2019: unresolved external symbol __imp_Sleep referenced in function wait_a_bit >>> LIBCMT.lib(mlock.obj) : error LNK2019: unresolved external symbol __imp_FatalAppExitA referenced in function _lockerr_exit >>> LIBCMT.lib(mbctype.obj) : error LNK2019: unresolved external symbol __imp_GetCPInfo referenced in function "void __cdecl setSBUpLow(struct threadmbcinfostruct *)" (?setSBUpLow@@YAXPEAUthreadmbcinfostruct@@@Z) >>> LIBCMT.lib(initctyp.obj) : error LNK2001: unresolved external symbol __imp_GetCPInfo >>> LIBCMT.lib(mbctype.obj) : error LNK2019: unresolved external symbol __imp_GetACP referenced in function "int __cdecl getSystemCP(int)" (?getSystemCP@@YAHH at Z) >>> LIBCMT.lib(getqloc.obj) : error LNK2001: unresolved external symbol __imp_GetACP >>> LIBCMT.lib(mbctype.obj) : error LNK2019: unresolved external symbol __imp_GetOEMCP referenced in function "int __cdecl getSystemCP(int)" (?getSystemCP@@YAHH at Z) >>> LIBCMT.lib(mbctype.obj) : error LNK2019: unresolved external symbol __imp_IsValidCodePage referenced in function _setmbcp_nolock >>> LIBCMT.lib(getqloc.obj) : error LNK2001: unresolved external symbol __imp_IsValidCodePage >>> LIBCMT.lib(write.obj) : error LNK2019: unresolved external symbol __imp_GetConsoleCP referenced in function _write_nolock >>> LIBCMT.lib(write.obj) : error LNK2019: unresolved external symbol __imp_GetConsoleMode referenced in function _write_nolock >>> LIBCMT.lib(winsig.obj) : error LNK2019: unresolved external symbol __imp_SetConsoleCtrlHandler referenced in function signal >>> LIBCMT.lib(rand_s.obj) : error LNK2019: unresolved external symbol __imp_FreeLibrary referenced in function rand_s >>> LIBCMT.lib(rand_s.obj) : error LNK2019: unresolved external symbol __imp_LoadLibraryW referenced in function rand_s >>> LIBCMT.lib(crtmboxw.obj) : error LNK2001: unresolved external symbol __imp_LoadLibraryW >>> LIBCMT.lib(inithelp.obj) : error LNK2019: unresolved external symbol __imp_GetLocaleInfoW referenced in function __getlocaleinfo >>> LIBCMT.lib(a_loc.obj) : error LNK2001: unresolved external symbol __imp_GetLocaleInfoW >>> LIBCMT.lib(getqloc.obj) : error LNK2001: unresolved external symbol __imp_GetLocaleInfoW >>> LIBCMT.lib(osfinfo.obj) : error LNK2019: unresolved external symbol __imp_SetStdHandle referenced in function _set_osfhnd >>> LIBCMT.lib(commit.obj) : error LNK2019: unresolved external symbol __imp_FlushFileBuffers referenced in function _commit >>> LIBCMT.lib(open.obj) : error LNK2019: unresolved external symbol __imp_CreateFileA referenced in function _tsopen_nolock >>> LIBCMT.lib(a_map.obj) : error LNK2019: unresolved external symbol __imp_LCMapStringW referenced in function "int __cdecl __crtLCMapStringA_stat(struct localeinfo_struct *,unsigned long,unsigned long,char const *,int,char *,int,int,int)" (?__crtLCMapStringA_stat@@YAHPEAUlocaleinfo_struct@@KKPEBDHPEADHHH at Z) >>> LIBCMT.lib(a_str.obj) : error LNK2019: unresolved external symbol __imp_GetStringTypeW referenced in function "int __cdecl __crtGetStringTypeA_stat(struct localeinfo_struct *,unsigned long,char const *,int,unsigned short *,int,int,int)" (?__crtGetStringTypeA_stat@@YAHPEAUlocaleinfo_struct@@KPEBDHPEAGHHH at Z) >>> LIBCMT.lib(iswctype.obj) : error LNK2001: unresolved external symbol __imp_GetStringTypeW >>> LIBCMT.lib(putwch.obj) : error LNK2019: unresolved external symbol __imp_WriteConsoleW referenced in function _putwch_nolock >>> LIBCMT.lib(msize.obj) : error LNK2019: unresolved external symbol __imp_HeapSize referenced in function _msize >>> LIBCMT.lib(chsize.obj) : error LNK2019: unresolved external symbol __imp_SetEndOfFile referenced in function _chsize_nolock >>> LIBCMT.lib(chsize.obj) : error LNK2019: unresolved external symbol __imp_GetProcessHeap referenced in function _chsize_nolock >>> LIBCMT.lib(getqloc.obj) : error LNK2019: unresolved external symbol __imp_GetUserDefaultLCID referenced in function GetLcidFromDefault >>> LIBCMT.lib(getqloc.obj) : error LNK2019: unresolved external symbol __imp_GetLocaleInfoA referenced in function CountryEnumProc >>> LIBCMT.lib(getqloc.obj) : error LNK2019: unresolved external symbol __imp_EnumSystemLocalesA referenced in function GetLcidFromCountry >>> LIBCMT.lib(getqloc.obj) : error LNK2019: unresolved external symbol __imp_IsValidLocale referenced in function __get_qualified_locale >>> LIBCMT.lib(initcon.obj) : error LNK2019: unresolved external symbol __imp_CreateFileW referenced in function __initconout >>> e:/research/open/output_amd64/btbins/freetype_versioncheck.exe : fatal error LNK1120: 79 unresolved externals >>> Makefile:68: recipe for target 'e:/research/open/output_amd64/btbins/freetype_versioncheck.exe' failed >>> make[2]: Leaving directory '/cygdrive/e/research/open/jdk7/jdk/make/tools/freetypecheck' >>> Failed to build freetypecheck. >>> >>> >>> Exiting because of the above error(s). >>> >>> make/sanity-rules.gmk:71: recipe for target 'post-sanity' failed >>> make: *** [post-sanity] Error 1 >>> >>> >>> ------ >>> >>> >>> and this is my command: >>> >>> >>> --- >>> make ARCH_DATA_MODEL=64 \ >>> ALT_OUTPUTDIR=e:/research/open/output_amd64 \ >>> ALT_FREETYPE_LIB_PATH=e:/freetype-2.4.7/objs/x64/vc2010 \ >>> ALT_FREETYPE_HEADERS_PATH=e:/freetype-2.4.7/include \ >>> ALT_BOOTDIR=c:/jdk1.6 \ >>> ALT_DROPS_DIR=e:/research/open/ALT_DROPS_DIR \ >>> ALT_MSVCRNN_DLL_PATH=e:/research/jdkBuild/msvcr100 \ >>> HOTSPOT_BUILD_JOBS=4 \ >>> PARALLEL_COMPILE_JOBS=4 \ >>> 2>&1 | tee e:/research/open/output_amd64.log >>> >> >> >> -- >> -Alex -- -Alex From gnu.andrew at redhat.com Tue Jul 7 18:50:48 2015 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 7 Jul 2015 14:50:48 -0400 (EDT) Subject: JDK 7 Updates: Policy Changes In-Reply-To: <55912170.2050804@redhat.com> References: <55912170.2050804@redhat.com> Message-ID: <1658646930.13781455.1436295048326.JavaMail.zimbra@redhat.com> snip... > > Which bug database should we use? The OpenJDK JIRA is the obvious > choice, but access is very limited. For OpenJDK 6 updates we have > been using the database at https://java.net/jira/browse/OPENJDK6, > which is much more accessible. Should we do the same for OpenJDK 7? > I'm working on the assumption so far that we'll use an OPENJDK7 instance equivalent to the one we did for OpenJDK 6. As you say, access to the OpenJDK JIRA is limited and it would be difficult for us to e.g. add milestones, additional users, etc. It's also replete with references to proprietary 7 releases, such as u85, which would only cause confusion. Most importantly, we need somewhere to host source tarball releases and the java.net instance would provide this too. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From omajid at redhat.com Tue Jul 7 19:09:50 2015 From: omajid at redhat.com (Omair Majid) Date: Tue, 7 Jul 2015 15:09:50 -0400 Subject: JDK 7 Updates: Policy Changes In-Reply-To: <1658646930.13781455.1436295048326.JavaMail.zimbra@redhat.com> References: <55912170.2050804@redhat.com> <1658646930.13781455.1436295048326.JavaMail.zimbra@redhat.com> Message-ID: <20150707190949.GC11567@redhat.com> * Andrew Hughes [2015-07-07 14:51]: > I'm working on the assumption so far that we'll use an OPENJDK7 > instance equivalent to the one we did for OpenJDK 6. As you say, > access to the OpenJDK JIRA is limited and it would be difficult > for us to e.g. add milestones, additional users, etc. There should definitely some change in the OpenJDK JIRA to allow the project lead to make the changes they see fit (including adding milestones and what not). I am not sure I am convinced by additional users, though: if you are committing to OpenJDK 7, you have an OpenJDK user id and can access the bug tracker. > It's also > replete with references to proprietary 7 releases, such as u85, > which would only cause confusion. I wonder if we can use a separate project in the official OpenJDK bug tracker. There are existing projects like KONA and DIO there and perhaps we can create OPENJDK7, if the official JDK project is not usable. If not, then I agree about falling back to a separate project on java.net. > Most importantly, we need somewhere to host source tarball releases > and the java.net instance would provide this too. In the short term, agreed. But perhaps, in the long run (I am thinking when 8 goes through something like this) it might be better to have a project-specific place to publish project-official source releases (if any). I can't imagine that other projects would object to having an optional place where they can upload releases if they want. I see that Oracle also seems to be using java.net for their proprietary JDK 9 builds [1] too. I am not sure we want something like that, because we will be trying to distribute open source tarballs under licence terms matching the rest of the OpenJDK project. Thanks, Omair [1] https://jdk9.java.net/ -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From gnu.andrew at redhat.com Tue Jul 7 20:28:17 2015 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 7 Jul 2015 16:28:17 -0400 (EDT) Subject: JDK 7 Updates: Policy Changes In-Reply-To: <20150707190949.GC11567@redhat.com> References: <55912170.2050804@redhat.com> <1658646930.13781455.1436295048326.JavaMail.zimbra@redhat.com> <20150707190949.GC11567@redhat.com> Message-ID: <785474877.13847235.1436300897090.JavaMail.zimbra@redhat.com> ----- Original Message ----- > * Andrew Hughes [2015-07-07 14:51]: > > I'm working on the assumption so far that we'll use an OPENJDK7 > > instance equivalent to the one we did for OpenJDK 6. As you say, > > access to the OpenJDK JIRA is limited and it would be difficult > > for us to e.g. add milestones, additional users, etc. > > There should definitely some change in the OpenJDK JIRA to allow the > project lead to make the changes they see fit (including adding > milestones and what not). I am not sure I am convinced by additional > users, though: if you are committing to OpenJDK 7, you have an OpenJDK > user id and can access the bug tracker. > Going by OpenJDK 6, it needs to be more than just the project lead... Your idea about users is nice in theory, but it doesn't seem to work out in practice. > > It's also > > replete with references to proprietary 7 releases, such as u85, > > which would only cause confusion. > > I wonder if we can use a separate project in the official OpenJDK bug > tracker. There are existing projects like KONA and DIO there and perhaps > we can create OPENJDK7, if the official JDK project is not usable. > > If not, then I agree about falling back to a separate project on > java.net. I don't really see the difference; either way, we use a different namespace of OPENJDK7-x IDs, not OpenJDK bug IDs. > > > Most importantly, we need somewhere to host source tarball releases > > and the java.net instance would provide this too. > > In the short term, agreed. But perhaps, in the long run (I am thinking > when 8 goes through something like this) it might be better to have a > project-specific place to publish project-official source releases (if > any). I can't imagine that other projects would object to having an > optional place where they can upload releases if they want. > How is this any different to what I proposed? I guess my main point is that I'd rather we get updates out to users as soon as possible, rather than risk being stalled waiting for Oracle admins. If that means having a less-than-ideal setup, but one where we have control, than so be it. Of course, if someone from Oracle wants to jump in and tell us all this stuff is ready to go right now, I'm all for it. > I see that Oracle also seems to be using java.net for their proprietary > JDK 9 builds [1] too. I am not sure we want something like that, because > we will be trying to distribute open source tarballs under licence terms > matching the rest of the OpenJDK project. No, we'll not be uploading binaries, if that's what you mean. > > Thanks, > Omair > > [1] https://jdk9.java.net/ > > -- > PGP Key: 66484681 (http://pgp.mit.edu/) > Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From omajid at redhat.com Tue Jul 7 20:35:48 2015 From: omajid at redhat.com (Omair Majid) Date: Tue, 7 Jul 2015 16:35:48 -0400 Subject: JDK 7 Updates: Policy Changes In-Reply-To: <785474877.13847235.1436300897090.JavaMail.zimbra@redhat.com> References: <55912170.2050804@redhat.com> <1658646930.13781455.1436295048326.JavaMail.zimbra@redhat.com> <20150707190949.GC11567@redhat.com> <785474877.13847235.1436300897090.JavaMail.zimbra@redhat.com> Message-ID: <20150707203548.GH11567@redhat.com> * Andrew Hughes [2015-07-07 16:28]: > Your idea about users is nice in theory, but it doesn't seem to work > out in practice. Can you elaborate? It seems to me like everyone who used the OpenJDK6 bug tracker was already an OpenJDK committer. > How is this any different to what I proposed? It's really not :) > I guess my main point is that I'd rather we get updates out to users as > soon as possible, rather than risk being stalled waiting for Oracle admins. > If that means having a less-than-ideal setup, but one where we have > control, than so be it. Yes, I am wondering more about the longer term ways to improve things. I agree that in the short term getting updates out to users is more important. But I don't want us to simply repeat what we did for JDK 6 when JDK 8 rolls around too. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From volker.simonis at gmail.com Tue Jul 7 22:37:38 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 8 Jul 2015 00:37:38 +0200 Subject: JDK 7 Updates: Policy Changes In-Reply-To: <55912170.2050804@redhat.com> References: <55912170.2050804@redhat.com> Message-ID: On Monday, June 29, 2015, Andrew Haley wrote: > I'm looking at the existing rules for JDK 7 Updates, and I can't see > much that I think should be changed. There are some process rules which > we may not follow closely, and we should review them. > > https://wiki.openjdk.java.net/display/jdk7u/JDK+7+Updates%3A+Ground+Rules > > However, there are some issues we should dicuss. > > Some of the content of the Wiki is out of date. In particular, the > "JDK 7 Update Project Proposal Q & A" is somewhat misleading. I have > lightly edited it, but as much of what it refers to has passed it > perhaps makes more sense to delete it or replace it with something > which reflects reality. > > Such as: > > Which bug database should we use? The OpenJDK JIRA is the obvious > choice, but access is very limited. For OpenJDK 6 updates we have > been using the database at https://java.net/jira/browse/OPENJDK6, > which is much more accessible. Should we do the same for OpenJDK 7? > > All of the Linux distros and some others use the IcedTea 2.x forests > rather than the source trees at > http://hg.openjdk.java.net/jdk7u/jdk7u-dev. The IcedTea trees have a > lot of back-ported code, some of it essential. Should we apply these > patches to the JDK 7 Updates tree? > > Yes, because: > > It would make the official 7 Updates trees much better, fix bugs, > improve performance, etc. > > No, because: > > Everyone (at least on GNU/Linux systems) uses the IcedTea 2.x forests > anyway. It's a lot of work, and it's pointlessly moving furniture > around. > > I think we should go with "Yes", after proper patch review. The main > advantage, IMO, is that it would give us a chance to re-review these > patches and be sure that we still really need them. > > I agree with you Andrew and I'd really welcome if you merge the IcedTea patches into the JDK 7 update forest. I observed that there is some confusion out there among many Java users who don't know exactly if they ar using an "Oracle JDK", a vanilla "OpenJDK" or a version of "IcedTea" and very few understand the actual differences between these three version. Merging two of them may certainly simplify the situation. But there's one more thing to consider here: I don't know what patches you have in IcedTea but merging them into the OpenJDK jdk7u-dev forest can only be done under the Oracle Contribution Agreement. So if you should have any patches in IcedTea for which you do not have the permission to submit them under the OCA into the OpenJDK forest that would be problematic. Or do you have a similar agreement like the OCA in place for contributions to IcedTea which allows you reuse them under whatever license you like? Regards, Volker I welcome your comments. > > Andrew. > From aph at redhat.com Wed Jul 8 08:48:25 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 08 Jul 2015 09:48:25 +0100 Subject: JDK 7 Updates: Policy Changes In-Reply-To: References: <55912170.2050804@redhat.com> Message-ID: <559CE3D9.2000500@redhat.com> On 07/07/15 23:37, Volker Simonis wrote: > But there's one more thing to consider here: I don't know what patches you > have in IcedTea but merging them into the OpenJDK jdk7u-dev forest can only > be done under the Oracle Contribution Agreement. So if you should have any > patches in IcedTea for which you do not have the permission to submit them > under the OCA into the OpenJDK forest that would be problematic. I don't think that's a real problem because all patches have to be reviewed and as part of that process we will look at the author's OCA status. Andrew. From dalibor.topic at oracle.com Fri Jul 10 18:04:32 2015 From: dalibor.topic at oracle.com (dalibor topic) Date: Fri, 10 Jul 2015 20:04:32 +0200 Subject: JDK 7 Updates: Policy Changes In-Reply-To: <55912170.2050804@redhat.com> References: <55912170.2050804@redhat.com> Message-ID: <55A00930.2060804@oracle.com> On 29.06.2015 12:44, Andrew Haley wrote: > Which bug database should we use? The OpenJDK JIRA is the obvious > choice, but access is very limited. For OpenJDK 6 updates we have > been using the database at https://java.net/jira/browse/OPENJDK6, > which is much more accessible. Should we do the same for OpenJDK 7? If you foresee yourself continuing to work on JDK 7 updates for a while, and then also want to consider working on JDK 8 Updates at some point in the future, having to maintain a monotonically increasing amount of information about issues in multiple distinct places sounds like a rather problematic idea to me, fraught with all kinds of transaction costs. I assume based on other comments in the thread that part of the insecurity about using JBS is due to the JDK Project in JBS being simultaneously used by multiple different Projects. While there is a transaction cost argument to be made about the benefits of such sharing, I understand the inherent desire to stake out a claim on a space of one's own that doesn't need to be shared to reduce risk & friction and increase familiarity with a new tool & process. OpenJDK Projects can have a corresponding Project in JBS, if the Project Lead so chooses and requests from the ops team. In such a case, requests to change the configuration would probably go from the Project Lead to the ops team. For a Project that does that with a fair amount of success, please see the CodeTools Project in JBS. Please see https://wiki.openjdk.java.net/display/general/JBS+Overview for details. In other words, if you have a fair idea of what your milestones look like for a few weeks down the road, it should not pose a massive challenge to ask the ops team in time to add them to a Project's JBS configuration, for example. As far as names go, I'd suggest using JDK7U or something like that, as the OpenJDK 7 Project completed its work back in 2011. Calling something new "OpenJDK 7" in 2015 would be rather irritating. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From aph at redhat.com Mon Jul 13 08:45:08 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 13 Jul 2015 09:45:08 +0100 Subject: JDK 7 Updates: Policy Changes In-Reply-To: <55A00930.2060804@oracle.com> References: <55912170.2050804@redhat.com> <55A00930.2060804@oracle.com> Message-ID: <55A37A94.5020002@redhat.com> On 10/07/15 19:04, dalibor topic wrote: > On 29.06.2015 12:44, Andrew Haley wrote: >> Which bug database should we use? The OpenJDK JIRA is the obvious >> choice, but access is very limited. For OpenJDK 6 updates we have >> been using the database at https://java.net/jira/browse/OPENJDK6, >> which is much more accessible. Should we do the same for OpenJDK 7? > > If you foresee yourself continuing to work on JDK 7 updates for a while, > and then also want to consider working on JDK 8 Updates at some point in > the future, having to maintain a monotonically increasing amount of > information about issues in multiple distinct places sounds like a > rather problematic idea to me, fraught with all kinds of transaction costs. Indeed it does. I'm not at all happy about it, but there seem to be no really nice solutions. > I assume based on other comments in the thread that part of the > insecurity about using JBS is due to the JDK Project in JBS being > simultaneously used by multiple different Projects. While there is a > transaction cost argument to be made about the benefits of such sharing, > I understand the inherent desire to stake out a claim on a space of > one's own that doesn't need to be shared to reduce risk & friction and > increase familiarity with a new tool & process. > > OpenJDK Projects can have a corresponding Project in JBS, if the Project > Lead so chooses and requests from the ops team. In such a case, requests > to change the configuration would probably go from the Project Lead to > the ops team. OK, so let me be sure I understand what you mean. We could create a new Project in JBS called (say) OpenJDK7u. It would therefore be separate from proprietary 7u. That sounds quite attractive. We'd still have the problem that only Authors could create and comment on bugs, but I think that's liveable. > like for a few weeks down the road, it should not pose a massive > challenge to ask the ops team in time to add them to a Project's JBS > configuration, for example. > > As far as names go, I'd suggest using JDK7U or something like that, > as the OpenJDK 7 Project completed its work back in 2011. Calling > something new "OpenJDK 7" in 2015 would be rather irritating. :-) Andrew. From dalibor.topic at oracle.com Mon Jul 13 15:25:35 2015 From: dalibor.topic at oracle.com (dalibor topic) Date: Mon, 13 Jul 2015 17:25:35 +0200 Subject: JDK 7 Updates: Policy Changes In-Reply-To: <55A37A94.5020002@redhat.com> References: <55912170.2050804@redhat.com> <55A00930.2060804@oracle.com> <55A37A94.5020002@redhat.com> Message-ID: <55A3D86F.1030605@oracle.com> On 13.07.2015 10:45, Andrew Haley wrote: > OK, so let me be sure I understand what you mean. We could create a > new Project in JBS called (say) OpenJDK7u. It would therefore be > separate from proprietary 7u. That sounds quite attractive. Yeah. > We'd still have the problem that only Authors could create and comment on > bugs, but I think that's liveable. Under the assumption that users detecting issues would continue to report and discuss them on their distributors' issue trackers first, as the distributor's binary they ran may carry additional changes not found in the OpenJDK JDK 7 Updates Project source code repositories, I believe that the number of situations where that restriction would play a role in practice would continue to be very, very small. Looking at the jdk6-dev traffic from the past 6 months seems to support that conclusion, fwiw: http://openjdk.markmail.org/search/?q=list%3Anet.java.openjdk.jdk6-dev+date%3A2015 cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Mon Jul 13 15:46:21 2015 From: dalibor.topic at oracle.com (dalibor topic) Date: Mon, 13 Jul 2015 17:46:21 +0200 Subject: JDK 7 Updates: Policy Changes In-Reply-To: <55A3D86F.1030605@oracle.com> References: <55912170.2050804@redhat.com> <55A00930.2060804@oracle.com> <55A37A94.5020002@redhat.com> <55A3D86F.1030605@oracle.com> Message-ID: <55A3DD4D.1080107@oracle.com> On 13.07.2015 17:25, dalibor topic wrote: > > > On 13.07.2015 10:45, Andrew Haley wrote: >> OK, so let me be sure I understand what you mean. We could create a >> new Project in JBS called (say) OpenJDK7u. It would therefore be >> separate from proprietary 7u. That sounds quite attractive. > > Yeah. On a further tangent, when picking JBS names, short is beautiful - so I'd suggest picking JDK7U over longer alternatives. Your wrists will thank you each time you need to refer to a specific issue. ;) cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From aph at redhat.com Mon Jul 13 15:47:23 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 13 Jul 2015 16:47:23 +0100 Subject: JDK 7 Updates: Policy Changes In-Reply-To: <55A3DD4D.1080107@oracle.com> References: <55912170.2050804@redhat.com> <55A00930.2060804@oracle.com> <55A37A94.5020002@redhat.com> <55A3D86F.1030605@oracle.com> <55A3DD4D.1080107@oracle.com> Message-ID: <55A3DD8B.9010306@redhat.com> On 07/13/2015 04:46 PM, dalibor topic wrote: > so > I'd suggest picking JDK7U over longer alternatives But is there not a proprietary 7u project? Andrew. From omajid at redhat.com Mon Jul 20 15:36:26 2015 From: omajid at redhat.com (Omair Majid) Date: Mon, 20 Jul 2015 11:36:26 -0400 Subject: JDK 7 Updates: Policy Changes In-Reply-To: <55A00930.2060804@oracle.com> References: <55912170.2050804@redhat.com> <55A00930.2060804@oracle.com> Message-ID: <20150720153626.GB2520@redhat.com> Hi, * dalibor topic [2015-07-10 14:05]: > I assume based on other comments in the thread that part of the insecurity > about using JBS is due to the JDK Project in JBS being simultaneously used > by multiple different Projects. While there is a transaction cost argument > to be made about the benefits of such sharing, I understand the inherent > desire to stake out a claim on a space of one's own that doesn't need to be > shared to reduce risk & friction and increase familiarity with a new tool & > process. On the flip side, would it be possible to continue using the standard JDK project for this? Could be there be conflicts would Open and Proprietary bugs? If so, any tips to minimize those conflicts? Could the project lead (possibly with requests to ops@) create OpenJDK7-specific milestones and versions? Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From dalibor.topic at oracle.com Wed Jul 22 17:05:44 2015 From: dalibor.topic at oracle.com (dalibor topic) Date: Wed, 22 Jul 2015 19:05:44 +0200 Subject: JDK 7 Updates: Policy Changes In-Reply-To: <20150720153626.GB2520@redhat.com> References: <55912170.2050804@redhat.com> <55A00930.2060804@oracle.com> <20150720153626.GB2520@redhat.com> Message-ID: <55AFCD68.2010408@oracle.com> On 20.07.2015 17:36, Omair Majid wrote: > On the flip side, would it be possible to continue using the standard > JDK project for this? Yes, of course. > Could be there be conflicts would Open and > Proprietary bugs? If so, any tips to minimize those conflicts? An interesting potential source of conflict is that hgupdater creates backports entries in JBS. So you want to ensure that for jdk7u forests it's configured in a way that lets you easily distinguish issues. That's why we had this thread back in March: http://mail.openjdk.java.net/pipermail/jdk7u-dev/2015-March/010279.html > Could the project lead (possibly with requests to ops@) create > OpenJDK7-specific milestones and versions? The Project Lead would need to discuss such requirements with ops directly, I think, once you determine what they really are. A lot of that really depends on what workflow and development process makes most sense for the Project going forward, which also typically depends on who, from where and how many would be actively involved. For example, there is no special representation of the milestones like Rampdown Phase 2 in the JDK JBS Project. Instead, they were tracked separately - see https://wiki.openjdk.java.net/display/jdk7u/JDK+7u80 for an example. So if you want to continue working the same way the Project worked before, as Andrew seems to have indicated on the list in the past, there is no need to create OpenJDK 7 Updates specific milestones in JBS - you just document them on the wiki as was done before. The way the forests were configured when I left as Project Lead was to allow fixVersion=openjdk7u to be used in the manner described above. One could, for example, use the 'Resolved in Build' field of JBS issues to distinguish issues resolved in different future OpenJDK 7u builds without having to request the ops team to create additional versions (as the generic 'openjdk7' version already exists for that purpose). That way, when an issue X is marked as Fixed in Version OpenJDK 7, Resolved in Build b85, you could distinguish it from one that is marked as fixed in version 7u85, Resolved in Build b01 (as would for example be the case for issues addressed in Oracle's JDK). cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Wed Jul 22 17:08:26 2015 From: dalibor.topic at oracle.com (dalibor topic) Date: Wed, 22 Jul 2015 19:08:26 +0200 Subject: JDK 7 Updates: Policy Changes In-Reply-To: <55AFCD68.2010408@oracle.com> References: <55912170.2050804@redhat.com> <55A00930.2060804@oracle.com> <20150720153626.GB2520@redhat.com> <55AFCD68.2010408@oracle.com> Message-ID: <55AFCE0A.3030408@oracle.com> On 22.07.2015 19:05, dalibor topic wrote: > the generic 'openjdk7' version already exists for that purpose). typo - 'openjdk7u'. cheers, dalibor tolpic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From omajid at redhat.com Wed Jul 22 19:04:17 2015 From: omajid at redhat.com (Omair Majid) Date: Wed, 22 Jul 2015 15:04:17 -0400 Subject: JDK 7 Updates: Policy Changes In-Reply-To: <55AFCD68.2010408@oracle.com> References: <55912170.2050804@redhat.com> <55A00930.2060804@oracle.com> <20150720153626.GB2520@redhat.com> <55AFCD68.2010408@oracle.com> Message-ID: <20150722190416.GH3448@redhat.com> Hi Dalibor, Thanks for the responses! I have a few follow on questions that mostly stem from my unfamiliarity with JIRA. * dalibor topic [2015-07-22 13:05]: > On 20.07.2015 17:36, Omair Majid wrote: > >Could be there be conflicts would Open and > >Proprietary bugs? If so, any tips to minimize those conflicts? > > An interesting potential source of conflict is that hgupdater creates > backports entries in JBS. So you want to ensure that for jdk7u forests it's > configured in a way that lets you easily distinguish issues. > > That's why we had this thread back in March: > http://mail.openjdk.java.net/pipermail/jdk7u-dev/2015-March/010279.html What about manual OpenJDK7-specific issues? Can we create those manually? > For example, there is no special representation of the milestones like > Rampdown Phase 2 in the JDK JBS Project. Instead, they were tracked > separately - see https://wiki.openjdk.java.net/display/jdk7u/JDK+7u80 for an > example. Thank you, this clarifies things. Is there a way to say "We expect this bug to be resolved in OpenJDK 7u99" in JIRA? Bugzilla calls this "Target Milestone" [1]. > That way, when an issue X is marked as Fixed in Version OpenJDK 7, Resolved > in Build b85, you could distinguish it from one that is marked as fixed in > version 7u85, Resolved in Build b01 (as would for example be the case for > issues addressed in Oracle's JDK). Can we mark an issue as Fixed in Version OpenJDK 7, Resolved in Build 7u85? I expect future "releases" of OpenJDK7u to continue using the 7uXY versioning scheme that has been used in the past (I don't know if we will use many build numbers, however). Thanks, Omair [1] https://bugzilla.readthedocs.org/en/latest/using/understanding.html -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From gnu.andrew at redhat.com Wed Jul 22 20:28:52 2015 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 22 Jul 2015 16:28:52 -0400 (EDT) Subject: JDK 7 Updates: Policy Changes In-Reply-To: <20150722190416.GH3448@redhat.com> References: <55912170.2050804@redhat.com> <55A00930.2060804@oracle.com> <20150720153626.GB2520@redhat.com> <55AFCD68.2010408@oracle.com> <20150722190416.GH3448@redhat.com> Message-ID: <2032558441.2768520.1437596932320.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hi Dalibor, > > Thanks for the responses! I have a few follow on questions that mostly > stem from my unfamiliarity with JIRA. > > * dalibor topic [2015-07-22 13:05]: > > On 20.07.2015 17:36, Omair Majid wrote: > > >Could be there be conflicts would Open and > > >Proprietary bugs? If so, any tips to minimize those conflicts? > > > > An interesting potential source of conflict is that hgupdater creates > > backports entries in JBS. So you want to ensure that for jdk7u forests it's > > configured in a way that lets you easily distinguish issues. > > > > That's why we had this thread back in March: > > http://mail.openjdk.java.net/pipermail/jdk7u-dev/2015-March/010279.html > > What about manual OpenJDK7-specific issues? Can we create those > manually? I don't follow this. Are you saying something will happen when e.g. JDK-8043202 from the current security update [0] is pushed to the OpenJDK 7 tree? > > > For example, there is no special representation of the milestones like > > Rampdown Phase 2 in the JDK JBS Project. Instead, they were tracked > > separately - see https://wiki.openjdk.java.net/display/jdk7u/JDK+7u80 for > > an > > example. > > Thank you, this clarifies things. Is there a way to say "We expect this > bug to be resolved in OpenJDK 7u99" in JIRA? Bugzilla calls this "Target > Milestone" [1]. There is in JIRA, generally; we already do this in the OpenJDK 6 JIRA. [1] > > > That way, when an issue X is marked as Fixed in Version OpenJDK 7, Resolved > > in Build b85, you could distinguish it from one that is marked as fixed in > > version 7u85, Resolved in Build b01 (as would for example be the case for > > issues addressed in Oracle's JDK). > > Can we mark an issue as Fixed in Version OpenJDK 7, Resolved in Build > 7u85? I expect future "releases" of OpenJDK7u to continue using the 7uXY > versioning scheme that has been used in the past (I don't know if we > will use many build numbers, however). We're using OpenJDK 7u85 for the new update. I've currently bumped the build numbers only when a new merge to IcedTea is required, so I don't expect them to reach double digits unless we use them in a different way. IcedTea 2.6.1 [0] is based on 7u85 b01. There was a b00, but a couple of additional issues (OPENJDK7-04 and OPENJDK7-05) were found, resulting in b01 being tagged and merged. For the bug database, I'd need to be able to target bugs to a particular version so we can see easily what needs to be fixed in the update and not miss anything. This is how we currently operate with both IcedTea Bugzilla and (to a lesser extent) the OpenJDK 6 JIRA. We also use tracker bugs in IcedTea [2] but this is not essential. The OpenJDK 6 project was largely winding down before the change in leadership. If we expect the OpenJDK 7 project to be more active than OpenJDK 6 has been, then the bug database will be more active in turn. If it is going to be used for more than just quarterly security updates (I've seen suggestions on this list of moving IcedTea patches into it and having it replace that repository [3] ), then it's essential that we can point people to the bug database to file bugs. As far as I'm aware, the OpenJDK bug database is only accessible to OpenJDK committers, so this would be a blocker to using it for the OpenJDK 7 project. > > Thanks, > Omair > > [1] https://bugzilla.readthedocs.org/en/latest/using/understanding.html > > -- > PGP Key: 66484681 (http://pgp.mit.edu/) > Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 > [0] http://bitly.com/it20601 [1] https://java.net/jira/browse/OPENJDK6/fixforversion/17281/ [2] http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1698 [3] http://mail.openjdk.java.net/pipermail/jdk7u-dev/2015-July/010325.html -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From david.holmes at oracle.com Thu Jul 23 02:19:32 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Jul 2015 12:19:32 +1000 Subject: JDK 7 Updates: Policy Changes In-Reply-To: <20150722190416.GH3448@redhat.com> References: <55912170.2050804@redhat.com> <55A00930.2060804@oracle.com> <20150720153626.GB2520@redhat.com> <55AFCD68.2010408@oracle.com> <20150722190416.GH3448@redhat.com> Message-ID: <55B04F34.4070307@oracle.com> On 23/07/2015 5:04 AM, Omair Majid wrote: > Hi Dalibor, > > Thanks for the responses! I have a few follow on questions that mostly > stem from my unfamiliarity with JIRA. > > * dalibor topic [2015-07-22 13:05]: >> On 20.07.2015 17:36, Omair Majid wrote: >>> Could be there be conflicts would Open and >>> Proprietary bugs? If so, any tips to minimize those conflicts? >> >> An interesting potential source of conflict is that hgupdater creates >> backports entries in JBS. So you want to ensure that for jdk7u forests it's >> configured in a way that lets you easily distinguish issues. >> >> That's why we had this thread back in March: >> http://mail.openjdk.java.net/pipermail/jdk7u-dev/2015-March/010279.html > > What about manual OpenJDK7-specific issues? Can we create those > manually? > >> For example, there is no special representation of the milestones like >> Rampdown Phase 2 in the JDK JBS Project. Instead, they were tracked >> separately - see https://wiki.openjdk.java.net/display/jdk7u/JDK+7u80 for an >> example. > > Thank you, this clarifies things. Is there a way to say "We expect this > bug to be resolved in OpenJDK 7u99" in JIRA? Bugzilla calls this "Target > Milestone" [1]. > >> That way, when an issue X is marked as Fixed in Version OpenJDK 7, Resolved >> in Build b85, you could distinguish it from one that is marked as fixed in >> version 7u85, Resolved in Build b01 (as would for example be the case for >> issues addressed in Oracle's JDK). > > Can we mark an issue as Fixed in Version OpenJDK 7, Resolved in Build > 7u85? I expect future "releases" of OpenJDK7u to continue using the 7uXY > versioning scheme that has been used in the past (I don't know if we > will use many build numbers, however). 7u85 is not a "build number" but a "version". The allowed values for build numbers is constrained in JBS and currently only includes some things that are not build numbers due to the way the system had to be initialized from our internal bug systems (as I understand it). If you want to keep track of OpenJDK7u fixes relative to their Oracle JDK 7u counterparts then using backport issues may be the way to go. David > Thanks, > Omair > > [1] https://bugzilla.readthedocs.org/en/latest/using/understanding.html > From gnu.andrew at redhat.com Thu Jul 23 02:44:41 2015 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 22 Jul 2015 22:44:41 -0400 (EDT) Subject: JDK 7 Updates: Policy Changes In-Reply-To: <55B04F34.4070307@oracle.com> References: <55912170.2050804@redhat.com> <55A00930.2060804@oracle.com> <20150720153626.GB2520@redhat.com> <55AFCD68.2010408@oracle.com> <20150722190416.GH3448@redhat.com> <55B04F34.4070307@oracle.com> Message-ID: <1022983203.2932670.1437619481459.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 23/07/2015 5:04 AM, Omair Majid wrote: > > Hi Dalibor, > > > > Thanks for the responses! I have a few follow on questions that mostly > > stem from my unfamiliarity with JIRA. > > > > * dalibor topic [2015-07-22 13:05]: > >> On 20.07.2015 17:36, Omair Majid wrote: > >>> Could be there be conflicts would Open and > >>> Proprietary bugs? If so, any tips to minimize those conflicts? > >> > >> An interesting potential source of conflict is that hgupdater creates > >> backports entries in JBS. So you want to ensure that for jdk7u forests > >> it's > >> configured in a way that lets you easily distinguish issues. > >> > >> That's why we had this thread back in March: > >> http://mail.openjdk.java.net/pipermail/jdk7u-dev/2015-March/010279.html > > > > What about manual OpenJDK7-specific issues? Can we create those > > manually? > > > >> For example, there is no special representation of the milestones like > >> Rampdown Phase 2 in the JDK JBS Project. Instead, they were tracked > >> separately - see https://wiki.openjdk.java.net/display/jdk7u/JDK+7u80 for > >> an > >> example. > > > > Thank you, this clarifies things. Is there a way to say "We expect this > > bug to be resolved in OpenJDK 7u99" in JIRA? Bugzilla calls this "Target > > Milestone" [1]. > > > >> That way, when an issue X is marked as Fixed in Version OpenJDK 7, > >> Resolved > >> in Build b85, you could distinguish it from one that is marked as fixed in > >> version 7u85, Resolved in Build b01 (as would for example be the case for > >> issues addressed in Oracle's JDK). > > > > Can we mark an issue as Fixed in Version OpenJDK 7, Resolved in Build > > 7u85? I expect future "releases" of OpenJDK7u to continue using the 7uXY > > versioning scheme that has been used in the past (I don't know if we > > will use many build numbers, however). > > 7u85 is not a "build number" but a "version". The allowed values for > build numbers is constrained in JBS and currently only includes some > things that are not build numbers due to the way the system had to be > initialized from our internal bug systems (as I understand it). > > If you want to keep track of OpenJDK7u fixes relative to their Oracle > JDK 7u counterparts then using backport issues may be the way to go. > Indeed. I think what we want to say is fixed in version OpenJDK 7u85, resolved in build 00, 01, etc. > David > > > Thanks, > > Omair > > > > [1] https://bugzilla.readthedocs.org/en/latest/using/understanding.html > > > -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From dalibor.topic at oracle.com Thu Jul 23 14:01:21 2015 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 23 Jul 2015 16:01:21 +0200 Subject: JDK 7 Updates: Policy Changes In-Reply-To: <20150722190416.GH3448@redhat.com> References: <55912170.2050804@redhat.com> <55A00930.2060804@oracle.com> <20150720153626.GB2520@redhat.com> <55AFCD68.2010408@oracle.com> <20150722190416.GH3448@redhat.com> Message-ID: <55B0F3B1.1080906@oracle.com> On 22.07.2015 21:04, Omair Majid wrote: > What about manual OpenJDK7-specific issues? Can we create those > manually? Yes. You could set 'Affects Version/s' to openjdk7u to differentiate them from other issues. > Thank you, this clarifies things. Is there a way to say "We expect this > bug to be resolved in OpenJDK 7u99" in JIRA? Bugzilla calls this "Target > Milestone" [1]. You'd do that through a label. For example, labels are used to communicate the status of an issue wrt to Rampdown 2 - *-critical-request, *-critical-watch and *-critical-approved are a typical example in update releases. Such information is ephemeral - so it's not really that useful to have after a couple of years when you look again at the issue. Labels are great for that kind of information, as you can add, change and remove them without having to pollute comments. And you can also search for issues with given labels. > Can we mark an issue as Fixed in Version OpenJDK 7, Resolved in Build > 7u85? I expect future "releases" of OpenJDK7u to continue using the 7uXY > versioning scheme that has been used in the past (I don't know if we > will use many build numbers, however). Well, unless you plan to actually use build numbers to signify multiple builds (and that's not something that's being done for OpenJDK 6, afaict), then you could simply use them to signify releases - so Resolved in Build would carry b85, and Fixed in version would be openjdk7u. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Thu Jul 23 14:20:08 2015 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 23 Jul 2015 16:20:08 +0200 Subject: JDK 7 Updates: Policy Changes In-Reply-To: <2032558441.2768520.1437596932320.JavaMail.zimbra@redhat.com> References: <55912170.2050804@redhat.com> <55A00930.2060804@oracle.com> <20150720153626.GB2520@redhat.com> <55AFCD68.2010408@oracle.com> <20150722190416.GH3448@redhat.com> <2032558441.2768520.1437596932320.JavaMail.zimbra@redhat.com> Message-ID: <55B0F818.7070207@oracle.com> On 22.07.2015 22:28, Andrew Hughes wrote: > I don't follow this. Are you saying something will happen when e.g. > JDK-8043202 from the current security update [0] is pushed to the OpenJDK 7 > tree? With the current jdk7u forest hgupdater configuration, a backport issue in the JDK JBS configuration would get created. If that's not desired, the Project Lead should let the ops know. >>> For example, there is no special representation of the milestones like >>> Rampdown Phase 2 in the JDK JBS Project. Instead, they were tracked >>> separately - see https://wiki.openjdk.java.net/display/jdk7u/JDK+7u80 for >>> an >>> example. >> >> Thank you, this clarifies things. Is there a way to say "We expect this >> bug to be resolved in OpenJDK 7u99" in JIRA? Bugzilla calls this "Target >> Milestone" [1]. > > There is in JIRA, generally; we already do this in the OpenJDK 6 JIRA. [1] Yeah, Fix Version is the other option, aside from using labels. > we can point people to the bug database to file bugs. As far as I'm aware, > the OpenJDK bug database is only accessible to OpenJDK committers, so this > would be a blocker to using it for the OpenJDK 7 project. That's not quite correct: "An individual with at least one OpenJDK Project role of Author or higher has sufficient cause to get a JBS account. A JBS account grants an individual general read and write access to issues, including the ability to file new issues, transitioning issues among the states of the workflow, adding comments, changing field values (including adding and removing labels). The holder of a JBS account can also be the assignee of an issue." from https://wiki.openjdk.java.net/display/general/JBS+Overview cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Oracle is committed to developing practices and products that help protect the environment From aph at redhat.com Thu Jul 23 14:28:22 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 23 Jul 2015 15:28:22 +0100 Subject: JDK 7 Updates: Policy Changes In-Reply-To: <55B0F818.7070207@oracle.com> References: <55912170.2050804@redhat.com> <55A00930.2060804@oracle.com> <20150720153626.GB2520@redhat.com> <55AFCD68.2010408@oracle.com> <20150722190416.GH3448@redhat.com> <2032558441.2768520.1437596932320.JavaMail.zimbra@redhat.com> <55B0F818.7070207@oracle.com> Message-ID: <55B0FA06.8040005@redhat.com> On 07/23/2015 03:20 PM, dalibor topic wrote: > >> we can point people to the bug database to file bugs. As far as I'm aware, >> the OpenJDK bug database is only accessible to OpenJDK committers, so this >> would be a blocker to using it for the OpenJDK 7 project. > > That's not quite correct: > > "An individual with at least one OpenJDK Project role of Author or > higher has sufficient cause to get a JBS account. A JBS account grants > an individual general read and write access to issues, including the > ability to file new issues, transitioning issues among the states of the > workflow, adding comments, changing field values (including adding and > removing labels). The holder of a JBS account can also be the assignee > of an issue." So, the situation with OpenJDK 7 would be as with other projects, and people don't need to be, say, JDK9 committers to modify bug reports. And we can grant Author status to suitably-qualified contributors to OpenJDK 7. It has the downside that end-users can't create bugs, but that's no different from the other OpenJDK projects. Sure, it'd be nice to get that fixed for all projects. Andrew. From gnu.andrew at redhat.com Thu Jul 23 20:27:50 2015 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 23 Jul 2015 16:27:50 -0400 (EDT) Subject: JDK 7 Updates: Policy Changes In-Reply-To: <55B0FA06.8040005@redhat.com> References: <55912170.2050804@redhat.com> <55A00930.2060804@oracle.com> <20150720153626.GB2520@redhat.com> <55AFCD68.2010408@oracle.com> <20150722190416.GH3448@redhat.com> <2032558441.2768520.1437596932320.JavaMail.zimbra@redhat.com> <55B0F818.7070207@oracle.com> <55B0FA06.8040005@redhat.com> Message-ID: <520674275.3693730.1437683270923.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 07/23/2015 03:20 PM, dalibor topic wrote: > > > >> we can point people to the bug database to file bugs. As far as I'm aware, > >> the OpenJDK bug database is only accessible to OpenJDK committers, so this > >> would be a blocker to using it for the OpenJDK 7 project. > > > > That's not quite correct: > > > > "An individual with at least one OpenJDK Project role of Author or > > higher has sufficient cause to get a JBS account. A JBS account grants > > an individual general read and write access to issues, including the > > ability to file new issues, transitioning issues among the states of the > > workflow, adding comments, changing field values (including adding and > > removing labels). The holder of a JBS account can also be the assignee > > of an issue." > Close enough. "An Author for a Project is a Contributor who has been granted the right to create changesets intended to be pushed into a specific Project?s code repositories, but does not have the right to push such changesets directly." http://openjdk.java.net/bylaws#author Unlike with the other roles, it's not clear how someone is "granted the right". There's no voting process as described for committers, etc. My point was that, if I'm discussing an issue with someone via e-mail and/or IRC, I can't ask them to go and make a bug unless they're already involved in the OpenJDK development process and have been awarded this author role somehow. In contrast, someone can file an IcedTea bug by signing up with an e-mail address. > So, the situation with OpenJDK 7 would be as with other projects, and > people don't need to be, say, JDK9 committers to modify bug reports. > And we can grant Author status to suitably-qualified contributors to > OpenJDK 7. Can we? As I say, it's not clear how this is done. I also don't believe someone should first need to be "a suitably-qualified contributor" to file a bug report. People testing and filing issues are just as valuable as those fixing them. Other development projects, yes. I think the potential bug reporters for a package which is installed on many user's desktops (java-1.7.0-openjdk and the like in other distros) is different from that of something like Shenandoah, which are still experimental and where they'd probably have had to build it themselves first. > > It has the downside that end-users can't create bugs, but that's no > different from the other OpenJDK projects. Sure, it'd be nice to get > that fixed for all projects. It's different from the IcedTea bugzilla and our existing OpenJDK 6 JIRA, which are closer equivalents of OpenJDK 7. It's also different from what OpenJDK 7 had before, where bugs could enter the database via Oracle's reporting system. I don't think it's something that will ever be "fixed". It's done by design so that bugs for Oracle's binaries have to go through their triaging system first. I'm hearing lots of downsides, but I have yet to hear any benefits of using the OpenJDK bug system over the existing system we have for OpenJDK 6, which has worked well for the last couple of years. > > Andrew. > > > -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From david.holmes at oracle.com Fri Jul 24 06:38:27 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 24 Jul 2015 16:38:27 +1000 Subject: JDK 7 Updates: Policy Changes In-Reply-To: <520674275.3693730.1437683270923.JavaMail.zimbra@redhat.com> References: <55912170.2050804@redhat.com> <55A00930.2060804@oracle.com> <20150720153626.GB2520@redhat.com> <55AFCD68.2010408@oracle.com> <20150722190416.GH3448@redhat.com> <2032558441.2768520.1437596932320.JavaMail.zimbra@redhat.com> <55B0F818.7070207@oracle.com> <55B0FA06.8040005@redhat.com> <520674275.3693730.1437683270923.JavaMail.zimbra@redhat.com> Message-ID: <55B1DD63.3050104@oracle.com> On 24/07/2015 6:27 AM, Andrew Hughes wrote: > ----- Original Message ----- >> On 07/23/2015 03:20 PM, dalibor topic wrote: >>> >>>> we can point people to the bug database to file bugs. As far as I'm aware, >>>> the OpenJDK bug database is only accessible to OpenJDK committers, so this >>>> would be a blocker to using it for the OpenJDK 7 project. >>> >>> That's not quite correct: >>> >>> "An individual with at least one OpenJDK Project role of Author or >>> higher has sufficient cause to get a JBS account. A JBS account grants >>> an individual general read and write access to issues, including the >>> ability to file new issues, transitioning issues among the states of the >>> workflow, adding comments, changing field values (including adding and >>> removing labels). The holder of a JBS account can also be the assignee >>> of an issue." >> > > Close enough. > > "An Author for a Project is a Contributor who has been granted the right > to create changesets intended to be pushed into a specific Project?s code > repositories, but does not have the right to push such changesets directly." > > http://openjdk.java.net/bylaws#author > > Unlike with the other roles, it's not clear how someone is "granted the > right". There's no voting process as described for committers, etc. That is stated most clearly under Projects: http://openjdk.java.net/projects/ But it is implicit in the description of the Project Leads role in the bylaws: "The authority to appoint and remove Authors who are not also Committers;" David ----- > My point was that, if I'm discussing an issue with someone via e-mail > and/or IRC, I can't ask them to go and make a bug unless they're already > involved in the OpenJDK development process and have been awarded this > author role somehow. In contrast, someone can file an IcedTea bug by > signing up with an e-mail address. > >> So, the situation with OpenJDK 7 would be as with other projects, and >> people don't need to be, say, JDK9 committers to modify bug reports. >> And we can grant Author status to suitably-qualified contributors to >> OpenJDK 7. > > Can we? As I say, it's not clear how this is done. I also don't believe > someone should first need to be "a suitably-qualified contributor" to > file a bug report. People testing and filing issues are just as valuable > as those fixing them. > > Other development projects, yes. I think the potential bug reporters for > a package which is installed on many user's desktops (java-1.7.0-openjdk > and the like in other distros) is different from that of something > like Shenandoah, which are still experimental and where they'd probably > have had to build it themselves first. > >> >> It has the downside that end-users can't create bugs, but that's no >> different from the other OpenJDK projects. Sure, it'd be nice to get >> that fixed for all projects. > > It's different from the IcedTea bugzilla and our existing OpenJDK 6 JIRA, > which are closer equivalents of OpenJDK 7. It's also different from what > OpenJDK 7 had before, where bugs could enter the database via Oracle's > reporting system. > > I don't think it's something that will ever be "fixed". It's done by > design so that bugs for Oracle's binaries have to go through their > triaging system first. > > I'm hearing lots of downsides, but I have yet to hear any benefits > of using the OpenJDK bug system over the existing system we have > for OpenJDK 6, which has worked well for the last couple of years. > >> >> Andrew. >> >> >> > From aph at redhat.com Fri Jul 24 08:17:11 2015 From: aph at redhat.com (Andrew Haley) Date: Fri, 24 Jul 2015 09:17:11 +0100 Subject: JDK 7 Updates: Policy Changes In-Reply-To: <520674275.3693730.1437683270923.JavaMail.zimbra@redhat.com> References: <55912170.2050804@redhat.com> <55A00930.2060804@oracle.com> <20150720153626.GB2520@redhat.com> <55AFCD68.2010408@oracle.com> <20150722190416.GH3448@redhat.com> <2032558441.2768520.1437596932320.JavaMail.zimbra@redhat.com> <55B0F818.7070207@oracle.com> <55B0FA06.8040005@redhat.com> <520674275.3693730.1437683270923.JavaMail.zimbra@redhat.com> Message-ID: <55B1F487.1060509@redhat.com> On 23/07/15 21:27, Andrew Hughes wrote: > >> So, the situation with OpenJDK 7 would be as with other projects, and >> people don't need to be, say, JDK9 committers to modify bug reports. >> And we can grant Author status to suitably-qualified contributors to >> OpenJDK 7. > > Can we? Yes. > As I say, it's not clear how this is done. I also don't believe > someone should first need to be "a suitably-qualified contributor" > to file a bug report. Neither do I, but that's something to be fixed as part of of the OpenJDK project itself rather than trying to do an end-around with another bug database. > People testing and filing issues are just as valuable as those > fixing them. > > Other development projects, yes. I think the potential bug reporters for > a package which is installed on many user's desktops (java-1.7.0-openjdk > and the like in other distros) is different from that of something > like Shenandoah, which are still experimental and where they'd probably > have had to build it themselves first. > >> It has the downside that end-users can't create bugs, but that's no >> different from the other OpenJDK projects. Sure, it'd be nice to get >> that fixed for all projects. > > It's different from the IcedTea bugzilla and our existing OpenJDK 6 JIRA, > which are closer equivalents of OpenJDK 7. Indeed it is. > It's also different from what OpenJDK 7 had before, where bugs could > enter the database via Oracle's reporting system. That's an interesting point, although from what I remember it has not always been successful, and there's always been that "black hole" feeling after a bug was reported and before it became visible. > I don't think it's something that will ever be "fixed". It's done by > design so that bugs for Oracle's binaries have to go through their > triaging system first. > > I'm hearing lots of downsides, but I have yet to hear any benefits > of using the OpenJDK bug system over the existing system we have > for OpenJDK 6, which has worked well for the last couple of years. Using a separate bug database is not a real solution, though. It's not at all clear to me that we benefit substantially enough from going outside the OpenJDK bug database but we lose continuity, the ability to search and link bugs, and so on. I'm not convinced that the ability of non-Authors to create and edit bug reports is worth doing something so different from the rest of OpenJDK. The semi-detached status that the OpenJDK community outside Oracle has is not doing anyone any good. It's a hangover from the days when we really did need to use our own infrastructure, not something to be perpetuated. By working outside OpenJDK we also lose some of the incentive to get OpenJDK itself fixed. Andrew. From dalibor.topic at oracle.com Fri Jul 24 12:32:19 2015 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Fri, 24 Jul 2015 14:32:19 +0200 Subject: JDK 7 Updates: Policy Changes In-Reply-To: <55B1F487.1060509@redhat.com> References: <55912170.2050804@redhat.com> <55A00930.2060804@oracle.com> <20150720153626.GB2520@redhat.com> <55AFCD68.2010408@oracle.com> <20150722190416.GH3448@redhat.com> <2032558441.2768520.1437596932320.JavaMail.zimbra@redhat.com> <55B0F818.7070207@oracle.com> <55B0FA06.8040005@redhat.com> <520674275.3693730.1437683270923.JavaMail.zimbra@redhat.com> <55B1F487.1060509@redhat.com> Message-ID: <55B23053.4090602@oracle.com> On 7/24/15 10:17 AM, Andrew Haley wrote: > to search and link bugs, and so on. I'm not convinced that the > ability of non-Authors to create and edit bug reports is worth doing > something so different from the rest of OpenJDK. Looking at https://bugs.openjdk.java.net/issues/?jql=text%20~%20%22\%22OpenJDK%20Runtime%20Environment\%22%22%20AND%20text%20~%20%221.7.0%22%20AND%20labels%3Dwebbug%20AND%20createdDate%3E%3D2011-06-30 - I can see that out of 8 issues filed by end users against OpenJDK 7 Updates in the last 4 years through bugs.java.com, two resulted in useful changes. The rest should have been filed in the corresponding downstream patchset or binary distributor's bug tracker, or been a mailing list/forum discussion at best. That's one useful OpenJDK 7 Updates-specific bug report from someone who is not an OpenJDK developer every two years. I doubt that the picture looks very different for the 63 issues in the OpenJDK 6 JIRA, that has been offering such an ability to non-Authors for a few years as well. End users typically use binaries provided by third parties with their own bug tracking facilities, which is where they go to file their issues with such binaries. cheers, dalibor topic -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment From aph at redhat.com Fri Jul 24 14:04:58 2015 From: aph at redhat.com (Andrew Haley) Date: Fri, 24 Jul 2015 15:04:58 +0100 Subject: JDK 7 Updates: Policy Changes In-Reply-To: <55B23053.4090602@oracle.com> References: <55912170.2050804@redhat.com> <55A00930.2060804@oracle.com> <20150720153626.GB2520@redhat.com> <55AFCD68.2010408@oracle.com> <20150722190416.GH3448@redhat.com> <2032558441.2768520.1437596932320.JavaMail.zimbra@redhat.com> <55B0F818.7070207@oracle.com> <55B0FA06.8040005@redhat.com> <520674275.3693730.1437683270923.JavaMail.zimbra@redhat.com> <55B1F487.1060509@redhat.com> <55B23053.4090602@oracle.com> Message-ID: <55B2460A.1090508@redhat.com> On 07/24/2015 01:32 PM, Dalibor Topic wrote: > On 7/24/15 10:17 AM, Andrew Haley wrote: >> to search and link bugs, and so on. I'm not convinced that the >> ability of non-Authors to create and edit bug reports is worth doing >> something so different from the rest of OpenJDK. > > Looking at https://bugs.openjdk.java.net/issues/?jql=text%20~%20%22\%22OpenJDK%20Runtime%20Environment\%22%22%20AND%20text%20~%20%221.7.0%22%20AND%20labels%3Dwebbug%20AND%20createdDate%3E%3D2011-06-30 - > > I can see that out of 8 issues filed by end users against OpenJDK 7 > Updates in the last 4 years through bugs.java.com, two resulted in > useful changes. > > The rest should have been filed in the corresponding downstream > patchset or binary distributor's bug tracker, or been a mailing > list/forum discussion at best. > > That's one useful OpenJDK 7 Updates-specific bug report from someone > who is not an OpenJDK developer every two years. > > I doubt that the picture looks very different for the 63 issues in > the OpenJDK 6 JIRA, that has been offering such an ability to > non-Authors for a few years as well. > > End users typically use binaries provided by third parties with > their own bug tracking facilities, which is where they go to file > their issues with such binaries. Thanks for doing the work to discover all that. Appreciated! Andrew. From gnu.andrew at redhat.com Mon Jul 27 15:35:05 2015 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 27 Jul 2015 11:35:05 -0400 (EDT) Subject: JDK 7 Updates: Policy Changes In-Reply-To: <55B23053.4090602@oracle.com> References: <55912170.2050804@redhat.com> <20150722190416.GH3448@redhat.com> <2032558441.2768520.1437596932320.JavaMail.zimbra@redhat.com> <55B0F818.7070207@oracle.com> <55B0FA06.8040005@redhat.com> <520674275.3693730.1437683270923.JavaMail.zimbra@redhat.com> <55B1F487.1060509@redhat.com> <55B23053.4090602@oracle.com> Message-ID: <623758247.804857.1438011305412.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 7/24/15 10:17 AM, Andrew Haley wrote: > > to search and link bugs, and so on. I'm not convinced that the > > ability of non-Authors to create and edit bug reports is worth doing > > something so different from the rest of OpenJDK. > > Looking at > https://bugs.openjdk.java.net/issues/?jql=text%20~%20%22\%22OpenJDK%20Runtime%20Environment\%22%22%20AND%20text%20~%20%221.7.0%22%20AND%20labels%3Dwebbug%20AND%20createdDate%3E%3D2011-06-30 > - > I can see that out of 8 issues filed by end users against OpenJDK 7 Updates > in the last 4 years through bugs.java.com, two resulted in useful changes. > > The rest should have been filed in the corresponding downstream patchset or > binary distributor's bug tracker, or been a mailing list/forum discussion at > best. > > That's one useful OpenJDK 7 Updates-specific bug report from someone who is > not an OpenJDK developer every two years. Well, yes, I'm well aware of the current status quo. I was talking about a hypothetical scenario of having the upstream OpenJDK 7 bug reporting process replace the current IcedTea bug process, which is where the issues currently go. Also, as Andrew Haley also mentioned, there's a 'black hole' feeling with that bug process and I've personally had bugs go into it and never appear out the other side. That's why we currently point users at the IcedTea bugzilla. On that basis, I don't think you can pre-judge how an OpenJDK bugzilla would operate if users were being directed to it and able to input bugs in the more usual manner of FOSS bug trackers, rather than going through the internal Oracle triaging process. > > I doubt that the picture looks very different for the 63 issues in the > OpenJDK 6 JIRA, that has been offering such an ability to non-Authors for a > few years as well. Again, we've not been directing anyone at that bug database. Those issues have pretty much all being filed by me after the fact; we hit an issue during the security update that is unique to the backport and so it gets an OJ6 issue. We have five such OJ7 issues waiting with the first backport of security issues there. My entire position is founded on having upstream OpenJDK 7 *replace* IcedTea in the long run. If we instead just want to do the minimum again - file a few backport bugs as needed, keep everything else in IcedTea - then yes, it really doesn't matter that much where you file them. For all you need for that, you could simply stick a table up on the IcedTea wiki. > > End users typically use binaries provided by third parties with their own bug > tracking facilities, which is where they go to file their issues with such > binaries. I know, I triage enough of them. > > cheers, > dalibor topic > -- > Oracle > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > > Oracle Java Platform Group > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher > > Green Oracle Oracle is committed to > developing practices and products that help protect the environment > -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From gnu.andrew at redhat.com Mon Jul 27 15:45:04 2015 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 27 Jul 2015 11:45:04 -0400 (EDT) Subject: JDK 7 Updates: Policy Changes In-Reply-To: <55B1F487.1060509@redhat.com> References: <55912170.2050804@redhat.com> <55AFCD68.2010408@oracle.com> <20150722190416.GH3448@redhat.com> <2032558441.2768520.1437596932320.JavaMail.zimbra@redhat.com> <55B0F818.7070207@oracle.com> <55B0FA06.8040005@redhat.com> <520674275.3693730.1437683270923.JavaMail.zimbra@redhat.com> <55B1F487.1060509@redhat.com> Message-ID: <2037302116.810076.1438011904726.JavaMail.zimbra@redhat.com> snip... > > Using a separate bug database is not a real solution, though. It's > not at all clear to me that we benefit substantially enough from going > outside the OpenJDK bug database but we lose continuity, the ability > to search and link bugs, and so on. I'm not convinced that the > ability of non-Authors to create and edit bug reports is worth doing > something so different from the rest of OpenJDK. > > The semi-detached status that the OpenJDK community outside Oracle has > is not doing anyone any good. It's a hangover from the days when we > really did need to use our own infrastructure, not something to be > perpetuated. By working outside OpenJDK we also lose some of the > incentive to get OpenJDK itself fixed. > > Andrew. > Well, no, I'm not proposing it as an ideal. I just want to make sure we have something that works for practical purposes and doesn't suddenly bring up admin issues in the middle of a security update. The semi-detached status hasn't continued for the fun of it; it's continued because it works and it works now, and there's an element of risk in switching to something else. I'm still not convinced the OpenJDK project has an accessible enough level of infrastructure even now. Is there somewhere to host source tarballs? One of the reasons we started down the same external JIRA bug tracker route as OpenJDK 6, apart from it being well trodden, was that it also comes with a download facility to offer the source code release tarballs. I'm not aware of an equivalent facility within OpenJDK, which would mean we still end up having to set up somewhere else to host releases. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From aph at redhat.com Mon Jul 27 16:08:39 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 27 Jul 2015 17:08:39 +0100 Subject: JDK 7 Updates: Policy Changes In-Reply-To: <623758247.804857.1438011305412.JavaMail.zimbra@redhat.com> References: <55912170.2050804@redhat.com> <20150722190416.GH3448@redhat.com> <2032558441.2768520.1437596932320.JavaMail.zimbra@redhat.com> <55B0F818.7070207@oracle.com> <55B0FA06.8040005@redhat.com> <520674275.3693730.1437683270923.JavaMail.zimbra@redhat.com> <55B1F487.1060509@redhat.com> <55B23053.4090602@oracle.com> <623758247.804857.1438011305412.JavaMail.zimbra@redhat.com> Message-ID: <55B65787.7010908@redhat.com> On 07/27/2015 04:35 PM, Andrew Hughes wrote: > My entire position is founded on having upstream OpenJDK 7 *replace* > IcedTea in the long run. If we instead just want to do the minimum again - > file a few backport bugs as needed, keep everything else in IcedTea - then > yes, it really doesn't matter that much where you file them. For all you need > for that, you could simply stick a table up on the IcedTea wiki. Absolutely so, yes. The OpenJDK 7 updates project can certainly do that: there's no reason not to take all suitably-qualified patches from IcedTea 7 and later OpenJDK releases. Andrew. From aph at redhat.com Mon Jul 27 16:08:40 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 27 Jul 2015 17:08:40 +0100 Subject: JDK 7 Updates: Policy Changes In-Reply-To: <2037302116.810076.1438011904726.JavaMail.zimbra@redhat.com> References: <55912170.2050804@redhat.com> <55AFCD68.2010408@oracle.com> <20150722190416.GH3448@redhat.com> <2032558441.2768520.1437596932320.JavaMail.zimbra@redhat.com> <55B0F818.7070207@oracle.com> <55B0FA06.8040005@redhat.com> <520674275.3693730.1437683270923.JavaMail.zimbra@redhat.com> <55B1F487.1060509@redhat.com> <2037302116.810076.1438011904726.JavaMail.zimbra@redhat.com> Message-ID: <55B65788.3040105@redhat.com> On 07/27/2015 04:45 PM, Andrew Hughes wrote: > snip... > >> >> Using a separate bug database is not a real solution, though. It's >> not at all clear to me that we benefit substantially enough from going >> outside the OpenJDK bug database but we lose continuity, the ability >> to search and link bugs, and so on. I'm not convinced that the >> ability of non-Authors to create and edit bug reports is worth doing >> something so different from the rest of OpenJDK. >> >> The semi-detached status that the OpenJDK community outside Oracle has >> is not doing anyone any good. It's a hangover from the days when we >> really did need to use our own infrastructure, not something to be >> perpetuated. By working outside OpenJDK we also lose some of the >> incentive to get OpenJDK itself fixed. > > Well, no, I'm not proposing it as an ideal. I just want to make sure > we have something that works for practical purposes and doesn't > suddenly bring up admin issues in the middle of a security > update. The semi-detached status hasn't continued for the fun of it; > it's continued because it works and it works now, and there's an > element of risk in switching to something else. We would not be switching anything: we'd just be continuing to run the 7 Updates project on the same bug database it's always been run. I can certainly agree that OpenJDK would be a better project if it had a proper open bug database, but I have seen nothing which convinces me that it's something we should do as part of maintaining OpenJDK 7 Updates. 7u is a long-term maintenance project, and I don't think that the burden of creating bugs in bugs.openjdk.java.net will be a significant problem, let alone an overwhelming one. > I'm still not convinced the OpenJDK project has an accessible enough > level of infrastructure even now. Is there somewhere to host source > tarballs? One of the reasons we started down the same external JIRA > bug tracker route as OpenJDK 6, apart from it being well trodden, > was that it also comes with a download facility to offer the source > code release tarballs. I'm not aware of an equivalent facility > within OpenJDK, which would mean we still end up having to set up > somewhere else to host releases. Sure, we might well end up needing somewhere else to host releases. That's a separate issue. Andrew. From gnu.andrew at redhat.com Mon Jul 27 17:07:22 2015 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 27 Jul 2015 13:07:22 -0400 (EDT) Subject: JDK 7 Updates: Policy Changes In-Reply-To: <55B65788.3040105@redhat.com> References: <55912170.2050804@redhat.com> <2032558441.2768520.1437596932320.JavaMail.zimbra@redhat.com> <55B0F818.7070207@oracle.com> <55B0FA06.8040005@redhat.com> <520674275.3693730.1437683270923.JavaMail.zimbra@redhat.com> <55B1F487.1060509@redhat.com> <2037302116.810076.1438011904726.JavaMail.zimbra@redhat.com> <55B65788.3040105@redhat.com> Message-ID: <41032633.845779.1438016842439.JavaMail.zimbra@redhat.com> snip... > > Sure, we might well end up needing somewhere else to host releases. > That's a separate issue. > > Andrew. > Ok, I believe Omair is already working on a solution to that. So how do I go about filing OpenJDK bugs for the five issues that are part of this security update? Are there changes that need to be made first in the OpenJDK database or is it possible to do it now? It's nearly two weeks since the embargo was lifted and I'd like to finally start posting webrevs for this. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From aph at redhat.com Mon Jul 27 17:11:53 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 27 Jul 2015 18:11:53 +0100 Subject: JDK 7 Updates: Policy Changes In-Reply-To: <41032633.845779.1438016842439.JavaMail.zimbra@redhat.com> References: <55912170.2050804@redhat.com> <2032558441.2768520.1437596932320.JavaMail.zimbra@redhat.com> <55B0F818.7070207@oracle.com> <55B0FA06.8040005@redhat.com> <520674275.3693730.1437683270923.JavaMail.zimbra@redhat.com> <55B1F487.1060509@redhat.com> <2037302116.810076.1438011904726.JavaMail.zimbra@redhat.com> <55B65788.3040105@redhat.com> <41032633.845779.1438016842439.JavaMail.zimbra@redhat.com> Message-ID: <55B66659.4050803@redhat.com> On 07/27/2015 06:07 PM, Andrew Hughes wrote: > snip... >> >> Sure, we might well end up needing somewhere else to host releases. >> That's a separate issue. > > Ok, I believe Omair is already working on a solution to that. > > So how do I go about filing OpenJDK bugs for the five issues that > are part of this security update? Are there changes that need to > be made first in the OpenJDK database or is it possible to do it > now? > > It's nearly two weeks since the embargo was lifted and I'd like > to finally start posting webrevs for this. Anyone who is an OpenJDK author can file them now, as far as I know. Andrew. From gnu.andrew at redhat.com Mon Jul 27 17:26:09 2015 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 27 Jul 2015 13:26:09 -0400 (EDT) Subject: JDK 7 Updates: Policy Changes In-Reply-To: <55B66659.4050803@redhat.com> References: <55912170.2050804@redhat.com> <55B0FA06.8040005@redhat.com> <520674275.3693730.1437683270923.JavaMail.zimbra@redhat.com> <55B1F487.1060509@redhat.com> <2037302116.810076.1438011904726.JavaMail.zimbra@redhat.com> <55B65788.3040105@redhat.com> <41032633.845779.1438016842439.JavaMail.zimbra@redhat.com> <55B66659.4050803@redhat.com> Message-ID: <263202695.850172.1438017969004.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 07/27/2015 06:07 PM, Andrew Hughes wrote: > > snip... > >> > >> Sure, we might well end up needing somewhere else to host releases. > >> That's a separate issue. > > > > Ok, I believe Omair is already working on a solution to that. > > > > So how do I go about filing OpenJDK bugs for the five issues that > > are part of this security update? Are there changes that need to > > be made first in the OpenJDK database or is it possible to do it > > now? > > > > It's nearly two weeks since the embargo was lifted and I'd like > > to finally start posting webrevs for this. > > Anyone who is an OpenJDK author can file them now, as far as I know. > > Andrew. > > Yes, I know the process in general. I wanted to know if anything special needed to be done for OpenJDK 7. There was mention of tags and such, so I wanted to make sure they were filed correctly. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From aph at redhat.com Fri Jul 31 09:18:21 2015 From: aph at redhat.com (Andrew Haley) Date: Fri, 31 Jul 2015 10:18:21 +0100 Subject: JDK 7 Updates: Policy Changes In-Reply-To: <263202695.850172.1438017969004.JavaMail.zimbra@redhat.com> References: <55912170.2050804@redhat.com> <55B0FA06.8040005@redhat.com> <520674275.3693730.1437683270923.JavaMail.zimbra@redhat.com> <55B1F487.1060509@redhat.com> <2037302116.810076.1438011904726.JavaMail.zimbra@redhat.com> <55B65788.3040105@redhat.com> <41032633.845779.1438016842439.JavaMail.zimbra@redhat.com> <55B66659.4050803@redhat.com> <263202695.850172.1438017969004.JavaMail.zimbra@redhat.com> Message-ID: <55BB3D5D.9020902@redhat.com> On 27/07/15 18:26, Andrew Hughes wrote: > Yes, I know the process in general. I wanted to know if anything special > needed to be done for OpenJDK 7. There was mention of tags and such, so > I wanted to make sure they were filed correctly. Tags can be changed after a bug has been created, so there is no reason to hang back. We might as well simply create the JBS entries for each bug and do the changesets based on them. I think the latter should be no more than replacing the bug ID in each changeset. Andrew.