Re: RFS: cobertura (updated package, new upstream release for a package already in Debian)
Hi Miguel, On Sun, Mar 7, 2010 at 5:42 AM, Miguel Landaeta wrote: > - Vcs-Git: git://git.debian.org/svn/pkg-java/cobertura.git It is /git/ not /svn/ ;-) > I would be glad if someone uploaded this package for me. done Thanks, Torsten -- 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/a90bfcf1003091350w6910acedj42073fd35405d...@mail.gmail.com
Re: RFS: maven-scm and others
Hi Gabriele, On Tue, Mar 9, 2010 at 1:36 AM, Gabriele Giacone <1o5g4...@gmail.com> wrote: > I've packaged maven-scm 1.3 (current 1.2). > Could anyone review and upload it? uploaded > maven-enforcer NEW > http://mentors.debian.net/debian/pool/main/m/maven-enforcer/maven-enforcer_1.0~beta2-1.dsc It needs a newer maven-site-plugin which does not build for me. May you check it, please? > maven-doxia-tools 1.2 (current 1.0.2) > http://mentors.debian.net/debian/pool/main/m/maven-doxia-tools/maven-doxia-tools_1.2-1.dsc uploaded Thanks, Torsten -- 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/a90bfcf1003091341u3d37617dgf164da1028cb...@mail.gmail.com
Re: EPL + LGPL compatiblity?
Pablo Duboue wrote: > Hi, > > We seek some advice regarding #572982 [1] (azureus, a well-known torrent > client, combines source licensed under incompatible licenses). > > From Niels quoted sources, there is no doubt about the incompatibility of GPL > and EPL. But LGPL and EPL might be a different matter and Google has proved > quite unfriendly on this regard. I think that the LGPL v3 is compatible with the EPL. The LGPL allows you to convey combined works as long as you can recompile the LGPL parts. Since we have the source for everything, this is not a problem. Cheers, Walter Landry wlan...@caltech.edu -- 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/20100309.043452.761058721790309809.wal...@geodynamics.org
Re: EPL + LGPL compatiblity?
Le Tue, Mar 09, 2010 at 02:03:31AM -0500, Pablo Duboue a écrit : > > We seek some advice regarding #572982 [1] (azureus, a well-known torrent > client, combines source licensed under incompatible licenses). > > From Niels quoted sources, there is no doubt about the incompatibility of GPL > and EPL. But LGPL and EPL might be a different matter and Google has proved > quite unfriendly on this regard. > > Any advice on the matter will be highly appreciated. Dear Pablo, It looks like Aelitis/Vuze is the copyright owner of most of the GPL'ed code, so the quickest way to solve the problem may be to ask them to add a license exception to allow combining their code with the co-distributed EPL and CPL-licensed sources. I hope others will correct me if I am wrong, but it seems that the CPL does not forbid the program to be linked with works under other licenses, so exception is only needed on the GPL side. According to debian/copyright, this leaves two files to either replace or get relicensed by their authors: Files: com/aelitis/azureus/core/peermanager/utils/BTPeerIDByteDecoder.java Copyright: 2003-2006, Aelitis 2002-2004, Alon Rohter License: GPL-2+ Files: org/gudy/azureus2/core3/util/BrokenMd5Hasher.java Copyright: 2005, jMuleGroup License: GPL-2 Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20100309111524.ga28...@kunpuu.plessy.org
Re: Reasonable values for the -Xmx parameter ?
On 03/08/2010 11:11 PM, Vincent Fourmond wrote: > Pablo Duboue wrote: >>> All right... >>> >>> Then, maybe I could add a function to java-wrappers that would find >>> out what is a 'good default' for that parameter, getting something more >>> than the memory required but still reasonably less than the memory >>> present on the machine ? >> >> If you want to go in that direction, you might want to add also >> pointer compression in AMD64 (-XX:+UseCompressedOops), which makes a >> huge difference with respect to minimum heap sizes in AMD64. Otherwise >> what it's OK for 32-bits might be way too little for 64 bits. >> >> http://wikis.sun.com/display/HotSpotInternals/CompressedOops >> http://java.sun.com/javase/6/webnotes/6u14.html >> >>> Would that be useful for anyone else than me ? >> >> I find it difficult to imagine how would you automatically determine >> the heap size based on the ideas you sketched in your earlier >> comments. If what you propose actually solves the problem, then you >> can actually write a patch for upstream to do that within the JVM :-) >> :-) > > My idea would be something just like "all the memory minus a bit", > which would make java apps behave somehow like the other programming > languages with respect to memory allocation. > > The reason why this isn't done by default in the JVM (and why it > definitely shouldn't be done that way) is that the JVM puts a strong > emphasis on security: setting a limit on the resources a web applet can > take seems like a good idea. No, that's not the main reason. It's done that way because the heap is contiguous, so has to be pre-allocated. The key issue here is the setting of vm.overcommit_memory and vm.overcommit_ratio. If you set the ratio large enough you can allocate a large heap without any problems. Andrew. -- 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/4b9615e4.1090...@redhat.com
