JServ www-data CPU usage
When I start up I have www-data running a process that consumes up to 90%+ of my CPU time - and I cannot connect to the servlets. This started happening after I changed /etc/jserv/jserv.properties to try to add a LD_LIBRARY_PATH - with incorrect syntax. I have now removed my change to that file but have still knackered JServ - even after a full reboot of the computer. Is there something I could have done with that properties file that would cause this? Could editing it have messed up permissions? Any ideas? Many thanks, James
Re: Java libraries and proposal.
On Sat, Apr 07, 2001 at 07:47:29PM -0700, Per Bothner wrote: > I disagree. My goal is that that /usr/share/java (or > /usr/share/java/lib if you prefer) should be similar to Sun's > extensions directory: a directory where *all* .jars > (i.e. /usr/share/java/*.jar) are added to the implied classpath. > (This is of course a default assuming nothing is over-ridden.) Yes, > you could define a standard where all .jars in all subdirectories of > /usr/share/java (i.e. /usr/share/java/*/*.jar) but I think that is > going too far. I think explicitly specifying the .jars you want to import into your library or application, with sonames if necessary, seems better. The 'add everything' approach only invites DLL hell. The list of jars (basically equivalent to CLASSPATH) could simply be stored in a jar member or attribute, and the .so versions could use plain old library dependency information. Class visibility for applets and servlets would of course be handled by the browser resp. server involved rather than use the same mechanism as for applications. > Anyway, I think using Extension-List or something similar should be > a refinement for the future. For now applications that want special > library versions should install a shell script that sets the CLASSPATH > to include the preferred jar file versions. This really ought to go in the first version. Then there's no need to import the whole /usr/share/java directory at all. > Well, each VM is responsible for setting its own builtin classpath. This sounds reasonable, but there might be a problem with things that depend on certain versions of the basic java libraries. > Unless they have trademarked "javac" they don't get to say what gets > run when a user types it. The only relevant license issue I know about > is about re-distributing jdk but only as long as no part is "replaced". If this is an issue 'javac' can simply say it will only run with the jdk jvm. -- James Deikun, Techie(tm), CSI Multimedia The opinions expressed &c.
Re: Java libraries and proposal.
On Wed, Apr 11, 2001 at 12:32:12PM -0700, Per Bothner wrote: > That is fine for nicely-packaged libraries and applications. However, > I'm concerned about a random Java programmer who should not have to > manually fiddle with their classpath. Such programmers should be able > to write Java code without having to know which jar is where. Also, > if each application has to specify jars, then you also complicate the > life of people developing such applications. Hence, I feel the > 'add everything" approach is a reasonable default. The programmer would just specify the name of the jar, like with the C compiler's -l flag. Some think the hierarchical class/package namespace makes that sort of thing obsolete, but I don't buy it. C++ has namespaces, but you wouldn't default to linking your entire libdir to every C++ application unless it said otherwise, even with a lazy dynamic linker. Java shouldn't be any different in this sense. (Yes, I'm aware that I'm ignoring certain issues in how a dynamic linker would find a C++ class in an .so compared to how a JVM would find a .class in a .jar, as well as some issues of namespace coordination. It's not that I'm unaware of them or think they'd make no difference. I just don't think they'd make ENOUGH of a difference, qualitatively, to make add-everything the Right Thing for Java but not for C++.) I wrote: > > The 'add everything' approach only invites DLL hell. Per Bothner continued: > Well, first this is what Sun does, at least to some extent, with the > "extensions" mechanism. How very unfortunate. > Secondly, DLL hell as I understand it is a completely different problem, > due to lack of support for multiple versions of a library, and applications > installing a version they need without consideration for other applications. If an application were to install a new, incompatible version of a .jar library, even with a version of add-everything that prioritised multiple versions so that only one would be used, all the 'informal' applications that were using the old version implicitly would break when the new version was installed. Basically, for applications that didn't declare a dependency on a particular library version it would be as if the support for multiple versions didn't exist at all, thus dragging them into DLL hell. I see no problem with an end-user script to run unpackaged applications in a 'fat' library environment (although I'd never use it myself, too slow), but if you encourage people to put sloppy stuff like that in '/usr/bin' what you end up with perfectly satisfies the above definition of 'DLL hell'. Packaged, or even plain released, libraries and applications should be encouraged to specify what they really need, and to construct proper (versioned!) dependencies for the release .jar when it is built, just like the link step for any other compiled application or library. -- James Deikun, Techie(tm), CSI Multimedia The opinions expressed &c.
Re: Java libraries and proposal.
On Thu, Apr 12, 2001 at 02:06:33PM -0400, Jeff Sturm wrote: > However I like the idea of a Class-path: entry in the MANIFEST, to list > dependencies by name. If an application is built as a .jar, it can have a > Class-path: too. Then the linking mechanism is similar to ELF shared > objects, and can easily be managed in parallel with classes natively > compiled by gcj. (I'm imagining utilities like `ldd' that would find and > print all the dependent jar files for a Java application. That would be > so nice to have now.) I have nothing really to add here, but this is exactly the sort of thing I was thinking of. If only I could have expressed it this well and precisely. Until someone can think of a method of dynamic library management that at least /looks/ like it could handle the complex problems of versioning and the overhead of a large number of libraries better than current best practices it's best to stick with them and not be led by whatever the reference implementation of Java does even when that behavior is not in the spec. -- James Deikun, Techie(tm), CSI Multimedia The opinions expressed &c.
JServ www-data CPU usage
When I start up I have www-data running a process that consumes up to 90%+ of my CPU time - and I cannot connect to the servlets. This started happening after I changed /etc/jserv/jserv.properties to try to add a LD_LIBRARY_PATH - with incorrect syntax. I have now removed my change to that file but have still knackered JServ - even after a full reboot of the computer. Is there something I could have done with that properties file that would cause this? Could editing it have messed up permissions? Any ideas? Many thanks, James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Java libraries and proposal.
On Sat, Apr 07, 2001 at 07:47:29PM -0700, Per Bothner wrote: > I disagree. My goal is that that /usr/share/java (or > /usr/share/java/lib if you prefer) should be similar to Sun's > extensions directory: a directory where *all* .jars > (i.e. /usr/share/java/*.jar) are added to the implied classpath. > (This is of course a default assuming nothing is over-ridden.) Yes, > you could define a standard where all .jars in all subdirectories of > /usr/share/java (i.e. /usr/share/java/*/*.jar) but I think that is > going too far. I think explicitly specifying the .jars you want to import into your library or application, with sonames if necessary, seems better. The 'add everything' approach only invites DLL hell. The list of jars (basically equivalent to CLASSPATH) could simply be stored in a jar member or attribute, and the .so versions could use plain old library dependency information. Class visibility for applets and servlets would of course be handled by the browser resp. server involved rather than use the same mechanism as for applications. > Anyway, I think using Extension-List or something similar should be > a refinement for the future. For now applications that want special > library versions should install a shell script that sets the CLASSPATH > to include the preferred jar file versions. This really ought to go in the first version. Then there's no need to import the whole /usr/share/java directory at all. > Well, each VM is responsible for setting its own builtin classpath. This sounds reasonable, but there might be a problem with things that depend on certain versions of the basic java libraries. > Unless they have trademarked "javac" they don't get to say what gets > run when a user types it. The only relevant license issue I know about > is about re-distributing jdk but only as long as no part is "replaced". If this is an issue 'javac' can simply say it will only run with the jdk jvm. -- James Deikun, Techie(tm), CSI Multimedia The opinions expressed &c. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Java libraries and proposal.
On Wed, Apr 11, 2001 at 12:32:12PM -0700, Per Bothner wrote: > That is fine for nicely-packaged libraries and applications. However, > I'm concerned about a random Java programmer who should not have to > manually fiddle with their classpath. Such programmers should be able > to write Java code without having to know which jar is where. Also, > if each application has to specify jars, then you also complicate the > life of people developing such applications. Hence, I feel the > 'add everything" approach is a reasonable default. The programmer would just specify the name of the jar, like with the C compiler's -l flag. Some think the hierarchical class/package namespace makes that sort of thing obsolete, but I don't buy it. C++ has namespaces, but you wouldn't default to linking your entire libdir to every C++ application unless it said otherwise, even with a lazy dynamic linker. Java shouldn't be any different in this sense. (Yes, I'm aware that I'm ignoring certain issues in how a dynamic linker would find a C++ class in an .so compared to how a JVM would find a .class in a .jar, as well as some issues of namespace coordination. It's not that I'm unaware of them or think they'd make no difference. I just don't think they'd make ENOUGH of a difference, qualitatively, to make add-everything the Right Thing for Java but not for C++.) I wrote: > > The 'add everything' approach only invites DLL hell. Per Bothner continued: > Well, first this is what Sun does, at least to some extent, with the > "extensions" mechanism. How very unfortunate. > Secondly, DLL hell as I understand it is a completely different problem, > due to lack of support for multiple versions of a library, and applications > installing a version they need without consideration for other applications. If an application were to install a new, incompatible version of a .jar library, even with a version of add-everything that prioritised multiple versions so that only one would be used, all the 'informal' applications that were using the old version implicitly would break when the new version was installed. Basically, for applications that didn't declare a dependency on a particular library version it would be as if the support for multiple versions didn't exist at all, thus dragging them into DLL hell. I see no problem with an end-user script to run unpackaged applications in a 'fat' library environment (although I'd never use it myself, too slow), but if you encourage people to put sloppy stuff like that in '/usr/bin' what you end up with perfectly satisfies the above definition of 'DLL hell'. Packaged, or even plain released, libraries and applications should be encouraged to specify what they really need, and to construct proper (versioned!) dependencies for the release .jar when it is built, just like the link step for any other compiled application or library. -- James Deikun, Techie(tm), CSI Multimedia The opinions expressed &c. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Java libraries and proposal.
On Thu, Apr 12, 2001 at 02:06:33PM -0400, Jeff Sturm wrote: > However I like the idea of a Class-path: entry in the MANIFEST, to list > dependencies by name. If an application is built as a .jar, it can have a > Class-path: too. Then the linking mechanism is similar to ELF shared > objects, and can easily be managed in parallel with classes natively > compiled by gcj. (I'm imagining utilities like `ldd' that would find and > print all the dependent jar files for a Java application. That would be > so nice to have now.) I have nothing really to add here, but this is exactly the sort of thing I was thinking of. If only I could have expressed it this well and precisely. Until someone can think of a method of dynamic library management that at least /looks/ like it could handle the complex problems of versioning and the overhead of a large number of libraries better than current best practices it's best to stick with them and not be led by whatever the reference implementation of Java does even when that behavior is not in the spec. -- James Deikun, Techie(tm), CSI Multimedia The opinions expressed &c. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: JDE
>>>>> On Tue, 3 Aug 1999 09:15:29 +0200 (CEST), Andreas Tille <[EMAIL >>>>> PROTECTED]> said: Andreas> On Tue, 3 Aug 1999, Ruud de Rooij wrote: >> > No, I think this is the right behaviour. The only thing which >> > would make sense could be, that the ~/.emacs files of each user >> > could be scanned and the line could be added as comment with a >> > describing text. So each user could be informed about the >> > installed packages. I think that not all users parse the >> > database of installed programs every week and read the according >> > docs. But this would be much more effort in the installation >> > scripts. >> >> This sounds like something that needs to be coordinated between >> all emacs and emacs add-on packages maintainers. You could bring >> it up on [EMAIL PROTECTED] Andreas> Is someone subscribed to this list and could foreward this Andreas> idea, please. Of course, only if he thinks that this is a Andreas> good idea ... Messing with a user's config files is generally a bad idea, but it might be nice if all emacs package maintainers added something like a /usr/doc/example.emacs file to their packages so that there was a simple place for all these config statements to go and be found. (This is assuming that autoloads won't work or are a bad idea in a /etc/(x)emacs/site-start.d/*.) Dres PS: crossposted to the emacsen list to get feedback from there. -- @James LewisMoss <[EMAIL PROTECTED]> | Blessed Be! @http://www.ioa.com/~dres | Linux is kewl! @"Argue for your limitations and sure enough, they're yours." Bach
Re: A packaging scheme...
>>>>> On Tue, 28 Sep 1999 12:12:44 -0500, "Ean R . Schuessler" <[EMAIL >>>>> PROTECTED]> said: Ean> Instead of org.gnu.regex.Regex you might have Ean> lgpl.regex.Regex. The nice thing being that you wouldn't see Ean> anything in lgpl.* linking in something from gpl.*, because that Ean> would break the license. There are some disadvantages, Ean> obviously, but the process of linking is tightly coupled with Ean> copyright licenses and is also less politically charged than Ean> organizational attributions. This way, when someone takes over a Ean> piece of code perhaps they will feel less inclined to completely Ean> change the package the code lives in to their specific Ean> organization. What if I want to release a regex package under the lgpl. Should I have to rename mine so that it doesn't conflict with gnu's? This seems like it would place a large burden on different organizations not to step on each others toes. So much that I can't imagine anyone actually following it. I certainly don't want to deal with conflicting with Joe Random java programmer's gpled util.ByteTools with my own. Jim -- @James LewisMoss <[EMAIL PROTECTED]> | Blessed Be! @http://www.ioa.com/~dres | Linux is kewl! @"Argue for your limitations and sure enough, they're yours." Bach
Re: A packaging scheme...
>>>>> On Tue, 28 Sep 1999 22:27:51 -0500, "Ean R . Schuessler" <[EMAIL >>>>> PROTECTED]> said: Ean> On Tue, Sep 28, 1999 at 07:37:12PM -0400, James LewisMoss wrote: >> What if I want to release a regex package under the lgpl. Should >> I have to rename mine so that it doesn't conflict with gnu's? >> This seems like it would place a large burden on different >> organizations not to step on each others toes. So much that I >> can't imagine anyone actually following it. I certainly don't >> want to deal with conflicting with Joe Random java programmer's >> gpled util.ByteTools with my own. Ean> Right, but thats exactly what I'm talking about. It would be Ean> convenient to have a consolidated system on the order of Ean> libc. There are many packages that provide functionality that is Ean> similar to libc but eventually those libraries are consolidated Ean> into a single library that people can count on. This would be a Ean> free software equivelent to the java base classes that is a Ean> single managed and coordinated framework. The final product Ean> should be similar in spirit to libc. Hmm. So you envision a stdc type add on to the standard java.* heirarchy... Put that way it's not such a bad idea. Course I don't think it's polite to change someone else's code to fit into this hierarchy. Where they put it in the package space is where it should remain. (Not that you can't convince them that the org.gnu space is good, but Debian shouldn't take it upon itself to change java packages this way.) (IMO of course) Dres -- @James LewisMoss <[EMAIL PROTECTED]> | Blessed Be! @http://www.ioa.com/~dres | Linux is kewl! @"Argue for your limitations and sure enough, they're yours." Bach
Re: [ITS] Re: RFS: args4j/2.0.25-1 and jenkins-remoting/2.23-2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 24/10/13 23:48, Emmanuel Bourg wrote: >> Could you push your pristine-tar branch? It's missing the 2.23 >> version. > > I already pushed all my branches. I guess James forgot to push it? Apologies if I missed this - I pushed all my local branches just to be sure. > Thank you for all the uploads Tony. Yes - thankyou! Apologies if I've been a bit unresponsive on IRC/email; working/travelling at the moment so have not had much time spare. - -- James Page Ubuntu and Debian Developer james.p...@ubuntu.com jamesp...@debian.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSarIBAAoJEL/srsug59jDUKsQAKWHdkl50tNGuXlujlPeEohJ veqP2f/N+IIvgYY4wsHxTooP1HCIui8fwg0UjJbm2PiqqKaSOExUwciOBT5BQU2l M35l0qYMPtlqRiwyhzUgEVIkQYqKMLP4Wlr2ftXdgq2AfDVXo0q/lw1VbOlr2fD+ BSRiRxKHXqiOBDozMhWP6jMJRM1qHX2rI9r9VvnAEt/HZWM9u+XubLXS8SZ5DJBN /WCm5KY6KmWItUAsqj7+6YCy+zfMkro9Ha6QtNYi5p1NYoLTUOq2UgwNruJaM5a4 9wvAH8Q31L4jAhnHyjldj8IVOXXKLzrqtllvBqIbJ1zPeTuZ4fsvuPRCcnupS+dN qqQqOmS6nlPpBC303zgm0L+Y0XnetaIFM4jQtQyPHGgArkeUZYlHZfR34y2N+TrN HYV07O+FMGwGi7pwtM9NospyhyEsOBwosXqaCGBb3uLtyex7RbH10dVFfKxK7WD8 rJ5HrkflL0uVH0CXifmJYMxLKbXTFSvxrLLDyPwlS4HkftBbVHU1NeyVDNf0RTe3 gbBBL5JzL/Du2w0aa/rNr0I42kToTCHNkC5HjT9AAsWAMl4s+sZUOW6JY+t4qFai AZ1dfHom2uSJpKjcvP4rUvENEKuIaX0BlPO3D4L3DdNl5aKTlPib4/PehkDgz5xv FLwrqwmYwM61ZjPaM2fi =+Tp9 -END PGP SIGNATURE- -- 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/526ab205.9080...@ubuntu.com
State of Jenkins in Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Team I'm writing here first before I file a formal RFH or O in the hope that someone in the team might have the capacity to take up the mantle of maintaining Jenkins in Debian. I've found myself with increasingly less time to spend on Jenkins; my day-job has changed focus quite a bit in the last 18 months so in-hours time on Jenkins is limited (if non-existent) and with a growing family, I've not much time other than that right now. Which reading that back is pretty much 0 time. I'm also concerned about where Jenkins could be realistically maintained in a stable Debian; Upstream move fast (LTS release every 3 months) and I've found that unless you understand the inside of Kohsuke's mind, trying to backport to older releases is extremely time consuming/if not impossible. I'm also not sure how useful the packages are; alot of sites I would expect to use the Debian package don't - jenkins.debian.org for example. Can't really blame people - its different to upstreams packaging in terms of how its built and what it ships with. With these three things in mind, I'm considering orphaning the package and requesting its removal from both Debian and Ubuntu. Cheers James - -- James Page Ubuntu and Debian Developer james.p...@ubuntu.com jamesp...@debian.org -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTFeUuAAoJEL/srsug59jDj8QQALl1s+XJurol/lVr6PSeZk8k piMTnW0deQ3RZ+WaBHY3g8HbA2zN4o4LfZADu0b9Vyv25j4wRCA2+Zj5hgZ7tGW1 5q4c7HpcGt2XpQYOMrrpf8Eaq0v0dW4uXlJVjpa4uZdF5F2Rr+gsuMDUymivCAj1 aduuUNQPQIJAXYyuBanKmXpl5FmqgN3zBPNcafHblkbBFit6pzPP+cOcYjcjz3mV 9SNGrxREBx1GKhdHKVOlHLxiByxnpre/gPdFr/RmXpn8XKwqQhk+jNUQ6m3E2Mtj i43mCc/ZAUMX660uF9IUeKcH6vcumQtBXf7S/JUJSYjD18LjXgkWmdH3D/P+BJUY 4xa9hRR4WkyvQ+TBCxJUfBzstEF1Wf1uASkptJrbS/g3Pdm8YtfqcIp0GHzFNDv+ +OqQTLiEzD4FsObG1h47zfAkICHiOdSxHsUDC2oEjlwhkXVIH457sPGkYApeWw9i WXHpCuJc5GwdwuyTRiVAjmbBdlXQekvSW2ysb3tss8cBYOY3KtkWR61ZsMWt0+Zf +IMjm817ITDQ+wL0FcPma4SuO6Rm0lgcZ9lwNPRlm/UEzynuckeNd8/rH6IrgZK7 BoKoyuk0nLK0/nbRC1PJ1Qv9gYZhE9xlRq+A7f5O9NtXZrrAeTF8xHFVl/x2ulhE Z6xpxZF5uoPsbLi5RJf2 =xOQa -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5315e52e.4060...@ubuntu.com
Re: State of Jenkins in Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/03/14 21:58, Stephen Nelson wrote: > On Tue, Mar 4, 2014 at 2:37 PM, James Page > wrote: >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 >> >> Hi Team >> >> I'm writing here first before I file a formal RFH or O in the >> hope that someone in the team might have the capacity to take up >> the mantle of maintaining Jenkins in Debian. >> > > Hi James, > > I hope that Jenkins can be kept in Debian, as I think it's an > extremely useful piece of Java software that many developers > interact with on a daily basis. > > I don't have the experience in packaging to take on the package > myself but would be interested in assisting the effort if other > more experienced members in the Java group would lead. > > With regards to the complexity of Kohsuke's mind, is the task made > easier by the fact that the software is already packaged and > therefore the most difficult task has been achieved, or are there > difficult tasks added on every version bump? The challenge is that between stable releases, jenkins changes alot; so say we shipped the current stable release on release day - in +3 months time the codebase will have potentially changed so radically, backporting security or critical bug fixes because very time consuming; I've also found that sometimes this also required new dependencies to be packaged. - -- James Page Ubuntu and Debian Developer james.p...@ubuntu.com jamesp...@debian.org -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTHwTiAAoJEL/srsug59jD8BoP/3Tevv4QiWfbftrTmrkOtjWY ms2zB3kSa0cSs3KbvibAg9BS+alQ2ofc6rs2SfYcpyP0P2AiUVKLTAeLpxQyWBTy jtlOjF6X/axe1Hhw0JFtrQhhJumTsJt7sTl0CUpiC/NhPxo5ypYM2RCWEdA6POwq GLRtVzOueq42k2AGwQxJp6EW/kH/uSCkc9KlYqAI2m6adoUkjtoLAYYGAqpt+PAH tLZFHdhLAVwG7Cvo7ZAvSmJ+UPasyyMtHJaA5IJbD9gjlU9dxLC/2i/vXkFusdY4 1rwmebpeIGse8XGD0VOMH9jGILYyPJcoSnqKXeK+X+a9O/8jtM8TmSnBSJeYEXFk Oa0rot0Wh/Oc2qK7k3o6S/6ef6AmHkYiU5VbjJ8nnMFyzH0rYaWFUSaAjS/YknS/ NMg5M2zJIphAio3MJfSkvAsjc/yj97GdJS17xGQNHQErLsmcesVc4BFlU9CJD/PA kfaLMoQ6EEohEKKWTOVow+DLyW9dSF3QxbbtrEekbfmzvtzMuHE9s44DvhsA9d16 UH+/nlA9Io/OEox+lVVAzgKcLK6SMtkXyr/NFFfAcwCEiux4A7bkXfC4h6D2wku1 Tp6t8rP1FGc1oVKjvn2YWBaaUQiwg+7YcJyQgPOdGhVEHyZRX/7vUxV8oLyk6Kt/ Tj67MbjEZ8ztogku/HF3 =iFCC -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/531f04e2.5090...@ubuntu.com
Re: zookeeper FTBFS with gcj as default-jdk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 25/03/14 00:09, Emmanuel Bourg wrote: > Le 23/03/2014 22:12, Tim Retout a écrit : > >>> What's the right thing to do when Java packages can only build >>> against openjdk-7-jdk, and not gcj? > Hi Tim, > > gcj is stuck with Java 5 and no longer supported upstream. It's > nice if a package still works with gcj, but it wouldn't be > reasonable to invest more energy into supporting it. This energy > would be better spent on porting openjdk to these architectures. The versioning on the BD for default-jdk used to exclude architectures less than Java 6 (gcj or otherwise): default-jdk (>= 1:1.6), I guess that's not working so well now - it needs an epoch bump: default-jdk | 2:1.5-51 | jessie | kfreebsd-amd64, kfreebsd-i386, sparc default-jdk | 2:1.5-51 | sid | hurd-i386, kfreebsd-amd64, kfreebsd-i386, sparc default-jdk | 2:1.7-51 | jessie | amd64, armel, armhf, i386, mips, mipsel, powerpc, s390x default-jdk | 2:1.7-51 | sid | amd64, armel, armhf, i386, mips, mipsel, powerpc, s390x - -- James Page Ubuntu and Debian Developer james.p...@ubuntu.com jamesp...@debian.org -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTMU8UAAoJEL/srsug59jDTdYQAJMnPoDVonVAXFlWJpHcqgcf kgJrzX+HbL4Ys/dAT6UCNeXv7dj2fhz0lMg1gaF6fhPcNZixqV3zM8OZeO1O2bDD WCsi5eeyk4Pm4A+aTZWB6fxtB56Hs3Fv44SS/0ObEqOE0U39NtOgcUXkOl79bre9 905zwFcbQyuY+87ChpDsPwB2627lKiJcba/DKJROyXoc2g+GD7tKbYP2crrcSX6M AL89lMwKCUC5HidyaI8/FSPvWZaoptemZaVK+1MXQ1c7JW7gj5ulHjpfD7LIY1Nf ffrXLAnH1E6426LrOW/5AoMu67ybTgap5DUMx57rfZzN2JXl24zQFUDZTPxpCcTn nWogi7TefcLDIQC+E++O2a1O10ZCYKk/XsCmAYYvNlr7bEfqsVj6IpoCeAOyjflR MkcY7yFYrdrXoNAC8r6qBzFFBMBFWG5MyL9HWOtDr6ahnyBXsde/wpNZE58cUq7X yU9Bvs75Y4HYAwjjASKaNNB1HM07ModMlyJPulinA4OZd0bQP/gWV3BNynVZYfSz fnhNe2I2IIqQUvPrfVwf23GLOwZZnFfJD8PoSOpfpqiJkqk1tljWLv+EanBQy0E4 qXjmU/OUw1H9b/DVRBUTxK6rp8vGQDhPWjfCBJwWSCkQtXvdtU9Juwa8i5VWi8u2 ORVCRnjZo/mXWRI2nJdj =pWuh -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53314f14.30...@ubuntu.com
Re: zookeeper FTBFS with gcj as default-jdk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 25/03/14 09:40, James Page wrote: > On 25/03/14 00:09, Emmanuel Bourg wrote: >> Le 23/03/2014 22:12, Tim Retout a écrit : > >>>> What's the right thing to do when Java packages can only >>>> build against openjdk-7-jdk, and not gcj? >> Hi Tim, > >> gcj is stuck with Java 5 and no longer supported upstream. It's >> nice if a package still works with gcj, but it wouldn't be >> reasonable to invest more energy into supporting it. This energy >> would be better spent on porting openjdk to these architectures. > > The versioning on the BD for default-jdk used to exclude > architectures less than Java 6 (gcj or otherwise): > > default-jdk (>= 1:1.6), > > I guess that's not working so well now - it needs an epoch bump: > > default-jdk | 2:1.5-51 | jessie | kfreebsd-amd64, kfreebsd-i386, > sparc default-jdk | 2:1.5-51 | sid | hurd-i386, > kfreebsd-amd64, kfreebsd-i386, sparc default-jdk | 2:1.7-51 | > jessie | amd64, armel, armhf, i386, mips, mipsel, powerpc, s390x > default-jdk | 2:1.7-51 | sid | amd64, armel, armhf, i386, > mips, mipsel, powerpc, s390x Fix pushed to the git repo. - -- James Page Ubuntu and Debian Developer james.p...@ubuntu.com jamesp...@debian.org -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTMU+xAAoJEL/srsug59jDyWEP/0xtqSXZGnhGUKp10h3HUD0T L3hsPld/OC88vbRZqEzKbtxdTMXeY96r3wEpV4DFgnx5n+N9pjlhILe4ubI7XDqQ eVnMA8IxT97oMlDp6ZqKZbCPkGxlWoYLMORA97yzATJQlpTDTfSpsCDjnnu2AU4w +HTgWSDnHKM8SUMu0fm8eEsLXa+kRCoaTT0Wy4jvSq0fQCXK0hin2pyoD+jNbhgk zk9cU1z2L2mo+NLQbmoIJF58J/qbGNuWuBR+VJPB7G61/eQD1eT22s7nE8Uqc1iv 6nyfKZmfsis0YJ5mbp6bZmf5Dxx75bD1J192f6cD34PEmAgUZS60C9H+FCQ1vLdh H3RAhlMBpF/g0TU/EbwhvK6fW/PK4SyLkfP7oNyvSDnlSr76NTQtsd/OQXNSnZwW n8zxSql4HT5qqXhD7Us7AzWKLifefuQL17GATsyZmK1SLO9hgVVUIjA2k96OjoML 6Klhh2YdCUtOi+Wif9dQLsLy9Q/99PIghumzHKPt7FTl0P4fN72eRPoJkZMQMElz jlnW8JS3DTvpq78KBUDpxzBWFu4k0RhYOgCci+RWIFiDh3GdCgRjVkrdPAV9ciOS vU8obXwOEbwTavMbzSBtJN1vgk5qwqER0q2+goITHqhIa7k1gWkymc2SRMXO6XBN cjzRWB220B0kxdf34y+h =NXMV -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53314fb1.3040...@ubuntu.com
Re: Merging maven-repo-helper and maven-debian-helper
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Emmanuel On 29/06/14 21:45, Emmanuel Bourg wrote: > I'm thinking about merging maven-repo-helper and > maven-debian-helper into a single source package to make the > updates easier (they are closely tied and often updated together). > The binary packages produced would remain distinct, so this won't > impact the packages depending on them. Is there any objection to > this change? I think I'll merge maven-repo-helper into > maven-debian-helper, I'll ensure the change history is preserved. > The resulting source package would be named maven-debian-helper or > simply maven-helper, I'm still pondering. - From an Ubuntu perspective, I'd prefer that these two package not be merged; maven-repo-helper is not currently built or depends on Maven in any way, and is used by several Java packages in Ubuntu main to produce/install maven artefacts. maven-debian-helper, which is dependent on Maven, is in Ubuntu universe as the effort required to review and support Maven in Ubuntu main has blocked its entry into main - infact its actively avoided and Ubuntu carries several deltas to Java packages in Ubuntu main to switch build systems away from Maven. So to avoid a) having to maintain forks for mdh and mrh in Ubuntu or b) having to try to persuade the Ubuntu security team to review the 100's of packages that putting Maven into main would mean I'm a -1 on this proposal. Cheers James - -- James Page Ubuntu and Debian Developer james.p...@ubuntu.com jamesp...@debian.org -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTsYUWAAoJEL/srsug59jDdmgP/1Bruk0wCb/33lsA8ZLEQAJj c2SNvNQJ9HHVAL33tA4cs8bGO7M/qEs2WNXbrYmfFWGqs3kWAZokwT1ioBxcAQPQ eTOxW68f87Ckdg3jM3qH6v2bnM4oR7POSmxjdUoJlQ7u1TV0RNsW25mKdYHhQdhW MCj5QI1ZZqKqjbxI10szUzIO+N+B4u9skXnf9uVyE9so2yT3fZt71PdsjVQteS4m xfcdHWU4gqed/epRtLbd7kdjLUba3EykrNHgUZwauTB17p6RqJ+wNCW8oQEOa8Wi JOSPYwVtuTF8RfqwehSoAgdPUxHGO/oR/JUxSifgoSyZs/7nG3Aa2jqN8HJVehiQ Ty12a5KyJ5Ly+RRmQUh335aBsSnN9YUfbR1E2lA0M6FPtMvniq0Kpj+1QVYZWlRT GQ2cTRHG/EV/6mBjrDIs94+vQWcrrnf+h6cAZJtdlo5FilMv4ZeLvaldpPsljSLT lSyMI+ybpcEH84ZYamQP/t/rs9t5r80rjdoMV2LYS8ZecO6B4TVT3IUXwHSVJxsI T76jQC5Q6hCezqWLI1vK9drYEwkw/zuTja28RLVsXEui41eEboUDziTgftBNAWcj zm0P/xXUOo4V9AaODEe6DwswHK36YDAoEWnRatwnh4k++FForqrAbw1XqzClGvxP Jwl2/aZ7gjhbBPyIuc7/ =Srsj -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53b18516.1020...@ubuntu.com
Re: Bug#788189: java-atk-wrapper: build depends on openjdk-6 which is going away
On Tue, 2015-06-09 at 14:29 +0200, Samuel Thibault wrote: > Hello, > > James Cowgill, le Tue 09 Jun 2015 10:23:38 +0100, a écrit : > > It's probably better to just depend on default-jdk. > > java-atk-wrapper requires at least java 1.6. I would have tended to > prefer to advertise this as a build-dependency (as 0.33.0-2 does) > than a build failure (as 0.33.0-1 did). That actually makes sense in > the kfreebsd case for instance, whois AIUI default-jdk is gcj, which > is at most java 1.5, but openjdk-7-sdk exists there too. > > What do you think? Firstly I'm not a java person, I just noticed this because the buildds don't like ORed build-dependencies which are partially satisfiable. Eg the freebsd and sparc builds are currently looping and will continue until an admin stops them: https://buildd.debian.org/status/package.php?p=java-atk-wrapper I don't think it is possible (yet) to have a >= dependency on a java version. You could depend on openjdk-7 but you'll have to update it when the default changes. On freebsd the latest version of openjdk-7 failed to build almost 2 months ago: https://buildd.debian.org/status/package.php?p=openjdk-7 Maybe you could ask the java list for the best way to deal with this? James signature.asc Description: This is a digitally signed message part
Re: Active Java packagers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Damien Raude-Morvan wrote: > I'll not attend Debconf but I'm interrested in any effort bringing > Java Policy in a refreshed state. Is there a repo. somewhere to > check current state (beside java-common pakage bugs [1]) ? > I'm not a DD, will not be at debconf and do not have any real packaging experience or a lot of free time. But as a Java developer and Eclipse user, I have an interest in seeing the Eclipse and general Java experience in Debian at its best. If there are small tasks I can pick off when I have a spare hour or so that would help, I'm more than willing to contribute. If there are more involved tasks that I can dive into and someone is willing to hold my hand through the first couple and tolerate my stupid questions, the same applies. Cheers, JT - -- - ---+---- James Tait, BSc|xmpp:jayte...@wyrddreams.org Programmer and Free Software advocate | VoIP: +44 (0)870 490 2407 - ---+ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKNuCRyDo4xMNTLiYRAlsKAJwJbYaT7wpv1GqaHL+ZgVX/lCK5iwCfXiIg bBUzGdt5++fHRnzF8+gYzk8= =KQaP -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Setting goals for Wheezy
Hi Appreciate that I have been *absolutely* silent on this mailing list since I joined but I would like to get more involved in Java packaging for Debian and have a few opinions on some of this thread. On Tue, 2011-02-08 at 17:07 +0100, Torsten Werner wrote: > - Ship more pom files. +1 on this for me. Maybe installation of Maven artifacts into /usr/share/maven-repo should become part of the Debian Java Library Policy as it is for /usr/share/java? This would really help out when the Java Libraries in Debian mature to a point where packaging of larger applications such as Jenkins, JEE Apps Servers etc... is feasible as the majority of larger Java projects seem to be using Maven these days. > - Set up a real Maven repo based on our packages. Dak may help, too. This is something that we discussed at the Ubuntu Developer Summit last October in one of the Java Development Toolset sessions. Having this type of service would potentially really help upstreams who are not packaging for Debian align to versions of Java libraries already packaged which could make things much easier going forward. I'd like to help out with these two goals as they fit nicely with some of my downstream objectives for Ubuntu (which I can hopefully feedback to Debian!). Regards James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
Re: Setting goals for Wheezy
On Wed, 2011-02-09 at 00:17 +0100, Damien Raude-Morvan wrote: > - package some CI (Continuous Integration) tools like Nexus, Hudson, > Sonar and > some essentials plugins Hi Damien I've been working on packaging Hudson/Jenkins for Ubuntu since UDS-N in October (see [0] for the associated blueprint). The key support from this came from a number of teams within Ubuntu (and Linaro) who are all using Hudson but where not happy about using the binary distribution provided by upstream. My current objective is to achieve a built-from-source version of Jenkins + selected plugins available through a PPA; As a project it does pretty much everything that makes packaging for a Linux distro hard including branching of dependencies, inactive project dependencies etc... so its taking me more time than I expected to get to the point of actually packaging Jenkins (rather than all of its 60+ missing dependencies - see [1] and [2]). In the long term I would like to take this to the point where its available in the main archive for both Debian and Ubuntu. Not sure what long-term really means yet as I think there will be technical and licensing challenges to get Jenkins accepted into either Debian or Ubuntu but within the next 12 months would be good for me! Regards James [0] https://blueprints.launchpad.net/ubuntu/+spec/packageselection-server-n-hudson [1] https://wiki.ubuntu.com/ServerTeam/Specs/HudsonSpec/HudsonPackages [2] https://launchpad.net/~hudson-ubuntu/+archive/testing -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
Re: Problems with many POMs in the same package
On Thu, 2011-02-17 at 12:04 +0100, Giovanni Mascellani wrote: > The compilation runs without problems, but mh_resolve_dependencies > seems > to be unable to understand that some of the artifacts shouldn't be > searched on the filesystem, because are provided by my package. This > leads it to try some network access, execute some dpkg --search and > then > giving up, generating a messed up dependency string. I've had similar issues with some of the packages I have been working on for Jenkins; the default command for generating the jar files in 'package'; some Java projects require that 'install' is used during the build which drops them into the local maven repo which means that they then get resolved. debian/rules: DEB_MAVEN_BUILD_TARGET := install Not that elegant but generally does the trick for me. Cheers James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
RFS: java-xmlbuilder (new package)
Dear mentors, I am looking for a sponsor for my package "java-xmlbuilder". * Package name: java-xmlbuilder Version : 0.4-1 Upstream Author : James Murty * URL : http://code.google.com/p/java-xmlbuilder/ * License : Apache-2.0 Section : java It builds these binary packages: libjava-xmlbuilder-java - XML Builder Java library for creating XML documents libjava-xmlbuilder-java-doc - Documentation for XML Builder Java library for creating XML documents The package appears to be lintian clean. The upload would fix these bugs: 617526 My motivation for maintaining this package is: this package is a dependency of jets3t (which currently bundles it) and of jclouds (yet to be packaged). jets3t used by the Jenkins ec2 Plugin (which I intend to package alongside Jenkins). The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/j/java-xmlbuilder - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/j/java-xmlbuilder/java-xmlbuilder_0.4-1.dsc - Vcs-Git: git://git.debian.org/pkg-java/java-xmlbuilder.git I would be glad if someone uploaded this package for me. Cheers James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
Re: RFS: java-xmlbuilder (new package)
On Sat, 2011-03-12 at 09:03 +0100, Niels Thykier wrote: > Uploaded to NEW. My only comment is that the doc package does not > recommend on default-jdk-doc; possibly because it is not linked > against > the said doc. Could you please look into that for a -2 or the next > upstream release? > Hi Niels I will check this out and ensure any future packages/updates link against it. Thanks for sponsoring this package James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
Impact of switching to multi-arch on Java & native library handling.
Hi All You may (or may not) know that Ubuntu Natty (the current development release) has started to make the transition to multi-arch based libraries (see [0] & [4]). This basically means that instead of libraries being located in /usr/lib:/lib they are installed to architecture specific locations (/usr/lib/i386-linux-gnu...), allowing libraries for multiple archs to be installed on the same system (i386 and amd64 for example). For the majority of Java code this will have no impact as the JVM abstracts this underlying change away from the developer; however code that integrates with native libraries is potentially impacted by this change (see [1] & [2]). We encountered two separate issues in Ubuntu related to this switch-over: 1) Incomplete library search paths openjdk-6 and libjna-java have both been updated to be multi-arch aware when generating paths for library searching; This was a fairly simple fix but it will need to be expanded to support all of the various architectures that Debian builds for over and above Ubuntu (see [3]). I have submitted the patch to libjna-java back upstream (see [2]) with these comments as anyone using JNA on a multi-arch enabled Linux distro will have this issue. 2) Version-less library names. The second issue (which is not directly related to the multi-arch change) related to how native libraries are typically loaded in Java code. Calls to the loadLibrary function provided by the Java Runtime Environment simply take library names - for example 'pam'. The JVM maps this to 'libpam.so' and then tries to resolve this against the native libraries on the system. This is OK where a library provides both the Java code and the native shared object (without a ABI version number) which should be installed to /usr/lib/jni. However where the Java code is relying on a system library such as PAM this is unresolvable - i.e. the JRE will not be able to load the library as there is no version-less .so available. libjna-java works in a similar way but resolves this issue by 'best matching' the library - i.e. it takes a guess at which version is required and picks the highest one it finds - this is inherently a little dangerous as the Java 'native' code might not map to the version it picks to load. libjna-java also understands versioned libraries and passes these directly to libdl to resolve - 'libpam.so.0' would be handled in this way. This would be a better way to ensure that native Java integration is fixed and tested against a specific ABI version of the underlying native library. The intent of this email is really to: a) give the team a heads-up on issue 1) as I believe Wheezy is due to move to multi-arch. b) generate some discussion around version-less system library handling. Hoping that JNA will match a request for 'xx' to the right version of library 'xx' does not feel like a good thing to be doing. I don't think that this issue is particularly widespread in the Java code-base in Debian or Ubuntu (not many libraries use libjna-java); however I have at least two new packages I want to contribute that use JNA in this way and it would be great to get a consensus on how to handle this in Debian and derivatives. I think that fixing to a particular version of a library is the right way to go - this can be managed using a patch and ensures that ABI compatibility is maintained between the Java library and the native system library for this type of package. Cheers James [0] https://wiki.ubuntu.com/MultiarchSpec [1] https://bugs.launchpad.net/ubuntu/+source/libjna-java/+bug/737603 [2] http://java.net/jira/browse/JNA-184 [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620122 [4] http://wiki.debian.org/Multiarch/ James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
Packaging Jenkins for Debian and Ubuntu
Hi All Over the current Ubuntu development cycle I have been working on packaging Jenkins (nee Hudson) and new dependencies from source against the existing set of Java libraries in the Debian and Ubuntu archives. The packaging is now at the point where its pretty much all built-from-source (aside from one package - see [2] - working with upstream to get that resolved) and is functional on the current Ubuntu development release - indeed Ubuntu QA are using it to execute automated ISO and ec2 image testing for this release (see [4]). To date all work has been done outside of the Ubuntu archive in PPA's (see [3]) - this aligns to the objectives that we set for Ubuntu Natty (see [1]) due to the large volume of packaging work that needed to be undertaken. I have been feeding back any patches to existing Java libraries over the last few weeks (again see [2]) - these have mainly been around enabling Maven artifact deployment. I'm now at the point where I would like to start getting this work into the Debian archive (and then Ubuntu for the next release) so that both distributions can benefit from having this useful tool. As you can see from [2] this is quite a large piece of work; so I'm looking for developers and sponsors to help get the packages into an acceptable state and uploaded into the Debian archive. I've been trying to get in contact with the ITP owner (see [0]) but have not had any response in the last couple of weeks so I'm hoping that the Debian Java team can help me out! I don't think they are far off - I have been as thorough as possible in terms of reviewing licensing etc. However I appreciate that I've been working quite closely with these packages for the last few months and may be blind to any potential issues. Most of the packaging has been built using maven-debian-helper/mh_make so should be policy compliant - its pretty much lintian clean. Thanks for any help you can offer. Cheers James [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561963 [1] https://wiki.ubuntu.com/ServerTeam/Specs/HudsonSpec [2] https://wiki.ubuntu.com/ServerTeam/Jenkins/JenkinsPackages [3] http://launchpad.net/~hudson-ubuntu/ [4] http://jenkins.qa.ubuntu-uk.org/ -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
RFS: libcodemodel-java (updated package)
Dear mentors, I am looking for a sponsor for the new version 2.1-1 of the package "libcodemodel-java". It builds these binary packages: libcodemodel-java - Java library for code generators libcodemodel-java-doc - Documentation for Java library for code generators The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/libcodemodel-java - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/libcodemodel-java/libcodemodel-java_2.1-1.dsc It would be great if someone uploaded this package for me. Regards James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
Re: RFS: libcodemodel-java (updated package)
Hi Damien On Wed, 2011-05-04 at 01:19 +0200, Damien Raude-Morvan wrote: > I've just some small comments before uploading: > - What's the purpose of "* * maven-plugin * * *" line in > debian/maven.rules ? Good spot - that's completely superfluous so I have removed. Not sure how that crept in. > - You should document switch to 3.0 (quiltà source format in > d/changelog Actioned; I'll upload a new version to mentors in the next hour or so. Thanks James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
Re: RFS: libcodemodel-java (updated package)
On Wed, 2011-05-04 at 08:41 +0100, James Page wrote: > > - You should document switch to 3.0 (quiltà source format in > > d/changelog > > Actioned; I'll upload a new version to mentors in the next hour or so. > > Uploaded - I also merge the UNRELEASED changelog entry into 2.1-1 as requested by Sylvestre via irc Thanks James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
RFS: ant (updated package to 1.8.2-1)
Dear mentors, I am looking for a sponsor for the new version 1.8.2-1 of the package "ant". It builds these binary packages: ant- Java based build tool like make ant-doc- Java based build tool like make - API documentation and manual ant-gcj- Java based build tool like make ant-optional - Java based build tool like make - optional libraries ant-optional-gcj - Java based build tool like make - API documentation and manual The package appears to be lintian clean. The upload would fix these bugs: 610320, 613914 The key upstream change in ant 1.8.2 is the removal of ant-nodeps.jar from the distribution. Optional tasks with no external dependencies are now part of ant core. This includes the classes that support XSLT processing which until ant 1.8.1 where found in ant-trax.jar. In 1.8.1 they moved to ant-nodeps.jar and in 1.8.2 into ant core (ant.jar). This caused some packages to FTBFS as they could no longer find the required classes to support ant tasks like junitreport that use XSLT in 1.8.1. I've tested the new package with groovy and jug, two packages that I know FTBFS against ant 1.8.1. They both build correctly using 1.8.2-1. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/a/ant - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/a/ant/ant_1.8.2-1.dsc It would be great if someone uploaded this package for me. Thanks James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
Java related sessions at the Ubuntu Developer Summit next week.
Hi All If anyone is interested I'm running a few Java related sessions at the Ubuntu Developer Summit next week (see [1]). All sessions are set-up so that people can participate remotely (see [0]). https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-java Summary: Maven2 toolchain - timing for main inclusion, OpenJDK 7 and switching default-java, general Java library housekeeping. https://blueprints.launchpad.net/ubuntu/+spec/server-o-jasmine Summary: Discussion around JASMINe (a JEE administration toolset from ow2) and potential for packaging alongside JOnAS. https://blueprints.launchpad.net/ubuntu/+spec/server-o-jonas Summary: Review of potential packaging of JOnAS JEE Application Server and current issues with JEE test compatibility with OpenJDK. https://blueprints.launchpad.net/ubuntu/+spec/server-o-tomcat7-packaging Summary: Packaging of Apache Tomcat 7 for inclusion in Ubuntu universe (and Debian...) https://blueprints.launchpad.net/ubuntu/+spec/server-o-jenkins Summary: Review of work-to-date and general awareness session prior to commencing work on getting this package set into Debian and Ubuntu. I've also been asked to run a session on package OpenGROK - someone has a crazy idea about having a code.ubuntu.com so its easy to search the archive. Not really looked at this in detail yet but noticed that this has been looked at in Debian in the past... I appreciate that some of these session might be Ubuntu oriented but I will try to feed as much of any resulting work back to Debian where possible. Cheers James P.S. Thanks to Miguel for poking me to send this email [0] http://uds.ubuntu.com/participate/remote/ [1] http://summit.ubuntu.com/uds-o/ -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
Re: ITS: ant (updated package to 1.8.2-1)
On Fri, 2011-05-06 at 00:23 +0200, Niels Thykier wrote: > > Hi, > > I am working on this. > > ~Niels > Thankyou! -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
Offline javadoc linking with maven-debian-helper/maven
Hi All After feedback from Niels on my first package for Debian I've been trying to get a new maven based package (args4j - see [0]) to link its javadoc against the default-jdk-doc API files provided in /usr/share/doc/openjdk-6-doc/api. The package is using maven-debian-helper which calls the maven javadoc:jar and javadoc:aggregate targets to build the javadoc. I've tried following the advice in the maven-javadoc-plugin FAQ (see [1]) by populating the maven.properties file with: maven.javadoc.offlineLinks=/usr/share/doc/openjdk-6-doc/api/ but I can't seem to get maven to generate offline links to the JDK provided API. As a result links to classes provided by Java (and I would suspect any other library) are not generated. Anyone else run into this issue or have a solution? Thanks in advance for any help! Cheers James [0] http://git.debian.org/?p=pkg-java/args4j.git;a=summary [1] http://maven.apache.org/maven-1.x/plugins/javadoc/faq.html#offlineLinks -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
Re: Offline javadoc linking with maven-debian-helper/maven
Hi Onkar On Fri, 2011-05-06 at 20:21 +0530, Onkar Shinde wrote: > > I've tried following the advice in the maven-javadoc-plugin FAQ (see > > [1]) by populating the maven.properties file with: > > > >maven.javadoc.offlineLinks=/usr/share/doc/openjdk-6-doc/api/ > > You should really link to /usr/share/doc/default-jdk-doc/api to make > the links functional on all architectures. Makes sense - I'll update accordingly. > > > but I can't seem to get maven to generate offline links to the JDK > > provided API. As a result links to classes provided by Java (and I > > would suspect any other library) are not generated. > > > > Anyone else run into this issue or have a solution? > > > > Thanks in advance for any help! > > Any chance that you forgot to add default-jdk-doc to build > dependencies. > Sorry, can't help you more as I have not worked on any packages using > maven as build system. That would have been a nice easy fix - alas the package does build-depend on default-jdk-doc so no such luck. Thanks for you help. James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
Re: Offline javadoc linking with maven-debian-helper/maven
Hi Miguel On Fri, 2011-05-06 at 10:26 -0430, Miguel Landaeta wrote: > The only way that I could make that work was patching the POM, > something > like this: > > --- checkstyle-5.3.orig/pom.xml > +++ checkstyle-5.3/pom.xml > @@ -375,6 +375,12 @@ > maven-javadoc-plugin > >1.5 > + > + > + file:///usr/share/doc/default-jdk-doc/api/ > + > file:///usr/share/doc/default-jdk-doc/api/ > + > + > > > > > > This probably is just a hack but you can take a look at checkstyle > package: > http://svn.debian.org/wsvn/pkg-java/trunk/checkstyle/debian/patches/01_link_to_system_javadocs.diff Yes - I considered this approach - works OK for simple libraries; however I have some packages that have lots of dependencies so that's not going to scale that well or be very maintainable. Thanks for the pointer though - I'll let you know if I find a better solution. Cheers James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
RFS: ant-contrib (updated package)
Dear mentors, I am looking for a sponsor for the new version 1.0~b3+svn177-3 of the package "ant-contrib". It builds these binary packages: ant-contrib - collection of tasks, types and other tools for Apache Ant The package appears to be lintian clean. The package updates removes maven2 from the build dependencies (not actually required), enables the upstream test suite and switches the packaging to source/format: 3.0 (quilt). Please see the changelog for full details. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/a/ant-contrib - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/a/ant-contrib/ant-contrib_1.0~b3+svn177-3.dsc It would be great if someone could uploaded this package for me. Thanks James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
Re: First steps with maven and Java packaging
Hi Miguel On Wed, 2011-05-18 at 11:39 +0200, Miguel Telleria de Esteban wrote: > > * Is there a way to disable any test phase in the package? I would >like to set the property > > maven.test.skip = true > >but I don't know where, in the debian/ directory place this > command. Set this in debian/maven.properties - it should get picked up automatically then. > > * Is there an easy way to generate a POM for libmysql-java?. Should > I >file a bug on this package?. But I guess it will not be the only >one not providing POM content. Definitely raise a bug; a patch would be great as well - see http://wiki.debian.org/Java/MavenRepoHelper on how to install the jar and POM in the right locations by using maven-repo-helper. > > * Why do I have dependency problems with Junit?. This seems to be a >very common package that should work well with Maven. The junit packages install into the maven repo under version numbers 3.x or 4.x so you will need to add the following rule to debian/maven.rules to make your package pickup the right version: junit junit jar s/4\..*/4.x/ * * > > * I am still using maven-debian-helper 1.1 from squeeze. Should I >backport the 1.4 version in Sid and Wheezy? 1.4 certainly does alot more that 1.1 - especially when generating the initial package (see mh_make) - in fact it can even pull directly from a svn repository. Cheers James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
RFS: args4j
Hi All I am looking for a sponsor for my package "args4j". * Package name: args4j Version : 2.0.16-1 Upstream Author : Kohsuke Kawaguchi * URL : http://java.net/projects/args4j * License : MIT Section : java It builds these binary packages: libargs4j-java - Java command line arguments parser libargs4j-java-doc - Documentation for Java command line arguments parser The package appears to be lintian clean. The upload would fix these bugs: 625453 My motivation for maintaining this package is that it is a dependency of Jenkins (which I am working on packaging). The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/a/args4j - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/a/args4j/args4j_2.0.16-1.dsc I would be grateful if someone uploaded this package for me. Regards James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
RFS: tiger-types
Hi All I am looking for a sponsor for my package "tiger-types". * Package name: tiger-types Version : 1.3-1 Upstream Author : Kohsuke Kawaguchi * URL : http://java.net/projects/tiger-types * License : CDDL or GPL-2 with Classpath exception Section : java It builds these binary packages: libtiger-types-java - Type arithmetic library for Java5 libtiger-types-java-doc - Documentation for Type arithmetic library for Java5 The package appears to be lintian clean. The upload would fix these bugs: 628725 My motivation for maintaining this package is that it is a dependency of Jenkins (which I am also working on). The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/t/tiger-types - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/t/tiger-types/tiger-types_1.3-1.dsc I would be glad if someone uploaded this package for me. Thanks James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
RFS: metainf-services
Hi All I am looking for a sponsor for my package "metainf-services". * Package name: metainf-services Version : 1.1-1 Upstream Author : Kohsuke Kawaguchi * URL : http://java.net/projects/metainf-services * License : MIT Section : java It builds these binary packages: libmetainf-services-java - META-INF/services generator libmetainf-services-java-doc - Documentation for META-INF/services generator The package appears to be lintian clean. The upload would fix these bugs: 628721 My motivation for maintaining this package is that it is a dependency of Jenkins (which I am also working on). The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/m/metainf-services - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/m/metainf-services/metainf-services_1.1-1.dsc I would be glad if someone uploaded this package for me. Thanks James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
RFS: txw2
Hi All I am looking for a sponsor for my package "txw2". * Package name: txw2 Version : 0.1+20070624-1 Upstream Author : Kohsuke Kawaguchi * URL : https://txw.dev.java.net/ * License : CDDL Section : java It builds these binary packages: libtxw2-java - Typed XML Writer for Java libtxw2-java-doc - Documentation for Typed XML Writer for Java The package is not quite lintian clean: I: txw2 source: debian-watch-file-is-missing Please see debian/README.source for details of why this package has no watch file. The upload would fix these bugs: 628789 My motivation for maintaining this package is that it is a dependency of jenkins (which I am also working on packaging). The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/t/txw2 - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/t/txw2/txw2_0.1 +20070624-1.dsc I would be glad if someone uploaded this package for me. Cheers James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
RFS: guava-libraries
Hi All I am looking for a sponsor for the new package "guava-libraries". * Package name: guava-libraries Version : 09-1 Upstream Author : Google Inc. * URL : http://code.google.com/p/guava-libraries/ * License : Apache License 2.0 Section : java It builds these binary packages: libguava-java - suite of Google Common Libraries for Java 5.0 libguava-java-doc - documentation for libguava-java The package appears to be lintian clean. The upload would fix these bugs: 555684 Miguel Landaeta has done the majority of the packaging work on this library (thanks); I need it to support the packaging of Jenkins. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/g/guava-libraries - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/g/guava-libraries/guava-libraries_09-1.dsc I would be glad if someone uploaded this package for me. Thanks James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
RFS: maven-antrun-extended-plugin
Hi All I am looking for a sponsor for my package "maven-antrun-extended-plugin". * Package name: maven-antrun-extended-plugin Version : 1.42-1 Upstream Author : Kohsuke Kawaguchi * URL : http://java.net/projects/maven-antrun-extended-plugin * License : Apache-2.0 Section : java It builds these binary packages: libmaven-antrun-extended-plugin-java - Extended integration between Maven and Ant libmaven-antrun-extended-plugin-java-doc - Documentation for extended integration between Maven and Ant The package is almost lintian clean; The overriden warning is not applicable to this package (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=629056) The upload would fix these bugs: 628807 My motivation for maintaining this package is that it is a dependency for packaging the Jenkins CI toolset. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/m/maven-antrun-extended-plugin - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/m/maven-antrun-extended-plugin/maven-antrun-extended-plugin_1.42-1.dsc I would be glad if someone uploaded this package for me. Thanks James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
RFS: localizer
Hi All I am looking for a sponsor for my package "localizer". * Package name: localizer Version : 1.12-1 Upstream Author : Kohsuke Kawaguchi * URL : http://java.net/projects/localizer * License : MIT Section : java It builds these binary packages: liblocalizer-java - type-safe access to message resources liblocalizer-java-doc - Documentation for type-safe access to message resources The package is almost lintian clean; The overriden warning is not applicable to this package (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=629056) The upload would fix these bugs: 628803 My motivation for maintaining this package is that it is a dependency for packaging the Jenkins CI toolset. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/localizer - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/localizer/localizer_1.12-1.dsc I would be glad if someone uploaded this package for me. Cheers James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
RFS: sezpoz
Hi All I am looking for a sponsor for my package "sezpoz". * Package name: sezpoz Version : 1.9-1 Upstream Author : Jesse Glick * URL : http://sezpoz.java.net/ * License : CDDL or GPL-2 with Classpath exception Section : java It builds these binary packages: libsezpoz-java - Lightweight library for modular service lookups libsezpoz-java-doc - Documentation for SezPoz The package appears to be lintian clean. The upload would fix these bugs: 629083 My motivation for maintaining this package is that it is a dependency for packaging jenkins. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/s/sezpoz - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/s/sezpoz/sezpoz_1.9-1.dsc I would be glad if someone uploaded this package for me. Cheers James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
Re: RFS: args4j
On Fri, 2011-06-03 at 22:18 -0700, tony mancill wrote: > > The package looks good to me. Before uploading it to the NEW queue, I > think we should list Jan Materne and Mark Sinke to debian/copyright. > Their names are listed in pom.xml, project.xml > and ./xdocs/changes.xml, > and so I assume that they're also copyright holders. (Admittedly, it's > not really clear from the upstream license file and the individual > files > don't carry any sort of license statement.) If you're okay with that, > I > can make the change to the repo and prepare the upload. I agree its not clear but as there is no copyright assignment for this project it would make sense to add them (its a good assumption). Happy for you to make the changes and upload - thanks! Cheers James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
Re: ITS: localizer
Hi Damien On Sun, 2011-06-05 at 23:43 +0200, Damien Raude-Morvan wrote: > > I couldn't find anything regarding license in upstream orig.tar : > where did you > get the MIT licencing terms ? The licensing terms came from the project website - see http://java.net/projects/localizer > FTP Masters won't be happy with a package with LICENSE/COPYING and/or > at least > some file headers. Making the assumption that the MIT licensing terms via the website is in-sufficient I'll contact the upstream author to see if I can get this referenced within the source code. Thanks for reviewing/sponsoring. Cheers James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
Re: ITS: txw2
Hi Damien On Mon, 2011-06-06 at 00:35 +0200, Damien Raude-Morvan wrote: > > Two comments here : > - There is no need to Build-Depends on quilt with 3.0 (quilt) source > format > - You have some duplication in your make targets : install/lib > $(PACKAGE)- > java:: (install + dh_link) and a binary-post-install/lib > $(PACKAGE)-java:: > (mh_installpom + mh_installjar). You should just keep mh_installpom + > mh_installjar. Both issues resolved and build-tested; I've pushed the changes back to the git repository (let me know if you would like them on mentors as well). Cheers James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
Re: ITS: sezpoz
Hi Damien On Sun, 2011-06-05 at 23:58 +0200, Damien Raude-Morvan wrote: > - I think there is some missing copyright assignment in > debian/copyright. > I've found those comments in files' headers : > * The Original Software is SezPoz. The Initial Developer of the > Original > * Software is Sun Microsystems, Inc. Portions Copyright 2006-2010 Sun > * Microsystems, Inc. All Rights Reserved. Added to the copyright file; I did scan through a sample of other files and this was the only assignment I could find that was missing. I also updated the email address for the primary author (now works for Oracle). Must remember not to entirely trust mh_make to identify all copyright assignment for me > > - Not a blocking issue, but mh_resolve_dependencie > doesn't manage to build all dependencies from pom.xml. > In pbuilder, I get : > mh_resolve_dependencies --non-interactive --offline -plibsezpoz-java > [...] > > dpkg > --search /usr/share/maven-repo/org/codehaus/mojo/versions-maven-plugin > dpkg-query: no path found matching pattern /usr/share/maven- > repo/org/codehaus/mojo/versions-maven-plugin. > dpkg failed to execute successfully > Jun 5, 2011 9:50:31 PM org.debian.maven.packager.DependenciesSolver > $ToResolve > resolve > SEVERE: Cannot resolve dependencies > in /tmp/buildd/sezpoz-1.9/pom.xml: > Dependency not found > org.codehaus.mojo:versions-maven-plugin:maven-plugin:1.2 > ERROR: > pom.xml: Plugin is not packaged in the Maven repository for Debian: > org.codehaus.mojo:versions-maven-plugin:1.2 > > Maybe it's an issue with maven-debian-helper. Could you check this ? Nope - its an issue with my packaging; the maven.ignoreRules file was missing a line: org.codehaus.mojo versions-maven-plugin * * * * Maven correctly identified it was not in the local repository. I've updated the packaging with both of these changes and pushed to the git repository. Thanks for reviewing/sponsoring. Cheers James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
RFS: akuma (NEW)
Hi All I am looking for a sponsor for my package "akuma". * Package name: akuma Version : 1.4-1 Upstream Author : Kohsuke Kawaguchi * URL : http://java.net/projects/akuma * License : MIT Section : java It builds these binary packages: libakuma-java - Embeddable daemonization library for Java libakuma-java-doc - Documentation for Embeddable daemonization library The package appears to be lintian clean. The upload would fix these bugs: 629073 My motivation for maintaining this package is that it is a dependency for packaging jenkins. I've uploaded the package to git.debian.org: - ssh://git.debian.org/git/pkg-java/akuma.git The package can also be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/a/akuma - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/a/akuma/akuma_1.4-1.dsc I would be glad if someone uploaded this package for me. Thanks James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
Re: missing-classpath lintian warnings and Maven based packages.
On Mon, 2011-06-06 at 09:56 +0200, Torsten Werner wrote: > it might help to submit a bug report of severity wishlist. On my list of things TODO Cheers James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
RFS: libpam4j (NEW)
Hi All I am looking for a sponsor for my package "libpam4j". * Package name: libpam4j Version : 1.4-1 Upstream Author : Kohsuke Kawaguchi * URL : http://java.net/projects/libpam4j/ * License : MIT Section : java It builds these binary packages: libpam4j-java - Java binding for libpam.so libpam4j-java-doc - Documentation for Java binding for libpam.so The package appears to be lintian clean. The upload would fix these bugs: 629381 My motivation for maintaining this package is that it is required in order to support packaging of jenkins. I have uploaded this package to git.debian.org: - ssh://git.debian.org/git/pkg-java/libpam4j.git The package can also be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/l/libpam4j - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/l/libpam4j/libpam4j_1.4-1.dsc I would be glad if someone uploaded this package for me. Thanks James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
Re: ITS: txw2
On Mon, 2011-06-06 at 22:16 +0200, Damien Raude-Morvan wrote: > Le lundi 06 juin 2011 09:19:21, James Page a écrit : > > Both issues resolved and build-tested; I've pushed the changes back to > > the git repository (let me know if you would like them on mentors as > > well). > > Uploaded. Thankyou! -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
Re: ITS: sezpoz
On Mon, 2011-06-06 at 22:15 +0200, Damien Raude-Morvan wrote: > > Hi Damien > [...] > > I've updated the packaging with both of these changes and pushed to > the > > git repository. > > OK, uploaded. Thankyou -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
RFS: robust-http-client (NEW)
Hi All I am looking for a sponsor for my package "robust-http-client". * Package name: robust-http-client Version : 1.1-1 Upstream Author : Kohsuke Kawaguchi * URL : http://java.net/projects/robust-http-client * License : MIT Section : java It builds these binary packages: librobust-http-client-java - Robust HTTP client library for Java librobust-http-client-java-doc - Documentation for Robust HTTP client library for Java The package appears to be lintian clean. The upload would fix these bugs: 629508 My motivation for maintaining this package is that it is required to support packaging of jenkins. I have push the package to git.debian.org: - ssh://git.debian.org/git/pkg-java/robust-http-client.git The package can be also found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/r/robust-http-client - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/r/robust-http-client/robust-http-client_1.1-1.dsc I would be glad if someone uploaded this package for me. Thanks James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
RFS: jcaptcha (NEW)
Hi All I am looking for a sponsor for my package "jcaptcha". * Package name: jcaptcha Version : 2.0~alpha1-1 * URL : http://www.jcaptcha.net/ * License : LGPL-2.1 Section : java It builds these binary packages: libjcaptcha-java - Java framework for CAPTCHA definition and integration libjcaptcha-java-doc - Documentation for JCaptcha The package appears to be lintian clean. The upload would fix these bugs: 629529 My motivation for maintaining this package is that it is a dependency for packaging of jenkins. I have uploaded this package to git.debian.org: - ssh://git.debian.org/git/pkg-java/jcaptcha.git The package can also be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/j/jcaptcha - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/j/jcaptcha/jcaptcha_2.0~alpha1-1.dsc I would be glad if someone uploaded this package for me. Thanks James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
Re: Bug#629622: ITP: jenkins-htmlunit-core-js -- Jenkins branch of the HtmlUnit Core JS Interpreter
Hi Damien On Wed, 2011-06-08 at 15:48 +0200, Damien Raude-Morvan wrote: > So, JenkisCI is using a fork (jenkins-htmlunit-core-js) of the fork > (htmlunit-core-js [1]) > of Rhino package... JenkisCI upstream seems a love code (and > effort...) > duplication. I don't disagree that this is pretty ugly; Jenkins CI upstream does fork other projects frequently - here's a short list of the ones I'm being impacted by during packaging: dom4j commons-jexl json-lib htmlunit xstream commons-jelly winstone trilead-ssh2 and ones I intend to avoid: jcifs jinterop Although some of these forks may be due to upstream inactivity I think this reflects the ~weekly release schedule of the project and the ease at which they can fork and upstream and maintain it to resolve their immediate issues. The introduction of a 3 monthly stable release should help reduce the impact of the standard release velocity but it does not necessarily remove the forked dependencies. I have seen forks disappear and the project revert back to mainstream upstream (jmdns was an example of this but I just noticed they forked it again - doh!). > /with my rhino package maintainer hat/ > Rhino is - now - an active project again (at least, they made a new > release on 2011-06-03 [2]). > You should try to convince JenkisCI team to merge back its changes [3] > (and htmlunit changes [4]) back into Rhino Absolutely; I'll endeavour to work on making this happen. I appreciate that this upstream behaviour does increase the effort required to support packaging of jenkins. I have the packaging in place so the additional effort is not really on me in the short term (although I expect to have to deal with updates and bug fixes) - it will be whomever sponsors these packages for me. Do you think this will block entry into Debian? Cheers James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
Re: Bug#629622: ITP: jenkins-htmlunit-core-js -- Jenkins branch of the HtmlUnit Core JS Interpreter
On Wed, 2011-06-08 at 17:30 +0200, Damien Raude-Morvan wrote: > On Wed, 08 Jun 2011 15:10:06 +0100, James Page > wrote: [...] > > If changes made by JenkinsCI team are not too intrusive maybe we can merge > them > - as patches - into existing debian packages ? > Might be the best option for "inactive" upstream projects like dom4j, > trilead-ssh2 or commons-jexl. That approach might work; I'll review my current list of variants for patchsets that could be applied (and document it somewhere so it can easily be reviewed). Most changes either seem to be adding new distinct features or fixing minor bugs that where impacting Jenkins. Is there any specific policy on taking this approach? In effect Debian would be branching from the original upstream - this is in principle the same as what jenkins are doing upstream although it would reduce the code duplication in the distro. [...] > Code duplication is always a bad thing (tm) from a distribution POV : > increase maintenance overhead, > imply some security issues have to be fixed multiple times... > > YMMV, but I don't consider this a blocking issue or a "no-go" for JenkisCI > but I think > we should at least describe this case explicitly : > http://wiki.debian.org/EmbeddedCodeCopies > http://anonscm.debian.org/viewvc/secure-testing/data/embedded-code-copies?view=markup Thanks for the feedback and for pointing me at the above Cheers James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
Re: ITS: metainf-services
Hi Damien On Thu, 2011-06-09 at 17:06 +0200, Damien Raude-Morvan wrote: > I've the same comments as on "localizer" : I couldn't find anything > regarding license / copyright in upstream orig.tar.gz > and, AFAIK, refering to a website for licensing information is not an > acceptable practice for FTP Masters. > > Could you please contact upstream about this ? Yes and apologies - I should have picked this up after the feedback you gave on localizer; I've also identified a few other packages in the pipeline that also have this issue. I have noted that some packages make reference to the license in the Maven pom.xml file - for example: GNU Lesser General Public License version 2.1 http://www.gnu.org/licenses/lgpl.html COMMON DEVELOPMENT AND DISTRIBUTION LICENSE (CDDL) Version 1.0 http://www.sun.com/cddl/cddl.html Is this acceptable practice? It still references out to an external website but it does state the licensing within the original source code. Cheers James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
Re: ITS: metainf-services
Hi Damien On Thu, 2011-06-09 at 16:43 +0100, James Page wrote: > > I've the same comments as on "localizer" : I couldn't find anything > > regarding license / copyright in upstream orig.tar.gz > > and, AFAIK, refering to a website for licensing information is not > an > > acceptable practice for FTP Masters. > > > > Could you please contact upstream about this ? > > Yes and apologies - I should have picked this up after the feedback > you > gave on localizer; I've also identified a few other packages in the > pipeline that also have this issue. The upstream project have already added headers to the SVN code repository; however this is as yet unreleased. Would it be acceptable to apply a patch based on the associated svn commit as part of building the orig.tar.gz and move to version 1.1+svn25 as the version number for this library? Let me know Cheers James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
Re: ITS: localizer
Hi Damien On Sun, 2011-06-05 at 23:43 +0200, Damien Raude-Morvan wrote: > > > * License : MIT > [...] > > I couldn't find anything regarding license in upstream orig.tar : > where did you > get the MIT licencing terms ? > FTP Masters won't be happy with a package with LICENSE/COPYING and/or > at least > some file headers. > > Could you please check this ? Upstream (Kohsuke Kawaguchi) updated the source code with license and copyright information and re-released this project. I've updated the packaging to version 1.13 and pushed to git.debian.org. Please could you re-review now this licensing issue has been remedied. Thanks James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
Re: ITS: localizer
On Sun, 2011-06-12 at 19:27 +0200, Damien Raude-Morvan wrote: > > Please could you re-review now this licensing issue has been > remedied. > > Fine, just uploaded to NEW. Thankyou for sponsoring my work Cheers James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
Re: ITS: jcaptcha (NEW)
Hi Damien On Sun, 2011-06-12 at 21:29 +0200, Damien Raude-Morvan wrote: [...] > > It builds these binary packages: > > libjcaptcha-java - Java framework for CAPTCHA definition and > integration > > libjcaptcha-java-doc - Documentation for JCaptcha > > Are you sure that this file is licenced under the same licence as > JCaptcha ? > -> "src/doc/captcha_crypt.pdf" > It's look like some kind of study, released by different authors than > JCaptcha. Hmm - it does look like its owned by different authors; I'll email upstream to see if we can identify the source/copyright/license - however this file is not included in the resulting packages and seems more for background information for developers so we may be better to drop this file from the packaging. -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
Re: ITS: metainf-services
On Mon, 2011-06-13 at 19:23 +0200, Damien Raude-Morvan wrote: > Maybe you can just extract and build a new upstream tarball from this > release > ? I've asked upstream to push a release; might happen quickly (I'm away for the next couple of days so will check Thursday). Cheers James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
Re: RFS: akuma (NEW)
Hi Tony On Wed, 2011-06-15 at 21:07 -0700, tony mancill wrote: > There seem to be questions regarding the upstream source license. The > source files themselves don't mention a license, the pom.xml claims > the > MIT license, while the upstream homepage claims CDDL-1.0. Since the > project some recent upstream activity, perhaps the author could > clarify. Good spot; I think that a number of project on java.net now have inconsistent project information - there was a large migration onto a new platform early this year and I'm not sure all the information on the website is correct. I've raised a bug upstream and contacted Kohsuke (project owner) via email to get this resolved. FYI Kohsuke is really keen to see Jenkins in an official distro and has committed to resolve and blocking issues as quickly as he can. I know he is running some Jenkins training at the moment so hopefully he will pickup end of this week/next week. Cheers James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
Re: RFS: akuma (NEW)
Hi Tony On Thu, 2011-06-16 at 10:20 +0100, James Page wrote: > > There seem to be questions regarding the upstream source license. > The > > source files themselves don't mention a license, the pom.xml claims > > the > > MIT license, while the upstream homepage claims CDDL-1.0. Since the > > project some recent upstream activity, perhaps the author could > > clarify. > > Good spot; I think that a number of project on java.net now have > inconsistent project information - there was a large migration onto a > new platform early this year and I'm not sure all the information on > the > website is correct. > > I've raised a bug upstream and contacted Kohsuke (project owner) via > email to get this resolved. Resolved - Kohsuke has confirmed that the license should be MIT and has updated the java.net project site accordingly so should now be consistent. Cheers James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
Policy question: Private Libraries and Maven Artefacts
Hi Team I have a question about how I should package some of the dependencies for Jenkins. Basically the Jenkins project manages a number of small utility libraries as separate projects; these are jenkins specific (i.e. unlikely to find use outside of the jenkins project itself). I want to align to upstream by managing these are separate Java library packages; however this does not appear to fit into the Debian Java Policy for either Java applications or Libraries exactly. This is my proposed approach: Package Name: libjenkins-XXX-java where XXX is the name of the library Artefacts will be published to /usr/share/maven-repo; Jenkins requires this in order to build successfully. JAR files will also be published to /usr/share/jenkins/java; these will be used by Jenkins at runtime but will not be shared with other applications as they are not published to /usr/share/java. This approach combines aspects of the Java application and library sections of the policy - and as such it does generate some lintian warnings about JAR's not being installed to /usr/share/java. I wondered whether anyone has come across similar issues and how they resolved them; and if not whether the above approach looks reasonable. Comments and guidance much appreciated. Cheers James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
Maintaining zookeeper in Debian
Hi Team Some of you may have been following the discussion around zookeeper and its future in Debian on debian-devel. Clint Byrum (cc'ed) and myself discussed this last week and we would like to step up to help maintain this package in Debian. There are a couple of reasons for this: 1) zookeeper is a essential part of ensemble (see [0] and [1]) so having a well maintained package in Debian and Ubuntu is key to the success of this project. 2) zookeeper is part of the Hadoop Big-Data suite which is important for the Ubuntu Server Team strategically. The package is currently maintained by Debian Java Maintainers; we propose that this remains as is and that Clint and I pickup the outstanding bugs against this package for resolution in the immediate future. Neither Clint or I are Debian Developers so we will need help in the form of sponsorship to ensure that this package continues to be actively maintained. Regards James [0] https://ensemble.ubuntu.com/ [1] http://lists.debian.org/debian-devel/2011/06/threads.html#00283 -- James Page Ubuntu Server Developer signature.asc Description: This is a digitally signed message part
Re: ITS: metainf-services
Hi Damien n Mon, 2011-06-13 at 19:22 +0100, James Page wrote: > > Maybe you can just extract and build a new upstream tarball from > this > > release > > ? > > I've asked upstream to push a release; might happen quickly (I'm away > for the next couple of days so will check Thursday). Upstream re-released last night after resolving the lack of licensing information - took a bit longer as someone from Oracle had already added headers to the source code which where incorrect - this has been resolved by the upstream author who has clarified the copyright and licensing for this project. I've updated the packaging and pushed to git.debian.org. Please could you review and upload if you are happy with the changes. Thanks James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
Re: ITS: metainf-services
On Tue, 2011-06-28 at 13:28 +0200, Damien Raude-Morvan wrote: > > > > I've updated the packaging and pushed to git.debian.org. Please > could > > you review and upload if you are happy with the changes. > > It's ok for me. > Uploaded. Thanks Cheers James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
RFS: libspring-ldap-java (update)
Dear Team I am looking for a sponsor for the new version 1.3.1.RELEASE-2 of "libspring-ldap-java". This update adds maven artifact deployment to /usr/share/maven-repo/ The updated package can be found on git.debian.org: - git+ssh://git.debian.org/git/pkg-java/libspring-ldap-java.git - http://anonscm.debian.org/gitweb/?p=pkg-java/libspring-ldap-java.git I would be grateful if someone could review/upload this for me. Thanks James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
RFS: jmdns 3.4.0-1 (updated)
Hi Team I am looking for a sponsor for the new version 3.4.0-1 of my package "jmdns". It builds these binary packages: libjmdns-java - Java implementation of multi-cast DNS (Apple Rendezvous) libjmdns-java-doc - Documentation for Java implementation of multi-cast DNS The package appears to be lintian clean. The upload would fix these bugs: 616175, 620048 This version upgrades the package to upstream 3.4.0 and adds Maven artifact deployment to /usr/share/maven-repo. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/j/jmdns - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/j/jmdns/jmdns_3.4.0-1.dsc I have also committed the changes to the team SVN repository: - svn+ssh://svn.debian.org/svn/pkg-java/trunk/jmdns It would be great if someone uploaded this package for me. Thanks James -- James Page Ubuntu Server Developer signature.asc Description: This is a digitally signed message part
Re: Maintaining zookeeper in Debian
Hi Damien On Thu, 2011-06-23 at 23:52 +0200, Damien Raude-Morvan wrote: [...] > > Are you already in contact with upstream ? > AFAIK, from [1], we have to choose between Apache/Cloudera distribution and > find a way to establish long term support from upstream. I think this is an important consideration in the mid to long term; The Cloudera distribution is certainly more popular (one of the Ubuntu server team discussed this with Hadoop users at Hadoop World last year) but at the moment they only support the Sun/Oracle JDK which would be a blocker for good upstream participation/support. Reference [1] also mentions Bigtop; This is a Cloudera project that has been open-sourced and has just been accepted as an Apache Incubator project. I will be participating (see [3]) and I hope that this will allow the upstream distribution packaging to converge with the distro packaging. > > Neither Clint or I are Debian Developers so we will need help in the > > form of sponsorship to ensure that this package continues to be actively > > maintained. > > You can count on my help for sponsoring (and I think others DD in Debian Java > Team can provide time for reviews and upload too :) Great - thankyou! Cheers James [1] http://lists.debian.org/debian-devel/2011/06/msg00371.html [2] http://wiki.debian.org/DebianMaintainer [3] http://wiki.apache.org/incubator/BigtopProposal -- James Page Ubuntu Server Developer signature.asc Description: This is a digitally signed message part
Re: RFS: jmdns 3.4.0-1 (updated)
On Tue, 2011-07-05 at 22:25 +0200, Damien Raude-Morvan wrote: > > I am looking for a sponsor for the new version 3.4.0-1 > > of my package "jmdns". > > Ok, uploaded. Thankyou -- James Page Ubuntu Server Developer signature.asc Description: This is a digitally signed message part
RFS: zookeeper 3.3.3+dfsg1-1 (updated)
Hi Team I am looking for a sponsor for the new version 3.3.3+dfsg1-1 of the package "zookeeper". The package is not lintian clean yet; I have addressed what I considered to be the key warnings and will be working on the rest going forwards. The upload would fix these bugs: 594970, 601383, 625441, 626020 It also upgrades zookeeper to the latest available release from Apache. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/z/zookeeper - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/z/zookeeper/zookeeper_3.3.3 +dfsg1-1.dsc I've also pushed these changes to git.debian.org: - git+ssh://git.debian.org/git/pkg-java/zookeeper.git It would be great if someone uploaded this package for me. Thanks James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
Re: ITS: zookeeper 3.3.3+dfsg1-1 (updated)
On Tue, 2011-07-12 at 23:31 +0200, Damien Raude-Morvan wrote: > Le mardi 12 juillet 2011 21:42:23, Damien Raude-Morvan a écrit : > > > The upload would fix these bugs: 594970, 601383, 625441, 626020 > > I've just done a first upload "as-is" to allow fix for thoses RC bugs. Thankyou > But, I've some - still - comments on this package : > - src/java/test/data/* seems to contains many binary files (tests database > ?). > AFAIK, there is no source/script to generate this data (non-DFSG). > - there is a src/contrib/zooinspector/licences/epl-v10.html licence file in > source tarball but from debian/copyright those files seems to be under > Apache-2.0. You might want to double-check this. > - libzookeeper-dev put headers into /usr/include/c-client-src/ which seems a > bit generic name :) You might want to forward this to upstream. I'll review this feedback and work towards another release; I also managed to disable the python 2.7 features of python-zookeeper during the transition to dh_python2 so will fix that at the same time. > Many thanks for this work. No Problem Thanks again James -- James Page Ubuntu Server Developer signature.asc Description: This is a digitally signed message part
RFS: jmdns 3.4.0-2 (updated)
Hi Team I am looking for a sponsor for the new version 3.4.0-2 of the package "jmdns". It builds these binary packages: libjmdns-java - Java implementation of multi-cast DNS (Apple Rendezvous) libjmdns-java-doc - Documentation for Java implementation of multi-cast DNS This upload resolves an issue introduced in 3.4.0-1 where the Maven artefacts deployed to /usr/share/maven-repo are un-usable due to an un-resolvable parent POM reference. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/j/jmdns - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/j/jmdns/jmdns_3.4.0-2.dsc I also pushed the change to : - ssh+svn://svn.debian.org/svn/pkg-java/trunk/jmdns It would be great if someone could uploaded this package for me. Thanks James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
Re: RFS: jmdns 3.4.0-2 (updated)
On Sat, 2011-07-16 at 10:29 -0700, tony mancill wrote: > Uploaded. > > Cheers, > tony > Thankyou -- James Page Ubuntu Server Developer signature.asc Description: This is a digitally signed message part
RFS: annotation-indexer 1.2-1 (new)
Hi Team I am looking for a sponsor for my new package "annotation-indexer". * Package name: annotation-indexer Version : 1.2-1 * URL : http://github.com/jenkinsci/lib-annotation-indexer * License : CDDL Section : java The package appears to be lintian clean. This upload would fix this bug: http://bugs.debian.org/629697 My motivation for maintaining this package is that it is a dependency of Jenkins. I have uploaded to git.debian.org: - ssh://git.debian.org/git/pkg-java/annotation-indexer.git - http://git.debian.org/?p=pkg-java/annotation-indexer.git It would be great if someone could review and upload this package for me. Thanks James -- James Page Ubuntu Server Developer -- 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/20110727112644.1632A428FA@hendrix.shouse.local
RFS: jenkins-test-annotations 1.0-1 (new)
Hi Team I am looking for a sponsor for my new package "jenkins-test-annotations". * Package name: jenkins-test-annotations Version : 1.0-1 * URL : http://github.com/jenkinsci/lib-test-annotations * License : MIT Section : java The package appears to be lintian clean. The upload would fix this bug: http://bugs.debian.org/631207 My motivation for maintaining this package is that it is a dependency of Jenkins. I have uploaded to git.debian.org: - ssh://git.debian.org/git/pkg-java/jenkins-test-annotations.git - http://git.debian.org/?p=pkg-java/jenkins-test-annotations.git It would be great if someone could review and upload this package for me. Thanks James -- James Page Ubuntu Server Developer -- 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/20110727123704.CF41E428FA@hendrix.shouse.local
RFS: jenkins-crypto-util 1.1-1 (new)
Hi Team I am looking for a sponsor for my new package "jenkins-crypto-util". * Package name: jenkins-crypto-util Version : 1.1-1 * URL : https://github.com/jenkinsci/lib-crypto-util * License : MIT Section : java The package is lintian clean aside from: O: jenkins-crypto-util: missing-classpath libcommons-io-java This package is a private package for Jenkins; this dependency is resolved using maven during the Jenkins build so is not applicable in this case. The upload would fix this bug: http://bugs.debian.org/631209 My motivation for maintaining this package is that it is a dependency of Jenkins. I have uploaded to git.debian.org: - ssh://git.debian.org/git/pkg-java/jenkins-crypto-util.git - http://git.debian.org/?p=pkg-java/jenkins-crypto-util.git It would be great if someone could review and upload this package for me. Thanks James -- James Page Ubuntu Server Developer -- 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/20110727124511.54EAA428FA@hendrix.shouse.local
RFS: jenkins-executable-war 1.22-1 (new)
Hi Team I am looking for a sponsor for my new package "jenkins-executable-war". * Package name: jenkins-executable-war Version : 1.22-1 * URL : http://jenkinsci.org/ * License : MIT Section : java The package appears to be lintian clean. The upload would fix this bug: http://bugs.debian.org/631210 My motivation for maintaining this package is that it is a dependency of Jenkins. I have uploaded to git.debian.org: - ssh://git.debian.org/git/pkg-java/jenkins-executable-war.git - http://git.debian.org/?p=pkg-java/jenkins-executable-war.git It would be great if someone could review and upload this package for me. Thanks James -- James Page Ubuntu Server Developer -- 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/20110727125906.5FC0F428FA@hendrix.shouse.local
Re: ITS: Re: RFS: annotation-indexer 1.2-1 (new)
On Wed, 2011-07-27 at 22:14 -0700, tony mancill wrote: > I'll sponsor this. The only issue I see so far is that upstream > doesn't > include a license in all of the source files. However, given that > they're all by the same author and come from the same place (as the > licensed files), it should be okay. Thankyou Cheers James -- James Page Software Engineer, Ubuntu Server Team signature.asc Description: This is a digitally signed message part
RFS: jellydoc 1.5-1 (new)
Hi Team I am looking for a sponsor for my new package "jellydoc". * Package name: jellydoc Version : 1.5-1 * URL : http://java.net/projects/maven-jellydoc-plugin * License : Apache-2.0 Section : java The package appears to be lintian clean. The upload would fix this bug: http://bugs.debian.org/630795 My motivation for maintaining this package is that it is a dependency of Jenkins. I have uploaded to git.debian.org: - ssh://git.debian.org/git/pkg-java/jellydoc.git - http://git.debian.org/?p=pkg-java/jellydoc.git It would be great if someone could review and upload this package for me. Thanks James -- James Page Ubuntu Server Developer -- 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/20110801084345.DA88D43101@hendrix.shouse.local
RFS: jenkins-memory-monitor 1.5-1 (new)
Hi Team I am looking for a sponsor for my new package "jenkins-memory-monitor". * Package name: jenkins-memory-monitor Version : 1.5-1 * URL : https://github.com/jenkinsci/extras-memory-monitor * License : MIT Section : java The upload would fix this bug: http://bugs.debian.org/634630 My motivation for maintaining this package is that it is a dependency of Jenkins. I have uploaded to git.debian.org: - ssh://git.debian.org/git/pkg-java/jenkins-memory-monitor.git - http://git.debian.org/?p=pkg-java/jenkins-memory-monitor.git It would be great if someone could review and upload this package for me. Thanks James -- James Page Ubuntu Server Developer -- 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/20110801085855.B04E243101@hendrix.shouse.local
RFS: jenkins-task-reactor 1.3-1 (new)
Hi Team I am looking for a sponsor for my new package "jenkins-task-reactor". * Package name: jenkins-task-reactor Version : 1.3-1 * URL : https://github.com/jenkinsci/lib-task-reactor * License : MIT Section : java The upload would fix this bug: http://bugs.debian.org/631211 My motivation for maintaining this package is that it is a dependency of Jenkins. I have uploaded to git.debian.org: - ssh://git.debian.org/git/pkg-java/jenkins-task-reactor.git - http://git.debian.org/?p=pkg-java/jenkins-task-reactor.git It would be great if someone could review and upload this package for me. Thanks James -- James Page Ubuntu Server Developer -- 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/20110801090552.D4BAE43101@hendrix.shouse.local
RFS: access-modifier-checker 1.0-1 (new)
Hi Team I am looking for a sponsor for my new package "access-modifier-checker". * Package name: access-modifier-checker Version : 1.0-1 * URL : https://github.com/kohsuke/access-modifier * License : MIT Section : java The package appears to be lintian clean. The upload would fix this bug: http://bugs.debian.org/629909 My motivation for maintaining this package is that it is a dependency of Jenkins. I have uploaded to git.debian.org: - ssh://git.debian.org/git/pkg-java/access-modifier-checker.git - http://git.debian.org/?p=pkg-java/access-modifier-checker.git It would be great if someone could review and upload this package for me. Thanks James -- James Page Ubuntu Server Developer -- 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/20110801091642.8A42843101@hendrix.shouse.local
Re: jenkins for Debian
Resending to debian-java (don't think my last email made it). On Sat, 2011-07-30 at 23:01 +0200, Damien Raude-Morvan wrote: > James, could you provide a (link ?) to updated status of your > packaging effort > ? And is there something we (Debian Java Team) could do to help you ? For tracker see [0]. I spent time last week scripting the migration of the Ubuntu accepted packages into Debian packages (new changelog entries, revised control + repositories on git.debian.org) so I expect to start RFS'ing in earnest this week. Please bear in mind that there are a number of forks maintained by the Jenkins project (some of which are already package and some are not) - see [1]. As most of the forks introduce API changes in one way or another I am reticent to integrate them as patches into existing packages - as a result I have filed ITP's for them all in Debian and they have been accepted into Ubuntu as-is. I have been pushing upstream to get their changes folded back into the original projects - for some packages this will work; for others it won't mainly due to inactivity etc. If anyone would like to review this work and provide another perspective on these forks that would be really helpful. I have attached a dependency graph to [1] to illustrate how these forks fit into the dependency chain for jenkins; they are not all directly used by jenkins - stapler (this project is pretty much driven by jenkins and is developed by the Jenkins founder) pulls a few as well. Regards James [0] https://wiki.ubuntu.com/ServerTeam/Jenkins/JenkinsUbuntuTracker [1] https://wiki.ubuntu.com/ServerTeam/Jenkins/JenkinsForks -- James Page Ubuntu Server Developer signature.asc Description: This is a digitally signed message part
RE: RFS jellydoc, access-modifier-checker, jenkins-task-reactor, jenkins-memory-monitor (NEW)
Thanks for uploading! Cheers James -- James Page Ubuntu Server Developer signature.asc Description: This is a digitally signed message part
RFS: bridge-method-injector 1.4-1 (new)
Hi Team I am looking for a sponsor for my new package "bridge-method-injector". * Package name: bridge-method-injector Version : 1.4-1 * URL : http://bridge-method-injector.infradna.com/ * License : MIT Section : java The package appears to be lintian clean. The upload would fix this bug: http://bugs.debian.org/629814 My motivation for maintaining this package is that it is a dependency of Jenkins. I have uploaded to git.debian.org: - ssh://git.debian.org/git/pkg-java/bridge-method-injector.git - http://git.debian.org/?p=pkg-java/bridge-method-injector.git It would be great if someone could review and upload this package for me. Thanks James -- James Page Ubuntu Server Developer -- 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/20110804094641.0ADC5443F6@hendrix.shouse.local
Re: RFS: bridge-method-injector 1.4-1 (new)
On Thu, 2011-08-04 at 23:30 +0200, Damien Raude-Morvan wrote: > Uploaded. > > Thanks! James -- James Page Ubuntu Server Developer signature.asc Description: This is a digitally signed message part
RFS: jenkins-json 2.1-rev6-1 (new)
Hi Team I am looking for a sponsor for my new package "jenkins-json". * Package name: jenkins-json Version : 2.1-rev6-1 * URL : https://github.com/jenkinsci/json-lib * License : Apache-2.0 Section : java The package appears to be lintian clean. The upload would fix this bug: http://bugs.debian.org/634634 My motivation for maintaining this package is that it is a dependency of Jenkins. I have uploaded to git.debian.org: - ssh://git.debian.org/git/pkg-java/jenkins-json.git - http://git.debian.org/?p=pkg-java/jenkins-json.git It would be great if someone could review and upload this package for me. Thanks James -- James Page Ubuntu Server Developer -- 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/20110830135415.9515D45E51@hendrix.shouse.local
RFS: jenkins-commons-jexl 1.1-hudson-20090508-1 (new)
Hi Team I am looking for a sponsor for my new package "jenkins-commons-jexl". * Package name: jenkins-commons-jexl Version : 1.1-hudson-20090508-1 * URL : https://github.com/jenkinsci/jexl/ * License : Apache-2.0 Section : java The package appears to be lintian clean. The upload would fix this bug: http://bugs.debian.org/634631 My motivation for maintaining this package is that it is a dependency of Jenkins. I have uploaded to git.debian.org: - ssh://git.debian.org/git/pkg-java/jenkins-commons-jexl.git - http://git.debian.org/?p=pkg-java/jenkins-commons-jexl.git It would be great if someone could review and upload this package for me. Thanks James -- James Page Ubuntu Server Developer -- 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/20110830214445.4FDE045E51@hendrix.shouse.local
RFS: jenkins-dom4j 1.6.1-hudson-3-1 (new)
Hi Team I am looking for a sponsor for my new package "jenkins-dom4j". * Package name: jenkins-dom4j Version : 1.6.1-hudson-3-1 * URL : http://github.com/jenkinsci/dom4j * License : DOM4J Section : java The package appears to be lintian clean. The upload would fix this bug: http://bugs.debian.org/634632 My motivation for maintaining this package is that it is a dependency of Jenkins. I have uploaded to git.debian.org: - ssh://git.debian.org/git/pkg-java/jenkins-dom4j.git - http://git.debian.org/?p=pkg-java/jenkins-dom4j.git It would be great if someone could review and upload this package for me. Thanks James -- James Page Ubuntu Server Developer -- 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/20110830215006.252CA45E55@hendrix.shouse.local
RFS: jenkins-trilead-ssh2 212-hudson-6-1 (new)
Hi Team I am looking for a sponsor for my new package "jenkins-trilead-ssh2". * Package name: jenkins-trilead-ssh2 Version : 212-hudson-6-1 * URL : https://github.com/jenkinsci/trilead-ssh2 * License : BSD Section : java The package appears to be lintian clean. The upload would fix this bug: http://bugs.debian.org/634644 My motivation for maintaining this package is that it is a dependency of Jenkins. I have uploaded to git.debian.org: - ssh://git.debian.org/git/pkg-java/jenkins-trilead-ssh2.git - http://git.debian.org/?p=pkg-java/jenkins-trilead-ssh2.git It would be great if someone could review and upload this package for me. Thanks James -- James Page Ubuntu Server Developer -- 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/20110830215411.7808145E55@hendrix.shouse.local
Re: RFS: jenkins-dom4j 1.6.1-hudson-3-1 (new)
On Fri, 2011-09-09 at 21:53 -0700, tony mancill wrote: > Sponsored. Thankyou! -- James Page Ubuntu Server Developer signature.asc Description: This is a digitally signed message part
Re: RFS: jenkins-commons-jexl 1.1-hudson-20090508-1 (new)
On Thu, 2011-09-08 at 22:51 -0700, tony mancill wrote: > Uploaded. Thankyou! -- James Page Ubuntu Server Developer signature.asc Description: This is a digitally signed message part
Re: RFS: lucene3
On Mon, 2011-09-05 at 23:49 +0100, Mat Scales wrote: > Hello all, > > I'm still looking for a sponsor for lucene3: Hi Mat I'm unable to sponsor your package but I do have the following feedback: 1) FTBFS on javadoc warnings I was unable to get the package to build as is; the lucene build is configured to fail on any javadoc warnings - adding -Dfailonjavadocwarning=false to the ant call in debian/rules worked around this issue and is probably a sensible default anyway. 2) debhelper + javahelper I noticed that you have used .install and .links files to install and link the jar files into /usr/share/java - I would recommend that you use the javahelper package as it does alot of this work for you and will deal with new upstream release numbers etc.. See file:///usr/share/doc/javahelper/tutorial.html (when you have it installed :-)). 3) Repack of orig.tar.gz The upstream tarball has been repacked to removed bundled libraries etc.. and given the package a +dfsg version number - however this is not done automatically through debian/watch or documented in the packaging. I would recommend looking at automating this process - makes it easier to pickup future upstream releases. jh_repack might do enough for you - you can plumb it into the watch file. I also don't believe that you really *NEED* to have the +dfsg version number if you are just stripping our bundled jar files - anyone else please feel free to correct me if this is not the case. You can also use the git repo to store an upstream and pristine-tar branch which makes life easier for sponsors - see http://wiki.debian.org/Java/JavaGit for more details. 4) liblucene2-java Conflicts on -java packages IMHO it would be better if lucene2 and lucene3 could co-exist on the same system - they are just libraries so appropriate naming (which could complicate point 2) i.e. lucene3.jar would be possible. I'd like to see this package in Debian as I want to look at packaging OpenGROK which depends on lucene3 so it would be great if someone could sponsor. HTH Cheers James -- James Page Ubuntu Server Developer signature.asc Description: This is a digitally signed message part
RFS: jenkins-commons-jelly 1.1-jenkins-20110627-1 (new)
Hi Team I am looking for a sponsor for my new package "jenkins-commons-jelly". * Package name: jenkins-commons-jelly Version : 1.1-jenkins-20110627-1 * URL : http://github.com/jenkinsci/jelly * License : Apache-2.0 Section : java The upload would fix this bug: http://bugs.debian.org/634657 My motivation for maintaining this package is that it is a dependency of Jenkins. I have uploaded to git.debian.org: - ssh://git.debian.org/git/pkg-java/jenkins-commons-jelly.git - http://git.debian.org/?p=pkg-java/jenkins-commons-jelly.git It would be great if someone could review and upload this package for me. Thanks James -- James Page Ubuntu Server Developer -- 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/20110919091412.BFD0B4634B@hendrix.shouse.local
RFS: jenkins-xstream 1.3.1-jenkins-9-1 (new)
Hi Team I am looking for a sponsor for my new package "jenkins-xstream". * Package name: jenkins-xstream Version : 1.3.1-jenkins-9-1 * URL : https://github.com/jenkinsci/xstream * License : BSD Section : java The upload would fix this bug: http://bugs.debian.org/634655 My motivation for maintaining this package is that it is a dependency of Jenkins. I have uploaded to git.debian.org: - ssh://git.debian.org/git/pkg-java/jenkins-xstream.git - http://git.debian.org/?p=pkg-java/jenkins-xstream.git It would be great if someone could review and upload this package for me. Thanks James -- James Page Ubuntu Server Developer -- 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/20110919094850.BA1B546351@hendrix.shouse.local
