Bug#823812: netbeans: non-free files
ml.axi/test/unit/src/org/netbeans/modules/xml/axi/resources/address1.xsd xml.axi/test/unit/src/org/netbeans/modules/xml/axi/resources/address2.xsd xml.axi/test/unit/src/org/netbeans/modules/xml/axi/resources/address3.xsd xml.axi/test/unit/src/org/netbeans/modules/xml/axi/resources/brokenSchema.xsd xml.axi/test/unit/src/org/netbeans/modules/xml/axi/resources/cycle.xsd xml.axi/test/unit/src/org/netbeans/modules/xml/axi/resources/include1.xsd xml.axi/test/unit/src/org/netbeans/modules/xml/axi/resources/include2.xsd xml.axi/test/unit/src/org/netbeans/modules/xml/axi/resources/items.xsd xml.axi/test/unit/src/org/netbeans/modules/xml/axi/resources/multifilePO.xsd xml.axi/test/unit/src/org/netbeans/modules/xml/axi/resources/newpo.xsd xml.axi/test/unit/src/org/netbeans/modules/xml/axi/resources/newpo1.xsd xml.axi/test/unit/src/org/netbeans/modules/xml/axi/resources/po.xsd xml.axi/test/unit/src/org/netbeans/modules/xml/axi/resources/types.xsd xml.schema.completion/test/unit/src/org/netbeans/modules/xml/schema/completion/resources/OTA_TravelItinerary.xsd xml.text/test/unit/src/org/netbeans/modules/xml/text/indent/OTA_TravelItinerary.xsd xml.wsdl.model/test/unit/src/org/netbeans/modules/xml/wsdl/model/resources/OTA_TravelItinerary.xsd contain "SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.". Less important issues include many files with "All Rights Reserved" but without reference to any particular license as well as files with (full text of) non-free licenses without scope where they apply: "nbbuild/licenses/TEL_For_NB_dbxGUI" contains "SUN Technology Evaluation License" limiting use of "Sun Studio GUI Modules for dbx debugger" to "One-hundred-twenty (120) days". "nbbuild/licenses/Northwoods" contains "3. You may only use the Software in binary form and only in conjunction with NetBeans". Please investigate. -- Best wishes, Dmitry Smirnov GPG key : 4096R/53968D1B --- However beautiful the strategy, you should occasionally look at the results. -- Winston Churchill signature.asc Description: This is a digitally signed message part. __ 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#823813: netbeans: non-DFSG .xsd files (no modification?)
Source: netbeans Version: 8.1+dfsg2-3 Severity: serious Usertags: dfsg Files: websvc.wsitmodelext/src/org/netbeans/modules/websvc/wsitmodelext/catalog/resources/wsrm-policy-200502.xsd websvc.wsitmodelext/src/org/netbeans/modules/websvc/wsitmodelext/catalog/resources/WS-Trust.xsd websvc.wsitmodelext/src/org/netbeans/modules/websvc/wsitmodelext/catalog/resources/metadata-exchange.xsd websvc.wsitmodelext/src/org/netbeans/modules/websvc/wsitmodelext/catalog/resources/optimizedmimeserialization-policy.xsd websvc.wsitmodelext/src/org/netbeans/modules/websvc/wsitmodelext/catalog/resources/ws-policy-10.xsd websvc.wsitmodelext/src/org/netbeans/modules/websvc/wsitmodelext/catalog/resources/wsat.xsd are licensed under terms allowing only distribution (i.e. "copy and display") while explicitly prohibiting everything else: "No other rights are granted by implication, estoppel or otherwise." I'm particularly concerned about modification rights that appears to be prohibited. Please investigate. -- Regards, Dmitry Smirnov. --- Truth — Something somehow discreditable to someone. -- H. L. Mencken, 1949 signature.asc Description: This is a digitally signed message part. __ 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#822290: colorpicker: disturbing text of license grant
Source: colorpicker Version: 1.0.0-2 Severity: normal Usertags: dfsg Some files have fairly disturbing text of license grant: You may not use, copy or modify this software, except in accordance with the license agreement you entered into with Jeremy Wood. For details see accompanying license terms. I'm not even sure if this is a reference to modified BSD-3-Clause license from "License.html" as the latter does not mention Jeremy Wood in the text of the license. I believe this text of license grant is not DFSG compliant as (most) users are unlikely to be in any direct license agreement with copyright owner. Please investigate. -- All the best, Dmitry Smirnov GPG key : 4096R/53968D1B signature.asc Description: This is a digitally signed message part. __ 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#796755: RFP: mpxj-java -- library to manipulate project information in various file formats
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org pkg-java-maintainers@lists.alioth.debian.org debian-qt-...@lists.debian.org Control: affects -1 calligra Package name: mpxj-java Version: 5.1.8 Upstream Author: Jon Iles jon.i...@bcs.org.uk License: LGPL-2.1+ URL: http://mpxj.sourceforge.net/ MPXJ provides a set of facilities to allow project information to be manipulated in Java and .Net. MPXJ supports a range of data formats: Microsoft Project Exchange (MPX), Microsoft Project (MPP,MPT), Microsoft Project Data Interchange (MSPDI XML), Microsoft Project Database (MPD), Planner (XML), Primavera (PM XML, XER, and database), Asta Powerproject (PP, MDB), and the Standard Data Exchange Format (SDEF). Calligra Plan can use MPXJ to import project data from foreign file formats. -- Cheers, Dmitry Smirnov. signature.asc Description: This is a digitally signed message part. __ 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#729943: jarwrapper: pass only 48 chars of Debian-Java-Parameters
On Wed, 19 Mar 2014 06:52:56 Niels Thykier wrote:
Why is perl needed rather than perl-base (which is essential). The
patch seems to be using none of the modules from perl or perl-modules
Good point. It's just that dependencies on perl-base are so rare probably
because ${perl:Depends} never expands as perl-base but only as perl.
I'll update dependency to perl-base. I think it should be just enough.
Thanks.
--
Cheers,
Dmitry Smirnov.
---
It is impossible to imagine Goethe or Beethoven being good at billiards
or golf.
-- H. L. Mencken
signature.asc
Description: This is a digitally signed message part.
__
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#729943: jarwrapper: pass only 48 chars of Debian-Java-Parameters
On Wed, 19 Mar 2014 07:23:24 Niels Thykier wrote:
because never expands as perl-base but only as perl.
Actually, you should probably just drop the dependency, since perl-base
is essential (and therefore causes a lintian error if you depend on it
without version).
You're right, depends-on-essential-package-without-using-version it is.
Perhaps the best would be to Depend on ${perl:Depends}. For jarwrapper it
expands to empty string.
Also ${perl:Depends} is missing from javahelper's Depends where (if added)
it expands to perl. I'll add ${perl:Depends} to Depends of javahelper as
the latter is actually using Perl scripts.
--
All the best,
Dmitry Smirnov.
signature.asc
Description: This is a digitally signed message part.
__
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#729943: jarwrapper: pass only 48 chars of Debian-Java-Parameters
This bug (potentially) affect ~40 packages... Would you like a friendly NMU to fix it? -- Regards, Dmitry Smirnov GPG key : 4096R/53968D1B --- However beautiful the strategy, you should occasionally look at the results. -- Winston Churchill signature.asc Description: This is a digitally signed message part. __ 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#729943: jarwrapper: pass only 48 chars of Debian-Java-Parameters
Hi Emmanuel, On Wed, 19 Mar 2014 00:33:50 Emmanuel Bourg wrote: I checked the suggested regexp and I confirm it parses properly the manifest entries. It's a bit sad to add a dependency on perl just for this though. Thanks for double-checking my fix. Although I added perl to Depends I'm not too sure if we have to add such explicit dependency since Perl is Priority: standard and therefore pretty much always installed. I feel comfortable with Perl as dependency. I'm not too comfortable with sed that is (IMHO) much harder to use not to mention that sometimes it is just not sufficient... Could you please commit your changes on alioth and upload a regular update instead? That would save the need to ack a NMU. Someone recently approved my request to join pkg-java (thanks if it were you) so I can do team uploads now. Perhaps I'll just include fix for #699180 as well... I've made all the changes in my local git clone of javatools but Alioth still not allow me to push (perhaps because I was added just recently). I'll wait some hours and try again... -- All the best, Dmitry Smirnov. signature.asc Description: This is a digitally signed message part. __ 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#661464: java-propose-classpath: rewrite proposal
Hi Niels,
Good to hear from you.
Thank you for your reply.
On Monday 27 February 2012 22:37:36 Niels Thykier wrote:
Thanks, though if you are talking about java-propose-classpath, I
believe you want to thank Matthew Johnson. :)
Thanks! :)
On a related note, I would love for jh_depends to be smarter and
generate ${java:Depends} based on the actual usage[0]. Actually, I
believe I have some code somewhere that might could be useful for this.
[0] Including checking for useless/overlinking and erroing out if
classes are missing etc.
I like this idea. :)
While I do not have time right now to give it a detailed review, I hope
we can use it (partly or even fully).
Either way would be fine, I will be happy if you manage to use any part.
P.S. Please don't worry about license compatibility because for javatools
I give permission to use GPL-2+ license.
I appreciate the gesture, but I cannot accept it[1]. It is possible
that we could bump the license of the existing javatools code to GPL-2+
or alternatively, I can also accept an unconditional GPL-2+ license on
your code.
My bad, I overlooked this paragraph in social contract - sorry.
Of course unconditional GPL-2+ is fine: I hereby grant permission to use this
code under GPL-2+ license.
I reckon it will be better to attach the script with updated license to avoid
any doubts. [attached]
All the best,
Dmitry.
listdeps-jar.sh
Description: application/shellscript
signature.asc
Description: This is a digitally signed message part.
__
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.
java-propose-classpath proposal
Dear Niels and Java Maintainers, Let me thank you sincerely for your work. I'm writing to you to share some feedback and improvements to java-propose- classpath which I hope you might find useful. But first please excuse me for starting with describing a problem: java-propose-classpath in its current form is not very useful, to say the least. The problem is that it makes assumptions that all the required dependencies can be satisfied with installed shared java libraries (jars). If the dependency is not installed the proposed class path is incomplete and there is no warning for incomplete dependency. This is very misleading. But the problem is much worse: if java-propose-classpath is given two jars, one primary and the other one providing needed classes, java-propose-classpath tries to calculate class path for both of them, completely ignoring their relationships. (unless all dependent jars are installed to /usr/share/java the calculated class path would be incorrect) Needless to say there are many cases when application may need to install private jars and java-propose-classpath could be a very useful tool to help calculate what libraries are really needed. Sadly many Java developers distribute their stuff as a bunch of jars some of which are not even needed and some of which can be substituted with debian packages providing needed dependencies. We need a better java-propose- classpath to help maintainers to package not so perfect java software. For example, java-propose-classpath could suggest what package provides the dependent java library. This could significantly ease tedious Depends calculation which for a moment can only be done manually. = I experienced all the above problems when I was struggling with packaging one Java application. To overcome the issues I wrote a helper bash script which successfully deals with all described problems and more. Initially I thought I would use my script to improve java-propose-classpath but this would replace over 90% of java-propose-classpath code. It appears to me that doing it the other way (merging java-propose-classpath with my script or using my slightly modified script to replace java-propose- classpath) may be an easier task. Sadly at the moment I can't afford spending enough time to do the merging work hence I'm sharing my script with you in hope that you can accommodate improvements, ideas and implementation to the package. === The attached bash script takes one or more jars as arguments and extract all the used classes to associative arrays using the method similar to one java- propose-classpath uses. If the required class is present in given jars it considered as satisfied dependency. Then script scans the jars installed to /usr/share/java and print out all the needed classes which are not provided by neither given nor shared jars. The identified shared jars providing classes required by given jars are then printed out, with corresponding packages providing them, if 'dlocate' is installed. My implementation is slightly faster and more flexible: it can use 'fastjar', but falls back to use 'jar' provided by openjdk; it can use 'jcf-dump' from gcj-jdk but falls back to 'javap' from openjdk. Because script heavily rely on bash associative arrays it is very important to use bash (= 4.2) because older versions affected by nasty memory leak. Without the license my script have roughly the same number of lines as java- propose-classpath so in the same size it does a bit more, including some progress indication which I find very useful when scanning large jars (it sometimes takes over 20 minutes). Please let me know what do you think. Hopefully with your suggestions we can accommodate improvements into javatools package easy enough. Please CC to me as I'm not subscribed to pkg-java-maintainers list. All the best, Dmitry. P.S. Please don't worry about license compatibility because for javatools I give permission to use GPL-2+ license. listdeps-jar.sh Description: application/shellscript signature.asc Description: This is a digitally signed message part. __ 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.
