Right you are on 12 - thanks for the catch!
Cheers,
Martijn
On Wed, 17 Jul 2019 at 22:36, Matthias Klose wrote:
> On 17.07.19 14:51, Martijn Verburg wrote:
> > Hi all,
> >
> > I've updated the info below - happy building!
> >
> > On Tue, 16 Jul 201
Hi all,
I've updated the info below - happy building!
On Tue, 16 Jul 2019 at 23:44, Martijn Verburg
wrote:
> Hi all,
>
> For this quarterly release the tags are:
>
> *Java 8 (all non-aarch64)*
>
> * jdk8u222-b10 (which matches jdk8u222-ga)
>
> *Java 8 (aar
Hi all,
For this quarterly release the tags are:
*Java 8 (all non-aarch64)*
* jdk8u222-b10 (which matches jdk8u222-ga)
*Java 8 (aarch64):*
Still to be pushed but it will be:
aarch64-shenandoah-jdk8u222-b10
*Java 11:*
* jdk-11.0.4+11 (which matches jdk-11.0.4-ga)
*Java 12 & 13:*
12 and 13
Hi All,
Starting a new thread here. I know the Red Hat folks well (AdoptOpenJDK
hosts their OpenJDK binaries for them from the source tarballs as
previously mentioned).
So it sounds like getting the arm sources merged in (or at least kept in
sync) would help?
As an FYI - the 'Official' AArch64
Hi Thorsten,
I just wanted to respond with a thank you for the explanation! I'm going
to sit down with some coffee and map this out and see if/how
OpenJDK can provide backport sets.
I'll respond here after I have a chat to Matthias next Monday.
Cheers,
Martijn
On Mon, 27 May 2019 at 17:21, Th
Hi all,
It's one of the challenges, the rest of the world doesn't necessarily know
>> about the new `-ga` tag that we use to designate releases, so we need to go
>> and help them.
>>
>
> I've also replied separately to this thread (with a meeting request) but
> cut out the OpenJDK mailing lists
Hi Florian,
> My understanding is that 8u212-b01 is a version identifier created by
> > the jdk8u project, and based on a quick check, it matches what Debian
> > identifies as its upstream sources (except for some stripping of system
> > library components). But it's not the most current re
Hi Matthias.
I don't think that playing games with version numbers is a good thing to do.
> Version numbers should match the upstream source release, and the binary
> packages should not change that version. Of course openjdk has a split
> personality to give even another version when called wi
On Mon, 27 May 2019 at 11:13, Florian Weimer wrote:
> * Gil Tene:
>
> > root@020dc36b9046:/# java -version
> > openjdk version "1.8.0_212"
> > OpenJDK Runtime Environment (build 1.8.0_212-8u212-b01-1~deb9u1-b01)
> > OpenJDK 64-Bit Server VM (build 25.212-b01, mixed mode)
> > root@020dc36b9046:/#
Hi all, (I've removed the OpenJDK mailing lists as they're not the correct
place for a distro packaging discussion)
OK - The direction of this discussion isn't going to help us resolve the
challenges at hand. Let's take a step back and focus on getting a common
understanding of how OpenJDK source
On Fri, 24 May 2019 at 15:40, tony mancill wrote:
> On Thu, May 23, 2019 at 11:58:14PM +0200, Emmanuel Bourg wrote:
> > Le 23/05/2019 à 19:04, Martijn Verburg a écrit :
> >
> > > What was the difficulty in grabbing the 11.0.3+7 tag directly?
> >
> > The diff
Thanks for following up on this!!
What was the difficulty in grabbing the 11.0.3+7 tag directly?
On Thu, 23 May 2019 at 17:50, Emmanuel Bourg wrote:
> Le 20/05/2019 à 14:38, Aleksey Shipilev a écrit :
>
> > Yes. Security fixes and Japanese epoch changes are delivered in
> 11.0.3+7, after securi
12 matches
Mail list logo
