Support Status of IcedTea 2.x Releases
gnu.andrew at redhat.com
Thu Jun 13 04:37:34 PDT 2013
----- Original Message -----
> Thanks for your great work on this.
> I'm trying to understand the release/build model for icedtea, and it's a
> little confusing.
> I can't find good documentation on the various kinds of icedtea changes.
> Upstreamed changes are easy to understand, but there's changes to
> icedtea7-forest-2.4, patches in icedtea7-2.4/patches, and patches in
For 7, most IcedTea fixes go into the forest. The only ones held in patches
are those that are applied conditionally.
> Is it true that boot/patches are only used when --disable-bootstrap=no?
Yes (the default). Most of the fixes make the build work when it's not being
built with Sun classes present or workaround known issues in some bootstrap JDKs.
> Why would patches end up in icedtea7-forest-2.4 rather than in
See above. Ideally, they don't and we try to avoid it where possible.
Of those in 2.4:
nss-config.patch: Enables the PKCS11 NSS configuration when enabled.
pulse-soundproperties.patch: Sets up the PulseAudio provider when enabled.
test_gamma.patch: Disables the gamma test on PaX builds.
There's also systemtap_gc.patch still in there, which can be moved into the forest
(SystemTap support was optional before the main patch finally went upstream).
> The icedtea7 forests aren't well advertised. Are they supposed to be an
> implementation detail?
Yes. With 6, we used build drops from Oracle and heavy patching instead. Having
our own forest as a base is easier to maintain and makes it more obvious what is
> Is building them independently as just another openjdk a
> reasonable/supported thing to do?
Yes, but someone doing so would be expected to know about building OpenJDK already.
IcedTea is primarily there to not have to deal with the mass of make options and
system knowledge needed to setup an OpenJDK build.
We do build the forest standalone when integrating new changes and I believe Fedora
uses it directly, a situation I feel creates more work for them and means they miss
out on build fixes in IcedTea which they'd have to replicate themselves.
> icedtea7-2.4/INSTALL refers to
> but that looks obsolete.
Ah, thanks :) I'll fix that. We were using that initially but we've moved back to our
own servers as it's easier to resolve issues.
> is the use of the word "creat" a typo or a Unix in-joke?
> > Most targets in IcedTea creat stamp files in the stamps directory to
Typo -- but a funny one :)
> On Mon, Jun 10, 2013 at 3:45 AM, Andrew Hughes <gnu.andrew at redhat.com>wrote:
> > This is an update on the status of the various IcedTea 2.x releases,
> > following
> > the release of 2.4.0 (http://bitly.com/11Bzajd).
> > * The 2.1.x series will remain supported until the ARM32 JIT is available
> > in a
> > later release. This should be true of at least the 2.3.x series by the
> > end of
> > the year.
> > * The 2.2.x series will be updated as part of the next security update (due
> > in just over a week on the 18th/19th of June, 2013, depending on what
> > timezone
> > you're in). After that, it will no longer be supported.
> > * The 2.3.x and 2.4.x series will be supported until the release of 2.5.0
> > and 2.6.0 respectively.
> > This information has now been included on our release policy page:
> > http://icedtea.classpath.org/wiki/ReleasePolicy
> > Thanks,
> > --
> > Andrew :)
> > Free Java Software Engineer
> > Red Hat, Inc. (http://www.redhat.com)
> > PGP Key: 248BDC07 (https://keys.indymedia.org/)
> > Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07
More information about the distro-pkg-dev