Hacker News new | past | comments | ask | show | jobs | submit login
Ubuntu 18.04.2 LTS Released (ubuntu.com)
77 points by slyrus on Feb 10, 2019 | hide | past | web | favorite | 21 comments

I for one would very much like to see this bug in 18.04 fixed as a priority:


The Java 11 package installs Java 10. This was supposed to be a short term hack (because Ubuntu's long term supported version 18.04 was being released shortly before Java's long term supported version 11) but it's been a good while now - six months or so.

The short term support version 18.10 of Ubuntu has Java 11 so it's very non-obvious what the blocker is.

To me this seems like a really poor choice. The result of installing the Java 11 package but getting Java 10 clearly fails the principle of least astonishment. If we can live without the fix a quarter of the way to the next LTS edition of Ubuntu then we could have lived with Java 10 as the preferred (and correctly named) package in the first place.

Meanwhile the bug asks us not to spam with requests for updates yet there's no suggestion of where we can go to gauge what the timescales we're up against are.

It definitely dents my confidence in Ubuntu as a well organised distribution.

Reminds me of when they replaced ffmpeg with avconv. As in, installing 'ffmpeg' would give you something completely different.

Or when the proprietary Broadcom driver was replaced by open source version, although it was still lacking in features and we had to use LAN cable for about 6 months until it reached feature parity.

Debian's stretch-backports had a slightly awkward transition phase where "openjdk-11" started as Java 9, then 10, and then 11... took about a month for it to get "caught up". They did it because the JDK can be bootstrapped by version N-1, so building Java 11 required Java 10, which required Java 9 to build, which in turn required Java 8, which is the version in stretch anyway.

Though I doubt and hope Ubuntu didn't base their stuff on the backports branch...

That seems odd to me - why could one not install (or build) package N-1 in order to build package N ? i.e. why does it all need to be the same package name?

It would have required moving openjdk-9 and openjdk-10 into backports only to be removed later. These packages were already removed from unstable and testing, and I assume it would have made things only more of a hassle... Also I guess it meant that installing openjdk-11 on stretch-backports would eventually gain you Java 11 (and it does now).

I'm not a Debian maintainer. They'll probably have a better answer if you asked them :)

This looked like a decent idea when the package was created, but turned into a disaster, an example of how NOT to do things.

Yeah, I'm sympathetic to the Ubuntu maintainers - at this point there are teams/companies which have built some server application/service on Ubuntu 18.04, and expect no backwards-incompatible changes for 5 years (the classic stable distro objective), but if openjdk-11 is updated from openjdk 10.x to 11.x then some stuff will stop working. I'm curious how they'll resolve it (and I think an additional half-year past the openjdk-11 release is reasonable, in the overall 5-year timeframe).

(Meanwhile, apparently, some users have come to expect an upstream release to get into ubuntu stable updates within 2 days ?!)

Jdk 10 is unsupported already.

Stable linux distros have a long history of backporting security patches themselves - RHEL does this the most/longest, Debian and Ubuntu somewhat less but still a lot. They've given up on web browsers, but for most other stuff, definitely including java, they certainly can and do support what they have released. In the linked issue, it notes that they already have backported some security fixes that were in 11.0.1 to openjdk-10.

Possible, but is it a good idea?

If the package is called "openjdk-11", I want JDK 11.

This is not an official announcement and it has not been officially declared released or ISOs updated.

The last official comment was it was delayed till Thursday, Feb. 14:


Those preparing the release will update release notes and fixed bug lists (like this one) before the release.

The official release announcement is now out:


I wish there was some announcement about when HWE kernels will be available for 18.04. This page has not yet been updated.


Apparently 18.04.2 LTS has been released, as that's what my box reports running now. I don't see any clear announcements of the actual release, but perhaps they're just hard to find on the various ubuntu wiki/planet/mailing list/etc... sites.

It should make no difference to an existing installation. The point releases to LTS really just mean that the installer images are kept up to date.

So that means that if my system says it's version 18.04.1 and reports "your system is up to date", then I am up to date?

If you have done apt update and apt upgrade recently followed by a reboot then it will show .2 on login. I have just confirmed this on a VM.

Not true, they also come with hardware enablement updates (new kernel, graphics drivers, X and Wayland).

Does it include the fix for apt's recent mirror redirect vulnerability? If not, any update to a fresh system would be trivially susceptible to a MITM attack if redirects aren't disabled. This includes docker images as well: https://justi.cz/security/2019/01/22/apt-rce.html

Canonical really should enable https as an additional layer of protection. This isn't the first time a bug in apt's authentication was found and it's unlikely that this bug will be the last.

Fixed in January: https://people.canonical.com/~ubuntu-security/cve/2019/CVE-2...

edit: the updated, point release ISOs will have the fix

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact