Bug#1005294: [Pkg-javascript-devel] Bug#1005294: Emscripten attempts to run invalid closure-compiler command

[Jeremy James]

> Yes, this is a known issue, documented in README.Debian:
> https://salsa.debian.org/js-team/emscripten/-/blob/debian/latest/debian/README.Debian#L50
> ...
> Thanks for the suggestion.  I wonder if such change will actually be any
> better: I very much doubt that the horribly old closure-compiler
> available in Debian can do *anything* sensible, but would be happy if
> proven wrong.
>
> Did you test that suggested change, using closure-compiler in Debian?

Well, it certainly can't be worse - this error is caused by the debian
patch! But yes, the packaged closure-compiler from 2013 is somewhat
unsuitable for use generally. In this case, I was hoping to create a
/usr/local/bin/closure-compiler script and use that instead.

If I install that package and explicitly set CLOSURE_COMPILER to
/usr/bin/closure-compiler then I get the inevitable following:

building:ERROR: Closure compiler run failed:
building:ERROR: "--language_out" is not a valid option

If I grab a recent closure-compiler JAR [1] and create a wrapper script:

cat >/usr/local/bin/closure-compiler < Sounds like you have some knowledge/experience here.

To be fair, I'm just trying to get this working for some automated
builds rather than getting deep into the internals of emscripten, but
I really would prefer not to have to create custom versions of tools
like emscripten if at all possible. For example there's another
frustrating issue for parallel builds that it always wants to create
~/.emscripten even if --generate-config is used but that's upstream
and I'll send a bug to them (I do, however, want to use the debian
feature of automatically setting CLANG_ADD_VERSION/LLVM_ADD_VERSION to
save having to install the llvm-defaults related packages).

> I am open to improving README.Debian, but will need help: Please provide
> suggestions for rephrased text.

I would suggest updating the arguably faulty patch to just have the
following for tools/building.py's get_closure_compiler() (optionally
fixing the upstream comment typo):
--
def get_closure_compiler():
  # First check if the user configured a specific CLOSURE_COMPILER in
thier settings
  if config.CLOSURE_COMPILER:
return config.CLOSURE_COMPILER

  # Otherwise use the system-shared one
  return ['closure-compiler']
--
And then it would actually call closure-compiler and it might just
inspire somebody more au fait with the respective packages (and how to
approach such a problem) to address the 16 or so reverse-dependencies
of closure-compiler mentioned in #916145?

Best wishes,
Jeremy

[1] https://mvnrepository.com/artifact/com.google.javascript/closure-compiler

Bug#1005294: Emscripten attempts to run invalid closure-compiler command

[Jeremy James]

Package: emscripten
Version: 3.1.3~dfsg-4

If emcc is run with --closure 1 then you receive an error that the
command '--max_old_space_size=8192' is invalid.

In fact, it attempts to run a command starting:
--max_old_space_size=8192 closure-compiler --compilation_level ...

Which appears to be caused by the 2009_closure-compiler.patch Debian
patch that modifies tools/building.py to create the following
function:

--
def get_closure_compiler():
  # First check if the user configured a specific CLOSURE_COMPILER in
thier settings
  if config.CLOSURE_COMPILER:
return config.CLOSURE_COMPILER

  # Otherwise use the system-shared one
  cmd = ['closure-compiler']
  if not WINDOWS:
# Work around an issue that Closure compiler can take up a lot of
memory and crash in an error
# "FATAL ERROR: Ineffective mark-compacts near heap limit
Allocation failed - JavaScript heap
# out of memory"
cmd.insert(-1, '--max_old_space_size=8192')
  return cmd
--

Which results in the invalid return value of
['--max_old_space_size=8192', 'closure-compiler']

Since max_old_space_size is a nodejs parameter that would have been
inserted into the return value of
shared.get_npm_cmd('google-closure-compiler'), I would suggest
removing the 'if not WINDOWS' section condition altogether in this
patch.

A workaround is to set CLOSURE_COMPILER, except there was a separate
upstream bug that broke this until recently [1].

[1] https://github.com/emscripten-core/emscripten/pull/15008

Bug#593466: zope-ldapuserfolder: Fails to check password for emergency user

[Jeremy James]

Package: zope-ldapuserfolder
Version: 2.9-1
Severity: grave
Tags: security
Justification: user security hole


When an LDAP user folder is enabled, any password is accepted when attempting 
to log in
as the emergency user (that is, the one defined in the 'access' file using 
zpasswd.py).

/usr/share/zope/Products/LDAPUserFolder/LDAPUserFolder.py fails to check the 
password is
correct, leading to the above security issue. Patch should be:

--- LDAPUserFolder.py.orig  2010-08-18 12:58:18.0 +0100
+++ LDAPUserFolder.py.fixed 2010-08-18 13:50:22.0 +0100
@@ -800,7 +800,7 @@
 if not name:
 return None

-if super and name == super.getUserName():
+if super and name == super.getUserName() and 
super.authenticate(password, request):
 user = super
 else:
 user = self.getUser(name, password)

-- System Information:
Debian Release: 5.0.5
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-2-686-bigmem (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash

Versions of packages zope-ldapuserfolder depends on:
ii  python-ldap 2.3.5-1  An LDAP interface module for Pytho
ii  zope-common 0.5.45   common settings and scripts for Zo
ii  zope2.9 2.9.6-4etch2 Open Source Web Application Server

zope-ldapuserfolder recommends no packages.

zope-ldapuserfolder suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org