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

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

Re: Debian distributions of stable OpenJDK updates

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: Debian distributions of stable OpenJDK updates Emmanuel Bourg <ebourg@apache.org> - 2019-05-20 12:20 +0200
    Re: Debian distributions of stable OpenJDK updates Emmanuel Bourg <ebourg@apache.org> - 2019-05-20 14:40 +0200
      Re: Debian distributions of stable OpenJDK updates Emmanuel Bourg <ebourg@apache.org> - 2019-05-20 15:10 +0200
        Re: Debian distributions of stable OpenJDK updates tony mancill <tmancill@debian.org> - 2019-05-22 06:20 +0200
          Re: Debian distributions of stable OpenJDK updates Emmanuel Bourg <ebourg@apache.org> - 2019-05-22 12:30 +0200
            Re: Debian distributions of stable OpenJDK updates tony mancill <tmancill@debian.org> - 2019-05-22 16:40 +0200
            Re: Debian distributions of stable OpenJDK updates Matthias Klose <doko@debian.org> - 2019-05-26 22:00 +0200
              Re: Debian distributions of stable OpenJDK updates Emmanuel Bourg <ebourg@apache.org> - 2019-05-27 00:00 +0200
                Re: Debian distributions of stable OpenJDK updates Matthias Klose <doko@debian.org> - 2019-05-27 16:00 +0200
              Re: Debian distributions of stable OpenJDK updates Thorsten Glaser <t.glaser@tarent.de> - 2019-05-27 18:50 +0200
      Re: Debian distributions of stable OpenJDK updates Emmanuel Bourg <ebourg@apache.org> - 2019-05-23 18:00 +0200
        Re: Debian distributions of stable OpenJDK updates Martijn Verburg <martijnverburg@gmail.com> - 2019-05-23 19:10 +0200
          Re: Debian distributions of stable OpenJDK updates Emmanuel Bourg <ebourg@apache.org> - 2019-05-24 00:00 +0200
            Re: Debian distributions of stable OpenJDK updates Thorsten Glaser <t.glaser@tarent.de> - 2019-05-24 00:50 +0200
              Re: Debian distributions of stable OpenJDK updates tony mancill <tmancill@debian.org> - 2019-05-25 18:10 +0200
                Re: Debian distributions of stable OpenJDK updates Emmanuel Bourg <ebourg@apache.org> - 2019-05-27 17:10 +0200
                Re: Debian distributions of stable OpenJDK updates Thorsten Glaser <t.glaser@tarent.de> - 2019-05-27 18:40 +0200
                  Re: Debian distributions of stable OpenJDK updates Emmanuel Bourg <ebourg@apache.org> - 2019-05-28 10:40 +0200
                    Re: Debian distributions of stable OpenJDK updates Thorsten Glaser <t.glaser@tarent.de> - 2019-05-29 14:20 +0200
                      Re: Debian distributions of stable OpenJDK updates Emmanuel Bourg <ebourg@apache.org> - 2019-05-30 00:10 +0200
            Re: Debian distributions of stable OpenJDK updates tony mancill <tmancill@debian.org> - 2019-05-24 15:50 +0200
              Re: Debian distributions of stable OpenJDK updates Martijn Verburg <martijnverburg@gmail.com> - 2019-05-24 20:30 +0200
                Re: Debian distributions of stable OpenJDK updates Matthias Klose <doko@debian.org> - 2019-05-26 21:50 +0200
                  Re: Debian distributions of stable OpenJDK updates tony mancill <tmancill@debian.org> - 2019-05-27 00:00 +0200
                    Re: Debian distributions of stable OpenJDK updates Matthias Klose <doko@debian.org> - 2019-05-27 16:10 +0200
                    Re: Debian distributions of stable OpenJDK updates Thorsten Glaser <t.glaser@tarent.de> - 2019-05-27 18:40 +0200
                      debian/watch file for OpenJDK (was Re: Debian distributions of stable  OpenJDK updates) Emmanuel Bourg <ebourg@apache.org> - 2019-05-28 10:30 +0200
                        Re: debian/watch file for OpenJDK (was Re: Debian distributions of  stable OpenJDK updates) Paul Wise <pabs@debian.org> - 2019-05-28 11:20 +0200
                          Re: debian/watch file for OpenJDK (was Re: Debian distributions of  stable OpenJDK updates) Emmanuel Bourg <ebourg@apache.org> - 2019-05-28 11:30 +0200
                            Re: debian/watch file for OpenJDK (was Re: Debian distributions of  stable OpenJDK updates) Tiago Daitx <tiago.daitx@canonical.com> - 2019-05-29 04:10 +0200
                              Re: debian/watch file for OpenJDK (was Re: Debian distributions of  stable OpenJDK updates) Tiago Daitx <tiago.daitx@canonical.com> - 2019-05-29 04:20 +0200
                              Re: debian/watch file for OpenJDK (was Re: Debian distributions of  stable OpenJDK updates) Thorsten Glaser <t.glaser@tarent.de> - 2019-05-29 14:20 +0200
                              Re: debian/watch file for OpenJDK (was Re: Debian distributions of  stable OpenJDK updates) Dalibor Topic <dalibor.topic@oracle.com> - 2019-05-29 16:00 +0200
                    Re: Debian distributions of stable OpenJDK updates Emmanuel Bourg <ebourg@apache.org> - 2019-05-30 00:00 +0200
                      Re: Debian distributions of stable OpenJDK updates Thorsten Glaser <t.glaser@tarent.de> - 2019-05-30 00:30 +0200
                      Re: Debian distributions of stable OpenJDK updates Matthias Klose <doko@debian.org> - 2019-06-10 11:40 +0200
                  Re: Debian distributions of stable OpenJDK updates Martijn Verburg <martijnverburg@gmail.com> - 2019-05-27 12:30 +0200

Page 1 of 2  [1] 2  Next page →

#11203 — Re: Debian distributions of stable OpenJDK updates

Hi Aleksey,

Le 20/05/2019 à 10:48, Aleksey Shipilev a écrit :

> Is there a plan to put the latest stable binaries for openjdk-8 and openjdk-11 out? I am looking at
> this page:
>   https://qa.debian.org/developer.php?email=openjdk%40lists.launchpad.net
> 
> 11.0.3+1 is the old pre-release, the GA is jdk-11.0.3+7 / jdk-11.0.3-ga:
>   http://hg.openjdk.java.net/jdk-updates/jdk11u/tags

I can only comment on the OpenJDK 11 backport in Stretch since I'm the
one who uploaded it last month. Debian 9 "Stretch" is far from being
usable with Java 11 (we poured a lot of work into Debian 10 to make this
possible) and this backport can only be reasonably seen as a technology
preview aimed at gathering feedback.

I intend to update it to a more recent version, but by policy the
packages backported to the stable release cannot have a more recent
version than the one in the testing repository (the packages staged for
the next stable release). So as soon as an updated version transitions
to testing (11.0.3+1 currently as you pointed out) I'll upload a new
backport.


> Both GAs were released a month ago, and it is surprising for users to have pre-release binaries
> instead of GA binaries at this point. Separately, it feels tad dubious to put out the pre-release
> binaries into "stable", IMO, but that is a separate longer-term discussion.

I agree that we should preferably only upload the GA tags (or newers if
there are fixes worth picking) to avoid diverging too much with the
upstream releases.

Emmanuel Bourg

[toc] | [next] | [standalone]

#11204

Le 20/05/2019 à 13:54, Aleksey Shipilev a écrit :

> Right. Maybe then "-ea" or "-preview" in version tag would communicate that intent more clearly, on
> the off-chance "stretch" users would install openjdk-11, thinking it is somehow stable.

Do you think the 11.0.3+1 package in stretch is affected by serious
issues compared to the GA release that should be addressed quickly?


> Excellent, do you have any rough ETA? Having 11.0.4+x in "unstable" (preferably with "-ea" suffix)
> and 11.0.3+7 in "testing"/"stable" would be the good state for the current moment.

That may happen later this week if no other update is uploaded in
unstable and the release team approves the transition (that's a big "if"
because testing is currently in deep freeze, and the previous minor
update 11.0.2 broke a ton of packages due to javadoc changes). A likely
outcome is that Debian 10 gets released with OpenJDK 11.0.3+1 and
receives a 11.0.4 update after the release.


> Yup, would be nice if outlier like the current one does not happen again. I think you can always
> check with upstream 8u/11u maintainers if the tags you're building from are sane for "stable",
> especially if you cannot see the -ga tags in the upstream repo.

I've just noticed the new *-ga tags added recently to the OpenJDK 8/11
repositories, that's a very welcome change. That will allow us to write
debian/watch files detecting the release tags.

Emmanuel Bourg

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

#11205

Le 20/05/2019 à 14:38, Aleksey Shipilev a écrit :

> Yes. Security fixes and Japanese epoch changes are delivered in 11.0.3+7, after security embargo was
> lifted. The fixes are not in 11.0.3+6, which was tagged before the embargo lifted. You are looking
> for these:
>   http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/175eb80c253a
>   http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/2996b4523925
>   http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/f0d8b845de21
>   http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/1084d119236b
>   http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/c61b8801f0e4
>   http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/59610bddd37a

Thank you. As I understand the rev 1084d119236b is the fix for
CVE-2019-2684, and 59610bddd37a is the fix for CVE-2019-2602. But I'm
not sure about c61b8801f0e4, is there a related CVE?

Emmanuel Bourg

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

#11206

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

On Mon, May 20, 2019 at 03:15:13PM +0200, Aleksey Shipilev wrote:
> On 5/20/19 3:08 PM, Emmanuel Bourg wrote:
> > Le 20/05/2019 à 14:38, Aleksey Shipilev a écrit :
> > 
> >> Yes. Security fixes and Japanese epoch changes are delivered in 11.0.3+7, after security embargo was
> >> lifted. The fixes are not in 11.0.3+6, which was tagged before the embargo lifted. You are looking
> >> for these:
> >>   http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/175eb80c253a
> >>   http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/2996b4523925
> >>   http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/f0d8b845de21
> >>   http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/1084d119236b
> >>   http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/c61b8801f0e4
> >>   http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/59610bddd37a
> > 
> > Thank you. As I understand the rev 1084d119236b is the fix for
> > CVE-2019-2684, and 59610bddd37a is the fix for CVE-2019-2602. But I'm
> > not sure about c61b8801f0e4, is there a related CVE?
> 
> I don't think there is, but I am not the authoritative source on this. I just listed the differences
> between +6 and +7 (which came from the security-related repo after the fork for release).
> 
> See more here:
>   https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000951.html
>   https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-April/009115.html
> 
> -Aleksey
> 

Hello Aleksey,

Thank you for posting this to the list.  Reconciling the Debian version
numbers with those found in AdoptOpenJDK has been a recent topic of
discussion with several of my coworkers and so I was preparing to bring
up the issue here as well, but you beat me to it.

For reference for the list, the upstream tags can be seen here:

  http://hg.openjdk.java.net/jdk-updates/jdk11u/tags

So 11.0.3+7 == 11.0.3-ga.

For stable backports and buster, I agree that we should upload an
11.0.3-ga package, particularly given the vulnerabilities still present
in 11.0.3+1: CVE-2019-2698, CVE-2019-2684, and CVE-2019-2602

  https://security-tracker.debian.org/tracker/source-package/openjdk-11

It would be nice to do the same for buster, although now that 11.0.4+x
has been introduced to unstable, I believe we'll have to be creative
with the naming, either by introducing an epoch or using the
"11.0.4+1_really11.0.3-ga" trick.

In general, I think it would be helpful for our users if we uploaded the
prereleases to experimental but stuck to GA releases for unstable,
testing, and backports.  I think it is easy to mistake, for example, an
11.0.3+x (prerelease) version in Debian with the 11.0.3 GA release being
distributed by other projects.

Matthias, since you've been handling all of the recent uploads, do you
have specific thoughts or concerns about an upload of 11.0.3-ga?

Thank you,
tony

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

#11207

Le 22/05/2019 à 06:17, tony mancill a écrit :

> For stable backports and buster, I agree that we should upload an
> 11.0.3-ga package, particularly given the vulnerabilities still present
> in 11.0.3+1: CVE-2019-2698, CVE-2019-2684, and CVE-2019-2602

I've uploaded 11.0.3+1 with a patch bringing it up to 11.0.3+7 to
stretch-backports yesterday, it's still pending validation.


> It would be nice to do the same for buster, although now that 11.0.4+x
> has been introduced to unstable, I believe we'll have to be creative
> with the naming, either by introducing an epoch or using the
> "11.0.4+1_really11.0.3-ga" trick.

I think we should leave 11.0.4 in unstable until the GA release in July
and upload 11.0.3+7-4 directly to testing through
testing-proposed-updates. I'm volunteering to deal with this upload if
Matthias agrees.


> In general, I think it would be helpful for our users if we uploaded the
> prereleases to experimental but stuck to GA releases for unstable,
> testing, and backports.  I think it is easy to mistake, for example, an
> 11.0.3+x (prerelease) version in Debian with the 11.0.3 GA release being
> distributed by other projects.

It looks like upstream is going to append a -ea suffix to the version
reported by the pre-releases [1]. This is a welcome clarification and we
should ensure our builds do it as well.

Emmanuel Bourg

[1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-May/009369.html

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

#11208

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

On Wed, May 22, 2019 at 12:24:03PM +0200, Emmanuel Bourg wrote:
> Le 22/05/2019 à 06:17, tony mancill a écrit :
> 
> > For stable backports and buster, I agree that we should upload an
> > 11.0.3-ga package, particularly given the vulnerabilities still present
> > in 11.0.3+1: CVE-2019-2698, CVE-2019-2684, and CVE-2019-2602
> 
> I've uploaded 11.0.3+1 with a patch bringing it up to 11.0.3+7 to
> stretch-backports yesterday, it's still pending validation.
> 
> 
> > It would be nice to do the same for buster, although now that 11.0.4+x
> > has been introduced to unstable, I believe we'll have to be creative
> > with the naming, either by introducing an epoch or using the
> > "11.0.4+1_really11.0.3-ga" trick.
> 
> I think we should leave 11.0.4 in unstable until the GA release in July
> and upload 11.0.3+7-4 directly to testing through
> testing-proposed-updates. I'm volunteering to deal with this upload if
> Matthias agrees.

Ah, that's great if we can upload 11.0.3+7 without having to play
any games with the version string.  Also, I should have said explicitly
that I'm also volunteering to help with uploads - both this version and
going forward.

> > In general, I think it would be helpful for our users if we uploaded the
> > prereleases to experimental but stuck to GA releases for unstable,
> > testing, and backports.  I think it is easy to mistake, for example, an
> > 11.0.3+x (prerelease) version in Debian with the 11.0.3 GA release being
> > distributed by other projects.
> 
> It looks like upstream is going to append a -ea suffix to the version
> reported by the pre-releases [1]. This is a welcome clarification and we
> should ensure our builds do it as well.
> 
> [1] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-May/009369.html
 
Excellent!  Let's see if Matthias has any concerns.

Cheers,
tony

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

#11221

On 22.05.19 12:24, Emmanuel Bourg wrote:
> Le 22/05/2019 à 06:17, tony mancill a écrit :
> 
>> For stable backports and buster, I agree that we should upload an
>> 11.0.3-ga package, particularly given the vulnerabilities still present
>> in 11.0.3+1: CVE-2019-2698, CVE-2019-2684, and CVE-2019-2602
> 
> I've uploaded 11.0.3+1 with a patch bringing it up to 11.0.3+7 to
> stretch-backports yesterday, it's still pending validation.
> 
> 
>> It would be nice to do the same for buster, although now that 11.0.4+x
>> has been introduced to unstable, I believe we'll have to be creative
>> with the naming, either by introducing an epoch or using the
>> "11.0.4+1_really11.0.3-ga" trick.
> 
> I think we should leave 11.0.4 in unstable until the GA release in July
> and upload 11.0.3+7-4 directly to testing through
> testing-proposed-updates. I'm volunteering to deal with this upload if
> Matthias agrees.

well, I disagree ;)  The Debian security team has the policy to take any OpenJDK
update and backport that to stable release.   From my point of view, the Debian
release team is playing games with both the security team, and the OpenJDK
packagers to force something else, although it's unknown to me what they really
want to achieve, if further backports land in stable-security anyway.

>> In general, I think it would be helpful for our users if we uploaded the
>> prereleases to experimental but stuck to GA releases for unstable,
>> testing, and backports.  I think it is easy to mistake, for example, an
>> 11.0.3+x (prerelease) version in Debian with the 11.0.3 GA release being
>> distributed by other projects.

I would like to avoid experimental, because it really doesn't get much testing.
 See the openjdk-11 updates as a stable release branch, and it's worth to check
these out early, because upstream doesn't test most Debian architectures.

> It looks like upstream is going to append a -ea suffix to the version
> reported by the pre-releases [1]. This is a welcome clarification and we
> should ensure our builds do it as well.

no, at least not for the recent release:
https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000951.html

Matthias

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

#11223

Le 26/05/2019 à 21:52, Matthias Klose a écrit :

>> It looks like upstream is going to append a -ea suffix to the version
>> reported by the pre-releases [1]. This is a welcome clarification and we
>> should ensure our builds do it as well.
> 
> no, at least not for the recent release:
> https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000951.html

Well, my comment was based on this post:

  https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-May/009370.html

If I understand well, non GA releases will be reported with a -ea suffix
when typing "java -version" (at least for OpenJDK 8, I haven't checked
for OpenJDK 11). If upstream does this, so should we, otherwise we'll be
blamed for falsifying the version reported.

Emmanuel Bourg

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

#11233

On 26.05.19 23:55, Emmanuel Bourg wrote:
> Le 26/05/2019 à 21:52, Matthias Klose a écrit :
> 
>>> It looks like upstream is going to append a -ea suffix to the version
>>> reported by the pre-releases [1]. This is a welcome clarification and we
>>> should ensure our builds do it as well.
>>
>> no, at least not for the recent release:
>> https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000951.html
> 
> Well, my comment was based on this post:
> 
>   https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-May/009370.html
> 
> If I understand well, non GA releases will be reported with a -ea suffix
> when typing "java -version" (at least for OpenJDK 8, I haven't checked
> for OpenJDK 11). If upstream does this, so should we, otherwise we'll be
> blamed for falsifying the version reported.

no, this is unfortunately a configure option, not a property of the source
tarball.  But yes, will add that until upstream hopefully fixes this.

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

#11241

On Sun, 26 May 2019, Matthias Klose wrote:

> >> In general, I think it would be helpful for our users if we uploaded the
> >> prereleases to experimental but stuck to GA releases for unstable,
> >> testing, and backports.  I think it is easy to mistake, for example, an
> >> 11.0.3+x (prerelease) version in Debian with the 11.0.3 GA release being

It would help if prereleases did not use the ‘+’ character.

Perhaps an upstream mangling in debian/watch to replace it with ‘~pre’
or ‘~ea’ or so might help?

> >> distributed by other projects.
>
> I would like to avoid experimental, because it really doesn't get much testing.

What about using unstable/testing/stable-backports for preleases until
the soft (not hard, so we have some time) freeze, then tracking only
releases, so a frozen testing, stable-backports during time of the
freeze, stable and oldstable-backports have releases only?

>  See the openjdk-11 updates as a stable release branch, and it's worth to check

That’s a good argument against the previous paragraph, and it matches
what I wrote earlier in the other thread:

| 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

To me, this makes just as much sense.

Perhaps, shipping upstream prereleases really isn’t a problem
(trust the content, not the label), but labelling them clearly
(see the above comment about an upstream mangling rule in the
watch file) might please all but the weirdest (that Azul guy)
people; after all, if it’s really a fix-only branch, it’s in
the interest of our users to get the fixes out fast without
waiting for an upstream release (possibly).

> these out early, because upstream doesn't test most Debian architectures.

And that’s a good argument in favour of packaging them up for
unstable and testing them there, widely (especially as some of
the ports architectures’ buildds don’t often get around to
building experimental).

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]

#11209

Le 20/05/2019 à 14:38, Aleksey Shipilev a écrit :

> Yes. Security fixes and Japanese epoch changes are delivered in 11.0.3+7, after security embargo was
> lifted. The fixes are not in 11.0.3+6, which was tagged before the embargo lifted. You are looking
> for these:
>   http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/175eb80c253a
>   http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/2996b4523925
>   http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/f0d8b845de21
>   http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/1084d119236b
>   http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/c61b8801f0e4
>   http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/59610bddd37a
> 
> So yes, I would say the update should be high priority.

OpenJDK 11.0.3 GA is now available in stretch-backports for amd64, the
other architectures are still building [1] and will follow soon.

Since I couldn't upload 11.0.3+7 directly I've uploaded 11.0.3+1 with a
patch containing the changes up to 11.0.3+7 (the patch is only ~1000
lines long, so it's still reasonable). The version of the package could
be misleading since it's still 11.0.3+1, but I've taken care to ensure
that "java -version" reports 11.0.3+7.

Disclaimer: this backport remains a technology preview for Debian 9
"Stretch", I'll do my best to maintain it but I can't guarantee any ETA
on the updates (co-maintainers would be welcome). Anyone serious about
using OpenJDK 11 in production should switch to Debian 10 "Buster" when
it's released. OpenJDK 11 in Buster will be tracked by the Security Team
and is guaranteed to work with the Java applications and libraries
packaged in Debian.

Emmanuel Bourg

[1]
https://buildd.debian.org/status/package.php?p=openjdk-11&suite=stretch-backports

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

#11210

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

Thanks for following up on this!!

What was the difficulty in grabbing the 11.0.3+7 tag directly?

On Thu, 23 May 2019 at 17:50, Emmanuel Bourg <ebourg@apache.org> wrote:

> Le 20/05/2019 à 14:38, Aleksey Shipilev a écrit :
>
> > Yes. Security fixes and Japanese epoch changes are delivered in
> 11.0.3+7, after security embargo was
> > lifted. The fixes are not in 11.0.3+6, which was tagged before the
> embargo lifted. You are looking
> > for these:
> >   http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/175eb80c253a
> >   http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/2996b4523925
> >   http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/f0d8b845de21
> >   http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/1084d119236b
> >   http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/c61b8801f0e4
> >   http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/59610bddd37a
> >
> > So yes, I would say the update should be high priority.
>
> OpenJDK 11.0.3 GA is now available in stretch-backports for amd64, the
> other architectures are still building [1] and will follow soon.
>
> Since I couldn't upload 11.0.3+7 directly I've uploaded 11.0.3+1 with a
> patch containing the changes up to 11.0.3+7 (the patch is only ~1000
> lines long, so it's still reasonable). The version of the package could
> be misleading since it's still 11.0.3+1, but I've taken care to ensure
> that "java -version" reports 11.0.3+7.
>
> Disclaimer: this backport remains a technology preview for Debian 9
> "Stretch", I'll do my best to maintain it but I can't guarantee any ETA
> on the updates (co-maintainers would be welcome). Anyone serious about
> using OpenJDK 11 in production should switch to Debian 10 "Buster" when
> it's released. OpenJDK 11 in Buster will be tracked by the Security Team
> and is guaranteed to work with the Java applications and libraries
> packaged in Debian.
>
> Emmanuel Bourg
>
> [1]
>
> https://buildd.debian.org/status/package.php?p=openjdk-11&suite=stretch-backports
>
> --
Cheers, Martijn (Sent from Gmail Mobile)

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

#11211

Le 23/05/2019 à 19:04, Martijn Verburg a écrit :

> What was the difficulty in grabbing the 11.0.3+7 tag directly?

The difficulty is the policy that applies to backported packages. A
package that is backported from the Debian release n+1 to the release n
has to remain upgradable when the system is upgraded. For this to happen
the version backported must rank lower than the version in the next
release. That's why there are weird suffixes appended to the versions of
the backported packages (1.2.3-1~bpo9+1 is lower than 1.2.3-1).

Currently Debian Buster has openjdk-11/11.0.3+1-1, so it isn't possible
to upload the version 11.0.3+7-1~bpo9+1 to stretch-backports. The only
solutions is to either upgrade openjdk-11 in testing to a version higher
than 11.0.3+7, or patch the existing version. Since testing is currently
frozen and difficult to update until the release of Buster, it leaves
only the patch solution.

Emmanuel Bourg

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

#11212

On Thu, 23 May 2019, Emmanuel Bourg wrote:

> than 11.0.3+7, or patch the existing version. Since testing is currently
> frozen and difficult to update until the release of Buster, it leaves
> only the patch solution.

That being said, it’s also not permitted to add in a patch anything
to a backport that’s not in the base (n+1) version, except things
necessary to do the backporting itself.

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

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

#11217

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

On Fri, May 24, 2019 at 12:45:15AM +0200, Thorsten Glaser wrote:
> On Thu, 23 May 2019, Emmanuel Bourg wrote:
> 
> > than 11.0.3+7, or patch the existing version. Since testing is currently
> > frozen and difficult to update until the release of Buster, it leaves
> > only the patch solution.
> 
> That being said, it’s also not permitted to add in a patch anything
> to a backport that’s not in the base (n+1) version, except things
> necessary to do the backporting itself.

Emmanuel,

I see that openjdk-11 11.0.3+1-1~bpo9+2 has been accepted in stable
backports [1], so the (smallish) patch to bring the code up to the
+7/-ga tag was deemed allowable after all.  Thank you for driving this
for stable.

I think it is important to get a "-ga" versioned package into Buster
because 11.0.3+1 is potentially confusing - it seems like it's version
*after* 11.0.3, when in fact it's an EA release.  According to the
developer's reference for t-p-u [2], this case meets all of the
criteria.  And once that version is Buster, we can also update the
version number in stable backports.

Can folks think of any reasons why we shouldn't go ahead and upload to
testing-proposed-updates for Buster?  If there are any concerns, please
speak up.  Otherwise, I'll work on an upload this weekend.

Thanks,
tony

[1] https://tracker.debian.org/news/1040268/accepted-openjdk-11-11031-1bpo92-source-amd64-all-into-stretch-backports-backports-policy-stretch-backports/
[2] https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#t-p-u

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

#11235

Le 25/05/2019 à 18:07, tony mancill a écrit :

> Can folks think of any reasons why we shouldn't go ahead and upload to
> testing-proposed-updates for Buster?  If there are any concerns, please
> speak up.  Otherwise, I'll work on an upload this weekend.

It looks like openjdk-11 wasn't unblocked due to #926009 and the fear
this issue could affect other applications. This is being discussed in
#928185.

Emmanuel Bourg

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

#11240

On Sat, 25 May 2019, tony mancill wrote:

> backports [1], so the (smallish) patch to bring the code up to the
> +7/-ga tag was deemed allowable after all.  Thank you for driving this

More likely it was just not manually reviewed.

Please don’t do this again but only upload to backports
what’s in the subsequent release. Backports users know
what they’ll be getting and that testing can be less
stable than, well, stable.

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]

#11248

Le 27/05/2019 à 18:34, Thorsten Glaser a écrit :

>> backports [1], so the (smallish) patch to bring the code up to the
>> +7/-ga tag was deemed allowable after all.  Thank you for driving this
> 
> More likely it was just not manually reviewed.
> 
> Please don’t do this again but only upload to backports
> what’s in the subsequent release. Backports users know
> what they’ll be getting and that testing can be less
> stable than, well, stable.

Sorry but I'll do it again if it's necessary to fix overdue security
issues during a hard freeze. The diff was reasonably small, mostly
focused on the security fixes, and the changes were documented in the
changelog. I didn't try to sneak a major update in stretch-backports
with an unreviewable 50K lines patch. So I don't think I deserve to be
lectured for a necessary upload that indisputably benefits our users.

Emmanuel Bourg

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

#11262

On Tue, 28 May 2019, Emmanuel Bourg wrote:

> Sorry but I'll do it again if it's necessary to fix overdue security
> issues during a hard freeze.

If you just upload the patch to t-p-u first, then backport
the package you uploaded to t-p-u, it’ll be fine.

> lectured for a necessary upload that indisputably benefits our users.

Uploads against backports policy can have the responsible
DD’s backports upload permissions revoked, which is why
I’m warning.

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]

#11265

Le 29/05/2019 à 14:15, Thorsten Glaser a écrit :

> If you just upload the patch to t-p-u first, then backport
> the package you uploaded to t-p-u, it’ll be fine.

This process is too long for a security update.


> Uploads against backports policy can have the responsible
> DD’s backports upload permissions revoked, which is why
> I’m warning.

I admire your strict and blind respect of the rules, but sometimes an
ounce of pragmatism is useful.

Emmanuel Bourg

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web