Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.java > #11225 > unrolled thread

Re: Mystery meat OpenJDK builds strike again

Back to article view | Back to linux.debian.maint.java

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Mystery meat OpenJDK builds strike again Matthias Klose <doko@ubuntu.com> - 2019-05-27 00:50 +0200
    Re: Mystery meat OpenJDK builds strike again Gil Tene <gil@azul.com> - 2019-05-27 02:10 +0200
      Re: Mystery meat OpenJDK builds strike again Thomas Stüfe <thomas.stuefe@gmail.com> - 2019-05-27 17:20 +0200
        Re: Mystery meat OpenJDK builds strike again Emmanuel Bourg <ebourg@apache.org> - 2019-05-27 17:40 +0200
        Re: Mystery meat OpenJDK builds strike again Matthias Klose <doko@ubuntu.com> - 2019-05-27 19:20 +0200
    Re: Mystery meat OpenJDK builds strike again Gil Tene <gil@azul.com> - 2019-05-27 03:30 +0200
      Re: Mystery meat OpenJDK builds strike again Martijn Verburg <martijnverburg@gmail.com> - 2019-05-27 12:20 +0200
        Re: Mystery meat OpenJDK builds strike again Florian Weimer <fweimer@redhat.com> - 2019-05-27 13:00 +0200
          Re: Mystery meat OpenJDK builds strike again Martijn Verburg <martijnverburg@gmail.com> - 2019-05-28 11:00 +0200
        Re: Mystery meat OpenJDK builds strike again Martijn Verburg <martijnverburg@gmail.com> - 2019-05-28 11:00 +0200
        Re: Mystery meat OpenJDK builds strike again Gil Tene <gil@azul.com> - 2019-05-28 18:10 +0200
      Re: Mystery meat OpenJDK builds strike again Martijn Verburg <martijnverburg@gmail.com> - 2019-05-27 12:20 +0200
        OpenJDK upstream ↔ Debian packages mapping (was Re: Mystery meat OpenJDK builds strike again) Thorsten Glaser <t.glaser@tarent.de> - 2019-05-27 18:30 +0200
          Re: OpenJDK upstream ↔ Debian packages mapping (was Re: Mystery meat OpenJDK builds strike again) Martijn Verburg <martijnverburg@gmail.com> - 2019-05-28 12:00 +0200
      Re: Mystery meat OpenJDK builds strike again Florian Weimer <fweimer@redhat.com> - 2019-05-27 12:40 +0200
        Re: Mystery meat OpenJDK builds strike again Gil Tene <gil@azul.com> - 2019-05-28 18:00 +0200

#11225 — Re: Mystery meat OpenJDK builds strike again

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

[toc] | [next] | [standalone]

#11226

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 <doko@ubuntu.com> 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

[toc] | [prev] | [next] | [standalone]

#11236

[Multipart message — attachments visible in raw view] — view raw

Hi Gil,

On Mon, May 27, 2019 at 1:41 AM Gil Tene <gil@azul.com> 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

[toc] | [prev] | [next] | [standalone]

#11237

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

[toc] | [prev] | [next] | [standalone]

#11243

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

[toc] | [prev] | [next] | [standalone]

#11227

[Multipart message — attachments visible in raw view] — view raw

> On May 26, 2019, at 3:25 PM, Matthias Klose <doko@ubuntu.com> 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

[toc] | [prev] | [next] | [standalone]

#11228

[Multipart message — attachments visible in raw view] — view raw

On Mon, 27 May 2019 at 11:13, Florian Weimer <fweimer@redhat.com> 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
>

[toc] | [prev] | [next] | [standalone]

#11232

* Martijn Verburg:

> On Mon, 27 May 2019 at 11:13, Florian Weimer <fweimer@redhat.com> 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

[toc] | [prev] | [next] | [standalone]

#11249

[Multipart message — attachments visible in raw view] — view raw

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
>

[toc] | [prev] | [next] | [standalone]

#11250

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#11257

[Multipart message — attachments visible in raw view] — view raw

> On May 27, 2019, at 3:19 AM, Martijn Verburg <martijnverburg@gmail.com> wrote:
> 
> On Mon, 27 May 2019 at 11:13, Florian Weimer <fweimer@redhat.com <mailto:fweimer@redhat.com>> 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 <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
https://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-October/007940.html
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

[toc] | [prev] | [next] | [standalone]

#11229

[Multipart message — attachments visible in raw view] — view raw

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 @Matthias Klose <doko@ubuntu.com> - 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 <gil@azul.com> wrote:

>
>
> > On May 26, 2019, at 3:25 PM, Matthias Klose <doko@ubuntu.com> 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
>
>

[toc] | [prev] | [next] | [standalone]

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

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.

**********

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

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 <t.glaser@tarent.de> 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.
>
> **********
>

[toc] | [prev] | [next] | [standalone]

#11231

* 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

[toc] | [prev] | [next] | [standalone]

#11256

[Multipart message — attachments visible in raw view] — view raw

> On May 27, 2019, at 3:13 AM, Florian Weimer <fweimer@redhat.com> 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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.java

csiph-web