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
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
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 p
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 Open
On 29.05.2019 03:59, Tiago Daitx wrote:
On Tue, May 28, 2019 at 6:21 AM Emmanuel Bourg 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 t
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 ind
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
On Tue, May 28, 2019 at 10:59 PM Tiago Daitx wrote:
>
> On Tue, May 28, 2019 at 6:21 AM Emmanuel Bourg 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
On Tue, May 28, 2019 at 6:21 AM Emmanuel Bourg 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
>
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{ href=\"/jdk-updates/jdk11u/rev/[^\"]*\">\s*(jdk-1
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 app
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 ba
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 alre
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) v
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
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 th
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 d
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 i
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,
Hi Matthias.
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 wi
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://ma
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 wrote:
> >
> >> On Thu, May 23, 2019 at 11:58:14PM +0200, Emmanuel Bourg wrote:
> >>> Le 23/05/2019 à 19:04, Martijn Verburg a écrit :
> >>>
>
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
On 24.05.19 20:29, Martijn Verburg wrote:
> On Fri, 24 May 2019 at 15:40, tony mancill 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?
>>>
>>> T
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.
>
> T
On Fri, 24 May 2019 at 15:40, tony mancill 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 ba
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 Deb
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 backpor
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
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 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 securi
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.jav
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-20
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 i
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 f
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
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.jav
On 5/20/19 2:32 PM, Emmanuel Bourg wrote:
> 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.
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 a
Hi Emmanuel,
On 5/20/19 12:10 PM, Emmanuel Bourg wrote:
> Le 20/05/2019 à 10:48, Aleksey Shipilev a écrit :
>> 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 Stre
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
40 matches
Mail list logo
