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
signature.asc
Description: OpenPGP digital signature
