Le 06/04/2024 à 17:10, Thorsten Glaser a écrit :
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.
Got caught by the mailing list police, doh! ;) Not need to invent
mailing list rules
already provides a package.
Emmanuel Bourg
, in this case you
want the plugin dependencies to appear in the Depends field of the package.
Emmanuel Bourg
there are zlib-related bugs reported against JRuby which
may lead to further changes in jruby-jzlib, see
https://github.com/jruby/jruby/issues/6613
Good point. If the code diverges significantly an independent package is
perfectly justified then.
Emmanuel Bourg
s of jzlib (org.jruby:jzlib -> com.jcraft:jzlib).
Emmanuel Bourg
[1] https://github.com/jruby/jzlib
in
experimental. If you want to test the compatibility with Java 21 you can
install default-jdk from experimental, it will switch the default JDK to
Java 21 and update the java_compat_level macro.
Emmanuel Bourg
the -source/-target options rather than
removing them, it extends the lower bound of the Java versions range
usable with the package.
Emmanuel Bourg
.
Emmanuel Bourg
the flexibility of an imperative build
system (and Ant is by far the easiest to bootstrap).
Emmanuel Bourg
Le 25/09/2023 à 22:17, Sean Gilligan a écrit :
Hi Everyone,
I appreciate the efforts of the Debian Java team and know that your job
is not easy.
I work on bitcoinj (Java) and we are (for better
bugs
from the list.
Emmanuel Bourg
are a
recurrent source of issues when migrating to more recent JDKs, and they
are almost never used.
Emmanuel Bourg
Hi Guillem,
On 31/08/2023 02:23, Guillem Jover wrote:
So I guess it should be fine to rip that off?
Yes go ahead, GCJ is long dead and gone, you can remove the remaining
references safely.
Emmanuel Bourg
address.
Emmanuel Bourg
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
and should
especially not be used in new places.
Alioth is no longer maintained, but the old lists.alioth.debian.org
addresses have been preserved and should still be used.
Emmanuel Bourg
(for example Tomcat uses the Eclipse JDT compiler, BiglyBT
uses Eclipse SWT). That's why there are several eclipse-platform-*
packages, but that doesn't mean you can install the Eclipse IDE from them.
Emmanuel Bourg
On 26/04/2023 22:01, Gervase wrote:
Currently, I have access to the packages
-*
packages in unstable now use jtreg6. So I suggest upgrading the unused
jtreg package to the version 7 instead of creating a new package.
Emmanuel Bourg
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
Le 2023-02-23 12:48, Thorsten Glaser a écrit :
How about asking Doko to locally add that parameter to 17 as a
Debian-specific patch, just ignoring it?
Patching the JDK is overkill, it's just a flag to change in a script.
The question is, where is this script?
Emmanuel Bourg
for OpenJDK 8 (with a dedicated
ca-certificate-java8 package maybe). This way installing openjdk-17
would not drag in python dependencies.
Emmanuel Bourg
Le 2023-02-07 20:12, Vladimir Petko a écrit :
Dear Maintainers,
Would it be possible to consider a proposal to break dependency of
ca
to be wrong about that. :)
This is really just an optimization parameter, I don't think this is
a critical issue. There is probably a UseParallelOldGC parameter left
somewhere in the bazel source files. I can't find it on codesearch [1],
maybe in a zip extracted at build time?
Emmanuel Bourg
[1]
https
be to port to the new API
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011567
Another solution, maybe simpler: package the com.sun.javadoc API
in a standalone package, independent from openjdk-8
Emmanuel Bourg
Le 2023-02-10 18:07, Thorsten Glaser a écrit :
The MIPS buildds are at it currently and expected to finish soon,
in case you still want to go forward. It’s close to soft freeze.
It's still building but that's fine, we won't need openjdk-8
for kotlin, the beast has been tamed.
Emmanuel Bourg
The 'may' requirement for the suffix is very weak. The Lintian
repackaged-source-not-advertised warning should be downgraded
to pedantic.
Our time is limited, let's focus on important things.
Emmanuel Bourg
packaged and needs to be modified afterward
because unwanted files were included by mistake.
Emmanuel Bourg
that was possible.
Emmanuel Bourg
:
com.fasterxml.jackson.core jackson-annotations * s/.*/2.x/ * *
Emmanuel Bourg
the packaging type from bundle to jar, or ignore
the parent pom, just to get the initial run of mh_make to complete
without error.
Emmanuel Bourg
Le 2023-01-26 17:17, Emmanuel Bourg a écrit :
I've been working on Kotlin lately, trying to make it build with
OpenJDK 17
only, and hopefully have it included in Bookworm.
Long story short, after days banging my head on this issue, I don't
think
it's possible.
I take that back, kotlin now
transition to testing now before the
beginning of the soft freeze, just to keep our options open. We won't
expand the usage of kotlin during that time (no Gradle upgrade for
example)
such that the situation remains reversible before the release.
Emmanuel Bourg
community for the lifetime of Bookworm.
How do you feel about allowing openjdk-8 in testing/bookworm with a
clear
mention in the release notes that it's only there for technical reasons
and
we make no commitment about its support?
Emmanuel Bourg
[1] https://packages.ubuntu.com/source/kinetic
Hi,
It looks like the missing methods have moved to
org.eclipse.core.internal.runtime.AuthorizationHandler.
We could either add them back to the Platform class, or patch the
affected packages
to call the AuthorizationHandler methods.
Emmanuel Bourg
Le 2023-01-22 09:40, Pierre Gruet a écrit
Le 2021-04-19 16:33, Emmanuel Bourg a écrit :
I'm still making progress and I'm now at the version 0.8.409.
I've started a GitHub project detailing the full build procedure from
Kotlin 0.6.786 to 0.8.409:
https://github.com/ebourg/kotlin-bootstrapping
Follow up on the Kotlin
hanges
files of java-common and openjdk-17
- relax and grab some popcorn
- cry because you forgot to use 'screen'
- analyze the build logs, looking for unexpected failures compared to
amd64 (reproducible-builds.org [1] has a good summary of the know build
issues)
Emmanuel Bourg
[1]
https://tests
Hi Alban,
Did you try this rule:
grant codeBase "file:/etc/tomcat9/-" {
permission java.security.AllPermission;
};
Emmanuel Bourg
Le 22/12/2022 à 11:05, Alban Espié-Guillon a écrit :
Hello,
I'm very new to tomcat, forgive me if I did not found my answer
elsewhere, i'm cur
Hi Tomas,
Jetty 11 is unlikely to be included in Bookworm. It may come later as a
backport though. In the meantime, you can also use Tomcat 10 which will
be part of the next Debian release.
Emmanuel Bourg
Le 13/12/2022 à 01:36, Tomas Potok a écrit :
Hello!
May I ask about any plans
Le 28/09/2022 à 17:53, Emmanuel Bourg a écrit :
Pros:
- no need to create a new package, replacing tomcat with tomcat
everywhere, and then wait for the NEW queue
- unique packaging repository
- no more transition, replacing the libtomcat-java dependency with
libtomcat-java everywhere
at9.
I would just suggest dropping the current tomcat10 repository on Salsa
and starting with a fresh clone of the latest tomcat9 repository, from
the 9.0.70 release (and with the full history preserved).
Let me know if you need any help.
Emmanuel Bourg
Le 12/12/2022 à 00:40, Markus Kosch
with the versioned java-runtime dependency.
Emmanuel Bourg
java-runtime, that's not a huge constraint. And I
expect the openjdk security updates to introduce the java-runtime (= n)
provides in stable/oldstable, so that may no be even necessary.
Emmanuel Bourg
me. So even with:
default-jre (>= 2:1.11) | java11-runtime
there is no guarantee Java 11 will be used.
If you want Java 11 only, you'll be able to depend on:
openjdk-11-jre | java-runtime (= 11)
Emmanuel Bourg
de before using the
versioned java-runtime dependency in the packaged applications, what
issue do you foresee?
Emmanuel Bourg
with the Bookworm release timeline.
That's fine with me (if doko continues to update it in unstable) (and if we
again only have 17 as the default + 21 preview/secondary JRE). And 11 not in
testing.
Thank you Moritz. I've filed #1023237 to get openjdk-11 removed from
testing.
Emmanuel Bourg
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
- if if not, clone the package to keep the previous version (we had to
do this with antlr 3.2)
Good luck!
Emmanuel Bourg
.
The default libtomcat-java package is a good idea.
Thank you for sharing your thoughts!
Emmanuel Bourg
be Doko,
could be someone else) commits to maintaining it. If nobody does, Scala
and Kotlin are SOL.
I don't mind for Scala, but Kotlin can't be ignored unfortunately. Its
integration into Gradle makes it an essential part of the Java ecosystem.
Emmanuel Bourg
able after the transition to OpenJDK 17.
Emmanuel Bourg
[1]
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=default-java17;users=debian-java@lists.debian.org
ay forget to upgrade it and will keep an
unsupported instance that is no longer receiving security updates.
What do you think?
Emmanuel Bourg
;Require-Bundle".
What about changing the version in libgeronimo-annotation-1.3-spec-java
instead? The Eclipse source packages publish 120+ binary packages, if we
start tweaking manually their OSGi metadata to fit what we have in
Debian this will turn into a maintenance nightmare.
Emmanuel Bourg
.
The watch file doesn't limit to 5.x releases:
https://sources.debian.org/src/javacc5/5.0-10/debian/watch/
Yes, because there is no 5.x release tagged in the upstream repository :(
Emmanuel Bourg
isn't worth the trouble, and I'd instead amend the policy to
accept what has been done de facto for years.
Emmanuel Bourg
;Java Policy for Debian."
"Debian Policy for Java" or "Java Policy for Debian", which one is correct?
Emmanuel Bourg
Le 15/10/2021 à 15:17, Andrius Merkys a écrit :
> Not sure though what is the impact of this policy inversion. Most of
> Java-related software seems to read both regular files and symbolic
> links transparently.
There isn't much impact, both styles are fine in my opinion.
Emmanuel Bourg
LR creates regressions, we just clone
the package to preserve the old version. That's the only sane solution,
because you really don't want to test, debug and fix grammars with an
incompatible version of ANTLR, that's the reponsability of the upstream
developers.
Emmanuel Bourg
, the packages are independent and are free to evolve as
needed
without impacting the others. An unified package will only bring pain
and tears,
and distract us from more important topics (like the OpenJDK 17
transition,
the Kotlin packaging or the Gradle upgrade).
Emmanuel Bourg
, each language team having the freedom to
maintain its version as needed without impacting the others.
Emmanuel Bourg
Le 26/07/2021 à 05:03, Paul Wise a écrit :
> Since tomcat9 was released in buster a long time ago,
> is it now time to remove tomcat8 from Debian experimental?
Yes no objection.
Emmanuel Bourg
binary package should be 'libstringprep-java'.
There is no absolute rule but personally I tend to prefer the upstream
project name for the source package (if it isn't too generic or confusing).
Emmanuel Bourg
'1.3.31+~cs1.11.13', but that does
not
support uscan --download-current-version which is needed until we can
bump them all to their latest tags.
If the '+' is required, maybe mangling the kotlin version would work?
Something like this for example:
1.3.31~bootstrap+~cs1.11.13
Emmanuel Bourg
all the jar files downloaded by debian/bootstrap rebuilt? None
is copied directly into the stage 2 .deb, right?
Emmanuel Bourg
reconnect with them to provide the bootstrap compiler, or
certify later that both approaches produce the same binaries.
Emmanuel Bourg
Le 06/04/2021 à 09:40, Emmanuel Bourg a écrit :
> There are missing symbols when building the first 0.7.x tag, I'm still
> working on it.
I'm still making progress and I'm now at the version 0.8.409.
I've started a GitHub project detailing the full build procedure from
Kotlin 0.6.786 to 0
ank you for the work.
Emmanuel Bourg
k this isn't very useful, it's more a waste of
resources since I've already built the packages locally before pushing
the changes to Salsa. In an era of digital sobriety I prefer to keep it
turned off. And it's also a source of spam on the IRC channel.
Emmanuel Bourg
Le 02/04/2021 à 22:56, Emmanuel Bourg a écrit :
> Step 5: how to build Kotlin 0.6.2350 ???
I have the next steps, the decompiler code was refactored in the SDK in
the commit f6c6bec7361fba61ecb3aa955e4145a789d4ed97, and this wasn't
used until Kotlin 0.6.2443. Kotlin 0.6.2350 builds with Kot
lin 0.6.1364
Step 3: build Kotlin 0.6.2052
Step 4: build Kotlin 0.6.2107 (good up to Kotlin 0.6.2338).
Step 5: how to build Kotlin 0.6.2350 ???
If someone figures out the next step, or has any hint about the last
error, please ping me :)
Emmanuel Bourg
building with
the latest openjdk-8 package from snapshot.debian.org and doing a binary
upload.
Emmanuel Bourg
d it
back.
Emmanuel Bourg
Le 24/03/2021 à 21:29, Sunil Mohan Adapa a écrit :
> openjdk-8 appears to been removed from unstable recently[1][2].
Sorry I misunderstood your message, I didn't realize it got kicked
already :(
Emmanuel Bourg
o help with the bootstrapping of Kotlin. Until the
kotlin package builds fine with openjdk-11 it's premature to consider
the removal of openjdk-8.
Emmanuel Bourg
uired? My understanding is that it merely
provides build time improvements and some code/build reports. I guess it
could be simply disabled.
Emmanuel Bourg
that's
useless.
Emmanuel Bourg
affected.
Do you wish to upload this yourself or should I?
I'll upload it with the next monthly update.
Emmanuel Bourg
rate was
around 85%. There were many trivial build issues (javadoc errors,
language level to change from 6 to 7) so the runtime compatibility is
likely to be higher. I've filed the issues in the BTS:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=default-java17;users=debian-java@lists.debian.org
Emmanuel Bourg
m copying of this
> openjdk-17 sources and binaries for all architectures from bookworm
> to bullseye-backports.
>
> Subsequent updates of openjdk-17 in bullseye-backports would then follow
> the normal backports rules.
If openjdk-17 can't be shipped in bullseyes even with prominent warnings
that it's unsupported, then this sounds like a good idea.
Emmanuel Bourg
- geronimo-jacc-1.1-spec
> - libaxiom-java
> - netty
These packages (minus euca2ools) are already handled by the Java Team,
we'll change the uploaders in the next uploads.
Emmanuel Bourg
eclipse-collections source package building
libeclipse-collections-java. The gs-collections repository on Salsa can
be cloned and used as a starting point for the new package.
Emmanuel Bourg
Le 07/01/2021 à 01:56, Vincent Prat a écrit :
> Dear all,
>
> The latest version of NatTable (2.0.0
t; the update wouldn't break things right and left, as I'm not.
Hi Louis-Philippe,
I've updated mustache-java to the version 0.9.1, it no longer depends on
jruby.
Emmanuel Bourg
endencies are properly set
to ensure a smooth backporting. Go ahead, if it breaks I'll look into it.
Emmanuel Bourg
Le 29/12/2020 à 01:46, Sudip Mukherjee a écrit :
> So, I will wait for any other objection or Ack till tomorrow night and
> then upload.
Thank you for spotting issue. Please go ahead and upload the fix.
Emmanuel Bourg
f more people find this approach useful, this could become official
> some day.
This could be very useful to get openjdk-8 in buster.
Emmanuel Bourg
ething…
Yes it does (for example jetty9, javamail or maven itself) but there are
edge cases that require some tweaking of the poms (typically when the
project uses OSGi bundles and with convoluted submodule layouts).
Emmanuel Bourg
age in a couple of weeks. Going
the official Debian archive route takes a lot more time and you're tied
by the Debian release schedule and update policy. If the application is
mature and stable it works well, but it can become frustrating if it
evolves quickly.
Emmanuel Bourg
dance on
how to structure the package and ensure it plays well with the Java
ecosystem in Debian.
Emmanuel Bourg
[1] https://github.com/tcurdt/jdeb
Hi Pierre,
I think the Maintainer field of debian/control should reference the Java
Team.
Emmanuel Bourg
On 14/11/2020 07:37, Pierre Gruet wrote:
> Hi,
>
> I have worked on libjaba-client-java, with the further aim to revive
> jalview in Debian. Would you mind either reviewing [
Hi Pierre,
There is a minor mistake with the email address of the Java team in
debian/control:
pkg-java-maintain...@alioth-lists.debian.net
should be replaced by:
pkg-java-maintain...@lists.alioth.debian.org
Emmanuel Bourg
On 03/11/2020 07:46, Pierre Gruet wrote:
> Hi,
>
&g
and test it thoroughly).
Emmanuel Bourg
from
feature.xml file and use.
Yes there is, we can use xmlstartlet:
xmlstarlet sel -t -v '//feature/@version'
features/org.eclipse.equinox.executable.feature/feature.xml
I've pushed the modification to the sudip/jni branch with a few other
changes.
Emmanuel Bourg
' for this change.
Can you please have a look at the branch when you get some time..
I think the version should be picked from the feature.xml file, so the
package would have the version 3.8.900+eclipse4.17-2.
Emmanuel Bourg
iated -java
package. The version of the eclipse packages is heavily tinkered to use
the OSGi bundle version instead of the tag version. So you'll need a
tweak in debian/rules for the jni package. I can get a look before you
upload if you aren't sure to do it right.
Emmanuel Bourg
.
For
instance the platform packages are needed for visualvm. I believe
maintaining this package is viable.
It sounds good, as long as visualvm is preserved that's fine for me.
Emmanuel Bourg
such as Netbeans or Eclipse I tend to think the community
would be better served with flatpak packages (it would be nice to have a
pure Java toolchain generating these packages), and for complex server
side applications a .deb package simply generated by jdeb would be fine.
Emmanuel Bourg
[1] ht
t. Any taker?
Emmanuel Bourg
Hi Ole,
I've added you to the group. Please try to use this script
to create the new repository:
https://salsa.debian.org/java-team/pkg-java-scripts/raw/master/setup-salsa-repository
Emmanuel Bourg
On 25/08/2020 10:33, Ole Streicher wrote:
> Hi,
>
> I think that I was in the te
le/common/jimfs/PathService.java:[290,30]
> error: is not abstract and
> does not override abstract method test(Object) in Predicate
Have you tried setting the source/target level to Java 8?
Just add this to debian/maven.properties:
maven.compiler.source=8
maven.compiler.target=8
Emmanuel Bourg
s team
> maintained.
>
> Is NMU correct or shall I cancel that and do a normal "Team upload" instead ?
You can team upload this one just like I did the last time I updated it,
but it isn't that important if you uploaded a NMU instead. Just ensure
that your changes are pushed to the Sa
tion. Otherwise it raises a doubt
that something important may have been removed, and that's not the case
when the project was merely cleaned from unwanted build files.
> Could you please remove the now unused Git repository in Salsa to avoid
> confusion?
Done
Emmanuel Bourg
ven properly interlinked.
Emmanuel Bourg
On 25/07/2020 08:39, Emmanuel Bourg wrote:
>> Could someone please review and sponsor it when time permits?
>
> Hi Pierre, I'll take care of it.
The package has been uploaded and is now in the NEW queue.
Technically the package was good, I just made a few minor changes:
- I've remo
1 - 100 of 1775 matches
Mail list logo
