Re: Links in /usr/share/java
Hi, olivier.sal...@codeless.fr said: On 06/09/2013 01:14 AM, Emmanuel Bourg wrote: Most packages install these files in /usr/share/java foo-1.2.jar foo.jar - foo-1.2.jar But some packages have the reverse relation: foo.jar foo-1.2.jar - foo.jar with this solution, you can't install multiple versions of a library. First solution is the correct one. (same behavior than with .so libraries by the way) May I add that I agree with this and already had to patch multiple libraries, just to get the library created with version, and be able to soft-link it unversioned. Cheers, Eric -- You don't need to CC me on debian-java, debian-mentors and pkg-java-maintainers. Please CC me on other Debian lists. -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/19102.15.195.185.76.1370950513.squir...@my.bawue.net
Re: Pack200 compression of packaged jars
Hi, Balancing jar size vs. simplicity of the solution, I'd definitely vote for simplicity: priceless, for everything else there is cheap disk space and bandwidth! Cheers, Eric -- Eric de France, d'Allemagne et de Navarre -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2561.15.195.185.83.1367582787.squir...@my.bawue.net
Re: Too old JRE/JDK in repos
Hi, Roman V.Leon. said: Hello gentlemen. Could you advise please, why the JRE/JDK versions are too old in Debian? There were a few security issues recently but current version in testing is still 7u3, while the oracle version is already 7u17. I can't see other ways of installing java in Debian except for downloading from oracle.com or I miss something? Thanks. One reason is surely manpower, so you are more than welcome to help. Another reason is that Oracle can release new versions without having to take care of dependencies, because each customer can decide if they'd like to install the new version or not. If we release a new version in Debian, all packages depending on it have to work as well (one of the reasons why OpenJDK6 is still the default), that makes it more complex. Furthermore we have currently a freeze in Debian + (as far as I know) advisories and security patches should be/are backported to the version currently packaged, and I think that's what's important because it's not like there would be new features introduced. Cheers, Eric -- Eric de France, d'Allemagne et de Navarre -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/49907.78.43.250.198.1362729463.squir...@my.bawue.net
Re: Bug#698164: mandate unique package names in Debian Java policy
Hi, Daniel Pocock said: B. I doubt that such a badly named package would be of enough interest / quality for Debian packaging (but I might be wrong, I don't know any example) There are examples like this. It has been argued by some developers that to compile using some toolchains (e.g. Blackberry builds done on Windows), they have to shorten the package names, otherwise they end up with filenames that are too long And who are we, packagers, to decide that this argument is wrong? And again, perfect example: if we change the package name on Debian, programs built on Debian wouldn't work on Windows and vice versa, and possibly neither on Blackberry which would make the principle of a toolchain quite absurd, wouldn't it. Wonderful result for a language supposedly portable... Having this in Debian policy would help underline best practice and show people evidence why they shouldn't deviate from it. I quickly checked other Debian language policies (Perl, Python) and couldn't anything even similar to this proposal, which confirms me in my opinion that policies are (rightly IMHO) about packaging not about programming best practices. Conclusion: I vote against + close the bug. Can you leave the bug open so other people can comment for now? It is not RC after all Sure, I meant to say that I vote to close the bug. Unless someone disagrees, I would suggest to leave it open until next week (gives one more week-end for people to react) and then close it (if votes continue to go in the same direction, of course). Cheers, Eric -- You don't need to CC me on debian-java, debian-mentors and pkg-java-maintainers. Please CC me on other Debian lists. -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/26490.15.195.185.83.1358323544.squir...@my.bawue.net
Re: Questions about simplyhtml[-freeplane] package
Hi, Felix Natter said: shall I continue to put you in CC:? Please don't put me into CC: as I am subscribed to debian-java :-) You indeed don't need to CC me. = thanks, now I have this in the parent directory of my checkout: simplyhtml/ simplyhtml_0.16.05-1.debian.tar.gz simplyhtml_0.16.05-1.dsc simplyhtml_0.16.05.orig.tar.gz Can it be that you mixed up svn-buildpackage and dpkg-buildpackage: svn-buildpackage works with only simplyhtml/debian checked-out from SVN, but then you need to have the source file in tarballs/ directory. Or you merge manually the debian directory and the sources and you can then use dpkg-buildpackage. BTW: my post concerning the relationship of freemind 1.0.0 and simplyhtml 0.16.05 is unanswered: http://sourceforge.net/projects/freemind/forums/forum/22101/topic/6359977 Perhaps you should directly contact Christian (upstream), but you can start with (d) aka ignore, ugly but not more, and once you're finished with simplyhtml + freeplane, go with (a) or (c), with an updated version of simplyhtml resp. freeplane package. Probably simpler than fix all at once. Hope this helps, Eric -- You don't need to CC me on debian-java, debian-mentors and pkg-java-maintainers. Please CC me on other Debian lists. -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/19314.15.195.185.83.1355815441.squir...@my.bawue.net
Re: Quitting Debian Java packaging - HOWTO best
Done deal! :-) Thanks, Eric Andrew Ross said: On 22/10/11 11:19, Eric Lavarde wrote: * libjcalendar-java - used to be a dependency of FreeMind, not anymore, dependency of no package, and popcon 52 - candidate for removal! Eric, Please don't request removal of this one - I'm planning to upload a package which depends on this when I get a chance. I'd be happy to take it over from you - would you like me to prepare an upload and remove you from Uploaders? Thanks, Andy -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ea42a21.5040...@rossfamily.co.uk -- You don't need to CC me on debian-java, debian-mentors and pkg-java-maintainers. Please CC me on other Debian lists. -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/26205.15.203.233.76.1319528763.squir...@my.bawue.net
[Fwd: Bug#571376: freemind: FTBFS: freemind plugins do not exist]
Hello, I got the below message, and I suspect that it's due to the recent upgrade of ant to 1.8.0. Has someone already encountered this kind of error, and give me a hint if I'm right in my suspicion and how to fix it? I'm also assuming that I won't be the only one hit by this error... Thanks, Eric Original Message Subject: Bug#571376: freemind: FTBFS: freemind plugins do not exist From: Lucas Nussbaum lu...@lucas-nussbaum.net Date:Thu, February 25, 2010 11:16 To: sub...@bugs.debian.org -- Source: freemind Version: 0.9.0~rc6+dfsg-2 Severity: serious User: debian...@lists.debian.org Usertags: qa-ftbfs-2010-02-24 qa-ftbfs Justification: FTBFS on amd64 Hi, During a rebuild of all packages in sid, your package failed to build on amd64. [...] [javac] /build/user-freemind_0.9.0~rc6+dfsg-2-amd64-xr90zE/freemind-0.9.0~rc6+dfsg/freemind/build.xml:153: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds [javac] Compiling 1 source file to /build/user-freemind_0.9.0~rc6+dfsg-2-amd64-xr90zE/freemind-0.9.0~rc6+dfsg/bin/classes [... more similar ant errors ...] build: [echo] Plugin plugins/svg build on path . [javac] /build/user-freemind_0.9.0~rc6+dfsg-2-amd64-xr90zE/freemind-0.9.0~rc6+dfsg/freemind/plugins/build_import.xml:8: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds [...] The full build log is available from: http://people.debian.org/~lucas/logs/2010-02-24/freemind_0.9.0~rc6+dfsg-2_lsid64.buildlog -- You don't need to CC me on debian-java, debian-mentors and pkg-java-maintainers. Please CC me on other Debian lists. -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/24514.15.203.233.75.1267188547.squir...@my.bawue.net
Re: Latest sun java5 packages
Diederik, are you planning to put the packages in a publicly available repository? I'd be interested. Eric Dalibor Topic said: Diederik de Haas wrote: Hello, Some time ago it was decided that the sun java 5 packages should be removed from the archives (EOL) and now they have. But I have a requirement (work) for the various sun-java5-* packages and I know that 1.5.0_20 was uploaded to the archives some time ago, since it's installed on my system, but they are now removed from the archives (and apparently I did aptitude autoclean a bit too much, so they're also gone from apt's cache). I know that the _17 packages are still in the repositories for Lenny, but if it is possible I'd like to have the _20 packages. Can someone help me get those _20 packages and preferably for both i386 and amd64? Then I can put them in my own archive (or sth like that) and still use them. The raw data for them is at http://jdk-distros.dev.java.net. cheers, dalibor topic -- Eric de France, d'Allemagne et de Navarre -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Java Help on Debian
Hi, you probably need to set the CLASSPATH environment variable to the listed JAR files, wherever you put them, I would recommend NOT in Java's own directories (I tend to put local JARs to /usr/local/share/java, then CLASSPATH=/usr/local/share/java/odinms.jar:/usr/local/share/java/xttools.jar:etc...). Java is already installed, so you should be set from this point of view (if you need Java6, make sure you have installed the package sun-java6-jre or openjdk-6-jre). You can improve the setup by installing the packages for the libraries already packaged for Debian (e.g. slf4j), instead of using locally downloaded libraries. Then you get automatically patch updates and the same. Eric Michael Su said: odinms.jar (this is just the server jar file) xttools.jar mina-core.jar jpcap.jar mysql-connector-java-bin.jar slf4j-api slf4j-jdk14 -- Eric de France, d'Allemagne et de Navarre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
re: libgdata-java: java bytecode / java runtime version mismatch
Hi, peter green said: It is preferred to build the bytecode so that it runs on older jvms. This is done passing '-source 1.[45]' to javac (or for cdbs ant tasks setting ANT_OPTS to -Dant.build.javac.source=1.[45]. are you sure, the javac manpage only states that option affects the version the source is assumed to be for and when I tried adding that option to the build for libgdata-java it didn't seem to make any difference to the class file version generated That's what I wrote, you need to set 'source' _and_ 'target' in order to be clean. Eric -- You don't need to CC me on debian-java, debian-mentors and pkg-java-maintainers. Please CC me on other Debian lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: java bytecode / java runtime version mismatch
Hi,
I thought, you need to set ant.build.javac.source _and_
ant.build.javac.target to be on the safe side (resp. -target and -source)?
Wouldn't it make sense to police this? i.e. to state that all packages
should be explicitly compiled with 1.5 source/target unless they use 6's
features?
Eric
Matthias Klose said:
I filed bug reports for packages building with openjdk-6 or cacao-oj6,
producing java bytecode for version 50, and which still depend on
java-runtime5, or earlier (attached at the end).
For lenny+1, when using openjdk/cacao as the default, there will be a
lot more of these mismatches (I fixed about 30 packages in the
pkg-java repo), so maybe a lintian check for this kind of mismatch
would be nice.
Matthias
Bug mail:
User: debian-java@lists.debian.org
Usertags: jbc-mismatch
This package builds with openjdk-6 or cacao-oj6, which is not the
default jvm in testing/unstable. The openjdk-6 and cacao-oj6 javac
creates java bytecode for version 50, which cannot be used by older
jvms. Binary packages explicitely built with openjdk-6 or cacao-oj6
must not depend on java-runtime{,1,2,5}{,-headless}, but only on
java-runtime6{,-headless} or any of the non-virtual packages providing
a java6 runtime.
It is preferred to build the bytecode so that it runs on older jvms.
This is done passing '-source 1.[45]' to javac (or for cdbs ant tasks
setting ANT_OPTS to -Dant.build.javac.source=1.[45].
You usually can check for the java byte code with file(1), currently
broken in testing/unstable, or use javap -verbose (a script checking
the command line args (check-class-version) can be found at
http://people.debian.org/~doko/tmp/. Both .class and .jar files found
in the binary packages need to be checked.
Note: this report may be a false positive, if all bytecode files have
version 49 or less.
--
Eric de France, d'Allemagne et de Navarre
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian featuring http://java.sun.com/products/jimi/ ?
Hi Steffen, I'd like to say Free Jimi!. Seriously, this library is under Sun Microsystems, Inc. Binary Code License Agreement, hence not free, not even free enough for non-free because the license forbids redistribution. The program you're interested to package, if it's distributed with the library, is probably not in agreement with this license, you should warn upstream. Sorry, Eric Steffen Moeller said: Hello, I know I should make this a RFP, but I am a bit lost about what the perfect package name would possibly be. A program that I am interested to package comes with the jimi.jar. Is there a way to have this Java Image I/O Debianised? Many thanks and regards Steffen -- Eric de France, d'Allemagne et de Navarre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Sun's graphic art for Java
Hi, the icons set distributed by Sun under [1] doesn't respond to the DFSG criteria (point ii of the -attached- license doesn't allow for modifications, as pointed out by my sponsor, in cc), hence a few questions and remarks: 1. From the lookfeel of different java apps, the icon set is relatively widely used, everybody should be aware of this limitation. 2. I know that people from Sun are lurking around, they might be interested in fixing this (that would be the easiest). 3. Perhaps someone has already faced the same issue, and knows of an alternative *free* drop-in replacement that I/upstream could use. Thanks, Eric [1] http://java.sun.com/developer/techDocs/hi/repository/ -- Eric de France, d'Allemagne et de NavarreCopyright 2000 by Sun Microsystems, Inc. All Rights Reserved. Sun grants you (Licensee) a non-exclusive, royalty free, license to use, and redistribute this software graphics artwork, as individual graphics or as a collection, as part of software code or programs that you develop, provided that i) this copyright notice and license accompany the software graphics artwork; and ii) you do not utilize the software graphics artwork in a manner which is disparaging to Sun. Unless enforcement is prohibited by applicable law, you may not modify the graphics, and must use them true to color and unmodified in every way. This software graphics artwork is provided AS IS, without a warranty of any kind. ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND ITS LICENSORS SHALL NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY LICENSEE AS A RESULT OF USING, MODIFYING OR DISTRIBUTING THE SOFTWARE GRAPHICS ARTWORK. IN NO EVENT WILL SUN OR ITS LICENSORS BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT, INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, ARISING OUT OF THE USE OF OR INABILITY TO USE SOFTWARE GRAPHICS ARTWORK, EVEN IF SUN HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. If any of the above provisions are held to be in violation of applicable law, void, or unenforceable in any jurisdiction, then such provisions are waived to the extent necessary for this Disclaimer to be otherwise enforceable in such jurisdiction.
Re: Packaging Java Tomcat web app howto ?
Hi Olivier, I move this thread to debian-java, where it belongs :-) - debian-mentors in Bcc I think that the short answer is that there is no such howto, but I might be wrong: - there was a thread about the topic http://lists.debian.org/debian-java/2007/12/msg00039.html (and you can search further) - you can search also on http://wiki.debian.org/ (but I didn't find anything). - and you have more knowledgeable people than me on this list, which will be happy to help you :-) Cheers, Eric Olivier Berger said: Hi. Is there any howto document explaining how to package a java tomcat web app for Debian ? I'm considering the possibility to try and package CAS server (Central Authentication Service and thus address the corresponding RFP I've just filed : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=493969). I doubt it's very simple, but who knows... ain't Java about easy deployment ? ;-) Any help welcome. Best regards, -- Olivier BERGER [EMAIL PROTECTED] http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC Ingénieur Recherche - Dept INF Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Eric de France, d'Allemagne et de Navarre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packaging Java Tomcat web app howto ?
As an after-thought: you might want to check an existing web app package and adapt it to your needs. From the description, tomcat5.5-webapps might be a good fit. Hope this helps, Eric Eric Lavarde - Debian said: Hi Olivier, I move this thread to debian-java, where it belongs :-) - debian-mentors in Bcc I think that the short answer is that there is no such howto, but I might be wrong: - there was a thread about the topic http://lists.debian.org/debian-java/2007/12/msg00039.html (and you can search further) - you can search also on http://wiki.debian.org/ (but I didn't find anything). - and you have more knowledgeable people than me on this list, which will be happy to help you :-) Cheers, Eric Olivier Berger said: Hi. Is there any howto document explaining how to package a java tomcat web app for Debian ? I'm considering the possibility to try and package CAS server (Central Authentication Service and thus address the corresponding RFP I've just filed : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=493969). I doubt it's very simple, but who knows... ain't Java about easy deployment ? ;-) Any help welcome. Best regards, -- Olivier BERGER [EMAIL PROTECTED] http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 1024D/6B829EEC Ingénieur Recherche - Dept INF Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Eric de France, d'Allemagne et de Navarre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Eric de France, d'Allemagne et de Navarre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Apache Commons packaging question
Hi Manuel, Manuel Prinz said: Hi all, I thought about packaging the Apache Commons Math Library[1] which I use regularly. I do have a some question though and would like to ask you for your opinion on that: 1. Other commons source packages seem to be renamed to libcommon-*-java. Do all commons packages do this? Is there a kind of agreement on this? Yes. the lib*-java part is given by the Java Policy [2], the rest is more of a common understanding. 2. The commons-math tarball ships three jars containing the class files, source files and documentation, respectively. Is it OK to just put them in the Debian package (as they are) or should I extract the source and rebuild a Debian source package from that? (The tarball is 4.5 MB large, extracted sources are 2.3 MB, tarred+gzipped 270 KB.) Everything which is generated needs to be generated from source as part of the package build. As if you need to repackage the sources, it's yes if some is not distributable, and it's at your judgement if you spare a lot of space. In your case, I would repackage the source. See [3] for more details. 3. Is the above case known from other commons libraries? I'd be thankful for a pointer to a package that I could have a look at. Can't answer. Once the upstream sources are repackaged, you can use any package as a basis for your work. Or is there no need for this library at all? If you're willing to package and maintain it, there is a need :-) (but *I* don't need it). You can check [4]. Eric Best regards Manuel [1] http://commons.apache.org/math/ [2] http://www.debian.org/doc/packaging-manuals/java-policy/x105.html [3] http://www.debian.org/doc/developers-reference/ch-best-pkging-practices.en.html#s-bpp-origtargz [4] http://www.debian.org/devel/wnpp/ -- Eric de France, d'Allemagne et de Navarre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sponsor for jaranalyzer package needed
Hi Florian, Florian Grandel said: Can it be used to track changes in the method signatures or does it just analyze inter-jar depenedencies? No, method signatures are not checked. The tool just analyzes inter-jar dependencies similar to java-propose-classpath within Matthew's javahelper package. I find this very useful for packaging more complicated java applications. The tool generates a very nice clickable HTML-Report with all dependencies and further dependency statistics. See the XML-part of README.Debian for an example on how to get the HTML. One more thought: did you check that the logic is the same between Matthew's javahelper and your tool? Is code sharing an option? The worse that could happen to packagers would be different results from those two tools; I can already imagine the mess... ;-) Thanks, Eric -- Eric de France, d'Allemagne et de Navarre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: About java virtual dependencies and provides and the Java
Hi, my email was the last one in the chain, but I don't consider it was a conclusive one. Thanks, Eric Eric Lavarde - Debian said: Hi, Michael Koch said: On Wed, May 21, 2008 at 11:17:13PM +0100, Matthew Johnson wrote: On Wed May 21 22:06, Michael Koch wrote: Debian supports only Java 5+ compatible runtimes in unstable. Almost compatible http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35020 (amongst others) Thats a small bug that doesn't change the whole picture. But is really the whole picture that many java programs don't need to rely on Sun's (or other certified) JRE to work properly? I try at regular intervals and FreeMind and SimplyHTML still don't work properly with GCI; we read recently that there were issues with Azureus. So, I still think that we need to make the difference between free and complete implementations, and the original issue, which wasn't answered, is that the Java policy needs to be updated, and packages be adapted, best before complete freeze. Eric -- Eric de France, d'Allemagne et de Navarre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: About java virtual dependencies and provides and the Java
Hi, Michael Koch said: On Wed, May 21, 2008 at 11:17:13PM +0100, Matthew Johnson wrote: On Wed May 21 22:06, Michael Koch wrote: Debian supports only Java 5+ compatible runtimes in unstable. Almost compatible http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35020 (amongst others) Thats a small bug that doesn't change the whole picture. But is really the whole picture that many java programs don't need to rely on Sun's (or other certified) JRE to work properly? I try at regular intervals and FreeMind and SimplyHTML still don't work properly with GCI; we read recently that there were issues with Azureus. So, I still think that we need to make the difference between free and complete implementations, and the original issue, which wasn't answered, is that the Java policy needs to be updated, and packages be adapted, best before complete freeze. Eric Cheer, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Eric de France, d'Allemagne et de Navarre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Where do you install local (not packaged) java libraries (.jar files)?
Hi Javier, a slightly off-topic question you have here... Javier Barroso said: Hi, We have jar files that not appears in any debian package. I'm thinking where coul I put it. Is /usr/local/share/java the location that I am searching ? The Java Policy doesn't say anything about this, but it's also the place I chose as I faced the same question. Where can I configure the classpath to make java search there ? It's application dependent, can't be answered in a generic manner. In a nutshell, you need either to define the CLASSPATH environment variable or to make sure java is called with the right -cp statement. I read java debian policy, java debian faq, and I search on this list, but I couldn't find anything about this (I'm not java expert, as you can read here) It's not topic of those documents, which are about packaged java applications. Eric PS: no need to cc me, I'm on the list! Thank you! Debian Rocks -- Javier Barroso Tristán -- Eric de France, d'Allemagne et de Navarre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Help needed on the Java policy
Hi everybody, OK, second try at getting a common understanding: - the Java Policy should state that a Java package should depend on java2-runtime only if the packager expects its program to work with a classpath-alike implementation of Java. (what about IcedTea then?) - in the words of Michael: Michael Koch said: The X packages should only be in Recommends and its possible to not install Recommends (but you are expected you are knowing what you are doing). Can we get an agreement on those points? Eric -- You don't need to CC me on debian-java, debian-mentors and pkg-java-maintainers. Please CC me on other Debian lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Help needed on the Java policy
Hi, Michael Koch said: On Wed, Jan 30, 2008 at 09:32:46AM +0100, Eric Lavarde - Debian wrote: - the Java Policy should state that a Java package should depend on java2-runtime only if the packager expects its program to work with a classpath-alike implementation of Java. (what about IcedTea then?) IMO all java packages should depend on java2-runtime as second alternative and bugs should be filed against runtimes not working properly with a package. Oookay... Looks like we're doing circles here. How do we progress now? I'm fine with both options, but I feel that we need a consensus within debian-java, and that we don't have it yet. - in the words of Michael: Michael Koch said: The X packages should only be in Recommends and its possible to not install Recommends (but you are expected you are knowing what you are doing). Can we get an agreement on those points? Thats already fact. Do we need our own consensus in Debian Java? No, fine with me, I've closed my serious bug on this basis :-) Thanks, Eric -- You don't need to CC me on debian-java, debian-mentors and pkg-java-maintainers. Please CC me on other Debian lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Help needed on the Java policy
Hi, Michael Koch said: I'm currently working on a proposal for cleaning up the virtual package chaos. Please give me some more days for this. Fair enough, let's consider as a warm up for the discussion that will come once you'll show your proposal ;-) Thanks, Eric -- You don't need to CC me on debian-java, debian-mentors and pkg-java-maintainers. Please CC me on other Debian lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: icedtea status?
Hi, I agree that we have to take care when moving from contrib to main and that we have problems when some package in main works *only* with icedtea. IMO it is a good policy to file bugs against not working runtimes in this case so people know the problems and can work on them. OK, but please also post gcj failures to [EMAIL PROTECTED] At least, thing that don't buld with the latest gcj. I can't promise we'll fix everything, of course. Could we get those things officialized and documented somewhere (Debian's Wiki? Java Policy?) before it disappears in the depths of the mailing list? Eric -- Eric de France, d'Allemagne et de Navarre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Remove groovy
Hi Torsten, Torsten Werner said: Debian's groovy 0.1 currently FTBFS because libmockobject-java has been removed from sid, which it is broken by itself. Groovy 1.0 needs radeox which is not packaged (yet) but I had some discussions with upstream. I'll check the brand new version 1.5 ASAP. I assume Groovy 1.0 :-) I think it would be acceptable as a first step to have groovy 1.0 packaged with the dependencies already available. It would already be a huge improvement to have only 2 dependencies within the package. But you have now taken the lead, so your choice :-) Eric PS: I understand you are not on debian-java, but you should be :-) -- You don't need to CC me on debian-java, debian-mentors and pkg-java-maintainers. Please CC me on other Debian lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: OpenJDK and the Free Java Packaging Roadmap
But I like what the server tells you when you try to be smart and follow the link https://penta.debconf.org/file/event_attachment/38%20deb-openjdk.odp :-) Eric Florian Weimer said: These appear to be password-protected. -- Eric de France, d'Allemagne et de Navarre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: freemind and dependencies
Hi Arnaud, thanks for your answer. Arnaud Vandyck said: Package: libjibx-java (src) You build it with Sun's jdk and I don't have it (ppc). I tried to build it with java-gcj-compat-dev but it failed to generate byte code somewhere in the build process. Also, you set ANT_HOME, and you put ant-launcher in debian/rules. These two lines are no more needed. OK, will fix these two things. If you have packages that build with gcj-java-compat-dev, just give me the url to the orig tarball and the name of the directory in SVN and I'll be glad to review and upload if possible. I tried (not too hard to be honest) to get all packages compiling with gcj, but without success. My plan was actually to get all these packages into Debian (compiled with Sun's compiler), and then A. patch code or B. flag bugs against classpath/gcj until FreeMind and dependencies compile and run. It's perhaps not the best approach and I'm happy to hear about alternative ones. Nevertheless, everything should compile with Blackdown Java (I assume, I don't know, it worked a while ago); would this be an alternative!? Cheers, Eric -- Eric de France, d'Allemagne et de Navarre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: freemind and dependencies
Hi,
Arnaud Vandyck said:
I'll try to rebuild your packages with ibm's jdk and upload them.
Do you _add_ IBM's home directory to JAVA_HOME_DIRS in rules +
corresponding build dependency, or replace it?
Background of my question: I know that it's not considered good practice
to have alternative build dependencies, but on the other hand:
- we will have tested both alternatives
- it's a bit cumbersome if we both need to switch JDK back and forth in
debian/{rules,control}
Anyway, thanks for your support :-)
Cheers, Eric
--
Eric de France, d'Allemagne et de Navarre
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#411692: bootchart-view: Needs libgtkpeer.so when converting a bootchart to EPS or PNG format
Hi, Michael Koch said: Recommends are installed by default. People explicitely dont installing the recommends and then wondering about broken stuff are on their own. How do you mean this? Technically, apt-get and aptitude do *not* install Recommends by default. I read the policy in such a way that missing features are ok, broken should be a dependency. Thanks, Eric -- Eric de France, d'Allemagne et de Navarre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Which class in which package
Hi, [EMAIL PROTECTED] said: Eric Lavarde - Debian schrieb: Hi, There is no formal way to do this that I would know, but: apt-cache search some intelligent search pattern there is also apt-file but I'm not using it. Eric If i catch your point your suggestions are for searching files, which i also can do on http://www.debian.org/distrib/packages. The point of my question ist, that classes are _inside_ of jar-files and therefor not visible for this kind of search (as fas as i know). it's true, that's why I called it an intelligent search pattern: often you can guess/derive the possible debian-package and/or library name from the java-package and/or class name. But, of course, Michael's offer is much better ;-) Eric thanks for your quick answer gerhard gerhard oettl said: Hello Is there a standard (or any) way to find out which java class is in which non installed debian package to know whats to install if a ClassNotFoundException arises? gerhard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- You don't need to CC me on debian-java, debian-mentors and pkg-java-maintainers. Please CC me on other Debian lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Which class in which package
Hi, There is no formal way to do this that I would know, but: apt-cache search some intelligent search pattern there is also apt-file but I'm not using it. Eric gerhard oettl said: Hello Is there a standard (or any) way to find out which java class is in which non installed debian package to know whats to install if a ClassNotFoundException arises? gerhard -- Eric de France, d'Allemagne et de Navarre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Location of API docs
Hi, Mark Wielaard said: You can use the -link option to do this. It works very well with Sun's Javadoc, but I have not tried it with gjdoc. I can't remember the details, but it's integrated with ant's javadoc target. For Debian packages we need -linkoffline to link to the locally installed javadocs of dependant packages. I havent tried yet if one or both of these options work in gjdoc or not. They both work for gjdoc. so to summarize (and give my personal conclusion of) the discussion: one needs to give explicitly the location of the referred-to javadoc in ones call to ant, and it doesn't make any difference if it's under $package-doc/api or $package/api, so better respect the expectations of the Debian policy. No!? Eric -- You don't need to CC me on debian-java, debian-mentors and pkg-java-maintainers. Please CC me on other Debian lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Changing policy for the Maintainer field
Hi Marcus, I'd like to raise three things: 1. you say twice in your email that Debian has a Java quality issue. Can you please be more specific, I don't understand which issue(s) you're aiming at? 2. perhaps a step to make those issues visible and more easily addressable by the pkg-java team, would be to have a report sent monthly with all RC bugs + all bugs of a certain importance not answered for 6 months. We would then do a review making sure that each package/bug is properly owned (e.g. through a certain tag). 3. Maintainer would remain on pkg-java, first name of the Uploaded field should be the human/main maintainer, but would be only updated when doing for other reasons an upload. Cheers, Eric -- You don't need to CC me on debian-java, debian-mentors and pkg-java-maintainers. Please CC me on other Debian lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Location of API docs
Hi,
Marcus Better said:
Matthias Klose wrote:
How come? I thought we put api docs in the -doc package, if there is
one.
exactly, but into the /usr/share/doc/$package/api directory, not into
the /usr/share/doc/$package-doc/api directory.
[...]
Is it really better to put the docs in /usr/share/doc/$package? Note that
${package-doc} should not depend on $package, and installing only the -doc
package would still create both directories under /usr/share/doc.
I do second this comment: I don't understand the advantage to have the api
under /usr/share/doc/$package/api but I surely know that it's confusing if
it's part of $package-doc package, and keeps us from using dh_installdocs.
The Debian policy uses a lot of should in the Documentation section (12)
but 12.3 says /usr/share/doc/package may be a symbolic link to another
directory in /usr/share/doc only if the two packages both come from the
same source and the first package Depends on the second.. I translate
this into it's OK to share documentation if one package depends on the
other, i.e. $package-doc depends on $package, which is generally not the
case.
Eric
Guess we should decide on some policy and start filing wishlist bugs.
Let's see :-)
Marcus
--
You don't need to CC me on debian-java, debian-mentors and
pkg-java-maintainers.
Please CC me on other Debian lists.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian key-signing in victoria bc
Hi, Shaun Jackman said: On 1/9/07, Alan Ezust [EMAIL PROTECTED] wrote: Ah, you maintain another java package! that's good to know. So azureus does not require java 1.5, I take it? I see under depends, it requires java2-runtime and java-virtual-machine. Those are (I think) for 1.4? jedit needs java 1.5, so should I list its dependency as sun-java5-jre? Good question. I don't know the answer. Best to ask debian-java. Depending specifically on sun-java5-jre precludes using any other Java VM though. I would avoid it unless sun-java5-jre is really the only Java VM that works with jedit. I think that there is currently no good answer for this, a new version of the java-policy is pending since quite a while, which might resolve this common kind of issue (or not). Personally I would currently tend to put something like sun-java5-jre | java2-runtime and let my script check the java version actually used, issuing a warning if I don't think the used java VM will work. Not perfect but the best I could currently come with. On a more generic note, I think that the issue comes from Java having different compilers/VMs with different versioning, whereas C/C++/Perl/YouNameIt has only one candidate, and can depend on a specific version. Perfect solution would be to have all compilers/VMs align their versioning with the Java version they _completely_ support (one could think about things like 1.4~notyetfinished, meaning '1.4 almost implemented'). Alternative being the possibility to have virtual packages with versions. Cheers, Eric -- You don't need to CC me on debian-java, debian-mentors and pkg-java-maintainers. Please CC me on other Debian lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: getting search url address from browser by java
Hi Shaji, shajiprabhakaran prabhakaran said: from:- [EMAIL PROTECTED] To, All Members, Debian-java is not a general purpose list for asking Java questions, but a list to discuss compiling and packaging issues concerning Java packages under Debian. how can collect searching url address from browser by using java? Furthermore, your question is not very clear to me. Cheers, Eric thanking you shaji.p -- Eric de France, d'Allemagne et de Navarre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: JDK is GPL now! a package in main requested
Hi, AIUI, all that is becoming GPL as of today is javac and JavaHelp (and does someone know where one can pull the GPLed version of JavaHelp? Someone already planning to package it? Someone minding if I'll do it? Thanks, Eric -- You don't need to CC me on debian-java, debian-mentors and pkg-java-maintainers. Please CC me on other Debian lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian-Edu and Java (Was: java.awt.AWTError: Cannot load AWTtoolkit: gnu.java.awt.peer.gtk.GtkToolkit)
Hi, Petter Reinholdtsen writes: The most important feature is java applet support. Some of the important test cases are listed on URL:http://wiki.debian.org/DebianEdu/JavaInDebianEdu. Last time I tested, few of them were working properly in Etch with gcjappletviewer. :( apparently before java-gcj-compat-plugin entered the archive, equivalent with the classpath-0.92 release. Is the security issue which was discussed a while ago (something about lack of encapsulation of java applets) solved in the mean time? Thanks, Eric Matthias -- You don't need to CC me on debian-java, debian-mentors and pkg-java-maintainers. Please CC me on other Debian lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: java.awt.AWTError: Cannot load AWT toolkit: gnu.java.awt.peer.gtk.GtkToolkit
Hi, I see 3 possible solutions: 1. add -Dgnu.java.awt.peer.gtk.Graphics=Graphics2D to the command line (not sure if it's related but it shouldn't hurt ;-) ). 2. call JAVA_HOME=/usr/lib/jvm/java-1.5.0-sun java -cp ... (case by case) 3. or make sure that Sun's Java is your default Java by using the /usr/sbin/update-java-alternatives command. /usr/sbin/update-java-alternatives --set java-1.5.0-sun should do the trick. Hope this helps, Eric -- You don't need to CC me on debian-java, debian-mentors and pkg-java-maintainers. Please CC me on other Debian lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Testing: calculating/setting icon sizes: java.lang.ArithmeticException: / by zero
Hi, Holger Rauch wrote: Hi Eric, first of all, thanks for your reply. Is this bug considered important enough so it will be fixed for the final release of Etch? Just to say that I can't answer this question, it's Sun or the package maintainers to answer. All I can say is that the bug report is currently 'important' i.e. not Release Critical. Eric -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
FOP and BATIK removed from testing
Hi, I'm not sure I really sure I properly understand the consequences of those annoucements, but I'm sure I appreciate that fop batik are part of Debian. Any risk that it won't be the case in the future? Anything I can do to avoid this? Thanks, Eric -- Eric de France, d'Allemagne et de Navarre---BeginMessage--- FYI: The status of the fop source package in Debian's testing distribution has changed. Previous version: 1:0.20.5-8 Current version: (not in testing) Hint: http://ftp-master.debian.org/testing/hints/vorlon # 20060915; done 20060916 Bug #385293: batik: build-depends on libgnujaxp-java, which is RC-buggy The script that generates this mail tries to extract removal reasons from comments in the britney hint files. Those comments were not originally meant to be machine readable, so if the reason for removing your package seems to be nonsense, it is probably the reporting script that got confused. Please check the actual hints file before you complain about meaningless removals. -- This email is automatically generated; [EMAIL PROTECTED] is responsible. See http://people.debian.org/~henning/trille/ for more information. ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers ---End Message--- ---BeginMessage--- FYI: The status of the batik source package in Debian's testing distribution has changed. Previous version: 1.6-2 Current version: (not in testing) Hint: http://ftp-master.debian.org/testing/hints/vorlon # 20060915; done 20060916 Bug #385293: batik: build-depends on libgnujaxp-java, which is RC-buggy The script that generates this mail tries to extract removal reasons from comments in the britney hint files. Those comments were not originally meant to be machine readable, so if the reason for removing your package seems to be nonsense, it is probably the reporting script that got confused. Please check the actual hints file before you complain about meaningless removals. -- This email is automatically generated; [EMAIL PROTECTED] is responsible. See http://people.debian.org/~henning/trille/ for more information. ___ pkg-java-maintainers mailing list pkg-java-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers ---End Message---
Re: Why Sun-JRE does not provide java-runtime?
Hi Joerg, it was not meant like this and changes to the Java Policy should fix this in the near future, but one can currently say that: java2-runtime = Sun/Blackdown Java java-runtime = classpath (or alike) based free VM It's probably not politically correct to write this ;-), but I think that it represents quite well the current reality. Cheers, Eric Hi, I've got a request #385190 to add the java2-runtime to the dependency alternative of the package bootchart-view. What's the difference between java-runtime and java2-runtime? Why does the JRE from Sun not provide java-runtime? Bye, Jörg. -- Wir leben zwar unter dem gleichen Himmel, müssen aber nicht zwangsläufig den gleichen Horizont haben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Eric de France, d'Allemagne et de Navarre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
ArithmeticException: / by zero in XIconWindow
Hi, I know it´s probably linked to a proprietary Java (I know that some people from Sun have now sneaked in ;-), but is someone aware of the problem described under: http://forum.java.sun.com/thread.jspa?threadID=760238 which will probably hit testing (and the fan) at some point in time? I´m asking because I'm supporting FreeMind on Linux and would prefer to have the issue fixed before the fan is hit (already got a request about it), even though I have no clue where I should start looking (hence this email). Thanks, Eric -- Eric de France, d'Allemagne et de Navarre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: JNotify
Hi, being relatively new to the world of packaging, I'll be a bit more specific: - start with reading the New Maintainer's guide, on the devel page given by Michael, or out of the maint-guide package. - create an ITP (Intent To Package) on the wnpp package (with reportbug). - CDBS is in deed really nice to easily package a Java library. - as a basis for your package, I can suggest my packages libjgoodies-forms-java and libjcalendar-java. They use CDBS and are pretty straight-forward aka simple to understand. - once you've packaged the library and can install remove it without error or warnings and once it's lintian linda clean, you can ask for a sponsor on this list. If you have questions in the mean time, you are welcome to ask back questions on this list or on the debian-mentors list. Nevertheless, most of your questions will already been answered before, either in the Debian Policy or in the Developer's Reference, so you should consider these 2 documents as your bible/thora/coran ;-). Check also http://wiki.debian.org/Java and http://pkg-java.alioth.debian.org/ Hope this helps, Eric On Fri, Jun 23, 2006 at 10:12:18AM +0300, Omry Yadan wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, JNotify (http://sourceforge.net/projects/jnotify/) is a java library that provide file system notification for java applications running on linux and windows, licensed under lgpl. I`d like to get it into Debian, what's the procedure? Read all the documentation at http://www.debian.org/devel/. Look at some other packages. Java libraries preferable. Look at CDBS. Package JNotify. Upload it somewhere, e.g. mentors.debian.net. Come back and ask for review and upload of the package. It would be nice to maintain this udner the Debian Java maintainers umbrella. When the package is done we can commit the package to our SVN and start maintaining from there. Cheers, Michael -- Eric de France, d'Allemagne et de Navarre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: priorities for java alternatives
Hi, Eric Lavarde - Debian wrote: Speaking of alternatives, it would be nice to have a mean to completely switch from one Java alternative to another. Currently you need to modify more than 10 different alternatives in order to switch from e.g. kaffe to Sun's Java or back. I don't know how this could be fixed, but this is cumbersome. Wouldn't it be possible to define only alternatives for java and javac, and everything else would be slave alternatives of the both, depending if they're meant to be Runtime or Development commands? You are correct. A solution to this problem has been incorporated into java-common 0.25: update-java-alternatives(8) Thanks for the hint, I've just seen that java-common 0.25 entered testing, so I should have it soon installed on my laptop. Else, for all your enhancement points, +1. But you don't need to be DD to fix them, just do a reportbug and attach a patch ;-) Eric -- You don't need to CC me on debian-java, debian-mentors and pkg-java-maintainers. Please CC me on other Debian lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: priorities for java alternatives
Hi, Before popcon (number of downloads), I would suggest number of non-library packages depending on the VM, i.e. if you install a certain VM, how many applications will you be able to run with it, without having to install another VM and play with JAVA_HOME etc... You are proposing two distinct alternatives: - number of non-library packages depending on the VM - if you install a certain VM, how many applications will you be able to run with it The first is easier to measure, while the second would potentially be more useful. Errh, agree, but the idea was that it's somewhat correlated (or am I missing something!?), and if: 1. you trust the non-library package maintainers :-) 2. modify the 2nd alternative with being *sure* to be able to run then it's pretty much the same. In other words: if the package has a dependency on a specific VM, that should mean that the maintainer has tested the application with the VM. Cogito ergo sum. Cheers, Eric -- Eric de France, d'Allemagne et de Navarre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Bug#360906: libhsqldb-java: should depend on java-runtime?
Hi, as java-runtime is not a virtual package listed in the policy, I would say that it's worth a bug against gij, which should provide java1-runtime *and* java2-runtime (according to the current, in deed not really practicable policy). Eric PS: no need to cc me on debian-java. Any suggestions on this? I think having java1-runtime and java2-runtime is meaningless in practice, but the policy calls for them and hsqldb will probably not work with Java 2 runtime. -- Forwarded Message -- Subject: Bug#360906: libhsqldb-java: should depend on java-runtime? Date: Wednesday 05 April 2006 14:42 From: Luca Capello [EMAIL PROTECTED] To: Debian Bug Tracking System [EMAIL PROTECTED] Package: libhsqldb-java Version: 1.8.0.2-2 Severity: minor Hello, I'd like to completely get rid off the Sun JRE in favor of the GIJ, but I can't, because - libhsqldb-java depends on java2-runtime - gij-4.0 provides java-runtime and java1-runtime only I don't know anything about Java, so I'm not sure where it's the problem: should libhsqldb-java depend on java-runtime or gij-4.0 provide java2-runtime? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Eric de France, d'Allemagne et de Navarre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
SVN for dummy java packagers...
Hi, Until recently, I had never used SVN and had to learn it quite quickly, so I created myself a list of important commands. I've put this list in its raw state under http://wiki.debian.org/Java/JavaSvn. Two things: 1. if you think it's of interest to other persons, I can put some words around the raw data. 2. svn-buildpackage --svn-tag creates tags which are not compliant with the Java packager instructions hosted somewhere (I lost track of this page), i.e. it's X.Y.Z-N instead of RELEASE_X_Y_Z-N. Do you see this as an issue? Cheers, Eric -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Someone working on ws-jaxme?
Hi Wolfgang, Its already package and will be uploaded to the archive soon. For now: http://www.home.uos.de/wbaer/downloads/ForUpload/ Great, thanks! PS: 0.5.1 has not the freemind issue fixed. It's fine, it's not anymore meant as a replacement for JAXB (it'll be JiBX), but as a dependency of JiBX/xsd2jibx, and this one was already working with version 0.3. I'm just now hoping it's still working with 0.5.1... Thanks a lot, Eric -- Eric de France, d'Allemagne et de Navarre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Someone working on ws-jaxme?
Hi, for jibx packaging (well, actually, xsd2jibx), I would need ws-jaxme as a dependency (I'm currently using the jar jaxme-js-0.3, which is part of the jibx sources). I vaguely remember that someone said, he would work on jaxme. Is this still correct? If yes, what would be the timeline? If not, I could package it... Thanks, Eric -- Eric de France, d'Allemagne et de Navarre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Debian-Java] Bits from the FOSDEM
Hi, If the library builds with a free VM and only runs partially under a free VM, the question should be is there a program ready to go to main, depending on this library, and running under a free VM with this library?; if the answer would be yes, then the library MUST go to main, in order to allow the program to go to main as well. Thats the intention for this change. Which is by the way explained in the draft as rational point 3. There are libraries which are needed for programs runnable by free runtimes. That means that the libraries parts/classes/features used by this program work on free runtimes. I understood this, and my point (which you've cut out) was more that if there is no program able to use this library with a free VM and/or if the maintainer of the library can't think of any use case where his library could work under a free VM, then the library SHOULD NOT/CANNOT be part of main. Also: will the rational be part of the finalized policy? Eric PS: no need to CC me! Wolfgang -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- N/A signature -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Debian-Java] Bits from the FOSDEM
Hi, - java libraries can go to main if they can be built with free VM; Does this also mean that it is no longer required that a library be runnable from a free VM? My libbcprov-java builds just fine, but the test cases fail under all free VMs. I would also second the fact that, if the library builds with a free VM but the maintainer can't find/determine a use case where the library would run under a free VM, the library CANNOT not be part of main. If the library builds with a free VM and only runs partially under a free VM, the question should be is there a program ready to go to main, depending on this library, and running under a free VM with this library?; if the answer would be yes, then the library MUST go to main, in order to allow the program to go to main as well. In all other cases, well, it would be up to the maintainer (or we could say the library MAY/SHOULD go to main). As a maintainer, I'm not really keen to answer to hordes of disappointed users why the library in main doesn't work with any free VM. Cheers, Eric -- Eric de France, d'Allemagne et de Navarre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kaffe transition freemind
Hi, thanks to everybody for the help, in deed the -Dthing suppressed the warning but didn't change anything else (well, the GUI style looks different). But, as said, I will first dig a bit more into it, especially make sure to suppress all warnings at compile time, and then I'll file bugs :- Cheers, Eric This one is easy if kaffe has been configure with --enable-gtk-cairo (this is an experimental Graphics2D implementation based on Cairo, it still needs lots of works, I don't know if the kaffe package in Debian has this enabled). If it has then you can run the program with -Dgnu.java.awt.peer.gtk.Graphics=Graphics2D -- Eric de France, d'Allemagne et de Navarre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using Free JVM implementations
Hi, Unfort with kaffe I get the following error: I am sure that the kaffe developers would be pleased to know what exactly doesn't work with their implementation. BTW, have you tried to use any other JVM for comparison purposes? It would be good to know. 15:27:32 ~/src$ kaffe -jar JabRef-1.8.1.jar kaffe-bin: /build/buildd/kaffe-1.1.6/build-tree/kaffe-1.1.6/kaffe/kaffevm/support.c:351: lookupClassMethod: Assertion `cls != ((void *)0)' failed. Aborted It's a known issue with the current version of Kaffe [1], to be solved (I understand) with the next version. BTW, you can check the already reported bugs against any package using http://bugs.debian.org/packagename (e.g. http://bugs.debian.org/kaffe). Hope this helps, happy christmas, Eric [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=337560 -- Eric de France, d'Allemagne et de Navarre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Questions about Eclipse, EMF, ecj...
Hello, as a Java newbye, I have three questions: 1. I see a lot of emails going round concerning issues with Eclipse. Are all these issues only border cases and can Eclipse be used productive, or should a newbye still wait a bit with it? (speaking 'sid'). 2. For FreeMind, upstream and myself are thinking of replacing JAXB through EMF http://www.eclipse.org/emf/. Is this tool hidden somewhere in the Eclipse packages (I couldn't find it as an explicite one)? Does someone plan to package it, or has experience with it? 3. Also for FreeMind, I tried to use kaffe but jikes dumped http://bugs.debian.org/338176 and its development seems to be quite stalled. Is there an option to use ecj as a drop-in replacement (and how)? Thanks, Eric PS: and a nice christmas to all! -- Eric de France, d'Allemagne et de Navarre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Questions about Eclipse, EMF, ecj...
Hi, Hi Eric, Michael Koch wrote: On Thu, Dec 22, 2005 at 01:38:16PM +0100, Eric Lavarde - Debian wrote: 3. Also for FreeMind, I tried to use kaffe but jikes dumped http://bugs.debian.org/338176 and its development seems to be quite stalled. Is there an option to use ecj as a drop-in replacement (and how)? kaffe development is not stalled. Its very active. They just not release very often. ;-) sorry, I didn't mean to say that the kaffe development had stalled, but that the _jikes_ development has stalled. A conclusion to which the kaffe team seems to have also come. The next kaffe package will switch to ecj as the default compiler. Is it already possible to switch? Thanks, Eric -- N/A signature -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Questions about Eclipse, EMF, ecj...
Hi Eric, Eric Lavarde - Debian wrote: Hi, The next kaffe package will switch to ecj as the default compiler. Is it already possible to switch? No, it needs adaption only available in upstream CVS and some tweaks in the packaging. I will be without internet from today on until end of year. A package for experimental will be available after new year for testing of packages against the new kaffe before a new upstream release is made and uploaded to unstable. OK, you've got one interested beta tester :-) Eric Wolfgang -- N/A signature -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Does libjcalendar-java qualify for main?
Hi, -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric Lavarde - Debian wrote: Hi, I didn't get any answer to this email, so I reformulate my question: - is someone willing to sponsor me on this package placed in main? - if not, I already have a sponsor for contrib ;-) Why not in main? Oh, he would probably agree to be my sponsor for main, but I thought that: - JCalendar fitting for main, - I would put it under shared Java maintenance. - then it would make sense to have a sponsor from the Java maintenance group. but if I'm making it too complicated, just tell me, it's my first package I'm trying to put under main resp. under common Java maintenance. - is it OK to upload this package to CVS, even though it's not (yet) maintained by Java Maintainer? yes. OK. Eric, sorry the slow response, very busy at the moment and it seems other java DD also are :( That's fine, I'm seeing all the eclipse and tomcat messages flying around. I know you're not lazy :- I'll try to recontact you if your package has not been reviewed. It hasn't yet, in respect of being OK for main (there is already a version in contrib). What about libforms-java? (I know, give a finger, take an arm...) Thanks, Eric PS: and, I wish everybody a merry christmas, frohe Weihnachten, joyeux noel... (and the same for the new year as a whole) -- N/A signature -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Does libforms-java qualify for main?
Hi, I didn't get any answer to this email, so I reformulate my question: - is someone willing to sponsor me on this package placed in main? - if not, is someone willing to sponsor me on this package placed in contrib? Thanks, Eric (and the version is also uploaded in CVS) Hi, I have repackaged libforms-java, using kaffe (I formerly also successfully used free-java-sdk but was convinced to jump to kaffe), but (see attached file for details): 1. I hit the current GUI issue with kaffe 1.6. 2. free-java-sdk aka sablevm does not really work. 3. the thing works perfectly with Sun's Java, and as part of FreeMind. 4. the example also does work actually with kaffe 1.5, even though there is a warning about NO LAYOUT SET !!!, and the GUI is kind of not so nice (but usable, see picture). So, does it qualify for main, or not? And, anyway, does someone want to be my sponsor (Arnaud, you candidated!?)? Thanks, Eric PS: right now, I didn't yet upload the new version to CVS, but will do shortly, and the packages are available from: deb http://eric.lavar.de/comp/linux/debian/ experimental/ deb-src http://eric.lavar.de/comp/linux/debian/ experimental/ -- Eric de France, d'Allemagne et de Navarre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Does libjcalendar-java qualify for main?
Hi, I didn't get any answer to this email, so I reformulate my question: - is someone willing to sponsor me on this package placed in main? - if not, I already have a sponsor for contrib ;-) - is it OK to upload this package to CVS, even though it's not (yet) maintained by Java Maintainer? Thanks, Eric (and the version is also uploaded in CVS) Hi again, I have a similar issue with libjcalendar-java as with libforms-java: I can compile with kaffe but I can't really test the runtime behavior. JCalendar compiles well with kaffe 1.6, but I, short of creating myself a test program, I can only test through freemind (with Sun's java) as I don't know of any other free applet viewer than gcjappletviewer, and this one fails with a Segmentation fault (and no other error message). So what? ;-) Thanks, Eric The packages are available from: deb http://eric.lavar.de/comp/linux/debian/ unstable/ deb-src http://eric.lavar.de/comp/linux/debian/ unstable/ (take care: it's version 1.2.2-7! Version 1.2.2-6.1 is the one in testing/unstable, compiled with Sun's Java). -- Eric de France, d'Allemagne et de Navarre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Does libforms-java qualify for main?
Just be patient. Wow, wow, nobody told me it was a prerequisite to package Java for Debian! OK, I'll do my best... ;-) Eric PS: I'm on both Debian Java and Java Maintainers mailing lists, no need to CC. -- N/A signature -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Does libforms-java qualify for main?
Hi, I have repackaged libforms-java, using kaffe (I formerly also successfully used free-java-sdk but was convinced to jump to kaffe), but (see attached file for details): 1. I hit the current GUI issue with kaffe 1.6. 2. free-java-sdk aka sablevm does not really work. 3. the thing works perfectly with Sun's Java, and as part of FreeMind. 4. the example also does work actually with kaffe 1.5, even though there is a warning about NO LAYOUT SET !!!, and the GUI is kind of not so nice (but usable, see picture). So, does it qualify for main, or not? And, anyway, does someone want to be my sponsor (Arnaud, you candidated!?)? Thanks, Eric PS: right now, I didn't yet upload the new version to CVS, but will do shortly, and the packages are available from: deb http://eric.lavar.de/comp/linux/debian/ experimental/ deb-src http://eric.lavar.de/comp/linux/debian/ experimental/ -- Eric de France, d'Allemagne et de Navarre libforms.out Description: Binary data forms-kaffe1_5.png Description: PNG image
Does libjcalendar-java qualify for main?
Hi again, I have a similar issue with libjcalendar-java as with libforms-java: I can compile with kaffe but I can't really test the runtime behavior. JCalendar compiles well with kaffe 1.6, but I, short of creating myself a test program, I can only test through freemind (with Sun's java) as I don't know of any other free applet viewer than gcjappletviewer, and this one fails with a Segmentation fault (and no other error message). So what? ;-) Thanks, Eric The packages are available from: deb http://eric.lavar.de/comp/linux/debian/ unstable/ deb-src http://eric.lavar.de/comp/linux/debian/ unstable/ (take care: it's version 1.2.2-7! Version 1.2.2-6.1 is the one in testing/unstable, compiled with Sun's Java). -- Eric de France, d'Allemagne et de Navarre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status of FreeMind
Hi, jaxme is almost ready as part of my dom4j packaging effort. It was only stalled recently due to other more important stuff. I will reactivate it :-) Great, if you want really to be nice with me, have a look at my RFP, as I point to an issue with FreeMind, which would need a (non-trivial IMHO) patch (else I'll just wait vor version 0.6, which might/should have the fix). xindice is not needed to provide jaxme. One can compile it without xml-db support - which I think most people don't use anyway. That's even greater. :-) The FontInfo class is really a problem - I would go upstream and ask for replacement as its undocumented and will never be part of GNU classpath. That's less great, but I will do. If someone can point to a possible replacement, that would be nice. Thanks a lot, Eric Regards, Wolfgang -- N/A signature -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Running X Java Client from chroot environment?
Hi, That is a bug in older GNU Classpath snapshots. Use a newer kaffe and it should work (I think the bug is still in gcj 4.0 in unstable. Aha, thanks for the hint, I was using SableVM where I should have used Sun's Java... stupid me... Eric -- N/A signature -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Running X Java Client from chroot environment?
Hi,
SableVM uses an ultra old snapshot of GNU classpath. Kaffe should work
fine. No need to switch to non-free stuff for this.
Well, not for this, but for other reasons perhaps: :-)
[EMAIL PROTECTED]:~$ DISPLAY=:0 JAVA_HOME=/usr/lib/kaffe/jre DEBUG=1 freemind
DEBUG: Freemind parameters are ''.
DEBUG: Linux lavardex 2.6.12-5.99.sarge1 #1 Fri Oct 14 09:13:19 CEST
2005 i686 GNU/Linux
DEBUG: Using $JAVA_HOME to find java virtual machine.
DEBUG: Using '/usr/lib/kaffe/jre/bin/java' as java virtual machine...
java full version kaffe-1.4.2
kaffe VM 1.1.6
Copyright (c) 1996-2005 Kaffe.org project contributors (please see
the source code for a full list of contributors). All rights reserved.
Portions Copyright (c) 1996-2002 Transvirtual Technologies, Inc.
The Kaffe virtual machine is free software, licensed under the terms of
the GNU General Public License. Kaffe.org is a an independent, free software
community project, not directly affiliated with Transvirtual Technologies,
Inc. Kaffe is a Trademark of Transvirtual Technologies, Inc. Kaffe comes
with ABSOLUTELY NO WARRANTY.
Engine: Just-in-time v3 Version: 1.1.6 Java Version: 1.4
Heap defaults: minimum size: 5 MB, maximum size: unlimited
Stack default size: 256 KB
DEBUG: Freemind Directory is '/usr/share/freemind'.
DEBUG: Calling: '/usr/lib/kaffe/jre/bin/java
-Dfreemind.base.dir=/usr/share/freemind -cp
::/usr/share/freemind/lib/freemind.jar:/usr/share/freemind/lib/ant/lib/jaxb-api.jar:/usr/share/freemind/lib/ant/lib/jaxb-impl.jar:/usr/share/freemind/lib/ant/lib/jaxb-libs.jar:/usr/share/freemind/lib/ant/lib/namespace.jar:/usr/share/freemind/lib/ant/lib/xsdlib.jar:/usr/share/freemind/lib/ant/lib/jax-qname.jar:/usr/share/java/forms-1.0.5.jar:/usr/share/java/commons-lang.jar:/usr/share/java/jaxp-1.2.jar:/usr/share/java/relaxngDatatype.jar:/usr/share/freemind
freemind.main.FreeMind '.
kaffe-bin:
/build/buildd/kaffe-1.1.6/build-tree/kaffe-1.1.6/kaffe/kaffevm/support.c:351:
lookupClassMethod: Assertion `cls != ((void *)0)' failed.
/usr/bin/freemind: line 142: 9191 Aborted ${JAVACMD}
-Dfreemind.base.dir=${freedir} -cp ${CLASSPATH} freemind.main.FreeMind
$@
Cheers, Eric
--
N/A signature
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to compile java files?
Hi, I rather recently learned to compile Java programs the Debian way, hence I remember how I learnt it, and basically the easiest way is to take a similar java program from debian and look at the way it's packaged. I was a bit reluctant at the beginning but using cdbs makes it even simplier, just copy a version from some other package or from /usr/share/doc/cdbs/examples, tweak the result using different variables (I've found easier to browse through the included makefiles to understand which variables are available and do what), create some patches under debian/patches, and that's almost it... Hope this helps, Eric -- Eric de France, d'Allemagne et de Navarre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Contrib packages should absolutely be compiled with Java 1.4
Hi, trying to use a new library libjcalendar-java, compiled with Java 1.5, to recompile FreeMind with Java 1.4, I got an error saying that Java couldn't open the Jar file: [javac] Compiling 6 source files to /home/ericl/Comp/FreeMind/freemind-0.7.9.rc5/bin/classes [javac] /home/ericl/Comp/FreeMind/freemind-0.7.9.rc5/freemind/plugins/time/TimeManagement.java:52: cannot access com.toedter.calendar.JCalendar [javac] bad class file: /usr/share/java/jcalendar.jar(com/toedter/calendar/JCalendar.class) [javac] class file has wrong version 49.0, should be 48.0 [javac] Please remove or make sure it appears in the correct subdirectory of the classpath. [javac] import com.toedter.calendar.JCalendar; [javac] ^ [javac] 1 error For me it means that the need to compile with Java 1.4 should be added to the policy, or at least to the Java FAQ. What do you think? Eric -- Eric de France, d'Allemagne et de Navarre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Missing JSpinner component
Hi, If you upload it to contrib before - please add the package to http://java.debian.net/index.php/MovingJavaToMain, with some additional comment that its compilable against Classpath CVS and should be moved to main when new vm's are uploaded. The package libjcalendar-java is since today in contrib/unstable, and I added a note to the given page. A have an additional question though: Under http://java.debian.net/index.php/ShouldGoToMain, chapter Swing problem, it's written: Many of these packages might be buildable using [SwingWT], an implementation of Swing and AWT based on SWT (which is now in main). It claims to be an almost complete drop-in replacement, and can be built to use the class names java.awt.* and javax.swing.* . (But it's not the way we wanna go in Debian (avdyk)). Mmh, what is the way we wanna go in Debian? Thanks, Eric -- N/A signature -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Missing JSpinner component
Hi, PS: Are you now subscribed to pkg-java-maintainers and debian-java lists? Yep, you can stop cc me ;-) Eric -- N/A signature -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposing libforms-java for debian java maintenance
Hello, I didn't get an answer to this email? Everybody in holiday or nobody interested? (it's not a problem, I can try to use my usual sponsor, perhaps he doesn't get weary of me) Thanks, Eric Hi, I've packaged libforms-java (ITP: http://bugs.debian.org/320044) as it'll be a dependency for the next version of FreeMind. I managed to package it only with free java tools (free-java-sdk + gjdoc), and hence wanted to propose it for adoption by the Debian Java Maintainers as IMHO it could go to main (I need in all cases a sponsor). I thought I'd seen a description on how to trigger this but I can't find it anymore, thanks for pointing me to the right document or triggering it. Packages can be found under: http://eric.lavar.de/comp/linux/debian/dump/ (lintian and linda clean, works, etc). Thanks, Eric -- Eric de France, d'Allemagne et de Navarre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposing libforms-java for debian java maintenance
Hi, (replying at the same time to Peter and Stefan) Thanks to both, the link to Alioth was what I was missing, I'll get an account and subscribe to the mailing list, and then I'll ask for addition on the pkg-java project (Stefan, I'll grab your offer), upload my files to CVS and finally ask for sponsoring. Did I understand everything right? :-) If you want to use the pkg-java source repository and add [EMAIL PROTECTED] as a co-maintainer of your package, read URL:http://pkg-java.alioth.debian.org/developers.html and join in on the effort to improve the state of Java in Debian. :) Will do. May I suggest to add this link somewhere on the Debian Java Wiki (OK, did it myself!), and also possibly to the java-common package (perhaps to the FAQ packaged with it?). Thanks again, Eric -- Eric de France, d'Allemagne et de Navarre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Proposing libforms-java for debian java maintenance
Hi, I've packaged libforms-java (ITP: http://bugs.debian.org/320044) as it'll be a dependency for the next version of FreeMind. I managed to package it only with free java tools (free-java-sdk + gjdoc), and hence wanted to propose it for adoption by the Debian Java Maintainers as IMHO it could go to main (I need in all cases a sponsor). I thought I'd seen a description on how to trigger this but I can't find it anymore, thanks for pointing me to the right document or triggering it. Packages can be found under: http://eric.lavar.de/comp/linux/debian/dump/ (lintian and linda clean, works, etc). Thanks, Eric -- Eric de France, d'Allemagne et de Navarre -- Eric de France, d'Allemagne et de Navarre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Policy/recommendation on compiling with version 1.4 vs. 1.5?
Hi, my understanding of the differences between Java 1.4 and 1.5 is that programs compiled with Java 1.5 might not work in the JVM 1.4, but the other way around should always work. So my questions: 1. is this correct? 2. if yes, shouldn't the consequence for Debian be, even though Sun Java is not officially supported, a recommendation or policy that Java packages should be compiled with Java 1.4, if possible? Thanks, Eric -- Eric de France, d'Allemagne et de Navarre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#283557: java-common: JAVA POLICY: define defaultJAVA_HOME=/usr/lib/java as alternative.
Hi,
the program which needed JAVA_HOME was 'ant'; it might have had to do with
the fact that I had the JDK and JRE packages both installed with some
alternatives (java) pointing to the JRE and some (javac) to the JDK.
But, anyway, I had to define JAVA_HOME to make it work.
And I thought that what I proposed is aligned with the policy rule you are
listing (and which I considered in my thoughts). If /usr/lib/java is
defined as the default alternative for the JAVA_HOME directory, I can, in
my program, script, Makefile, rule-file, set JAVA_HOME to the default
/usr/lib/java value, giving the user a chance to overrule this through his
own definition of JAVA_HOME.
Am I clear? :-) I am not saying JAVA_HOME should be set to /usr/lib/java,
I am saying that /usr/lib/java could be created as alternative to be used
as default value for JAVA_HOME within programs.
But if you think that my configuration is broken, and ant shouldn't need
JAVA_HOME, then I'll try to fix it myself. Actually I think I already
fixed it by removing the JRE and re-linking the different alternatives to
the JDK (but I don't notice because JAVA_HOME is defined in my Makefile).
Eric
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
tags 283557 + wontfix
thanks
Mon, 29 Nov 2004 22:02:06 +0100,
Eric Lavarde [EMAIL PROTECTED] wrote:
Hi,
Hi,
my suggestion would be to define the directory /usr/lib/java as default
java-home, so that someone can define a default value for the variable
JAVA_HOME, which some utilities seem to require.
I think of something like the following in a shell script:
${JAVA_HOME:=/usr/lib/java}
,[ /usr/share/doc/debian-policy/policy.txt ]
| 9.9. Environment variables
| --
|
| A program must not depend on environment variables to get
| reasonable defaults. (That's because these environment variables
| would have to be set in a system-wide configuration file like
| `/etc/profile', which is not supported by all shells.)
| [...]
`
Which program does need JAVA_HOME? and why? IMHO this is not a clean
design.
Cheers,
PS: If someone else wanna take care of this bug, just remove the
'wontfix' tag.
--
Eric de France, d'Allemagne et de Navarre
