2020/12/4 6:08:13 -0800, [email protected]:
> On Fri, 4 Dec 2020 12:30:02 GMT, Alan Bateman wrote:
>>> And I can certainly move jdwp.spec to java.base instead. That's the
>>> reason I need input on this: All I know is that is definitely not
>>> the responsibility of the Build Group to maintai
2020/7/23 10:33:34 -0700, [email protected]:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8250216
>>
>> [ ... ]
>>
>> Patch below.
>
> Looks good.
>
> I think it would be nice if you could reference the JDK Project page
> (ojn/projects/jdk), not just ojn.
Good idea ... but I just pushe
Bug: https://bugs.openjdk.java.net/browse/JDK-8250216
The README at the root of the source tree says, “For information about
building the JDK, including how to retrieve all of the source code,
please see ...” yet we haven’t needed instructions on how to retrieve
the rest of the source code since J
2019/10/23 12:37:56 -0700, [email protected]:
>> On Oct 23, 2019, at 3:07 PM, [email protected] wrote:
>> ...
>>
>> Addendum: To keep things sane for JFR and the serviceability agent,
>> I had to propagate this change through to those subsystems.
>>
>> Relative patch below; original
2019/10/22 15:36:28 -0700, [email protected]:
> 2019/10/22 12:43:42 -0700, [email protected]:
>>> On Oct 22, 2019, at 3:22 PM, [email protected] wrote:
>>> 2019/10/22 10:31:55 -0700, [email protected]:
In arguments.cpp, could you use a new JVMFlag to declare options
>
2019/10/22 12:43:42 -0700, [email protected]:
>> On Oct 22, 2019, at 3:22 PM, [email protected] wrote:
>> 2019/10/22 10:31:55 -0700, [email protected]:
>>> In arguments.cpp, could you use a new JVMFlag to declare options
>>> that came from this resource as RESOURCE?
>>>
>>> - ji
2019/10/22 14:12:18 -0700, [email protected]:
> On 10/21/19 8:22 PM, [email protected] wrote:
>> RFE: https://bugs.openjdk.java.net/browse/JDK-8232080
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8232753
>> Webrev: https://cr.openjdk.java.net/~mr/rev/8232080/
>
> Looks good to me.
2019/10/22 7:15:10 -0700, [email protected]:
> On 22/10/2019 04:22, [email protected] wrote:
>> RFE: https://bugs.openjdk.java.net/browse/JDK-8232080
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8232753
>> Webrev: https://cr.openjdk.java.net/~mr/rev/8232080/
>
> I've read through
2019/10/22 10:31:55 -0700, [email protected]:
> In arguments.cpp, could you use a new JVMFlag to declare options that came
> from this resource as RESOURCE?
>
> - jint result = parse_each_vm_init_arg(vm_options_args, &patch_mod_javabase,
> JVMFlag::INTERNAL);
> + jint result = parse_each_v
RFE: https://bugs.openjdk.java.net/browse/JDK-8232080
CSR: https://bugs.openjdk.java.net/browse/JDK-8232753
Webrev: https://cr.openjdk.java.net/~mr/rev/8232080/
This change implements jlink plugins, and associated changes in the VM
and libraries, to support the following new jlink options:
- --
2018/10/3 12:13:15 -0700, [email protected]:
> ...
>
> https://bugs.openjdk.java.net/browse/JDK-8208089
Or, more readably: https://openjdk.java.net/jeps/8208089
- Mark
2018/8/21 7:25:58 -0700, [email protected]:
> On Tue, Aug 21, 2018 at 12:14 PM, [email protected] wrote:
>> ...
>>
>> I can easily add a new make target to build hsdis.
>>
>> Adding a new binary to the OpenJDK images will require a CSR.
>
> Do we really need a CSR for hsdis? h
2018/8/21 11:11:00 -0700, [email protected]:
> On Aug 21, 2018, at 9:41 AM, Andrew Haley wrote:
>> On 08/21/2018 11:14 AM, Magnus Ihse Bursie wrote:
>>> Am I correct in understanding that there are no more legal barriers
>>> towards doing such a thing anymore?
>>
>> You'd still be linking G
2018/6/29 3:03:09 -0700, [email protected]:
> This still doesn't explain why replacing one trademark with another
> one is helpful here.
Perhaps some trademarks are more important than others.
> After Phil's remark, OpenJDK doesn't even seem to be registered as a
> trademark, so in that se
2018/6/27 23:21:34 -0700, [email protected]:
> On Thu, Jun 28, 2018 at 12:08 AM, [email protected] wrote:
>> ...
>>
>> “OpenJDK” is a trademarked term, per the OpenJDK Trademark Notice [1].
>> As such it should be used only as an adjective, and not as a noun.
>> Phrases such as “the
2018/6/28 0:14:26 -0700, Aleksey Shipilev :
> On 06/28/2018 08:21 AM, Volker Simonis wrote:
>> Sorry, but I don't see any sense in this change!
>
> +1
>
> Also, "(open-source) JDK" is way too generic, and does awkwardly apply
> to other JDK's in the wild, including IBM's, Azul's, Excelsior's,
> e
2018/6/27 16:19:58 -0700, [email protected]:
> Looks good to me as well.
>
> Tim
>
> On 06/27/18 15:33, Erik Joelsson wrote:
>> Looks good.
>>
>> /Erik
Thanks!
- Mark
Bug: https://bugs.openjdk.java.net/browse/JDK-8205956
Webrev: http://cr.openjdk.java.net/~mr/rev/8205956/
Quick links to handier HTML diffs:
http://cr.openjdk.java.net/~mr/rev/8205956/doc/building.html.hdiff.html
http://cr.openjdk.java.net/~mr/rev/8205956/doc/testing.html.hdiff.html
“OpenJDK
2018/5/3 13:16:11 +0100, [email protected]:
> On Thu, May 3, 2018 at 12:21 PM, [email protected] wrote:
>> ...
>>
>> Until a consensus of a better solution for hosting the generated
>> documentation is reached, I'd like to avoid changing the build code. That
>> will just open fo
2017/12/18 20:40:19 -0800, Martin Buchholz :
> On Mon, Dec 18, 2017 at 3:50 PM, [email protected] wrote:
>> I didn't know you'd requested this -- is there an existing issue?
>
> https://bugs.openjdk.java.net/browse/JDK-8189761
Thanks. I cross-linked that with 8193764, which addresses part
2017/12/18 15:36:03 -0800, Martin Buchholz :
> Mark, thanks for implementing my little feature request. Looks good to me.
I didn't know you'd requested this -- is there an existing issue?
- Mark
Bug: https://bugs.openjdk.java.net/browse/JDK-8193764
Webrev: http://cr.openjdk.java.net/~mr/rev/8193764/
You can set COMPANY_NAME in make/autoconf/version-numbers, but you can't
set it when configuring a build, so it's impossible to change the value
of IMPLEMENTOR in the $JAVA_HOME/release file w
2017/12/13 15:49:53 -0800, [email protected]:
> On 13 Dec 2017, at 14:36, [email protected] wrote:
>> I understand that other incoming changes are waiting for the 11 version
>> bump, but can't we at least do the straightforward parameterizations and
>> introduce _CURRENT constants in th
2017/12/13 14:09:44 -0800, [email protected]:
>> On 13 Dec 2017, at 13:18, [email protected] wrote:
>> How much of this can we parameterize and/or automate?
>
> I suspect quite a bit, as you present below, and i agree we should try
> and automate as much as possible. At the moment it’s
2017/12/13 8:44:33 -0800, [email protected]:
>> On 12 Dec 2017, at 20:56, [email protected] wrote:
>>
>> Anyway, none of the proposed changes have any impact on hotspot
>> AFAICT. It is only when the actual version is updated to 11 that
>> hotspot, and other entities will have to be upd
2017/10/26 9:11:08 -0700, [email protected]:
> Please review this small change to update the link to the
>
> Specification license referenced by the JavaDoc API. For
>
> JDK 10, we should reference the 10 redirect.
>
> Bug:
>
>
>
> 8189919: Update link to license in Docs.gmk
>
>
2017/6/30 16:08:09 -0700, [email protected]:
> Mark,
>
> The font-family settings in the nodes were deliberate, and a
> workaround for not having time to create a proper taglet for tool guides.
>
> If you remove the style attribute, you'll see in your sample output that
> the "Tool G
8182776: Fix typo "upgradeble" in the javadoc of upgradeable modules
8183161: Remove extraneous font-family style attributes from module declarations
8183251: Meta "keywords" tag malformed in overview-summary.html and related
pages
http://cr.openjdk.java.net/~mr/rev/8182776/jdk9-dev.patch
http://
2017/6/19 10:41:09 +0200, [email protected]:
> Looks good to me.
>
> The change to the log message is a bit weird. Was this meant as a
> temporary way for finding the output file?
Good catch -- yes, that was temporary. I'll remove it.
Thanks,
- Mark
http://cr.openjdk.java.net/~mr/rev/8182408/
https://bugs.openjdk.java.net/browse/JDK-8182408
This is a follow-on to Magnus's changes for 8175824.
Oracle's legal department has recently advised that the liberal use of
trademark symbols on the API-specification overview page is not required.
We sho
2017/4/4 12:28:18 -0700, [email protected]:
> Don't we need the JEP to be moved from "Proposed To Target" to
> "Targetted" before we can push?
Yep. Coming right up ...
- Mark
2017/4/4 8:22:50 -0700, [email protected]:
> On 04/04/17 16:12, [email protected] wrote:
>> The trouble here is that "arm64" and "aarch64" are effectively synonyms
>> for the ISA, but in the JDK we've wound up using them as the names of
>> two different ports.
>>
>> A JMOD file built for the
2017/4/4 4:47:58 -0700, [email protected]:
> Here is an updated webrev:
> http://cr.openjdk.java.net/~ihse/JDK-8172312-combined-javadocs/webrev.03
>
> The only change compared to the previous webrev is that I have updated
> the title for the JDK javadocs so it does not claim to be Jav
2017/4/4 1:04:22 -0700, [email protected]:
> On 2017-04-03 23:50, Mandy Chung wrote:
>> ...
>>
>>JDK 8 JDK 9
>>- -
>> OS_NAMELinux linux
>>SunOS solaris
>>Darwin
2017/4/3 11:01:13 -0700, [email protected]:
> I agree there will need to be some cosmetic cleanup with respect to
> headings. Given the optionality of whether or not the build is set to
> import JavaFX, the headings and content of the new overview page will
> need to be somewhat synthe
2017/4/3 3:24:52 -0700, [email protected]:
> I think the distinction you ask for is already there. The two separate
> make targets "docs-javadoc" and "docs-reference" builds two distinct
> images "docs" and "javase-docs", respectively. The first of these builds
> the complete Java SE
2017/4/3 14:50:52 -0700, [email protected]:
>> On Apr 3, 2017, at 2:39 PM, [email protected] wrote:
>> 2017/4/3 13:35:30 -0700, [email protected]:
>>> ...
>>>
>>> I am not sure why we would change to osx for Mac when the Mac developers
>>> have recently dropped the Mac OS X terminology
2017/4/3 13:35:30 -0700, [email protected]:
> On 03/04/2017 21:15, [email protected] wrote:
>> 2017/4/3 11:41:03 -0700, [email protected]:
>>> Webrev:
>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/
>>>
>>> ...
>>>
>>> This shows the old and new value of OS_NAME
2017/4/3 11:41:03 -0700, [email protected]:
> Webrev:
> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8175819/webrev.00/
>
> ...
>
> This shows the old and new value of OS_NAME/OS_ARCH properties
> in the `release` file:
>
> JDK 8 JDK 9
> -
2017/3/30 6:05:43 -0700, [email protected]:
> As a part of JEP 299, we should build the Javadoc as a single combined
> output, instead of a dozen or so individual javadoc bundles. This bug
> fixes this. The selection on what to include is now based on modules
> instead of packages.
2017/1/6 7:30:28 -0800, [email protected]:
> Andrew Haley has resigned as lead for the JDK 6 Project [1].
>
> Under the bylaws for Project Roles [2], a new Project Lead may be
> nominated by the Group Leads of the Project's sponsoring groups.
>
> The Build Infrastructure Group is sponsor of the
2015/5/21 12:01 -0700, [email protected]:
> This is a patch adding a new option, -platform, to javac.
>
> Patch for the top-level repository is here:
> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/top-level/
>
> Patch for the langtools repository is here:
> http://cr.openjdk.java.net
2015/1/20 9:28 -0800, [email protected]:
> Kelly O'Hair resigned as the Lead of the Build Group in April 2014 [1].
> Tim Bell was voted in as the new Group Lead shortly thereafter [2].
> (Unfortunately this particular change slipped through the cracks, which
> is why you're only hearing abo
2015/1/20 9:26 -0800, [email protected]:
> On 20.01.2015 18:19, Andrew Haley wrote:
>> Okay, so does that mean I have to petition the GB to get this done,
>> or could Kelly do this retroactively?
>
> The nomination of a new Project Lead would have to take place sometime
> in April. I'd assu
2014/12/4 9:51 -0800, [email protected]:
> On 12/03/2014 02:58 AM, Magnus Ihse Bursie wrote:
>> ...
>>
>> My suggestion is that the microbenchmarks are put in the top-level
>> repo, if only for the reason that it seems fully possible to split
>> them out to a separate repo some time in
2014/12/1 4:08 -0800, [email protected]:
> Hopefully this is the right list for this discussion.
This change is going to affect many more people than just those
interested in the build. Suggest you float this on jdk9-dev.
- Mark
2014/4/22 21:23 -0700, [email protected]:
> Yes, I did consider using some ifeq tricks like that -- but they are rather
> ugly and unreadable and have the same problem that you want to avoid:
> adding distribution-specific code into the open-source makefiles.
>
> My goal here is to have the pu
2014/4/16 14:52 -0700, [email protected]:
> src/closed is Oracle's "custom source" location (hotspot calls it
> alt_src). If we never saw src/closed in the makefiles, only
> CUSTOM_SRC_DIR, and guarded with an existence test for a specific
> directory/file, then that should address your pr
Vote: yes
- Mark
2014/1/8 16:47 -0800, [email protected]:
> ...
>
> For the future, is there a reason for not automatically generating the
> "specification-version" based on the version numbers we have, or at
> least move the definition of it to the version numbers file?
Excellent question. We should tr
2013/11/26 23:33 -0800, [email protected]:
> On 11/27/2013 03:41 AM, Alan Bateman wrote:
>> The security providers have vestiges of Sun in the provider names (SUN,
>> SunPKCS11, SunJSSE ..) but these are documented and I don't think can be
>> changed (although it not recommended to select serv
2013/11/26 8:29 -0800, [email protected]:
> On 27/11/2013 8:49 AM, [email protected] wrote:
>> Now that we've removed the old build system, can we please now
>> remove the last vestiges of Sun's pre-Java 5 naming scheme?
>
> There are also a bunch of security libs with j2 in their nam
Now that we've removed the old build system, can we please now
remove the last vestiges of Sun's pre-Java 5 naming scheme?
I refer in particular to these directories in a typical build:
images/j2re-image
images/j2sdk-image
images/j2sdk-server-image
The "j2" nomenclature hasn't been used si
2013/11/18 2:02 -0800, [email protected]:
> So, finally it has happened. The old build system is now removed. ...
Huzzah!
- Mark
2013/10/31 2:41 -0700, [email protected]:
> With build logic, it is relatively easy to build before and after and
> verify the exact same resulting bits.
>
> So the risk is considerably less than in other areas of software
> development. There might be more risk leaving it in, where the wrong
2013/6/5 10:22 -0700, [email protected]:
> This comes from hotspot build. The FDS processing happens in a file that
> is included a number of times due to the nested make invocations that
> happen with hotspot. Consequently this gets repeated a few times
> (actually fewer than it used to)
The following lines are repeated over and over when building JDK 8:
INFO: ENABLE_FULL_DEBUG_SYMBOLS=1
INFO: ALT_OBJCOPY=/usr/bin/objcopy
INFO: /usr/bin/objcopy cmd found so will create .debuginfo files.
INFO: STRIP_POLICY=min_strip
INFO: ZIP_DEBUGINFO_FILES=1
It seems like a lot of noi
2013/5/21 6:54 -0700, [email protected]:
>> On 05/21/2013 04:55 PM, Volker Simonis wrote:
>>> I always felt that having the build instructions checked in into the
>>> repository is somewhat to heavyweight.
>>
>> There are two good reasons to do this.
>>
>> Firstly, it's a free software tradit
2013/5/9 8:14 -0700, [email protected]:
>> (Yes, this is one of those rare cases in which a sponsor should use
>> the -u option.)
>
> I'd hazard a guess that there are number of people who overlook this option
> in part because they don't realise you can do
>
> hg commit -u ...
>
> I was
2013/5/9 2:10 -0700, [email protected]:
>> Indeed. I do this with the Oracle patches when applying them to IcedTea.
>> The problem is how this gets done is down to the sponsor; I've had ones
>> that have been imported, ones where I've just been giving the Contributed-by
>> attribution (despite
2013/3/5 11:39 -0800, [email protected]:
> We need to regenerate the open and closed configure scripts in the tl
> forest.
>
> The open change is trivial as it just updates the timestamp:
>
>> hg diff
> diff -r c4901c0e0579 common/autoconf/generated-configure.sh
> --- a/common/autoconf/gen
2012/11/14 8:17 -0800, [email protected]:
> I looked in jcheck.py and see:
>
> if not (bs[0] in ['1','2','4','5','6','7']):
> ch.error(ctx, "Invalid bugid: %s" % bs)
>
> so either I don't have the latest or '8' needs to be added. I'll try that.
You have an antique copy of jcheck.
2012/10/10 16:21 -0700, [email protected]:
> This was originally submitted as 7196354 check-in jdk.tbom file to openjdk
> repo, but the file was checked in to the closedjdk repository.
>
> The automated translation drop system handles penjdk and closedjdk resource
> files separately as 2 dif
2012/9/10 14:26 -0700, [email protected]:
> I have updated the webrev:
> http://cr.openjdk.java.net/~mfang/7196354/webrev.01/
>
> ...
>
> I am also moving the file from root of source tree to
> jdk/make/jdk.tbom. SGT strongly recommends we follow the standard file
> naming convention used b
2012/9/5 14:08 -0700, [email protected]:
> Please help to review the new JDK8 file for the following CR:
> 7196354 check-in jdk.tbom file to openjdk repo
>
> The webrev is located at:
> http://cr.openjdk.java.net/~mfang/7196354/webrev.00/
This file needs a more descriptive name, especially
2012/8/15 4:52 -0700, [email protected]:
> Unfortunately, it is not that simple to just replace everything with x86.
Sad, but true.
> ...
>
> 2) Changing names on files or directories (unfortunately) makes version
> control
> harder. If files are to be moved around all over the plac
Changeset: d3b334e376d3
Author:mr
Date: 2012-01-23 12:39 -0800
URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/d3b334e376d3
7110396: Sound code fails to build with gcc 4.6 on multiarch Linux systems
Reviewed-by: ohair
! make/javax/sound/jsoundalsa/Makefile
2012/1/13 9:33 -0800, [email protected]:
> I am getting the following error when building openjdk 7.0 on ubuntu 11.10
> But I already have the package libasound2-dev installed.
This is 7110396. You need this patch:
diff --git a/make/javax/sound/jsoundalsa/Makefile
b/make/javax/soun
2011/11/10 17:45 -0800, [email protected]:
> On 11/11/2011 1:47 AM, [email protected] wrote:
>> 2011/11/10 4:49 -0800, [email protected]:
>>> The patch is correct, but in order to follow the convention in most other
>>> makefiles, I advice to use OTHER_LDLIBS instead of EXTRA_
2011/11/10 4:49 -0800, [email protected]:
> The patch is correct, but in order to follow the convention in most other
> makefiles, I advice to use OTHER_LDLIBS instead of EXTRA_LIBS.
Ah, thanks. I missed that one when reading through the common makefiles.
2011/11/10 5:16 -0800, robert.o
Some Linux distros have started to adopt a "multiarch" filesystem layout for
shared libraries in order to support the installation of packages for multiple
hardware architectures on a single system. For more information see, e.g.,
http://wiki.debian.org/Multiarch.
In Ubuntu 11.10 the ALSA shared
Vote: yes
- Mark
2011/6/7 20:32 -0700, [email protected]:
> Please review this change to bump the JDK 8 version number from 1.7 to 1.8:
>
>7052122: Update JDK_MINOR_VERSION for JDK 8
>http://cr.openjdk.java.net/~darcy/7052122.0/
>
> Patch below followed by post-GPL text of new langtools test.
Looks go
2011/5/23 12:27 -0700, [email protected]:
> Should the Build Group sponsor the JDK 8 Project [1]?
Vote: yes
- Mark
2011/5/11 8:23 -0700, [email protected]:
> Should the Build Group sponsor the Build Infrastructure Project [1]?
Vote: yes
- Mark
2011/5/11 10:55 -0700, [email protected]:
> Should the following person be added as a member of the OpenJDK Build Group?
> Phil Race http://db.openjdk.java.net/people/prr
Vote: yes
- Mark
2011/5/11 10:20 -0700, [email protected]:
> Should the following person be added as a member of the OpenJDK Build Group?
> David Katleman http://db.openjdk.java.net/people/katleman
Vote: yes
- Mark
2011/3/16 7:55 -0700, [email protected]:
> ... Today we have a "sample" and a "demo" directory
> and
> it's not always clear where to put new sample code. I'm trying to remember why
> we have two locations. I think, but might be wrong, that the demo directory is
> sam
> Date: Wed, 16 Feb 2011 17:19:43 +0100
> From: [email protected]
> As part of our future work in speeding up the build process of OpenJDK
> I think it is necessary that it is easy to see the actual build times.
>
> This is a suggested patch that reports the build times for the subrepos
Okay, I can live with this.
(At the risk of stating the obvious: Please be sure to use hg mv when
you rename these files, otherwise the historical changeset trail will
be broken.)
- Mark
> Date: Sun, 11 Oct 2009 17:35:31 -0700
> From: [email protected]
> 6888701: Change all template java source files to a .java.template file suffix
>
> http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-build-template-6888701/webrev/
Most of the files you are renaming in this change are in NIO, an
> Date: Tue, 15 Sep 2009 10:44:08 -0700
> From: [email protected]
> For as long as I remember, we've used make 3.78.*. I assume the most
> problematic platform to upgrade is windows. However, if there are significant
> benefits build time benefits, I think upgrading the make version is justified
> Date: Fri, 11 Sep 2009 16:17:19 -0700
> From: [email protected]
> Joe Darcy wrote:
>> Generally looks okay; one minor comment, the jaxp webrev has files that
>> appear to be moved as being deleted and added.
>
> Yeah, I think that's an artifact of the way I move my patch from one
> workspace
> Date: Thu, 21 May 2009 16:51:24 +0100
> From: Andrew John Hughes
> ...
>
> Looks like the Contributed-by info is wrong. I tried adding the line
> as in the example and jcheck choked:
>
> remote: > Contributed-by: Andrew John Hughes
> remote:
> remote: Invalid contributor attribution
> remot
> Date: Mon, 18 May 2009 19:17:21 +0100
> From: Andrew John Hughes
> Ok, new webrev created against jdk7/build:
>
> http://fuseyism.com/6841728/webrev.01/
Looks good to me -- go ahead and push when ready.
> I presume I need to wait a bit due to the current block on pushes though.
No, the grou
> Date: Fri, 15 May 2009 18:32:14 +0100
> From: Andrew John Hughes
> 2009/5/15 Mark Reinhold :
>> One changeset is best. Â You need somehow to revert the changeset
>
> Somehow I thought that's what you were going to say.. :)
> Looks like I can do a hg backout to r
> Date: Fri, 15 May 2009 20:19:47 +0400
> From: [email protected]
> Mark Reinhold wrote:
>>> Date: Fri, 15 May 2009 07:16:01 -0700
>>> From: [email protected]
>>
>>> Yeah, tried that, didn't work for me; I had to do real work so I ga
> Date: Fri, 15 May 2009 09:08:39 -0700
> From: [email protected]
> What is your experience with the combination of mq and jcheck?
None, so far, since jcheck is disabled in the Jigsaw forest.
> I like having jcheck enabled as a preextension hook, but that
> didn't work well with mq.
Hmm,
> Date: Fri, 15 May 2009 16:30:04 +0100
> From: Andrew John Hughes
> I was thinking this as I read your mail. It should be easy enough to
> add this as an #else clause to the existing patch in Sanity.gmk.
> What's the best way to handle updating the patch, given that the
> existing patch is a co
> Date: Fri, 15 May 2009 07:16:01 -0700
> From: [email protected]
> Yeah, tried that, didn't work for me; I had to do real work so I gave
> up and downloaded and went back to using 0.9.5. :-(
Odd. I've been hacking on Jigsaw using hg 1.1.2 on my Ubuntu 9.04 box,
with the newest version of
> Date: Thu, 14 May 2009 23:31:58 +0100
> From: Andrew John Hughes
> 2009/5/14 [email protected]:
>> I do think I know what you want. But I consider its a slippery slope as
>> you have no way of knowing or keeping track of the consequences of
>> not building a particular component.
>
> Sure, but
> Date: Thu, 28 Aug 2008 00:19:24 +0200
> From: [EMAIL PROTECTED]
> sudo apt-get build-dep openjdk-6
>
> should get you the necessary build dependencies installed.
Wow. That is just too slick for words.
- Mark
> Date: Wed, 11 Jun 2008 15:09:04 -0700
> From: Martin Buchholz <[EMAIL PROTECTED]>
> On Wed, Jun 11, 2008 at 2:53 PM, Mark Reinhold <[EMAIL PROTECTED]> wrote:
>>> Date: Tue, 10 Jun 2008 18:09:10 -0700
>>> From: Martin Buchholz <[EMAIL PROTECTED]>
> Date: Tue, 10 Jun 2008 18:09:10 -0700
> From: Martin Buchholz <[EMAIL PROTECTED]>
> I did my last hg push from a Google machine.
> I have no idea why mercurial notification thinks I am [EMAIL PROTECTED]
Because that's the address you entered when you originally registered.
> I'd like to have c
> Date: Tue, 22 Apr 2008 13:22:58 +0200
> From: Clemens Eisserer <[EMAIL PROTECTED]>
> It looks like the mercurial-servers are down, I only get "500 -
> Internal Server Error".
> Is this already known and when can I expect it to be fixed?
Exactly what are you trying to do, and with what URL?
Eve
> Date: Tue, 01 Apr 2008 10:59:59 +0200
> From: [EMAIL PROTECTED]
> ...
>
> Perhaps somebody who knows how this works, can update the OpenJDK
> coverage at gmane and nabble?
Tim, could you please look into updating our coverage on gmane.org?
Thanks,
- Mark
> Date: Fri, 01 Feb 2008 14:21:07 +0100
> From: [EMAIL PROTECTED]
> I'd like to suggest to extend .hgignore with these two lines:
>
> ^webrev/
> ^webrev_.*/
>
> It would make it possible to keep several webrevs in your working
> repository without polluting the output of 'hg status'
>
> Well, o
> Date: Fri, 25 Jan 2008 03:02:04 -0800
> From: [EMAIL PROTECTED]
> On Jan 25, 2008, at 2:20 AM, Volker Simonis wrote:
>> I've also noticed that there are no updates in the Mercurial
>> repositories since the inital b24 upload. Is this because of the
>> distributed nature of mercurial and the fact
> Date: Fri, 25 Jan 2008 13:06:48 + (UTC)
> From: Dalibor Topic <[EMAIL PROTECTED]>
> I agree that the process work is incredibly important. More important than the
> process work, though, is to communicate with your fellow developers what is
> going on, in particular when things aren't going
Kelly: Thanks for running this vote, but unfortunately it was taken after
the 14-day limit defined in the interim governance rules.
I've asked the IGB to recognize it anyway [1].
- Mark
[1] http://mail.openjdk.java.net/pipermail/gb-discuss/2008-January/39.html
1 - 100 of 113 matches
Mail list logo
