Hi Tony, Emmanuel, Matthias, On 05-06-2019 08:07, tony mancill wrote: > On Tue, Jun 04, 2019 at 09:36:56PM +0200, Paul Gevers wrote: >> Ping... [fixed borked address of doko and added Tony] >> >> On 29-05-2019 20:22, Paul Gevers wrote: >>> Control: tags -1 928185 moreinfo >>> Control: reopen -1 >>> >>> Hi, >>> >>> On 28-05-2019 23:50, Emmanuel Bourg wrote: >>>> Tony Mancill has prepared the tpu upload yesterday and Matthias was ok >>>> with 11.0.3+7 in testing [1]. >>> >>> Can I see a debdiff please? >>> >>>> Unless Buster is expected at the end of July I'd advise against having >>>> 11.0.4+2 in testing. This version is an early access release, the final >>>> 11.0.4 release is expected on July 16th [2]. Debian is currently being >>>> criticized [3] for allowing EA versions of OpenJDK in Debian stable, I >>>> think it's important to ship Buster with a GA release. >>> >>> Then please refrain from uploading the wrong version to unstable, we >>> have experimental for that. TPU doesn't get much testing, and for sure >>> isn't covered well by our QA yet. So having such a high profile package >>> with so much changes going through tpu is awkward. > > Hi Paul! > > Thank you for copying me on this as I missed this bug, despite being > part of a related thread on debian-java [1] (that probably mentions it > somewhere). Also, aside from sponsoring an upload of openjdk-8 to > experimental for Tiago last year, I haven't worked much with the openjdk > packaging and so am trying to come up to speed. However, I do think > it's important that Buster ship with a "GA" version of openjdk-11 (if > possible), which is why I have volunteered to help. > > I've looked at a couple different approaches, both of which result in > large debdiffs. > > The first is to take Matthias' upload of 11.0.3+7-4 to unstable [2] and > then revert the jdk11u-dev updates patch as per a suggestion made by > Emmanuel in IRC. The resulting debdiff against the current package in > buster is about 310k [3]. > > The second approach was to go back to the 11.0.3+1-1 package in buster > and then import upstream 11.0.3+7, resulting in a debdiff of 270k [4]. > (I am numbered this 11.0.3+7-1 for my local build, since that's still > less than the version in unable, but let's ignore the package revision > for now.) My hope was that the second approach would result in a smaller > diff to make it more palatable to the Release Team, but 270k is big. > > Note that the second approach is essentially the one Emmanuel took with > openjdk-11 backport for stretch [5]. The reason the debdiff is smaller > is because debian/patches/changes-from-11.0.3+1-to-11.0.3+7.patch > doesn't prunes the changes to upstream tests that changed between those > releases. Or to put it another way, most of the large debdiff is due to > tests, not changes to the runtime. > > All that said, I'm not well-versed in all of the packaging changes made > since the freeze and haven't formed a strong opinion on which approach > is better for Buster. At a minimum we need to address the CVEs present > in 11.0.3+1, so the idea with jumping to 11.0.3+7 is that we address the > security issues and are building from an upstream GA tag instead of an > early-access tag. > > Sorry for the book - I know all you asked for was the debdiff... > > Thanks, > tony > > [1] https://lists.debian.org/debian-java/2019/05/msg00007.html > [2] https://tracker.debian.org/news/1038802/accepted-openjdk-11-11037-4-source-into-unstable/ > [3] https://people.debian.org/~tmancill/openjdk-11/11.0.3+1-1.dsc_vs_11.0.3+7-5.dsc.debdiff > [4] https://people.debian.org/~tmancill/openjdk-11/buster_minimal_11.0.3+1-1_11.0.3+7-1_dsc.debdiff > [5] https://tracker.debian.org/news/1040268/accepted-openjdk-11-11031-1bpo92-source-amd64-all-into-stretch-backports-backports-policy-stretch-backports/ I really want bug 900912 and 925071 fixed. It seems that is missing from your second approach. Let me sleep on it. What are the chances of you agreeing on doing the +really upstream version dance such that we can get some testing done in unstable? Paul
Attachment:
signature.asc
Description: OpenPGP digital signature