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

[Colin Watson]

On Fri, Jan 03, 2014 at 09:49:09PM -0800, tony mancill wrote:
> On 01/03/2014 07:55 AM, David Prévot wrote:
> > 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:

The behaviour of binfmt_misc in conjunction with chroots is often a bit
hard to understand; although the kernel will execute the interpreter
in the same chroot context as the original executable, there's only one
/proc/sys/fs/binfmt_misc instance for the whole system right now, so the
interactions can be confusing.  You can largely get away with it as long
as things don't conflict ...

> > Setting up jarwrapper (0.45) ...
> > update-binfmts: warning: jarwrapper already enabled in kernel.

This implies that jarwrapper was already installed in the base system.

> 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

This is basically the same underlying error at a slightly different
point.

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

Right, hmm.  Possibly we're bailing out a bit early.  I think I see the
problem, but this is non-trivial enough that I'd like to track it
properly; could you please file a bug against binfmt-support for me, and
attach tarballs of /usr/share/binfmts/ and /var/lib/binfmts/ from the
various chroots, plus a tarball of /proc/sys/fs/binfmt_misc/ (will be
the same in all filesystem contexts)?

> 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 = 
> 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 =

The error messages you cite above relate to whether the binfmt *name* is
already registered with binfmt_misc, which shouldn't have anything to do
with whether they use the same magic number or not.  The c

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 = 
> 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 = 
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 p

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

[David Prévot]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

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.

Regards

David


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)

iQEcBAEBCAAGBQJSxt19AAoJEAWMHPlE9r08WVMH/3kc+ns1BFc3+yiq/zzbxQmO
DsFTWgeJrTrH/vIk8sbNkwyjo4K4OAvjgKge5rtLxh/K1mNUwEOf0045AzY0qMZE
EHSIusV4U6C7iIL/yj2sK2Ab3a2DxQI6kb3jbyc+vghSGgsZfJVT+wLn1ChPeGQV
2hghTJtaEsr4C9wFBx9bQjC60xtBAjAqrPkmh/OGTZnXEqF6FX6CEpSsvroflvfz
GCkkDagTQHmL5LLrCpmGE2ypyRReekT7GDPoxema8YGLNYliVY81aYzQ3jSnUvWd
mEPu4u49owHyl3kpT4t2Qpze5TKyIadMJPNAc4h/m7kRqUvqZDuY4pSXJDY+Nvw=
=CvLQ
-END PGP SIGNATURE-

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

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

[tony mancill]

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
>>
>> It works fine with debuild, and closure-compiler can even be called
>> without error in a minimal (pbuilder) chroot, but not during a “normal”
>> build.
> 
> I get the same error in a PBuilder chroot:
> 
> run-detectors: unable to find an interpreter for /usr/bin/closure-compiler
> 
> And even when invoking the command from a plain prompt in the chroot:
> 
> # /usr/bin/closure-compiler 
> run-detectors: unable to find an interpreter for /usr/bin/closure-compiler
> 
> Since this now breaks when using a number of package build tools, this bug
> is IMO an “important” severity.

Odd, I don't see that error when installing into a clean sid chroot, but
I do see it when installing into my "jdk" chroot, which already has a
JDK (and I presume jarwrappers) installed.  I'll try to figure out
what's going on with jarwrappers.  The only change with -4 upload is to
depend on jarwrappers.

Thanks for the bug report.
tony




signature.asc
Description: OpenPGP digital signature
__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

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

[David Prévot]

Package: libclosure-compiler-java
Version: 20130227+dfsg1-4
Severity: normal
Control: block 733880 by -1

Hi,

Thanks Tony for uploading a package fixing #705565.

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

It works fine with debuild, and closure-compiler can even be called
without error in a minimal (pbuilder) chroot, but not during a “normal”
build.

Regards

David

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 
'oldstable'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.12-1-rt-amd64 (SMP w/1 CPU core; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libclosure-compiler-java depends on:
ii  default-jre-headless  1:1.7-50
ii  jarwrapper0.45
ii  libandroid-json-org-java  20121204-20090211-1
ii  libargs4j-java2.0.25-1
ii  libguava-java 15.0-2

libclosure-compiler-java recommends no packages.

Versions of packages libclosure-compiler-java suggests:
pn  libclosure-compiler-java-doc  

-- no debconf information


signature.asc
Description: Digital signature
__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

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

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> package libclosure-compiler-java
Limiting to bugs with field 'package' containing at least one of 
'libclosure-compiler-java'
Limit currently set to 'package':'libclosure-compiler-java'

> severity 734011 important
Bug #734011 [libclosure-compiler-java] Can’t build a package using 
closure-compiler
Severity set to 'important' from 'normal'
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
734011: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734011
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

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

[Ben Finney]

package wnpp
block 726171 by 734011
severity 734011 important
thanks

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
> 
> It works fine with debuild, and closure-compiler can even be called
> without error in a minimal (pbuilder) chroot, but not during a “normal”
> build.

I get the same error in a PBuilder chroot:

run-detectors: unable to find an interpreter for /usr/bin/closure-compiler

And even when invoking the command from a plain prompt in the chroot:

# /usr/bin/closure-compiler 
run-detectors: unable to find an interpreter for /usr/bin/closure-compiler

Since this now breaks when using a number of package build tools, this bug
is IMO an “important” severity.

-- 
 \  “I find the whole business of religion profoundly interesting. |
  `\ But it does mystify me that otherwise intelligent people take |
_o__)it seriously.” —Douglas Adams |
Ben Finney 


signature.asc
Description: Digital signature
__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Processed (with 1 errors): Re: Bug#734011: Can’t build a package using closure-compiler

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> package wnpp
Limiting to bugs with field 'package' containing at least one of 'wnpp'
Limit currently set to 'package':'wnpp'

> block 726171 by 734011
Bug #726171 [wnpp] ITP: libjs-zxcvbn -- realistic password strength estimation
726171 was blocked by: 726294 705565
726171 was not blocking any bugs.
Added blocking bug(s) of 726171: 734011
> severity 734011 important
package: "libclosure-compiler-java"' does not match at least one of "wnpp"
Failed to set severity of Bug 734011 to important: limit failed for bugs: 
734011.

> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
726171: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=726171
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.