Bug#602362: libjsr166y-java: FTBFS in sid with type parameters ... cannot be determined error

[Miguel Landaeta]

Hi Damien,

On Fri, Nov 5, 2010 at 1:57 PM, Damien Raude-Morvan <drazzib at debian.org> wrote:
> I've checked a bit upstream CVS changelog and it seems jsr166y is in real flux.
>
> [...]
>
> It seems Doug Lea (spec leader) has settle things down recently :
> http://cs.oswego.edu/pipermail/concurrency-interest/2010-September/007420.html
> (sync between jsr166y, jdk6 packages and jdk7 code-copy)
>
> As I see that there is only one Reverse Depends: libgpars-groovy-java for
> libjsr166y-java, I propose to remove those software from testing as they
> doesn't seems suitable for a stable release and continue to work on them in
> unstable for next release.
>
> What's your position on this, Miguel ?

I would like to have libgpars-groovy-java in stable if possible.
That is a stable library used in production.
In fact, that was the reason why I packaged libjsr166y-java in first place.

I know jsr166y is in real flux, I packaged 0.1.20080107 version because
that is the exact version needed by GPars. I suspect GPars development
team is waiting for JDK7 to update their codebase (but I'm just speculating).

Also I'm aware that forkjoin project was refactored and the ParallelArray
class is now located in extra166y package but the problematic code is
still there. So this has to be fixed or just wait for JDK7.

Before asking to remove jsr166y and GPars libraries from testing I would
like to try to find a workaround for that code.

I plan to contact Doug Lea and the concurrency group during the weekend,
probably they can propose a fix for this bug. If not then I will ask the removal
of those packages from testing.

Cheers,

-- 
Miguel Landaeta, miguel at miguel.cc
secure email with PGP 0x7D8967E9 available at http://keyserver.pgp.com/
"Faith means not wanting to know what is true." -- Nietzsche