Re: Status of axis in debian

[Pierre Gruet]

Hi all,

Le 10/07/2024 à 15:52, Santiago Ruano Rincón a écrit :

(Resending to the correct address list; sorry for the noise)

El 10/07/24 a las 10:41, Santiago Ruano Rincón escribió:

Dear Java packaging team,

(Please CC: me when replying, I am not subscribed to the list)

According to the apache advisory of CVE-2023-51441, axis 1.x has been
EOL'ed upstream:

https://lists.apache.org/thread/8nrm5thop8f82pglx4o0jg8wmvy6d9yd

According to the comment by grid on #debian-security, I understand it is
on life support upstream, and there have been fixes for CVEs the last
years, including at least one not-unimportant. However, from the above
mentioned advisory, upstream recommends to migrate to a "different SOAP
engine, such as Apache Axis 2/Java."

On sid, this is the current list of build dependencies of libaxis-java:

jalview
jets3t
jglobus
starjava-datanode
starjava-dpac
starjava-topcat
starjava-ttools
starjava-vo
starjava-votable
uimaj

So my mail is just to start any discussion to see if it would be
appropriate to file bugs on the reverse dependencies, to ask the
maintainers if they could study how feasible is to migrate to another
SOAP engine.

Any thoughts?


Thanks for raising this issue. My first feeling is filing these bug 
reports is sensible, unconditionally.


But also I wonder if we have some reasonable alternative to suggest in 
these bug reports:
- axis2 is unpackaged (could be) and its latest release is 2 years (+ 1 
day) old;
- saaj and jaxws: I can't say if they can provide an alternative to what 
axis does. Perhaps some people there have an opinion?

- Apache CXF, unpackaged as of now but seems to be actively maintained?
- something else?

Do others in the team have some ideas?



Cheers,

  -- Santiago





Best,

--
Pierre


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: OpenJDK 21

[Emmanuel Bourg]

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.  The transition was finished 
for Ubuntu earlier this year (thanks Vladimir), and most, if not all 
patches should be in the Debian bug tracker.


I've uploaded some updates prepared by Vladimir and Pushkar today and 
yesterday. Kudos for the outstanding work, the patches cover most of the 
remaining Java 21 issues, are well documented and were forwarded upstream.


There are 17 patches left to apply [1], most of them are for minor 
packages or packages not maintained by the Java Team. The most important 
ones are kotlin and lombok in my opinion. Once they are fixed I think we 
can switch the default JDK to OpenJDK 21.


After the transition I'd suggest keeping the openjdk-17 package in 
unstable only, that may be useful for upgrading Gradle and Kotlin.


Emmanuel Bourg

[1] 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=default-java21;users=debian-java@lists.debian.org

Re: OpenJDK 21

[Matthias Klose]

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 transition on my own (besides the java-common
upload), I still have to do some other transitions.


I'm not in a position to offer to drive this transition end-to-end, but
can provide sponsoring and routine maintenance support.  I will start by
resuming working through the reported issues in the BTS.


PS: I'll be at DebConf, but I doubt we'll have much attendance from the
debian-java team there.


If there are suitable facilities for video conference at Debconf, we
could schedule a Java BoF to discuss your plans.  Afternoon in GMT+9
will the morning in Europe and late evening in the evening in the US.
(Of course, we could do that before or after Debconf too.)


we can try that, sure, but I don't want to be the only one sitting 
there. Is that really needed?


Matthias

openjfx for arm64 bookworm

[Søren Juul]

Hi all,

Are there any plans for releasing openjfx for arm64 for bookworm? I see
that there exist builds for trixie and older versions as well.

Thanks in advance
Søren

Re: OpenJDK 21

[tony mancill]

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 time in the near future doing that.  The transition was finished
> for Ubuntu earlier this year (thanks Vladimir), and most, if not all
> patches should be in the Debian bug tracker.

Yes, the patches in the BTS (almost all from Vladimir) have been very
helpful.

Is the intent to allow OpenJDK 21 to migrate to testing, or to get it
into unstable and block the migration?

> I don't want to drive this transition on my own (besides the java-common
> upload), I still have to do some other transitions.

I'm not in a position to offer to drive this transition end-to-end, but
can provide sponsoring and routine maintenance support.  I will start by
resuming working through the reported issues in the BTS.

> PS: I'll be at DebConf, but I doubt we'll have much attendance from the
> debian-java team there.

If there are suitable facilities for video conference at Debconf, we
could schedule a Java BoF to discuss your plans.  Afternoon in GMT+9
will the morning in Europe and late evening in the evening in the US.
(Of course, we could do that before or after Debconf too.)

Cheers,
tony


signature.asc
Description: PGP signature

Re: OpenJDK 21

[Thorsten Glaser]

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 something like:

ifeq (,$(filter ${distrel},wheezy jessie stretch buster bullseye bookworm 
precise trusty xenial bionic focal jammy mantic noble oracular))
  # Debian testing/sid
  ifneq (,$(filter ${DEB_HOST_ARCH},m68k sh4))
# xfwm4 B-D for testing not available
with_check = disabled running check on ${distrel}/${DEB_HOST_ARCH}
  endif
  nocheck_profile = ${NULL} [!m68k !sh4] 
endif

The qemu-user buildds for these two architectures set nocheck
anyway currently still, so this won’t be a regression in practice.

xfwm4 has very heavy dependencies including cyclic. Are the tests
tied to it or would say twm or evilwm suffice? (I normally would
recommend icewm, but it’s got a good part of the same too-heavy
dependencies.)

bye,
//mirabilos
-- 
Infrastrukturexperte • Qvest Digital AG
Am Dickobskreuz 10, D-53121 Bonn • https://www.qvest-digital.com/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 18196 • USt-ID (VAT): DE274355441
Vorstand: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Vorsitzender Aufsichtsrat: Peter Nöthen

OpenJDK 21

[Matthias Klose]

Hi,

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.  The transition was finished 
for Ubuntu earlier this year (thanks Vladimir), and most, if not all 
patches should be in the Debian bug tracker.


We will have to keep m68k as pointing to 17 for now.

I don't want to drive this transition on my own (besides the java-common 
upload), I still have to do some other transitions.


Matthias

PS: I'll be at DebConf, but I doubt we'll have much attendance from the 
debian-java team there.

Status of axis in debian

[Santiago Ruano Rincón]

(Resending to the correct address list; sorry for the noise)

El 10/07/24 a las 10:41, Santiago Ruano Rincón escribió:
> Dear Java packaging team,
> 
> (Please CC: me when replying, I am not subscribed to the list)
> 
> According to the apache advisory of CVE-2023-51441, axis 1.x has been
> EOL'ed upstream:
> 
> https://lists.apache.org/thread/8nrm5thop8f82pglx4o0jg8wmvy6d9yd
> 
> According to the comment by grid on #debian-security, I understand it is
> on life support upstream, and there have been fixes for CVEs the last
> years, including at least one not-unimportant. However, from the above
> mentioned advisory, upstream recommends to migrate to a "different SOAP
> engine, such as Apache Axis 2/Java."
> 
> On sid, this is the current list of build dependencies of libaxis-java:
> 
> jalview
> jets3t
> jglobus
> starjava-datanode
> starjava-dpac
> starjava-topcat
> starjava-ttools
> starjava-vo
> starjava-votable
> uimaj
> 
> So my mail is just to start any discussion to see if it would be
> appropriate to file bugs on the reverse dependencies, to ask the
> maintainers if they could study how feasible is to migrate to another
> SOAP engine.
> 
> Any thoughts?
> 
> Cheers,
> 
>  -- Santiago




signature.asc
Description: PGP signature

Re: any efforts to get Eclipse IDE (with CDT) back into Debian?

[Matthias Klose]

On 16.06.24 23:21, Philippe Cerfon wrote:

Hey Emmanuel.

On Sun, Jun 16, 2024 at 6:54 PM Emmanuel Bourg  wrote:

The lack of manpower is still an issue. I'm still able to update the
core Eclipse libraries once or twice a year, but the full IDE would
require at least a full time maintainer I think.


I see.

What a pity that none of the big companies using Debian and doing
development (and thus may benefit from Eclipse, too) or e.g. Canonical
seems to have an interest in this and being able to sponsor the needed
manpower.


I fail to see the connection between using Debian and using Eclipse.

Go start packaging yourself, or at least write what would be needed.  In 
the past, upstream didn't care much about getting packaging issues 
addressed upstream, and packaging is very time consuming.


I'm not sure if RedHat is still doing that, but they had one or two full 
time developers doing that.


Matthias

Re: Contacting Java packaging team

[Andrius Merkys]

Hello,

I am running late to this discussion, but thought I could share my 
personal thoughts as a data point.


On 2024-06-12 18:27, Andreas Tille wrote:

I have some specific questions to the Java packaging team.

   - Do you feel good when doing your work in Java packaging team?


Yes. I attribute it to the teammates and high quality tooling, as well 
as overall stability and quality of Java ecosystem.



   - Do you consider the workload of your team equally shared amongst its
 members?


I feel uploads per uploader should follow the power law, but I have no 
data to prove that.



   - Do you have some strategy to gather new contributors for your team?


Personally, not.


   - Can you give some individual estimation how many hours per week you
 are working on your tasks in youre team?  Does this fit the amount of
 time you can really afford for this task?


Roughly half an hour per week. However, I spend most of my time on often 
ill-fated attempts to refresh debian/copyright when attempting to update 
the few large Java packages I maintain.



   - In my packaging work I frequently contacted Java packaging team and
 usually got help very quickly - thanks a lot for this.  The only
 thing I was not happy about is the fact that the team decided to make
 the usage of Salsa CI extra hard.  I've contacted the Salsa CI team
 before and explicitly asked about this policy.  They do not understand
 and recommend to run Salsa CI as default but by no means even hide
 the button to switch it on.  Would you mind changing your policy about
 this?


I have no opinion here.


   - Can I do anything for you?


Keep up the good work!

Best wishes,
Andrius

Re: Contacting Java packaging team

[Andrius Merkys]

Hello,

On 2024-06-26 00:06, Emmanuel Bourg wrote:

Le 17/06/2024 à 08:16, Andreas Tille a écrit :


The problems Pierre described with upgrading Gradle might be some
indication that some more skilled packagers could help.


We would need a core Gradle and/or Kotlin developer to tackle this 
issue, but I don't think they are interested in spending days or weeks 
figuring out an upgrade path for old versions of Gradle.


+1

Just FTR, I have successfully switched several packages from gradle 
buildsystem to plain javahelper, see libejml-java for example.


Andrius

Re: Contacting Java packaging team

[Andreas Tille]

Hi Emmanuel,

Am Tue, Jun 25, 2024 at 11:06:59PM +0200 schrieb Emmanuel Bourg:
> > The problems Pierre described with upgrading Gradle might be some
> > indication that some more skilled packagers could help.
> 
> We would need a core Gradle and/or Kotlin developer to tackle this issue,
> but I don't think they are interested in spending days or weeks figuring out
> an upgrade path for old versions of Gradle.

I don't have the slightest idea about the technical details but I've
seen good cooperation for instance to get bazel packaged and other
fruitful cooperations with upstream.  Finally I do not think it is good
if Debian is lagging behind gradle upstream more and more and we somehow
need to catch up.  IMHO at least we should try and if I can help out
to establish this contact as DPL I'd happily help here.
 
> > I intentionally linked to some response I once received[2] which says:
> > "java-team have pipelines disabled by default".  I consider this a
> > really unfortunate blocker to simply switch on Salsa CI.  If there is no
> > policy to use Salsa CI or not please make sure developers will not need
> > extra hurdles to switch it on.
> 
> If I remember well, the repository creation script [1] for the Java team
> disables the CI feature, because at the time it was written the Salsa CI
> wasn't implemented yet.
 
I can only say that java-team is the only team space I know with this
extra hard setting to switch on Salsa-CI.  If you are willing to change
this but have no idea how this can be done I'd volunteer to find out the
needed information.
 
> > Regarding the "IRC spam":  IMHO this is not a Salsa CI feature but
> > rather the KGB bot you can switch of.
> 
> I'd like KGB to report commits but not CI builds, if that's possible.

Usually these things are configurable.  I have no idea how but if this
is your main reason to not enable Salsa CI I would also try to find this
information.
 
> > For me as someone who barely
> > speaks any Java and just crossing fingers that the upstream build system
> > works flawlessly it helps a lot to have some build log available online
> > very easily which I can link to in some mail to the Debian Java list to
> > get further help.  This might be true for potential newcomers as well.
> 
> That's indeed a convenience, but with an energy cost and a CO2 impact on the
> planet.

I've heard that CO2 saving argument in connection with Salsa CI.  As you
might have read in my platform I personally care for the environment.
In this regard its really hard to draw a line.  You could argue that we
should not support old, power hungry architectures, stop this or that
service etc.  I do not consider the discussion on that level as fruitful.

Kind regards
Andreas.

> [1] 
> https://salsa.debian.org/java-team/pkg-java-scripts/-/blob/master/setup-salsa-repository

-- 
https://fam-tille.de

Re: Contacting Java packaging team

[gregor herrmann]

On Tue, 25 Jun 2024 23:06:59 +0200, Emmanuel Bourg wrote:

> > Regarding the "IRC spam":  IMHO this is not a Salsa CI feature but
> > rather the KGB bot you can switch of.
> I'd like KGB to report commits but not CI builds, if that's possible.

In the Perl team we're using
https://kgb.debian.net/webhook/?channel=debian-perl-changes_only_status=success_only_status=failed
AFAIK this doesn't eliminate Ssalsa CI message but limits them to one
line with the final result (I was also annoyed by the Salsa CI
message flood). (And it's a separe channel (for KGB with both commits
and Salsa messages, separate from the discussion channel.)


Cheers,
greggor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Re: Contacting Java packaging team

[Emmanuel Bourg]

Le 17/06/2024 à 08:16, Andreas Tille a écrit :


The problems Pierre described with upgrading Gradle might be some
indication that some more skilled packagers could help.


We would need a core Gradle and/or Kotlin developer to tackle this 
issue, but I don't think they are interested in spending days or weeks 
figuring out an upgrade path for old versions of Gradle.




I intentionally linked to some response I once received[2] which says:
"java-team have pipelines disabled by default".  I consider this a
really unfortunate blocker to simply switch on Salsa CI.  If there is no
policy to use Salsa CI or not please make sure developers will not need
extra hurdles to switch it on.


If I remember well, the repository creation script [1] for the Java team 
disables the CI feature, because at the time it was written the Salsa CI 
wasn't implemented yet.




Regarding the "IRC spam":  IMHO this is not a Salsa CI feature but
rather the KGB bot you can switch of.


I'd like KGB to report commits but not CI builds, if that's possible.



For me as someone who barely
speaks any Java and just crossing fingers that the upstream build system
works flawlessly it helps a lot to have some build log available online
very easily which I can link to in some mail to the Debian Java list to
get further help.  This might be true for potential newcomers as well.


That's indeed a convenience, but with an energy cost and a CO2 impact on 
the planet.


Emmanuel Bourg

[1] 
https://salsa.debian.org/java-team/pkg-java-scripts/-/blob/master/setup-salsa-repository

Re: Contacting Java packaging team

[Andreas Tille]

Hi Emmanuel,

Am Sun, Jun 16, 2024 at 10:40:02PM +0200 schrieb Emmanuel Bourg:
> That's a good idea, thank you.

You (all in the Java team) are welcome.  I frequently profited from
your help.
 
> > I have some specific questions to the Java packaging team.
> > 
> >- Do you feel good when doing your work in Java packaging team?
> 
> Absolutely

That's always good to know.

> >- Do you consider the workload of your team equally shared amongst its
> >  members?
> 
> No but that's not an issue, everyone scratches the itches he wants.

>From my experience in other teams I'd recommend to reach out to team
members a bit more.  I consider the coordintion inside the Perl team a
good example.  Also the Python team does yearly meetings at DebConf.
This common team feeling might increase the productivity of the team.
Inside the Debian Med team besides yearly sprints we have quite good
experience with what we call "advent bug squashing party".  In this
effort team members are try to close bugs in packages of other
Uploaders.  This contributes to some interchange of packaging knowledge
and some common team feeling.
 
> >- Do you have some strategy to gather new contributors for your team?
> 
> Not really.

I'd recommend to actively think about this.  While its a time consuming
task to seek for new contributors it might have a nice return of
investment.  I'd specifically try to involve upstream into packaging
efforts.  Usually upstreams are happy if their code is packaged for
Debian (not sure if this is true in the Java world).  Providing them
with some packaging knowledge might be a shortcut to packages that
receive good testing by people who perfectly know the functionality.

The problems Pierre described with upgrading Gradle might be some
indication that some more skilled packagers could help.

> >- In my packaging work I frequently contacted Java packaging team and
> >  usually got help very quickly - thanks a lot for this.  The only
> >  thing I was not happy about is the fact that the team decided to make
> >  the usage of Salsa CI extra hard.  I've contacted the Salsa CI team
> >  before and explicitly asked about this policy.  They do not understand
> >  and recommend to run Salsa CI as default but by no means even hide
> >  the button to switch it on.  Would you mind changing your policy about
> >  this?
> 
> There is no policy regarding Salsa CI in the Java Team, anyone who wishes to
> use it is free to do so.

I intentionally linked to some response I once received[2] which says:
"java-team have pipelines disabled by default".  I consider this a
really unfortunate blocker to simply switch on Salsa CI.  If there is no
policy to use Salsa CI or not please make sure developers will not need
extra hurdles to switch it on.

> Personally, I do not because it doesn't add value
> to my workflow. I'm also not a fan of the IRC spam induced, and in times of
> energy sobriety I feel that's a non-essential tool we can do without.

Regarding the "IRC spam":  IMHO this is not a Salsa CI feature but
rather the KGB bot you can switch of.  For me as someone who barely
speaks any Java and just crossing fingers that the upstream build system
works flawlessly it helps a lot to have some build log available online
very easily which I can link to in some mail to the Debian Java list to
get further help.  This might be true for potential newcomers as well. 

> >- Can I do anything for you?
> 
> Just keep the good work :)

Thank you 
Andreas.

[2] https://lists.debian.org/debian-java/2021/04/msg00025.html 

-- 
https://fam-tille.de

Re: Contacting Java packaging team

[Mechtilde]

Hello,


Am 16.06.24 um 22:40 schrieb Emmanuel Bourg:

Hi Andreas,

Le 12/06/2024 à 17:27, Andreas Tille a écrit :


I'd like to officially contact all our teams to learn about potential
issues that might affect your work.  I would love to learn how you
organise / share your workload.  If you do some regular meetings - be it
on IRC, video conference or whatever I'm interested in joining one of
your next meetings.


That's a good idea, thank you.


I have some specific questions to the Java packaging team.

   - Do you feel good when doing your work in Java packaging team?


Absolutely


A little bit more help for newcommers is appreciate



   - Do you consider the workload of your team equally shared amongst its
 members?


No but that's not an issue, everyone scratches the itches he wants.


(s)he 




   - Do you have some strategy to gather new contributors for your team?


Not really.


I think that is a problem not only in this team but here too




   - In my packaging work I frequently contacted Java packaging team and
 usually got help very quickly - thanks a lot for this.  The only
 thing I was not happy about is the fact that the team decided to 
make

 the usage of Salsa CI extra hard.  I've contacted the Salsa CI team
 before and explicitly asked about this policy.  They do not 
understand

 and recommend to run Salsa CI as default but by no means even hide
 the button to switch it on.  Would you mind changing your policy 
about

 this?


There is no policy regarding Salsa CI in the Java Team, anyone who 
wishes to use it is free to do so. Personally, I do not because it 
doesn't add value to my workflow. I'm also not a fan of the IRC spam 
induced, and in times of energy sobriety I feel that's a non-essential 
tool we can do without.



   - Can I do anything for you?


Just keep the good work :)


Emmanuel Bourg



Kind regards

--
Mechtilde Stehmann
## Apache OpenOffice
## Freie Office Suite für Linux, MacOSX, Windows und OS/2
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: any efforts to get Eclipse IDE (with CDT) back into Debian?

[Philippe Cerfon]

Hey Emmanuel.

On Sun, Jun 16, 2024 at 6:54 PM Emmanuel Bourg  wrote:
> The lack of manpower is still an issue. I'm still able to update the
> core Eclipse libraries once or twice a year, but the full IDE would
> require at least a full time maintainer I think.

I see.

What a pity that none of the big companies using Debian and doing
development (and thus may benefit from Eclipse, too) or e.g. Canonical
seems to have an interest in this and being able to sponsor the needed
manpower.

Thanks,
Philippe.

Re: Contacting Java packaging team

[Emmanuel Bourg]

Hi Andreas,

Le 12/06/2024 à 17:27, Andreas Tille a écrit :


I'd like to officially contact all our teams to learn about potential
issues that might affect your work.  I would love to learn how you
organise / share your workload.  If you do some regular meetings - be it
on IRC, video conference or whatever I'm interested in joining one of
your next meetings.


That's a good idea, thank you.


I have some specific questions to the Java packaging team.

   - Do you feel good when doing your work in Java packaging team?


Absolutely


   - Do you consider the workload of your team equally shared amongst its
 members?


No but that's not an issue, everyone scratches the itches he wants.


   - Do you have some strategy to gather new contributors for your team?


Not really.


   - In my packaging work I frequently contacted Java packaging team and
 usually got help very quickly - thanks a lot for this.  The only
 thing I was not happy about is the fact that the team decided to make
 the usage of Salsa CI extra hard.  I've contacted the Salsa CI team
 before and explicitly asked about this policy.  They do not understand
 and recommend to run Salsa CI as default but by no means even hide
 the button to switch it on.  Would you mind changing your policy about
 this?


There is no policy regarding Salsa CI in the Java Team, anyone who 
wishes to use it is free to do so. Personally, I do not because it 
doesn't add value to my workflow. I'm also not a fan of the IRC spam 
induced, and in times of energy sobriety I feel that's a non-essential 
tool we can do without.



   - Can I do anything for you?


Just keep the good work :)


Emmanuel Bourg

Re: any efforts to get Eclipse IDE (with CDT) back into Debian?

[Emmanuel Bourg]

Hi Philippe,

Le 16/06/2024 à 04:16, Philippe Cerfon a écrit :


Since quite some time has passed, I merely wanted to ask whether
there's been ever any thoughts from the Java Team to get Eclipse IDE
back into Debian as proper packages?


The lack of manpower is still an issue. I'm still able to update the 
core Eclipse libraries once or twice a year, but the full IDE would 
require at least a full time maintainer I think.


Emmanuel Bourg

Re: Contacting Java packaging team

[Pierre Gruet]

Hi Andreas,

And thanks for contacting us.

All thoughts below are personal and I hope some others will come up.

Le 12/06/2024 à 17:27, Andreas Tille a écrit :

Hi,


[...]


I have some specific questions to the Java packaging team.

   - Do you feel good when doing your work in Java packaging team?


Sure. Teammates are always helpful!


   - Do you consider the workload of your team equally shared amongst its
 members?


(Disclaimer: I am never on IRC so I really might be missing things from 
there.)


Hard to say, my feeling is we in the team are not sharing a 
well-established common goal, and for this reason "workload" is hard to 
define.


Surely some team members have precise goals in mind, but I don't.

My feeling: some coordination among us (e.g. through periodic BoF?) 
would be really useful. We could discuss big issues and directions for 
the team, for instance:

- timeline of default JDK versions in Debian;
- the gradle issue: we are stuck with an old version because we miss big 
dependencies of newest versions, thus we have to patch more and more 
heavily the upstream build.gradle files in order to be able to build 
against our old gradle... I know a lot of efforts have been made about 
this, including some years ago by the Android team. But I cannot say if 
getting a newer gradle is an unreachable goal or if coordination could help;

- same for groovy, scala, ...


   - Do you have some strategy to gather new contributors for your team?


Not that I am aware of.


   - Can you give some individual estimation how many hours per week you
 are working on your tasks in youre team?  Does this fit the amount of
 time you can really afford for this task?


I would say 1 hour per week on average, but it also depends on Java 
needs I may have from packages in other packaging teams.



   - In my packaging work I frequently contacted Java packaging team and
 usually got help very quickly - thanks a lot for this.  The only
 thing I was not happy about is the fact that the team decided to make
 the usage of Salsa CI extra hard.  I've contacted the Salsa CI team
 before and explicitly asked about this policy.  They do not understand
 and recommend to run Salsa CI as default but by no means even hide
 the button to switch it on.  Would you mind changing your policy about
 this?


Another thing we could discuss in the team as I am not aware of this issue.


   - Can I do anything for you?


Your email is already important. If others raise their voices, maybe 
other ideas could come.





Kind regards and thanks a lot for your work
Andreas.



Thanks again for your interest,

--
Pierre



OpenPGP_signature.asc
Description: OpenPGP digital signature

any efforts to get Eclipse IDE (with CDT) back into Debian?

[Philippe Cerfon]

Hello.

Quite a while ago, the Eclipse IDE and related plugins (like CDT) were
dropped from Debian, as far as I understand primarily because of a
lack of manpower.

There's an ITP (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923219)
for https://github.com/philippmeisberger/eclipse-package but not only
seems the ITP dead, but also upstream itself.
But even if that weren't the case - I'd say a proper packaging would
be way better than some more or less downloader.

Since quite some time has passed, I merely wanted to ask whether
there's been ever any thoughts from the Java Team to get Eclipse IDE
back into Debian as proper packages?

It's probably still the most powerful FLOSS IDE (yes I know, that
there are alternatives) so it would be quite nice to have.


Thanks,
Philippe.

Contacting Java packaging team

[Andreas Tille]

Hi,

I'd like to officially contact all our teams to learn about potential
issues that might affect your work.  I would love to learn how you
organise / share your workload.  If you do some regular meetings - be it
on IRC, video conference or whatever I'm interested in joining one of
your next meetings.

Like previous DPLs, I'm open to any inquiries or requests for
assistance. I personally prefer public discussion whenever possible, as
they can benefit a wider audience. You can find a list of contact
options at the bottom of my page on people.d.o[1].

I prefer being offline when I'm away from my keyboard, so I don't carry
a phone. In urgent situations, I can provide the number of my dumb
phone, though it may not always be within reach. Feel free to ping me
via email if I don't respond promptly to ensure I address your concerns.

Please let me know whether I can do something for you.  I'm fine joining
your IRC channel if needed but please invite me in case I should be
informed about some urgent discussion there since I normally do not lurk
on this channel.

I'd also like to inform you that I've registered a BoF for DebConf24 in
Busan with the following description:

  This BoF is an attempt to gather as much as possible teams inside
  Debian to exchange experiences, discuss workflows inside teams, share
  their ways to attract newcomers etc.

  Each participant team should prepare a short description of their work
  and what team roles (“openings”) they have for new contributors. Even
  for delegated teams (membership is less fluid), it would be good to
  present the team, explain what it takes to be a team member, and what
  steps people usually go to end up being invited to participate. Some
  other teams can easily absorb contributions from salsa MRs, and at some
  point people get commit access. Anyway, the point is that we work on the
  idea that the pathway to become a team member becomes more clear from an
  outsider point-of-view.

I'm sure not everybody will be able to travel this distance but it would
be great if you would at least consider joining that BoF remotely.  I'll
care for a somehow TimeZone aware scheduling - if needed we'll organise
two BoFs to match all time zones.  I'm also aware that we have pretty
different teams and it might make sense to do some infrastructure
related BoF with your team and other teams that are caring for Debian
infrastructure.

I have some specific questions to the Java packaging team.

  - Do you feel good when doing your work in Java packaging team?
  - Do you consider the workload of your team equally shared amongst its
members?
  - Do you have some strategy to gather new contributors for your team?
  - Can you give some individual estimation how many hours per week you
are working on your tasks in youre team?  Does this fit the amount of
time you can really afford for this task?
  - In my packaging work I frequently contacted Java packaging team and
usually got help very quickly - thanks a lot for this.  The only
thing I was not happy about is the fact that the team decided to make
the usage of Salsa CI extra hard.  I've contacted the Salsa CI team
before and explicitly asked about this policy.  They do not understand
and recommend to run Salsa CI as default but by no means even hide
the button to switch it on.  Would you mind changing your policy about
this?
  - Can I do anything for you?


Kind regards and thanks a lot for your work
   Andreas.


[1] https://people.debian.org/~tille/
[2] https://lists.debian.org/debian-java/2021/04/msg00025.html

-- 
https://fam-tille.de


signature.asc
Description: PGP signature

Re: (java) Builds not reproducible on armhf

[Vagrant Cascadian]

On 2024-05-20, Mechtilde Stehmann wrote:
> I want to clean up my Java packages.
>
> There are several with FTBR. I found that the day of the *.poms s a date 
> from 1970.
>
> for example they are the packages
>
> vinnie

Looking at the history for vinnie:

  https://tests.reproducible-builds.org/debian/history/armhf/vinnie.html

It is only very recently that this started happening (2024-05-04)
without source changes in vinnie itself, so I would suspect some change
in the toolchain used to produce the .pom files?

commons-email is similar, although starting 2024-04-04:

  https://tests.reproducible-builds.org/debian/history/armhf/commons-email.html

ez-vcard is similar too, starting 2024-04-20:

  
https://tests.reproducible-builds.org/debian/rb-pkg/trixie/armhf/diffoscope-results/ez-vcard.html

Although some of those builds also have differences in some xz
contents... might just be related to the timestamp differences.


Wild hunch is one build is run on a 64-bit kernel (without a linux32
personality) and one build on a 32-bit kernel... that is one of the main
differences between these armhf test builds and builds on other
architectures, where this does not seem to happen...


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Builds not reproducible on armhf

[Thorsten Glaser]

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 JDK bug: I tested…

import java.io.*;

class T1 {
public static void main(String args[]) throws IOException {
File sf = new File("T1.java");
File df = new File("T1.out");
System.out.println(sf.lastModified());
InputStream is = new FileInputStream(sf);
OutputStream os = new FileOutputStream(df);
byte[] data = new byte[32768];
int nbytes = is.read(data);
os.write(data, 0, nbytes);
os.close();
is.close();
df.setLastModified(sf.lastModified());
}
}

… on armhf with OpenJDK 8, 17 and 21 (11 needs t64-transitioning).

Given the range of January 1970…

$ TZ=UTC date -d '1970-01-31T23:59:59Z' +%s
2678399
$ TZ=UTC date -d @2678399000
Sun Nov 15 23:43:20 UTC 2054

… it is entirely possible that someone confused time_t and
Java millis, so the timestamps are off by a factor of 1000.

-rw-r--r--···0·root·(0)·root·(0)·1415·1970-01-06·08:03:05.00·./usr/share/maven-repo/com/github/mangstadt/vinnie/2.0.2/vinnie-2.0.2.pom
-rw-r--r--···0·root·(0)·root·(0)·1415·1970-01-03·13:27:14.00·./usr/share/maven-repo/com/github/mangstadt/vinnie/2.0.2/vinnie-2.0.2.pom

-rw-r--r--···0·root·(0)·root·(0)·1416·1970-01-09·01:36:03.00·./usr/share/maven-repo/com/github/mangstadt/vinnie/debian/vinnie-debian.pom
-rw-r--r--···0·root·(0)·root·(0)·1416·1970-01-04·21:40:23.00·./usr/share/maven-repo/com/github/mangstadt/vinnie/debian/vinnie-debian.pom

$ for t in 1970-01-06T08:03:05 1970-01-03T13:27:14 \
1970-01-09T01:36:03 1970-01-04T21:40:23; do \
TZ=UTC date -d @$(TZ=UTC date -d "${t}Z" +%s)000; \
  done

Fri Aug 10 11:23:20 UTC 1984
Tue Jan  4 13:53:20 UTC 1977
Sat Feb  1 16:50:00 UTC 1992
Mon Sep  8 01:03:20 UTC 1980

Okaaay… So, maybe not so much. I *was* guessing something with
DEB_SOURCE_EPOCH vs. project.build.outputTimestamp, but that’s
apparently not it either.

So I fear someone’ll have to dig through all the various Maven-
related source packages…

FWIW, the 517-day-old .deb currently in the repo has…

-rw-r--r-- root/root  1415 2022-12-17 18:36 
./usr/share/maven-repo/com/github/mangstadt/vinnie/2.0.2/vinnie-2.0.2.pom

… which matches Sat, 17 Dec 2022 18:36:19 +0100 from d/changelog,
so something something reproducible-builds is still suspect.

Good luck with that,
//mirabilos
-- 
Infrastrukturexperte • Qvest Digital AG
Am Dickobskreuz 10, D-53121 Bonn • https://www.qvest-digital.com/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 18196 • USt-ID (VAT): DE274355441
Vorstand: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Vorsitzender Aufsichtsrat: Peter Nöthen

Builds not reproducible on armhf

[Mechtilde Stehmann]

Hello,

I want to clean up my Java packages.

There are several with FTBR. I found that the day of the *.poms s a date 
from 1970.


for example they are the packages

vinnie
commons-email
ez-vcard
...
and so on

Can you give me/a hint to fix this behaviour.

Kind regards
--
Mechtilde Stehmann
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: maven-debian-helper: dependency org.kohsuke github-api not found

[Pierre Gruet]

Hi Tobias,

Le 18/05/2024 à 15:28, Tobias Hilbricht a écrit :

Meanwhile I resolved some dependencies of the Zettelkasten app using
https://wiki.debian.org/Java/MavenPkgs/Stable
but some remain - they are in Maven and I have them here locally, but
not in maven-debian:

org.jdesktop:swing-worker:jar:1.1
org.jdesktop:appframework:jar:1.0.3
bibtex:javabib:jar:20040801


Admittedly these three ones are really needed by the software you are 
looking at. Would you consider packaging them?



com.formdev:flatlaf:jar:3.2.5


It is feasible to patch the code to avoid needing this one, as is done 
by one of the patches of the jalview source package for instance. Other 
Look-and-Feel systems are handled by the code of Zettelkasten.




I read https://wiki.debian.org/Java/MavenRepoHelper and found
mh_installjar and thought I do it like this:

root@syke:/home/tobias/zettelkasten# mh_installjar -l --
package=zettelkasten pom.xml
/home/tobias/zettelkasten/target/Zettelkasten.app/Contents/Java/classpa
th/org/jdesktop/swing-worker/1.1/swing-worker-1.1.jar

but it did not work, because I could not install without
debian/control, and to get a debian/control I had to ignore the
dependencies, and they were no longer in pom.xml.


You really don't have to worry about mh_installjar, instead in 
debian/control you should build-depend on maven-debian-helper which will 
do the right things to install the jars provided you fill in the files 
described at

https://wiki.debian.org/Java/MavenDebianHelper
among others the debian/$PACKAGE.poms file.



Help is appreciated, thanks in advance


A quick copyright review lead to no show-stopper, so you can go ahead 
with packaging.


I think the first thing to do is to package the dependencies
org.jdesktop:swing-worker
org.jdesktop:appframework
bibtex:javabib
as they obviously will be needed.


Tobias



Best,

--
Pierre


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Re: maven-debian-helper: dependency org.kohsuke github-api not found

[Tobias Hilbricht]

Meanwhile I resolved some dependencies of the Zettelkasten app using
https://wiki.debian.org/Java/MavenPkgs/Stable
but some remain - they are in Maven and I have them here locally, but
not in maven-debian:

org.jdesktop:swing-worker:jar:1.1
org.jdesktop:appframework:jar:1.0.3
bibtex:javabib:jar:20040801
com.formdev:flatlaf:jar:3.2.5

I read https://wiki.debian.org/Java/MavenRepoHelper and found
mh_installjar and thought I do it like this:

root@syke:/home/tobias/zettelkasten# mh_installjar -l --
package=zettelkasten pom.xml
/home/tobias/zettelkasten/target/Zettelkasten.app/Contents/Java/classpa
th/org/jdesktop/swing-worker/1.1/swing-worker-1.1.jar

but it did not work, because I could not install without
debian/control, and to get a debian/control I had to ignore the
dependencies, and they were no longer in pom.xml.

Help is appreciated, thanks in advance
Tobias

Re: Re: maven-debian-helper: dependency org.kohsuke github-api not found

[Tobias Hilbricht]

Pierre,

thank you for your advice, I will dig into it.

Tobias

Re: maven-debian-helper: dependency org.kohsuke github-api not found

[Pierre Gruet]

Hello Tobias,

Le 17/05/2024 à 15:39, Tobias Hilbricht a écrit :

Dear readers,

as my first packaging project I try to package the Zettelkasten Zkn3
app https://github.com/Zettelkasten-Team/Zettelkasten/tree/main
and can build it successfully with maven on Debian bookworm. However,
trying to package it in a deb with mh_helper, I get this message:

In pom.xml: This dependency cannot be found in the Debian Maven
repository. Ignore this dependency?  org.kohsuke:github-api:jar:1.117
[y/N] >

dpkg --search /usr/share/maven-repo/org/kohsuke/github-api/*/*

dpkg failed to execute successfully

apt-file search /usr/share/maven-repo/org/kohsuke/github-api

apt-file failed to execute successfully

dpkg --search /usr/share/java/github-api.jar

dpkg failed to execute successfully

apt-file search /usr/share/java/github-api.jar

Found perl
Found perl
Found perl
apt-file failed to execute successfully
[error] Package perl does not contain Maven dependency
org.kohsuke:github-api:jar:1.117 but there seem to be a match
If the package contains already Maven artifacts but the names don't
match, try to enter a substitution rule
of the form s/groupId/newGroupId/ s/artifactId/newArtifactId/ jar
s/version/newVersion/ here:

Using the suggestions here https://wiki.debian.org/Java/Packaging/FAQ
I do not find a corresponding debian package, but on maven it exists:
https://mvnrepository.com/artifact/org.kohsuke/github-api


That's right, this artifact is not packaged in Debian. One possibility 
is to package it if it is really needed. However, I think you can skip 
it for your build, the classes of org.kohsuke:github-api do not seem to 
be used anywhere in the software you are interested in. You can simply 
get rid of this dependency by adding the line

org.kohsuke github-api * * * *
to the file debian/maven.ignoreRules (create it, if needed).

Make sure you read
https://wiki.debian.org/Java/MavenDebianHelper
and the examples at
https://wiki.debian.org/Java/Packaging/Maven
Also you can look at the sources of other Debian packages using Maven, 
e.g. junit4, biojava6-live, libdistlib-java, ... to see more examples.


Possibly you will meet other unpackaged artifacts in the dependencies of 
Zettelkasten, in which case it is good to look at how their classes are 
used. If not at all, ignoring the artifact as done above is safe.




How can I satisfy the dependency in a Debian way? Thanks for helpful
pointers

Tobias



Best,

--
Pierre


OpenPGP_signature.asc
Description: OpenPGP digital signature

maven-debian-helper: dependency org.kohsuke github-api not found

[Tobias Hilbricht]

Dear readers,

as my first packaging project I try to package the Zettelkasten Zkn3
app https://github.com/Zettelkasten-Team/Zettelkasten/tree/main
and can build it successfully with maven on Debian bookworm. However,
trying to package it in a deb with mh_helper, I get this message:

In pom.xml: This dependency cannot be found in the Debian Maven
repository. Ignore this dependency?  org.kohsuke:github-api:jar:1.117
[y/N] > 
> dpkg --search /usr/share/maven-repo/org/kohsuke/github-api/*/* 
dpkg failed to execute successfully
> apt-file search /usr/share/maven-repo/org/kohsuke/github-api 
apt-file failed to execute successfully
> dpkg --search /usr/share/java/github-api.jar 
dpkg failed to execute successfully
> apt-file search /usr/share/java/github-api.jar 
Found perl
Found perl
Found perl
apt-file failed to execute successfully
[error] Package perl does not contain Maven dependency
org.kohsuke:github-api:jar:1.117 but there seem to be a match
If the package contains already Maven artifacts but the names don't
match, try to enter a substitution rule
of the form s/groupId/newGroupId/ s/artifactId/newArtifactId/ jar
s/version/newVersion/ here:

Using the suggestions here https://wiki.debian.org/Java/Packaging/FAQ
I do not find a corresponding debian package, but on maven it exists:
https://mvnrepository.com/artifact/org.kohsuke/github-api

How can I satisfy the dependency in a Debian way? Thanks for helpful
pointers

Tobias 

Re: Tomcat 9 removed from Debian 12

[Emmanuel Bourg]

Le 03/05/2024 à 15:46, Thorsten Glaser a écrit :


Full disclosure, while I’m a Debian Developer and team member,
Emmanuel has veto’d the changes to the tomcat9 package in the
past (mostly on the grounds of using adduser… *sigh*).


Still shooting in my direction five years later? Will that ever stop? 
Can't we agree to disagree and move on please? There are other 
challenges in the Debian Java ecosystem that require our focus and energy.




because the javax.* to jakarta.* packages problem


Upstream Tomcat says they can convert that automatically,
but I wouldn’t rely on just that because from experience
I know that upgrading the Tomcat version is always a
breaking change that needs changes to all applications.


The Tomcat migration tool is fairly reliable, but if you find specific 
issues please report them to:


https://github.com/apache/tomcat-jakartaee-migration/

Emmanuel Bourg

Re: Tomcat 9 removed from Debian 12

[Emmanuel Bourg]

Hi Luis,

Le 03/05/2024 à 11:54, Luis Panadero Guardeño a écrit :


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 meme), because the javax.* to jakarta.* packages 
problem. The changes needed to move a web application from javax to 
jackarte aren't simple to do. Specially when *3rd party java 
libraries, aren't migrated yet to jakarta packages* ( for example 
Apache Commons Email ).


You don't have to migrate to the jakarta.* namespace yet, Tomcat 10 
supports both javax and jakarta webapps, just install the 
tomcat-jakartaee-migration package and drop your .war file to the 
webapps-javaee directory, the classes will be automatically converted, see:


https://tomcat.apache.org/migration-10.html#Specification_APIs


I really hope that someone could reconsider to keep both Tomcat 9 and 
Tomcat 10 on Debian 12. If some help it's needed to do this, I could 
help (however I don't have idea how to do this).


This won't happen unfortunately, Tomcat is a security intensive package 
and we can really maintain efficiently only one version per Debian release.



I choose Debian instead of keeping using Ubuntu server, because the 
well know stability of Debian (plus I HATE Canonical weird things and 
forcing snap on everything) and I don't expected this kind of changes 
inside a stable version.


The javax->jakarta transition is annoying for everyone, but you should 
blame Oracle lawyers for this mess, the Debian Java Team is just 
following the trend.


Emmanuel Bourg

Bug#1069970: marked as done (ITP: libeddsa-java -- implementation of EdDSA in Java)

[Debian Bug Tracking System]

Your message dated Sat, 11 May 2024 13:00:12 +
with message-id 
and subject line Bug#1069970: fixed in libeddsa-java 0.3.0-1
has caused the Debian Bug report #1069970,
regarding ITP: libeddsa-java -- implementation of EdDSA in Java
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1069970: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069970
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: wnpp
Severity: wishlist
Owner: Debian-Java team 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-java@lists.debian.org

* Package name: libeddsa-java
  Version : 0.3.0
  Upstream Contact: str4d
* URL : https://github.com/str4d/ed25519-java
* License : CC0-1.0
  Programming Lang: Java
  Description : implementation of EdDSA in Java

This package is needed as a dependency of libmina-sshd-java and of new upstream
versions of jgit. I plan to maintain it in the Debian-Java team and to be its
first uploader.


This implementation of EdDSA is based on the ref10 implementation in SUPERCOP.

There are two internal implementations:
- A port of the radix-2^51 operations in ref10 - fast and constant-time, but
  only useful for Ed25519;
- A generic version using BigIntegers for calculation - a bit slower and not
  constant-time, but compatible with any EdDSA parameter specification.
--- End Message ---
--- Begin Message ---
Source: libeddsa-java
Source-Version: 0.3.0-1
Done: Pierre Gruet 

We believe that the bug you reported is fixed in the latest version of
libeddsa-java, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1069...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Pierre Gruet  (supplier of updated libeddsa-java package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 30 Apr 2024 21:30:13 +0200
Source: libeddsa-java
Binary: libeddsa-java
Architecture: source all
Version: 0.3.0-1
Distribution: experimental
Urgency: medium
Maintainer: Debian Java Maintainers 

Changed-By: Pierre Gruet 
Description:
 libeddsa-java - implementation of EdDSA in Java
Closes: 1069970
Changes:
 libeddsa-java (0.3.0-1) experimental; urgency=medium
 .
   * Initial release (Closes: #1069970)
Checksums-Sha1:
 84284a5ad908571e862dd7b9c98b268d3d472914 2058 libeddsa-java_0.3.0-1.dsc
 1aea53588138fce5459521a7055bce07be33b028 5818956 
libeddsa-java_0.3.0.orig.tar.gz
 df9c3e03e19175ead9e0df753b6667dffe36 3008 
libeddsa-java_0.3.0-1.debian.tar.xz
 44ca5db5cc5b1b94991332124bd167d344b33764 58812 libeddsa-java_0.3.0-1_all.deb
 813f1022aeb8f2b176cfcc74fd5cf1a917b4bdfa 10665 
libeddsa-java_0.3.0-1_amd64.buildinfo
Checksums-Sha256:
 6b7da8be89fcce897cb9fe406313162faa41229190a62d167d2355b4ec471399 2058 
libeddsa-java_0.3.0-1.dsc
 eb2205360fff2c7fb28f0fa96ca7e812622de33408c6f35e043d0b566ef84647 5818956 
libeddsa-java_0.3.0.orig.tar.gz
 c76df2b16c8dbdc8bde3b767172597b5fac6299a9181a1e94bf2a2303abd0340 3008 
libeddsa-java_0.3.0-1.debian.tar.xz
 25e5ae2cc43f6a249d53a3f723e9f8bec34c7af9f1c32cb6dc019e24ba3d8125 58812 
libeddsa-java_0.3.0-1_all.deb
 ef275e14949aa26905791bfe77cbdc98b8349a3629cb462938cc41fdbbdf7d65 10665 
libeddsa-java_0.3.0-1_amd64.buildinfo
Files:
 a0dcfa36d997ea01d569b0912e6725e5 2058 java optional libeddsa-java_0.3.0-1.dsc
 40bf627c1e717925e708265ceaa592d6 5818956 java optional 
libeddsa-java_0.3.0.orig.tar.gz
 f8d16a664cb23bd3611db83b04168991 3008 java optional 
libeddsa-java_0.3.0-1.debian.tar.xz
 e6c8f52ae13f8fe07fccc429e0aaccfa 58812 java optional 
libeddsa-java_0.3.0-1_all.deb
 5f76e59cd71a6de1ed0c93603a144cb3 10665 java optional 
libeddsa-java_0.3.0-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEM8soQxPpC9J9y0UjYAMWptwndHYFAmYxSaYACgkQYAMWptwn
dHZKqg//VBMxbEByDiuFYqQOZO/EfwohIXbAj2+9O8pXBdFSpyKmXmGjB0BNukMP
q2xBGPBd+q4zDucH8IwhGr1mL+KJzT1jBxBtOR1k9OCWKWyKgt+2YnM5UBONLV6F
PZnIhKxpaSyA5t6ZlX7vH6wqsEgRsQlqpVaaPJJcokwNgQ3eSNL+7dctut4b6rz1
3UzyYT5KRra907FWnRmVZpgMMw80Zmy+F3WIks7ZyETmqovFoSwJpYOYx07IxAt3
G6AAobYEMtfG+/Qa0AN99KBWZGc/g5Ffg7DSg9rllC662kkg/IWCLbFvRIZ2S0PP
UbsbkTLk3dMT5XOW0nu3s2KpH3nb8brJGDi00AFWA6qm0W/DrwvRcYmrI4fHoQIm

Re: Tomcat 9 removed from Debian 12

[Luis Panadero Guardeño]

Thanks! I would take a look.

A think that I found different when I made the effort to move from 
Ubuntu Server to Debian, was that on Debian not had removed the tomcat 
version. Ubuntu Server, had a "tomcatX" user/group that match the tomcat 
installed. Also, some old Ubuntu Server LTS had two versions of tomcat 
at same time on his repositories without issues (7 and 8.5).



El 3/5/24 a las 15:46, Thorsten Glaser escribió:

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 externally,
and I have users who use it for their customers so it’s used
in production, with sysvinit instead of systemd, even.

The packages are here:
http://www.mirbsd.org/~tg/Debs/dists/bookworm/wtf/Pkgs/tomcat9/

Don’t just install them from there, though, that would not
be secured. Ideally, you’d use the Debian package “extrepo”
to enable the “wtf-lts” repository, then pin it so that only
the packages tomcat9{,-admin,-common,-docs,-examples,-user}
and libtomcat9-{,embed-}java are considered from that repo.

Alternatively,http://www.mirbsd.org/~tg/Debs/debidx.htm
contains links to manual installation instructions, but you
might still want to consider pinning as the repo contains
other packages as well.

Full disclosure, while I’m a Debian Developer and team member,
Emmanuel has veto’d the changes to the tomcat9 package in the
past (mostly on the grounds of using adduser… *sigh*). I also
haven’t tested installing it together with tomcat10, and I
personally don’t test on bookworm (but others do), only on
bullseye and sometimes buster.


because the javax.* to jakarta.* packages problem

Upstream Tomcat says they can convert that automatically,
but I wouldn’t rely on just that because from experience
I know that upgrading the Tomcat version is always a
breaking change that needs changes to all applications.

bye,
//mirabilos

--

/Luis Panadero Guardeño/
Departamento de Informática
luis.panad...@digibis.com

DIGIBÍS S.L.
DIGIBÍS S.L.U.

C/ Alenza, 4, 5ª planta.
28003 Madrid
Tf. 91 432 08 88 . Fax 91 432 11 13

http://www.digibis.com

Certificado ISO 9001.
No imprimir si no es necesario. Protejamos el Medio Ambiente

En cumplimiento de la LOPD y la LSSI, le informamos de que sus datos 
personales son incorporados a un fichero, titularidad de DIGIBÍS, 
S.L.U., con el fin de ofrecerle información sobre servicios que pueden 
ser de su interés. Podrá ejercitar sus derechos ARCO (de acceso, 
rectificación, cancelación y oposición) mediante un escrito dirigido a 
digi...@digibis.com , con copia del DNI o documento identificativo 
sustitutorio.
En caso de querer darse de baja pinche aquí 
.

Re: Seeking help with Java compile heap memory out-of-memory error on armel for zeroc-ice build

[tony mancill]

On Fri, May 03, 2024 at 09:13:09PM -0400, Chris Knadle wrote:
> Thank you this sounds promising.
> 
> Would you consider this option in debian/rules to be safe to deploy to all
> architectures?
> 
> i.e. would adding this globally be an acceptable bug fix?

Hi Chris,

Yes, I think this is suitable for all builds.

Cheers,
tony


signature.asc
Description: PGP signature

Re: Seeking help with Java compile heap memory out-of-memory error on armel for zeroc-ice build

[Chris Knadle]

Thank you this sounds promising.

Would you consider this option in debian/rules to be safe to deploy to 
all architectures?


i.e. would adding this globally be an acceptable bug fix?

Cheers,

Chris

On 5/3/24 00:06, tony mancill wrote:

On Thu, May 02, 2024 at 01:54:51PM +1200, Vladimir Petko wrote:

Unfortunately I do not have an armel box accessible, but maybe
tweaking Gradle heap size through 'export GRADLE_OPTS=-Xmx'
might help?
I have tried with export GRADLE_OPTS=-Xmx512M and the package was
built successfully.

Hi Chris,

If it saves you any time (it's a long build), I was able to build
zeroc-ice successfully on armel after adding Vladimir's suggestion to
debian/rules.

Cheers,
tony


--
Chris Knadle
chris.kna...@coredump.us

Re: Tomcat 9 removed from Debian 12

[Thorsten Glaser]

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 externally,
and I have users who use it for their customers so it’s used
in production, with sysvinit instead of systemd, even.

The packages are here:
http://www.mirbsd.org/~tg/Debs/dists/bookworm/wtf/Pkgs/tomcat9/

Don’t just install them from there, though, that would not
be secured. Ideally, you’d use the Debian package “extrepo”
to enable the “wtf-lts” repository, then pin it so that only
the packages tomcat9{,-admin,-common,-docs,-examples,-user}
and libtomcat9-{,embed-}java are considered from that repo.

Alternatively, http://www.mirbsd.org/~tg/Debs/debidx.htm
contains links to manual installation instructions, but you
might still want to consider pinning as the repo contains
other packages as well.

Full disclosure, while I’m a Debian Developer and team member,
Emmanuel has veto’d the changes to the tomcat9 package in the
past (mostly on the grounds of using adduser… *sigh*). I also
haven’t tested installing it together with tomcat10, and I
personally don’t test on bookworm (but others do), only on
bullseye and sometimes buster.

> because the javax.* to jakarta.* packages problem

Upstream Tomcat says they can convert that automatically,
but I wouldn’t rely on just that because from experience
I know that upgrading the Tomcat version is always a
breaking change that needs changes to all applications.

bye,
//mirabilos
-- 
Infrastrukturexperte • Qvest Digital AG
Am Dickobskreuz 10, D-53121 Bonn • https://www.qvest-digital.com/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 18196 • USt-ID (VAT): DE274355441
Vorstand: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Vorsitzender Aufsichtsrat: Peter Nöthen

Tomcat 9 removed from Debian 12

[Luis Panadero Guardeño]

Hi all,

I just has been affected by this now. I was to updated a fleet of old 
VMs with Ubuntu 18.04 LTS with Tomcat 7 to Debian 12 with Tomcat 9 .


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 meme), because the javax.* to jakarta.* packages problem. 
The changes needed to move a web application from javax to jackarte 
aren't simple to do. Specially when *3rd party java libraries, aren't 
migrated yet to jakarta packages* ( for example Apache Commons Email ). 
I really hope that someone could reconsider to keep both Tomcat 9 and 
Tomcat 10 on Debian 12. If some help it's needed to do this, I could 
help (however I don't have idea how to do this).


I choose Debian instead of keeping using Ubuntu server, because the well 
know stability of Debian (plus I HATE Canonical weird things and forcing 
snap on everything) and I don't expected this kind of changes inside a 
stable version. I was expecting that Tomcat 9 would be removed in Debian 
13, specially when I first configured our Debian 12 virtual machine 
template, Tomcat 9 was yet there.


PD: Sorry, if I write something that sounds weird on English, this isn't 
my mother language.


--

/Luis Panadero Guardeño/
Departamento de Informática
luis.panad...@digibis.com

DIGIBÍS S.L.
DIGIBÍS S.L.U.

C/ Alenza, 4, 5ª planta.
28003 Madrid
Tf. 91 432 08 88 . Fax 91 432 11 13

http://www.digibis.com

Certificado ISO 9001.
No imprimir si no es necesario. Protejamos el Medio Ambiente

En cumplimiento de la LOPD y la LSSI, le informamos de que sus datos 
personales son incorporados a un fichero, titularidad de DIGIBÍS, 
S.L.U., con el fin de ofrecerle información sobre servicios que pueden 
ser de su interés. Podrá ejercitar sus derechos ARCO (de acceso, 
rectificación, cancelación y oposición) mediante un escrito dirigido a 
digi...@digibis.com , con copia del DNI o documento identificativo 
sustitutorio.
En caso de querer darse de baja pinche aquí 
.

Re: Seeking help with Java compile heap memory out-of-memory error on armel for zeroc-ice build

[tony mancill]

On Thu, May 02, 2024 at 01:54:51PM +1200, Vladimir Petko wrote:
> Unfortunately I do not have an armel box accessible, but maybe
> tweaking Gradle heap size through 'export GRADLE_OPTS=-Xmx'
> might help?
> I have tried with export GRADLE_OPTS=-Xmx512M and the package was
> built successfully.

Hi Chris,

If it saves you any time (it's a long build), I was able to build
zeroc-ice successfully on armel after adding Vladimir's suggestion to
debian/rules.

Cheers,
tony


signature.asc
Description: PGP signature

Re: Seeking help with Java compile heap memory out-of-memory error on armel for zeroc-ice build

[Vladimir Petko]

Hi,

Unfortunately I do not have an armel box accessible, but maybe
tweaking Gradle heap size through 'export GRADLE_OPTS=-Xmx'
might help?
I have tried with export GRADLE_OPTS=-Xmx512M and the package was
built successfully.

Best Regards,
 Vladimir.

On Wed, May 1, 2024 at 4:08 PM Chris Knadle  wrote:
>
> Greetings.
>
> I'm looking for some help for a build failure on armel related to
> compiling Java that has cropped up in the last couple of weeks. This is
> keeping Debian packages zeroc-ice as well as mumble from transitioning
> to Testing.
>
> The compile seems to fail during a Gradle / Java memory check and seems
> to be specific to armel.
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069538
>
> I've done additional test builds on 2 armel Debian porter boxes and the
> error is repeatable.
>
> > :test:compileJava
> > Putting task artifact state for task ':test:compileJava' into context
> > took 0.0 secs.
> > Up-to-date check for task ':test:compileJava' took 47.549 secs. It is
> > not up-to-date because:
> >   No history is available.
> > All input files are considered out-of-date for incremental task
> > ':test:compileJava'.
> > Use of target 1.7 is no longer supported, switching to 8
> > Use of source 1.7 is no longer supported, switching to 8
> > Compiling with JDK Java compiler API.
> > Failed to execute
> > org.gradle.process.internal.health.memory.DefaultMemoryManager$MemoryCheck@12c1b75.
> > An exception has occurred in the compiler (17.0.11). Please file a bug
> > against the Java compiler via the Java bug reporting page
> > (https://bugreport.java.com) after checking the Bug Database
> > (https://bugs.java.com) for duplicates. Include your program, the
> > following diagnostic, and the parameters passed to the Java compiler
> > in your report. Thank you.
> > java.lang.OutOfMemoryError: Java heap space
> > :test:compileJava FAILED
> > :test:compileJava (Thread[Task worker for ':',5,main]) completed. Took
> > 48 mins 58.651 secs.
>
> I'd like to know how to fix or work around this bug if possible.
>
> Thanks
>
> --
>
> Chris Knadle
> chris.kna...@coredump.us
>

Seeking help with Java compile heap memory out-of-memory error on armel for zeroc-ice build

[Chris Knadle]

Greetings.

I'm looking for some help for a build failure on armel related to 
compiling Java that has cropped up in the last couple of weeks. This is 
keeping Debian packages zeroc-ice as well as mumble from transitioning 
to Testing.


The compile seems to fail during a Gradle / Java memory check and seems 
to be specific to armel.


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069538

I've done additional test builds on 2 armel Debian porter boxes and the 
error is repeatable.



:test:compileJava
Putting task artifact state for task ':test:compileJava' into context 
took 0.0 secs.
Up-to-date check for task ':test:compileJava' took 47.549 secs. It is 
not up-to-date because:

  No history is available.
All input files are considered out-of-date for incremental task 
':test:compileJava'.

Use of target 1.7 is no longer supported, switching to 8
Use of source 1.7 is no longer supported, switching to 8
Compiling with JDK Java compiler API.
Failed to execute 
org.gradle.process.internal.health.memory.DefaultMemoryManager$MemoryCheck@12c1b75.
An exception has occurred in the compiler (17.0.11). Please file a bug 
against the Java compiler via the Java bug reporting page 
(https://bugreport.java.com) after checking the Bug Database 
(https://bugs.java.com) for duplicates. Include your program, the 
following diagnostic, and the parameters passed to the Java compiler 
in your report. Thank you.

java.lang.OutOfMemoryError: Java heap space
:test:compileJava FAILED
:test:compileJava (Thread[Task worker for ':',5,main]) completed. Took 
48 mins 58.651 secs.


I'd like to know how to fix or work around this bug if possible.

Thanks

--

Chris Knadle
chris.kna...@coredump.us

Bug#1069970: ITP: libeddsa-java -- implementation of EdDSA in Java

[Pierre Gruet]

Package: wnpp
Severity: wishlist
Owner: Debian-Java team 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-java@lists.debian.org

* Package name: libeddsa-java
  Version : 0.3.0
  Upstream Contact: str4d
* URL : https://github.com/str4d/ed25519-java
* License : CC0-1.0
  Programming Lang: Java
  Description : implementation of EdDSA in Java

This package is needed as a dependency of libmina-sshd-java and of new upstream
versions of jgit. I plan to maintain it in the Debian-Java team and to be its
first uploader.


This implementation of EdDSA is based on the ref10 implementation in SUPERCOP.

There are two internal implementations:
- A port of the radix-2^51 operations in ref10 - fast and constant-time, but
  only useful for Ed25519;
- A generic version using BigIntegers for calculation - a bit slower and not
  constant-time, but compatible with any EdDSA parameter specification.

Re: Removing freeplane 1.7.x from Debian?

[Emmanuel Bourg]

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 to state your disagreement. IMHO upstreams providing 
packages contribute to the success of the Debian ecosystem, which is a 
good thing overall.


Emmanuel Bourg

Re: Removing freeplane 1.7.x from Debian?

[Felix Natter]

hello Sebastiaan, Tony, Thorsten, Emmanuel,

Sebastiaan Couwenberg  writes:
> On 4/1/24 8:49 AM, Felix Natter wrote:
>> tony mancill  writes:
>>> In my opinion we should be remove the outdated freeplane package from
>>> Debian.
>> the only thing that speaks against this is the user comment in #1030150
>> [1]. Is it true that "as Debian (and many derivates) still ship with old
>> JDK"? [2]
>
> It might be feasible to patch freeplane to use Maven for the Debian package
> build. This was suggested in the Gradle packaging status thread some time
> ago [0].
>
> Osmosis 0.49 also required a more recent Gradle to build, and adding a
> patch to use Maven for the Debian package build was reasonably simple.
>
> [0] https://lists.debian.org/debian-java/2022/08/msg00010.html

thank you for the suggestion. In addition to a complex gradle build
system [1] using the latest features, there are also a number of new
dependencies. The biggest one (I think) is twemoji [2].

[1]
https://github.com/freeplane/freeplane/blob/1.11.x/freeplane/build.gradle etc.

[2] #878875 (Freeplane >= 1.9 can add any unicode emoji as an icon)

I *might* succeed packaging Freeplane with maven, but then it might not
be compatible at all due to some missing gradle build system quirks,
which I think is worse than using the upstream .deb.

@Thorsten: Yes, having a 100% free build in Debian is
nice, but I do not see this happening :( I agree with @Emmanuel that the
upstream .deb is the best solution we can get (and given the nature of
java, this is extremely easy to install for users and upstream to provide) :)

However, in #1030150 Alex says:

> as Debian (and many derivates) still ship with old JDK, there is in my eyes 
> no reason to remove
> Freeplane because of that. Also it would be a shame if it maybe would vanish 
> from it, in that way.

Is this really true for Debian [3]?

[3]
https://packages.debian.org/search?keywords=jre=names=stable=all

I think that if we do not remove freeplane from Debian, people are
"forced" to keep old unsupported JDK/JRE versions, which is a security
risk IMHO. Do you agree, or is an outdated Debian package even more
secure than an up-to-date upstream package as "Rpnpif" says in #1030150:

> I would agree with alex. Encouraging users to take packages out of
> Debian's repositories is a security risk for their OS. The current case
> with xz demonstrates this. My opinion does not mean that upstream should
> not offer an alternative and packages.

Cheers and Best Regards,
Felix
--
Felix Natter

Re: Removing freeplane 1.7.x from Debian?

[Thorsten Glaser]

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 :-)

Re: Removing freeplane 1.7.x from Debian?

[Emmanuel Bourg]

Le 31/03/2024 à 20:32, tony mancill a écrit :


What do you think?


In my opinion we should be remove the outdated freeplane package from
Debian.


+1, even if fixing the security manager issue is easy, I'm tempted to 
think there is little benefit packaging freeplane ourself since upstream 
already provides a package.


Emmanuel Bourg

Re: Removing freeplane 1.7.x from Debian?

[Sebastiaan Couwenberg]

On 4/1/24 8:49 AM, Felix Natter wrote:

tony mancill  writes:

In my opinion we should be remove the outdated freeplane package from
Debian.


the only thing that speaks against this is the user comment in #1030150
[1]. Is it true that "as Debian (and many derivates) still ship with old
JDK"? [2]


It might be feasible to patch freeplane to use Maven for the Debian 
package build. This was suggested in the Gradle packaging status thread 
some time ago [0].


Osmosis 0.49 also required a more recent Gradle to build, and adding a 
patch to use Maven for the Debian package build was reasonably simple.


[0] https://lists.debian.org/debian-java/2022/08/msg00010.html

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Re: Removing freeplane 1.7.x from Debian?

[Felix Natter]

tony mancill  writes:

> On Sun, Mar 31, 2024 at 04:53:17PM +0200, Felix Natter wrote:
>> Dear java team,
>>
>> the current freeplane package only works with an old JRE [1].
>> [1] https://bugs.launchpad.net/ubuntu/+source/freeplane/+bug/2034752
>>
>> I think that not many users figure out how to set JAVA_CMD or
>> FREEPLANE_JAVA_HOME, and even if they did, it would be a security risk
>> due to an old JRE. I cannot package freeplane 1.11.x because it requires
>> gradle >= 7.x.
>>
>> Since it is easy to install the upstream .deb...
>> - https://sourceforge.net/projects/freeplane/
>> - select "Files"
>> - select "freeplane stable"
>> - select freeplane_1.11.11~upstream-1_all.deb
>> - install with "sudo apt install
>>   /path/to/freeplane_1.11.11~upstream-1_all.deb"
>>
>> ... I wonder whether it is better to remove freeplane now?
>> What do you think?
>
> Hi Felix,

hello Tony,

> In my opinion we should be remove the outdated freeplane package from
> Debian.

the only thing that speaks against this is the user comment in #1030150
[1]. Is it true that "as Debian (and many derivates) still ship with old
JDK"? [2]

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030150#25
[2] 
https://packages.debian.org/search?keywords=jre=names=stable=all

Cheers and Best Regards,
Felix

--
Felix Natter
debian/rules!

Re: Removing freeplane 1.7.x from Debian?

[tony mancill]

On Sun, Mar 31, 2024 at 04:53:17PM +0200, Felix Natter wrote:
> Dear java team,
> 
> the current freeplane package only works with an old JRE [1].
> [1] https://bugs.launchpad.net/ubuntu/+source/freeplane/+bug/2034752
> 
> I think that not many users figure out how to set JAVA_CMD or
> FREEPLANE_JAVA_HOME, and even if they did, it would be a security risk
> due to an old JRE. I cannot package freeplane 1.11.x because it requires
> gradle >= 7.x.
> 
> Since it is easy to install the upstream .deb...
> - https://sourceforge.net/projects/freeplane/
> - select "Files"
> - select "freeplane stable"
> - select freeplane_1.11.11~upstream-1_all.deb
> - install with "sudo apt install
>   /path/to/freeplane_1.11.11~upstream-1_all.deb"
> 
> ... I wonder whether it is better to remove freeplane now?
> What do you think?

Hi Felix,

In my opinion we should be remove the outdated freeplane package from
Debian.

Cheers,
tony


signature.asc
Description: PGP signature

Removing freeplane 1.7.x from Debian?

[Felix Natter]

Dear java team,

the current freeplane package only works with an old JRE [1].
[1] https://bugs.launchpad.net/ubuntu/+source/freeplane/+bug/2034752

I think that not many users figure out how to set JAVA_CMD or
FREEPLANE_JAVA_HOME, and even if they did, it would be a security risk
due to an old JRE. I cannot package freeplane 1.11.x because it requires
gradle >= 7.x.

Since it is easy to install the upstream .deb...
- https://sourceforge.net/projects/freeplane/
- select "Files"
- select "freeplane stable"
- select freeplane_1.11.11~upstream-1_all.deb
- install with "sudo apt install
  /path/to/freeplane_1.11.11~upstream-1_all.deb"

... I wonder whether it is better to remove freeplane now?
What do you think?

Best Regards,
Felix
--
Felix Natter

RFS: precis/1.1.0-1 [ITP] -- Java implementation of the PRECIS Framework

['Matthew Fennell]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "precis":

 * Package name : precis
   Version  : 1.1.0-1
   Upstream contact : Christian Schudt
 * URL  : https://github.com/sco0ter/precis
 * License  : Expat
 * Vcs  : https://salsa.debian.org/java-team/precis
   Section  : java

The source builds the following binary packages:

  libprecis-java - Java implementation of the PRECIS Framework

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/precis/

Alternatively, you can download the package with 'dget' using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/p/precis/precis_1.1.0-1.dsc

Changes for the initial release:

 precis (1.1.0-1) unstable; urgency=low
 .
   * Initial release. Closes: #1067524

Regards,
-- 
  Matthew Fennell

Re: Request to join Java team

[Markus Koschany]

Hi Matthew,

Am Freitag, dem 29.03.2024 um 08:45 + schrieb 'Matthew Fennell:
> [...]
> * Please may I get approved to join the java team on Salsa? My username is
>   matthew-fennell.

I have just added you to the Java team on Salsa

> * Please may someone also use the script to create "precis" on Salsa, and
> then
>   (ideally) give me access to push to the repository?

...and created the precis repository. You should be able to push your packaging
work now.

> 
> Once the package is done, I'll look to raise an RFS to this list. This is my
> first Debian package, so it might need more feedback than normal, but I hope
> the fact it's a simple library will counteract this :)

No problem. If you have any questions, feel free to ask them on the list.

Cheers,

Markus


signature.asc
Description: This is a digitally signed message part

Request to join Java team

['Matthew Fennell]

Hi,

I would like to get into packaging of Debian Java applications. This is mainly
to eventually get caas [1] into Debian, which is a useful tool to test XMPP
server compliance.

caas has a few dependencies, the main one being babbler [2]. This in turn
depends on precis [3], which is a very small and simple library, and I figured
a good place to get started. I'd like to start by packaging this simple library
end-to-end, before continuing with some more complicated ones.

If this all sounds ok, I need your help with a couple of things:

* Please may I get approved to join the java team on Salsa? My username is
  matthew-fennell.
* Please may someone also use the script to create "precis" on Salsa, and then
  (ideally) give me access to push to the repository?

Once the package is done, I'll look to raise an RFS to this list. This is my
first Debian package, so it might need more feedback than normal, but I hope
the fact it's a simple library will counteract this :)

Thanks for your time!
Matthew

[1] Bug #959816
[2] https://sco0ter.bitbucket.io/babbler/
[3] Bug #1067524

Re: Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf

[Thorsten Glaser]

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 :-)

Re: Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf

[Wookey]

On 2024-03-27 22:30 +, Thorsten Glaser wrote:
> >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 unchanged)
> with just control.tar.xz/control changed to allow installation given
> the relevant libraries were already rebuilt for t64.

OK. I get it now.

> > but actually having an openjdk binaries is very useful
> >too to satisfy the self-dependency without more faff.
> 
> Yes, that was their purpose.

And it worked beatifully. Thanks.

armhf and armel uploaded and accepted half an hour ago (armel built by Andrey 
Rakhmatullin)

I'll try doing openjdk-20 next.


Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Re: Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf

[Thorsten Glaser]

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 unchanged)
with just control.tar.xz/control changed to allow installation given
the relevant libraries were already rebuilt for t64.

> but actually having an openjdk binaries is very useful
>too to satisfy the self-dependency without more faff.

Yes, that was their purpose.

>I'm no java expert so if anything breaks or it gets more complicated
>than 'get the right build-deps in (with care for t64-libs) somehow' I
>will indeed be asking questions :-)

Right. I’m no expert either, though :/

>> What was the actual problem with uploading the images you built? Just
>> not having any corresponding source? Or something more complicated?
>
>Answering my own question: There have been a couple of new openjdk-17
>uploads (latest is: 17_17.0.11~7ea-1) so Thorsten's bootstrap build
>(17.0.10+7-1) is out of date.

Yes, exactly: dak lacked the 17.0.10+7.orig.tar.* because sid already
moved to 17.0.11~7ea.orig.tar.*

>So I now have all the pieces (on armhf, not checked armel yet but
>hopefully it matches)

Depends, but 'apt install /tmp/*.deb' will tell you ;-)

>The build failed:
>
>An exception has occurred in the compiler (17.0.10). Please file a bug against 
>the Java compiler via the Java bug reporting page (https://bugreport.java.com) 
>after checking the Bug Database (https://bugs.java.com) for duplicates. 
>Include your program, the following diagnostic, and the parameters passed to 
>the Java compiler in your report. Thank you.
>java.io.UncheckedIOException: java.nio.file.FileSystemException: .: Value too 
>large for defined data type
>
>Don't worry about this. It's a an issue to do with building for 32 bit
>inside qemu on a 64-bit machine. I'll stop doing that and use real
>hardware :-/

Ouch. I was just wondering which filesystem you used, but yes,
there’s that known combined qemu/kernel/libc issue which cbmuser
is also constantly running into. I think switching to… sgixfs I
think? also makes it work, but I’m not sure.

https://sourceware.org/bugzilla/show_bug.cgi?id=23960#c73
sgixfs and btrfs, yeah, ext4 is problematic. But apparently,
LFS should fix this but Java is again special in that it’s
still problematic there.

Were you using qemu-user? qemu-system has its own kernel and
“should” be fine, modulo the usual qemu issues. Real hardware
is better (for many architectures even necessary).

Good luck,
//mirabilos
-- 
 exceptions: a truly awful implementation of quite a nice idea.
 just about the worst way you could do something like that, afaic.
 it's like anti-design.   that too… may I quote you on that?
 sure, tho i doubt anyone will listen ;)

Re: Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf

[Wookey]

On 2024-03-27 15:27 +, Wookey wrote:
> On 2024-03-26 22:28 +, Thorsten Glaser wrote:
> 
> > I hacked that, and I tried to do armel and armhf as well but
> > dak stopped me, whereas mini-dak was not as strict.
> 
> What was the actual problem with uploading the images you built? Just
> not having any corresponding source? Or something more complicated?

Answering my own question: There have been a couple of new openjdk-17
uploads (latest is: 17_17.0.11~7ea-1) so Thorsten's bootstrap build 
(17.0.10+7-1) is out of
date.

But it does a great job of filling the self-dependency so I can build the 
current version.
So I now have all the pieces (on armhf, not checked armel yet but hopefully it 
matches)

Building now...


Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Re: Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf

[Wookey]

On 2024-03-26 22:28 +, Thorsten Glaser wrote:

> I hacked that, and I tried to do armel and armhf as well but
> dak stopped me, whereas mini-dak was not as strict.

What was the actual problem with uploading the images you built? Just
not having any corresponding source? Or something more complicated?

It seems to me you've done all the hard work - we just need to work
out how to get those packages into the archive.  Maybe that needs a
rebuild with corresponding source? Although if we already have the
source just making a new changes file with all the right piece in
should be enough, should it not?

or am I missing something?

Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Re: Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf

[Thorsten Glaser]

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 adep and idep but not the profiles, unfortunately,
and these can be key in ordering decisions).

>another blocked chain with ghostscript,cups and libgtk2 conflicting
>about their t64 status.

You do need the t64 versions of all that, and the latest openjdk-17
fixed the issue with libcups2 (Ubuntu initially forgot to move that
to t64 while Debian did that early, and openjdk-?? followed the
former).

> apt : Depends: libgnutls30 (>= 3.8.1) but it is not going to be installed

You should get that rebuilt, yes.
On the other hand, if everything else is falling into place, it’s
not a problem for apt to uninstall itself just in that one build
chroot ☻

> libasound2t64 : Breaks: libasound2 (< 1.2.11-1) but 1.2.10-3 is to be 
> installed
> libcups2t64 : Breaks: libcups2 (< 2.4.7-1.2) but 2.4.7-1+b1 is to be installed
> libnettle8t64 : Breaks: libnettle8 (< 3.9.1-2.2) but 3.9.1-2 is to be 
> installed

These are fine.

> libcups2 : Depends: libgnutls30 (>= 3.8.1) but it is not going to be installed

Force that away; nothing from this is actually used during the
openjdk build in a way sufficient to impact the build.

>But dose now says there is a solution, unlike last week.

Oh, dose… right… here I was checking all of them manually ^^
(which did give me a better impression of where to break the
cycles and what to upload earlier).

>> openjdk-21 is in a similar situation, build-depending on itself, while
>> openjdk-22 and openjdk-23 build-depend on -21 and -22 respectively.

>I presume the same, but don't actually know how old a java you can use
>to bootstrap each newer java. Is it always just one version?

AIUI it’s always just one version; I know it was so until 17,
but I don’t think this has loosened (I asked in IRC, but got
no answer until I went to sleep).

>> Presumably once we have a single OpenJDK version that is installable,
>> it would be possible to step through 18,19,20,21 building each version
>> with the previous one.

You’d have to patch them to both address the t64 issues and
make it imply nocheck (or quinn-diff doesn’t pick it up as
installable).

It’s best to get at least 17 and 21 (which AIUI is the one
we’ll want for trixie?) built this way. I think, unless
users complain, we can these days go without 8 and probably
even without 11.

(You’d be surprised at the amount of users wanting 8, so
I now provide those in a private repo of mine, but so far
amd64/i386-only has sufficed for those. For the purposes
for which 8 is still in sid, dropping armel and armhf will
_most likely_ also suffice; ELTS still wants them, but
rebuilt in jessie and stretch chroots so there is no re‐
bootstrapping to be done.)

Re: Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf

[Wookey]

On 2024-03-26 10:35 +, Simon McVittie wrote:
> It seems that some of the dependency chains for packages that are still
> waiting to be rebuilt on armel,armhf now end at openjdk-17, which is the
> default Java version for most architectures and Build-Depends on itself
> (with an alternative dependency on openjdk-16, but that no longer exists).
> evolution-data-server -> libphonenumber-dev is an example.
> 
> Are the ARM or Java teams intending to re-bootstrap openjdk-17 somehow?

I looked at this last week, but got stuck because openjdk-17's
build-deps included graphviz which was also uninstallable and led to
another blocked chain with ghostscript,cups and libgtk2 conflicting about their 
t64 status.

Checking again now, apt still complains:
The following packages have unmet dependencies:
 apt : Depends: libgnutls30 (>= 3.8.1) but it is not going to be installed
 libasound2t64 : Breaks: libasound2 (< 1.2.11-1) but 1.2.10-3 is to be installed
 libcups2 : Depends: libgnutls30 (>= 3.8.1) but it is not going to be installed
 libcups2t64 : Breaks: libcups2 (< 2.4.7-1.2) but 2.4.7-1+b1 is to be installed
 libnettle8t64 : Breaks: libnettle8 (< 3.9.1-2.2) but 3.9.1-2 is to be installed

But dose now says there is a solution, unlike last week.

So it should be possible to get the dependencies in place (without
unreasonable jiggery-pokery) and bootstrap it. I'll have another go tomorrow.

> Or do maintainers of packages that build both a C/C++ library and Java
> bindings from a single source package need to disable its Java bindings
> on the affected architectures, either temporarily or permanently?

Some of that might still be expedient, but hopefully we can get a t64
java soon and it won't be necessary. We have to do that sooner or later anyway.

> openjdk-21 is in a similar situation, build-depending on itself, while
> openjdk-22 and openjdk-23 build-depend on -21 and -22 respectively.
> Presumably once we have a single OpenJDK version that is installable,
> it would be possible to step through 18,19,20,21 building each version
> with the previous one.

I presume the same, but don't actually know how old a java you can use
to bootstrap each newer java. Is it always just one version?

Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Re: Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf

[Thorsten Glaser]

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 Europe if you don't mind paying the VAT. I
>think you will be the fourth or fifth Debian maintainer I've sent
>hardware to.

So sending from outside the eurozone, that can get tricky fast
(depending on the value, they also want import duties on top),
I think that might just be overkill for a oneshot helping out.
Let’s see if I can get an account on a project box first, or
work with someone who has. (I’m not intending to add going into
ARM development on top of what I already try to balance… right
now, I’m mostly helping m68k through t64, so Adrian does not
burn out, he’s also got sh4 and powerpc to do, and the whole
rest of d-ports with the mini-dak trouble of keeping old binary
packages around.)

But I do thank you for that offer.

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Re: Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf

[Jeffrey Walton]

On Tue, Mar 26, 2024 at 7:44 PM Thorsten Glaser
 wrote:
>
> 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). Both work, but I
> >don't use them much anymore. I've mostly moved on to Aarch64.
>
> That is certainly an option, if you don’t want them any more and want
> to ship them to .de, although it’ll likely take longer than just getting
> access on a suitable project machine. RAM is tight on them, but with
> swap the compiling should work. Both seem to have serial console, good.

Nothing beats a native compile in your basement. It sure beats the
snot out of a cross-compile, or an emulator like a Debian QEMU/Chroot.
I switched to the dev boards after getting frustrated with
cross-compiles. (So many makefiles are poorly written, and can't
handle a simple cross-compile).

And I run a first class swap file on all of my dev boards. SDcards are
easy to replace. A SDcard lasts 6 to 9 months before you start seeing
unexplained file system errors. That's around the time you know it's
time to replace the SDcard.

> Do they run stock Debian armhf?

So the CubieTruck is embarrassingly down level:

cubietruck:~$ lsb_release -a
Distributor ID: Linaro
Description:Linaro 14.04
Release:14.04
Codename:   trusty

The Wandboard is doing better:

wandboard:~$ lsb_release -a
Distributor ID: Debian
Description:Debian GNU/Linux 11 (bullseye)
Release:11
Codename:   bullseye

I don't mind shipping to Europe if you don't mind paying the VAT. I
think you will be the fourth or fifth Debian maintainer I've sent
hardware to.

Jeff

Re: Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf

[Thorsten Glaser]

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). Both work, but I
>don't use them much anymore. I've mostly moved on to Aarch64.

That is certainly an option, if you don’t want them any more and want
to ship them to .de, although it’ll likely take longer than just getting
access on a suitable project machine. RAM is tight on them, but with
swap the compiling should work. Both seem to have serial console, good.

Do they run stock Debian armhf?

Thanks,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Re: Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf

[Jeffrey Walton]

On Tue, Mar 26, 2024 at 6:30 PM Thorsten Glaser  wrote:
>
> [...]
>
> The options for the armel/armhf porters are to either get the
> .debs from me, install them in a chroot, and then the other B-D,
> and rebuild the packages, or to use dpkg --force-depends to
> install the dependencies (which makes it hard to use apt to
> install the other ones unless you also edit /var/lib/dpkg/status
> by hand first, something I was already used to from my reviving
> m68k back in 2012–2015) into the chroot then rebuild there.
>
> I will gladly help if it’s made possible for me to help. This
> cannot be done on a porterbox because it’s still impossible to
> either install arbitrary .debs into a chroot there or to obtain
> root in the chroot to be able to force installation in the absence
> of some Depends.
>
> So if you have a fast armhf box or two, ideally with chroots
> already made for sid, which you don’t mind temporarily giving
> me root on, I’m in, otherwise I’ll answer questions from these
> doing that work if needed.

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). Both work, but I
don't use them much anymore. I've mostly moved on to Aarch64.

Provide your postal mailing address, if you want them.

Jeff

Re: Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf

[Thorsten Glaser]

-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 tried to do armel and armhf as well but
dak stopped me, whereas mini-dak was not as strict.

I did the observation that doko changed their source packages
to have the binaries Recommend instead of Depend on the libraries
in question. (Unfortunately neither before the transition started
nor coordinated with the openjdk-8 maintainer (me).)

I downloaded the latest binary packages of openjdk-{8,11,17,21},
changed all references to the libraries in question to refer to
their t64 counterparts, bumped the version number, repacked the
.deb files and updated the .changes files as if to do a binNMU.
After uploading, I used wanna-build to set the priority high so
they get rebuilt before someone considers using them.

mini-dak accepted these, but dak requires that the archive has
the corresponding source available, and since new versions (the
part before the Debian hyphen-minus) had already been uploaded,
it did not have them at hand any more either.

The rebuild process succeeded, as openjdk building itself does
indeed not use the libraries in question (or at least those
parts of their interface that are time_t-relevant).

I don’t have access to a fast armel machine (only an RPi 1) and
to no armhf machine, so I’m not in the situation of throwing the
.debs from above into a chroot to rebuild the current sources.
I *was* considering writing to whereever the t64 transition was
coordinated for ARM, we’re using #debian-ports on OFTC for the
d-ports architectures and I couldn’t find out where to write to
for arm{el,hf}, so this mail of yours comes at a good time ;-)

The options for the armel/armhf porters are to either get the
.debs from me, install them in a chroot, and then the other B-D,
and rebuild the packages, or to use dpkg --force-depends to
install the dependencies (which makes it hard to use apt to
install the other ones unless you also edit /var/lib/dpkg/status
by hand first, something I was already used to from my reviving
m68k back in 2012–2015) into the chroot then rebuild there.

I will gladly help if it’s made possible for me to help. This
cannot be done on a porterbox because it’s still impossible to
either install arbitrary .debs into a chroot there or to obtain
root in the chroot to be able to force installation in the absence
of some Depends.

So if you have a fast armhf box or two, ideally with chroots
already made for sid, which you don’t mind temporarily giving
me root on, I’m in, otherwise I’ll answer questions from these
doing that work if needed.

I *think* 8/11/17/21 are the only versions we need to handle.

This does save us from having to rebootstrap this.

bye,
//mirabilos
- -- 
When he found out that the m68k port was in a pretty bad shape, he did
not, like many before him, shrug and move on; instead, he took it upon
himself to start compiling things, just so he could compile his shell.
How's that for dedication. -- Wouter, about my Debian/m68k revival

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (MirBSD)
Comment: ☃ ЦΤℱ—８　☕☂☄

iQIcBAEBCQAGBQJmA0vXAAoJEHa1NLLpkAfg0ZQQAI7P7qoVfADQrrsuNHAShvTB
lRvuK1br7bHRmqUx89dDwjOG1k0Xji3X3OURZldlhPCk99SJxQP3DLoCX5cmCzIA
IDyq+GoxREjJ/uyb4b6/qTAgSh7ZdRqxEfbVLsukL1i+wRs6dNw2Wg64i/R538jE
+yncg7zMyrWSA+3815i7BRfdMZBEk9E1qgW3hlnhueVfgANuyBLzzJchSstjunqE
0OcIukVQ30HaWaALmAfGcl7lcfM0sUFXL+EVpA8aBsVWNzZHtMIPnmI+yx8X4NOo
BOkfcYbPI928VZ/91meibSb9FXk8ShnO+zv+gU6dX74RlVoqOIeg6UQ/r2Cy+Up9
ssnksqTWTSkw1/n9bRNNiU8/O4kI5xV6FCUk2CaOsk+diQfXpoga50TR6DRM52tp
mjtBetkI1qK9vA0Y1VS+KoPp/FDYwFBKXiU3Jax9L7koaT5wGCurILqNTbDGVe19
2nmnphBUeIFniPByiItSEv7jH9GgxZyrwRvonYYpDXNeXFa0ymTNzKzrIG2ZqMrz
LcELgtIb6OD+WDYajUMOlTRBj2N9rFodruKyMcdUfc4so3OoFnS3cOdBvWBk/NdX
sFRgES39Ak5xgA3f4hP2ba03KZOFH2iIT3M8ZtZhH7eOIdhErKIUG0t6hxpWFdiV
ntE5WUlefRxovhbTOXKa
=KoS1
-END PGP SIGNATURE-

Re: Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf

[Simon McVittie]

It seems that some of the dependency chains for packages that are still
waiting to be rebuilt on armel,armhf now end at openjdk-17, which is the
default Java version for most architectures and Build-Depends on itself
(with an alternative dependency on openjdk-16, but that no longer exists).
evolution-data-server -> libphonenumber-dev is an example.

Are the ARM or Java teams intending to re-bootstrap openjdk-17 somehow?

Or do maintainers of packages that build both a C/C++ library and Java
bindings from a single source package need to disable its Java bindings
on the affected architectures, either temporarily or permanently?

openjdk-21 is in a similar situation, build-depending on itself, while
openjdk-22 and openjdk-23 build-depend on -21 and -22 respectively.
Presumably once we have a single OpenJDK version that is installable,
it would be possible to step through 18,19,20,21 building each version
with the previous one.

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.

smcv

Re: Bug#1004135: plantuml: please update to a newer upstream version

[Lilian BENOIT]

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 CVE bugs.

You’re welcome to help packaging a newer upstream version or backporting the 
fixes :)

Re: Bug#1004135: plantuml: please update to a newer upstream version

[Andrej Shadura]

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

Re: Bug#1057171: libitext5-java: FTBFS with bouncycastle 1.77

[tony mancill]

On Sat, Dec 09, 2023 at 12:50:33PM +0100, Andreas Tille wrote:
> I tried the latest upstream version of libitext5-java and commited the
> change to Git.  Unfortunately the problem persists.  Some Debian Med
> packages are depending from this package so I'd be happy if someone
> could have a look.  You can find the latest log in Salsa CI[1].

Hi Andreas,

Thank you for your efforts here.  I just pushed a patch that resolves
the FTBFS, and the tests are passing.  I plan to do a bit more poking
at the upstream tests to make sure that the patched classes are
exercised by the test cases, but will either update this bug or upload
in the 2-3 days.

Regards,
tony

Re: libitext5-java: FTBFS with bouncycastle 1.77

[Andreas Tille]

Hi,

I tried the latest upstream version of libitext5-java and commited the
change to Git.  Unfortunately the problem persists.  Some Debian Med
packages are depending from this package so I'd be happy if someone
could have a look.  You can find the latest log in Salsa CI[1].

Kind regards
   Andreas.

[1] https://salsa.debian.org/java-team/libitext5-java/-/jobs/5017940

-- 
http://fam-tille.de

Re: ditaa on Salsa

[Markus Koschany]

Am Freitag, dem 08.12.2023 um 16:34 +0100 schrieb Alexandre Detiste:
> Hi,
> 
> I found ditaa on Salsa: https://salsa.debian.org/java-team/ditaa
> 
> I'd like to do one QA upload
> to fix #953572 & more misc tiny stuff
> and push changes there.
> 
> Can I get access to this one repo ?

Done. Bienvenue Alexandre.


signature.asc
Description: This is a digitally signed message part

ditaa on Salsa

[Alexandre Detiste]

Hi,

I found ditaa on Salsa: https://salsa.debian.org/java-team/ditaa

I'd like to do one QA upload
to fix #953572 & more misc tiny stuff
and push changes there.

Can I get access to this one repo ?

Greetings

(or anybody else do it)

Re: Gradle problems when building adql-java package

[Ole Streicher]

Hi Pierre,

Pierre Gruet  writes:
> Le 08/12/2023 à 13:59, Ole Streicher a écrit :
>> When I removed the "distributions" block, the Jar file has the wrong
>> name (ADQLLib.jar). But when I include it, I get the error
>>  * What went wrong:
>>  A problem occurred evaluating project ':ADQLLib'.
>>  > Could not set unknown property 'distributionBaseName' for object of 
>> type org.gradle.api.distribution.internal.DefaultDistribution.
>> However, when looking in the Gradle docs, I find this as a valid
>> configuration. Do you have any idea here?
>
> Hmm, unfortunately we have an old Gradle in Debian at the moment. One
> has to look at the docs for version 4.4:
>   https://docs.gradle.org/4.4/userguide/distribution_plugin.html
> By reading this, I think you could try
>   baseName = archivesBaseName
> instead of
>   distributionBaseName = archivesBaseName
>
> Tell us if it works...

Yes it does. Thank you very much! I now can build the library
package. Some problems to resolve (documentation build, CI tests), but
I am optimistic now :-)

Best

Ole

Re: Gradle problems when building adql-java package

[Pierre Gruet]

Hi Ole,

Le 08/12/2023 à 13:59, Ole Streicher a écrit :

Hi Andrius,

Andrius Merkys  writes:

On 2023-12-08 13:03, Ole Streicher wrote:

I am trying to update the adql-java package to the newest upstream
(beta) version. As it is my first project using gradle, I sumbled upon a
number of problems: [...]


I guess you could patch 'junit:junit:4.13.1' with 'junit:junit:4.x' to
avoid this overly strict dependency version checking.


Thank you! This worked.

Now I have the next problem: the original ADQLLib/build.gradle contains the 
lines

 // Name of the JAR name (which will be then suffixed by the version 
number):
 archivesBaseName = "adql"
 distributions {
 main {
 distributionBaseName = archivesBaseName
 }
 }

When I removed the "distributions" block, the Jar file has the wrong
name (ADQLLib.jar). But when I include it, I get the error

 * What went wrong:
 A problem occurred evaluating project ':ADQLLib'.
 > Could not set unknown property 'distributionBaseName' for object of type 
org.gradle.api.distribution.internal.DefaultDistribution.

However, when looking in the Gradle docs, I find this as a valid
configuration. Do you have any idea here?


Hmm, unfortunately we have an old Gradle in Debian at the moment. One 
has to look at the docs for version 4.4:

https://docs.gradle.org/4.4/userguide/distribution_plugin.html
By reading this, I think you could try
baseName = archivesBaseName
instead of
distributionBaseName = archivesBaseName

Tell us if it works...



Cheers

Ole



Best,

--
Pierre


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Gradle problems when building adql-java package

[Ole Streicher]

Hi Andrius,

Andrius Merkys  writes:
> On 2023-12-08 13:03, Ole Streicher wrote:
>> I am trying to update the adql-java package to the newest upstream
>> (beta) version. As it is my first project using gradle, I sumbled upon a
>> number of problems: [...]
>
> I guess you could patch 'junit:junit:4.13.1' with 'junit:junit:4.x' to
> avoid this overly strict dependency version checking.

Thank you! This worked.

Now I have the next problem: the original ADQLLib/build.gradle contains the 
lines

// Name of the JAR name (which will be then suffixed by the version number):
archivesBaseName = "adql"
distributions {
main {
distributionBaseName = archivesBaseName
}
}

When I removed the "distributions" block, the Jar file has the wrong
name (ADQLLib.jar). But when I include it, I get the error

* What went wrong:
A problem occurred evaluating project ':ADQLLib'.
> Could not set unknown property 'distributionBaseName' for object of type 
org.gradle.api.distribution.internal.DefaultDistribution.

However, when looking in the Gradle docs, I find this as a valid
configuration. Do you have any idea here?

Cheers

Ole

Re: Gradle problems when building adql-java package

[Andrius Merkys]

Hi Ole,

On 2023-12-08 13:03, Ole Streicher wrote:

I am trying to update the adql-java package to the newest upstream
(beta) version. As it is my first project using gradle, I sumbled upon a
number of problems:

One is that the plugin org.javacc.javacc is not available. I guess this
is because it is not packaged yet, right? My solution here is that I
call javacc in d/rules before running dh_auto_build; is this the way to
go?

After this, dh_auto_build completes, but the tests fail with

 > Could not resolve junit:junit:4.13.1.
   Required by:
   project :ADQLLib
> No cached version of junit:junit:4.13.1 available for offline mode.

which is caused by

 dependencies {
 testImplementation 'junit:junit:4.13.1'
 testImplementation 'org.slf4j:slf4j-simple:1.7.25'
 }

in the main build.gradle (right?) junit4 is however a build dependency
(currently 4.13.2 in unstable). What should I do here? Are the versions
here minversions? Removing the complete dependency will cause junit4
classes missing in the test, also setting the CLASSPATH environment
variable doesn't help. What is the proper solution here?


I guess you could patch 'junit:junit:4.13.1' with 'junit:junit:4.x' to 
avoid this overly strict dependency version checking.


In some projects I maintain I got fed up with gradle and switched to 
plain jh_build. An example could be found in lucene9 [1]. I even found a 
way to build and run tests, but I did not succeed in doing so for 
lucene9, need to refresh my memory why.


[1] https://sources.debian.org/src/lucene9/9.4.2%2Bdfsg-2/debian/rules/

Hope this helps,
Andrius

Gradle problems when building adql-java package

[Ole Streicher]

Hi,

I am trying to update the adql-java package to the newest upstream
(beta) version. As it is my first project using gradle, I sumbled upon a
number of problems:

One is that the plugin org.javacc.javacc is not available. I guess this
is because it is not packaged yet, right? My solution here is that I
call javacc in d/rules before running dh_auto_build; is this the way to
go?

After this, dh_auto_build completes, but the tests fail with

> Could not resolve junit:junit:4.13.1.
  Required by:
  project :ADQLLib
   > No cached version of junit:junit:4.13.1 available for offline mode.

which is caused by

dependencies {
testImplementation 'junit:junit:4.13.1'
testImplementation 'org.slf4j:slf4j-simple:1.7.25'
}

in the main build.gradle (right?) junit4 is however a build dependency
(currently 4.13.2 in unstable). What should I do here? Are the versions
here minversions? Removing the complete dependency will cause junit4
classes missing in the test, also setting the CLASSPATH environment
variable doesn't help. What is the proper solution here?

Best

Ole

Re: beauti2 fails to start

[Andreas Tille]

Hi,

Am Sun, Dec 18, 2022 at 03:15:28PM +0100 schrieb Pierre Gruet:
> Control: tags -1 help
> 
> Hello,
> 
> I tried to investigate further, I feel a window should appear and the action
> of the user is expected, yet I don't see anything except the initial
> "Initializing BEAUti..." GUI.
> My knowledge of jdb did not allow me to understand further what is going on.

I tried to verify the issue with the latest uploaded beast2-mcmc and get:

$ beauti2
Loading package BEAST.base v2.7.6

as well as the very small "Initializing BEAUti..." window.

So this issue persists and some help to track this down would be really
appreciated.

Kind regards
Andreas.

-- 
http://fam-tille.de

Re: Intended use of ${maven:CompileDepends}

[Emmanuel Bourg]

Hi Sebastiaan,

Le 11/11/2023 à 09:15, Sebastiaan Couwenberg a écrit :

What's the intended use of the ${maven:CompileDepends} substvar?

It shouldn't be added to Depends nor Built-Using. The dpkg-gencontrol 
warning makes it very tempting to add it to Depends as some package in 
the archive have incorrectly done.


I've resorted to stripping it from the generated substvars file before 
dh_gencontrol to get rid of the warning, but it seems better to do this 
in maven-debian-helper.


I'll have to check but I think the intended use of 
${maven:CompileDepends} is for packaging parent poms, in this case you 
want the plugin dependencies to appear in the Depends field of the package.


Emmanuel Bourg

Intended use of ${maven:CompileDepends}

[Sebastiaan Couwenberg]

What's the intended use of the ${maven:CompileDepends} substvar?

It shouldn't be added to Depends nor Built-Using. The dpkg-gencontrol 
warning makes it very tempting to add it to Depends as some package in 
the archive have incorrectly done.


I've resorted to stripping it from the generated substvars file before 
dh_gencontrol to get rid of the warning, but it seems better to do this 
in maven-debian-helper.


Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Re: jtreg for openjdk-8 in ELTS

[Emilio Pozuelo Monfort]

Hi!

On 02/11/2023 21:24, Thorsten Glaser wrote:

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 can
use that.


I had started to look at backporting jtreg6, without vendored dependencies. That 
was a bit painful due to the need of upgrading other packages, which had rdeps. 
Using vendored deps in this case sounds like a good solution. Not sure whether 
it will be easier for jtreg5.



Vladimir would be able to tell you which dependencies would need
to be included, and at which versions, or maybe even help with
the package.


Any help would be appreciated!


libasmtools-java is also needed for fuller coverage but can probably
be easily backported.


Yeah, since it's is a new package there shouldn't be many issues with 
introducing that, as it's got no rdeps.


Cheers,
Emilio

Bug#1055270: ITP: starjava-auth -- Authentication for resources in accordance with VO standards

[Ole Streicher]

Package: wnpp
Owner: Ole Streicher 
Severity: wishlist
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-as...@lists.debian.org, 
debian-java@lists.debian.org


 * Package name: starjava-auth
   Version : 0.2
   Upstream Author : Mark Taylor
 * URL : https://github.com/Starlink/starjava/tree/master/auth
 * License : LGPL-3+
   Programming Lang: Java
   Description : VO standard conform resource authentication

This package manages authentication for HTTP(S) resources in accordance
with VO standards. This package relies on VO standards that are still
under discussion.

The package will be maintained by the Debian Astro team. It is a new
dependency of the "topcat" and "ttools" (STILTS) packages.

A git repository will be created at

https://salsa.debian.org/debian-astro-team/starjava-auth

Best regards

Ole

jtreg for openjdk-8 in ELTS

[Thorsten Glaser]

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 can
use that.

Vladimir would be able to tell you which dependencies would need
to be included, and at which versions, or maybe even help with
the package.

libasmtools-java is also needed for fuller coverage but can probably
be easily backported.

bye,
//mirabilos
-- 
18:47⎜ well channels… you see, I see everything in the
same window anyway  18:48⎜ i know, you have some kind of
telnet with automatic pong 18:48⎜ haha, yes :D
18:49⎜ though that's more tinyirc – sirc is more comfy

Potential circular dependency in JRuby

[Jérôme Charaoui]

Hello,

Lately I've been working in updating JRuby in Debian to the new 9.4 
release series.


As part of this work, I hoped to reduce the maintenance burden by 
greatly simplifying debian/rules and reducing the scope of required 
patches. By packaging both polyglot-ruby and jruby-mavengem (which I 
have completed) and making them available to the Maven build process, I 
was able to achieve this.


However, since both of these new binary packages rely on JRuby to 
function, I been warned that this circular dependency may cause problems 
in the future.


So my question is, what kinds of practical problems might this cause? 
Bootstrapping new Debian ports shouldn't be affected, since all packages 
involved are arch:all.


Thanks!

-- Jérôme

Re: Bug#1054361: ITP: jruby-jzlib

[Jérôme Charaoui]

Le 2023-10-24 à 11 h 02, Emmanuel Bourg a écrit :

Le 24/10/2023 à 16:28, Jérôme Charaoui a écrit :

Right, my thinking was to use the same path usj/jzlib.jar to signal 
the classpath conflict. Otherwise, we can install it to 
usj/jruby-jzlib.jar and not make the packages conflict, but I'm not 
sure what would happen if both were installed at the same time, at the 
JVM-level.


If both jars are loaded in the classpath the JVM will randomly resolve 
the classes from the 2 files, that may lead to runtime errors if the two 
implementations are not binary compatible.



There are some (small) code changes as well, here is a pkgdiff report: 
https://paste.lib3.net/lavamind/2023-10-24-gBV6KdXXUJ4R0DlxXjjnjz0RmA9OCJ6goNYKux5c03M/changes_report.html


Looking at the changes :

* DeflaterOutputStream.java: exception message changed
* GZIPHeader.java: private 'time' variable removed
* GZIPInputStream.java: getModifiedTime method added (typo fix)
* Inflate.java: call a setter instead of setting the variable directly
* ZStream.java: comment change

The only notable change is the addition of getModifiedTime(), we can add 
it to the existing package.



In addition, I believe there may be more substantive changes in the 
future since 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.


Alright, thanks for the analysis! I'll patch GZIPInputStream.java in the 
existing jzlib package to add getModifiedTime(), and I'll keep an eye on 
jruby-jzlib and upload it if/when it diverges more from jzlib.


-- Jérôme

Re: Bug#1054361: ITP: jruby-jzlib

[Emmanuel Bourg]

Le 24/10/2023 à 16:28, Jérôme Charaoui a écrit :

Right, my thinking was to use the same path usj/jzlib.jar to signal the 
classpath conflict. Otherwise, we can install it to usj/jruby-jzlib.jar 
and not make the packages conflict, but I'm not sure what would happen 
if both were installed at the same time, at the JVM-level.


If both jars are loaded in the classpath the JVM will randomly resolve 
the classes from the 2 files, that may lead to runtime errors if the two 
implementations are not binary compatible.



There are some (small) code changes as well, here is a pkgdiff report: 
https://paste.lib3.net/lavamind/2023-10-24-gBV6KdXXUJ4R0DlxXjjnjz0RmA9OCJ6goNYKux5c03M/changes_report.html


Looking at the changes :

* DeflaterOutputStream.java: exception message changed
* GZIPHeader.java: private 'time' variable removed
* GZIPInputStream.java: getModifiedTime method added (typo fix)
* Inflate.java: call a setter instead of setting the variable directly
* ZStream.java: comment change

The only notable change is the addition of getModifiedTime(), we can add 
it to the existing package.



In addition, I believe there may be more substantive changes in the 
future since 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

Re: Bug#1054361: ITP: jruby-jzlib

[Jérôme Charaoui]

Hi Emmanuel,

Le 2023-10-24 à 10 h 02, Emmanuel Bourg a écrit :

Hi Jérôme,

Le 24/10/2023 à 15:18, Jérôme Charaoui a écrit :

I've prepared the jruby-jzlib package, but I'm uncertain about the 
relationship it should have with jzlib.


Since the module itself is still using the same "com.jcraft" 
namespace, I'm thinking of using a Conflicts: and Provides: on 
libjzlib-java.


No that's not necessary, because the libjzlib-java and 
libjruby-jzlib-java packages do not conflict at the filesystem level. 
The Conflicts field doesn't cover classpath conflicts.


Right, my thinking was to use the same path usj/jzlib.jar to signal the 
classpath conflict. Otherwise, we can install it to usj/jruby-jzlib.jar 
and not make the packages conflict, but I'm not sure what would happen 
if both were installed at the same time, at the JVM-level.



You can check out the package here: 
https://salsa.debian.org/lavamind/jruby-jzlib


I got a quick look at the jzlib fork [1] and there are very few changes 
compared to the original project, it just adds a JPMS auto module name. 
We could simply patch our existing jzlib package instead of introducing 
a new one. On the jruby side, that would mean patching the Maven 
coordinates of jzlib (org.jruby:jzlib -> com.jcraft:jzlib).


There are some (small) code changes as well, here is a pkgdiff report: 
https://paste.lib3.net/lavamind/2023-10-24-gBV6KdXXUJ4R0DlxXjjnjz0RmA9OCJ6goNYKux5c03M/changes_report.html


In addition, I believe there may be more substantive changes in the 
future since 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


Thanks,

-- Jérôme

Re: Bug#1054361: ITP: jruby-jzlib

[Emmanuel Bourg]

Hi Jérôme,

Le 24/10/2023 à 15:18, Jérôme Charaoui a écrit :

I've prepared the jruby-jzlib package, but I'm uncertain about the 
relationship it should have with jzlib.


Since the module itself is still using the same "com.jcraft" namespace, 
I'm thinking of using a Conflicts: and Provides: on libjzlib-java.


No that's not necessary, because the libjzlib-java and 
libjruby-jzlib-java packages do not conflict at the filesystem level. 
The Conflicts field doesn't cover classpath conflicts.



You can check out the package here: 
https://salsa.debian.org/lavamind/jruby-jzlib


I got a quick look at the jzlib fork [1] and there are very few changes 
compared to the original project, it just adds a JPMS auto module name. 
We could simply patch our existing jzlib package instead of introducing 
a new one. On the jruby side, that would mean patching the Maven 
coordinates of jzlib (org.jruby:jzlib -> com.jcraft:jzlib).


Emmanuel Bourg

[1] https://github.com/jruby/jzlib

Fwd: Bug#1054361: ITP: jruby-jzlib

[Jérôme Charaoui]

Hello,

I've prepared the jruby-jzlib package, but I'm uncertain about the 
relationship it should have with jzlib.


Since the module itself is still using the same "com.jcraft" namespace, 
I'm thinking of using a Conflicts: and Provides: on libjzlib-java.


You can check out the package here: 
https://salsa.debian.org/lavamind/jruby-jzlib


Thanks!

-- Jérôme


 Message transféré 
Sujet : Bug#1054361: ITP: jruby-jzlib
Date de renvoi : Sun, 22 Oct 2023 14:48:02 +
De (renvoi) : Jérôme Charaoui 
Pour (renvoi) : debian-bugs-d...@lists.debian.org
Copie (renvoi) : debian-de...@lists.debian.org, w...@debian.org
Date : Sun, 22 Oct 2023 10:45:27 -0400
De : Jérôme Charaoui 
Répondre à : Jérôme Charaoui , 1054...@bugs.debian.org
Pour : Debian Bug Tracking System 

Package: wnpp
Severity: wishlist
Owner: Jérôme Charaoui 
X-Debbugs-Cc: debian-de...@lists.debian.org

   Package name : jruby-jzlib
   Version  : 1.1.5
   Upstream author  : y...@jcraft.com, JCraft,Inc.
   Upstream contact : Charles Oliver Nutter 
   URL  : https://github.com/jruby/jzlib
   License  : BSD-3-clause
   Programming Lang : Java
   Description  : JRuby's fork of the jzlib pure-Java zlib library

JZlib is a re-implementation of zlib in pure Java. This version is a 
fork of com.jcraft:jzlib with additional improvements for the JRuby 
environment.


This is part of an effort to improve the JRuby build chain in Debian.

Thanks,

-- Jerome

Re: jtreg7: request to vendor the dependencies

[Thorsten Glaser]

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 must be packaged separately.

>A new point release of the package in the stable release requires
>careful testing and ensuring that there is no impact on reverse
>dependencies.

Right. Please talk to stable release maintainers and security people
and ask them how they’d prefer to have this handled. Do also include
Doko (as openjdk-?? maintainer).

bye,
//mirabilos
-- 
Infrastrukturexperte • Qvest Digital AG
Am Dickobskreuz 10, D-53121 Bonn • https://www.qvest-digital.com/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 18196 • USt-ID (VAT): DE274355441
Vorstand: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Vorsitzender Aufsichtsrat: Peter Nöthen

jtreg7: request to vendor the dependencies

[Vladimir Petko]

Hi,

jtreg7 is a package that provides regression testing for openjdk-21
and soon openjdk-17 and is critical to the openjdk package build
process.

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.

A new point release of the package in the stable release requires
careful testing and ensuring that there is no impact on reverse
dependencies.

JTreg is seeing some acceleration in development and will require a
regular backporting effort for the dependencies.

I wonder if it is possible to provide an exclusion for jtreg7 to
vendor the required dependencies to simplify the backporting effort.

The draft vendoring implementation is available here[1].

Best Regards,
 Vladimir.

[1] 
https://salsa.debian.org/vpa1977/jtreg/-/commit/eebacdae191d6f0a833d548681fb3fe6b17dbd91

Bug#1053896: Acknowledgement (content very outdated)

[Thomas Lange]

It seems that on https://www.debian.org/doc/user-manuals#java-faq we
publish the a version from 2014 from
https://salsa.debian.org/ddp-team/java-faq
which is much more outdated that the version in the package
java-policy.

-- 
regards Thomas

Bug#1053896: content very outdated

[Thomas Lange]

Package: java-policy
Version: 0.57


Hi,

the Java FAQ is very outdated. It only covers i386 and java 6/7 up to
Debian wheezy. There are links to alioth and it talks about
icedtea-7-plugin.

The salsa repo shows that it was not updated since 9 years.

Maybe we should remove the FAQ.
--
regards Thomas

Re: Q: javac -source and -target version

[Emmanuel Bourg]

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 
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

Re: Q: javac -source and -target version

[Hideki Yamane]

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_compat_level) -target $(java_compat_level) ...

 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


> It's preferable to keep using the -source/-target options rather than
> removing them, it extends the lower bound of the Java versions range
> usable with the package.

 Okay :)


-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp

Re: Q: javac -source and -target version

[Emmanuel Bourg]

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?
 


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_compat_level) -target $(java_compat_level) ...


It's preferable to keep using the -source/-target options rather than
removing them, it extends the lower bound of the Java versions range
usable with the package.

Emmanuel Bourg

Re: Q: javac -source and -target version

[Hideki Yamane]

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 safely, then?

-- 
Hideki Yamane 

Re: Q: javac -source and -target version

[Emmanuel Bourg]

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, Maven or Gradle the level is adjusted automatically. 
You can drop the language level, but the package will require the same 
version or higher at runtime.


We should probably provide the minimum language level supported as a 
variable in the /usr/share/java/java_defaults.mk file from java-common.


Emmanuel Bourg

Q: javac -source and -target version

[Hideki Yamane]

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 asked it before but cannot remember the reasons...
 so I hope someone let me know it.


 Thanks!

-- 
Hideki Yamane 

Using Gradle Build Scans™ with Debian Gradle 4.4.x

[Sean Gilligan]

Although Build Scans™ are a proprietary add-on to Gradle, they are very 
useful in a FOSS CI environment. They make it very easy to find all the 
information you need to troubleshoot a failing build or find ways to 
optimize build scripts.


Unfortunately, the options for agreeing to the terms-of-service in a CI 
environment have been difficult to configure cleanly. (You also have to 
give them your email, which I don't mind doing but some may object.)


I opened an issue with Gradle about programmatically agreeing to the TOS 
and Stefan Wolf from Gradle provided an initialization script that 
solves the problem:


https://github.com/gradle/gradle/issues/26316#issuecomment-1739245349

The script works with Gradle 4.4.x (FrankenGradle) through 8.x (at 
least.) The nice thing about this solution is that the script lives in a 
separate file and is only activated with specific command line options:


`--init-script build-scan-agree.gradle --scan`

I've tested it with bitcoinj and created two PRs that use it. They 
provide examples of how to use it:


GitHub Actions: https://github.com/bitcoinj/bitcoinj/pull/3289
GitLab CI: https://github.com/bitcoinj/bitcoinj/pull/3290

Regards,


Sean