Le 11/07/2024 à 10:58, Matthias Klose a écrit :
I'd like to update java-common to OpenJDK 21, basically uploading the
package from experimental to unstable. In the past, Emmanuel was
leading these updates, but he told me privately that he doesn't have
much time in the near future doing that.
On 12.07.24 05:59, tony mancill wrote:
Is the intent to allow OpenJDK 21 to migrate to testing, or to get it
into unstable and block the migration?
I don't understand that. OpenJDK 21 is in testing, this is about
changing the default to 21 in java-common.
I don't want to drive this transiti
Hi Matthias,
On Thu, Jul 11, 2024 at 10:58:49AM +0200, Matthias Klose wrote:
> I'd like to update java-common to OpenJDK 21, basically uploading the
> package from experimental to unstable. In the past, Emmanuel was
> leading these updates, but he told me privately that he doesn't have
> much ti
On Thu, 11 Jul 2024, Matthias Klose wrote:
> We will have to keep m68k as pointing to 17 for now.
What, other than the test dependencies, is missing for m68k?
I uploaded a t64-installable hacked 20 so we can bootstrap 21.
Maybe there are some patches that need updating?
Could you maybe do someth
On 26/06/2023 20:53, Thorsten Glaser wrote:
Last time I asked the answer was a vague yes; is this still
the case?
Nothing has changed, so yes. We just need openjdk-8 in unstable.
Emmanuel Bourg
Hi Vladimir,
>Sorry for the late reply, but I have realized that there might be an
>issue with adopting jtreg6 for Java 8 testing.
>
>Jtreg 6 requires testng 7.3[1] and Jtreg 5 uses 6.9.5[2]. The current
>jtreg6 package uses 6.9.5 making it suitable for Java 8 testing but
>not so much for 11 and u
Hi,
Sorry for the late reply, but I have realized that there might be an
issue with adopting jtreg6 for Java 8 testing.
Jtreg 6 requires testng 7.3[1] and Jtreg 5 uses 6.9.5[2]. The current
jtreg6 package uses 6.9.5 making it suitable for Java 8 testing but
not so much for 11 and up. If testng is
Hi,
I see. I will look into those failures to see if it is something that
I can submit upstream, so that jtreg 5 could be phased out.
Thanks a lot for the help again !!!
Best Regards,
Valdimir.
On Thu, Mar 16, 2023 at 11:11 AM Thorsten Glaser wrote:
>
> On Thu, 16 Mar 2023, Vladimir Petko
On Thu, 16 Mar 2023, Vladimir Petko wrote:
>Regarding using jtreg6 for tests of openjdk-8 it should be noted that
>some tier1[1] tests fail with jtreg6.
Lots of tests fail there anyway, also due to lack of asmtools.
>For instance jtreg 6 fails:
[…]
>and with jreg 5 those tests pass:
[…]
>There a
Hi,
Regarding using jtreg6 for tests of openjdk-8 it should be noted that
some tier1[1] tests fail with jtreg6.
For instance jtreg 6 fails:
FAILED: java/util/stream/boottest/java/util/stream/DoubleNodeTest.java
FAILED: java/util/stream/boottest/java/util/stream/FlagOpTest.java
FAILED: java/util/s
Hi,
Thank you very much
Best Regards,
Vladimir.
On Wed, Mar 15, 2023 at 10:43 PM Emmanuel Bourg wrote:
>
> Hi,
>
> Thank you for the package Vladimir, I'll take care of it. I think I'll
> rebase it on top of the previous jtreg package to keep the continuity.
>
> Emmanuel Bourg
>
>
> Le 202
Le 2023-03-02 01:30, Thorsten Glaser a écrit :
openjdk-8 was switched to jtreg6 recently. See if doko will
follow for 11.
openjdk-11/11.0.18+10-1 in unstable now uses jtreg6
Is a new package needed anyway?
I agree with Thorsten, a new package is probably not needed. All
openjdk-*
packag
Hi,
Thank you for the package Vladimir, I'll take care of it. I think I'll
rebase it on top of the previous jtreg package to keep the continuity.
Emmanuel Bourg
Le 2023-03-15 08:23, Vladimir Petko a écrit :
Hi,
Thank you very much for your help!!!
I have filed ITP here [1].
Best Regards,
V
Hi,
Thank you very much for your help!!!
I have filed ITP here [1].
Best Regards,
Vladimir.
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1032981
On Wed, Mar 15, 2023 at 8:53 AM Thorsten Glaser wrote:
>
> On Wed, 15 Mar 2023, Vladimir Petko wrote:
>
> >Since I can not upload I will fi
On Wed, 15 Mar 2023, Vladimir Petko wrote:
>Since I can not upload I will file the ITP then.
Depends on your sponsor, whether they insist on one. But, go ahead.
>Would it be ok to
>keep ownership with the Debian Java Team in line with jtreg6?
Usual procedure is that for team-maintained packages
Hi,
Thank you very much!
Since I can not upload I will file the ITP then. Would it be ok to
keep ownership with the Debian Java Team in line with jtreg6?
Best Regards,
Vladimir.
On Tue, Mar 14, 2023 at 10:29 PM Thorsten Glaser wrote:
>
> On Tue, 14 Mar 2023, Vladimir Petko wrote:
>
> >jtr
On Tue, 14 Mar 2023, Vladimir Petko wrote:
>jtreg6 (in line with jtreg6 packaging which kept jtreg changelog). Was
>it a correct thing to do, or should it be truncated?
You can keep it; debhelper can now truncate it.
>I could not find an ITP bug for jtreg6, does it mean that there is
>some other
Hi,
I have uploaded a draft [1] to salsa. I have kept changelog from
jtreg6 (in line with jtreg6 packaging which kept jtreg changelog). Was
it a correct thing to do, or should it be truncated?
I could not find an ITP bug for jtreg6, does it mean that there is
some other process that I need to foll
On Fri, 3 Mar 2023, Vladimir Petko wrote:
>It is definitely an option to chase those errors and failures down and
>ensure that basic tests pass with jtreg 7.1.1, but keeping around
>jtreg6 for JDK 17 and jtreg7 for JDK 20 is probably an easier option
>that will not require a lot of maintenance ove
Hi,
I've run tier1 and tier2 tests of OpenJDK 17 with jtreg 7.1.1.
For tier1 there are 4 failures in javac and 6 failures in javadoc.
Tier 2 fails jaxp testsuite with 418 failures due to permission error,
hotspot fails class data sharing test and jdk fails with 'can`t find
junit`, since jtreg now
On Thu, 2 Mar 2023, Vladimir Petko wrote:
> Unfortunately jtreg6 is required. 6.1 is used by OpenJDK 17 and 6.1.1
I only see an “is used by” there, not a “requires this but cannot work
with a newer version”.
Upper bounds are often much more flexible, see openjdk-8 using jtreg6
now for example ☻
Hi,
Unfortunately jtreg6 is required. 6.1 is used by OpenJDK 17 and 6.1.1
is used by OpenJDK 18 and 19. Java 17 is going to be supported until
2030[1] and Java 21 is going to be supported until 2028 [2], so both
packages are warranted.
Best Regards,
Vladimir.
[1] https://javaalmanac.io/jdk/17
On Thu, 2 Mar 2023, Vladimir Petko wrote:
>OpenJDK 20. We still need jtreg6 and jtreg packages for older
>versions of OpenJDK.
openjdk-8 was switched to jtreg6 recently. See if doko will
follow for 11.
>I was wondering if it would be acceptable for me
>to file an intent to package proposal for
On Tue, Jan 10, 2023 at 10:21:34AM +1300, Vladimir Petko wrote:
> Hi,
>
> Thanks a lot for the reply!!! I am more than happy to try to package it,
> just wondering if I should put
> "Owner: Debian Java team " and "The package
> will be team-maintained in the Debian Java team" or something else in
Hi,
Thanks a lot for the reply!!! I am more than happy to try to package it,
just wondering if I should put
"Owner: Debian Java team " and "The package
will be team-maintained in the Debian Java team" or something else in the
ITP bug?
Best Regards,
Vladimir.
On Tue, Jan 10, 2023 at 10:06 AM ton
Hello Vladimir,
On Tue, Jan 10, 2023 at 08:22:45AM +1300, Vladimir Petko wrote:
> Dear Maintainers,
>
> A number of jtreg tests fail during OpenJDK testing with the following
> error:
>
> `` compiler/c1/KlassAccessCheckTest.java
> Error. can't find jasm``
>
On 06.01.2023 12:48, Aleksey Shipilev wrote:
Hi Emmanuel,
On 1/5/23 23:20, Emmanuel Bourg wrote:
Its tricky, the arch all packages are usually built and tested on amd64
only (reproducible-builds.org also rebuilds on i386, arm64 and armhf).
Rebuilding the 1500+ Java packages takes at least two
Hi Emmanuel,
On 1/5/23 23:20, Emmanuel Bourg wrote:
Is it enabled in all JDKs after JDK 18 too?
Yes, it is implemented and enabled by default in JDK 18+ onward. I now see openjdk-{18,19,20,21}-*
ship in sid for many architectures already, so this Zero improvement might already be implicitly t
Hi Aleksey,
Le 05/01/2023 à 10:16, Aleksey Shipilev a écrit :
Last year, I implemented the fast bytecodes feature in OpenJDK Zero
interpreter [1]. It shipped with JDK 18, and I have recently backported
it to 17u. This should land in 17.0.7 in April 2023.
I believe Debian runs with Zero on so
On Fri, 11 Nov 2022, Emmanuel Bourg wrote:
> once the system
> is upgraded to bookworm, openjdk-11-jre will not be updated anymore and a
> manual update to openjdk-17-jre will be necessary at some point.
Yes, but if this is precisely the desired outcome…
> Why worse? sid users will be the first
Le 11/11/2022 à 01:46, Thorsten Glaser a écrit :
3. openjdk-11-jre-headless was used in bullseye (most people I know
do this to avoid the needless metapackage), the user will end up with
both because the Provides on java-runtime-headless in bullseye was
unversioned but maybe they don’t (worse if
On Fri, 11 Nov 2022, Emmanuel Bourg wrote:
> default-jre-headless | java11-runtime-headless
>
> Let's assume this is changed in bookworm to:
>
> default-jre-headless | java-runtime-headless (>= 11)
>
> Considering a tomcat9 user upgrading from bullseye to bookworm, there are two
> cases
Le 10/11/2022 à 22:39, Thorsten Glaser a écrit :
That’s not the point. That much is true, but the point here is
that the user *CAN* use Java 11, *if* they have installed it
beforehand, i.e. that they are not _forced_ to upgrade.
If they don’t have it installed, the default-jre will be installed
Le 10/11/2022 à 22:15, Thorsten Glaser a écrit :
The application defines
default-jre (>= 2:1.11) | java-runtime (>= 11)
but openjdk-11-jre does not yet Provides java-runtime,
only java11-runtime. This will force the user to 17.
But openjdk-17-jre also provides java11-runtime. So even
On Thu, 10 Nov 2022, Emmanuel Bourg wrote:
> But openjdk-17-jre also provides java11-runtime. So even with:
>
> default-jre (>= 2:1.11) | java11-runtime
>
> there is no guarantee Java 11 will be used.
That’s not the point. That much is true, but the point here is
that the user *CAN* use Jav
On Thu, 10 Nov 2022, Emmanuel Bourg wrote:
> better. But I don't see the need to wait a decade before using the versioned
> java-runtime dependency in the packaged applications, what issue do you
> foresee?
The application defines
default-jre (>= 2:1.11) | java-runtime (>= 11)
but openj
Le 31/10/2022 à 19:54, Thorsten Glaser a écrit :
No, we really should not: the various JDKs also only provide
java-runtime and this dependency is specifically meant to
also make it possible for software to use a JRE *other* than
the default (the dependency reads like
default-jre (>= x) |
Le 08/11/2022 à 20:49, Moritz Mühlenhoff a écrit :
If the Security Team agrees I think we should continue with this strategy in
Bookworm and ship OpenJDK 21 in addition to OpenJDK 17. The first OpenJDK 21
EA release will be available in December well before the freeze in March, so
that fits with
On Tuesday, 8 November 2022 19:51:12 GMT Moritz Mühlenhoff wrote:
> Am Thu, Sep 29, 2022 at 02:06:06PM +0200 schrieb Thorsten Glaser:
> > > Last point, we still have OpenJDK 8 in unstable to help with the
> > > bootstrapping of some packages that can't build directly with the
> > > latest JDK (more
On Tue, 8 Nov 2022, Moritz Mühlenhoff wrote:
> Do we even have to keep 8 around in unstable at this point? If people
> want to bootstrap kotlin or scala for a new arch, why can't this
> happen on a buster system?
AIUI this is not a :any issue, but an issue of bootstrapping one
new enough to run w
Am Thu, Sep 29, 2022 at 02:06:06PM +0200 schrieb Thorsten Glaser:
> > Last point, we still have OpenJDK 8 in unstable to help with the
> > bootstrapping
> > of some packages that can't build directly with the latest JDK (more
> > specifically, Kotlin and Scala). Similarly I think we should preserv
Am Thu, Sep 29, 2022 at 12:00:42PM +0200 schrieb Emmanuel Bourg:
> Hi all,
Sorry for the late reply, this got backlogged in my inbox.
> The first point is to plan when we'll switch the default JDK to OpenJDK 17.
> The transition has progressed well, with 113 bugs fixed already, but there
> are st
On Mon, 31 Oct 2022, Emmanuel Bourg wrote:
> Also worth noting, default-jre now provides a versioned java-runtime
> dependency. This means we can now replace the java-runtime dependencies
> with java-runtime (>= n).
No, we really should not: the various JDKs also only provide
java-runtime and thi
Le 29/09/2022 à 12:00, Emmanuel Bourg a écrit :
I propose to switch on October 31th
for Halloween, such that the switch will unleash compatibility
nightmares and runtime horrors haunting those who have ignored the bug
reports for months ;)
As announced last month, I've just uploaded java-com
On Thu, Sep 29, 2022 at 08:07:30PM +0200, Emmanuel Bourg wrote:
> Le 29/09/2022 à 14:06, Thorsten Glaser a écrit :
>
> > > Last point, we still have OpenJDK 8 in unstable to help with the
> > > bootstrapping
> > > of some packages that can't build directly with the latest JDK (more
> > > specific
On Thu, 29 Sep 2022, Emmanuel Bourg wrote:
> > Who’s going to maintain that?
>
> I don't think the maintenance is a concern, we only have to ensure it
> keeps building in sid.
Yeah well, that’s maintenance, and that was missing for 8 as shown in:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug
Le 29/09/2022 à 14:06, Thorsten Glaser a écrit :
Last point, we still have OpenJDK 8 in unstable to help with the bootstrapping
of some packages that can't build directly with the latest JDK (more
specifically, Kotlin and Scala). Similarly I think we should preserve OpenJDK
11 in unstable after
On Thu, 29 Sep 2022, Emmanuel Bourg wrote:
> previous releases is kept. This scenario is likely to continue in the future
> since the Debian and Java releases are now synchronized on the same 2 years
> cycle.
We could always delay Debian’s… (SCNR) or petition upstream to change theirs.
> Assumin
Hi Thomas,
> since Java 8 Update 341 is the default on java.com I think it should be in the
> Debian repo.
there’s 8u342-b07-1 (which corresponds to 8u345-ga) in Debian,
but *only* for jessie and stretch ELTS, and (totally unsupported)
in unstable. java.*com* has no bearing on Debian.
Debian has
On Wed, Sep 28, 2022 at 01:30:02PM +, Thomas Vatter wrote:
> Am 28.09.22 um 10:22 schrieb Phil Morrell:
> > On Wed, Sep 28, 2022 at 08:32:23AM +, Thomas Vatter wrote:
> > > a complete OpenJDK 8 is missing in the repo. There is only a server VM.
> >
> > Hi Thomas,
> >
> Hi Phil,
Hello Mai
Hi Phil,
since Java 8 Update 341 is the default on java.com I think it should be
in the Debian repo.
Thomas
Am 28.09.22 um 10:22 schrieb Phil Morrell:
On Wed, Sep 28, 2022 at 08:32:23AM +, Thomas Vatter wrote:
a complete OpenJDK 8 is missing in the repo. There is only a server VM.
Hi
Hi Phil,
> On Wed, Sep 28, 2022 at 08:32:23AM +, Thomas Vatter wrote:
> > a complete OpenJDK 8 is missing in the repo. There is only a server VM.
> OpenJDK 8 LTS has not been included in Debian since stretch which as of
it’s in sid, though… mostly to help boostrap Kotlin and things,
and to p
On Wed, Sep 28, 2022 at 08:32:23AM +, Thomas Vatter wrote:
> a complete OpenJDK 8 is missing in the repo. There is only a server VM.
Hi Thomas,
OpenJDK 8 LTS has not been included in Debian since stretch which as of
June 30th is no longer supported by LTS team. Please update to v11 LTS
from D
Hi,
> However, this version has not been updated since the Bullseye release
> (whereas the up to date version is available in testing).
right, someone has to do a stable or stable-security upload; probably
the latter, from how this has been handed for other JDK versions before.
Primary contact f
On Wed, 23 Jun 2021, Debian FTP Masters wrote:
> openjdk-8 (8u292-b10-3) unstable; urgency=medium
> .
>* Re-upload with actually regenerated debian/control, oops
Meh. This SHOULD have failed when building the source package.
I fully blame git, unlike proper version control software (that
i
Processing commands for cont...@bugs.debian.org:
> tags 907541 + confirmed upstream
Bug #907541 [openjdk-8] [openjdk-8] Bind to a multicast address fails
Added tag(s) upstream and confirmed.
> found 907541 openjdk-8/8u292-b10-1
Bug #907541 [openjdk-8] [openjdk-8] Bind to a multicast address fails
Processing commands for cont...@bugs.debian.org:
> tags 834053 + confirmed upstream
Bug #834053 [src:openjdk-8] openjdk-8: java.awt.Font#deriveFont(int style)
corrupts font size
Added tag(s) upstream and confirmed.
> found 834053 openjdk-8/8u292-b10-1
Bug #834053 [src:openjdk-8] openjdk-8: java.a
Processing commands for cont...@bugs.debian.org:
> found 819785 8u292-b10-1
Bug #819785 [openjdk-8-jre-headless] openjdk-8-jre-headless: Debug information
missing in JRE jars
Marked as found in versions openjdk-8/8u292-b10-1.
> tags 819785 + upstream
Bug #819785 [openjdk-8-jre-headless] openjdk-8
On Mon, 26 Apr 2021, Thorsten Glaser wrote:
>I assume the normal
> process of looking at it and eventually getting back to us will run
> now.
So far, nothing happened, and repeated inquiries got no response at all.
Just keeping the list informed.
bye,
//mirabilos
--
Infrastrukturexperte • tare
Hi again,
I’ve asked over time again, but other than the “can we keep it out of
bookworm?”, which, of course, is a yes, I’ve not got any feedback yet.
> 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
> be
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 e
Le 22/04/2021 à 02:51, Thorsten Glaser a écrit :
> unfortunately not yet. They’re probably depriorising sid in times of
> freeze, but the grace period for not bothering them is probably over
> by now so if ebourg doesn’t want to prod them now, I can do this but
> nobody else should so they don’t g
Hi Phil,
> I'm sure it's just a matter of time, but have you had any feedback from
> ftp-masters about openjdk-8?
unfortunately not yet. They’re probably depriorising sid in times of
freeze, but the grace period for not bothering them is probably over
by now so if ebourg doesn’t want to prod them
[please ignore this thread started by Adrian; he's making statements on behalf
of other teams, which are not correct. Also he "forgot" to CC the security team
and the package maintainers. The issue is handled in #975016.]
On 2/6/21 11:47 PM, Emmanuel Bourg wrote:
> Le 02/02/2021 à 19:04, Adrian Bu
Le 07/02/2021 à 00:43, Thorsten Glaser a écrit :
> Users will probably ignore that and use it anyway. It would have been
> good if it could be included and kept up to date, but that’s doubling
> of efforts, not worth the hassle,
I wonder if the effort of maintaining OpenJDK 17 in bullseyes could
On Sat, 6 Feb 2021, Emmanuel Bourg wrote:
> If openjdk-17 can't be shipped in bullseyes even with prominent warnings
> that it's unsupported
Users will probably ignore that and use it anyway. It would have been
good if it could be included and kept up to date, but that’s doubling
of efforts, not
Le 02/02/2021 à 19:04, Adrian Bunk a écrit :
> bullseye-backports would be the perfect place for providing
> OpenJDK 17 to users on bullseye.
>
> OpenJDK can only be built with the previous version, and doing a
> 11 -> 12 -> 13 -> 14 -> 15 -> 16 -> 17
> bootstrap for 9 release architectures in bu
Hi All,
On Sat, Jan 2, 2021 at 12:44 AM Sudip Mukherjee
wrote:
>
> Hi All,
>
> I am seeing segfault in openjdk with a coredump when I am using the
> updated JNI libraries of swt4-gtk on ppc64el. Its happening every time
>
> Also, this will be a bug on swt4-gtk or openjdk ?
I have opened #9796
On Tue, 22 Dec 2020, Emilio Pozuelo Monfort wrote:
> I have released this to stretch and jessie (after some testing on the latter).
Thanks!
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 (
Hi Thorsten,
On 02/12/2020 20:39, Thorsten Glaser wrote:
On Wed, 2 Dec 2020, Emilio Pozuelo Monfort wrote:
Let me know how those tests go and we can proceed from there.
It builds, with the usual “most tests pass”, and the test
program I threw at it also works.
I have released this to stret
On Wed, 2 Dec 2020, Emilio Pozuelo Monfort wrote:
> Let me know how those tests go and we can proceed from there.
It builds, with the usual “most tests pass”, and the test
program I threw at it also works.
bye,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tar
On 02/12/2020 11:21, Thorsten Glaser wrote:
Hi Emilio,
If you can send a debdiff I'd be happy to take a look.
the debdiff between sid and stretch would be trivial, just
changelog and the regenerated debian/control file (attached).
I’m building it at the moment so I can test it first.
Do you
Hi Emilio,
> If you can send a debdiff I'd be happy to take a look.
the debdiff between sid and stretch would be trivial, just
changelog and the regenerated debian/control file (attached).
I’m building it at the moment so I can test it first.
Do you also need a debdiff against the version curre
Hi Thorsten,
On 02/12/2020 10:06, Thorsten Glaser wrote:
Hi (E)LTS-people,
I’ve just uploaded an OpenJDK 8 regression update to sid,
sponsored by my employer (as below). (I’m also building locally
for buster, wheezy and various *buntu releases, so all possible
systems I may encounter are covere
hey Jim,
On Debian/buster, `apt-get install gradle` works for me, and its running
Java11. bullseye has the same version, as far as I know.
gradle started using kotlin, so the blocker for updates is getting
kotlin into Debian. Unfortunately the Kotlin devs made that much harder
than it should
tony mancill writes:
> Hi Felix,
>
> I haven't taken a look at it yet but will do so this weekend. Would you
> mind filing a wishlist bug against groovy regarding the update?
Sure: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951831
Thanks and Best Regards,
--
Felix Natter
On Thu, Feb 20, 2020 at 03:56:35PM +0100, Felix Natter wrote:
> Lilian BENOIT writes:
> > Hello,
>
> hello Lilian, Hans, Tony,
>
> > In july, a message "OpenJDK 13 (ea) entering testing" has been sended on
> > this
> > mailing-list. (https://lists.debian.org/debian-java/2019/07/msg9.html)
>
Lilian BENOIT writes:
> Hello,
hello Lilian, Hans, Tony,
> In july, a message "OpenJDK 13 (ea) entering testing" has been sended on
> this
> mailing-list. (https://lists.debian.org/debian-java/2019/07/msg9.html)
> There was a question : Would anybody be interested in setting up a machine
> t
Hi Moritz,
> Yeah, I wanted to let it settle in unstable for a few days, but a
> stretch-security build is already running and should appear in the
> next days.
yeah, that’s sensible, although I don’t know how many sid users
use Java 8 (I run a Jenkins instance under it); the smoketests
that were
On Mon, Feb 10, 2020 at 07:17:59PM +0100, Thorsten Glaser wrote:
> Hi tony,
>
> > source package uploaded to Debian unstable against stretch for a
> > stretch-security upload. I should be able to complete the builds and
> > smoke-tests by the end of the week and will upload once I get the
> > go-
Hi tony,
> source package uploaded to Debian unstable against stretch for a
> stretch-security upload. I should be able to complete the builds and
> smoke-tests by the end of the week and will upload once I get the
> go-ahead from the Security Team.
did you have a chance to look at my upload to
On Thu, 6 Feb 2020, Thorsten Glaser wrote:
> I’ll upload to sid if things seem to work, as discussed. I’ve also
Done now, it built, with the usual handful of test failures, but
most passing, and Jenkins still works after upgrading, so…
Things I noticed afterwards:
• debian/generate-*.sh can go a
Dixi quod…
> I’ve prepared an upload, which I’m currently building locally in
> cowbuilder, for testing it a bit
I had forgotten just how long the testsuite runs. I guess I’m
calling it a night and continue testing when it built tomorrow.
> (any suggestions, other than run a few applications?)
On Wed, 5 Feb 2020, tony mancill wrote:
> Thorsten, if you have cycles to handle the GA upload to unstable, please
I’ve prepared an upload, which I’m currently building locally in
cowbuilder, for testing it a bit (any suggestions, other than run
a few applications?). I’ve looked at and merged the
On Wed, 5 Feb 2020, tony mancill wrote:
> Thorsten, if you have cycles to handle the GA upload to unstable, please
> go ahead and do so. Otherwise, I will do it by the end of the week.
OK, will do so, I can justify doing this partially during daytime ☻
Thanks,
//mirabilos
--
tarent solutions G
On Wed, Feb 05, 2020 at 04:20:40PM +0100, Thorsten Glaser wrote:
> Hi tony,
>
> > on January 28th as a reminder). I am in process of building the 8u242
> > source package uploaded to Debian unstable against stretch for a
>
> thanks for the update, but… Debian unstable has not yet been updated
>
Hi tony,
> on January 28th as a reminder). I am in process of building the 8u242
> source package uploaded to Debian unstable against stretch for a
thanks for the update, but… Debian unstable has not yet been updated
to the GA release yet. Perhaps doing that first would be sensible?
If I can he
On Wed, Feb 05, 2020 at 03:57:11PM +0100, Thorsten Glaser wrote:
> On Tue, 28 Jan 2020, Thorsten Glaser wrote:
>
> > What I don’t understand is why the new version isn’t uploaded
>
> It’s been over three weeks since the release, what (besides
> GCC breaking everything) gives?
Hi Thorsten,
I spo
On Tue, 28 Jan 2020, Thorsten Glaser wrote:
> What I don’t understand is why the new version isn’t uploaded
It’s been over three weeks since the release, what (besides
GCC breaking everything) gives?
bye,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de
On 14.12.19 12:01, YunQiang Su wrote:
> Lilian BENOIT 于2019年11月16日周六 上午5:56写道：
>>
>>
>> Hello,
>>
>> In july, a message "OpenJDK 13 (ea) entering testing" has been sended on
>> this mailing-list.
>> (https://lists.debian.org/debian-java/2019/07/msg9.html)
>> There was a question : Would anybod
Lilian BENOIT 于2019年11月16日周六 上午5:56写道：
>
>
> Hello,
>
> In july, a message "OpenJDK 13 (ea) entering testing" has been sended on
> this mailing-list.
> (https://lists.debian.org/debian-java/2019/07/msg9.html)
> There was a question : Would anybody be interested in setting up a
> machine to che
Hi Martijn,
I somehow missed this email, sorry about that and for the late reply.
On Wed, May 29, 2019 at 7:14 AM Martijn Verburg
wrote:
>
> Hi All,
>
> Starting a new thread here. I know the Red Hat folks well (AdoptOpenJDK
> hosts their OpenJDK binaries for them from the source tarballs as p
Hi Thorsten,
I just wanted to respond with a thank you for the explanation! I'm going
to sit down with some coffee and map this out and see if/how
OpenJDK can provide backport sets.
I'll respond here after I have a chat to Matthias next Monday.
Cheers,
Martijn
On Mon, 27 May 2019 at 17:21, Th
Kotlin needs jdk 8 to build.
On Tue, 28 May 2019, 3:13 pm John Paul Adrian Glaubitz, <
glaub...@physik.fu-berlin.de> wrote:
> Hi!
>
> On 5/27/19 11:04 PM, Matthias Klose wrote:
> > The packages are now accepted and the 8u212-b03 upstream version is now
> uploaded
> > as well.
> >
> > The changes
Hi!
On 5/27/19 11:04 PM, Matthias Klose wrote:
> The packages are now accepted and the 8u212-b03 upstream version is now
> uploaded
> as well.
>
> The changes and buildinfo files didn't exist anymore for the powerpc, ppc64,
> sparc64 and x32 binaries, so if a porter wants to restore those, pleas
On Mon, 27 May 2019, Matthias Klose wrote:
> The changes and buildinfo files didn't exist anymore for the powerpc, ppc64,
> sparc64 and x32 binaries, so if a porter wants to restore those, please
> rebuild
> them with manually installed openjdk-8 packages from snapshot.debian.org.
Will do for x3
On 26.05.19 21:13, Matthias Klose wrote:
> The openjdk-8 packages which were unfortunately removed from unstable
> (although
> the issue #915620 only asked for the removal of some binaries), are now again
> in
> NEW, targeting unstable. One of the FTP assistants is objecting to the upload
> to u
On Sun, May 26, 2019 at 09:13:38PM +0200, Matthias Klose wrote:
> The openjdk-8 packages which were unfortunately removed from unstable
> (although
> the issue #915620 only asked for the removal of some binaries), are now again
> in
> NEW, targeting unstable. One of the FTP assistants is objecti
Le 26/05/2019 à 21:13, Matthias Klose a écrit :
> The openjdk-8 packages which were unfortunately removed from unstable
> (although
> the issue #915620 only asked for the removal of some binaries), are now again
> in
> NEW, targeting unstable.
Thank you for the upload Matthias.
> I honestly do
On 30/04/2019 15.21, Hans-Christoph Steiner wrote:
> It is also not possible to run upstream Gradle binaries older than 4.8
> or 4.7. It is a stupid bug on Gradle's part, but nonetheless, those
> versions work with OpenJDK 8. I guess the Debian package of gradle
> fixed the issue, since it is gr
1 - 100 of 346 matches
Mail list logo
