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 Mon, 20 May 2024, Mechtilde Stehmann wrote:
> There are several with FTBR. I found that the day of the *.poms s a date from
> 1970.
I’ve had a look at this. The files have various, *differing*,
timestamps within the month of January 1970, which in itself
is not proper.
It’s not a t64-related
Hola Luis,
> I know that the remove tomcat9 packages was done on December of 2023 and that
> this was decided a long time ago. But I think that nobody has stopped to
> consider that you *cannot simply migrate from Tomcat 9 to 10 *(inserte here
I have. I currently maintain the tomcat9 package exte
On Sat, 6 Apr 2024, Emmanuel Bourg wrote:
> since upstream already provides a package.
That is not a justification appropriate for a Debian mailing list.
bye,
//mirabilos
--
15:41⎜ Somebody write a testsuite for helloworld :-)
Wookey dixit:
>And it worked beatifully. Thanks.
Nice!
>I'll try doing openjdk-20 next.
You’ll want 21 as 20 has not got the t64 treatment.
gl hf,
//mirabilos
--
15:41⎜ Somebody write a testsuite for helloworld :-)
Hi Wookey,
>OK, got those. but that's just binaries. It was the source changes I
>was looking for (or did I misunderstand and you didn't actually make
>any of those?),
Yes, I did not make any source changes. These were the last binaries
from before the t64 transition (I downloaded the .deb files
On Wed, 27 Mar 2024, Wookey wrote:
>I looked at this last week, but got stuck because openjdk-17's
>build-deps included graphviz
Build-Depends-Indep: graphviz, pandoc
You don’t need that. Use dpkg-checkbuilddeps -B, or manual
inspection of the .dsc (packages.d.o does show the difference
between
On Tue, 26 Mar 2024, Jeffrey Walton wrote:
>Nothing beats a native compile in your basement.
Yes, definitely.
>> Do they run stock Debian armhf?
>
>So the CubieTruck is embarrassingly down level:
Oofff…
>The Wandboard is doing better:
Right, close enough anyway.
>I don't mind shipping to Eur
Hi Jeffrey,
I’m answering back from the $dayjob address because Googlemail
cannot communicate with normal mailservers.
>I can send you two dev boards, if you want them. The first is
>Wandboard Dual (Cortex-A9, ARMv7 with NEON), and the second is
>CubieTruck 5 (Cortex-A7, ARMv7 with NEON and VFPv4
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA384
Hi,
>In the -ports world, hppa doesn't have Java anyway, while m68k, powerpc
>and sh4 seem to have had a re-bootstrap at some point; so I think it's
>only the release architectures armel and armhf that have a problem here.
I hacked that, and I trie
Hi ELTS people (mostly pochu, I guess),
for openjdk-8 tests, Vladimir tells me we “really” want jtreg5.
If it is possible to add a jtreg5 package to jessie and stretch
even if it exists nowhere else, perhaps with vendored dependencies
where applicable like it is done for jtreg7 in stable now, we
On Wed, 18 Oct 2023, Vladimir Petko wrote:
>jtreg7 depends on a number of test-related packages (junit4, junit5,
>libhamcrest-java) that require transitive dependencies such as picocli
>or opentest4j-reporting either introduced (that is not an issue) or
>upgraded.
Standard answer is that these mu
On Fri, 11 Aug 2023, Vladimir Petko wrote:
>As far as I know, the bug was fixed in [1] which is safe to update to.
20230620~deb12u1 is in bookworm-p-u which you could enable to get that
kind of fixes for stable earlier; it’ll otherwise be in the next point
release.
bye,
//mirabilos
--
Infrastru
On Fri, 7 Jul 2023, Emmanuel Bourg wrote:
> Alioth is no longer maintained, but the old lists.alioth.debian.org addresses
> have been preserved and should still be used.
But not for new things, I understood?
bye,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-
On Thu, 6 Jul 2023, Andreas B. Mundt wrote:
>The 'resources' are expected relative to /usr/share/java/filius.jar in
>directories (i.e. config/filius.ini). How is it best to handle this
>situation? Is it possible to tweak the path somehow (in the wrapper
>script?) or do I need to patch the source
On Wed, 5 Jul 2023, Andreas B. Mundt wrote:
>after that. However, when I try to start it, I get:
>
> $ java -jar /usr/share/java/filius.jar
> Error: Unable to initialize main class filius.Main
> Caused by: java.lang.NoClassDefFoundError:
> ch/qos/logback/core/joran/spi/JoranException
I think
On Tue, 4 Jul 2023, Vincent Prat wrote:
> Lately, we have been receiving a significant number of automatic emails
> concerning openjdk-8.
> This is because this diffusion list is in the Maintainer field of the package.
This is how I understoof team-maintained packages to be handled.
Especially ho
Dixi quod…
>Indeed. Weird.
>
>Thanks for reporting, I’ll have two or three looks at it… fixing that
>is going to be… fun. Not.
OK so first analysis is showing the cause of the problem:
• the buildd chroots for sid/unstable do not identify themselves as
sid/unstable but instead as trixie/testin
Hi,
we have a situation; could you please abort the openjdk-8 builds
that are not yet finished?
Thanks!
-- Forwarded message --
From: Fab Stz
Message-ID: <22218593.EfDdHjke4D@debian>
Resent-From: Fab Stz
To: Debian Bug Tracking System
Resent-To: debian-bugs-d...@lists.debian.o
On Sun, 2 Jul 2023, Fab Stz wrote:
>Updating from 8u372-ga-1 which was the previous version in unstable is not
>possible because openjdk-8-jre-headless_8e382~b04-1 depends on libjpeg8
WTF‽
*checks*
Indeed. Weird.
Thanks for reporting, I’ll have two or three looks at it… fixing that
is going to
Hi,
apparently there’s again the question whether we still need
openjdk-8 in sid for bootstrapping JVM-based languages and/or
utilities. This is independent of the question whehter it
should be there to ease backports or because people might
otherwise turn to Canonical’s commercial offer or whethe
On Sat, 13 May 2023, Andreas B. Mundt wrote:
>{htmlparser.version}
At the very least, there should be a $ before {
bye,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax:
On Tue, 18 Apr 2023, Per Lundberg wrote:
> A short update on this. This is a known regression in more recent versions of
> Java: https://bugs.openjdk.org/browse/JDK-8226919
>
> One of my colleagues (thanks, Sebastian!) managed to workaround this by
> patching the JDK 17 sources to make it use plai
On Tue, 18 Apr 2023, Loïc Rouchon wrote:
>targets the lowest installed JVM which version is greater or equals to
I’m very much not fond of this approach, because who’s to say you
want the lowest?
I’d rather have the local admin or invoking user specify the version
to use if the default version i
On Mon, 17 Apr 2023, Rob Browning wrote:
>Is there Is there a policy or preferred way to handle a package that
>needs a particular version or versions of java? e.g. say it doesn't
>work with < 9.
From a Depends standpoint, java9-runtime-headless or java9-runtime. But…
>I could imagine it might
On Sun, 9 Apr 2023, Markus Koschany wrote:
>maven-compiler-plugin. Usually this just works without changes to the version
>number. I don't think a strict plugin dependency is the true solution but it
>might help future contributors to remember the RC bug.
Also not a real fix but more sustainable
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
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
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
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
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
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 ☻
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 Fri, 24 Feb 2023, Vladimir Petko wrote:
>The issue is the migration procedure - those packages have to be
>published together to avoid any nasty surprises.
Yeah, we’ll have to pick a time to do that, which is after
the bookworm release anyway (it’s not okay to upload things
to unstable right n
On Fri, 24 Feb 2023, Vladimir Petko wrote:
>This is possible to do if we update openjdk packaging and make it
>trigger certificates-ca-java, so that it always runs after the openjdk
We can do that easily. I maintain 8 and doko the rest (I hope).
If that’s needed, i.e. if there’s no other way, th
On Thu, 23 Feb 2023, Vladimir Petko wrote:
>Notice that ca-certificates-java attempts to process triggers before
>default-jre is set up. This is exactly the condition we are trying to
>avoid.
It should run them again, and there’s got to be a way, but I’m
not a triggers expert and currently ill, p
On Thu, 23 Feb 2023, sun min wrote:
>It seems that the build system's local jdk overrides those jvm
>parameters we defined in bazelrc or bashsrcript.
How about asking Doko to locally add that parameter to 17 as a
Debian-specific patch, just ignoring it?
(And, ideally, warning.)
bye,
//mirabilos
On Wed, 22 Feb 2023, Vladimir Petko wrote:
>Alternative is to go with two packages: one for Java 11 and onwards
>that does not use Java-based import, and the other - classic
>ca-certificates-java with the trigger updated to watch Java 8?
(this also confuses me, why would 8 be special?)
bye,
//mi
On Wed, 22 Feb 2023, Vladimir Petko wrote:
>The existing trigger "interest /usr/lib/jvm" causes the import to run
Unsure, I only used triggers once, a decade ago or so myself,
but isn’t this what the interest-await trigger method is for?
bye,
//mirabilos
--
Infrastrukturexperte • tarent solutio
On Wed, 22 Feb 2023, Vladimir Petko wrote:
>in sync. A possible scenario is CA being revoked, which results in an
That’s why I was suggesting to keep it down to manually vetted
relevant ones.
But if that’s unpalatable (do talk to the security people!),
ship an empty JKS keystore by default. The
On Wed, 22 Feb 2023, Vladimir Petko wrote:
>Just a small clarification, openssl itself allows importing a single
>certificate and its chain and overwrites the store in the process, so
>we need something like p11-kit.
>Another grey area is ORACLE_TrustedKeyUsage attribute - at the moment
Ugh.
How
On Mon, 13 Feb 2023, James Kennard wrote:
>Yes, it has been a long time now, but it's taken time for the alternatives
>to gain traction. I was just trying to understand the current state of play
>to help work out how and when to move away from openjdk-8.
We’ve already moved, as a whole, to openjd
On Mon, 13 Feb 2023, James Kennard wrote:
>With the changes to Java licensing
What changes? It’s been GPLv2 + Classpath exception for *ages* now.
>, alternative distributions of Java have
>become increasingly popular. They all have their pros and cons,
Perhaps, but we’re still talking about the
On Mon, 13 Feb 2023, Hans-Christoph Steiner wrote:
> Great work there! I would still love to see openjdk-8 in bookworm.
That ship has sailed yesterday. No new entries into testing are now
possible any more.
> We're
> going to loose a bunch of Android things because doclava cannot run newer
> J
Dixi quod…
>On Mon, 30 Jan 2023, Emmanuel Bourg wrote:
>> I suggest that we let openjdk-8 transition to testing now before the
>> beginning of the soft freeze, just to keep our options open.
[…]
>then, if we indeed can keep the options open.
The MIPS buildds are at it currently and expected to f
On Fri, 10 Feb 2023, James Kennard wrote:
>Is there a particular reason why you are continuing to update it as opposed
>to recommending people switch to an alternative distribution such as
>Temurin?
I don’t know what Temurin even is.
While I do recommend that people switch to default-jdk, and in
On Fri, 10 Feb 2023, Emmanuel Bourg wrote:
>>> - Drop the +ds suffix
>>
>> Why? Isn't that traditionally used to show a repack?
>
> I have a preference for clean version numbers. The suffix is useful
> if a version was already packaged and needs to be modified afterward
> because unwanted files we
On Fri, 10 Feb 2023, Vladimir Petko wrote:
> Sorry for jumping into the discussion, but it looks like maven-helper
>deploys
> jar files slightly incorrectly.
I think this is an open bug where it’s still under discussion
whether to fix it there or change the java policy instead.
(Your eMail lines
On Thu, 9 Feb 2023, Emmanuel Bourg wrote:
> The content of the binary package is perfect. Nice trick in debian/control
> to reuse the same description, I didn't know that was possible.
These tricka usually lead to *really* awfully useless .changes files
though, unfortunately.
bye,
//mirabilos
--
On Wed, 8 Feb 2023, James Kennard wrote:
>How long will Debian continue to provide a build of openjdk-8? And how long
>will Debian continue to apply security patches to openjdk-8?
The ELTS team is going to support openjdk-8 in jessie and stretch
for as long as they get paid for (see the ELTS proj
On Wed, 8 Feb 2023, Vladimir Petko wrote:
>This functionality can be implemented using the following Python packages:
[…]
Make that an “or” dependency then, so that people who already
have the JVM installed don’t need to pull tons of Python3
packages.
bye,
//mirabilos
--
Infrastrukturexperte •
On Mon, 30 Jan 2023, Emmanuel Bourg wrote:
> Le 2023-01-26 19:39, Thorsten Glaser a écrit :
>
>>> ineluctable truth: we need OpenJDK 8 back into the stable distribution.
>>
>> Not going to happen, sorry. This has been vetoed by the security
>> team and was the con
On Thu, 26 Jan 2023, Emmanuel Bourg wrote:
> ineluctable truth: we need OpenJDK 8 back into the stable distribution.
Not going to happen, sorry. This has been vetoed by the security
team and was the condition for keeping it in unstable at all.
bye,
//mirabilos
--
Infrastrukturexperte • tarent s
On Mon, 12 Dec 2022, Emmanuel Bourg wrote:
> There is another benefit of a versionless package: backport continuity. When
> the tomcat package replaces tomcat in testing/unstable, it's no longer
> possible to update the tomcat backport in stable (because the version must
> exist in testing). With
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
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
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
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
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
Hi Pierre,
>java.io.InvalidClassException: org.antlr.v4.runtime.atn.ATN;
>Could not deserialize ATN with version 4 (expected 3)
what exactly does it deserialise there?
Is this maybe something that we should build from source in the
Debian packaging instead?
That would also solve your i
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
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
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 Sat, 20 Aug 2022, Phil Morrell wrote:
> Hi all, documenting my observations as of today because it's not looking
> promising for bookworm.
>
> * kotlin FTBFS because of changes to support openjdk 17 #1012214
If gradle depends on kotlin, it’s not eligible for stable anyway
because kotlin curre
On Wed, 18 May 2022, Carlo Stemberger wrote:
> I'd like to do it myself, but:
> 1) It's a very big project;
> 2) I have 0 experience in packaging;
> 3) I'm not a Java programmer
>
> Is there someone interested in helping me?
This is then probably quite a bit more than just helping…
> First step,
On Fri, 29 Apr 2022, Evren Yurtesen wrote:
> > What is the problem with logrotate? It happily rotates files owned
> > by anyone in Debian.
>
> Because in Ubuntu rsyslog drops privileges to `syslog` user.
> Therefore, the log files generated by rsyslog are owned by the
> `syslog` user. But tomca
close 896907
thanks
Hi,
closing as the requested moreinfo was not provided in the last ~year
and we’re moving toward 17 as supported JDK/JRE.
bye,
//mirabilos
--
Gestern Nacht ist mein IRC-Netzwerk explodiert. Ich hatte nicht damit
gerechnet, darum bin ich blutverschmiert… wer konnte ahnen, daß
On Thu, 14 Apr 2022, Utkarsh Gupta wrote:
> The submitter has provided a debdiff, too:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1008668;filename=tomcat9_9.0.58-1ubuntu1.debdiff;msg=5.
This will break other syslog implementations, though.
What is the problem with logrotate? It ha
On Wed, 23 Mar 2022, Emmanuel Bourg wrote:
> I vaguely remember that replacing a symlink with a file during a package
> update was causing some issues (i.e. the target is updated but the symlink
Wasn’t that only for directories?
bye,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
A
On Tue, 22 Feb 2022, Thomas Uhle wrote:
> What do you think, wouldn't it be time for an update in Debian?
The comment
> at https://github.com/beanshell/beanshell/issues/603 .
reads for me more like a “maybe remove it instead…”.
Honestly though, if it’s not available in Central, upstreams will
no
Hi Holger,
> and filed against src:debian-security-support, as openjdk-17 seems to be
> supported and src:debian-security-support's purpose is to documented what's
no, 11 is supported, 17 is just for users to run third-party
stuff on (IIUC).
bye,
//mirabilos
--
Infrastrukturexperte • tarent sol
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 Mon, 25 Oct 2021, Nils Rennebarth wrote:
> Background is that I install the openjdk-11-jre in a chrooted
> environment where no /proc is available. This only produces the final
> system as a tarball though.
I’d argue that this is likely to be a problem in many more places,
though; making /proc
On Tue, 10 Aug 2021, Markus Koschany wrote:
> Obviously you should wait for Emmanuel's feedback before doing
> anything.
So… Emmanuel?
bye,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49
On Tue, 10 Aug 2021, Markus Koschany wrote:
> Currently I don't plan to update the bpo version of Tomcat 9 in Buster. If you
> prefer the latest updates then I'd suggest to focus on bullseye-backports from
I think you misunderstood the intention of this request.
Packages in $version-backports ha
Hi,
the tomcat9 backport is pretty much orphaned: newer tomcat9
versions don’t even build in buster any more¹, and both
bullseye² and buster received security fixes recently.
① One built in bullseye works on buster but that is, of course,
no option for bpo. (It works for my sysvinit-compatible
On Sat, 10 Jul 2021, Carsten Schoenert wrote:
> ensure users have also installed openjdk-11-jre to get Arduino IDE working.
Or 17?
If you need to ensure a minimum version, do this (/bin/sh-safe):
if test "$(java -XshowSettings:properties -version 2>&1 | \
sed -n '/^java.version = \([0-
On Mon, 5 Jul 2021, Carsten Schoenert wrote:
> > $ ls -la /usr/bin/java
> > lrwxrwxrwx 1 root root 22 19. Jun 2017 /usr/bin/java ->
> > /etc/alternatives/java
> > $ ls -la /etc/alternatives/java
> > lrwxrwxrwx 1 root root 43 8. Nov 2018 /etc/alternatives/java ->
> > /usr/lib/jvm/java-11-openj
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
Hi Samuel,
> I'd like to request this same feature for the java ecosystem on Debian.
this thing exists:
Package: openjdk-8-jre-headless
Provides: java2-runtime-headless, java5-runtime-headless,
java6-runtime-headless, java7-runtime-headless, java8-runtime-headless
# and java-runtime-headless e
reassign 920562 qemu-user-static
forcemerge 986022 920562
thanks
This is pretty much the same issue, just for arm64 emulation.
bye,
//mirabilos
--
Gestern Nacht ist mein IRC-Netzwerk explodiert. Ich hatte nicht damit
gerechnet, darum bin ich blutverschmiert… wer konnte ahnen, daß SIE so
reagier’
Hi Andre,
> This was supposed to be fixed upstream in Java 12:
> https://bugs.openjdk.java.net/browse/JDK-8210493
>
> However it was taken back again (see last comment in that issue) and is now
> supposedly fixed in java 13:
> https://bugs.openjdk.java.net/browse/JDK-8215294
> https://bugs.openjd
tags 907541 + confirmed upstream
found 907541 openjdk-8/8u292-b10-1
found 907541 openjdk-11/11.0.12+4-1
thanks
On Wed, 29 Aug 2018, Andre Naujoks wrote:
> This bugs affects all currently available Java versions in Debian (7, 8, 10
> and 11).
> I don't know how to mark this here.
Normally, cloni
On Wed, 25 Apr 2018, Mark Waite wrote:
> Java assistive
> technologies should be disabled in the *-headless package so that
> components do not mistakenly believe assistive technologies might work.
I’m not sure this is technically possible; this is a conffile,
so we cannot, from a packaging PoV,
tags 834053 + confirmed upstream
found 834053 openjdk-8/8u292-b10-1
found 834053 openjdk-11/11.0.12+4-1
thanks
On Mon, 18 Feb 2019, Nobuhiro Ban wrote:
> Or, should I send this report to upstream?
This would be appreciated. While we can fix that in the
Debian copies of openjdk-8, and probably Do
found 819785 8u292-b10-1
tags 819785 + upstream
thanks
On Sat, 2 Apr 2016, Christian Haul wrote:
> I have just discovered that stepping into JRE classes with a debugger does not
> allow inspecting variable states, the debugger complains that classes are
> built
> without "-g" option.
They are
Hi,
can anyone comment on the status of:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760982
Is there anything that still needs to be done? AFAICT it
works fine on jessie.
bye,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.
Dixi quod…
> On Thu, 29 Apr 2021, Sunil Mohan Adapa wrote:
>
> > Kotlin packaging[1] is in a good shape and ready to be uploaded[2] into
> > Debian. We need a DD willing to upload it.
> >
> > The actual upload needs to wait for openjdk-8, which is currently in the
> > NEW queue, to be accepted f
On Thu, 27 May 2021, Andreas Tille wrote:
> > Shoot into the blue: $HOME?
>
> I had the same idea and tried this
>
>
> https://salsa.debian.org/r-pkg-team/r-cran-epitweetr/-/blob/master/debian/rules#L9
>
> but it does not help. :-(
I see…
> PS: In case someone might like to try pbuilder to
On Thu, 27 May 2021, Andreas Tille wrote:
> I tried again without any clue - may be it is simply some missing
> directory inside pbuilder - but I have no idea which one. :-(
Shoot into the blue: $HOME?
bye,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121
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
--
Infrastrukt
On Fri, 7 May 2021, Phil Morrell wrote:
> Are you planning to upload to stretch
stretch is closed; backports only follow normal release cycles and
desupport LTS. (This is a thing I’m hoping to change when I might
be able to at some point in the future, but nothing’s decided yet.)
bye,
//mirabilo
On Fri, 7 May 2021, Matthias Klose wrote:
> Is there any reason to use debhelper 13? Does it have anything that
> is relevant for java packages? Just asking because that's usually
> something which needs to be downgraded for backports. But I assume
> there are enough dependency requiring debhelpe
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
On Sat, 1 May 2021, Olek Wojnar wrote:
> FWIW, help2man is often a really good starting point.
REALLY not; that produces really bad-quality man(7)-format manpages.
These days you want semantical markup via mdoc(7) instead (see, for
example, the manpage I wrote for jamulus or others).
bye,
//mir
On Thu, 29 Apr 2021, Sunil Mohan Adapa wrote:
> Kotlin packaging[1] is in a good shape and ready to be uploaded[2] into
> Debian. We need a DD willing to upload it.
>
> The actual upload needs to wait for openjdk-8, which is currently in the
> NEW queue, to be accepted first.
Again, please only
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
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
1 - 100 of 343 matches
Mail list logo
