Re: Upgrading jffi to 1.2.7
On Fri, Jan 23, 2015 at 05:48:29AM +, Potter, Tim (Cloud Services) wrote: > Hi everyone. I’ve finally beat the packaging bug I had for the latest > version of jffi. Just wondering what to do with it next - should I > just splat it on top of the existing jffi version (1.0.2 - very old). > The jffi package is a dependency for a handful of jnr-* packages > required by the latest JRuby. > > I’ve uploaded the new packaging as jffi-1.2.7 to the pkg-java > repository: > > http://anonscm.debian.org/cgit/pkg-java/jffi-1.2.7.git/ > > There’s also a jffi-1.2.6 version which hasn’t been packaged properly > and is nearly two years old. Can we delete that at some stage? Hi Tim, In terms of the packaging repo, there's no reason not to use the existing jffi repo [1]. All of the packaging history is there and intact as tags for both the debian and upstream versions. If you'd like a review of the packaging before the import, I'll be happy to do that. Then we can git-import-dsc your package into jffi.git (or get fancy if you'd like to preserve individual commits from your workflow on 1.2.7) and upload to experimental. Looking at /git/pkg-java/, jffi is definitely well-represented: tmarble-guest Mar 18 2013 jffi-1.2.6.git tpot-guest Jan 23 01:43 jffi-1.2.7.git twernerMar 18 2013 jffi.git tpot-guest Nov 26 05:38 jnr-jffi.git It looks like we can drop at least jnr-jffi.git and jffi-1.2.7.git once we've merged into jffi.git. (And unless Tom yells, we can drop jffi-1.2.6 too.) Cheers, tony signature.asc Description: Digital signature
Upgrading jffi to 1.2.7
Hi everyone. I’ve finally beat the packaging bug I had for the latest version of jffi. Just wondering what to do with it next - should I just splat it on top of the existing jffi version (1.0.2 - very old). The jffi package is a dependency for a handful of jnr-* packages required by the latest JRuby. I’ve uploaded the new packaging as jffi-1.2.7 to the pkg-java repository: http://anonscm.debian.org/cgit/pkg-java/jffi-1.2.7.git/ There’s also a jffi-1.2.6 version which hasn’t been packaged properly and is nearly two years old. Can we delete that at some stage? Tim. -- 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/cfe711c8-4f7e-4208-a9e4-811162555...@hp.com
Bug#776020: ITP: invokebinder -- Java DSL for binding method handles
Package: wnpp Severity: wishlist Owner: Miguel Landaeta * Package name: invokebinder Version : 1.5 Upstream Author : Charles Oliver Nutter * URL : https://github.com/headius/invokebinder * License : Apache-2.0 Programming Lang: Java Description : Java DSL for binding method handles This Java library hopes to provide a more friendly DSL for binding method handles. . Unlike the normal MethodHandle API, handles are bound forward from a source MethodType and eventually adapted to a final target MethodHandle. . Along the way the transformations are pushed onto a stack and eventually applied in reverse order, as the standard API demands. This is packaged since is a dependency of JRuby 1.7.x and upcoming 9.0.0.0 releases. -- 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
Bug#776016: ITP: libcoro-mock-java -- Mock library for compiling JVM coroutine-utilizing code on JVMs without coroutines
Package: wnpp Severity: wishlist Owner: Miguel Landaeta * Package name: libcoro-mock-java Version : 1.1-SNAPSHOT Upstream Author : Charles Oliver Nutter * URL : https://github.com/headius/coro-mock * License : Public domain Programming Lang: Java Description : Mock library for compiling JVM coroutine-utilizing code on JVMs without coroutines coro-mock is a trivial mock Java library that can be used to compile code on JVMs without coroutines feature. . The main usage of this library is on JRuby related code. -- 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: OpenJDK 8 vs Zulu
On 01/22/2015 02:23 PM, Paul Wise wrote: > On Thu, Jan 22, 2015 at 10:11 PM, Andrew Haley wrote: >>> On Mon, Jan 19, 2015 at 10:41 PM, Andrew Haley wrote: >>> That would be against the rules AFAICR: you're supposed to do your own TCK runs, and not on behalf of someone else. >>> >>> How do automated builds factor into that? >> >> I don't think it makes any difference. But IANAL, and you'd have to >> read the TCK agreement for more information. > > I mean, if an automated system builds the binary packages rather than > a human developer, who is allowed to test those packages? Ah, I see the confusion. By "you" I mean "you" as in Debian; i.e. an organization is supposed to use the OpenJDK TCK to test the binaries they ship. I don't think that people or organizations are allowed to set up a "TCK testing service" for other people's OpenJDK builds. But, again, IANAL: the details are in the TCK agreement. Andrew. -- 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/54c109e8.3080...@redhat.com
Re: Re: OpenJDK 8 vs Zulu
On Thu, Jan 22, 2015 at 10:11 PM, Andrew Haley wrote: >>On Mon, Jan 19, 2015 at 10:41 PM, Andrew Haley wrote: >> >>> That would be against the rules AFAICR: you're supposed to do your >>> own TCK runs, and not on behalf of someone else. >> >>How do automated builds factor into that? > > I don't think it makes any difference. But IANAL, and you'd have to > read the TCK agreement for more information. I mean, if an automated system builds the binary packages rather than a human developer, who is allowed to test those packages? -- bye, pabs https://wiki.debian.org/PaulWise -- 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/CAKTje6HJF19xWaSmsiLKaWPefN-jw6N=jj2_h1iepip4x3a...@mail.gmail.com
Re: Re: OpenJDK 8 vs Zulu
>On Mon, Jan 19, 2015 at 10:41 PM, Andrew Haley wrote: > >> That would be against the rules AFAICR: you're supposed to do your >> own TCK runs, and not on behalf of someone else. > >How do automated builds factor into that? I don't think it makes any difference. But IANAL, and you'd have to read the TCK agreement for more information. You can't run a full TCK as part of an automated test anyway, because there are some interacive tests. Andrew. -- 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/54c1051f.80...@redhat.com
