jcodings 1.0.56-1 MIGRATED to testing

[Debian testing watch]

FYI: The status of the jcodings source package
in Debian's testing distribution has changed.

  Previous version: 1.0.55-2
  Current version:  1.0.56-1

-- 
This email is automatically generated once a day.  As the installation of
new packages into testing happens multiple times a day you will receive
later changes on the next day.
See https://release.debian.org/testing-watch/ for more information.

__
This is the maintainer address of Debian's Java team
.
 Please use
debian-j...@lists.debian.org for discussions and questions.

Processed: block puppetserver itp by jruby

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> block 830904 by 972230
Bug #830904 [wnpp] ITP: puppetserver -- the next-generation application for 
managing Puppet agents
830904 was blocked by: 964222 819811 976751
830904 was not blocking any bugs.
Added blocking bug(s) of 830904: 972230
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
830904: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830904
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

__
This is the maintainer address of Debian's Java team
.
 Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#733586: closure-compiler: new upstream version available

[Nicholas D Steeves]

Hello Thomas and Tony,

CCing Javascript team (JS Team, please see below for why), and fixing
threading, since top-posting is confusing.  Reply follows inline:

Thomas Koch  writes:
>> tony mancill  hat am 29.03.2022 07:26 geschrieben:
>> > On Mon, Mar 28, 2022 at 03:27:17PM -0400, Nicholas D Steeves wrote:
>> > 
>> > This package came to my attention via #975505, where it was noted that
>> > MathJax2 has had to disable functionality because of too ancient of a
>> > closure-compiler, and at this time it appears that MathJax3 will have to
>> > do the same.
>> > 
>> > Closure-compiler is a candidate for salvaging:
>> > 
>> >   https://wiki.debian.org/PackageSalvaging
>> >   
>> > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
>> > 
>> > The ideal resolution would be for one of the listed Uploaders to resume
>> > maintenance of the package, but orphaning is of course also an option :-)
>> 
>> The closure-compiler package is officially a team-maintained package by
>> the Java Team, so you or anyone else who is interested in joining Java
>> Team and maintaining the package is welcome to do so.  That is, please
>> feel free to add yourself to Uploaders.
>> 
>> That said, it's more of a JavaScript tool than a Java package, and so
>> the package could also be moved to another team if that's preferable.
>> 
>> I will gladly help with either of those options, or with reviewing and
>> sponsoring an upload of a newer version if one is made available.
>> 
>> Finally, I have never been a user of closure-compiler - my packaging
>> work on it has been under the Java Team umbrella - and I have
>> (obviously) been unable to devote sufficient time to it.  I will remove
>> myself from Uploaders to avoid any future confusion.
>>
>
> Hello,
>
> sorry, I was under the wrong impression that closure-compiler would be
> abandoned upstream and that it would eventually die of age and be
> removed.  I packaged closure-compiler as a dependency of the code
> review system Gerrit which however couldn't be packaged at the time
> due to GWT.
>
> Whoever does another upload to closure-compiler please also remove me
> from uploaders.
>
> Thank you!
>

Thank you both for your quick reply!  Your clarification and context is
much appreciated :-)  While closure-compiler is currently under the Java
Team umbrella, removing both human uploaders will create a Policy §3.3
violation (the need for a human Maintainer/Uploader is unfulfilled):

  https://www.debian.org/doc/debian-policy/ch-binary.html#s-maintainer

Closure-compiler must be formally orphaned for this reason.

There is additionally a practical reason to orphan it: The maintainers
of all packages that depend on it will receive a Package Tracker
notification that it is unmaintained; This includes transitive
dependencies via MathJax2 (sigil, pandoc, etc).  Furthermore, it will
show up on the list of packages that prospective DMs and DDs investigate
as part of their process.  If I remember correctly the orphan bug will
also appear for developers who have the "how-can-i-help" package
installed.

Thus, please file the wnpp Orphan bug, because it's clearly the correct
avenue forward, and because it maximises the chance of finding a new
maintainer.

Cheers!
Nicholas


signature.asc
Description: PGP signature
__
This is the maintainer address of Debian's Java team
.
 Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#1007923: maven-*-helper JAR placement seems to contradict Java policy

[Pierre Gruet]

Hello everyone,

Le 29/03/2022 à 11:59, Markus Koschany a écrit :

Am Montag, dem 28.03.2022 um 21:06 -0700 schrieb tony mancill:

[...]
I am interested to hear other opinions from the Debian Java Team.


I have no objections with implementing this change and I agree that a
versionless symlink is preferable for consistency reasons. The current behavior
doesn't do any harm though. The Lintian warning should be fixed with a regular
upload and not just for the sake of it.



Thanks for addressing the issue of the jar placement. I also subscribe 
to the versionless symlink approach justified by Andrius.
Admittedly we won't be in a hurry to do the uploads ot the concerned 
packages because of this change.



Regards,

Markus


Best regards,

--
Pierre


OpenPGP_signature
Description: OpenPGP digital signature
__
This is the maintainer address of Debian's Java team
.
 Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#1007923: maven-*-helper JAR placement seems to contradict Java policy

[Markus Koschany]

Am Montag, dem 28.03.2022 um 21:06 -0700 schrieb tony mancill:
> [...]
> I am interested to hear other opinions from the Debian Java Team.

I have no objections with implementing this change and I agree that a
versionless symlink is preferable for consistency reasons. The current behavior
doesn't do any harm though. The Lintian warning should be fixed with a regular
upload and not just for the sake of it.

Regards,

Markus


signature.asc
Description: This is a digitally signed message part
__
This is the maintainer address of Debian's Java team
.
 Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#733586: closure-compiler: new upstream version available

[Thomas Koch]

Hello,

sorry, I was under the wrong impression that closure-compiler would be 
abandoned upstream and that it would eventually die of age and be removed.
I packaged closure-compiler as a dependency of the code review system Gerrit 
which however couldn't be packaged at the time due to GWT.

Whoever does another upload to closure-compiler please also remove me from 
uploaders.

Thank you!

> tony mancill  hat am 29.03.2022 07:26 geschrieben:
> 
>  
> Hello Nicholas,
> 
> On Mon, Mar 28, 2022 at 03:27:17PM -0400, Nicholas D Steeves wrote:
> > Control: unblock 886411 by -1
> > 
> > Hi Tony and Thomas,
> > 
> > This package came to my attention via #975505, where it was noted that
> > MathJax2 has had to disable functionality because of too ancient of a
> > closure-compiler, and at this time it appears that MathJax3 will have to
> > do the same.
> > 
> > Closure-compiler is a candidate for salvaging:
> > 
> >   https://wiki.debian.org/PackageSalvaging
> >   
> > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
> > 
> > The ideal resolution would be for one of the listed Uploaders to resume
> > maintenance of the package, but orphaning is of course also an option :-)
> 
> The closure-compiler package is officially a team-maintained package by
> the Java Team, so you or anyone else who is interested in joining Java
> Team and maintaining the package is welcome to do so.  That is, please
> feel free to add yourself to Uploaders.
> 
> That said, it's more of a JavaScript tool than a Java package, and so
> the package could also be moved to another team if that's preferable.
> 
> I will gladly help with either of those options, or with reviewing and
> sponsoring an upload of a newer version if one is made available.
> 
> Finally, I have never been a user of closure-compiler - my packaging
> work on it has been under the Java Team umbrella - and I have
> (obviously) been unable to devote sufficient time to it.  I will remove
> myself from Uploaders to avoid any future confusion.
> 
> > Pirate Praveen  writes:
> > 
> > > Control: block 886411 by -1
> > >
> > > On Sat, 20 Jan 2018 20:38:02 +0530 Pirate Praveen 
> > > wrote:> Being more familiar with nodejs packaging, I prefer to go back to
> > >> google-closure-compiler-js. But if there is a newer closure-compiler,
> > >> it'd make my work a lot easier.
> > >> 
> > >
> > > Hi Tony,
> > >
> > > Digging deeper, I found out even the javascript version is built using
> > > java sources (using gwt). So I have to update the java sources even for
> > > javascript version.  Hope you are still interested in updating
> > > closure-compiler and we can collaborate.
> > 
> > Hi Pirate!
> > 
> > I noticed that you were able to complete #886411 ITP: node-react using
> > some other method (perhaps google-closure-compiler-js, or perhaps
> > disabling functionality?), so I've unset the block relation.  It seemed
> > worthwhile keep you in the CC list in case you wanted to create a
> > "switch to closure-compiler" bug, and block it with this one (#733586).
> > 
> > 
> > Kind regards,
> > Nicholas
> 
> Cheers,
> tony

__
This is the maintainer address of Debian's Java team
.
 Please use
debian-j...@lists.debian.org for discussions and questions.