Bug#276302: JavaCC and bootstrap/javacc.jar
Hi, In CVS, bootstrap/javacc.jar has all of the old COM.sun.labs classes within it (instead of the org.javacc ones). This causes a slight problem with the packaging of JavaCC I am doing for Debian, as the Sun classes do not have a "free" license. How would people feel if I were to replace CVS's bootstrap/javacc.jar with one generated by the 4.0 code (and made corresponding changes to build.xmls)? I've checked that it still builds and passes its unit tests with a 4.0 Jar (well, it would be rather worrying if it didn't!) Thanks, Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#410283: RFP: jtb -- a syntax tree builder to be used with the Java Compiler Compiler (JavaCC) parser generator
Package: wnpp Severity: wishlist * Package name: jtb Version : 1.3.2 Upstream Author : Wanjun Wang <[EMAIL PROTECTED]> and others * URL : http://compilers.cs.ucla.edu/jtb/ * License : BSD Programming Lang: Java Description : a syntax tree builder for JavaCC JTB is a syntax tree builder to be used with the Java Compiler Compiler (JavaCC) parser generator. It takes a plain JavaCC grammar file as input and automatically generates the following: * A set of syntax tree classes based on the productions in the grammar, utilizing the Visitor design pattern. * Two interfaces: Visitor and GJVisitor. Two depth-first visitors: DepthFirstVisitor and GJDepthFirst, whose default methods simply visit the children of the current node. * A JavaCC grammar jtb.out.jj with the proper annotations to build the syntax tree during parsing. New visitors, which subclass DepthFirstVisitor or GJDepthFirst, can then override the default methods and perform various operations on and manipulate the generated syntax tree. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#400501: ajaxterm release 0.10-1 and screen sizing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Julien, I'm interested in version 0.10 of ajaxterm, as it allows me to specify the screen size (Cols-x-Rows). I had a look at your package [1] and wondered if I could make a couple of suggestions to support this changeable screen size? In /etc/default/ajaxterm, add an env variable SIZE=80x25 In /etc/init.d/ajaxterm, pass the value of this variable in the start-stop-daemon call. Does this sound OK? [1] http://kirya.net/~julien/pkg-ajaxterm/ Thanks, Paul -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFnk/ULSXFtdTZVSURAqteAKCmVhI1voI+T0WhIs7ytMPLENyTuwCeLmWm WI+1vjKjSovpJYCfvU123vQ= =quwG -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#400501: ajaxterm release 0.10-1 and screen sizing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Julien, Thanks for the reply. You are absolutely right, of course, ajaxterm *doesn't* have a "--size" parameter. I'm rather confused now - I'm sure I've seen ajaxterm in the past *with* a "--size=ColxRow" parameter. Maybe I'd used a forked version, or (more likely) I'm just plain confused. Anyway, sorry for the confusion! Thanks, Paul Julien Valroff wrote: > package ajaxterm > forwarded 400501 [EMAIL PROTECTED] > thanks > > Le vendredi 05 janvier 2007 à 13:17 +, Paul Cager a écrit : >> Julien, > Hi Paul, > >> I'm interested in version 0.10 of ajaxterm, as it allows me to specify the >> screen size (Cols-x-Rows). I had a look at your package [1] and wondered >> if I could make a couple of suggestions to support this changeable screen >> size? > > Thanks for the suggestion. There are no changes I am aware of that could > help changing the size of the terminal (except the fact that the max > width is now set to 256 from release 0.8). It is planned upstream to > allow changing the size dynamically from the GUI, but for the moment, > nothing is done. > > The width and height must now be changed in both ajaxterm.py (main > script) and in ajaxterm.html (in the call of ajaxterm.Terminal > function). > Implementing your proposal in the Debian package would imply too many > changes in the upstream sources, I will however report your wish > upstream so as to allow this in the next release. > > Cheers, > Julien > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFnsRJLSXFtdTZVSURAgpPAJ4znQZzIDzlQSCsCrRQ1GvUt2xFowCfdBXp Gdzu5h7yeO80D6yKTGAuDIg= =6vri -END PGP SIGNATURE-
Bug#229364: java2html
I've not been able to contact the originator of this bug. Unless someone else comes forwards with a request for a fix, I think this is likely to be pretty low priority. Paul Original Message Subject: Your Debian Bug Report re Java2html Date: Wed, 27 Dec 2006 13:54:26 - (GMT) From: Paul Cager <[EMAIL PROTECTED]> Norbert, Sorry - I'm not sure if my previous email got through OK. Please would you have a look at the message below? Thanks, Paul Original Message Subject: Your Debian Bug Report re Java2html From:"Paul Cager" <[EMAIL PROTECTED]> Date:Fri, December 15, 2006 7:13 pm To: [EMAIL PROTECTED] -- Norbert, I have been looking at your bug report on Debian about the java2html package. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=229364 java2html always escapes non - iso-8859-1 characters to XML entities. javadoc where java2html output is often put into, allows source code and comments to be in any encoding, so this escaping is not always necessary. Please consider a parameter to java2html that disables character escaping. Can you tell me if you are still interested in a fix for this problem? If so would you mind sending me a sample Java program that I could use for testing? I can then make sure my changes do what you expect them to. Many thanks, Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#265150: id3tool description
This sounds like a good idea - it will also list id3tool as an option when someone does an apt-cache search on mp3. I'll expand the description when id3tools is next uploaded.
Bug#325551: How to handle filename conflict "aleph" (Packages aleph, tetex-bin, texlive-bin)?
Frank Küster wrote: > severity 389163 serious > thanks > > Dear release team, > > I just noticed > > , Etch RC policy: > | > | > | Packages must not install programs in the default PATH with > | different functionality with the same file name, even if they > | Conflict:. > ` > > We've got a problem here, since all three packages are in testing, > provide /usr/bin/aleph, and conflict with each other (or rather, the > *tex* packages conflict with aleph). > > The right solution to this would be to package the "new upstream version" > of aleph, which changes the name to afnix. However, the aleph package > has been orphaned (#374120), and the ITP afnix has not yet yielded a > package. I wouldn't want to rely on that for etch (although this is the > first time I contact Paul about this, so I might be wrong). > > If there'll be no afnix package in etch, the only other solution to this > problem seems to be to remove aleph from testing - any NMUing won't make > sense without doing the actual work of packaging afnix. > > To me it seems as if the current situation is better than having no > aleph/afnix at all. However, it violates the release policy. > > What should we do? > > Regards, Frank > Frank, Thanks for your email. Just to confirm - I have only just started to package AFNIX, so it might be some time before it is ready. Regards, Paul
Bug#389163: How to handle filename conflict "aleph" (Packages aleph, tetex-bin, texlive-bin)?
Frank Küster wrote: > Andreas Barth <[EMAIL PROTECTED]> wrote: > >> Why is it better than to drop aleph? If a package is way outdated, and >> RC buggy, and also aleph is practically unchanged since Sarge, I think >> that is still grounds for a removal. > > I haven't investigated about aleph. I just thought that, since it > doesn't have many bugs, even the current version might be useful, and > better than nothing. > > If Thomas packages afnix (together with Paul or separately), that's > probably the best choice. From a technical point of view, the package > names could also stay the same, so that we don't need to wait for NEW > processing (but you RMs might have a magic wand to speed up that?) > > Regards, Frank It is probably worth pointing out that AFNIX isn't just Aleph with a new name - the language and system has moved on considerably since the final Aleph release in 2003 (see http://www.afnix.org/htm/desc.htm). So I would not expect the upstream author to be too happy with a Debian version of AFNIX called Aleph, or vice-versa. I'm very new to Debian packaging and it's likely to take me a lot longer to package AFNIX than an experienced developer (and the chances of errors in my packaging is a lot higher). So if you need an AFNIX package quickly I would be more than happy to stand aside and let an experienced developer at it - you are welcome to use my work on it so far, or start from scratch at your discretion. Having said that, I do not think it is sensible to regard AFNIX as a new upstream version of Aleph - it is more like a totally new package as so much of the build system and runtime are different. Would it be wise to rush it into Etch (even with a competent developer packaging it!) Just for background information, I chose to package AFNIX partly because I wanted to take my time and learn more about packaging non-trivial systems - no-one would be in any rush for the AFNIX package, would they? Just shows how wrong I can be Let me know what you think. Thanks, Paul
Bug#276302: JavaCC Licensing - now a pure BSD license.
The authors of JavaCC have now re-licensed the JavaCC code under a pure BSD license (http://www.opensource.org/licenses/bsd-license.html). This should clear up the doubts some organisations have had regarding the "Nuclear" and "Weapons" clauses in the original license, and the export restrictions imposed therein. Many thanks to the following authors who gave their permission for the relicensing: Sun Microsystems Inc, Sreenivasa Viswanadha and Kees Jan Koster. The updated source code has now been committed to the JavaCC CVS repository. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#397045: ant - java-gcj-compat-dev as dependency
Currently: Depends: java-gcj-compat | java-virtual-machine, java-gcj-compat | java1-runtime | java2-runtime, libxerces2-java Recommends: ant-optional, jikes | java-compiler Should ant Depend or Suggest the compiler packages? I'd say Depend, but I suppose its not an absolute dependency - you could have a buildfile that doesn't call javac. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#397045: ant - java-gcj-compat-dev as dependency
Michael Koch wrote: > On Sun, Mar 04, 2007 at 01:35:12AM +0000, Paul Cager wrote: >> Currently: >> >> Depends: java-gcj-compat | java-virtual-machine, java-gcj-compat | >>java1-runtime | java2-runtime, libxerces2-java >> Recommends: ant-optional, jikes | java-compiler >> >> Should ant Depend or Suggest the compiler packages? I'd say Depend, but >> I suppose its not an absolute dependency - you could have a buildfile >> that doesn't call javac. > > Recommends is the right thing. Its no hard dependency but its the > used/needed in most cases. Recommends are installe by default by aptitude > and synaptic but you can choose to deinstall or not install at all the > compiler. IMO that bug should just be closed as people need to be aware > what they break when they dont install the Recommends. > > From the Debian Policy 7.2: > > Recommends > > This declares a strong, but not absolute, dependency. > > The Recommends field should list packages that would be found together > with this one in all but unusual installations. > > > Cheers, > Michael I must learn not to write these things late at night - where I'd written Suggest, I meant Recommend. apt-get won't, of course, install the recommended packages, but I don't think I can put up any strong defence for "Depends", which is defined in the policy as: "required ... to provide a significant amount of functionality" I admit defeat and agree it should be Recommends. The warning message "unable to locate tools.jar" is a bit cryptic, but it should be followed later by an error "Unable to find a javac compiler". Is there anything else we could do to make it more obvious to the user that he/she needs to install a compiler? Amend the package's description maybe? Expand the Debian Java FAQ? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#344112: Your Debian ITP for the Java forehead package
Aldous, I am interested in a Debian version of the "forehead" Java library, and I noticed your ITP for it (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=344112). I was just wondering how it was going, and if you had an idea of when it is likely to be completed? Or, if you no longer have the time to complete the packaging, I'd be happy to help. Sorry to bother you. Thanks, Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#353586: ant-bootstrap.jar failure
EspeonEefi wrote:
> reopen 353586
> severity 353586 minor
> thanks
>
> I can reproduce this error using the attached very simple build.xml and
> HelloWorld java program. Indeed, ant by default still automatically
> adds /usr/share/ant/lib/ant-bootstrap.jar to the classpath. Note, though
> that the warning occurs only when the -Xlint compilerarg is passed to
> javac, and the warnings don't make anything fail, so I've downgraded the
> severity of this bug to minor.
>
> Just as a refresher, the output that ant build gives is
>
>
> Buildfile: build.xml
>
> build:
> [javac] Compiling 1 source file
> [javac] warning: [path] bad path element
> "/usr/share/ant/lib/xml-apis.jar": no such file or directory
> [javac] warning: [path] bad path element
> "/usr/share/ant/lib/xercesImpl.jar": no such file or directory
> [javac] warning: [path] bad path element "/usr/share/ant/lib/xalan.jar":
> no such file or directory
> [javac] 3 warnings
>
> BUILD SUCCESSFUL
> Total time: 2 seconds
>
>
> Some Googling turns up that the above warnings may be a result of
> extraneous things in the Class-Path attribute in the
> META-INF/MANIFEST.MF file of a JAR. Indeed, when I
> unjar /usr/share/ant/lib/ant-bootstrap.jar, I find in
> META-INF/MANIFEST.MF the line
>
> Class-Path: ant.jar xml-apis.jar xercesImpl.jar xalan.jar
>
> Now, according to the documentation for the JAR file format [1], the
> Class-Path attribute "specifies the relative URLs of the extensions or
> libraries that this application or extension needs." This is why javac
> is looking for xml-apis.jar, xercesImpl.jar, and xalan.jar
> in /usr/share/ant/lib/ (the same directory as ant-bootstrap.jar) and not
> in /usr/share/java/, where at least xercesImpl.jar lives. (Given that
> ant now uses Xerces and not Xalan, it's interesting that xml-apis.jar
> and xalan.jar still show up in this Class-Path line.)
>
> [1] http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html#Main%20Attributes
>
> Thus, this is indeed a bug in ant that the Class-Path attribute in
> MANIFEST.MF in ant-bootstrap.jar is referencing non-existent jars.
>
>
>
>
> public class HelloWorld {
> public static void main(String[] args) {
> System.out.println("Hello, world!");
> }
> }
Thank you for investigating this further. Yes, you are quite right -
bootstrap.jar is in /usr/share/ant/lib/ and *will* be included in the
class path.
Looking at the Apache binary download (of 1.7), I see that the bootstrap
Jar is normally in the "etc" directory, and the Debian packaging moves
it to /usr/share/ant/lib/. I am not sure this is the correct place for
the bootstrap Jar to live (but I agree that "etc" isn't the correct
place either). In fact, do we need to deliver it at all in the binary
deb package?
Maybe this bug can be fixed when the next upstream version is packaged?
Thanks,
Paul
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#413751: RFP: slf4j -- The Simple Logging Facade for Java (SLF4J)
Package: wnpp Severity: wishlist * Package name: slf4j Version : 1.3.0 Upstream Author : * URL : http://www.slf4j.org/ * License : permissive X11 type license Programming Lang: Java Description : The Simple Logging Facade for Java (SLF4J) is a simple facade for various logging APIs The Simple Logging Facade for Java (or SLF4J) is intended to serve as a simple facade for various logging APIs allowing to the end-user to plug in the desired implementation at deployment time. SLF4J also allows for a gradual migration path away from Jakarta Commons Logging (JCL). Logging API implementations can either choose to implement the the SLF4J interfaces directly, e.g. logback or SimpleLogger. Alternatively, it is possible (and rather easy) to write SLF4J adapters for the given API implementation, e.g. Log4jLoggerAdapter or JDK14LoggerAdapter.. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#413847: afnix: FTBFS on GNU/kFreeBSD: two tiny tweaks needed
Hi Cyril, Thanks very much for your bug report about AFNIX on GNU/kFreeBSD. I'll incorporate your patch in my next upload (and send it to upstream). Thanks again, Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#349779: Further Information
As I'm interested in BCEL I thought I would do a little further investigation of this problem. Of the 3 URLS given above, https://bugs.eclipse.org/bugs/show_bug.cgi?id=62631 is the most useful - it identifies the failing line of code in BCEL. The following URL gives the change made by the BCEL author to fix the problem: http://svn.apache.org/viewvc/jakarta/bcel/trunk/src/main/java/org/apache/bcel/generic/LDC_W.java?r1=152856&r2=152900 --- jakarta/bcel/trunk/src/java/org/apache/bcel/generic/LDC_W.java 2003/05/23 07:55:36152856 +++ jakarta/bcel/trunk/src/java/org/apache/bcel/generic/LDC_W.java 2004/11/09 20:02:42152900 @@ -84,5 +84,6 @@ setIndex(bytes.readUnsignedShort()); // Override just in case it has been changed opcode = org.apache.bcel.Constants.LDC_W; +length = 3; } } (This is slightly different from the suggestion made by the AspectJ developers). I have verified that this fix has been incorporated in the latest release of BCEL (5.2), so presumably we could close this bug by packaging the new upstream release.
Bug#395255: Further Information: jargs now available in unstable.
I noticed that Yann Dirson has now created a jargs package, so that is half of this bug fixed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#276302: New upstream release and license debate
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've had a look at the new upstream release (4.0), and it's still not clear if it is DFSG compliant. The website[1] explicitly states that the license is "Berkeley Software Distribution (BSD) License". In an answer to a query the author (Sreenivas Viswanadha) states that the "entire javacc distribution, including the example grammars comes under BSD license"[2]. The LICENSE file in the distribution is the standard BSD license, but with the following paragraph added at the end: "You acknowledge that this software is not designed, licensed or intended for use in the design, construction, operation or maintenance of any nuclear facility." Most of the source files contain a copyright declaration ending with: "Nuclear, missile, chemical biological weapons or nuclear maritime end uses or end users, whether direct or indirect, are strictly prohibited. Export or reexport to countries subject to U.S. embargo or to entities identified on U.S. export exclusion lists, including, but not limited to, the denied persons and specially designated nationals lists is strictly prohibited." I guess that the author intends it to be truly free software, but hasn't removed all of the licensing cruft left over from its time as a proprietary Sun product - assuming he is legally entitled to do so. I'll send him an email about it. [1] https://javacc.dev.java.net/ [2] https://javacc.dev.java.net/servlets/ReadMsg?listName=users&msgNo=919 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFbrVfLSXFtdTZVSURAqJfAJ4pndKy8aPbvLgHDwF0d4QB+QqY7ACfcSZD oOYJBxDpAPrLYvgcE6B29e0= =A9+8 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#400360: Updated website location
The website listed in the copyright file (http://kitsumi.cowspiracy.org/id3tool/index.html) is no longer correct. The new website is http://nekohako.xware.cx/id3tool/index.html. Upstream has a new release: * fixed broken getopt string (should close debian bug #280180) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#276302: [Fwd: Re: Sun License for JavaCC]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It looks as though upstream will be changing JavaCC to a pure BSD license, or (if we can't wait) we have been granted permission to patch the source ourselves. - Original Message Subject: Re: Sun License for JavaCC Date: Fri, 01 Dec 2006 17:42:28 -0600 From: Tom Marble <[EMAIL PROTECTED]> To: Paul Cager <[EMAIL PROTECTED]> CC: Simon Phipps <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED] References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Paul: I'm fairly familiar with debian-legal and you are right -- they will not accept this kind of license. I have inspected the code and found that the top level LICENSE file has this (non standard language) from stock BSD: http://www.opensource.org/licenses/bsd-license.html And several of the source files have incorrect and/or incomplete copyright blocks. We have approval from Sun Legal to fix these problems. Correct copyright & license block would be following the OSI template (above URL) with the values: = Sun Microsystems, Inc. = Sun Microsystems, Inc. = 2006 You may make these changes as a downstream delta patch. Thank you for packaging JavaCC for Debian!!! Sreeni: Please fix the JavaCC code (upstream) with these copyright and license fixes as well. Warmest Regards, - --Tom Paul Cager wrote: > Simon, > > As you can see below, Michael Van De Vanter felt you might be able to > help me with a problem Debian Linux has encountered with the licensing > of the JavaCC product. > > Would you mind having a look at my explanation of the problem, below, > and let me know your views on the matter? > > Many thanks, > Paul Cager > > Michael Van De Vanter wrote: >> Paul, >> >> My understanding is that your concerns can be addressed by Sun. Please >> contact Simon Phipps of our Open Source office to get this resolved, >> and cc Tom Marble and Barton George. >> >> Feel free to drop me off the conversation. There's probably little >> further value I can add unless historical questions arise concerning the >> technology or my original efforts to push it into Open Source. >> Fortunately, it is much easier now. >> >> Michael V. >> >> Michael L. Van De Vanter, Ph.D.Email: [EMAIL PROTECTED] >> Sun Microsystems Inc. Tel: +1 650 786-8864 >> 16 Network Circle, UMPK16-304 IM: [EMAIL PROTECTED] >> Menlo Park, CA 94025 USA Skype: michaelvandevanter >> http://homepage.mac.com/mlvdv/home.html >> >> On Nov 30, 2006, at 3:05 PM, Paul Cager wrote: >> >>> Michael, >>> >>> I am writing to you as you were the author of the original announcement >>> that JavaCC was to be made Open Source under a BSD license >>> (http://www.experimentalstuff.com/Technologies/JavaCC/announce.html). A >>> long time ago, I know, but as Sun still holds the copyright on JavaCC, >>> Sreeni & co (at java.dev.net) would not be able to help. I apologise for >>> taking up your time. >>> >>> A question has been raised in the Debian Linux distribution about >>> JavaCC's license (see >>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=276302 for the full >>> story). As you might know, Debian has a very strict definition of "Free >>> Software", and software which doesn't meet this definition cannot become >>> part of the "main" distribution. >>> >>> Although JavaCC is released using the BSD license, there are a couple of >>> "non-free" restrictions in the "LICENSE" file and copyright statements >>> at the head of the source files. The license file ends with: >>> >>>"You acknowledge that this software is not designed, licensed or >>> intended for use in the design, construction, operation or maintenance >>> of any nuclear facility." >>> >>> This is probably incompatible with one of Debian's guidelines: "The >>> license must not restrict anyone from making use of the program >>> in a specific field of endeavor." >>> >>> So my questions: >>> >>> 1) Does Sun still require these non-standard clauses in the license >>> (compared to the plain BSD license)? >>> >>> 2) If not, could Sun authorise the current maintainer of JavaCC >>> (Sreeni) to remove them from the current source code? >>> >>> Once again, apologies for taking up your time. >>> >>> Thanks, >>> Paul Cager. > - -- _ [EMAIL PROTECTED] (952) 832-4123 Senior Java Performance Engineer Sun Microsystems, Inc. http://blogs.sun.com/tmarbleWhat do you want from Java Libre? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFcMaFLSXFtdTZVSURAiYcAKCR1mW91pKZh/eEdxbF75OezafVBwCfVtGn 4EXuC//3OGTf2mvgFhW2RCA= =Prkz -END PGP SIGNATURE- signature.asc Description: PGP signature
Bug#229364: [Fwd: Re: Your java2hml program]
Original Message Subject: Re: Your java2hml program Date: Fri, 1 Dec 2006 13:43:38 +0100 From: Florian Schintke <[EMAIL PROTECTED]> To: Paul Cager <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> Hi, in principle I am still interested in the java2html program, but actually I have very few spare time and the tool seems to be very stable. Regarding the feature request, I cannot promise anything. I noticed it, thanks for the info, but when I have time to implement this, I don't know. If you are able by yourself to implement it, just do so and send me the patch, which I will check then. I will be happy to include your contribution then. I know that this is not the main task of a Debian maintainer, but maybe you have fun doing this nevertheless. Thanks and a nice weekend, Florian [Paul Cager] > Hi, > > I?m maintaining the Debian package for your java2html program > (http://user.cs.tu-berlin.de/~schintke/x2html/). I was just wondering if > you are still interested in receiving bug reports / feature requests for > your program? > > For your information, there is one Debian user?s feature request > outstanding at our end: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=229364 > > > >?java2html always escapes non - iso-8859-1 characters to XML > entities. > > >javadoc where java2html output is often put into, allows source > > >code and comments to be in any encoding, so this > > >escaping is not always necessary. > > >Please consider a parameter to java2html that disables character > escaping.? > > Sorry to bother you! > > Thanks, > Paul > Florian Schintke -- Florian Schintke <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#407659: Adopt micro-proxy
retitle 407659 ITA: micro-proxy -- really small HTTP/HTTPS proxy owner 407659 [EMAIL PROTECTED] thanks I'm adopting this package because I would not like to see it dropped from the archive. A small, self-contained program like this is a good way to learn about proxies. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#411929: RFP: imagefilters-java -- manipulation and filtering of images in Java
Package: wnpp Severity: wishlist * Package name: imagefilters-java Version : 2.0.235 Upstream Author : Jerry Huxtable * URL : http://www.jhlabs.com/ip/filters/index.html * License : Apache 2.0 Programming Lang: Java Description : manipulation and filtering of images in Java A large number of Java Image filters which are all standard Java BufferedImageOps and can be plugged directly into existing programs. . Many of these filters are useful in applications such as games where images need to be generated on the fly, or where it's quicker to generate them rather than downloading them. For instance, it's quicker to download one image and rotate it several times than to download several separate images. . Another use for the filters is in animation. For example animating the Water Ripple filter can produce a nice rippling effect. Some of the filters have a time parameter for this purpose. . All of the filters are designed to work with TYPE_INT_ARGB images. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#389163: Request removal of Aleph.
package aleph reassign 389163 ftp.debian.org retitle -1 Request removal of Aleph. noowner -1 thanks Please can aleph be removed from unstable. Aleph has been replaced by AFNIX which entered the incoming queue today. Please see #379564 for further information, and a request from Mohammed Adnène Trojette for Aleph's removal. Thanks, Paul
Bug#412952: [Fwd: Bug#412952: file conflicts between afnix and aleph]
Could I have some advice about the best way to fix this one please? Here's a summary: * The obsolete package "aleph" is supserseded by "afnix". * I've requested the removal of aleph from unstable (bug #389163). * There is already another RC bug against "aleph", as it conflicts with tetex-bin. I didn't make afnix "Replaces:" aleph because aleph is scheduled for removal. I guess I should have done? What would be best - uploading a new version of afnix, or marking this bug as blocked by 389163? Thanks, Paul Original Message Subject: Bug#412952: file conflicts between afnix and aleph From:"Michael Ablassmeier" <[EMAIL PROTECTED]> Date:Thu, March 1, 2007 8:00 am To: [EMAIL PROTECTED] -- Package: afnix, aleph Severity: serious Justification: file conflicts between packages, policy violation hi, both afnix and aleph do ship several files of eachother but do not conflict or add a diversion, thus fail to be installed on the same environment: Unpacking aleph (from .../aleph_0.9.0-3_amd64.deb) ... dpkg: error processing /var/cache/apt/archives/aleph_0.9.0-3_amd64.deb (--unpack): trying to overwrite `/usr/bin/axc', which is also in package afnix dpkg-deb: subprocess paste killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/aleph_0.9.0-3_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) full list of files conflicting: 'usr/share/man/man1/axc.1.gz' 'usr/share/man/man1/axl.1.gz' 'usr/bin/axc' 'usr/bin/axd' 'usr/bin/axl' bye, - michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#412952: [Fwd: Bug#412952: file conflicts between afnix and aleph]
Frank Küster wrote: > Michael Koch <[EMAIL PROTECTED]> wrote: > >> Add this to afnix: >> >> Conflicts: aleph >> Replaces: aleph >> >> This should make it possible to have always one of them installed and >> make afnix replace aleph on dist-upgrades. > > Isn't > > Provides: aleph > > also needed? > > Regards, Frank I've had a look at the relevant sections of the Policy, and I can see some advantages to having "Provides:". But, on balance, I think it is probably best left out, letting the "Aleph" name wither and die: * It is a long time since Aleph became AFNIX (2003). I do not believe too many people would still refer to it as Aleph, or attempt to install it as "apt-get install aleph". * Upstream make very little reference to the old name; just one mention, as far as I can see, in the "history" paragraph. * I believe the word "aleph" is probably more closely associated with TeX, now. I would be happy to change my mind if anyone has any counter-arguments to the above! In the mean time I have uploaded a new package to mentors.debian.net, and asked my mentor if he would consider sponsoring an upload. Thanks, Paul
Bug#428575: ITP: plexus-i18n -- Plexus internationalisation package.
Package: wnpp Severity: wishlist Owner: Paul Cager <[EMAIL PROTECTED]> * Package name: plexus-i18n Version : 1.0-beta-6 Upstream Author : Plexus Developers * URL : http://plexus.codehaus.org * License : Apache Programming Lang: Java Description : Plexus internationalisation package. Required for maven2 packaging -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#428575: ITP: plexus-i18n -- Plexus internationalisation package.
Christian Perrier wrote: >>> Description : Plexus internationalisation package. >>> >>> Required for maven2 packaging >> Shouldn't this be named plexus-l10n instad? Most of the time «-i18n» is >> the wrong names for those packages that are actually localization ones, >> which include translations and such. Internationalization is the action >> of preparing a software to be localized by translation teams for example. > > Agreed. This package must be named -l10n Apologies for the over-brief description of the package. My fault - I guess I was too eager to get on with the packaging! I'll fix that later. This package provides software components that can be used to localise Plexus, rather than the localisations themselves. In that case is i18n right? > > The long description should also be reworked. "Required for maven2 > packaging" tells nothing about the package. > > There should be a paragraph explaining what Plexus is and another > adding that "This package includes localization data For Plexus". > > Also, please remove the dot at the end of the short description. > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#428643: ITP: maven-ant-helper -- package helper scripts for building Maven components with ant
Package: wnpp Severity: wishlist Owner: Paul Cager <[EMAIL PROTECTED]> * Package name: maven-ant-helper Version : 1.0 Upstream Author : Trygve Laugstøl <[EMAIL PROTECTED]> * URL : http://svn.debian.org/wsvn/pkg-java/trunk/maven-ant-helper * License : Apache Programming Lang: Java Description : package helper scripts for building Maven components with ant An environment that can be used to simplify the creation of Debian packages to support the Maven system. A "modello" ant task is also provided. . Homepage: http://svn.debian.org/wsvn/pkg-java/trunk/maven-ant-helper -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#428643: [Fwd: Re: RFS: maven-ant-helper]
Michael Koch wrote: > plexus-i18n depends on maven-ant-helper which has some issue: > > debian/copyright: "Copyright holder" should be "Author" > debian/copyright: copyright with year is missing I have changed it to use the dh_make template (and also added a license declaration to the Java file). > > debian/changelog: a native debian package should be versioned 1, 2, 3, > ... and not 1.0, etc. This would be an NMU with a wrong NMU version. As discussed on IRC - will change to single digit. I've bumped the version to 2 as there were quite a few different version 1's in existence. > debian/rules: This needs to be cleaned up a lot. Best to port this to > CDBS at this point. OK - ported to CDBS. > debian/control: The Depends line of maven-ant-helper should be all in > one line. Done. > debian/changelog closes no ITP bug. Bug 428643 raised - closed by the upload. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426227: Licensing plexus-velocity.
Hi Jason, I'm intending to package plexus-velocity for the Debian distribution, but noticed that the source files do not have any license information within them. Would it be possible to fix it? Can I help in any way? Thanks, Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#413554: Licensing Doxia for Debian
Hi Jason, Sorry to bother you again, but you are also listed as the Project Lead for Doxia. I'm intending to package Doxia for the Debian distribution, but noticed that some source files do not have any copyright or license information within them. Would it be possible to fix this? As before I'd be happy to help if there is anything I could do. Thanks, Paul These files have no copyright statement or license declaration: doxia-sink-api/src/main/java/org/codehaus/doxia/sink/Sink.java doxia-core/src/main/java/org/apache/maven/doxia/module/confluence/parser/table/TableRowBlock.java doxia-core/src/main/java/org/apache/maven/doxia/module/confluence/parser/SectionBlock.java doxia-core/src/main/java/org/apache/maven/doxia/module/common/ByLineReaderSource.java doxia-core/src/main/java/org/apache/maven/doxia/module/common/ByLineSource.java These files have "Copyright (c) 2005 Your Corporation. All Rights Reserved" with no license declaration: doxia-core/src/main/java/org/apache/maven/doxia/module/confluence/parser/SectionBlockParser.java doxia-core/src/main/java/org/apache/maven/doxia/module/confluence/parser/VerbatimBlock.java doxia-core/src/main/java/org/apache/maven/doxia/module/confluence/parser/VerbatimBlockParser.java doxia-core/src/main/java/org/apache/maven/doxia/module/confluence/parser/TextBlock.java -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426219: ITP: plexus-component-factories -- Plexus factories for bsh, ant components etc
Package: wnpp Severity: wishlist Owner: Paul Cager <[EMAIL PROTECTED]> * Package name: plexus-component-factories Version : svn Upstream Author : Plexus Authors * URL : http://plexus.codehaus.org * License : Apache Programming Lang: Java Description : Plexus factories for bsh, ant components etc Factories used to create bsh, ant components etc, within Plexus. Used as part of maven2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426226: ITP: plexus-compiler -- Interface to compilers within Plexus
Package: wnpp Severity: wishlist Owner: Paul Cager <[EMAIL PROTECTED]> * Package name: plexus-compiler Version : svn Upstream Author : Plexus Authors * URL : http://plexus.codehaus.org * License : Apache Programming Lang: Java Description : Interface to compilers within Plexus The Plexus compiler manager, API and compilers. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426227: ITP: plexus-velocity -- The Plexus Velocity Component
Package: wnpp Severity: wishlist Owner: Paul Cager <[EMAIL PROTECTED]> * Package name: plexus-velocity Version : svn Upstream Author : Plexus Authors * URL : http://plexus.codehaus.org * License : Apache Programming Lang: Java Description : The Plexus Velocity Component The Plexus component interface to Velocity. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426228: ITP: plexus-digest -- a component of maven2
Package: wnpp Severity: wishlist Owner: Paul Cager <[EMAIL PROTECTED]> * Package name: plexus-digest Version : svn Upstream Author : Plexus Developers * URL : http://plexus.codehaus.org * License : Apache Programming Lang: Java Description : a component of maven2 Provides digest services to Plexus. Used in maven2 builds. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#421428: ITP: commons-openpgp -- a common and simple Java interface for generating and verifying OpenPGP signatures
Package: wnpp Severity: wishlist Owner: Paul Cager <[EMAIL PROTECTED]> * Package name: commons-openpgp Version : svn 533437 Upstream Author : Brett Porter, Stefan Bodewig * URL : http://jakarta.apache.org/commons/sandbox/openpgp/index.html * License : Apache V2 Programming Lang: Java Description : a common and simple Java interface for generating and verifying OpenPGP signatures Commons OpenPGP was started to produce a common and simple interface for generating and verifying OpenPGP signatures. Currently implemented using BouncyCastle, it is intended to allow pluggable providers so that alternate open source and commercial providers can be used. The library was started by Maven and Ant committers to enable the use of OpenPGP from these tools. Currently, Maven uses it in its development version to sign libraries released to the repository. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#421626: ITP: modello -- a Data Model toolkit in use by the Maven 2 Project
Package: wnpp Severity: wishlist Owner: Paul Cager <[EMAIL PROTECTED]> * Package name: modello Version : latest Upstream Author : Brett Porter ([EMAIL PROTECTED]) * URL : http://modello.codehaus.org * License : http://opensource.org/licenses/mit-license.php Programming Lang: Java Description : a Data Model toolkit in use by the Maven 2 Project Modello is used to build the maven system. Once a DataModel is defined, the toolkit can be used to generate any of the following at compile time. * Java Pojos of the DataModel. * Java Pojos to XML Writer. (provided via xpp3, stax, jdom or dom4j) * XML to Java Pojos Reader. (provided via xpp3, stax or dom4j) * XDOC documentation of the DataModel. * XML Schema to validate the DataModel. * Java Model to Prevayler Store (actually this plugin is in the sandbox). * Java Model to JPOX Store. * Java Model to JPOX Mapping. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#424547: tagging 424547
On Fri, June 29, 2007 9:44 am, Martin Michlmayr wrote: > * Paul Cager <[EMAIL PROTECTED]> [2007-06-03 23:49]: >> # Automatically generated email from bts, devscripts version 2.10.2 >> tags 424547 + pending > > Any chance to get this fixed package uploaded within the next few > days? We're preparing to move to 4.2 as the default compiler, see > http://lists.debian.org/debian-devel-announce/2007/06/msg8.html > If you need a sponsor, please let me know. > -- > Martin Michlmayr > http://www.cyrius.com/ Martin, The fixed package is currently with Michael Koch (as sponsor), but this is the first time he has seen this package (previous versions were sponsored by a different DD). It might take a few iterations for me to get it right, but it hasn't been forgotten! Thanks, Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426227: Licensing plexus-velocity.
On Sat, June 16, 2007 11:27 am, Paul Cager wrote: > Hi Jason, > > I'm intending to package plexus-velocity for the Debian distribution, > but noticed that the source files do not have any license information > within them. > > Would it be possible to fix it? Can I help in any way? > > Thanks, > Paul > i have raised a JIRA issue for this problem: http://jira.codehaus.org/browse/PLX-342 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#413554: Licensing Doxia for Debian
On Tue, June 19, 2007 1:02 am, Paul Cager wrote: > Hi Jason, > > Sorry to bother you again, but you are also listed as the Project Lead > for Doxia. > > I'm intending to package Doxia for the Debian distribution, > but noticed that some source files do not have any copyright or license > information within them. > > Would it be possible to fix this? As before I'd be happy to help if > there is anything I could do. > > Thanks, > Paul > > These files have no copyright statement or license declaration: > doxia-sink-api/src/main/java/org/codehaus/doxia/sink/Sink.java > doxia-core/src/main/java/org/apache/maven/doxia/module/confluence/parser/table/TableRowBlock.java > doxia-core/src/main/java/org/apache/maven/doxia/module/confluence/parser/SectionBlock.java > doxia-core/src/main/java/org/apache/maven/doxia/module/common/ByLineReaderSource.java > doxia-core/src/main/java/org/apache/maven/doxia/module/common/ByLineSource.java > > > These files have "Copyright (c) 2005 Your Corporation. All Rights > Reserved" with no license declaration: > doxia-core/src/main/java/org/apache/maven/doxia/module/confluence/parser/SectionBlockParser.java > doxia-core/src/main/java/org/apache/maven/doxia/module/confluence/parser/VerbatimBlock.java > doxia-core/src/main/java/org/apache/maven/doxia/module/confluence/parser/VerbatimBlockParser.java > doxia-core/src/main/java/org/apache/maven/doxia/module/confluence/parser/TextBlock.java > For information, I have created a JIRA issue for this: http://jira.codehaus.org/browse/DOXIA-126 Thanks, Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#413554: Licensing Doxia for Debian
On Mon, July 2, 2007 3:59 pm, Paul Cager wrote: > On Tue, June 19, 2007 1:02 am, Paul Cager wrote: >> I'm intending to package Doxia for the Debian distribution, >> but noticed that some source files do not have any copyright or license >> information within them. >> >> These files have no copyright statement or license declaration: >> >> [...] >> >> These files have "Copyright (c) 2005 Your Corporation. All Rights >> Reserved" with no license declaration: >> >> [...] >> > For information, I have created a JIRA issue for this: > http://jira.codehaus.org/browse/DOXIA-126 This problem has already been fixed by upstream, but not yet released: http://svn.apache.org/viewvc?view=rev&revision=496703 I think this should be enough to satisfy the ftp-masters. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#426227: Licensing plexus-velocity.
Jason van Zyl wrote: > It's all ASL licensed if not marked as such. > > On 2 Jul 07, at 8:06 AM 2 Jul 07, Paul Cager wrote: > >> On Sat, June 16, 2007 11:27 am, Paul Cager wrote: >>> Hi Jason, >>> >>> I'm intending to package plexus-velocity for the Debian distribution, >>> but noticed that the source files do not have any license information >>> within them. >>> >>> Would it be possible to fix it? Can I help in any way? >>> > > Provide patches that make the files look like this: > > http://svn.codehaus.org/plexus/plexus-containers/trunk/plexus-container-default/src/main/java/org/codehaus/plexus/DefaultComponentLookupManager.java Jason, Thanks for the advice. I have attached a patch to the JIRA issue: http://jira.codehaus.org/secure/attachment/28239/PLX-342.patch Thanks, Paul > > Or, I'll give you temporary access to fix whatever files you find need > fixing. > > I don't have time change this stuff right now, but I'll eventually get > there as I will propose to move Plexus to Apache at some point in the > near future. > >>> Thanks, >>> Paul >>> >> >> >> i have raised a JIRA issue for this problem: >> http://jira.codehaus.org/browse/PLX-342 >> > > Thanks, > > Jason > > -- > Jason van Zyl > Founder and PMC Chair, Apache Maven > jason at sonatype dot com > -- > > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#413554: Missing license info in source files - fixed in upstream svn
I'm packaging a couple of Java libraries where the source files do not have any license declarations. This is being fixed in upstream's svn repository. I still want to package upstream's latest *release* rather than the head of svn, so is it OK just to explain the situation in README.Debian-source (leaving the source files without license declarations)? Thanks, Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#389887: More information required.
tags 389887 + moreinfo thanks Regarding your Debian bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=389887 I am not sure if I understand the problem you are reporting. If you want to include a Jar on your classpath you must user the filename of the Jar itself, not just the owning directory, e.g. java -cp /usr/share/java/foo.jar your.package.YourClassName Please can you give me some examples of failing Java source and command line invocation? Thanks, Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#288655: Opinions on "Paul Hsieh derivative license"
Ben Finney wrote: > Paul Cager <[EMAIL PROTECTED]> writes: > >>> Copyright (C) 2005, 2006 The MyServer Team >>> This program is free software; you can redistribute it and/or modify >>> it under the terms of the GNU General Public License as published by >>> the Free Software Foundation; either version 2 of the License, or >>> (at your option) any later version. > > So, with this, the terms require that the redistributor must license > under the terms of the GPL, with no further restrictions. > >>> The superFastHash hash function [is] released under the Paul Hsieh >>> derivative license [...] > > If this license requires restrictions additional to those in the GPL, > then it is GPL-incompatible and cannot be redistributed under either > license. > >>> Paul Hsieh derivative license >>> >>> [...] Use and redistribution is limited to the following >>> conditions: >>> >>> * One may not create a derivative work which, in any way, >>> violates the Paul Hsieh exposition license described above on >>> the original content. >>> >>> [...] >>> Paul Hsieh exposition license >>> [...] >>> >>> * The redistributor must fully attribute the content's >>> authorship and make a good faith effort to cite the original >>> location of the original content. > > This restriction is additional to the GPL. The result is > GPL-incompatible and cannot be redistributed under either license. > >>> * The content may not be modified via excerpt or otherwise >>> with the exception of additional citations such as described >>> above without prior consent of Paul Hsieh. > > This restriction is additional to the GPL. The result is > GPL-incompatible and cannot be redistributed under either license. > >>> * The content may not be subject to a change in license >>> without prior consent of Paul Hsieh. > > This quite clearly is not compatible with the GPL: both licenses > require that the work be distributed only under their terms, thus both > cannot be simultaneously satisfied. > >> Is this DFSG-free? > > Worse, I don't think the work can be legally redistributed at all. > > Any of the problems noted above in the text of the Paul Hsieh > Exposition License make the combined work unredistributable, since one > cannot satisfy both of GPL and the Paul Hsieh Exposition License > simultaneously. > Thanks very much Ben and Don. I'll contact Paul Hsieh to see if he'd be willing to re-license it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341430: JTA - ssh documentation.
I found it quite difficult to locate this information on javassh.org's web site. The command line required is of the form: java -jar jta26.jar -plugins Status,Socket,SSH,Terminal hostname 22 (or you can use an equivalent config file). I'll update the package's description and README when I next upload it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#434316: Location of (new) checkstyle dtd and xsl files.
Using locations: /usr/share/checkstyle/dtd /usr/share/checkstyle/xsl seems to fit in with what other packages do. Unless anyone can think of better locations, that's what I'll implement. Thanks, Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#288655: myserver_0.8.11-1_amd64.changes REJECTED
On Mon, September 10, 2007 13:27, Joerg Jaspert wrote: > Hi Maintainer, > > rejected, sorry, the package name is too generic. (Yes, I know its > upstreams name. :() ). > > -- > bye Joerg Hi Joerg, Thanks for your email. I'll ask upstream if they would be happy for MyServer to enter Debian with a modified name. If so I'll repackage it with a name of their choice. Can I ask a couple of questions? 1) Are we talking just about the *package* name? I.e. would it be acceptable to rename the package but still install /usr/bin/myserver and /usr/share/myserver? 2) How much less generic should the name be? E.g. would "mywebserver" be OK? 3) I'm just wondering how "close" MyServer is to getting into Debian once I've fixed the name problem. Did you have a chance to look at the rest of the package? Thanks, Paul
Bug#432888: Patch about to be uploaded.
tags + pending thanks That was a rather silly mistake - will not build properly on non-i3x6 arches. I have prepared a new package which I will ask my sponsor to review. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#432540: checkstyle: FTBFS: Illegal class or package name '/usr/lib/kaffe/pthreads/jre/lib/glibj.zip:/usr/lib/kaffe/pthreads/lib/tools.jar'
Michael Koch wrote: > On Tue, Jul 10, 2007 at 12:08:49PM +, Lucas Nussbaum wrote: >> BUILD FAILED >> /build/user/checkstyle-4.1+dfsg/build.xml:220: Javadoc returned 5 >>at org.apache.tools.ant.taskdefs.Javadoc.execute (Javadoc.java:2077) >>at org.apache.tools.ant.UnknownElement.execute (UnknownElement.java:288) >>at java.lang.reflect.Method.invoke0 (Method.java) >>at java.lang.reflect.Method.invoke (Method.java:255) >>at org.apache.tools.ant.dispatch.DispatchUtils.execute >> (DispatchUtils.java:105) >>at org.apache.tools.ant.Task.perform (Task.java:348) >>at org.apache.tools.ant.Target.execute (Target.java:357) >>at org.apache.tools.ant.Target.performTasks (Target.java:385) >>at org.apache.tools.ant.Project.executeSortedTargets (Project.java:1329) >>at org.apache.tools.ant.Project.executeTarget (Project.java:1298) >>at org.apache.tools.ant.helper.DefaultExecutor.executeTargets >> (DefaultExecutor.java:41) >>at org.apache.tools.ant.Project.executeTargets (Project.java:1181) >>at org.apache.tools.ant.Main.runBuild (Main.java:698) >>at org.apache.tools.ant.Main.startAnt (Main.java:199) >>at org.apache.tools.ant.Main.start (Main.java:161) >>at org.apache.tools.ant.Main.main (Main.java:250) > > This is a regression from ant 1.6.5 -> 1.7.0. It builds fine with old > ant packages. I'm looking into a solution. > > > Cheers, > Michael checkstyle has other build problems, though, and I think this would be a good time to revamp it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#433350: checkstyle: New upstream version available
Package: checkstyle Severity: wishlist Release 4.3 Fixed Bugs: * The StrictDuplicateCode check didn't report correct results when multiple duplicate code regions were overlapping. (bug 1564465) * Fixed NPE in FallThrough check (bug 1472228) * Fixed typo in Command Line example (bug 1464595) * RegexpHeader check now correctly report problematic line in file with regexps for header (bug 1455575) * Fixed small problem in usage checks (patch 1498920). Thanks to Chris Povirk (cpovirk) for submitting the patch. * Fixed incorrect french translation (bug 1611403). Thanks to Fabien Bergeret for providing the correct value. New features: * Major performance improvements in the StrictDuplicateCode check, especially for large projects. Also, false alarms are no longer possible. * New CrossLanguageRegexpHeader check that allows checking file headers for other languages than Java. * Applied patch 1586411 from Dennis Lundberg (dennislundberg) to add Maven POM files to the build. Release 4.2 New features: * NoWhitespaceAfter check now accepts TYPECAST token to check is there is no whitespace after typecast. (rfe 1248106). * IllegalType can be configured to accept some abstract classes which matches to regexp of illegal type names (property legalAbstractClassNames, rfe 953266). Thanks to Paul Guyot (pguyot) for submitting patch. * TrailingComment now can be configured to accept some trailing comments (such as NOI18N) (property legalComment, rfe 1385344). * Added WriteTag check which outputs a JavaDoc tag as information (patch 902110) Thanks to Daniel Grenner (dgrenner) for contribution. * Support for suppressing audit events based on an identifier that is assigned to individual modules/checks. This allows for suppressing at a finer level than the check class name. See SuppressionFilter documentation for more. * Added the style sheet checkstyle-frames.xsl, thanks to Paul King. (Bug 1385095). * Applied patch (1505376) by Clint Stotesbery to support the suppressLoadErrors property for AbstractTypeAwareCheck (RFE 1491630). * Upgraded to ANTLR 2.7.6. * GUI now displays a TextArea with the contents of the file parsed. Based on patch from sermojohn (RFE 1499180). Fixed Bugs: * First attempt to fix 192 (RightCurlyCheck misbehaves for LIT_CATCH). The check has been rewritten to check rcurly after finally and else. Current behavior is incompatible with previous one. * Fixed problem in type aware checks with loading inner-classes which were referenced as . (bug 1379666, modules JavadocMethod and RedundantThrows). * Fix UTF-8 encoding error in XMLLogger. (bug 1369589). * The new property logLoadErrors of the JavaDocMethod check now allows controlling the behaviour when checkstyle cannot load a class that is referenced in javadoc (bug 1422462). * Tighten up the allowed use of the [EMAIL PROTECTED] tag. * Stop creating duplicate regular expression patterns. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#288655: Update regarding licensing.
Just to document the resolution of the "Paul Hsieh derivative license": upstream have removed this code, and used a different (free) implementation. I believe the work is now DFSG-free. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#432540: tagging 432540, tagging 305325, tagging 433350, tagging 434316
Lucas Nussbaum wrote: > On 21/08/07 at 22:24 +0100, Paul Cager wrote: >> # Automatically generated email from bts, devscripts version 2.10.6 >> tags 432540 + pending >> tags 305325 + pending >> tags 433350 + pending >> tags 434316 + pending > > Hi, > > This has been pending for more than a month. Is your upload blocked by > something else? Hi Lucas, Thanks for the reminder. I tagged the bugs as pending to show they are fixed in svn, but the package still needs some more work before it can be uploaded. The Java policy now is to use gcj rather than kaffe, but unfortunately this means ant's native2ascii task is no longer supported. I'm working on it, but my Debian time is a bit restricted at the moment (due to a rather nasty virus - and not the computer kind!) Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#408584: RFP: javatar -- Java library for accessing to TAR files
Package: wnpp Severity: wishlist * Package name: javatar Version : 2.5 Upstream Author : Tim Endres <[EMAIL PROTECTED]> * URL : http://www.trustice.com/java/tar/index.shtml * License : Public Domain Programming Lang: Java Description : This Java library allows you to create and extract tar archives. Since the package uses InputStream and OutputStream, it is possible to combine this package with the java.util.zip package to handle .tar.gz files. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#341405: Proposed fix
This happens because the default URL for the help file is "/index.html" (in default.properties). This will obviously not work. I'll attempt to improve the situation when I package the new upstream version (2.6). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#413518: RFP 413518 Wagon package - granularity
The maven2 distribution contains about 7 wagon jars (wagon-file, wagon-http-shared etc). What would be the best way to package this: A) Seven source packages (and hence seven binary packages). B) One source package generating seven binary packages. C) One source package generating one binary package (one big jar). D) Doesn't matter / something else. I'm rather in favour of the first option. What's the general view? Thanks, Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#413518: RFP 413518 Wagon package - granularity
Michael Koch wrote: > On Wed, Mar 28, 2007 at 11:29:35PM +0100, Paul Cager wrote: >> The maven2 distribution contains about 7 wagon jars (wagon-file, >> wagon-http-shared etc). What would be the best way to package this: >> >> A) Seven source packages (and hence seven binary packages). >> B) One source package generating seven binary packages. >> C) One source package generating one binary package (one big jar). >> D) Doesn't matter / something else. >> >> I'm rather in favour of the first option. What's the general view? > > Are all source packages normally release in sync? If yes I would prefer > one big source package which includes the tarballs of all releases and > builds either seven binary packages or one binary package with 7 jars. > I think I would prefer the later one. Upstream do not release source tarballs - access is by svn. It looks to me as though all of the Jars are released in sync (although I may be a bit confused, since the ibiblio repos has version 1.0-alpha-4, and the maven download contains 1.0-beta-2, and some things have been renamed). I guess if we produce one source package then we should package _all_ of wagon, not just the bits needed by maven. It don't think this will be a problem, as it doesn't look like it will pull in any additional dependencies. Regards, Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#413518: RFP 413518 Wagon package - granularity
Marcus Better wrote: > Paul Cager wrote: >> The maven2 distribution contains about 7 wagon jars (wagon-file, >> wagon-http-shared etc). What would be the best way to package this: > > I suggest one source file and several binary packages. This is because > (a) the top-level svn directory has a project file listing the other > sub-modules, so it can be built together, Yes, that makes sense. > (b) releases are tagged in the tags/ directory as "wagon-1.0-beta-2" etc > with all the modules together (at least after alpha-7, where there are > actually separate tags). Good spot. I'd not noticed the differences between wagon and (e.g.) plexus. I wonder why maven ships with beta-2 but ibiblio still has alpha-4 as the latest. How are you meant to find the latest binaries? > > If they ever start making separate releases it is not too hard to break up > the source package. > > The binary packages should probably be separated, for instance a user could > wish to install only one of the two ssh providers, or none of them. By the way, I probably haven't made it clear that I was just asking out of idle curiosity. I'm not intending to package it myself. So leap right in if you're interested! Regards, Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#413847: Patch for AFNIX on GNU/kFreeBSD
amaury darsch wrote: > Hello Paul, > > I looked into the patch and it looks to me like a hack. I would rather prefer > to add a new platform that corresponds to kFreeBsd. This will be a one hour > work but I cannot test it. The release 1.5.0 might come by mid April. I could > add this new platform but somebody will have to test it. Eventually I could > give you an early access to the 1.5.0 release in case you might want to test > it. Let me know how to proceed. Also I noticed that the person who reported > the bug is French. Do you mind if I contact him directly to do the testing in > case you cannot do it. > > Again, adding a new platform is quite simple and I rather prefer we do it > right at the beginning. > > cordially > amaury Hello amaury and Cyril, Thanks for your reply. I believe Cyril was aiming for "minimum changes" in his patch, rather than the most elegant solution. That way we could be sure it wouldn't affect any other architectures (Cyril, please correct me if I am wrong). I'd be happy for you to talk to Cyril directly - are you happy to do that Cyril? If you'd prefer not to, just let me know and I'll upload the new version of AFNIX as normal. Cyril, do you have access to a GNU/kFreeBSD machine, or were you just monitoring the buildd log? I'm wondering how best to test it - would it just be easiest if I uploaded the new version to "experimental"? Thanks, Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#413522: Questions about plexus-container-default
Hi Trygve, A couple of days ago on #debian-java you kindly offered to help if I hit any problems with the packaging of Plexus for Maven2. Would you have time for a couple of questions about plexus-container-default? ** src/main/java/org/codehaus/plexus/component/composition/DefaultComponentComposerManager.java This file has an "import sun.reflect.ReflectionFactory.GetReflection". I've patched it out in the Debian package, but it would be nice if it could be removed upstream. ** src/main/java/org/codehaus/plexus/component/configurator/converters/ComponentValueSetter.java This file has a copyright statement but no license information: /* * Copyright (c) 2005 Your Corporation. All Rights Reserved. */ Thanks, Paul. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
