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 2 of 2 — ← Prev page 1 [2]

#11213

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

On Thu, May 23, 2019 at 11:58:14PM +0200, Emmanuel Bourg wrote:
> 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,

It seems like we need to bring this up with the Release and Security
teams.  Releasing Buster with mulitple critical open CVEs in the JVM
isn't a good experience for our users.  My proposal is that we do what
we need to get 11.0.3-ga-1 into Buster.

From a versioning standpoint, this should work.  Am I missing something?

$ dpkg --compare-versions 11.0.3-ga-1 gt 11.0.3+7-1 && echo "11.0.3-ga-1 is newer"
11.0.3-ga-1 is newer

Thanks,
tony

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

#11214

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

On Fri, 24 May 2019 at 15:40, tony mancill <tmancill@debian.org> wrote:

> On Thu, May 23, 2019 at 11:58:14PM +0200, Emmanuel Bourg wrote:
> > 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,
>
> It seems like we need to bring this up with the Release and Security
> teams.  Releasing Buster with mulitple critical open CVEs in the JVM
> isn't a good experience for our users.  My proposal is that we do what
> we need to get 11.0.3-ga-1 into Buster.
>
> From a versioning standpoint, this should work.  Am I missing something?
>
> $ dpkg --compare-versions 11.0.3-ga-1 gt 11.0.3+7-1 && echo "11.0.3-ga-1
> is newer"
> 11.0.3-ga-1 is newer
>

We (AdoptOpenJDK) would really be appreciative of that! We're aiming to get
consistency amongst all of the OpenJDK providers that 'good known GA'
versions are deployed to end users.  I can only apologise for not having
reached out to the Debian community earlier to collaborate.  Appreciate the
efforts being put in here!

Is there anything we can do to help going forward?  OpenJDK upstream has a
pretty good established policy around having the `-ga` suffix added to
versions it would like downstream to take as a formal release.  Is there
anything else that OpenJDK can do to help Debian?  One thing that
AdoptOpenJDK provides is a free test pipeline in it's build farm that could
happily receive the Debian built binary and put it through 100,000+ tests
and see if it matches what other OpenJDK providers are broadly producing,
would that be of interest?

Cheers,
Martijn


>
> Thanks,
> tony
>

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

#11220

On 24.05.19 20:29, Martijn Verburg wrote:
> On Fri, 24 May 2019 at 15:40, tony mancill <tmancill@debian.org> wrote:
> 
>> On Thu, May 23, 2019 at 11:58:14PM +0200, Emmanuel Bourg wrote:
>>> 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,
>>
>> It seems like we need to bring this up with the Release and Security
>> teams.  Releasing Buster with mulitple critical open CVEs in the JVM
>> isn't a good experience for our users.  My proposal is that we do what
>> we need to get 11.0.3-ga-1 into Buster.
>>
>> From a versioning standpoint, this should work.  Am I missing something?
>>
>> $ dpkg --compare-versions 11.0.3-ga-1 gt 11.0.3+7-1 && echo "11.0.3-ga-1
>> is newer"
>> 11.0.3-ga-1 is newer

I don't think that playing games with version numbers is a good thing to do.
Version numbers should match the upstream source release, and the binary
packages should not change that version.  Of course openjdk has a split
personality to give even another version when called with java --version

The final 11.0.3 release:
https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000951.html

does *not* contain the ea specifier.

> We (AdoptOpenJDK) would really be appreciative of that! We're aiming to get
> consistency amongst all of the OpenJDK providers that 'good known GA'
> versions are deployed to end users.  I can only apologise for not having
> reached out to the Debian community earlier to collaborate.  Appreciate the
> efforts being put in here!

I don't care what AdoptJdk is doing.  In the past, the only activity by AdoptJdk
was trying to promote their builds for inclusion in some Linux distros.
AdoptJdk only supports a subset of the Debian architectures, and we really don't
need yet another IcedTea.

> Is there anything we can do to help going forward?  OpenJDK upstream has a
> pretty good established policy around having the `-ga` suffix added to
> versions it would like downstream to take as a formal release. 

This is a recent addition. Last time I asked on an upstream mailing list,
everybody seemed fine with the versioning:
https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000969.html

> Is there
> anything else that OpenJDK can do to help Debian?  One thing that
> AdoptOpenJDK provides is a free test pipeline in it's build farm that could
> happily receive the Debian built binary and put it through 100,000+ tests
> and see if it matches what other OpenJDK providers are broadly producing,
> would that be of interest?

I'm moving that discussion to upstream, but in summary you shouldn't a dozen of
configure options to configure your build from source.  Just release a sane
upstream tarball.

Matthias

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

#11224

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

On Sun, May 26, 2019 at 09:47:13PM +0200, Matthias Klose wrote:
> On 24.05.19 20:29, Martijn Verburg wrote:
> > On Fri, 24 May 2019 at 15:40, tony mancill <tmancill@debian.org> wrote:
> > 
> >> On Thu, May 23, 2019 at 11:58:14PM +0200, Emmanuel Bourg wrote:
> >>> 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,
> >>
> >> It seems like we need to bring this up with the Release and Security
> >> teams.  Releasing Buster with mulitple critical open CVEs in the JVM
> >> isn't a good experience for our users.  My proposal is that we do what
> >> we need to get 11.0.3-ga-1 into Buster.
> >>
> >> From a versioning standpoint, this should work.  Am I missing something?
> >>
> >> $ dpkg --compare-versions 11.0.3-ga-1 gt 11.0.3+7-1 && echo "11.0.3-ga-1
> >> is newer"
> >> 11.0.3-ga-1 is newer
> 
> I don't think that playing games with version numbers is a good thing to do.
> Version numbers should match the upstream source release, and the binary
> packages should not change that version.  Of course openjdk has a split
> personality to give even another version when called with java --version
> 
> The final 11.0.3 release:
> https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000951.html
> 
> does *not* contain the ea specifier.

Hi Matthias,

Thank you for weighing in on the thread.  I have been building openjdk
packages all weekend and now understand that the version number is
required to be numeric as per the upstream build system - i.e.,
VERSION_BUILD won't pass the test here [1] if it is arbitrarily changed
from from 7 to ga.  So 11.0.3+7 it is.  My bad for proposing otherwise
in this thread, before I got more familiar with the build system...

For the update to buster via testing-proposed-updates, I have prepared
11.0.3+7-4+deb10u1, which is simply your 11.0.3+7-4 package [2] targeted
at buster via t-p-u and with the changelog updated to note that 11.0.3+7
is the GA release from OpenJDK.  This will address the CVEs currently
open against the version in buster.

Does that sound acceptable for upload to Debian?  Would you prefer a
different approach?

Thank you,
tony

[1] http://hg.openjdk.java.net/jdk-updates/jdk11u/file/175eb80c253a/make/autoconf/jdk-version.m4#l40 
[2] https://tracker.debian.org/news/1038802/accepted-openjdk-11-11037-4-source-into-unstable/

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

#11234

On 26.05.19 23:51, tony mancill wrote:
> Thank you for weighing in on the thread.  I have been building openjdk
> packages all weekend and now understand that the version number is
> required to be numeric as per the upstream build system - i.e.,
> VERSION_BUILD won't pass the test here [1] if it is arbitrarily changed
> from from 7 to ga.  So 11.0.3+7 it is.  My bad for proposing otherwise
> in this thread, before I got more familiar with the build system...
> 
> For the update to buster via testing-proposed-updates, I have prepared
> 11.0.3+7-4+deb10u1, which is simply your 11.0.3+7-4 package [2] targeted
> at buster via t-p-u and with the changelog updated to note that 11.0.3+7
> is the GA release from OpenJDK.  This will address the CVEs currently
> open against the version in buster.
> 
> Does that sound acceptable for upload to Debian?  Would you prefer a
> different approach?

Please coordinate with Moritz, as he is doing the security updates. Either
testing-proposed-updates or testing-security is ok.

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

#11239

On Fri, 24 May 2019, Martijn Verburg wrote:

> Is there anything we can do to help going forward?

An uscan (watch file)-compatible webpage where new formal releases for
all versions are announced, that is consistent, and whose URL doesn’t
change, would be appreciated, as someone already said in the other
thread.

>One thing that
> AdoptOpenJDK provides is a free test pipeline in it's build farm that could
> happily receive the Debian built binary and put it through 100,000+ tests
> and see if it matches what other OpenJDK providers are broadly producing,
> would that be of interest?

Not speaking authoritatively, but I’d think this could be a good thing,
as long as this would not mean that Debian is forced to produce results
100% identical to others (as some deviations e.g. from backporting some
security patches can be expected), but it’d be good to know them, and
perhaps fix those that are not deliberate. (But I’ll leave it to doko
or tony or so to speak authoritatively, also on what to test, since
there are multiple releases, backports sometimes from prereleases of
testing, sometimes from stable releases/stable-security…)

However, mind that Debian runs on more architectures than just x86/ARM:

https://buildd.debian.org/status/package.php?p=openjdk-11

Consistency inside Debian but across those architectures is also
important (also with the Zero VM, since Hotspot only exists for
a minority of architectures).


On Sun, 26 May 2019, tony mancill wrote:

> For the update to buster via testing-proposed-updates, I have prepared
> 11.0.3+7-4+deb10u1, which is simply your 11.0.3+7-4 package [2] targeted
> at buster via t-p-u and with the changelog updated to note that 11.0.3+7
> is the GA release from OpenJDK.  This will address the CVEs currently
> open against the version in buster.

Why was 11.0.4+2-1 uploaded to sid during the freeze anyway, if it was
not intended for buster?

That is the question I personally would like to be answered.

It does leave the way for t-p-u, sure… and that’s the way to go now,
but this could have been avoided.

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]

#11247 — debian/watch file for OpenJDK (was Re: Debian distributions of stable OpenJDK updates)

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

>> Is there anything we can do to help going forward?
> 
> An uscan (watch file)-compatible webpage where new formal releases for
> all versions are announced, that is consistent, and whose URL doesn’t
> change, would be appreciated, as someone already said in the other
> thread.

+1, this is indeed an issue.

There is the Mercurial tags page [1] but unlike GitHub's tags pages it
doesn't play nice with uscan because the links are built with the hash
of the revision and not the value of the tag.

There is the AdoptOpenJDK Git mirror hosted on GitHub [2], but the tags
don't seem to match with upstream (no *-ga tags yet).

And there is the Oracle download page [3] which gives with some grepping
the actual release tag, but this is no longer a usable source since the
Oracle branch is now private (The current Oracle's tag for Java 11.0.3
is 11.0.3+12, this is not the OpenJDK 11.0.3 GA tag and it doesn't even
exist in the OpenJDK repository).

So far I used to parse the Oracle website in a PHP page [4] and output
uscan compatible links. But once the Oracle branch goes private it's no
longer usable.

So yes, an official release page would be really nice. Such a page would
have to contain uscan friendly links to the source tarballs of the
latest releases. For example:

  <a
href="https://hg.openjdk.java.net/jdk-updates/jdk11u/archive/jdk-11.0.3+7.tar.gz">OpenJDK
11.0.3</a>

Emmanuel Bourg

[1] http://hg.openjdk.java.net/jdk-updates/jdk11u/tags
[2] https://github.com/AdoptOpenJDK/openjdk-jdk11u/tags
[3]
https://www.oracle.com/technetwork/java/javase/downloads/jdk11-downloads-5066655.html
[4] http://java.debian.net/checkjdk.php

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

#11251 — Re: debian/watch file for OpenJDK (was Re: Debian distributions of stable OpenJDK updates)

On Tue, May 28, 2019 at 4:22 PM Emmanuel Bourg wrote:

> There is the Mercurial tags page [1] but unlike GitHub's tags pages it
> doesn't play nice with uscan because the links are built with the hash
> of the revision and not the value of the tag.

FTR, uscan is now flexible enough that it can apply arbitrary
transformations to the HTML and download URL so it is easy enough to
create a watch file that works:

version=4
opts="pagemangle=s{<a
href=\"/jdk-updates/jdk11u/rev/[^\"]*\">\s*(jdk-11\.[^<\s]*)}{<a
href=\"archive/$1.tar.gz">$1}g" \
https://hg.openjdk.java.net/jdk-updates/jdk11u/tags \
.*/jdk-(.*).tar.gz

$ uscan --watchfile watch --package openjdk --upstream-version 0
uscan: Newest version of openjdk on remote site is 11.0.4+4, local version is 0
uscan:    => Newer package available from
      https://hg.openjdk.java.net/jdk-updates/jdk11u/archive/jdk-11.0.4+4.tar.gz

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

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

#11252 — Re: debian/watch file for OpenJDK (was Re: Debian distributions of stable OpenJDK updates)

Le 28/05/2019 à 11:11, Paul Wise a écrit :

> FTR, uscan is now flexible enough that it can apply arbitrary
> transformations to the HTML and download URL so it is easy enough to
> create a watch file that works:
> 
> version=4
> opts="pagemangle=s{<a
> href=\"/jdk-updates/jdk11u/rev/[^\"]*\">\s*(jdk-11\.[^<\s]*)}{<a
> href=\"archive/$1.tar.gz">$1}g" \
> https://hg.openjdk.java.net/jdk-updates/jdk11u/tags \
> .*/jdk-(.*).tar.gz
> 
> $ uscan --watchfile watch --package openjdk --upstream-version 0
> uscan: Newest version of openjdk on remote site is 11.0.4+4, local version is 0
> uscan:    => Newer package available from
>       https://hg.openjdk.java.net/jdk-updates/jdk11u/archive/jdk-11.0.4+4.tar.gz

Thank you Paul. After I posted the previous message I dug into the uscan
documentation and found the new pagemangle option.

Here is the watch file I wrote to match the OpenJDK 11 GA releases:

version=4
opts="repack,compression=xz,pagemangle=s%(jdk-.*)%<a
href='http://hg.openjdk.java.net/jdk-updates/jdk11u/archive/$1.tar.gz'>$1</a>%g"
\
http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/tags
.*/archive/jdk-(11\..*)-ga.tar.gz

Emmanuel Bourg

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

#11258 — Re: debian/watch file for OpenJDK (was Re: Debian distributions of stable OpenJDK updates)

On Tue, May 28, 2019 at 6:21 AM Emmanuel Bourg <ebourg@apache.org> wrote:
>
> Le 28/05/2019 à 11:11, Paul Wise a écrit :
>
> > FTR, uscan is now flexible enough that it can apply arbitrary
> > transformations to the HTML and download URL so it is easy enough to
> > create a watch file that works:
> >
> > version=4
> > opts="pagemangle=s{<a
> > href=\"/jdk-updates/jdk11u/rev/[^\"]*\">\s*(jdk-11\.[^<\s]*)}{<a
> > href=\"archive/$1.tar.gz">$1}g" \
> > https://hg.openjdk.java.net/jdk-updates/jdk11u/tags \
> > .*/jdk-(.*).tar.gz
> >
> > $ uscan --watchfile watch --package openjdk --upstream-version 0
> > uscan: Newest version of openjdk on remote site is 11.0.4+4, local version is 0
> > uscan:    => Newer package available from
> >       https://hg.openjdk.java.net/jdk-updates/jdk11u/archive/jdk-11.0.4+4.tar.gz
>
> Thank you Paul. After I posted the previous message I dug into the uscan
> documentation and found the new pagemangle option.
>
> Here is the watch file I wrote to match the OpenJDK 11 GA releases:
>
> version=4
> opts="repack,compression=xz,pagemangle=s%(jdk-.*)%<a
> href='http://hg.openjdk.java.net/jdk-updates/jdk11u/archive/$1.tar.gz'>$1</a>%g"
> \
> http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/tags
> .*/archive/jdk-(11\..*)-ga.tar.gz
>
> Emmanuel Bourg
>

Hi,

Bellow is the watch file that I have been using for openjdk-11 in
Ubuntu which was not copied to Debian. It tracks the upstream tarballs
that RedHat has been generating since they got project leadership for
OpenJDK 11. Kudos to RedHat for such tarballs!

version=4
opts=pgpmode=auto https://openjdk-sources.osci.io/openjdk11/
openjdk@ANY_VERSION@@ARCHIVE_EXT@

They only provide tarballs for official releases, so one would find
only "GA" equivalent tags there. My aim is to use those tarballs to
generate Ubuntu security updates for our openjdk-11 package. I would
appreciate feedback on why this is better or worse than following the
mercurial tags for the official releases. The advantage I see is that
the tarballs are signed and do not need to be repacked, the downside
being that such watch file cannot track "pre"-releases (as that helps
testing the pre-releases) and won't work for openjdk-12 or openjdk-13
as Oracle does no such tarballs releases.

And compared to the "previous" way of updating openjdk-11 (ie. running
"debian/rule get-orig") it won't clear up the tree from some system
libraries - I don't find that to be a problem for builds, in all the
tests I did the libraries don't get used due to the configure flags we
(already) set. Matthias did mention something about the licenses from
those libraries. I tested adding Files-Excluded rules to
debian/copyright, which worked okay-ish: libjavajpeg required manually
listing files as a couple need to be kept, so does not scale that well
when new files get added (somebody will need to notice it and manually
add them to the list).


Emmanuel and Paul,

Great work on getting a watch file that works with the mercurial tags!
I know it is only meant to tracks ga, but with a few tweaks it can be
used to track pre-releases which might help testing those.

Regards,
Tiago

--
Tiago Stürmer Daitx
Software Engineer
tiago.daitx@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE

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

#11259 — Re: debian/watch file for OpenJDK (was Re: Debian distributions of stable OpenJDK updates)

On Tue, May 28, 2019 at 10:59 PM Tiago Daitx <tiago.daitx@canonical.com> wrote:
>
> On Tue, May 28, 2019 at 6:21 AM Emmanuel Bourg <ebourg@apache.org> wrote:
> >
> > Le 28/05/2019 à 11:11, Paul Wise a écrit :
> >
> > > FTR, uscan is now flexible enough that it can apply arbitrary
> > > transformations to the HTML and download URL so it is easy enough to
> > > create a watch file that works:
> > >
> > > version=4
> > > opts="pagemangle=s{<a
> > > href=\"/jdk-updates/jdk11u/rev/[^\"]*\">\s*(jdk-11\.[^<\s]*)}{<a
> > > href=\"archive/$1.tar.gz">$1}g" \
> > > https://hg.openjdk.java.net/jdk-updates/jdk11u/tags \
> > > .*/jdk-(.*).tar.gz
> > >
> > > $ uscan --watchfile watch --package openjdk --upstream-version 0
> > > uscan: Newest version of openjdk on remote site is 11.0.4+4, local version is 0
> > > uscan:    => Newer package available from
> > >       https://hg.openjdk.java.net/jdk-updates/jdk11u/archive/jdk-11.0.4+4.tar.gz
> >
> > Thank you Paul. After I posted the previous message I dug into the uscan
> > documentation and found the new pagemangle option.
> >
> > Here is the watch file I wrote to match the OpenJDK 11 GA releases:
> >
> > version=4
> > opts="repack,compression=xz,pagemangle=s%(jdk-.*)%<a
> > href='http://hg.openjdk.java.net/jdk-updates/jdk11u/archive/$1.tar.gz'>$1</a>%g"
> > \
> > http://hg.openjdk.java.net/jdk-updates/jdk11u-dev/tags
> > .*/archive/jdk-(11\..*)-ga.tar.gz
> >
> > Emmanuel Bourg
> >
>
> Hi,
>
> Bellow is the watch file that I have been using for openjdk-11 in
> Ubuntu which was not copied to Debian. It tracks the upstream tarballs
> that RedHat has been generating since they got project leadership for
> OpenJDK 11. Kudos to RedHat for such tarballs!
>
> version=4
> opts=pgpmode=auto https://openjdk-sources.osci.io/openjdk11/
> openjdk@ANY_VERSION@@ARCHIVE_EXT@
>
> They only provide tarballs for official releases, so one would find
> only "GA" equivalent tags there. My aim is to use those tarballs to
> generate Ubuntu security updates for our openjdk-11 package. I would
> appreciate feedback on why this is better or worse than following the
> mercurial tags for the official releases. The advantage I see is that
> the tarballs are signed and do not need to be repacked, the downside
> being that such watch file cannot track "pre"-releases (as that helps
> testing the pre-releases) and won't work for openjdk-12 or openjdk-13
> as Oracle does no such tarballs releases.
>
> And compared to the "previous" way of updating openjdk-11 (ie. running
> "debian/rule get-orig") it won't clear up the tree from some system
> libraries - I don't find that to be a problem for builds, in all the
> tests I did the libraries don't get used due to the configure flags we
> (already) set. Matthias did mention something about the licenses from
> those libraries. I tested adding Files-Excluded rules to
> debian/copyright, which worked okay-ish: libjavajpeg required manually
> listing files as a couple need to be kept, so does not scale that well
> when new files get added (somebody will need to notice it and manually
> add them to the list).
>
>
> Emmanuel and Paul,
>
> Great work on getting a watch file that works with the mercurial tags!
> I know it is only meant to tracks ga, but with a few tweaks it can be
> used to track pre-releases which might help testing those.
>
> Regards,
> Tiago

Just to be clear: the above discussion was all about openjdk-11.

OpenJDK 8 is another beast and the openjdk-8 package has to track a
lot more repositories: the "root" openjdk repository, corba, 3 hotspot
repositories (1 for the oracle supported archs, 1 for armhf, another
one for arm64), jaxp, jaxws, jdk, langtools, hotspot, nashorn. And the
arm related hotspot repositories usually lag behind the official one
from a few days to a few months (specially aarch32 used for armhf), so
that can delay the release or require hotspot security patches to be
applied on top of the arm hotspot. That makes having a watch file for
it much harder since the OpenJDK 8 tarballs don't include the code for
the arm hotspots. Hopefully the arm repositories will be eventually
merged upstream now that RedHat is leading OpenJDK 8.

That said, sorry to side track the discussion, if anyone wants to
discuss openjdk-8 further I recommend doing that in a separated
thread. ;-)

-- 
Tiago Stürmer Daitx
Software Engineer
tiago.daitx@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE

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

#11261 — Re: debian/watch file for OpenJDK (was Re: Debian distributions of stable OpenJDK updates)

On Tue, 28 May 2019, Tiago Daitx wrote:

> They only provide tarballs for official releases, so one would find

Nice!

> And compared to the "previous" way of updating openjdk-11 (ie. running
> "debian/rule get-orig") it won't clear up the tree from some system
> libraries - I don't find that to be a problem for builds, in all the
> tests I did the libraries don't get used due to the configure flags we

It’s easy enough to get uscan to generate a new origtgz that
excludes them from the download. I recently did so in some
package I inherited where we all *thought* the thirdparty
convenience libraries were not used, only to find that one
of them’s headers was still used, which incidentally was a
licence compatibility issue, too…

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]

#11263 — Re: debian/watch file for OpenJDK (was Re: Debian distributions of stable OpenJDK updates)

On 29.05.2019 03:59, Tiago Daitx wrote:
> On Tue, May 28, 2019 at 6:21 AM Emmanuel Bourg <ebourg@apache.org> wrote:

> mercurial tags for the official releases. The advantage I see is that
> the tarballs are signed and do not need to be repacked, the downside
> being that such watch file cannot track "pre"-releases (as that helps
> testing the pre-releases) and won't work for openjdk-12 or openjdk-13
> as Oracle does no such tarballs releases.

Going to

https://hg.openjdk.java.net/jdk-updates/jdk12u/tags
-> click jdk-12.0.1-ga
-> https://hg.openjdk.java.net/jdk-updates/jdk12u/rev/e831fc6bca9e
-> click bz2
-> 
https://hg.openjdk.java.net/jdk-updates/jdk12u/archive/e831fc6bca9e.tar.bz2

You can also fetch the source code corresponding to the tag using the 
tag directly, i.e.

https://hg.openjdk.java.net/jdk-updates/jdk12u/archive/jdk-12.0.1-ga.tar.bz2

(or tar.gz, etc.)

Hope this helps,
dalibor topic

-- 
Oracle <http://www.oracle.com>
Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | D-22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

Green Oracle <http://www.oracle.com/commitment> Oracle is committed to
developing practices and products that help protect the environment

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

#11264

Le 26/05/2019 à 23:51, tony mancill a écrit :

> For the update to buster via testing-proposed-updates, I have prepared
> 11.0.3+7-4+deb10u1, which is simply your 11.0.3+7-4 package [2] targeted
> at buster via t-p-u and with the changelog updated to note that 11.0.3+7
> is the GA release from OpenJDK.  This will address the CVEs currently
> open against the version in buster.

Is the +deb10u1 suffix necessary for a testing-proposed-updates upload?
Just asking, because if I backport that for stretch that will make a not
very nice 11.0.3+7-4+deb10u1~bpo9-1 version. Would 11.0.3+7-5 work?

Emmanuel Bourg

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

#11266

On Wed, 29 May 2019, Emmanuel Bourg wrote:

> Would 11.0.3+7-5 work?

Sure it would, since the version in sid is already larger than that.

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]

#11269

On 29.05.19 23:51, Emmanuel Bourg wrote:
> Le 26/05/2019 à 23:51, tony mancill a écrit :
> 
>> For the update to buster via testing-proposed-updates, I have prepared
>> 11.0.3+7-4+deb10u1, which is simply your 11.0.3+7-4 package [2] targeted
>> at buster via t-p-u and with the changelog updated to note that 11.0.3+7
>> is the GA release from OpenJDK.  This will address the CVEs currently
>> open against the version in buster.
> 
> Is the +deb10u1 suffix necessary for a testing-proposed-updates upload?
> Just asking, because if I backport that for stretch that will make a not
> very nice 11.0.3+7-4+deb10u1~bpo9-1 version. Would 11.0.3+7-5 work?

Please don't add more confusion to the versioning.  Honestly we should just
migrate the current package in unstable to testing.  We will get the final
11.0.4+x update in a month anyway.

But yes, 11.0.3+7-5 should work as well.

Matthias

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

#11230

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

Hi Matthias.

<snip>

I don't think that playing games with version numbers is a good thing to do.
> Version numbers should match the upstream source release, and the binary
> packages should not change that version.  Of course openjdk has a split
> personality to give even another version when called with java --version
>
> The final 11.0.3 release:
>
> https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000951.html
>
> does *not* contain the ea specifier.
>

That's correct, there currently is no `-ea` labeling, it's something that I
hope upstream
will add.  In the mean time you can assume that if it isn't `ga` then it's
a pre release build


>
> > We (AdoptOpenJDK) would really be appreciative of that! We're aiming to
> get
> > consistency amongst all of the OpenJDK providers that 'good known GA'
> > versions are deployed to end users.  I can only apologise for not having
> > reached out to the Debian community earlier to collaborate.  Appreciate
> the
> > efforts being put in here!
>
> I don't care what AdoptJdk is doing.  In the past, the only activity by
> AdoptJdk
> was trying to promote their builds for inclusion in some Linux distros.
> AdoptJdk only supports a subset of the Debian architectures, and we really
> don't
> need yet another IcedTea.
>

Apologies for not being clear.  AdoptOpenJDK is a community that promotes
OpenJDK, yes we
have our own builds (because there was an x-platform gap that needed
addressing) but our
*purpose* is to help solve issues that folks are having with OpenJDK.

On a side note if there are Debian architectures that we're not building
for then we'd like to
know so we can get coverage for those.  Our build farm is helpful in making
sure the
platform combinations have build and test coverage, we then fix issues
upstream so all
downstream providers get more stable builds (from the source in Debian's
case).


> > Is there anything we can do to help going forward?  OpenJDK upstream has
> a
> > pretty good established policy around having the `-ga` suffix added to
> > versions it would like downstream to take as a formal release.
>
> This is a recent addition. Last time I asked on an upstream mailing list,
> everybody seemed fine with the versioning:
>
> https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000969.html


It is a recent addition yes, I don't think we (the OpenJDK community)
communicated
that well enough.

Cheers,
Martijn


> > Is there
> > anything else that OpenJDK can do to help Debian?  One thing that
> > AdoptOpenJDK provides is a free test pipeline in it's build farm that
> could
> > happily receive the Debian built binary and put it through 100,000+ tests
> > and see if it matches what other OpenJDK providers are broadly producing,
> > would that be of interest?
>
> I'm moving that discussion to upstream, but in summary you shouldn't a
> dozen of
> configure options to configure your build from source.  Just release a sane
> upstream tarball.
>
> Matthias
>

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web