Le mercredi 18 juin 2025 10:43:31 CEST, vous avez écrit :
> On 17/06/2025 20:55, Fab Stz wrote:
> > Could the package be updated to a newer version?
>
> The Netbeans IDE was removed 5 years ago and there is no plan to
> reintroduce it, so yes go ahead.
Ok. Can I directly push t
On 17/06/2025 20:55, Fab Stz wrote:
Could the package be updated to a newer version?
The Netbeans IDE was removed 5 years ago and there is no plan to
reintroduce it, so yes go ahead.
Emmanuel Bourg
Hello,
I'm adding debian-java@l.d.o because update of libhtml5parser-java is required
for vnu (validator.nu: a html5 validator).
The changelog of libhtml5parser-java mentions that the package was downgraded
to 1.3.1 because of issues with netbeans
* Imported Upstream version 1.4+r
Hi Andreas,
Thank you for the update.
On 23/02/2025 22:03, Andreas Tille wrote:
Hi,
I've uploaded plexus-cli with fixed metadata. I've also fixed the watch
file which lists several new upstream versions. Unfortunately I did not
managed to build the latest version as you can see i
Hi,
I've uploaded plexus-cli with fixed metadata. I've also fixed the watch
file which lists several new upstream versions. Unfortunately I did not
managed to build the latest version as you can see in Salsa CI[1]. If
someone might manage to fix this it makes probably sense to have
Source: libjgroups-java
Version: 2.12.2.Final-5
Severity: normal
X-Debbugs-Cc: 867...@bugs.debian.org, debian-java@lists.debian.org
Hi,
when fixing Vcs fields in libjgroups-java I realised that the Debian packaged
version is lagging behind several major upstream versions. It has an open
CVE
Source: libjaudiotagger-java
Version: 2.0.3-3
Severity: normal
X-Debbugs-Cc: debian-java@lists.debian.org, Varun Hiremath ,
Torsten Werner
Hi,
when upgrading metadata of libjaudiotagger-java and fixing two bugs I
noticed there is a new makor upstream version. Since it needs new
dependencies I
Source: libimglib2-java
Version: 4.5.0-1
Severity: normal
X-Debbugs-Cc: Ghislain Antony Vaillant ,
debian-java@lists.debian.org
Hi,
when trying to update the metadata of libimglib2-java I noticed that Debian
is lagging behind upstream several major versions. Since at least one not
yet packaged
Source: libhibernate-commons-annotations-java
Version: 3.2.0.Final-4
Severity: normal
X-Debbugs-Cc: debian-java@lists.debian.org, Torsten Werner
, Varun Hiremath
Hi,
when upgrading the Vcs fields and other packaging metadata of
libhibernate-commons-annotations-java I realised that we are
Source: kxml2
Version: 2.3.0+ds1-2.1
Severity: wishlist
X-Debbugs-Cc: Damien Raude-Morvan , Jakub Adam
, debian-java@lists.debian.org
Hi Jakub,
I rnoticed that you have added yourself to Uploaders of kcml2[1]. I
just did a team upload with Updated Vcs fields and modernised packaging.
You-or
Source: knopflerfish-osgi
Version: 6.1.1-3.1
Severity: wishlist
X-Debbugs-Cc: Felix Natter , debian-java@lists.debian.org
Hi,
when trying to upgrade the packaging of knopflerfish-osgi I realised
there is a new upstream version available. I admit I'm not sure whether
there are
Source: jmock
Version: 1.2.0-5.1
Severity: wishlist
X-Debbugs-Cc: debian-java@lists.debian.org
Hi,
when inspecting jmock to fix Vcs fields I also fixed the watch file and
realised Debian is lagging way behind upstream. Since the new version has
lots of changes I hesitated to even try upgrading
Source: jhighlight
Version: 1.0-3.1
Severity: normal
X-Debbugs-Cc: debian-java@lists.debian.org
Hi,
when inspecting jhighlight due to missing Vcs fields I realised that the
project has moved. I updated the watch file and uploaded the existing
package with the current Debian version. After this
Source: jeromq
Version: 0.3.6-1.1
Severity: wishlist
X-Debbugs-Cc: debian-java@lists.debian.org
Hi,
when working on the jeromq package to fix Vcs fields and upgrading to
latest packaging I realised that upstream meanwhile has released some
new versions. It seems the packaging of the latest
Source: jctools
Version: 2.0.2-1
Severity: normal
X-Debbugs-Cc: debian-java@lists.debian.org
Hi,
I inspected jctools packaging since its Vcs fields needed upgrading and
uploaded the package with refreshed metadata. I also tried upgrading to
latest upstream (we are lagging behind two major
Source: java-comment-preprocessor
Version: 6.0.1-1.1
Severity: normal
X-Debbugs-Cc: Debian Java List
Hi,
I had a look into java-comment-preprocessor and at least polished the
packaging including setting Vcs fields properly. I also tried to work
on the latest upstream version. Unfortunately I
Source: jasmin-sable
Version: 2.5.0-2
Severity: minor
X-Debbugs-Cc: debian-java@lists.debian.org
Hi,
after polishing the packaging of jasmin-sable (fixing Vcs fields, fix a
simple bug etc.) I realised there is a new upstream version. After
injecting it into Git I had to confess that my skills
Hi,
I had a look into triplea and at least polished the packaging including
setting Vcs fields properly. I also tried to work on the latest
upstream version which includes fixing the CVE issue. Unfortunately I
did not managed to build the package successfully. You can see the
build result in
Source: htrace
Version: 3.1.0-2.1
Severity: minor
X-Debbugs-Cc: debian-java@lists.debian.org
Hi,
I've updated the packaging of htrace and uploaded htrace 3.1.0-3 with an
updated watch file. The upstream web page states that the project is
retiered but the latest release is way younger a
Source: janino
Version: 2.7.0-2.1
Severity: minor
X-Debbugs-Cc: debian-java@lists.debian.org
Hi,
I just uploaded janino 2.7.0-3 with lots of fixes including a fixed
watch file. There are lots of new upstream versions issues inbetween
and it would probably great to have the latest (or at least
Source: libajaxtags-java
Version: 1.5.1-3.1
Severity: wishlist
X-Debbugs-Cc: Debian Java Maintainers
, Torsten Werner
, debian-java@lists.debian.org
Hi,
I have fixed the watch file in my recent upload (1.5.1-4) which shows
upstream has 1.5.5. I've injected this into Git but the build
Hi,
On 23-01-2025 09:26, Julien Plissonneau Duquène wrote:
These issues are currently being discussed on debian-java [1].
Would a britney hint or something be appropriate here? We believe that
these reverse dependencies should not block these migrations.
If RC bugs have been filed for all re
Hi Paul,
These issues are currently being discussed on debian-java [1].
Would a britney hint or something be appropriate here? We believe that
these reverse dependencies should not block these migrations.
Cheers,
[1]: https://lists.debian.org/debian-java/2025/01/msg00012.html
--
Julien Pli
Control: tags -1 help
Thanks
Hi,
I injected the latest upstream version into Git. Unfortunately there
are build errors as you can see in Salsa CI[1]
Any help would be welcome
Andreas.
--
https://fam-tille.de
Emmanuel Bourg
On 12/01/2025 21:16, Pierre Gruet wrote:
Hi Emmanuel, and everyone,
I noticed that the new upstream version of maven-resolver, uploaded to
sid 27 days ago, failds to migrate because of two failing autopkgtests
in rdeps [0]. Also it is the root of #1091067 in scala, which w
wrote:
Hi Emmanuel, and everyone,
I noticed that the new upstream version of maven-resolver, uploaded to
sid 27 days ago, failds to migrate because of two failing autopkgtests
in rdeps [0]. Also it is the root of #1091067 in scala, which would
cause its autoremoval in a few weeks.
Do you have any g
Control: block -1 by 1092925
Thanks
I've filed a RFP bug since the latest version of felix-framework needs
moditect but unfortunately I have no capacity to package this. Any
volunteer is welcome.
The other open bugs of felix-framework are fixed in Git. You can see
a build log of the l
Hi Emmanuel, and everyone,
I noticed that the new upstream version of maven-resolver, uploaded to
sid 27 days ago, failds to migrate because of two failing autopkgtests
in rdeps [0]. Also it is the root of #1091067 in scala, which would
cause its autoremoval in a few weeks.
Do you have any
Hello Gregor,
Am Montag, 6. Januar 2025, 02:56:15 CET schrieben Sie:
> On Fri, 03 Jan 2025 23:47:15 +0100, Helmar Gerloni wrote:
>
> > I just uploaded version 1.6.6 to salsa:
> > https://salsa.debian.org/helger/tuxguitar
> > Maybe you can push this new version into Si
Hello Tony,
thanks for your help! I just uploaded the new version 1.6.6 to mentors:
https://mentors.debian.net/package/tuxguitar/
Regards, Helmar.
Am Montag, 6. Januar 2025, 02:39:10 CET schrieb tony mancill:
> Hello Helmar,
>
> On Fri, Jan 03, 2025 at 11:47:15PM +0100, Helma
On Fri, 03 Jan 2025 23:47:15 +0100, Helmar Gerloni wrote:
> I just uploaded version 1.6.6 to salsa:
> https://salsa.debian.org/helger/tuxguitar
> Maybe you can push this new version into Sid?
It looks like the master branch is updated but the upstream and
pristine-tar branches are still
Hello Helmar,
On Fri, Jan 03, 2025 at 11:47:15PM +0100, Helmar Gerloni wrote:
> I just uploaded version 1.6.6 to salsa:
>
> https://salsa.debian.org/helger/tuxguitar
>
> Maybe you can push this new version into Sid?
I review and sponsor the upload of 1.6.6.
> Just let me k
Hello Gregor,
thanks for importing version 1.6.4 of tuxguitar into salsa.
I just uploaded version 1.6.6 to salsa:
https://salsa.debian.org/helger/tuxguitar
Maybe you can push this new version into Sid?
> What's a bit sad is that tuxguitar doesn't build reproducibly.
I did not
Hi
How to i help you for packaging a newer upstream version ?
--
Regards,
Lilian.
Le 07/02/2024 à 08:55, Andrej Shadura a écrit :
Hi,
On Wed, 7 Feb 2024, at 00:51, Alejandro Rosso wrote:
Current version in Debian is close to be 4 years outdated and it seems
that updating it will fix some
Hi,
On Wed, 7 Feb 2024, at 00:51, Alejandro Rosso wrote:
> Current version in Debian is close to be 4 years outdated and it seems
> that updating it will fix some CVE bugs.
You’re welcome to help packaging a newer upstream version or backporting the
fixes :)
--
Cheers,
Andrej
Hi Hideki,
Le 08/10/2023 à 05:25, Hideki Yamane a écrit :
Thank you, and how about adding java_compat_level=8 for Java21?
Since some FTBFS reports are there.
https://salsa.debian.org/java-team/java-common/-/merge_requests/3
java_compat_level=8 is supported in java-common/0.75+exp1 in
e
Hi,
On Thu, 5 Oct 2023 01:26:11 +0200
Emmanuel Bourg wrote:
> I've just uploaded java-common/0.75 with a new java_compat_level
> variable if you want to give it a try:
>
>#!/usr/bin/make -f
>
>include /usr/share/java/java_defaults.mk
>
>build:
>javac -source $(java_co
Le 05/10/2023 à 01:07, Hideki Yamane a écrit :
We should probably provide the minimum language level supported as a
variable in the /usr/share/java/java_defaults.mk file from java-common.
Nice, each Java packages do not need to care about which level
should use and drop it safely, then?
Hi,
On Wed, 4 Oct 2023 19:49:44 +0200
Emmanuel Bourg wrote:
> We should probably provide the minimum language level supported as a
> variable in the /usr/share/java/java_defaults.mk file from java-common.
Nice, each Java packages do not need to care about which level
should use and drop it sa
Le 04/10/2023 à 13:36, Hideki Yamane a écrit :
Well, is there any text / document to use which version should be
used for -source and -target version, or is just dropping those options
allowed?
For Java 17 the minimum was 7, and with Java 21 the minimum is 8. For
packages using ant
Hi,
Some of Java packages are FTBFS with Java21 due to javac -source and -target
version is lower than that is supported in Java21.
Well, is there any text / document to use which version should be
used for -source and -target version, or is just dropgping those options
allowed?
Maybe I
Your message dated Sun, 02 Jul 2023 22:39:05 +
with message-id
and subject line Bug#1040167: fixed in openjdk-8 8u382~b04-2
has caused the Debian Bug report #1040167,
regarding openjdk-8-jre-headless: version 8u382~b04-1 depends on libjpeg8 which
is not in Debian
to be marked as done.
This
Your message dated Sun, 02 Jul 2023 21:49:53 +
with message-id
and subject line Bug#1040167: fixed in openjdk-8 8u382~b04-2~binfix1
has caused the Debian Bug report #1040167,
regarding openjdk-8-jre-headless: version 8u382~b04-1 depends on libjpeg8 which
is not in Debian
to be marked as done
/2.2.9 (2022-11-12)
Date: Sun, 2 Jul 2023 23:02:38 +0200
Subject: Re: Fwd: (buildd chroot bug) Re: Bug#1040167: openjdk-8-jre-headless:
version 8u382~b04-1 depends on libjpeg8 which is not in Debian
Message-ID:
[ tl;dr for buildd-maintainers: nothing to do. ]
Hi,
On 2023-07-02 21:44, Thorsten
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
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
Package: openjdk-8-jre-headless
Version: 8u382~b04-1
Severity: important
Dear Maintainer,
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
However libjpeg8 is not to be found in Debian
Expected
Hi Gregor,
>From what I've seen of the java-wrappers package, it seems to solve the problem
in a single direction: specifying the minimum JVM's version, but not the
maximum.
That was one of the remark of Thorsten to me.
The more I think about it, the more I think it is not a
Processing commands for cont...@bugs.debian.org:
> close 1035340
Bug #1035340 [openjdk-8-jdk] latest openjdk-8-jdk version 8u372-b07 is not
available
Marked Bug as done
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
1035340: https://bugs.debian.org/c
package: openjdk-8-jdk
version: latest
When I invoke `apt-get update && apt-get install openjdk-8-jdk` it is
installing an older version of jdk-8 which is 8u362-b09.
Jdk version 8u372-b07 is not getting installed while running the `apt-get
install openjdk-8-jdk` even after running the
On Wed, 19 Apr 2023 09:48:54 +, Loïc Rouchon wrote:
> Debian would need to provide a way to perform the "JRE with exact java
> $version exists"
> check. This could be done by providing stable symlinks, or alternatives like
> /etc/alternatives/jre_
(I haven't
tch
# else try every other supported version
for version in 17 16 15 14 13 12 11; do
if [ JRE with exact java $version exists ]; then
JAVA_HOME=...
fi
done
Debian would need to provide a way to perform the "JRE with exact java $version
exists"
check. This could be done by provi
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 vers
Hi,
> I’m a bit wary of auto-selecting something. I’d instead check whether
> ${JAVA:-java} has the right version and complain when not. Possibly
> check whether $JAVA_HOME is set (which it isn’t in a regular Debian
> one-JRE installation) and use that if suitable instead of complaini
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 co
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.
I could imagine it might not want to just rely on /usr/bin/java because
you might not want it to break if the system has 8 and 11 i
Hi Emmanuel,
Le 22/01/2023 à 10:44, Emmanuel Bourg a écrit :
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 method
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
Hello everyone,
Two weeks ago, eclipse-platform-runtime 4.26 entered testing, entailing
the removal of some methods in
org.eclipse.core.runtime.Platform
which raised the RC bug #1028768 in its rdep svnkit. As a consequence,
many reverse dependencies will get removed and not make it to Boo
On Fri, Jan 21, 2022 at 01:37:10PM +0100, Mathieu Malaterre wrote:
> [cc me please]
>
> Hi there,
>
> I am trying to update xmlgraphics-commons but I fail to understand
> what is going on with:
>
> % uscan --download --force-download --rename
> uscan: Newest versio
[cc me please]
Hi there,
I am trying to update xmlgraphics-commons but I fail to understand
what is going on with:
% uscan --download --force-download --rename
uscan: Newest version of xmlgraphics-commons on remote site is 2.7,
local version is 2.6
uscan: => Newer package available f
Happy to report that kotlin just made it into unstable.
https://tracker.debian.org/pkg/kotlin >
--
Happy hacking
Petter Reinholdtsen
14:12, Phil Morrell wrote:
>
>> On Tue, Sep 14, 2021 at 11:59:55PM +0200, Philippe De Neve wrote:
>> > I was wondering why the Gradle version in buster/bullseye/bookworm/sid
>> is
>> > 4.4.1. Latest release is 7.2.
>>
>> Gradle 4.4.1 is the lates
are on the
remove_enterprise_features branch, which is on top of the 7.2.0 release
commit.
Best regards,
Philippe
On Wed, 15 Sept 2021 at 14:12, Phil Morrell wrote:
> On Tue, Sep 14, 2021 at 11:59:55PM +0200, Philippe De Neve wrote:
> > I was wondering why the Gradle version in buster/bull
On Tue, Sep 14, 2021 at 11:59:55PM +0200, Philippe De Neve wrote:
> I was wondering why the Gradle version in buster/bullseye/bookworm/sid is
> 4.4.1. Latest release is 7.2.
Gradle 4.4.1 is the latest version before kotlin was added as a
build-dependency, which has been a known problem sinc
Hi,
On 2021-09-15 00:59, Philippe De Neve wrote:
> I was wondering why the Gradle version in buster/bullseye/bookworm/sid
> is 4.4.1. Latest release is 7.2.
Please see these bug reports for reference:
https://bugs.debian.org/926714
https://bugs.debian.org/933264
Best,
Andrius
Hi,
I was wondering why the Gradle version in buster/bullseye/bookworm/sid is
4.4.1. Latest release is 7.2.
Thanks,
Philippe De Neve
On Sun, Sep 27, 2020 at 01:47:06PM +0100, Sudip Mukherjee wrote:
> On Sun, Sep 27, 2020 at 12:01 PM Emmanuel Bourg wrote:
> >
> > On 27/09/2020 00:23, Markus Koschany wrote:
> >
>
> >
> > > Why don't we just create more or less official (even though not really
> > > perfect) Debian packages for n
On Sun, Sep 27, 2020 at 12:01 PM Emmanuel Bourg wrote:
>
> On 27/09/2020 00:23, Markus Koschany wrote:
>
>
> > Why don't we just create more or less official (even though not really
> > perfect) Debian packages for netbeans, eclipse, solr, hadoop, etc. by
> > using tools like jdeb [1] for ant and
On 27/09/2020 00:23, Markus Koschany wrote:
> from my point of view we need to package at least
>
> hadoop-common-3.2.0.jar
> hadoop-annotations-3.2.0.jar
> hadoop-hdfs-client-3.2.0.jar
> hadoop-auth-3.2.0.jar
I did package hadoop 2.6 a few years ago if someone wants to continue
the work [1]. Th
Hi tony,
[adding only Waldemar to CC because we are subscribed to the list anyway]
> Can you post a list of what others can help with?
I have made my list a few months ago and just looked into it again.
1.
First of all as of version 9.0 solr will use gradle as the new build
system. This
On Sat, Sep 26, 2020 at 03:40:39PM +0200, Markus Koschany wrote:
> In short: 3.6.2 will not be released again, 8.x could make it into
> Debian 11 but there is a big question mark at the moment, more help is
> appreciated.
Hi Markus,
Can you post a list of what others can help with?
Cheers,
tony
Hi,
i am currently working on a project running on a Debian 10 server. The project
needs a Solr server. I have installed the solr-tomcat and found that the
version of Solr is very outdated. The version is 3.6.2, the current Solr
version on the project page is version 8.6.2.
Is the version
Hello,
Am 26.09.20 um 14:51 schrieb Waldemar Zahn:
> Hi,
>
> i am currently working on a project running on a Debian 10 server. The
> project needs a Solr server. I have installed the solr-tomcat and found that
> the version of Solr is very outdated. The version is 3.6.2, t
HI Emmanuel,
I was trying to use libswt-gtk-4-java for #943552 and I get the error:
Unresolved requirement: Require-Bundle: org.eclipse.swt;
bundle-version="[3.111.0,4.0.0)"; visibility:="reexport"
Looking at the jar file the version is 3.104.0, but looking at salsa
(http
Hi,
> > > Therefore, I can quickly prepare a 5.3 upload.
> > >
> > > Are there any blockers regarding uploading a newer version?
> >
> > Should I prepare an upload? A merge request? Any known blockers?
> >
> > $ apt-cache rdepends libwoo
Hi Alex,
On Sun, May 03, 2020 at 05:30:38PM +0200, Alexandre Rossi wrote:
> Hi list,
>
> On Thu, Apr 23, 2020 at 10:21 AM Alexandre Rossi wrote:
> >
> > Package: libwoodstox-java
> > Version: 1:5.1.0-2
> > Severity: wishlist
> >
> > Dear Maintai
Hi list,
On Thu, Apr 23, 2020 at 10:21 AM Alexandre Rossi wrote:
>
> Package: libwoodstox-java
> Version: 1:5.1.0-2
> Severity: wishlist
>
> Dear Maintainer,
>
> woodstox-core 6.1.1 is available.
>
> upstream of davmail is carrying out a patch and would like at leas
On Fri, 13 Dec 2019, shirish शिरीष wrote:
> I didn't see it multple times. The only place it seems to have shared
> it is in this thread [1] but also just a hint therein, haven't seen
OK, it’s indeed not easy to find. Sorry.
There’s this though:
https://lists.debian.org/debian-java/2019/07/msg00
At bottom :-
On 13/12/2019, Thorsten Glaser wrote:
> On Fri, 13 Dec 2019, shirish शिरीष wrote:
>
>> which is 2 years down the line, so would we be having Java 11 for
>> bullseye release
>
> This is what was already announced multiple times, yes.
> The archives would most likely have the full info
On Fri, 13 Dec 2019, shirish शिरीष wrote:
> which is 2 years down the line, so would we be having Java 11 for
> bullseye release
This is what was already announced multiple times, yes.
The archives would most likely have the full information.
bye,
//mirabilos
--
tarent solutions GmbH
Rochusstra
Dear all,
It seems that the next LTS version of Java would be Java SE 17 [1]
which is 2 years down the line, so would we be having Java 11 for
bullseye release and have the interim releases . I looked both at the
wiki [2], the java goals [3] as well as the java FAQ manpage [4] to
have some sense
Hi,
any comment from Debian Java team?
Kind regards
Andreas.
On Mon, Sep 16, 2019 at 09:57:58AM +0200, Olivier Sallou wrote:
>
> On 9/13/19 3:43 PM, Andreas Tille wrote:
> > Hi,
> >
> > I upgraded the igv packaging Git[1] to the latest upstream version. I
> &
On 15.02.2019 18:49, Markus Koschany wrote:
Frederic did the bootstrap part wrong. Unfortunately nobody corrected
him in time before he tried to use the prebuilt upstream binaries for
bootstrapping sbt. Just ignore the current rules file. We have to come
up with something better.
Ok, I can t
Am 14.02.19 um 22:59 schrieb Thomas Finneid:
[...]
> Either this is what I had in mind originally or some detail is missing.
>
> Said another way, the rules script is in two parts. The first part is
> used in experimental, to download external sbt tools to bootstrap the
> build of
, the rules script is in two parts. The first part is
used in experimental, to download external sbt tools to bootstrap the
build of the pre-version sbt in debian. Then upload the experimental
package to unstable. Which in part to of the script, it can be used to
build the actual sbt version.
If
versioned and an unversioned jar file (just a
symlink). The reason is we want to simplify upgrades and instead of
patching a dozen pom files, we just declare a "debian" version. The
benefit is we only have to fix one package in case of security issues
but the disadvantage is that every
On 14.02.2019 11:55, Markus Koschany wrote:>
> What you can do of course is to patch sbt or scala. We use so-called
> quilt patches. For instance take a look at sbt. In debian/patches you
> can see several Debian specific patches that change the default Maven
> repository for example.
Thats what
Am 14.02.19 um 00:22 schrieb Thomas Finneid:
>
>
> On 12.02.2019 22:40, Markus Koschany wrote:
>> There are different rules for contrib and non-free. [1] You could
>> package scala and sbt for contrib, because both pieces of software
>> comply with the DFSG. If you use a prebuilt package for bui
On 07.02.2019 15:29, Thorsten Glaser wrote:
If there’s no such path, you’d need more intermediate versions and
upload them, one after another. Into experimental would most likely
be the best, with the understanding that these are intended for
bootstrapping, not for use by users, although they
Debian. Unfortunately none of the active team members is a Scala
>
> Thanks, Markus! And thanks for the super-quick "how-to", it got me
> started actually looking at the packages, to understand how Sbt has been
> compiled. Scala is easier to compile, cause 2.11.x version have A
On Thu, 7 Feb 2019, Thomas Finneid wrote:
> One thought, both the scala team and the sbt team produces .deb packages, can
> they be uploaded as final distribution packages, or even used as the the
One thing to remember is that we do NOT upload .deb packages.
We upload .dsc packages (Debian sourc
f external resources at build time.
We want to fix https://bugs.debian.org/845113, upgrading to a newer
version of scala, but we need to solve all open RC bugs in sbt first.
https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=sbt
We already have a version of sbt in Debian. I don&#
Sorry for all the confusing questions, but getting to know a new build
process, especially such an advanced one as Debians, is quite
confusing to begin with.
On 08.02.2019 02:29, Thorsten Glaser wrote:
On Thu, 7 Feb 2019, Thomas Finneid wrote:
One thought, both the scala team and the
build on CI system, is it allowed to preconfigure it manually with
> > > the
> > > newest sbt version, i.e. version 1.x, from a tarball download?
> >
> > No.
>
> Ok? Do I understand it correctly that everything has to be built from
> scratch and the build
On 07.02.2019 15:29, Thorsten Glaser wrote:
On Thu, 7 Feb 2019, Thomas Finneid wrote:
downloads and installs the required scala and sbt version inside the project
This is absolutely not going to happen in Debian.
I might have been a litte unclear by my wording, when I said scala/sbt
On Thu, 7 Feb 2019, Thomas Finneid wrote:
> downloads and installs the required scala and sbt version inside the project
This is absolutely not going to happen in Debian.
> With these facts at hand, the question is how to deal with this in the debian
> build system?
You can always d
installation of scala, as is
normal with f.ex. java and maven.
- Instead, a scala project describes its scala and sbt versions in its
build file, which sbt uses to bootstrap the project build environment.
I.e. it downloads and installs the required scala and sbt version inside
the project environment
compatability.
There is also a difference in compatability in terms of compiling vs
running. It is advised that compilation of scala code be done on a jdk
8, but can in most cases be run on later versions that are backwards
compatible (but here there is a matrix for which version of scala are
minimum
a 2.12 is built with sbt 0.13, even though sbt 1.x is
> available, Which means it also need the correct sbt version to build
> scala correctly.
>
> So, I want to help fix these issues for both scala and sbt and upgrade
> scala to 2.12.
Well, yes, this is a good idea in general. Howev
1 - 100 of 447 matches
Mail list logo
