Bug#330234: Problem with proposed patch (apt-cacher)
The proposed patch does not seem to work for restart, e.g. endon:~# /etc/init.d/apt-cacher start Starting Apt-Cacher: apt-cacher. endon:~# ps -ef | grep apt www-data 4008 1 0 21:43 pts/500:00:00 /usr/bin/perl /usr/sbin/apt-cacher -R 3 -d -p /var/run/apt-cacher.pid root 4010 3287 0 21:43 pts/500:00:00 grep apt endon:~# echo `cat /var/run/apt-cacher.pid` 4008 endon:~# /etc/init.d/apt-cacher restart Restarting Apt-Cacher: apt-cacher. endon:~# ps -ef | grep apt root 4018 3287 0 21:43 pts/500:00:00 grep apt endon:~# echo `cat /var/run/apt-cacher.pid` 4008 The restart kills off the old process, but does not start a new one. Also the stop (following a successful start) does not remove the PID file - is this normal? endon:~# ps -ef | grep apt www-data 4026 1 0 21:44 pts/500:00:00 /usr/bin/perl /usr/sbin/apt-cacher -R 3 -d -p /var/run/apt-cacher.pid root 4032 3287 0 21:44 pts/500:00:00 grep apt endon:~# echo `cat /var/run/apt-cacher.pid` 4026 endon:~# /etc/init.d/apt-cacher stop Stopping Apt-Cacher: apt-cacher. endon:~# ps -ef | grep apt root 4039 3287 0 21:45 pts/500:00:00 grep apt endon:~# echo `cat /var/run/apt-cacher.pid` 4026 (all tested on apt-cacher 1.6.4) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463277: afnix FTBFS - will fix when new upstream version is ready
Martin Michlmayr wrote: * Paul Cager [EMAIL PROTECTED] [2008-03-04 14:48]: Not yet. I'm afraid surreal life has caught up with me and the time I can spend on my Debian work has reduced. Hopefully this is just temporary, but I realise I'm rather neglecting some of my packages. Any update on this, Paul? Hi Martin, As I no longer use afnix myself I decided to put it up for adoption (RFA: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=475377). This has left me more time to work on Java within Debian. I guess I'll file for removal if no-one is interested post-lenny. Martin / Cyril - Would you be interested in adopting afnix? Thanks, Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486938: maven2.jar seems to be missing classes from org.apache.maven:maven-toolchain
package: maven2 owner: [EMAIL PROTECTED] thanks Hi Alexander, Thanks for your report. I'll investigate further later this week. Cheers, Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#481571: Confirmed - need to add manifest
tags 481571 +confirmed Thanks for the report. Yes, we need to add an explicit manifest. Upstream's looks like: Main-Class: org.w3c.tidy.Tidy Name: org/w3c/tidy/Tidy.class Java-Bean: True Thanks, Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#480964: ITP: libservlet2.5-java -- Version 2.5 of the Java Servlet API (includes version 2.1 of JSP and EL APIs).
Package: wnpp Severity: wishlist Owner: Paul Cager [EMAIL PROTECTED] * Package name: libservlet2.5-java Version : 2.5 Upstream Author : Various * URL : http://tomcat.apache.org * License : Apache 2 Programming Lang: Java Description : Version 2.5 of the Java Servlet API (includes version 2.1 of JSP and EL APIs). This package provides version 2.5 of Java's Servlet API, and version 2.1 of the JSP (Java Server Pages) and EL (Expression Language) API's. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.22-3-686 (SMP w/1 CPU core) Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474908: [Fwd: [ cdk-Bugs-1938953 ] Build fails with new JavaCC beta - MakeJavafilesFiles]
It's now been fixed upstream as well. Original Message Subject: [ cdk-Bugs-1938953 ] Build fails with new JavaCC beta - MakeJavafilesFiles From:SourceForge.net [EMAIL PROTECTED] Date:Mon, April 21, 2008 21:16 To: [EMAIL PROTECTED] -- Bugs item #1938953, was opened at 2008-04-09 23:20 Message generated for change (Settings changed) made by egonw You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=120024aid=1938953group_id=20024 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: build.xml Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Paul Cager (paulcager) Assigned to: Egon Willighagen (egonw) Summary: Build fails with new JavaCC beta - MakeJavafilesFiles Initial Comment: The new version of JavaCC (not yet released, but available from JavaCC's CVS) generates code with comments of the form: /** Token Manager. */ Unfortunately MakeJavafilesFiles.java doesn't handle this type of comment - if the comment starts with /** it only looks for **/ as a comment terminator (if it is a single-line comment). I have attached a patch I use in the Debian build to fix MakeJavafilesFiles.java (although you may want to fix it in a more robust way). (If you need the newer version of JavaCC I would be happy to send you the jar). Thanks. -- Comment By: Egon Willighagen (egonw) Date: 2008-04-21 22:15 Message: Logged In: YES user_id=25678 Originator: NO Hi Paul, at some point I've looked for a good Java source parser that also parser JavaDoc, but never found a free tool for that. No idea, why it specifically looks for **/... I'll apply the patch. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=120024aid=1938953group_id=20024
Bug#475715: ITP: plexus-compiler-javac -- Interface to javac compiler for Plexus
Package: wnpp Severity: wishlist Owner: Paul Cager [EMAIL PROTECTED] * Package name: plexus-compiler-javac Version : 1.5.3 Upstream Author : Codehaus developers. * URL : http://plexus.codehaus.org/ * License : MIT / Apache 2.0 Programming Lang: Java Description : Interface to javac compiler for Plexus The Plexus project provides a full software stack for creating and executing software projects. Based on the Plexus container, the applications can utilise component-oriented programming to build modular, reusable components that can easily be assembled and reused. This package provides the javac interface for Plexus. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475726: ITP: plexus-io -- Input-output utility library for Plexus
Package: wnpp Severity: wishlist Owner: Paul Cager [EMAIL PROTECTED] * Package name: plexus-io Version : 1.5.3 Upstream Author : Codehaus developers. * URL : http://plexus.codehaus.org/ * License : Apache 2.0 Programming Lang: Java Description : Input-output utility library for Plexus The Plexus project provides a full software stack for creating and executing software projects. Based on the Plexus container, the applications can utilise component-oriented programming to build modular, reusable components that can easily be assembled and reused. This package provides an Input-output utility library for Plexus -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475780: ITP: plexus-archiver -- Plexus archiving libraries
Package: wnpp Severity: wishlist Owner: Paul Cager [EMAIL PROTECTED] * Package name: plexus-archiver Version : 1.0-alpha-9 Upstream Author : Codehaus developers * URL : plexus.codehaus.org * License : Apache 2 Programming Lang: Java Description : Plexus archiving libraries The Plexus project provides a full software stack for creating and executing software projects. Based on the Plexus container, the applications can utilise component-oriented programming to build modular, reusable components that can easily be assembled and reused. . This package provides the Archiver plugin for Plexus, used to create JARs and other archives. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475377: RFA: afnix -- Compiler and run-time for the AFNIX programming language
Package: wnpp Severity: normal I no longer use the afnix package, and would like to offer it for adoption. The package is not in terribly good shape, I'm afraid, but if you enjoy fixing things this is a good opportunity! -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.22-3-686 (SMP w/1 CPU core) Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474908: cdk: FTBFS: NomParserTokenManager cannot be resolved to a type
Michael Koch wrote: On Mon, Apr 07, 2008 at 10:33:32PM +0200, Lucas Nussbaum wrote: Package: cdk Version: 1:1.0.2-1 Severity: serious User: [EMAIL PROTECTED] Usertags: qa-ftbfs-20080407 qa-ftbfs Justification: FTBFS on i386 ... This broken with the last javacc update. Teh Nom*.java classes are generated from NomParser.jj. Paul can you please take a look at this? Thanks for finding this problem, Lucas. cdk looks to have an interesting build system - it compiles a Java program (MakeJavafilesFiles.java) which is then used to copy the source files into a build directory. But MakeJavafilesFiles spits out the error message Something wrong with the Java source file: src/org/openscience/cdk/iupac/parser/NomParserTokenManager.java. The reason is because JavaCC is generating comments such as: /** Token Manager. */ CDK's MakeJavafilesFiles program looks at program sources to detect special @cdk.set tags in them. But there is a bug in the part of MakeJavafilesFiles that is meant to recognise comments - it doesn't recognise the comment terminator */ if the comment was introduced with /** on the same line. I'll probably patch cdk so that it recognises */ in this context, but also fix JavaCC upstream (change the comment terminator to be **/). Thanks, Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474610: ITP: plexus-compiler-api -- Compiler API for the Plexus framework
Package: wnpp Severity: wishlist Owner: Paul Cager [EMAIL PROTECTED] * Package name: plexus-compiler-api Version : 1.5.3 Upstream Author : Jason van Zyl and others * URL : http://plexus.codehaus.org/ * License : MIT / Apache 2.0 Programming Lang: Java Description : Compiler API for the Plexus framework The Plexus project provides a full software stack for creating and executing software projects. Based on the Plexus container, the applications can utilise component-oriented programming to build modular, reusable components that can easily be assembled and reused. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473954: Missing build-depends
It looks as though libcommons-cli-java needs to build-depend on ant-optional. I was surprised it didn't fail with pbuilder - does pbuilder still install Recommends:? I'll prepare a fix. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463277: afnix FTBFS - will fix when new upstream version is ready
Cyril Brulebois wrote: Hi, (putting back Luk into the loop, mailing [EMAIL PROTECTED] isn't sufficient) Paul Cager [EMAIL PROTECTED] (04/02/2008): I intend to fix this bug along with the upload for the new upstream version (probably within a week). any news on that new upstream release? Cheers, Not yet. I'm afraid surreal life has caught up with me and the time I can spend on my Debian work has reduced. Hopefully this is just temporary, but I realise I'm rather neglecting some of my packages. (Luk - sorry I didn't include you in my previous email; I'd assumed you didn't want to be deluged with mail, but preferred to manage the FTBFS bugs using your usertags). regards, Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466860: Your Debian Bug Report re Maven2
Thank you for your bug report, and I agree that it should be severity=important. I'd prefer lenny to go out without Maven rather than with this bug. This problem (and http://bugs.debian.org/458895) happen because Debian's version of Maven uses version 1.1 of Apache's commons-cli library, whereas upstream's Maven uses version 1.0. Version 1.1 has introduced significantly different behaviour around the handling of repeated arguments (such as: -Dsome.option=0 -Dsomething.else=1). The fix for 458895 allowed multiple -D args, as in: mvn -e archetype:create -DgroupId=org.x.y -DartifactId=z -DarchetypeArtifactId=maven-archetype-j2ee-simple But then commons-cli assumes that everything after the first -D is another -D, which is why this fails: mvn -Dsome.option=0 install Unless I am missing something obvious, commons-cli 1.1 is rather broken and can't support the syntax Maven requires. I'll look more deeply into commons-cli's code this week to see what we should do. Thanks, Paul
Bug#466860: Your Debian Bug Report re Maven2
Michael Koch wrote: If we can't work around this we will need to upload a commons-cli-1.0 package just for maven2. Would not be nice but a workaround. Hi Michael, It's good to have that option as a backup. Currently commons-cli 1.1 silently discards all but the first instance of any option (it throws an exception internally, which is then caught but discarded). I can't imagine anything deliberately depending on this behaviour, so I feel it should be safe to patch it. Once I'm more certain I'll clone the bug (as I'll have to revert the original Maven2 patch). It looks as though upstream accept that this behaviour is buggy (https://issues.apache.org/jira/browse/CLI-137). It's as much a question of what the code *should* be doing. Thanks, Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463277: afnix FTBFS - will fix when new upstream version is ready
Hi Luk, I intend to fix this bug along with the upload for the new upstream version (probably within a week). But if anyone wants to NMU it before that time, that's fine with me as well. Thanks, Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462591: FTBFS with GCC 4.3: missing #includes
Martin Michlmayr wrote: Package: msp-webserver Version: 0.8.11-1 Severity: important Usertags: ftbfs-gcc-4.3 Your package fails to build with GCC 4.3. Version 4.3 has not been released yet but I'm building with a snapshot in order to find errors and give people an advance warning. In GCC 4.3, the C++ header dependencies have been cleaned up. The advantage of this is that programs will compile faster. The downside is that you actually need to directly #include everything you use (but you really should do this anyway, otherwise your program won't work with any compiler other than GCC). There's some more information about this at http://gcc.gnu.org/gcc-4.3/porting_to.html You can reproduce this problem with gcc-4.3 or gcc-snapshot from unstable. Thanks for the report. There are 3 errors all in all: listen_threads needs to include bits/stl_algo.h hash_map needs to include string.h mem_buff needs to include string.h I'll send this to upstream, rather than patch it, as they release quite frequently. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458895: maven2: commons-cli.jar is the culprit
Paul Cager wrote: Mike Paul wrote: Package: maven2 Version: 2.0.8-3 Followup-For: Bug #458895 [...] It turns out that /usr/share/maven2/lib/commons-cli.jar is the one that makes the difference: if I copy that jar into a freshly-unpacked copy of Apache's Maven distribution, the problem occurs there too. [...] It would seem that this behaviour relies on Maven using an old version of commons-cli. I'll investigate further. [...] I've not had time to fix this problem yet, so I thought I'd just let you know what's happening. The problem happens because of a change introduced in commons-cli 1.1, which is described in http://issues.apache.org/jira/browse/CLI-137 Although the change has destroyed backwards compatibility (and I don't like that), the new behaviour agrees with cli's API specification. So I think we should call this a bug in Maven which just happens to be harmless with cli version 1.0. I'll prepare a new revision of the maven2 Debian package with Maven's calls to commons.cli patched, and send the bug upstream to the Maven developers (although they still use cli version 1.0). It'll probably take a few days as I want to give it a good test. Thanks, Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458895: maven2: commons-cli.jar is the culprit
Mike Paul wrote: Package: maven2 Version: 2.0.8-3 Followup-For: Bug #458895 [...] It turns out that /usr/share/maven2/lib/commons-cli.jar is the one that makes the difference: if I copy that jar into a freshly-unpacked copy of Apache's Maven distribution, the problem occurs there too. Thanks for investigating this so thoroughly, and sorry I have not had more time to look at it myself. It's a bit odd. At first I thought it must be a bug in the Debian packaging of commons-cli, but I downloaded the official Apache jar from http://mirrors.dedipower.com/ftp.apache.org/commons/cli/binaries/commons-cli-1.1.tar.gz and that exhibits the same failure. If you download the jar from Maven's repo (http://repo1.maven.org/maven2/commons-cli/commons-cli/1.0/commons-cli-1.0.jar) then it all works. It would seem that this behaviour relies on Maven using an old version of commons-cli. I'll investigate further. [...] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#458895: maven2: Creating empty project with artifacts fails
Valliet Emmanuel wrote: Package: maven2 Version: 2.0.8-3 Severity: normal Hi, I installed the maven2 debian package, and tried to make an empty j2ee package using the artifacts, and it failed: [EMAIL PROTECTED]:~/devel/java/sources$ mvn -e archetype:create -DgroupId=org.homelinux.beap -DartifactId=manu -DarchetypeArtifactId=maven-archetype-j2ee-simple + Error stacktraces are turned on. [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'archetype'. [INFO] org.apache.maven.plugins: checking for updates from central [INFO] org.codehaus.mojo: checking for updates from central [INFO] artifact org.apache.maven.plugins:maven-archetype-plugin: checking for updates from central Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-archetype-plugin/1.0-alpha-7/maven-archetype-plugin-1.0-alpha-7.pom 4K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/archetype/maven-archetype/1.0-alpha-7/maven-archetype-1.0-alpha-7.pom 3K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/archetype/maven-archetype-parent/2/maven-archetype-parent-2.pom 2K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-parent/5/maven-parent-5.pom 14K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/apache/3/apache-3.pom 3K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-archetype-plugin/1.0-alpha-7/maven-archetype-plugin-1.0-alpha-7.jar 12K downloaded [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Invalid task 'artifactId=manu': you must specify a valid lifecycle phase, or a goal in the format plugin:goal or pluginGroupId:pluginArtifactId:pluginVersion:goal [INFO] [INFO] Trace [...] Cheers, Valliet Emmanuel Hi, Thanks for your report and your initial investigations. I can reproduce this error in a clean chroot, but not on my standard desktop (which is confusing!). I'll have a more detailed look at it soon. Thanks, Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#453794: Adicional comments
Anibal Avelar wrote: The patch that I previously sent seems wrong. I confused the order. Basically is to change the line inside debian/rules: -dh_shlibdeps debian/tmp/usr/bin/* + LD_LIBRARY_PATH=debian/afnix/usr/lib/afnix:$$LD_LIBRARY_PATH dh_shlibdeps debian/tmp/usr/bin/* Hi Anibal, Thanks very much for that - very helpful. There's another problem with afnix that needs investigation, and then I'll be able to prepare an upload. Thanks, Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454077: maven2: maven-eclipse-plugin does not exist
On Mon, December 3, 2007 01:48, Amelia A Lewis wrote: [. . .] Note that the first attempt to invoke eclipse:eclipse used this command line (as advised in hudson build notes): mvn -o -DdownloadSources=true eclipse:eclipse Yes, they advise offline mode. It appears that this may create the directory with inadequate stuff, because once I delete the directory and run the command without -o, it succeeds. Problem solved. Good. Im glad youve solved it. Thank you for your time, and please excuse my verbosity. I recommend: 1) close this bug with no action; it resulted from wrongheaded directions supplied by a mavenized project over which Debian has no influence; 2) note the behavior, in case future bug reports show similar symptoms: if a user reports an error of this sort, suggest that they try deleting the problem directory in their repository, and that they verify that they're not running in offline mode (even if the project suggests doing so; hudson suggests mvn install and then mvn -o -DdownloadSources=true eclipse:eclipse, but since the maven-eclipse-plugin isn't installed by mvn install, the offline invocation appears to be the thing that stuffs up the repository completely). Or, to shorten the suggestion: ask anyone reporting similar behavior to check the content of the directory corresponding to the 'not found' dependency; if it contains only *.xml without *.pom/*.jar (or a version subdirectory), delete the directory from the repo and reinvoke with all possible offline flags turned off. Thanks Ill do that.
Bug#454087: maven2: New upstream version (2.0.8) released.
Package: maven2 Version: 2.0.7-2 Severity: wishlist 2.0.8 was released on 27-Nov-07 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454077: maven2: maven-eclipse-plugin does not exist
Amelia A Lewis wrote: Package: maven2 Version: 2.0.7-2 Severity: normal Command and results: (ydhegar)amyzing:/pub/projects/hudson/hudson$ mvn -e -DdownloadSources=true eclipse:eclipse + Error stacktraces are turned on. [ SNIPPED: project information (it's for hudson, if you care) ] [INFO] Searching repository for plugin with prefix: 'eclipse'. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] The plugin 'org.apache.maven.plugins:maven-eclipse-plugin' does not exist or no valid version could be found [INFO] [...snip...] This makes it hard to use the apt-delivered Maven + Eclipse for development of projects. Maven 2's project page doesn't appear to include instructions for manual installation of plugins when the automatic retrieval mechanism fails. I suppose that that's the next thing to try to do. Hi Amelia, Thanks for your report. I'm not sure that I understand the problem correctly. Debian has packaged Maven, but not any of its plugins - so the plugins should be downloaded normally (i.e. in the same way as a non-Debian Maven installation). Is this not the case? When I run eclipse:eclipse on my machine it seems to find the plugin correctly: [INFO] Searching repository for plugin with prefix: 'eclipse'. [INFO] artifact org.apache.maven.plugins:maven-eclipse-plugin: checking for updates from central Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-eclipse-plugin/2.4/maven-eclipse-plugin-2.4.pom 5K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-eclipse-plugin/2.4/maven-eclipse-plugin-2.4.jar 125K downloaded ... [INFO] Wrote Eclipse project for maven-plugin-descriptor to /home/paul/maven/maven-2.0.x/maven-plugin-descriptor. Thanks, Paul https://hudson.dev.java.net/files/documents/2402/77580/hudson-1.160-src.zip -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454077: maven2: maven-eclipse-plugin does not exist
Amelia A Lewis wrote: I'm not sure that I understand the problem correctly. Debian has packaged Maven, but not any of its plugins - so the plugins should be downloaded normally (i.e. in the same way as a non-Debian Maven installation). Is this not the case? Doesn't seem to work, for me. Amy, if you have loads of spare time would you mind trying with the non-Debian version of Maven (e.g. as downloaded from http://www.mirrorservice.org/sites/ftp.apache.org/maven/binaries/apache-maven-2.0.8-bin.tar.bz2 )? Only if you have spare time, of course. It might help eliminate / incriminate the Debian packaging. H. Think it's a machine-specific issue? Mine never shows the line: [INFO] artifact org.apache.maven.plugins:maven-eclipse-plugin: checking or updates from central (from your example) Is the location of central encoded into the binary or the config files somewhere? Maybe I could check that? I believe it is defined in the super-pom held in /usr/share/java/maven2.jar (org/apache/maven/project/pom-4.0.0.xml). I can't think of any way that could change accidentally. In file /etc/maven2/settings.xml is the value of offline set to false (the default value)? Are you behind a HTTP proxy or firewall? (My apologies if I am stating the obvious). Hmmm. Or a permissions problem? Where would plugins be stored when retrieved? The downloaded plugins would be stored in $HOME/.m2 (which Maven creates automatically). Debian doesn't try to centrally cache the downloaded artefacts, or anything clever like that. The output above indicates the location of the project that you were building (or so I assume), but I can't determine where in the Debian installation plugins go. Looks like needs more work from me. Ah, well. Amy! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454095: libplexus-utils: New version required for Maven2 version 2.0.8
Package: libplexus-utils Severity: wishlist The new upstream release of Maven2 requires a more up-to-date version of libplexus-utils. Current Debian Version: 1:1.4.1-1 Current Upstream: plexus-utils-1.4.8 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#449188: Confirmed: missing from wagon-ssh-common.jar
tags 449188 +confirmed thanks Thanks for the report. org/apache/maven/wagon/providers/ssh/knownhost/ is present in upstream's wagon-ssh-common-1.0-beta-2.jar but not in Debian's. I'll fix it and check for other missing packages. Thanks, Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445006: maven2: Selects first JRE found, ignoring alternatives (pending upload).
tags 445006 +pending thanks The fix I previously suggested for this bug would not work with java-gcj, due to the different ways the Java packages are set up in the alternatives system. E.g. /usr/bin/java - /etc/alternatives/java - /usr/lib/jvm/java-1.5.0-sun/jre/bin/java /usr/bin/java - /etc/alternatives/java - /usr/lib/jvm/java-gcj/bin/java - /usr/bin/gij-4.2 I've modified the solution slightly to follow each individual symlink (starting from the file returned by `which java`) until we find a directory somewhere within the /usr/lib/jvm tree. At this point we can correctly set up JAVA_HOME. If no JAVA_HOME has been found then I assume it is a user-installed JRE and set JAVA_HOME appropriately. I've tested it using java-6-sun, java-gcj, and a JDK installed under $HOME. If you've any comments or corrections I would be pleased to hear them. The full version of the patch can be found in http://svn.debian.org/wsvn/pkg-java/trunk/maven2/debian/patches/mvn-cmd.patch?op=filerev=0sc=0 Thanks, Paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445006: maven2: Selects first JRE found, ignoring alternatives
Michael Koch wrote: On Tue, Oct 02, 2007 at 06:37:55PM +0200, Krzysztof Sobolewski wrote: Package: maven2 Version: 2.0.7-1 Severity: normal I have two Java packages installed: sun-java5-jre and sun-java6-jre. The latter is selected as /usr/bin/java by update-java-alternatives. Now when Maven starts, it tries to select $JAVA_HOME by looking into places where it might find Java (/usr/lib/jvm), apparently giving priority to Sun packages. Unfortunately, in my case, it selects java-1.5.0-sun, because it comes up first. This is mostly fine, but creates problems when, for example, I'm compiling a program that uses newer APIs. The start script should probably first try to determine where /usr/bin/java (or even `which java`) comes from. The problem is that in the past not all JVM implementations worked for all usecases. That is why we implemented a way to guess a working JVM. This is wrong when new runtimes come up or change directories where they are installed. Using /usr/bin/java would probably work for Maven but /usr is no suitable setting for JAVA_HOME. I dont really know what a good solution might be here. Probably its using /usr as JAVA_HOME and /usr/bin/java as Java virtual machine and let the local admin decide which runtime to use. What are the opinion of others about this? Cheers, Michael At the very least mvn should select later Sun runtimes in preference to older ones. For the benefit of other users looking at this bug log, I'd better point out that you can explicitly set JAVA_HOME and mvn will not override the setting. E.g. export JAVA_HOME=$HOME/jdk1.6 mvn install I've done some experimenting with maven, leaving JAVA_HOME blank but setting JAVACMD=/usr/bin/java. You can certainly compile assemble maven with that configuration, but I suppose there might be some plugin that depends on JAVA_HOME. What about if we follow this algorithm to determine JAVA_HOME (assuming it is not already set)? (1) Keep following the symbolic link /usr/bin/java until you get to a plain file. (2) Traverse up the directory tree until you are in a directory where there is a lib/tools.jar file. (3) If step (2) fails, then try traversing up the tree until you find a directory with a bin subdirectory. E.g. if /usr/bin/java - /etc/alternatives/java and /etc/alternatives/java - /usr/lib/jvm/java-6-sun/jre/bin/java set JAVA_HOME=/usr/lib/jvm/java-6-sun -- 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#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#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#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#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 outer_class_name.inner_class_name (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#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#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#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=revrevision=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#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#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#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#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#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#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#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#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#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#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#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#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#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#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]
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#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#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#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#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#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#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#397045: ant - java-gcj-compat-dev as dependency
Michael Koch wrote: On Sun, Mar 04, 2007 at 01:35:12AM +, 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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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: OWNER = Sun Microsystems, Inc. ORGANIZATION = Sun Microsystems, Inc. YEAR = 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#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=usersmsgNo=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#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=152856r2=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]
