On Tue, Feb 21, 2023 at 03:15:18PM +, sun min wrote:
> > If the test passes regularly, and just sometimes fails under the same
> > conditions, I would consider disabling it in autopkgtest rather than have
> > it not
> > make it into bookworm. The perfect is the enemy of the good.
>
> The aut
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
Hi,
I would really love to prototype the approach, but might need a little
advice here: in order to use openjdk-20 onwards we need to run the
trigger after openjdk-20 jre is installed (all files are present on
file system, all property files renamed from .dpkg_new).
The existing trigger "interest
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
Hi,
I wonder if security guys will have some reservations abouts the
pre-built root list. This will result in supplying two potentially
different sources of trust and will require maintenance to keep those
in sync. A possible scenario is CA being revoked, which results in an
update to ca-certific
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
Hi,
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
store implementation sets it on save, but it does not
Hi,
That's a great idea. I was thinking of using p11-kit [1] to generate
Java 11 + certificates [2]. I have abandoned it because
ca-certificates-java attempts to synchronize the store, keeping user's
certificates that were added for Java only.
I wonder if we can drop this requirement and declare t
Hi Vladimir,
Thank you for tackling this annoying issue.
You said that JKS was required to support OpenJDK 8, but there is no
such requirement, at the Debian level at least. What about generating a
PKCS#12 certstore with OpenSSL instead, would that work? The python
script could still be used
Hi,
> If the test passes regularly, and just sometimes fails under the same
> conditions, I would consider disabling it in autopkgtest rather than have it
> not
> make it into bookworm. The perfect is the enemy of the good.
The autopkgtest always fails .
The maintainer added a “-XX:+UseParalle
Le 2023-02-21 16:03, Olek Wojnar a écrit :
I *have* temporarily disabled the Java tests [1]. As you said, to not
hold back the package due to a possibly flaky test. But my concern is
that this is actually an issue with how Bazel uses Java rather than a
flaky test. Again, I'd be happy to be wrong
My feeling is that this problem is probably fixed in a newer Bazel version,
so it could be automatically solved if we can package Bazel 5 or 6, but of
course, that's not trivial work.
On Tue, Feb 21, 2023 at 4:04 PM Olek Wojnar wrote:
> Hi hc,
>
> Thanks for helping to start the conversation!
>
Hi hc,
Thanks for helping to start the conversation!
On February 21, 2023 2:38:14 PM UTC, Hans-Christoph Steiner
wrote:
>
>If the test passes regularly, and just sometimes fails under the same
>conditions, I would consider disabling it in autopkgtest rather than have it
>not make it into bo
If the test passes regularly, and just sometimes fails under the same
conditions, I would consider disabling it in autopkgtest rather than have it not
make it into bookworm. The perfect is the enemy of the good.
.hc
Olek Wojnar:
Fellow Bazel contributors (and Java Team members),
I've dis
15 matches
Mail list logo