Re: RFS: jnr-constants
On 28/01/15 2:43 AM, "Miguel Landaeta" wrote: >> Hi everyone. As part of the JRuby 1.7 package update I'd like to >>request >> a sponsor to upload the jnr-constants package at: >> > >I can take care of this. > >BTW, Emmanuel prepared a script to migrate debian-java packages from >svn to git repos some time ago. > >I'd prefer to do this: > >- Migrate libconstantine-java to git. >- Apply your changes on top of it. >- Provide a new binary package libjnr-constants-java. >- Switch libconstantine-java to a dummy transitional package > (depending on libjnr-constants-java, so we don't break jython and > jruby packages). > >After that we can rename the source package. OK - that's a good plan and much better than my idea. Let's do that then. Tim. smime.p7s Description: S/MIME cryptographic signature
Re: Correct dependency for package needing Java 6?
Le 27/01/2015 18:02, Jan Niehusmann a écrit : > As far as I can tell, it's not really java 6 code, but only some > @Override annotations on methods implementing interfaces - which is OK > with java 6 but forbidden with java 5. So I _guess_ the byte code would > be compatible with java 5. Didn't verify that, though. In this case you can try to patch the code and remove the annotations. If no Java 6 API is used it's likely to work. > Java Policy states: "There may be situations, such as with very small > packages, where it is better to bundle the Java code and the native code > together into a single package. Such packages should be > architecture-specific and follow the usual libXXX[version]-java naming > convention." You can do it, but the best practice is to have separate packages. > Any help is appreciated, so if co-maintainership is the best way to go, > I wouldn't mind. It's up to you, you just have to join the pkg-java group on alioth [1] and create a Git repository under /srv/git.debian.org/git/pkg-java (there is a setup-repository script in this directory that can be used to create the repository and setup the hooks properly). Emmanuel Bourg [1] https://alioth.debian.org/projects/pkg-java -- 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/54c7d7e2.2090...@apache.org
Re: Correct dependency for package needing Java 6?
On 01/27/2015 05:35 PM, Thorsten Glaser wrote: > On Tue, 27 Jan 2015, Jan Niehusmann wrote: > >> Yes, sure - I missed that, because I tried the builds in clean chroots, >> where only one JDK was installed. > > Right, of course. > But debian java policy states "Packages must be built with default-jdk". > >> Well at least on some of the gcj architectures, the package can be >> compiled if openjdk is installed (and gcj is not). So I'd prefer to not > > No. The packages must be built with the default JDK, so if > gcj and OpenJDK are available but gcj is the default¹, the > packages must be built with gcj. > > ① I don’t think we’ll ever have this if the OpenJDK is at > all usable on that platform. > > > On Tue, 27 Jan 2015, Emmanuel Bourg wrote: > >>> Yes, that would prevent failing builds, as well. But it will also exclude >>> gcj architectures, as on these, this dependency is not available. >> >> Indeed, but gcj doesn't run Java 6 code, so that's normal. > > Another point for that. > > Architectures with gcj as default have that for a reason… > and one reason alone… OpenJDK is not really usable there. You should start working on cross-building openjdk-8 then, and fix bugs for m68k ... there are a lot of recipies on the net, just add these to the packages. -- 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/54c7cb82.8000...@debian.org
Re: Correct dependency for package needing Java 6?
On Tue, Jan 27, 2015 at 05:31:11PM +0100, Emmanuel Bourg wrote: > Le 27/01/2015 17:11, Jan Niehusmann a écrit : > > > Yes, that would prevent failing builds, as well. But it will also exclude > > gcj architectures, as on these, this dependency is not available. > > Indeed, but gcj doesn't run Java 6 code, so that's normal. As far as I can tell, it's not really java 6 code, but only some @Override annotations on methods implementing interfaces - which is OK with java 6 but forbidden with java 5. So I _guess_ the byte code would be compatible with java 5. Didn't verify that, though. > I got a quick look at the package, libzmq-java should be 'Architecture: > all' and depend on a 'Architecture: any' libzmq-jni package. Java Policy states: "There may be situations, such as with very small packages, where it is better to bundle the Java code and the native code together into a single package. Such packages should be architecture-specific and follow the usual libXXX[version]-java naming convention." Of course 'very small' is not strictly defined, but I think 35 classes in a 48kB jar file qualifies. It's basically just a wrapper around the native zmq library. > Also the Maven artifacts are missing in /usr/share/maven-repo. That's true, and could be fixed for sure. > Would you want to co-maintain the package with the Java team? We can > help you with these details. Any help is appreciated, so if co-maintainership is the best way to go, I wouldn't mind. Jan -- 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/20150127170214.ga29...@jannic.reliablesolutions.de
Re: Correct dependency for package needing Java 6?
On Tue, 27 Jan 2015, Jan Niehusmann wrote: > Yes, sure - I missed that, because I tried the builds in clean chroots, > where only one JDK was installed. Right, of course. > > > But debian java policy states "Packages must be built with default-jdk". > Well at least on some of the gcj architectures, the package can be > compiled if openjdk is installed (and gcj is not). So I'd prefer to not No. The packages must be built with the default JDK, so if gcj and OpenJDK are available but gcj is the default¹, the packages must be built with gcj. ① I don’t think we’ll ever have this if the OpenJDK is at all usable on that platform. On Tue, 27 Jan 2015, Emmanuel Bourg wrote: > > Yes, that would prevent failing builds, as well. But it will also exclude > > gcj architectures, as on these, this dependency is not available. > > Indeed, but gcj doesn't run Java 6 code, so that's normal. Another point for that. Architectures with gcj as default have that for a reason… and one reason alone… OpenJDK is not really usable there. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg -- 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/alpine.deb.2.11.1501271733140.5...@tglase.lan.tarent.de
Re: RFS: jnr-constants
Le 27/01/2015 16:43, Miguel Landaeta a écrit : > BTW, Emmanuel prepared a script to migrate debian-java packages from > svn to git repos some time ago. Here it is: http://anonscm.debian.org/cgit/pkg-java/pkg-java-svn2git.git/ Emmanuel Bourg -- 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/54c7bdf0.9020...@apache.org
Re: Correct dependency for package needing Java 6?
Le 27/01/2015 17:11, Jan Niehusmann a écrit : > Yes, that would prevent failing builds, as well. But it will also exclude > gcj architectures, as on these, this dependency is not available. Indeed, but gcj doesn't run Java 6 code, so that's normal. > In fact, that's the current state: > https://buildd.debian.org/status/package.php?p=jzmq > > So it has the same effect as Thorsten's suggestion. (With the added > benefit that the package will automatically become buildable when an > architecture gets updated to a more recent default-jdk.) I got a quick look at the package, libzmq-java should be 'Architecture: all' and depend on a 'Architecture: any' libzmq-jni package. Also the Maven artifacts are missing in /usr/share/maven-repo. Would you want to co-maintain the package with the Java team? We can help you with these details. Emmanuel Bourg -- 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/54c7bd4f.2070...@apache.org
Re: Correct dependency for package needing Java 6?
Thorsten, Emmanuel, thanks for your answers! On Tue, Jan 27, 2015 at 04:14:04PM +0100, Thorsten Glaser wrote: > On Tue, 27 Jan 2015, Jan Niehusmann wrote: > > > Depending on openjdk-6-jdk or openjdk-7-jdk would probably fix that > > No, as you can install several JDKs. Yes, sure - I missed that, because I tried the builds in clean chroots, where only one JDK was installed. > > But debian java policy states "Packages must be built with default-jdk". > > You could Build-Conflicts on gcj? > > But it would be better to whitelist the OpenJDK architectures > in the Architecture field of your package. That way, the m68k > buildd admins aren’t angry at you for wasting hours of CPU time > to try to install build dependencies for something, only to > abort the build due to Build-Conflicts later. Well at least on some of the gcj architectures, the package can be compiled if openjdk is installed (and gcj is not). So I'd prefer to not exclude them, but to fix the issue somehow. On Tue, Jan 27, 2015 at 04:23:28PM +0100, Emmanuel Bourg wrote: > If your package isn't 'arch: all' you can depend on default-jdk (>= 2:1.6). Yes, that would prevent failing builds, as well. But it will also exclude gcj architectures, as on these, this dependency is not available. In fact, that's the current state: https://buildd.debian.org/status/package.php?p=jzmq So it has the same effect as Thorsten's suggestion. (With the added benefit that the package will automatically become buildable when an architecture gets updated to a more recent default-jdk.) Jan -- 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/20150127161132.ga27...@jannic.reliablesolutions.de
Re: RFS: jnr-constants
On Tue, Jan 27, 2015 at 2:41 AM, Potter, Tim (Cloud Services) wrote: > > Hi everyone. As part of the JRuby 1.7 package update I'd like to request > a sponsor to upload the jnr-constants package at: > I can take care of this. BTW, Emmanuel prepared a script to migrate debian-java packages from svn to git repos some time ago. I'd prefer to do this: - Migrate libconstantine-java to git. - Apply your changes on top of it. - Provide a new binary package libjnr-constants-java. - Switch libconstantine-java to a dummy transitional package (depending on libjnr-constants-java, so we don't break jython and jruby packages). After that we can rename the source package. Cheers, -- Miguel Landaeta, nomadium at debian.org secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key. "Faith means not wanting to know what is true." -- Nietzsche signature.asc Description: Digital signature
Re: Correct dependency for package needing Java 6?
On Tue, 27 Jan 2015, Emmanuel Bourg wrote: > If your package isn't 'arch: all' you can depend on default-jdk (>= 2:1.6). Ah right, good idea. And even if it is, he can do that, even though it won’t hit the buildds. Should, even. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg -- 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/alpine.deb.2.11.1501271641410.5...@tglase.lan.tarent.de
Re: Correct dependency for package needing Java 6?
Le 27/01/2015 15:25, Jan Niehusmann a écrit : > Are there better alternatives? If your package isn't 'arch: all' you can depend on default-jdk (>= 2:1.6). Emmanuel Bourg -- 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/54c7ad70.4000...@apache.org
Re: Correct dependency for package needing Java 6?
On Tue, 27 Jan 2015, Jan Niehusmann wrote: > I'm trying to make a java package build on all debian architectures. As > the source code needs java 6 to compile, it fails on some architectures > when just depending on default-jdk. These are kfreebsd-* and sparc, where > default-jdk installs gcj instead of openjdk. And m68k, and a bunch of others. > Depending on openjdk-6-jdk or openjdk-7-jdk would probably fix that No, as you can install several JDKs. > But debian java policy states "Packages must be built with default-jdk". You could Build-Conflicts on gcj? But it would be better to whitelist the OpenJDK architectures in the Architecture field of your package. That way, the m68k buildd admins aren’t angry at you for wasting hours of CPU time to try to install build dependencies for something, only to abort the build due to Build-Conflicts later. bye, //mirabilos (also m68k buildd admin, hint hint) -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg -- 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/alpine.deb.2.11.1501271612110.5...@tglase.lan.tarent.de
Correct dependency for package needing Java 6?
Hi, I'm trying to make a java package build on all debian architectures. As the source code needs java 6 to compile, it fails on some architectures when just depending on default-jdk. These are kfreebsd-* and sparc, where default-jdk installs gcj instead of openjdk. Depending on openjdk-6-jdk or openjdk-7-jdk would probably fix that issue. (jdk 6 would suffice, but as it's already quite old and missing from jessie, depending on openjdk-7-jdk would be better, I guess) Therefore, I'd like to build-depend on openjdk-7-jdk | java-6-sdk. But debian java policy states "Packages must be built with default-jdk". I'd guess that where policy conflicts with reality, reality wins. But still, as I'm not experienced in java packaging, I'd like to hear your opinion. Are there better alternatives? Regards, Jan -- 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/20150127142520.ga8...@x61s.reliablesolutions.de
Re: mh_make and Maven 3.2
Le 27/01/2015 13:01, Stian Soiland-Reyes a écrit : > Thanks for the help. Agreed that as long as Maven plugins are up to > date it should generally work with Maven 2.x. One of the things that > is not upgraded I believe is the Maven reactor (which figures out the > build order) - and we have had trouble with this in the past in > earlier Maven versions. (NPE!) You can give it a try. So far I haven't seen a project that couldn't be built with Maven 2. Most of the time Maven 3 is only used by some reporting plugins that aren't needed in the Debian context. > How should I best put in such a patch for the pom.xml under debian/? > I'm afraid it's ten years ago since I last tried to make a Debian > package by hand.. The patches go in debian/patches. You can create them with quilt. The workflow looks like this: quilt new 01-maven2-compatibility.patch quilt add pom.xml nano pom.xml -> remove the prereq quilt refresh > Well, I'm getting doubtful as to the possibility to get it included in > Debian proper, as it seems to be quite a large job to also package all > the dependencies in newer versions in Debian (as we need them all to > be OSGi bundles), something like jdeb and our own Debian repository at > apache.org is probably an easier workaround. Would jdeb still install > into /usr/share/maven-repo ? If you build a non official package you don't need to install the Maven artifacts under /usr/share/maven-repo. This repository is only used to build other packages. Debian needs that local repository because the Maven artifacts can't be downloaded from Maven Central at build time, but for a non official packages you don't have this constraint. > We have previously used Install4j which makes a crude single-deb [1] > that goes into /opt/taverna*, and I was hoping we could do something > slightly more Debian like and go into /usr/share/maven-repo and > friends, and at least have a debian/ control files and .deb packages > for each of our upstream repositories. What really matters I think is to integrate well with the system for things like manpages, desktop icons, logs, bash completion and init daemon. The location of the files is not very important and /opt/taverna is fine. Emmanuel Bourg -- 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/54c78356.3030...@apache.org
Re: mh_make and Maven 3.2
Thanks for the help. Agreed that as long as Maven plugins are up to date it should generally work with Maven 2.x. One of the things that is not upgraded I believe is the Maven reactor (which figures out the build order) - and we have had trouble with this in the past in earlier Maven versions. (NPE!) How should I best put in such a patch for the pom.xml under debian/? I'm afraid it's ten years ago since I last tried to make a Debian package by hand.. Well, I'm getting doubtful as to the possibility to get it included in Debian proper, as it seems to be quite a large job to also package all the dependencies in newer versions in Debian (as we need them all to be OSGi bundles), something like jdeb and our own Debian repository at apache.org is probably an easier workaround. Would jdeb still install into /usr/share/maven-repo ? We have previously used Install4j which makes a crude single-deb [1] that goes into /opt/taverna*, and I was hoping we could do something slightly more Debian like and go into /usr/share/maven-repo and friends, and at least have a debian/ control files and .deb packages for each of our upstream repositories. [1] http://updates.taverna.org.uk/deb/ On 27 January 2015 at 11:49, Emmanuel Bourg wrote: > Le 27/01/2015 12:34, Stian Soiland-Reyes a écrit : > >> Is there a debian/maven* rule I can add to edit/remove the >> element at build time? > > Hi Stian, there is no such rule but this can be easily patched. Most of > the time Maven 2 is good enough to build the Debian packages. Even if > the core Maven used is old the plugins are more recent and up to the work. > > I don't know if you intend to submit your package to Debian for > inclusion in the official repository, but if this is just a private > package I recommend using jdeb instead, it's easier to use and > integrates well with Maven. > > Emmanuel Bourg > > > -- > 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/54c77b36.7070...@apache.org > -- Stian Soiland-Reyes Apache Taverna (incubating) http://orcid.org/-0001-9842-9718 -- 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/caprnxtkvrxqgwfhseaefkb6puairmjye8rc_b_w6mlauynu...@mail.gmail.com
Re: mh_make and Maven 3.2
Le 27/01/2015 12:34, Stian Soiland-Reyes a écrit : > Is there a debian/maven* rule I can add to edit/remove the > element at build time? Hi Stian, there is no such rule but this can be easily patched. Most of the time Maven 2 is good enough to build the Debian packages. Even if the core Maven used is old the plugins are more recent and up to the work. I don't know if you intend to submit your package to Debian for inclusion in the official repository, but if this is just a private package I recommend using jdeb instead, it's easier to use and integrates well with Maven. Emmanuel Bourg -- 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/54c77b36.7070...@apache.org
mh_make and Maven 3.2
Hi - I've been trying to use mh_make to package a Maven project for Debian. To start light-weight I have begun with just the Maven Parent pom of our project. https://github.com/stain/incubator-taverna-maven-parent/tree/debian after some struggles with the plugins mh_make generated me a nice set of debian/ files: https://github.com/stain/incubator-taverna-maven-parent/tree/debian/debian However, I get this error message in Debian unstable when I try to do: dpkg-buildpackage -b cd . && /usr/lib/jvm/default-java/bin/java -noverify -cp /usr/share/maven2/boot/classworlds.jar:/usr/lib/jvm/default-java/lib/tools.jar -Dproperties.file.manual=/root/src/incubator-taverna-maven-parent/debian/maven.properties -Dclassworlds.conf=/etc/maven2/m2-debian.conf org.codehaus.classworlds.Launcher -s/etc/maven2/settings-debian.xml -Dmaven.repo.local=/root/src/incubator-taverna-maven-parent/debian/maven-repo clean [INFO] NOTE: Maven is executing in offline mode. Any artifacts not already in your local repository will be inaccessible. [INFO] Scanning for projects... [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Unable to build project '/root/src/incubator-taverna-maven-parent/pom.xml; it requires Maven version 3.2.0 This is caused by our pom.xml 3.2.0 and mvn-debian being a decade out of date: root@25d478a1c2a6:~/src/incubator-taverna-maven-parent# mvn-debian -v Apache Maven 2.2.1 (rdebian-16) Is there a plan to update mvn-debian or a way to change my debian/ files to use Maven 3.x? Is there a debian/maven* rule I can add to edit/remove the element at build time? Manually deleting element seems to work for the parent pom - but I suspect Maven 2.2 will struggle with the rest of our source code. I don't want to suggest Maven 2.x for non-Debian users of our code as that would be quite fragile. We might have been overly cautious in specifying 3.2.0 - it might work fine with 3.0, but we have not been testing with such older versions of Maven. -- Stian Soiland-Reyes Apache Taverna (incubating) http://orcid.org/-0001-9842-9718 -- 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/CAPRnXt=+ftrjugaokq-tc-qouwimoegpvbbrx7ku9-7_uwk...@mail.gmail.com
