Re: Mystery meat OpenJDK builds strike again

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Mystery meat OpenJDK builds strike again

Matthias Klose-6
I am disappointed to see such trolling, bashing and telling fake news on a
technical mailing list.  Is this Azul's business model to promote their own
binary builds?

Such behavior propagates e.g. via twitter
https://twitter.com/jroper/status/1130678379403857920

I'm starting the discussion about version numbers and release information in a
new thread.

I am neither involved with any Docker image nor with any Debian backport.

Debian provides security support for its stable release (stretch, 9.x).
openjdk-11 isn't part of any released Debian version.

Ubuntu ships openjdk-8 as a supported package in Ubuntu 16.04 LTS and is
committed to provide security support for openjdk-8 in Ubuntu 18.04 LTS until
the EOL of Ubuntu 16.04 LTS (around April 2021).

Ubuntu 18.04 LTS initially shipped with OpenJDK 10 with the commitment to update
to OpenJDK 11 which now is available in the Ubuntu 18.04 LTS release (in the
security pocket).

There is no mystery meat, just security supported uploads for both Debian and
Ubuntu.

On 15.05.19 20:49, Gil Tene wrote:

> Umm…
>
> Lumpy.local-43% docker run -it --rm openjdk:8 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)
> Lumpy.local-44% date
> Wed May 15 11:41:12 PDT 2019
>
> Look at the build number carefully… This was populated no later
> than March 27, 2019. 3 weeks before the actual 8u212 was released
> on April 16, 2019.

The Debian openjdk-8 source package is put together from the jdk8u,
aarch64-port/jdk8u-shenandoah and aarch32-port/jdk8u projects.  Certainly not
ideal, however these packages can only be made if all the sources are available,
or tagged.

I am happy to see that the aarch64-port tries to keep up with the jdk8u project
however this is a different story with the aarch32-port project:  The project
doesn't have *any* prerelease tags, plus the project updates it's release tags
only months after the jdk8u releases.  So blaming Debian for shipping what they
are able to ship and Azul holding back source releases yourself?   Ein Schelm
wer Böses dabei denkt ...

> Similarly:
>
> Lumpy.local-46% docker run -it --rm openjdk:11 java -version
> openjdk version "11.0.3" 2019-04-16
> OpenJDK Runtime Environment (build 11.0.3+1-Debian-1bpo91)
> OpenJDK 64-Bit Server VM (build 11.0.3+1-Debian-1bpo91, mixed mode, sharing)
> Lumpy.local-47% date
> Wed May 15 11:43:12 PDT 2019
>
> This one was populate dno later than April 3, 2 weeks before
> the actual 11.0.3 was released on April 16, 2019
>
> If anyone was wondering about the importance of having version strings say
> "EA" (or some other "THIS IS NOT a RELEASED VERSION" warning) on any
> and all OpenJDK builds that are not an actual release build, the above shows
> you how bad things get when that practice is not followed.

Don't trust the label, just the content.  I agree that the java community is
much more label/version driven, however this is not a reason to discredit other
sane builds.

> Why Debian populated their repos with these builds is their business, and
> why docker chose to use those specific debian builds can be speculated
> about all we want. the details don't matter. The end result of these
> cumulative "reasonable" (according to some people) choices is that the
> default openjdk runs done by millions of people on docker right now are
> using "mystery meat", incomplete, and exposed builds while seeming to
> report (to the lay person) a Java version that would suggest a real 8u212
> or 11.0.3 (which one would expect has the security vulnerabilities in the
> April update addressed, the bug fixes included, etc.).

Again, I see this as an advertising or promotion email for the Azul binary
builds.  Fine, do so.  Both please use marketing lists and not the OpenJDK
technical lists.

Matthias

Reply | Threaded
Open this post in threaded view
|

Re: Mystery meat OpenJDK builds strike again

Gil Tene
Seriously?

You see factual reporting (directly documented and dated in the original posting) of the actual version numbers being used by official docker images, along with irrefutable proof that the packages used in those were built weeks before the respective OpenJDK 8u and 11u releases were complete, as “fake news”?

You think that alerting millions of unsuspecting people using exposed, insecure builds that falsely report their OpenJDK version (as one that includes e.g. critical security fixes) to the fact as “marketing”?

And you consider pleas to use responsibly built and tested OpenJDK builds, with no mention of any vendor name at all, “trolling”?

This (the specific things documented at the start of this thread) was absolutely Mystery Meat masquerading as an actual release OpenJDK.  Facts are facts.

Blaming the messager and trying to attribute commercial motives to the calling out of inconvenient truths is a way of dealing with reality.

Sent from Gil's iPhone

> On May 26, 2019, at 3:25 PM, Matthias Klose <[hidden email]> wrote:
>
> I am disappointed to see such trolling, bashing and telling fake news on a
> technical mailing list.  Is this Azul's business model to promote their own
> binary builds?
>
> Such behavior propagates e.g. via twitter
> https://twitter.com/jroper/status/1130678379403857920
>
> I'm starting the discussion about version numbers and release information in a
> new thread.
>
> I am neither involved with any Docker image nor with any Debian backport.
>
> Debian provides security support for its stable release (stretch, 9.x).
> openjdk-11 isn't part of any released Debian version.
>
> Ubuntu ships openjdk-8 as a supported package in Ubuntu 16.04 LTS and is
> committed to provide security support for openjdk-8 in Ubuntu 18.04 LTS until
> the EOL of Ubuntu 16.04 LTS (around April 2021).
>
> Ubuntu 18.04 LTS initially shipped with OpenJDK 10 with the commitment to update
> to OpenJDK 11 which now is available in the Ubuntu 18.04 LTS release (in the
> security pocket).
>
> There is no mystery meat, just security supported uploads for both Debian and
> Ubuntu.
>
>> On 15.05.19 20:49, Gil Tene wrote:
>> Umm…
>>
>> Lumpy.local-43% docker run -it --rm openjdk:8 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)
>> Lumpy.local-44% date
>> Wed May 15 11:41:12 PDT 2019
>>
>> Look at the build number carefully… This was populated no later
>> than March 27, 2019. 3 weeks before the actual 8u212 was released
>> on April 16, 2019.
>
> The Debian openjdk-8 source package is put together from the jdk8u,
> aarch64-port/jdk8u-shenandoah and aarch32-port/jdk8u projects.  Certainly not
> ideal, however these packages can only be made if all the sources are available,
> or tagged.
>
> I am happy to see that the aarch64-port tries to keep up with the jdk8u project
> however this is a different story with the aarch32-port project:  The project
> doesn't have *any* prerelease tags, plus the project updates it's release tags
> only months after the jdk8u releases.  So blaming Debian for shipping what they
> are able to ship and Azul holding back source releases yourself?   Ein Schelm
> wer Böses dabei denkt ...
>
>> Similarly:
>>
>> Lumpy.local-46% docker run -it --rm openjdk:11 java -version
>> openjdk version "11.0.3" 2019-04-16
>> OpenJDK Runtime Environment (build 11.0.3+1-Debian-1bpo91)
>> OpenJDK 64-Bit Server VM (build 11.0.3+1-Debian-1bpo91, mixed mode, sharing)
>> Lumpy.local-47% date
>> Wed May 15 11:43:12 PDT 2019
>>
>> This one was populate dno later than April 3, 2 weeks before
>> the actual 11.0.3 was released on April 16, 2019
>>
>> If anyone was wondering about the importance of having version strings say
>> "EA" (or some other "THIS IS NOT a RELEASED VERSION" warning) on any
>> and all OpenJDK builds that are not an actual release build, the above shows
>> you how bad things get when that practice is not followed.
>
> Don't trust the label, just the content.  I agree that the java community is
> much more label/version driven, however this is not a reason to discredit other
> sane builds.
>
>> Why Debian populated their repos with these builds is their business, and
>> why docker chose to use those specific debian builds can be speculated
>> about all we want. the details don't matter. The end result of these
>> cumulative "reasonable" (according to some people) choices is that the
>> default openjdk runs done by millions of people on docker right now are
>> using "mystery meat", incomplete, and exposed builds while seeming to
>> report (to the lay person) a Java version that would suggest a real 8u212
>> or 11.0.3 (which one would expect has the security vulnerabilities in the
>> April update addressed, the bug fixes included, etc.).
>
> Again, I see this as an advertising or promotion email for the Azul binary
> builds.  Fine, do so.  Both please use marketing lists and not the OpenJDK
> technical lists.
>
> Matthias
Reply | Threaded
Open this post in threaded view
|

Re: Mystery meat OpenJDK builds strike again

Gil Tene
In reply to this post by Matthias Klose-6


> On May 26, 2019, at 3:25 PM, Matthias Klose <[hidden email]> wrote:
>
> I am disappointed to see such trolling, bashing and telling fake news on a
> technical mailing list.  Is this Azul's business model to promote their own
> binary builds?
>
> Such behavior propagates e.g. via twitter
> https://twitter.com/jroper/status/1130678379403857920
>
> I'm starting the discussion about version numbers and release information in a
> new thread.
>
> I am neither involved with any Docker image nor with any Debian backport.
>
> Debian provides security support for its stable release (stretch, 9.x).
> openjdk-11 isn't part of any released Debian version.
>
> Ubuntu ships openjdk-8 as a supported package in Ubuntu 16.04 LTS and is
> committed to provide security support for openjdk-8 in Ubuntu 18.04 LTS until
> the EOL of Ubuntu 16.04 LTS (around April 2021).
>
> Ubuntu 18.04 LTS initially shipped with OpenJDK 10 with the commitment to update
> to OpenJDK 11 which now is available in the Ubuntu 18.04 LTS release (in the
> security pocket).
>
> There is no mystery meat, just security supported uploads for both Debian and
> Ubuntu.
With such an emphatic attack on the motives associated with the original posting on
this thread, I tried to figure out what might lead someone to take that path. I can attribute
one of few possible logic paths that may lead you to making the above argument:

a) You never bothered to check any of the actual facts posted, and just assumed the
original posting was fake news.

b) You did check the facts, but read the output wrong (like most people in the world
would have, since the scary details behind the specific 8u212 and
11.0.3 builds involved need some digging to figure out), and somehow assumed that the
thing reporting e.g. 'openjdk version "1.8.0_212"' was a good (non-Mystery-Meat) build
of the released version being reported.

c) You know the facts, but want others to think someone else is wrong for pointing them
out, and go about doing that by trying to associate as many negative motives as you can
muster ("trolling", "bashing", "fake news", "marketing", "business model", "advertising",
"promotion", all of which you had literally used in this one e-mail) to the factual posting
at the top of this tread.

d) You think the facts posted, even when true, do not amount to the associated builds
deserving to be called Mystery Meat.

So let's quickly dispense the first two possibilities: If the benefit of the doubt for not actually
realizing the truth of the situation, and the accuracy of the contents of the original e-mail is
deserved, and you wrongly called this stuff "fake news", go ahead and check on the facts
and come back to us with a correction.

But somehow (see below), I doubt that (a) or (b) explain your misrepresentation of facts in
this e-mail.

I doubt that the original e-mail in this thread could have been much more clear or specific
in documenting the actual Mystery Meat situation in the wild on the date it was posted.
Thankfully, the Official Docker openjdk images has since fixed their official builds to no
longer present docker users with images containing faulty, Mystery Meat 8u212 and
11.0.3 OpenJDK versions.

However, there seem to be plenty of people (you included, clearly, per this very e-mail)
who are trying to argue that the builds themselves are not a problem, that it is the lack of
education or understanding of the end-user that is responsible, etc. Many of these
arguments have taken a deflection approach of e.g. focusing on OpenJDK 11, combined
with something like "the good, stable, meant-for-actual-use, security-supported version of
Debian (debian stretrch, 9.x per the above) does not provide openjdk-11, and some
irresponsible middle-person act of taking mislabeled builds from other repos (e.g. backports,
unstable, etc.) is to blame.

Fine, let's go with that for just a minute. Ignore the fact that the original posting was about
the end-result (and specifically stated "Why Debian populated their repos with these builds
is their business") and ignore the impact on OpenJDK 11. Just for a  minute. Let's focus on
the OpenJDK 8 part, and let's test the facts, *today*, and limit our testing to the stable,
"security supported uploads" in Debian stretch:

We still end up staring at this very inconvenient truth: OpenJDK 8, Debian (stable, stretch, 9),
and the current situation (two weeks into being alerted to it) show the following right now:

root@020dc36b9046:/#
root@020dc36b9046:/# date
Sun May 26 23:55:45 UTC 2019
root@020dc36b9046:/#
root@020dc36b9046:/# cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
NAME="Debian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
root@020dc36b9046:/#
root@020dc36b9046:/# apt-get update
Ign:2 http://cdn-fastly.deb.debian.org/debian stable InRelease
Hit:1 http://security-cdn.debian.org/debian-security stable/updates InRelease
Hit:3 http://cdn-fastly.deb.debian.org/debian stable-updates InRelease
Hit:4 http://cdn-fastly.deb.debian.org/debian stable Release
Reading package lists... Done
root@020dc36b9046:/#
root@020dc36b9046:/# apt-get install openjdk-8-jdk
...
root@020dc36b9046:/#
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:/#

To be clear on what ״build 1.8.0_212-8u212-b01-1~deb9u1-b01" in the above tracks to,
we can track it in https://tracker.debian.org/pkg/openjdk-8 , which has this convenient log
for when the build was created (March 29, 2019, 3 weeks prior to the actual release of
8u212 by the OpenJDK 8u project):

        • [2019-04-06] openjdk-8 REMOVED from testing (Debian testing watch)
        • [2019-03-30] Removed 8u212-b01-1 from unstable (Debian FTP Masters)
        • [2019-03-30] Removed 8u144-b01-2 from unstable (Debian FTP Masters)
        • [2019-03-30] Removed 8u141-b15-3 from unstable (Debian FTP Masters)
        • [2019-03-29] openjdk-8 8u212-b01-1 MIGRATED to testing (Debian testing watch)
        • [2019-03-29] Accepted openjdk-8 8u212-b01-1~deb9u1 (source amd64 all) into proposed-updates->stable-new, proposed-updates (Moritz Muehlenhoff) (signed by: Moritz Mühlenhoff)
        • [2019-03-20] Accepted openjdk-8 8u212-b01-1~deb9u1 (source amd64 all) into stable->embargoed, stable(Moritz Muehlenhoff) (signed by: Moritz Mühlenhoff)
        • [2019-03-19] Accepted openjdk-8 8u212-b01-1 (source) into unstable (Matthias Klose)

[The fact that your name is on the actual log items above makes it unlikely that options (a) or (b) above apply. It's pretty clearly (c) and/or (d).]

So what do we have here?

A mislabeled (' openjdk version "1.8.0_212" ', no disqualifiers, early access, or "danger,
this is not really 8u212" labeled anywhere), fell off the truck (actually built from sources
picked up at a random weekly tag point, 3 weeks prior to the actual 8u212 release was
complete, and missing a multitude of bug fixes and security fixes that are in the actual
8u212 release), build of OpenJDK "8u212" is being delivered in the current, stable, debian
release from default repositories. Not the unstable repos, not the backports repos, not
by some other version's repos, not by some middle-men.

You may not think that "Mystery Meat" is a good label for this very situation. But I suspect
that would put you in the tiny minority of people who believe or argue that all meat, from all
sources, is equally untrustworthy. And that labels, cleanliness, use-by-dates, and (most
importantly) reputation for label accuracy and trustworthiness should not affect people's
consumption choices.

That's what is going on right now. Arguing that someone else is to blame doesn't change
it. Arguing that "the media" is against you and has nefarious motives doesn't either. And
arguing that "this is fine, and it is what users of "stable" Debian should expect", well, that
just tells them what to expect, I guess.

>
> On 15.05.19 20:49, Gil Tene wrote:
>> Umm…
>>
>> Lumpy.local-43% docker run -it --rm openjdk:8 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)
>> Lumpy.local-44% date
>> Wed May 15 11:41:12 PDT 2019
>>
>> Look at the build number carefully… This was populated no later
>> than March 27, 2019. 3 weeks before the actual 8u212 was released
>> on April 16, 2019.
>
> The Debian openjdk-8 source package is put together from the jdk8u,
> aarch64-port/jdk8u-shenandoah and aarch32-port/jdk8u projects.  Certainly not
> ideal, however these packages can only be made if all the sources are available,
> or tagged.
>
> I am happy to see that the aarch64-port tries to keep up with the jdk8u project
> however this is a different story with the aarch32-port project:  The project
> doesn't have *any* prerelease tags, plus the project updates it's release tags
> only months after the jdk8u releases.  So blaming Debian for shipping what they
> are able to ship and Azul holding back source releases yourself?   Ein Schelm
> wer Böses dabei denkt ...
>
>> Similarly:
>>
>> Lumpy.local-46% docker run -it --rm openjdk:11 java -version
>> openjdk version "11.0.3" 2019-04-16
>> OpenJDK Runtime Environment (build 11.0.3+1-Debian-1bpo91)
>> OpenJDK 64-Bit Server VM (build 11.0.3+1-Debian-1bpo91, mixed mode, sharing)
>> Lumpy.local-47% date
>> Wed May 15 11:43:12 PDT 2019
>>
>> This one was populate dno later than April 3, 2 weeks before
>> the actual 11.0.3 was released on April 16, 2019
>>
>> If anyone was wondering about the importance of having version strings say
>> "EA" (or some other "THIS IS NOT a RELEASED VERSION" warning) on any
>> and all OpenJDK builds that are not an actual release build, the above shows
>> you how bad things get when that practice is not followed.
>
> Don't trust the label, just the content.  I agree that the java community is
> much more label/version driven, however this is not a reason to discredit other
> sane builds.
>
>> Why Debian populated their repos with these builds is their business, and
>> why docker chose to use those specific debian builds can be speculated
>> about all we want. the details don't matter. The end result of these
>> cumulative "reasonable" (according to some people) choices is that the
>> default openjdk runs done by millions of people on docker right now are
>> using "mystery meat", incomplete, and exposed builds while seeming to
>> report (to the lay person) a Java version that would suggest a real 8u212
>> or 11.0.3 (which one would expect has the security vulnerabilities in the
>> April update addressed, the bug fixes included, etc.).
>
> Again, I see this as an advertising or promotion email for the Azul binary
> builds.  Fine, do so.  Both please use marketing lists and not the OpenJDK
> technical lists.
>
> Matthias


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Mystery meat OpenJDK builds strike again

Florian Weimer-4
* 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:/#

I wonder if the core technical issue is this: Debian stretch currently
packages OpenJDK 8 8u212-b01, when it should be packaging 8u212-b03 or
8u212-b04 (which one isn't clear, the release announcement
<https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-April/009115.html>
was for 8u212-b03, not for 8u212-b04 or 8u212-ga).

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 release.

Thanks,
Florian

Reply | Threaded
Open this post in threaded view
|

Re: Mystery meat OpenJDK builds strike again

Martijn Verburg
In reply to this post by Gil Tene
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(s) map onto the Debian packaging system/channels. It's been a failing on the OpenJDK community side to help communicate this properly, let's fix that together :-).

There's currently another thread going on that is working to resolve this challenge, that's where I suggest we focus our time and efforts.

In the meantime [hidden email] - I'm happy to jump on a call this week (I'm in the UK timezone) - I'd personally like to understand the Debian packaging ecosystem better and learn how OpenJDK can help ensure that release and pre-release builds go into the correct channels going forward.  There are certainly some gotchas when it comes to the aarch64/32 ports as well, the 'canonical' repositories aren't always what look like the obvious ones!

Let me know what day/time suits and we will work through this as a joint community.

Cheers,
Martijn


On Mon, 27 May 2019 at 02:25, Gil Tene <[hidden email]> wrote:


> On May 26, 2019, at 3:25 PM, Matthias Klose <[hidden email]> wrote:
>
> I am disappointed to see such trolling, bashing and telling fake news on a
> technical mailing list.  Is this Azul's business model to promote their own
> binary builds?
>
> Such behavior propagates e.g. via twitter
> https://twitter.com/jroper/status/1130678379403857920
>
> I'm starting the discussion about version numbers and release information in a
> new thread.
>
> I am neither involved with any Docker image nor with any Debian backport.
>
> Debian provides security support for its stable release (stretch, 9.x).
> openjdk-11 isn't part of any released Debian version.
>
> Ubuntu ships openjdk-8 as a supported package in Ubuntu 16.04 LTS and is
> committed to provide security support for openjdk-8 in Ubuntu 18.04 LTS until
> the EOL of Ubuntu 16.04 LTS (around April 2021).
>
> Ubuntu 18.04 LTS initially shipped with OpenJDK 10 with the commitment to update
> to OpenJDK 11 which now is available in the Ubuntu 18.04 LTS release (in the
> security pocket).
>
> There is no mystery meat, just security supported uploads for both Debian and
> Ubuntu.

With such an emphatic attack on the motives associated with the original posting on
this thread, I tried to figure out what might lead someone to take that path. I can attribute
one of few possible logic paths that may lead you to making the above argument:

a) You never bothered to check any of the actual facts posted, and just assumed the
original posting was fake news.

b) You did check the facts, but read the output wrong (like most people in the world
would have, since the scary details behind the specific 8u212 and
11.0.3 builds involved need some digging to figure out), and somehow assumed that the
thing reporting e.g. 'openjdk version "1.8.0_212"' was a good (non-Mystery-Meat) build
of the released version being reported.

c) You know the facts, but want others to think someone else is wrong for pointing them
out, and go about doing that by trying to associate as many negative motives as you can
muster ("trolling", "bashing", "fake news", "marketing", "business model", "advertising",
"promotion", all of which you had literally used in this one e-mail) to the factual posting
at the top of this tread.

d) You think the facts posted, even when true, do not amount to the associated builds
deserving to be called Mystery Meat.

So let's quickly dispense the first two possibilities: If the benefit of the doubt for not actually
realizing the truth of the situation, and the accuracy of the contents of the original e-mail is
deserved, and you wrongly called this stuff "fake news", go ahead and check on the facts
and come back to us with a correction.

But somehow (see below), I doubt that (a) or (b) explain your misrepresentation of facts in
this e-mail.

I doubt that the original e-mail in this thread could have been much more clear or specific
in documenting the actual Mystery Meat situation in the wild on the date it was posted.
Thankfully, the Official Docker openjdk images has since fixed their official builds to no
longer present docker users with images containing faulty, Mystery Meat 8u212 and
11.0.3 OpenJDK versions.

However, there seem to be plenty of people (you included, clearly, per this very e-mail)
who are trying to argue that the builds themselves are not a problem, that it is the lack of
education or understanding of the end-user that is responsible, etc. Many of these
arguments have taken a deflection approach of e.g. focusing on OpenJDK 11, combined
with something like "the good, stable, meant-for-actual-use, security-supported version of
Debian (debian stretrch, 9.x per the above) does not provide openjdk-11, and some
irresponsible middle-person act of taking mislabeled builds from other repos (e.g. backports,
unstable, etc.) is to blame.

Fine, let's go with that for just a minute. Ignore the fact that the original posting was about
the end-result (and specifically stated "Why Debian populated their repos with these builds
is their business") and ignore the impact on OpenJDK 11. Just for a  minute. Let's focus on
the OpenJDK 8 part, and let's test the facts, *today*, and limit our testing to the stable,
"security supported uploads" in Debian stretch:

We still end up staring at this very inconvenient truth: OpenJDK 8, Debian (stable, stretch, 9),
and the current situation (two weeks into being alerted to it) show the following right now:

root@020dc36b9046:/#
root@020dc36b9046:/# date
Sun May 26 23:55:45 UTC 2019
root@020dc36b9046:/#
root@020dc36b9046:/# cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
NAME="Debian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
root@020dc36b9046:/#
root@020dc36b9046:/# apt-get update
Ign:2 http://cdn-fastly.deb.debian.org/debian stable InRelease
Hit:1 http://security-cdn.debian.org/debian-security stable/updates InRelease
Hit:3 http://cdn-fastly.deb.debian.org/debian stable-updates InRelease
Hit:4 http://cdn-fastly.deb.debian.org/debian stable Release
Reading package lists... Done
root@020dc36b9046:/#
root@020dc36b9046:/# apt-get install openjdk-8-jdk
...
root@020dc36b9046:/#
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:/#

To be clear on what ״build 1.8.0_212-8u212-b01-1~deb9u1-b01" in the above tracks to,
we can track it in https://tracker.debian.org/pkg/openjdk-8 , which has this convenient log
for when the build was created (March 29, 2019, 3 weeks prior to the actual release of
8u212 by the OpenJDK 8u project):

        • [2019-04-06] openjdk-8 REMOVED from testing (Debian testing watch)
        • [2019-03-30] Removed 8u212-b01-1 from unstable (Debian FTP Masters)
        • [2019-03-30] Removed 8u144-b01-2 from unstable (Debian FTP Masters)
        • [2019-03-30] Removed 8u141-b15-3 from unstable (Debian FTP Masters)
        • [2019-03-29] openjdk-8 8u212-b01-1 MIGRATED to testing (Debian testing watch)
        • [2019-03-29] Accepted openjdk-8 8u212-b01-1~deb9u1 (source amd64 all) into proposed-updates->stable-new, proposed-updates (Moritz Muehlenhoff) (signed by: Moritz Mühlenhoff)
        • [2019-03-20] Accepted openjdk-8 8u212-b01-1~deb9u1 (source amd64 all) into stable->embargoed, stable(Moritz Muehlenhoff) (signed by: Moritz Mühlenhoff)
        • [2019-03-19] Accepted openjdk-8 8u212-b01-1 (source) into unstable (Matthias Klose)

[The fact that your name is on the actual log items above makes it unlikely that options (a) or (b) above apply. It's pretty clearly (c) and/or (d).]

So what do we have here?

A mislabeled (' openjdk version "1.8.0_212" ', no disqualifiers, early access, or "danger,
this is not really 8u212" labeled anywhere), fell off the truck (actually built from sources
picked up at a random weekly tag point, 3 weeks prior to the actual 8u212 release was
complete, and missing a multitude of bug fixes and security fixes that are in the actual
8u212 release), build of OpenJDK "8u212" is being delivered in the current, stable, debian
release from default repositories. Not the unstable repos, not the backports repos, not
by some other version's repos, not by some middle-men.

You may not think that "Mystery Meat" is a good label for this very situation. But I suspect
that would put you in the tiny minority of people who believe or argue that all meat, from all
sources, is equally untrustworthy. And that labels, cleanliness, use-by-dates, and (most
importantly) reputation for label accuracy and trustworthiness should not affect people's
consumption choices.

That's what is going on right now. Arguing that someone else is to blame doesn't change
it. Arguing that "the media" is against you and has nefarious motives doesn't either. And
arguing that "this is fine, and it is what users of "stable" Debian should expect", well, that
just tells them what to expect, I guess.

>
> On 15.05.19 20:49, Gil Tene wrote:
>> Umm…
>>
>> Lumpy.local-43% docker run -it --rm openjdk:8 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)
>> Lumpy.local-44% date
>> Wed May 15 11:41:12 PDT 2019
>>
>> Look at the build number carefully… This was populated no later
>> than March 27, 2019. 3 weeks before the actual 8u212 was released
>> on April 16, 2019.
>
> The Debian openjdk-8 source package is put together from the jdk8u,
> aarch64-port/jdk8u-shenandoah and aarch32-port/jdk8u projects.  Certainly not
> ideal, however these packages can only be made if all the sources are available,
> or tagged.
>
> I am happy to see that the aarch64-port tries to keep up with the jdk8u project
> however this is a different story with the aarch32-port project:  The project
> doesn't have *any* prerelease tags, plus the project updates it's release tags
> only months after the jdk8u releases.  So blaming Debian for shipping what they
> are able to ship and Azul holding back source releases yourself?   Ein Schelm
> wer Böses dabei denkt ...
>
>> Similarly:
>>
>> Lumpy.local-46% docker run -it --rm openjdk:11 java -version
>> openjdk version "11.0.3" 2019-04-16
>> OpenJDK Runtime Environment (build 11.0.3+1-Debian-1bpo91)
>> OpenJDK 64-Bit Server VM (build 11.0.3+1-Debian-1bpo91, mixed mode, sharing)
>> Lumpy.local-47% date
>> Wed May 15 11:43:12 PDT 2019
>>
>> This one was populate dno later than April 3, 2 weeks before
>> the actual 11.0.3 was released on April 16, 2019
>>
>> If anyone was wondering about the importance of having version strings say
>> "EA" (or some other "THIS IS NOT a RELEASED VERSION" warning) on any
>> and all OpenJDK builds that are not an actual release build, the above shows
>> you how bad things get when that practice is not followed.
>
> Don't trust the label, just the content.  I agree that the java community is
> much more label/version driven, however this is not a reason to discredit other
> sane builds.
>
>> Why Debian populated their repos with these builds is their business, and
>> why docker chose to use those specific debian builds can be speculated
>> about all we want. the details don't matter. The end result of these
>> cumulative "reasonable" (according to some people) choices is that the
>> default openjdk runs done by millions of people on docker right now are
>> using "mystery meat", incomplete, and exposed builds while seeming to
>> report (to the lay person) a Java version that would suggest a real 8u212
>> or 11.0.3 (which one would expect has the security vulnerabilities in the
>> April update addressed, the bug fixes included, etc.).
>
> Again, I see this as an advertising or promotion email for the Azul binary
> builds.  Fine, do so.  Both please use marketing lists and not the OpenJDK
> technical lists.
>
> Matthias

Reply | Threaded
Open this post in threaded view
|

Re: Mystery meat OpenJDK builds strike again

Martijn Verburg
In reply to this post by Florian Weimer-4
On Mon, 27 May 2019 at 11:13, Florian Weimer <[hidden email]> 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:/#

I wonder if the core technical issue is this: Debian stretch currently
packages OpenJDK 8 8u212-b01, when it should be packaging 8u212-b03 or
8u212-b04 (which one isn't clear, the release announcement
<https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-April/009115.html>
was for 8u212-b03, not for 8u212-b04 or 8u212-ga).

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 release.

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 as it's really the Debian distro list that we should be discussing this on. 
If folks feel otherwise, let me know and I'll CC these lists back in.

Cheers,
Martijn
 

Thanks,
Florian
Reply | Threaded
Open this post in threaded view
|

Re: Mystery meat OpenJDK builds strike again

Florian Weimer-4
* Martijn Verburg:

> On Mon, 27 May 2019 at 11:13, Florian Weimer <[hidden email]> 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:/#
>
>  I wonder if the core technical issue is this: Debian stretch currently
>  packages OpenJDK 8 8u212-b01, when it should be packaging 8u212-b03 or
>  8u212-b04 (which one isn't clear, the release announcement
>  <https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-April/009115.html>
>  was for 8u212-b03, not for 8u212-b04 or 8u212-ga).
>
>  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 release.
>
> 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.

Right.  <https://adoptopenjdk.net/release_notes.html#jdk8u212> could
mention these tags and link to official tarball(s).  I suspect this page
is the permanent, quasi-official release announcement due to the
openjdk.java.net limitations.

It would also help to have a permanent location *anywhere* which is
compatible with distribution upstream watch files.

Thanks,
Florian

Reply | Threaded
Open this post in threaded view
|

Re: Mystery meat OpenJDK builds strike again

Thomas Stüfe
In reply to this post by Gil Tene
Hi Gil,

On Mon, May 27, 2019 at 1:41 AM Gil Tene <[hidden email]> wrote:
Seriously?

You see factual reporting (directly documented and dated in the original posting) of the actual version numbers being used by official docker images, along with irrefutable proof that the packages used in those were built weeks before the respective OpenJDK 8u and 11u releases were complete, as “fake news”?

You think that alerting millions of unsuspecting people using exposed, insecure builds that falsely report their OpenJDK version (as one that includes e.g. critical security fixes) to the fact as “marketing”?


Did you try to contact Debian folks to give them opportunity to fix those security concerns before going public with them? Or did they not react in time?

Cheers, Thomas

Reply | Threaded
Open this post in threaded view
|

Re: Mystery meat OpenJDK builds strike again

Emmanuel Bourg-3
Le 27/05/2019 à 16:59, Thomas Stüfe a écrit :

> Did you try to contact Debian folks to give them opportunity to fix
> those security concerns before going public with them?

No he didn't, and I don't think he cares. I'd like to thank Aleksey
Shipilev for bringing the issue in a constructive and civilized manner
on the debian-java list. This led to the upload of OpenJDK 11.0.3+7 to
the Debian 9 "Stretch" backport repository last week.

Emmanuel Bourg

Reply | Threaded
Open this post in threaded view
|

OpenJDK upstream ↔ Debian packages mapping (was Re: Mystery meat OpenJDK builds strike again)

Thorsten Glaser-6
In reply to this post by Martijn Verburg
Hi Martijn,

> understanding of how OpenJDK source(s) map onto the Debian packaging
> system/channels. It's been a failing on the OpenJDK community side to help

the Debian side of this, as relates to the releases, is this:


Debian 9 (stretch), the current stable release, shipped with
OpenJDK 8, so it will continue to receive security fixes for
OpenJDK 8 throughout its supported lifetime.

Debian 10 (buster), currently prerelease, will ship with
OpenJDK 11, and thus receive updates for OpenJDK 11.

stretch-backports is a suite which corresponds to backports
of those packages that are, at the time of backporting, in
buster. “backports” here basically means that the exact(!)
package is rebuilt in the previous distribution, and the only
allowed changes are those necessary to make it build and work
there. Debian backports also operate under the expectation
that, whenever a new version is uploaded to or migrates¹ to
the origin suite, the backport will be updated (or removed,
if backporting is no longer possible).

Now, buster is still prerelease, which means that the packages
in stretch-backports are also prerelease right now. (We’re
expecting to release within $smallnum weeks, though.) But they
will eventually be identical to what will be shipped with, and
supported in, buster.

① “migrate”: the testing distribution is a bit of special case,
  as packages are not normally directly uploaded there, but to
  unstable first and then migrate after a period of time in which
  bugs can be identified, and it will not migrate if it depends
  on any other packages that cannot migrate (unless the version
  already in testing satisfies the dependency).


Now I’m not involved in what actually goes into the packages
in the first place, but the plan (a bit taken off path by the
ftpmasters misinterpreting a removal request for some builds
of OpenJDK 8 in unstable as a request to remove OpenJDK 8 in
its entirety) is to prepare updated versions of all supported
JDKs in unstable, then, when no problems are shown, to upload
those to oldstable-security or stable-security or testing² as
needed, and then (following backports policy) updating the
backports accordingly (oldstable-backports from stable-security,
stable-backports from testing).

② normally by letting it migrate, or, during pre-release freeze,
  requesting an unblock to allow the package to migrate


The intent is to package stable versions for actual Debian
releases, then apply necessary security fixes afterwards
(because in Debian, we never³ introduce new versions into
an already released version as part of the stability promise).

I assume part of the problem is the difficulty of identifying
what’s stable (and get the corresponding addons for e.g. the
ARM architectures), but, as doko said, trust the content, not
the label. Versions of software Debian ships don’t necessarily
correspond to the versions in other distributions of the same
software, but they are those tested and integrated with the
rest of the distribution, and those that will be supported by
the Debian maintainers and security team.

As a user, I’d rather have a, say, 8u212 upstream prerelease
that’s supported by the security team (and that works for our
use cases in building and running software in Java™, and that
integrates with the rest of the software shipped by Debian)
than to blindly install new upstream versions, especially if
those introduce regressions. (It was bad enough when those
JAR manifest “security” patches broke builds for ages.)

③ This is not entirely true, admittedly: for select software,
  such as “modern” web browsers, where supporting the versions
  in stable over the lifetime of a release is not possible at
  all, new versions are allowed into stable-security, but this
  deviates from both the security and the stability promises
  and is communicated to users as a compromise (we rather ship
  an unsupported but recent version than none at all, so our
  users may get the software) but we prefer to do that only
  when the regular way of retrofitting security updates only
  is not at all possible.

  For OpenJDK and some other softwares, it is understood that
  upstream branches containing only security fixes for the
  released version is acceptable for uploads of “new” versions
  (as long as those are really security and critical bug fixes
  only, not new versions or features; and even then, sometimes
  things break in a bad way, which we’d like to avoid).

Ah, and here comes the reasoning why an 8u212 prerelease is
no problem (as long as it’ll eventually be replaced by the
actual release or something newer): when an upstream branch
is considered to be comprised of only security and critica
bug fixes, the releases upstream cuts off that branch are
just snapshots at some given point in time, and a prerelease
would be just as stable, as surely upstream would only have
applied a patch to that branch only if it addresses either
a security problem or a critical bug and it had already been
tested in the latest development/feature branch. (Does this
make sense? If not, please DO tell, and I’ll try to explain
some more, as this is a core point and somewhat critical.)


Full disclosure: I’m a Debian Developer and maintainer of a
couple of packages, but not of any of the core Java packages.
In my dayjob, I’m a user of those, package some fringe ones
and occasionally help out.

Please listen to doko for anything authoritative to OpenJDK
packaging, and for anything to do with Canonical/Ubuntu with
which I have nothing to do.


Something else to keep in mind: all this talking about a
specific “build” of Java, as that Azul person does, cannot
apply to Debian as we always build all software shipped in
Debian ourselves from source code. So it’s best to avoid
using the word “build” when discussing something with Debian.

I think terms that correspond to specific statuses of the
source code trees and branches would work better instead.

bye,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**********

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.

**********

Reply | Threaded
Open this post in threaded view
|

Re: Mystery meat OpenJDK builds strike again

Matthias Klose-6
In reply to this post by Thomas Stüfe
On 27.05.19 18:23, Gil Tene wrote:
>> Did you try to contact Debian folks to give them opportunity to fix those security concerns before going public with them? Or did they not react in time?
>
> Multiple times over ~4.5 years, and through multiple channels. The
> “we don’t care”, “go away, vendor”, and “java and openjdk do versioning
> wrong” reactions are the most common. Many were less polite than that.
> The defensive tone of the email you see on this thread is about average.
> The denial and deflection attempts you see there are also common.

I can't follow that.  There is not a single bug report about that in the Debian
tracker.   Looking at the Debian Java mailing list, there is not a single
posting from your side.  And I can't remember that being discussed on the ML
either.  Also not on the distro-pkg-dev ML.  Same thing for the Ubuntu bug
tracker.  So which channels are you using?

> Some people just don’t want help, at least not from some. And that’s fine.

I raised questions about the versioning on the jdk ML's multiple times.  Most of
those were ignored, or saw the versioning as being correct.  I brought up the
configuration issues at this year OpenJDK committers workshop, but it was voted
down because other topics seemed more pressing to discuss.

Matthias

Reply | Threaded
Open this post in threaded view
|

Re: Mystery meat OpenJDK builds strike again

Martijn Verburg
In reply to this post by Florian Weimer-4
Hi Florian,

<snip>

>  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 release.
>
> 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.

Right.  <https://adoptopenjdk.net/release_notes.html#jdk8u212> could
mention these tags and link to official tarball(s).  I suspect this page
is the permanent, quasi-official release announcement due to the
openjdk.java.net limitations.

It would also help to have a permanent location *anywhere* which is
compatible with distribution upstream watch files.

Right, you are - https://github.com/AdoptOpenJDK/openjdk-website/pull/501 raised to resolve this, thanks!

Cheers,
Martijn
 

Thanks,
Florian
Reply | Threaded
Open this post in threaded view
|

Re: Mystery meat OpenJDK builds strike again

Martijn Verburg
In reply to this post by Martijn Verburg
Hi all,

<snip>

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 as it's really the Debian distro list that we should be discussing this on. 
If folks feel otherwise, let me know and I'll CC these lists back in.

FYI - I have a call (high bandwidth is required here) with Matthias next Monday (1100UK time) so I can learn more about the Debian process and what we can do to align going forward.  I'll report back here or via a Debian ticket so the conversation and outcomes can be tracked.

if anyone else wants to join on the call then please let me know!

Cheers,
Martijn
Reply | Threaded
Open this post in threaded view
|

Re: OpenJDK upstream ↔ Debian packages mapping (was Re: Mystery meat OpenJDK builds strike again)

Martijn Verburg
In reply to this post by Thorsten Glaser-6
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, Thorsten Glaser <[hidden email]> wrote:
Hi Martijn,

> understanding of how OpenJDK source(s) map onto the Debian packaging
> system/channels. It's been a failing on the OpenJDK community side to help

the Debian side of this, as relates to the releases, is this:


Debian 9 (stretch), the current stable release, shipped with
OpenJDK 8, so it will continue to receive security fixes for
OpenJDK 8 throughout its supported lifetime.

Debian 10 (buster), currently prerelease, will ship with
OpenJDK 11, and thus receive updates for OpenJDK 11.

stretch-backports is a suite which corresponds to backports
of those packages that are, at the time of backporting, in
buster. “backports” here basically means that the exact(!)
package is rebuilt in the previous distribution, and the only
allowed changes are those necessary to make it build and work
there. Debian backports also operate under the expectation
that, whenever a new version is uploaded to or migrates¹ to
the origin suite, the backport will be updated (or removed,
if backporting is no longer possible).

Now, buster is still prerelease, which means that the packages
in stretch-backports are also prerelease right now. (We’re
expecting to release within $smallnum weeks, though.) But they
will eventually be identical to what will be shipped with, and
supported in, buster.

① “migrate”: the testing distribution is a bit of special case,
  as packages are not normally directly uploaded there, but to
  unstable first and then migrate after a period of time in which
  bugs can be identified, and it will not migrate if it depends
  on any other packages that cannot migrate (unless the version
  already in testing satisfies the dependency).


Now I’m not involved in what actually goes into the packages
in the first place, but the plan (a bit taken off path by the
ftpmasters misinterpreting a removal request for some builds
of OpenJDK 8 in unstable as a request to remove OpenJDK 8 in
its entirety) is to prepare updated versions of all supported
JDKs in unstable, then, when no problems are shown, to upload
those to oldstable-security or stable-security or testing² as
needed, and then (following backports policy) updating the
backports accordingly (oldstable-backports from stable-security,
stable-backports from testing).

② normally by letting it migrate, or, during pre-release freeze,
  requesting an unblock to allow the package to migrate


The intent is to package stable versions for actual Debian
releases, then apply necessary security fixes afterwards
(because in Debian, we never³ introduce new versions into
an already released version as part of the stability promise).

I assume part of the problem is the difficulty of identifying
what’s stable (and get the corresponding addons for e.g. the
ARM architectures), but, as doko said, trust the content, not
the label. Versions of software Debian ships don’t necessarily
correspond to the versions in other distributions of the same
software, but they are those tested and integrated with the
rest of the distribution, and those that will be supported by
the Debian maintainers and security team.

As a user, I’d rather have a, say, 8u212 upstream prerelease
that’s supported by the security team (and that works for our
use cases in building and running software in Java™, and that
integrates with the rest of the software shipped by Debian)
than to blindly install new upstream versions, especially if
those introduce regressions. (It was bad enough when those
JAR manifest “security” patches broke builds for ages.)

③ This is not entirely true, admittedly: for select software,
  such as “modern” web browsers, where supporting the versions
  in stable over the lifetime of a release is not possible at
  all, new versions are allowed into stable-security, but this
  deviates from both the security and the stability promises
  and is communicated to users as a compromise (we rather ship
  an unsupported but recent version than none at all, so our
  users may get the software) but we prefer to do that only
  when the regular way of retrofitting security updates only
  is not at all possible.

  For OpenJDK and some other softwares, it is understood that
  upstream branches containing only security fixes for the
  released version is acceptable for uploads of “new” versions
  (as long as those are really security and critical bug fixes
  only, not new versions or features; and even then, sometimes
  things break in a bad way, which we’d like to avoid).

Ah, and here comes the reasoning why an 8u212 prerelease is
no problem (as long as it’ll eventually be replaced by the
actual release or something newer): when an upstream branch
is considered to be comprised of only security and critica
bug fixes, the releases upstream cuts off that branch are
just snapshots at some given point in time, and a prerelease
would be just as stable, as surely upstream would only have
applied a patch to that branch only if it addresses either
a security problem or a critical bug and it had already been
tested in the latest development/feature branch. (Does this
make sense? If not, please DO tell, and I’ll try to explain
some more, as this is a core point and somewhat critical.)


Full disclosure: I’m a Debian Developer and maintainer of a
couple of packages, but not of any of the core Java packages.
In my dayjob, I’m a user of those, package some fringe ones
and occasionally help out.

Please listen to doko for anything authoritative to OpenJDK
packaging, and for anything to do with Canonical/Ubuntu with
which I have nothing to do.


Something else to keep in mind: all this talking about a
specific “build” of Java, as that Azul person does, cannot
apply to Debian as we always build all software shipped in
Debian ourselves from source code. So it’s best to avoid
using the word “build” when discussing something with Debian.

I think terms that correspond to specific statuses of the
source code trees and branches would work better instead.

bye,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

**********

Mit der tarent Academy bieten wir auch Trainings und Schulungen in den
Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an.

Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt.

**********
Reply | Threaded
Open this post in threaded view
|

Re: Mystery meat OpenJDK builds strike again

Gil Tene
In reply to this post by Florian Weimer-4


> On May 27, 2019, at 3:13 AM, Florian Weimer <[hidden email]> 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:/#
>
> I wonder if the core technical issue is this: Debian stretch currently
> packages OpenJDK 8 8u212-b01, when it should be packaging 8u212-b03 or
> 8u212-b04 (which one isn't clear, the release announcement
> <https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-April/009115.html>
> was for 8u212-b03, not for 8u212-b04 or 8u212-ga).
>
> 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 release.
8u212-b01 is NOT an OpenJDK 8u release. Not in any form, current or otherwise.

Let's be very clear here since this is at the heart of these (misunderstandings?):
Releases are identified with tags. Tags are not releases.

"8u212-b01" was a tag (in mercurial) used during the active development
of 8u212, well before it was released. It in no way identifies an OpenJDK 8u
release, and has no "release with this tag exists" implications. An entire
month of additional code development and integration followed this tag
point, before an actual release was arrived at, declared, and tagged.

The 8u project tags source code at various points in time on the way to eventual
release, and has done so for many years. Tags are often chosen at arbitrary
points in time (e.g. they might appear weekly during a rampdown period).

See example of when tags are used in a weekly progression:
https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-May/009309.html
https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-May/009360.html
https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-May/009388.html

8u212-b01 was used in e.g. https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-March/008939.html
and nothing in the 8u-dev list attempted to indicate any sort of release
(not even an "EA" thing) at the time.

>
> Thanks,
> Florian


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Mystery meat OpenJDK builds strike again

Gil Tene
In reply to this post by Martijn Verburg


On May 27, 2019, at 3:19 AM, Martijn Verburg <[hidden email]> wrote:

On Mon, 27 May 2019 at 11:13, Florian Weimer <[hidden email]> 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:/#

I wonder if the core technical issue is this: Debian stretch currently
packages OpenJDK 8 8u212-b01, when it should be packaging 8u212-b03 or
8u212-b04 (which one isn't clear, the release announcement
<https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-April/009115.html>
was for 8u212-b03, not for 8u212-b04 or 8u212-ga).

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 release.

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.

Let's be clear about what the new (as in "additional") -ga tag is, in order
to avoid the misunderstanding (that you can see in other threads) that
somehow OpenJDK has just now started declaring releases:

The notion of a "-ga" tag was added recently as a convenience mechanism
to help people  "identify snapshots of GA releases in Mercurial history without
having to know the build number of the GA release".

(see
for initial discussion). 
To quote from there:
"For example, to obtain JDK 10.0.2 GA sources today, one issues the
`hg update -r jdk-10.0.2+13` command. With the proposed
enhancement, `hg update -r jdk-10.0.2-ga` could have been used."

[GA and other] Releases
existed long before this tag was added, and every [GA and other] Release
has a known tag number.

The "-ga" tag is a welcome addition, and makes it much easier (fewer steps)
to find the sources for a release, as well as programmatically watch
for ones to appear.


I've also replied separately to this thread (with a meeting request) but cut out the OpenJDK mailing lists as it's really the Debian distro list that we should be discussing this on. 
If folks feel otherwise, let me know and I'll CC these lists back in.

Cheers,
Martijn
 

Thanks,
Florian


signature.asc (849 bytes) Download Attachment