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 <d...@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 <g...@azul.com> wrote: > > > > On May 26, 2019, at 3:25 PM, Matthias Klose <d...@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 > >
