Bug#734011: Can’t build a package using closure-compiler

[tony mancill]

On 01/03/2014 07:55 AM, David Prévot wrote:
> Hi,
> 
> Le 03/01/2014 11:34, tony mancill a écrit :
>> On 01/02/2014 08:46 PM, Ben Finney wrote:
>>> On 02-Jan-2014, David Prévot wrote:
> 
>>>> Calling closure-compiler inside pbuilder or sbuild (e.g. from d/rules)
>>>> fails with:
>>>>
>>>> 	run-detectors: unable to find an interpreter for /usr/bin/closure-compiler
> 
>> […] I'll try to figure out
>> what's going on with jarwrappers.  The only change with -4 upload is to
>> depend on jarwrappers.
> 
> Haven’t double checked (so I don’t tag it directly with “found
> 20130227+dfsg1-3”), but I’m pretty sure I ran into this bug with -3, and
> only filled it against -4 after trying to understand it.

Hi David,

I'm seeing the same behavior with other packages that depend on
jarwrapper - e.g. sat4j and logisim.

When I install them into a base sid chroot, they start correctly.  But
when I install them into a chroot that has already has a JDK and a few
other tools installed, the same error is emitted as you're seeing for
closure-compiler:

(jdksid-chroot)$ sat4j
run-detectors: unable to find an interpreter for /usr/bin/sat4j
(jdksid-chroot)$ logisim
run-detectors: unable to find an interpreter for /usr/bin/logisim

Focusing on just jarwrappers, in the "good" case (base sid install),
update-binfmts is successful:

> (sid-chroot) apt-get install jarwrapper
> [...]
> The following extra packages will be installed:
>   binfmt-support fastjar init-system-helpers libpipeline1
> The following NEW packages will be installed:
>   binfmt-support fastjar init-system-helpers jarwrapper libpipeline1
> [...]
> Setting up binfmt-support (2.1.1-1) ...
> update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
> invoke-rc.d: policy-rc.d denied execution of start.
> Setting up fastjar (2:0.98-5) ...
> Setting up jarwrapper (0.45) ...
> update-binfmts: warning: jarwrapper already enabled in kernel.

And I think more to the point, /var/lib/binfmts/jarwrapper exists.

> (sid-chroot) ls -al /var/lib/binfmts/
> total 12
> drwxr-xr-x  2 root root 4096 Jan  4 04:32 .
> drwxr-xr-x 14 root root 4096 Jan  4 04:32 ..
> -rw-r--r--  1 root root   64 Jan  4 04:32 jarwrapper

And is registered with binfmts:

> (sid-chroot) update-binfmts --display jarwrapper
> jarwrapper (enabled):
>      package = <local>
>         type = magic
>       offset = 0
>        magic = PK\x03\x04
>         mask = 
>  interpreter = /usr/bin/jarwrapper
>     detector = /usr/bin/jardetector

Attempting the same in the non-base sid chroot (still stock sid, but
just created a while back with the JDK already installed), the
jarwrapper postinst output is different:

> (jdksid-chroot) apt-get install jarwrapper
> [...]
> The following extra packages will be installed:
>   binfmt-support fastjar init-system-helpers
> The following NEW packages will be installed:
>   binfmt-support fastjar init-system-helpers jarwrapper
> [...]
> Setting up binfmt-support (2.1.1-1) ...
> update-binfmts: warning: python3.3 already enabled in kernel.
> update-binfmts: warning: found manually created entry for python2.7 in /proc/sys/fs/binfmt_misc; leaving it alone
> update-binfmts: warning: found manually created entry for jar in /proc/sys/fs/binfmt_misc; leaving it alone
> update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
> invoke-rc.d: policy-rc.d denied execution of start.
> Setting up fastjar (2:0.98-5) ...
> Setting up jarwrapper (0.45) ...
> update-binfmts: warning: found manually created entry for jarwrapper in /proc/sys/fs/binfmt_misc; leaving it alone

And no entry is created for jarwrapper, so the magic number for jars
isn't known to run-detectors.

> (jdksid-chroot) ls -al /var/lib/binfmts/
> total 12
> drwxr-xr-x  2 root root 4096 Jan  4 04:31 .
> drwxr-xr-x 19 root root 4096 Jan  4 04:31 ..
> -rw-r--r--  1 root root   57 Jan  4 04:31 python3.3

update-binfmts agrees...

> (jdksid-chroot) update-binfmts --display jarwrapper
> update-binfmts: warning: jarwrapper not in database of installed binary formats.
> update-binfmts: exiting due to previous errors

It doesn't appear to be related to the most recent update to
binfmt-support because I see the same behavior in jessie as on sid if I
install default-jre *before* installing jarwrapper and binfmt-support.
Put another way, it seems to boil down to whether binfmt-support and
jarwrapper are able to be configured before the JRE/JDK/java-common
packages.

If jarwrapper is installed first, we have this situation:

$ update-binfmts --display jarwrapper
jarwrapper (enabled):
     package = <local>
        type = magic
      offset = 0
       magic = PK\x03\x04
        mask =
 interpreter = /usr/bin/jarwrapper
    detector = /usr/bin/jardetector

But the "jar" binfmt is unhappy:

$ update-binfmts --display jar
update-binfmts: warning: jar not in database of installed binary formats.
update-binfmts: exiting due to previous errors

Reverse the order of package installation, and you get this:

$ update-binfmts --display jarwrapper
update-binfmts: warning: jarwrapper not in database of installed binary
formats.
update-binfmts: exiting due to previous errors

$ update-binfmts --display jar
jar (enabled):
     package = openjdk-7
        type = magic
      offset = 0
       magic = PK\x03\x04
        mask =
 interpreter = /usr/bin/jexec
    detector =

In any event, I feel pretty confident that this bug doesn't belong to
libclosure-compiler-java, but instead with jarwrappers and/or openjdk-7,
although it's going to take some more digging to figure out what to do
about two packages trying to register the same magic number with
binfmt-support.  (Colin, I hope that you don't mind that I added you to
the cc:  I thought you could probably say right off whether its feasible
to have two packages trying to use binfmt-support in this manner.)

Perhaps jarwrapper's days are numbered, and we should count on jexec,
but that may require that we have openjdk on all architectures - I'm not
sure...

Thank you,
tony

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-java-maintainers/attachments/20140103/3412ad45/attachment-0001.sig>