Re: Debian Java policy update
Pablo Duboue wrote: > > > While looking into the right answer for Bug #554877 > (/usr/share/jetty/webapps or /usr/share/java/webapps ?) I found the > posted > Java policy is really out of date: > > http://www.debian.org/doc/packaging-manuals/java-policy/ > > It seems to focus on pre Open-JDK issues and it is lacking more recent > information about, for example, how to detail with > architectures where there is no Open-JDK (e.g., [1]). > > How can we go about updating this policy document in an efficient manner? > > (A wiki with a working version and yearly review could work, but > that's just a proposal). > > Best regards, > > Pablo > > [1] http://lists.debian.org/debian-java/2009/12/msg00107.html > Hi I have been working on this myself - you may want to check the bugs for the "java-common" package; it has all the suggested changes as well as my last draft (a month or 3 old now). I have been working on a second draft; though I have not been giving it too much attention lately. I will see if I cannot get it completed before Christmas. ~Niels signature.asc Description: OpenPGP digital signature
Debian Java policy update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 While looking into the right answer for Bug #554877 (/usr/share/jetty/webapps or /usr/share/java/webapps ?) I found the posted Java policy is really out of date: http://www.debian.org/doc/packaging-manuals/java-policy/ It seems to focus on pre Open-JDK issues and it is lacking more recent information about, for example, how to detail with architectures where there is no Open-JDK (e.g., [1]). How can we go about updating this policy document in an efficient manner? (A wiki with a working version and yearly review could work, but that's just a proposal). Best regards, Pablo [1] http://lists.debian.org/debian-java/2009/12/msg00107.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCAAGBQJLJyYPAAoJEMJ09r9KJ69qXn4P/3bIXOO7jfcWS1D5hpVCqJwx JU/bwF5HdysnTSi0XNl7Em+MoeCMxS+0+MZHR7NtmhnHbaY3f6YGOT+5A1SLrWE3 Tj9xHg7b7nXU7Tbv6GrYoNI9+zVVKUdpZ5SDGepGjMz7rrC5IMFblmZD+/iFgIkD fXxzpnOzWNB9KVYWlm6MV01HR/JBBtq6RngMUhIufZGGX22bNxMpl1thWTsPqYeW PHR+ArPr5tkz7oQ9l33y3O5rD7tFzai6rvnqAACW5+uvlq4jcz4R49oxzhEadn9A OFJo64stnoRSOMKsfsPnWFvX9d3PZUBCZKyMq6G38K57YOIIiho5KFK56EVV3rca 41pDbzWY7T9Uw4dv0rBGbNAbXEiC+ZOa7ylDfSKqq8I3zfQSQAT2GbPkBRisqGm9 Jx0HLzLlcF+5Ey9JOavacthvwnyEADsLZaldnAkWPc2D4eXwN/KZUXpeIf3JXcU3 EK0P0FKqSq5+QFXu6xlbx5SxfzTLurA90+7/NmHdE2R+Ad0CMp2hiH6siAPPj8aK XIKN2ISjdJ6rlg1IO9La1K9GIlmEIuK9ISup1sCE0j+tbHCN9kR5XJ6UwddWfxqa SmyYCpzk5JgGkPS6a2fepJggT/AysI2zzcb1mVSBatIAO/2yhu5jqugMfFd9caJu 2JjDqoDFh3X+O3lvmJpl =oPvW -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Generating External bundle-classpath on the fly?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 There was a posting [1] in the Eclipse linuxtools-dev mailing list about External bundle-classpath entries that might be quite relevant for us. The idea would be to generate the bundle-classpath based on the dependencies of the Debian packages. There are many ways this can be done at different moments in time. The most off-hands one would be to have a "bundle-classpath" manager package that packages needing the bundle-classpath information depend on and that will generate the bundle-classpaths (if needed) upon package install. (Another option is to create something like dh_java_bundle.) The granularity is of course different and we will be including too many dependencies unnecessarily but it is a balancing act. (Projects needing the bundle-classpath vs. projects required to add the bundle-classpath.) Any ideas? Comments? [1] http://dev.eclipse.org/mhonarc/lists/linuxtools-dev/msg00286.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCAAGBQJLJyPDAAoJEMJ09r9KJ69qMGEP/0HU09zUdU1jkB1TMkWQr8DV x4BIKYgcr+JR2gbqPl3nWZvRo3JV06fqcdVAbL9ZQicpxb/YerkXAsdI6GreIPbI KpcdbqaWrNXdrKwQ3yHql/IXlun62cDjsn/OesYivJJkazIeIfEsqvDlRMGYj3Ak ycPQAyx0b/iaRS9fdX4ZghGBZQsh0hOsN1mxXc1QCBROf0zDJBX1wq8E/Qp2me3h AAcjQ3WmnqI0yVfFJ9zW+BLYNV8p+dM5D+OUBSTbkOxEq2TTFDS8vIVi68hYwyTs /6oMyAbwgKAJD98c249nq9w8rqoQ5AeliA0PPhxD8ehom/xNIZCzyhzRnJ2cYMYp oVLEST01lspI7HgOUdiPpv+hhcoNRFSRGFRWTsd2+QIc+oLUv4VueuYJoLQkVJAY y1wEURiwVFCPxRz8LUqeuIXaqyeP6jUoHIrCtCsTWPKtehxjp1KQXvj6Sd9EIlPY eZveOEJlE07/wgMR2MTT3c6jUNfv2lk4gPPFEQD4UAjmDdL9pRTTpbaGCsWqzI3v uW1QIxnjvwQa6BH672kXJupmZmF9rLSvnWMcEmRWNhEJqbj1BrSfpBrvVYKGpoWz vvwjpffZObJy/f2vULuS6dHSga+DyJj9UL2j3YoN8unftN4b0O1TlTxmOF1siuFW WLbLbn0t1/rR+yT8vMej =D9Ws -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: Jetty 6.1.22 with OSGi bundles MANIFEST.MF committed into pkg-java svn
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 >> * According to #554874, the comment in jetty.default is wrong, it >> should say "set it to 0.0.0.0 to listen to all >> interfaces". I can look further into this and try to close that bug, too. > > That would be great yes. OK, so I'll leave the Eclipse testing to you, and I'll be working on getting this bug and (..) > As I recall 6.1.22 is supposed to fix a security issue (one of the two > RC+security bugs); we should have that verified. (...) these other two bugs. First, for the real CVE (Bug #553644), this bug affects 6.1.21. Niels had some Fedora patches in pkg-java svn trunk that fixed that bug. I manually checked that these changes are present in 6.1.22 upstream. I'll still do a second round reading the CVE before marking it as pending. That still leaves the "CVE-that-happened-and-was-solved-before-we-even-packed-that-project" issue. [1] I am tempted to audit the code to close that bug and concurrently do a post in security to ask for some policy decision. I agree there is absolutely no "reasonable doubt" that merits performing such audit and many projects will fall into that situation. OTOH Torsten has made the case that working on this is a waste of resources (I wonder if security will allow us to downgrade the bug to 'wishlist' and rename it to "audit the code for being really sure CVE-2007-6672 doesn't affect us"). I just don't like reading "Tags: security, wontfix", it might scare away potential users of the package ;-) Regards, Pablo [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559765 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCAAGBQJLJxpiAAoJEMJ09r9KJ69qsXkQAMyJHTelRpTX4eWFAT7dhv3U mjC93O/gIPSzSn1QgwXlWRbcvnAsW9N9xhmkq8NN7cEERl0YGFKQrttX2AGHzgWe KhhmKck07GgTwOFiq2Ux0Z2/9n8giTQINrSnKyWPkdnfFWtZbONXfaATcTRr3XnF EHkjz8WXkZOlQul2zqkZbI8K88l0dycBbnJIqSil4Tid5Um9UZ9uPdzmhea2AQPk CD6fEK8HwM/6WIxgqDNbFH3NHRNxeaPAj+5t2gjbkS/t+cYdPOBQJinORSQci9Cl L6djhhBqxZUmmb4ccizmSV7WeRlkZjHwa5I+YyVXy2Z5oyUz5pp/HCJq7p9gSZwp s4oSDM8p3yO9avbhPwbKE/hXS6IaMONv2p9Vc6zaHrNi4ON5nNIbjEnL7mkameb/ O6dSpxgVpm1MvvDWQkHZgOEOzuFFcpqL1J1EQ0RKKVmlVNbtom4Y02Hu5uu0i2Qc Ll9qeHAOXjA1/N7BQrwtz3XpF/xT/o8wTosH07ATzojknzrAS/AJTjHCh3qxXkmv WUcsKgeWJWUS7zPigGuGM4WIZZrqphkNoDszv/3JKW6FEGOo9EO9GIOLcLTn1uGs CPLVf4AOsAyCoZq3196mVAzEGeheyz7C+3B1OxNH+QDQXaa7i82O9wofRICcDWbG mmz37Ibv9RCLlJszRjKd =w89B -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: Jetty 6.1.22 with OSGi bundles MANIFEST.MF committed into pkg-java svn
Thanks for your work. > The current package fetches the sources from upstream SVN just fine > and builds correctly into a pbuilder > chroot. >=20 Could I have you upload (or send me a copy of) the orig.tar.gz somewhere? I get a different orig.tar.gz every time I use debian/rules get-orig-source And (unsurprisingly) everyone of them FTBFS. > Two questions: >=20 > * According to #554874, the comment in jetty.default is wrong, it > should say "set it to 0.0.0.0 to listen to all > interfaces". I can look further into this and try to close that bug, to= o. >=20 That would be great yes. > * Before going through the relative pain of finding a sponsor to > upload this into unstable, how can we verify > the new package actually helps with the Eclipse effort? >=20 We can build test eclipse with it without getting uploaded. You are welcome to try it; though you have to tell eclipse to use the jetty system jar - poll me if interested. As I recall 6.1.22 is supposed to fix a security issue (one of the two RC+security bugs); we should have that verified. > Thanks go to Niels for quite a bit of help and to upstream for > providing the MANIFEST.MF files. >=20 > Best regards, >=20 > Pablo ~Niels signature.asc Description: OpenPGP digital signature
Re: Bug#559967: FTBFS [hppa]: method openConnection() in the type URL is not...
On 12/14/2009 04:58 PM, dann frazier wrote:
> On Fri, Dec 11, 2009 at 02:10:18PM +0530, Onkar Shinde wrote:
>> AFAIK, GCJ uses classpath library these days. The code from classpath
>> is being merged in GCJ. And from the status of classpath [1] it is
>> clear that java.net.URL.openConnection(java.net.Proxy) does not exist
>> in classpath implementation.
>> This can be easily tested. Try compiling following code with GCJ and
>> OpenJDK. GCJ fails to compile the code but OpenJDK works fine.
>>
>> ***
>> import java.net.*;
>>
>> public class Hello {
>> public static void main (String args[]){
>> try {
>> URL url = new URL("http://www.google.com";);
>> url.openConnection(Proxy.NO_PROXY);
>> } catch (Exception e) {
>> e.printStackTrace();
>> }
>> }
>> }
>> ***
>>
>> Hence this is a tool chain issue and not issue in package
>> libxmlrpc3-java itself. As of now there is nothing package maintainer
>> can do except disabling building of the package for all arch that use
>> GCJ as default compiler (to unblock the transition to testing).
>
> Onkar,
> Thanks for looking into this.
>
> Would you mind filing a bug against the appropriate toolchain package,
> and setting a 'blocks' in the bug tracking system? This would make it
> easy to lookup the history/status of this issue next time someone
> notices it.
>
> Also, I believe the appropriate way to avoid having this bug block
> testing migration is to request the removal of hppa binaries from
> testing. Once no hppa binaries exist in testing, we can reduce the
> severity of this issue to "important", which is not release critical.
>
> I'd suggest *not* disabling building on gcj-archs because, presumably,
> this bug will be fixed at some point and we could then provide hppa
> binaries without updating each affected source package.
Fixing it properly will be hard, since AFAICS Classpath doesn't have support
for web proxies. But does this package actually *need* proxy support
to work? If not, it's easy to work around the problem with a simple patch
for the application. I can give advice if you like.
Andrew.
--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#559967: FTBFS [hppa]: method openConnection() in the type URL is not...
On Fri, Dec 11, 2009 at 02:10:18PM +0530, Onkar Shinde wrote:
> AFAIK, GCJ uses classpath library these days. The code from classpath
> is being merged in GCJ. And from the status of classpath [1] it is
> clear that java.net.URL.openConnection(java.net.Proxy) does not exist
> in classpath implementation.
> This can be easily tested. Try compiling following code with GCJ and
> OpenJDK. GCJ fails to compile the code but OpenJDK works fine.
>
> ***
> import java.net.*;
>
> public class Hello {
> public static void main (String args[]){
> try {
> URL url = new URL("http://www.google.com";);
> url.openConnection(Proxy.NO_PROXY);
> } catch (Exception e) {
> e.printStackTrace();
> }
> }
> }
> ***
>
> Hence this is a tool chain issue and not issue in package
> libxmlrpc3-java itself. As of now there is nothing package maintainer
> can do except disabling building of the package for all arch that use
> GCJ as default compiler (to unblock the transition to testing).
Onkar,
Thanks for looking into this.
Would you mind filing a bug against the appropriate toolchain package,
and setting a 'blocks' in the bug tracking system? This would make it
easy to lookup the history/status of this issue next time someone
notices it.
Also, I believe the appropriate way to avoid having this bug block
testing migration is to request the removal of hppa binaries from
testing. Once no hppa binaries exist in testing, we can reduce the
severity of this issue to "important", which is not release critical.
I'd suggest *not* disabling building on gcj-archs because, presumably,
this bug will be fixed at some point and we could then provide hppa
binaries without updating each affected source package.
--
dann frazier
--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Jetty 6.1.22 with OSGi bundles MANIFEST.MF committed into pkg-java svn
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I have committed to the current trunk (r11288) for jetty in pkg-java svn an upgrade to the latest version (6.1.22); plus Niels' fix for #554877; plus the OSGi blundles MANIFIEST.MFs we need for Eclipse (closes #558187). The current package fetches the sources from upstream SVN just fine and builds correctly into a pbuilder chroot. Two questions: * According to #554874, the comment in jetty.default is wrong, it should say "set it to 0.0.0.0 to listen to all interfaces". I can look further into this and try to close that bug, too. * Before going through the relative pain of finding a sponsor to upload this into unstable, how can we verify the new package actually helps with the Eclipse effort? Thanks go to Niels for quite a bit of help and to upstream for providing the MANIFEST.MF files. Best regards, Pablo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCAAGBQJLJgXMAAoJEMJ09r9KJ69qlt8P/0+8OxLqEeh3Kwz1MxiIN4Zq IzvsMDpNTIe9doTs0OBaqwRKJ/7qkdVtb02rBxhde7JzjcIz2UM+SecSDmhgwfU4 7nFjkFDB4J9wFJi14njjrMaKR/3cJVNAhCt0Pt8DPXLKuxqC/eb9HXjSaOUwAwa/ O5hoB9vo1FDwpadQOW75+E1zuAHrYE8pp4iZ38GwtbW3Su4ERqyROIUKlCbwBHHE FJ++hi/rZBTneWqT3c9hur8+EPUwcK22/sen2Ti1jdxl0zfNWePeR/AdTaHcdTkq uoECbuc/4Qe/uGY5QJ3G0ESteI5CD+LsDCJG8WQuDK5f8qxiyj0cU3CnPgfDc8jN rJSg/+nnMqfwn8ZuUO84OdxS8ZTQCsEUYie6XhVgovsVflEOBH221JTWsl3VwmYK FMUt5kjwcIR8wD9VCUbZTtEZobHoeRfOilWAM67ojKxm8svvNGOBIra1WRlkx0+V zByxPlFthtBDeXmFane7k/MFTvYMfB+Ulxs8yBR03qGWf/+uCEVlnrRkFxJvsTCY Ht2XzeKtVYAYz70QrxyamE8+L9yN37/EtVoncmgGYGMnr02cJ/pxJPuO+ARhrCsN 4HQKNCFymd5+/dBTeYasuhZR2PzGcsZtQIclMEKGbdYZe3vNlNGpzSCHLcqwMgFz x7NGsrBv0m+A15EYCctW =V2z7 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
