Bug#705565: Getting closure compiler back in testing?

2013-12-30 Thread Daniel Pocock
On 30/12/13 00:48, Rogério Brito wrote:
 Hi there.

 Can we have a late Christmas present (or even an New Year's present)? The
 closure compiler:

 * has already been removed from testing [1]
 * has many applications and users that depend/want it
 * already has patches in the BTS [2]

 [1]: 
 http://packages.qa.debian.org/c/closure-compiler/news/20131229T163915Z.html
 [2]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705565

 Given this information, could we have something (even a NMU) to fix this?


Tony made some commits in Git and it appears he is working to resolve this

The rename of the binary package from libclosure-compiler-java -
closure-compiler should probably be done now as well to get this out of
the way well before the Jessie release.

I've made the changes for a rename on a branch called pkgrename and
pushed that into Git

Tony, are you making another upload shortly, would you like to merge
pkgrename perhaps?

__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Re: Bug#705565: Getting closure compiler back in testing?

2013-12-30 Thread Thomas Koch
On Monday, December 30, 2013 10:19:53 AM Daniel Pocock wrote:
 Tony made some commits in Git and it appears he is working to resolve this
 
 The rename of the binary package from libclosure-compiler-java -
 closure-compiler should probably be done now as well to get this out of
 the way well before the Jessie release.
 
 I've made the changes for a rename on a branch called pkgrename and
 pushed that into Git
 
 Tony, are you making another upload shortly, would you like to merge
 pkgrename perhaps?

closure compiler is also a library dependency, e.g. of gwt. It might be a good 
idea to provide two binary packages, one for the library jar and another one 
for the manpage + executable.

Regards, Thomas Koch

__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.


Bug#705565: Getting closure compiler back in testing?

2013-12-30 Thread Daniel Pocock


On 30/12/13 20:35, Thomas Koch wrote:
 On Monday, December 30, 2013 10:19:53 AM Daniel Pocock wrote:
 Tony made some commits in Git and it appears he is working to resolve this

 The rename of the binary package from libclosure-compiler-java -
 closure-compiler should probably be done now as well to get this out of
 the way well before the Jessie release.

 I've made the changes for a rename on a branch called pkgrename and
 pushed that into Git

 Tony, are you making another upload shortly, would you like to merge
 pkgrename perhaps?
 
 closure compiler is also a library dependency, e.g. of gwt. It might be a 
 good 
 idea to provide two binary packages, one for the library jar and another one 
 for the manpage + executable.

That is awkward with an executable JAR, it is just a single artifact
that can be used either way

__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.


Bug#705565: Getting closure compiler back in testing?

2013-12-30 Thread tony mancill
On 12/30/2013 11:35 AM, Thomas Koch wrote:
 On Monday, December 30, 2013 10:19:53 AM Daniel Pocock wrote:
 Tony made some commits in Git and it appears he is working to resolve this

 The rename of the binary package from libclosure-compiler-java -
 closure-compiler should probably be done now as well to get this out of
 the way well before the Jessie release.

 I've made the changes for a rename on a branch called pkgrename and
 pushed that into Git

 Tony, are you making another upload shortly, would you like to merge
 pkgrename perhaps?
 
 closure compiler is also a library dependency, e.g. of gwt. It might be a 
 good 
 idea to provide two binary packages, one for the library jar and another one 
 for the manpage + executable.
 
 Regards, Thomas Koch

Hi Thomas, Daniel,

I agree with Thomas' suggestion.  I'm not sure what the FTP team will
think of the very small binary package (the next upload will go through
NEW), but adding a binary package with just the manpage + JRE and
jarwrapper dependency feels like the right thing to do.

Any thoughts about whether it's better to update to a newer upstream and
then rename, or rename first?

Cheers,
tony








signature.asc
Description: OpenPGP digital signature
__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#705565: Getting closure compiler back in testing?

2013-12-30 Thread tony mancill
On 12/30/2013 11:54 AM, Daniel Pocock wrote:
 
 
 On 30/12/13 20:35, Thomas Koch wrote:
 On Monday, December 30, 2013 10:19:53 AM Daniel Pocock wrote:
 Tony made some commits in Git and it appears he is working to resolve this

 The rename of the binary package from libclosure-compiler-java -
 closure-compiler should probably be done now as well to get this out of
 the way well before the Jessie release.

 I've made the changes for a rename on a branch called pkgrename and
 pushed that into Git

 Tony, are you making another upload shortly, would you like to merge
 pkgrename perhaps?

 closure compiler is also a library dependency, e.g. of gwt. It might be a 
 good 
 idea to provide two binary packages, one for the library jar and another one 
 for the manpage + executable.
 
 That is awkward with an executable JAR, it is just a single artifact
 that can be used either way

It means that the closure-compiler binary package is merely the
/usr/bin/ symlink and the dependency on jarwrapper.

I don't know that it really matters much - the reason for the rename is
to make the binary package easier to find, but the current java library
package is named correctly (as per policy and ease of locating) as well.

I'm not sure if there is a best practice for executable JARs that are
used in both contexts, but adding an additional binary package doesn't
seem too bad.

tony




signature.asc
Description: OpenPGP digital signature
__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#705565: Getting closure compiler back in testing?

2013-12-30 Thread Daniel Pocock
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 30/12/13 21:03, tony mancill wrote:
 On 12/30/2013 11:54 AM, Daniel Pocock wrote:
 
 
 On 30/12/13 20:35, Thomas Koch wrote:
 On Monday, December 30, 2013 10:19:53 AM Daniel Pocock wrote:
 Tony made some commits in Git and it appears he is working to
 resolve this
 
 The rename of the binary package from
 libclosure-compiler-java - closure-compiler should probably
 be done now as well to get this out of the way well before
 the Jessie release.
 
 I've made the changes for a rename on a branch called
 pkgrename and pushed that into Git
 
 Tony, are you making another upload shortly, would you like
 to merge pkgrename perhaps?
 
 closure compiler is also a library dependency, e.g. of gwt. It
 might be a good idea to provide two binary packages, one for
 the library jar and another one for the manpage + executable.
 
 That is awkward with an executable JAR, it is just a single
 artifact that can be used either way
 
 It means that the closure-compiler binary package is merely the 
 /usr/bin/ symlink and the dependency on jarwrapper.
 
 I don't know that it really matters much - the reason for the
 rename is to make the binary package easier to find, but the
 current java library package is named correctly (as per policy and
 ease of locating) as well.
 
 I'm not sure if there is a best practice for executable JARs that
 are used in both contexts, but adding an additional binary package
 doesn't seem too bad.
 

- From a useability perspective, I agree that the two packages is more
appealing

I'll change my own packages to depend on closure-compiler when it exists

I'd suggest doing the new binary package before doing the update to
the latest code, then it will be easier for the FTP masters to review

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJSwdJ9AAoJEOm1uwJp1aqDFocP+wV2PFBQl4/4YBc/Hn/UJEhR
wWhLJS8LlqHzqb3y+f5V/ezK55AYx/G0RWBSWxhsh9xmmOZFF4xqlF/k3wY2kjt4
YehjW8Px+Kn3VDLsb0Fyo6CSGk7N8rathGtcYbLIWDu2Qs/btlucPkdpk4Q8eoYM
tf7eMs15tESNyVNkYGSbQ4Tltj1g6W/ZWlXxRnSPVBLSqUBqlXMoUcq/sFgsa/in
OpSiszWakp99AMv6MubvM25kKKvlMzVhK9gf2OZ1I8JiX5dFiHw+/liRpRDDnFY+
mfNnvD58LNEvkVVV9xWCG3yVkj8uby8Zd3tBOn4MH2LuagUUUXdFL7neM2l+sSIi
04wua8i7nP0xyqc04Lxvkyt3Se6ro0Vsx6GKfXmR4kcoHjTmJGyWFTru4nPBd9QP
9Iqsk82Ym017nY181+NClgZZDmzxcR3xn8Lv29Adv4rYju4wOfoy6GGQUd2Iwyat
6OP3roxd03bOWXhIi83U72JWwCOxV00RVtLXfmWQFYD2Z6Yt5R4cCJXeZs8/sJZF
sOpWWqadbGlUZViN0CJEuTIOBsZQFSt+hQxhNDMD0BFqgnybSkcmEg0j4USougNB
lc5jOieLL9V3MoB/El5ht9dylzv9XK5vFG385U94YflxpVuV0MJ4cmyF4L1tRHSX
yNzQjg+CE79snZpN8usR
=BMiD
-END PGP SIGNATURE-

__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.


Bug#705565: Getting closure compiler back in testing?

2013-12-30 Thread gregor herrmann
On Mon, 30 Dec 2013 12:03:13 -0800, tony mancill wrote:

  The rename of the binary package from libclosure-compiler-java -
  closure-compiler should probably be done now as well to get this out of
  the way well before the Jessie release.

 It means that the closure-compiler binary package is merely the
 /usr/bin/ symlink and the dependency on jarwrapper.

Can't this be solved with a simple
Provides: closure-compiler
in the libclosure-compiler-java package?
(Or the other way round.)

Having a de facto empty package doesn't seem very appealing to me.
 

Cheers,
gregor

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT  SPI, fellow of the Free Software Foundation Europe
   `-   NP: Bob Dylan: Temporary like Achilles


signature.asc
Description: Digital signature
__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#705565: Getting closure compiler back in testing?

2013-12-30 Thread tony mancill
On 12/30/2013 03:15 PM, gregor herrmann wrote:
 On Mon, 30 Dec 2013 12:03:13 -0800, tony mancill wrote:
 
 The rename of the binary package from libclosure-compiler-java -
 closure-compiler should probably be done now as well to get this out of
 the way well before the Jessie release.
 
 It means that the closure-compiler binary package is merely the
 /usr/bin/ symlink and the dependency on jarwrapper.
 
 Can't this be solved with a simple
 Provides: closure-compiler
 in the libclosure-compiler-java package?
 (Or the other way round.)
 
 Having a de facto empty package doesn't seem very appealing to me.

Hi gregor,

Yes, that will work, provided that no users of libclosure-compiler-java
have concerns with jarwrapper (and its depdendencies, thus
binfmt-support and fastjar) being pulled in when they only want the
library.  Given that all 3 packages are small, it's probably a non-issue.

Thanks for the suggestion!
tony



signature.asc
Description: OpenPGP digital signature
__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#705565: Getting closure compiler back in testing?

2013-12-29 Thread Rogério Brito
Hi there.

Can we have a late Christmas present (or even an New Year's present)? The
closure compiler:

* has already been removed from testing [1]
* has many applications and users that depend/want it
* already has patches in the BTS [2]

[1]: http://packages.qa.debian.org/c/closure-compiler/news/20131229T163915Z.html
[2]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705565

Given this information, could we have something (even a NMU) to fix this?


Thanks in the name of the users,

Rogério.

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org/blog : Projects : https://github.com/rbrito/
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Bug#705565: Getting closure compiler back in testing?

2013-12-29 Thread tony mancill
On 12/29/2013 03:48 PM, Rogério Brito wrote:
 Hi there.
 
 Can we have a late Christmas present (or even an New Year's present)? The
 closure compiler:
 
 * has already been removed from testing [1]
 * has many applications and users that depend/want it
 * already has patches in the BTS [2]
 
 [1]: 
 http://packages.qa.debian.org/c/closure-compiler/news/20131229T163915Z.html
 [2]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705565
 
 Given this information, could we have something (even a NMU) to fix this?
 
 
 Thanks in the name of the users,

Hi Rogério,

I'll take a look to see if I can get the package building again.  Thanks
for pinging the list.

Cheers,
tony





signature.asc
Description: OpenPGP digital signature
__
This is the maintainer address of Debian's Java team
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers. 
Please use
debian-j...@lists.debian.org for discussions and questions.