[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#892842: OpenJDK 8 archive re-entry



Hi again,

> > Emmanuel, will you or should I?
> 
> Please do.

sorry for taking a bit, but I did today. I talked a bit with elbrus,
explaining the reasoning, and that, of course, this won’t end up in
bookworm or have any sort of official support — I assume the normal
process of looking at it and eventually getting back to us will run
now.

In the meantime I also prepared an 8u292-b10-1… found lots of issues
even… but will wait uploading it until it was ACCEPTED into unstable
because then the buildds can do their job, instead of me needing to
do builds for each architecture… I’m building it for testing locally
right now.

> That said, we may also upload kotlin now even if openjdk-8 is still in
> the queue. As long as they enter sid in the right order, that's fine. In

I’d really prefer not. The first upload of openjdk-8 was done in a
hackish way. Please wait with uploading kotlin until 8u292 is both
uploaded *and* built by the buildds *and* in status Installed, so
it’s ready as B-D for further builds.

> the worst case kotlin will be accepted before openjdk-8 and simply
> prevented from transitioning to testing until openjdk-8 arrives.

If kotlin runtime-Depends on openjdk-8 there’s no chance it’ll ever
end up in testing anyway ☺ and even if not, it’d only do so after
the bullseye release of course.

> > I’m not exactly sure this method is the preferred one, especially
> > given ebourg’s alternative bootstrapping path from source is
> > progressing admirably. (Not to throw away that work though, it’ll
> > become useful nearer to that bootstrapping processes end.)
> 
> To be honest, I still have a very long way to go and I'm not even sure
> to succeed (I spent a full day dealing with 2 months worth of commits,
> and I'm only at the Q2 2015 code).

Right.

> They've done a great work, I don't think my approach replaces theirs, at
> best I may reconnect with them to provide the bootstrap compiler, or
> certify later that both approaches produce the same binaries.

That’s certainly one way to do it, if things build reproducibly.

We probably should look at rebootstrapping openjdk-8 at some point in
time as well… the fetch-orig target used http, not https, for downloading
the sources… one of the things I’m fixing in 8u292-b10-1 (except for
icedtea-sound because of unavailability of https for it but I downloaded
it manually, verified-ish it with PGP and added a SHA256 check to d/rules
for it so it’s at least consistent).

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*************************************************

Mit dem tarent-Newsletter nichts mehr verpassen: www.tarent.de/newsletter

*************************************************


Reply to: