Bug#916145: closure-compiler: Not working with recent JS code

2019-04-07 Thread Markus Koschany
Am 07.04.19 um 20:36 schrieb Adrian Bunk:
> On Sun, Apr 07, 2019 at 11:12:30AM -0700, tony mancill wrote:
>> ...
>> Somewhat related, given that closure-compiler upstream releases about
>> once a month on average, perhaps it is a candidate for doing Something
>> Different.
> 
> That's pretty normal for a package, and we aren't even close to the 
> point where this would matter:
> 
> It is by design that stretch ships 2016 versions of packages and
> buster ships 2018 versions of packages.
> 
> But stretch and buster shipping a 2013 version of a package with more 
> recent versions means that even the version in stretch is 3 years
> older than it could be.

What tony wanted to imply is that closure-compiler requires more
maintenance effort than other packages and releases more frequently
which means more changes, more often, more new build-dependencies and
more work. The day is only 24 hours long for all of us. The maintainer
who introduced this package left the team shortly afterwards and tony
just spent some of his time to keep this package in Debian (a real team
effort) because it seems useful for other packages. Those who contribute
nothing to the packaging work, which also means packaging new
build-dependencies and making sure that r-deps continue to work, have
absolutely no right to complain about how up-to-date a package is.

>> Maybe a closure-compiler-installer package or something like that?
>> ...
> 
> The main user of the version currently in buster/unstable are reverse 
> dependencies inside Debian. And some are already blocked by the outdated 
> version.

This is the only reason why this package is still in Debian and
apparently closure-compiler seems to work for those packages, otherwise
the maintainers would have noticed it, I guess? So it is still useful
for its main purpose, being a build-dependency for other packages,
although heavily outdated.

The only positive way forward is to update this package and its
reverse-dependencies. The less positive way is to remove the package
from Debian. Just to be clear, personally I don't mind but the timing is
bad. Maintainers of reverse-dependencies should have had a chance to
contribute a fix or ensure that their packages work without
closure-compiler but it looks to me it never happened. So as long as
those r-deps are useful and work correctly, bug #916145 is not RC.

> closure-compiler-installer would force such packages out of main.

We know that. At least it would give users "something", that's the quick
and dirty approach. IMO this would be the perfect fit for our "bikeshed"
or the currently discussed Debian User Repository idea. However it isn't
implemented yet.






signature.asc
Description: OpenPGP digital signature


Bug#916145: closure-compiler: Not working with recent JS code

2019-04-07 Thread Adrian Bunk
On Sun, Apr 07, 2019 at 11:12:30AM -0700, tony mancill wrote:
>...
> Somewhat related, given that closure-compiler upstream releases about
> once a month on average, perhaps it is a candidate for doing Something
> Different.

That's pretty normal for a package, and we aren't even close to the 
point where this would matter:

It is by design that stretch ships 2016 versions of packages and
buster ships 2018 versions of packages.

But stretch and buster shipping a 2013 version of a package with more 
recent versions means that even the version in stretch is 3 years
older than it could be.

> Maybe a closure-compiler-installer package or something like that?
>...

The main user of the version currently in buster/unstable are reverse 
dependencies inside Debian. And some are already blocked by the outdated 
version.

closure-compiler-installer would force such packages out of main.

> Cheers,
> tony 
> (wearing a Java Team hat...)

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed



Bug#916145: closure-compiler: Not working with recent JS code

2019-04-07 Thread tony mancill
On Sun, Apr 07, 2019 at 11:16:53AM +0300, Adrian Bunk wrote:
> On Sat, Apr 06, 2019 at 06:13:05PM +0200, Chris Hofstaedtler wrote:
> > * Roland Gruber  [190406 16:07]:
> > > the current version is so old that it got incompatible with recent JS 
> > > code.
> > > E.g. jQuery 3.3.1 cannot be minified as the tool reports parsing errors.
> > > 
> > > Please either update the tool or remove it from the archive. This is now
> > > 5 years in unmaintained state.
> > 
> > I've checked all r-deps of closure-compiler in Debian, and they all
> > build -- datatables-extensions shows some errors in a prebuilt file,
> > but it has done so for a long time, so probably not super relevant.
> > 
> > While I agree that having a 5 year old JS compiler in Debian is not
> 
> Now over 6 years.
> 
> > a great situation, its also not threatening to the packages in
> > Debian using it, so I'd suggest keeping it for now.
> 
> Packages that would require a non-prehistoric version of 
> closure-compiler are already blocked from entering Debian,
> see #843951 and #727529 (since 2013!) as examples.
> 
> Any actual user installing closure-compiler will have a WTF experience 
> when discovering that the new Debian release ships a version that was
> already outdated when the dinosaurs roamed the earth.
> 
> > Adrian: you raised the severity, care to lower it until buster is
> > out (or say some words on why)?
> 
> IMHO the release team adding a buster-ignore tag would be the best way 
> forward here - this would still show up as RC bug for bullseye.

+1 for not orphaning r-build-deps at this point in the release cycle but
forcing the issue at the onset of the bullseye release cycle.

I'm not a user of closure-compiler but have tried to help keep the
package in Debian because it appears to be useful to others.  I agree
that at a certain point, an old package is probably more harmful than a
missing package.  

Packaging the transitive build-deps for closure-compiler is a
non-trivial effort and one that people might easily overlook when they
ask for the latest version.  Since there are plenty of users who want a
newer version, it shouldn't be that hard to get some help with those
build-deps, right?  

Somewhat related, given that closure-compiler upstream releases about
once a month on average, perhaps it is a candidate for doing Something
Different.  Maybe a closure-compiler-installer package or something like
that?  (Maybe backports would work, but we would have to manage the
transitive dependencies as well.)  

Cheers,
tony 
(wearing a Java Team hat...)


signature.asc
Description: PGP signature


Bug#916145: closure-compiler: Not working with recent JS code

2019-04-07 Thread Ivo De Decker
Control: severity -1 important

Hi,

On Sun, Apr 07, 2019 at 11:16:53AM +0300, Adrian Bunk wrote:
> > Adrian: you raised the severity, care to lower it until buster is
> > out (or say some words on why)?
> 
> IMHO the release team adding a buster-ignore tag would be the best way 
> forward here - this would still show up as RC bug for bullseye.

No. Downgrading is the way forward.

If you want to update the package for bullseye, filing an RC bug is not the
way to do it. Joining the team and preparing a new package (after the freeze)
is.

Thanks,

Ivo



Bug#916145: closure-compiler: Not working with recent JS code

2019-04-07 Thread Adrian Bunk
On Sat, Apr 06, 2019 at 06:13:05PM +0200, Chris Hofstaedtler wrote:
> * Roland Gruber  [190406 16:07]:
> > the current version is so old that it got incompatible with recent JS code.
> > E.g. jQuery 3.3.1 cannot be minified as the tool reports parsing errors.
> > 
> > Please either update the tool or remove it from the archive. This is now
> > 5 years in unmaintained state.
> 
> I've checked all r-deps of closure-compiler in Debian, and they all
> build -- datatables-extensions shows some errors in a prebuilt file,
> but it has done so for a long time, so probably not super relevant.
> 
> While I agree that having a 5 year old JS compiler in Debian is not

Now over 6 years.

> a great situation, its also not threatening to the packages in
> Debian using it, so I'd suggest keeping it for now.

Packages that would require a non-prehistoric version of 
closure-compiler are already blocked from entering Debian,
see #843951 and #727529 (since 2013!) as examples.

Any actual user installing closure-compiler will have a WTF experience 
when discovering that the new Debian release ships a version that was
already outdated when the dinosaurs roamed the earth.

> Adrian: you raised the severity, care to lower it until buster is
> out (or say some words on why)?

IMHO the release team adding a buster-ignore tag would be the best way 
forward here - this would still show up as RC bug for bullseye.

> Cheers,
> Chris (from the Salzburg BSP)

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed



Bug#916145: closure-compiler: Not working with recent JS code

2019-04-06 Thread Chris Hofstaedtler
* Roland Gruber  [190406 16:07]:
> the current version is so old that it got incompatible with recent JS code.
> E.g. jQuery 3.3.1 cannot be minified as the tool reports parsing errors.
> 
> Please either update the tool or remove it from the archive. This is now
> 5 years in unmaintained state.

I've checked all r-deps of closure-compiler in Debian, and they all
build -- datatables-extensions shows some errors in a prebuilt file,
but it has done so for a long time, so probably not super relevant.

While I agree that having a 5 year old JS compiler in Debian is not
a great situation, its also not threatening to the packages in
Debian using it, so I'd suggest keeping it for now.
Adrian: you raised the severity, care to lower it until buster is
out (or say some words on why)?

Cheers,
Chris (from the Salzburg BSP)



Bug#916145: closure-compiler: Not working with recent JS code

2019-03-21 Thread Thierry fa...@linux.ibm.com
Hello,
Is that bug still valid with current version 20130227+dfsg1-10 ?
thanks



On Mon, 10 Dec 2018 17:42:12 +0100 Roland Gruber 
wrote:
> Package: closure-compiler
> Version: 20130227+dfsg1-9
> Severity: important
> 
> Dear Maintainer,
> 
> the current version is so old that it got incompatible with recent JS code.
> E.g. jQuery 3.3.1 cannot be minified as the tool reports parsing errors.
> 
> Please either update the tool or remove it from the archive. This is now
> 5 years in unmaintained state.
> 
> 
> -- System Information:
> Debian Release: 9.6
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.9.0-8-amd64 (SMP w/8 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE= 
> (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages closure-compiler depends on:
> ii  default-jre-headless [java6-runtime-headless]2:1.8-58
> ii  java-wrappers0.1.28
> ii  libclosure-compiler-java 20130227+dfsg1-9
> ii  openjdk-8-jre-headless [java6-runtime-headless]  8u181-b13-2~deb9u1
> ii  oracle-java8-jdk [java6-runtime-headless]8u77
> 
> closure-compiler recommends no packages.
> 
> closure-compiler suggests no packages.
> 
> -- no debconf information
> 
> 

-- 
Thierry Fauck @ fr.ibm.com



Bug#916145: closure-compiler: Not working with recent JS code

2018-12-10 Thread Roland Gruber
Package: closure-compiler
Version: 20130227+dfsg1-9
Severity: important

Dear Maintainer,

the current version is so old that it got incompatible with recent JS code.
E.g. jQuery 3.3.1 cannot be minified as the tool reports parsing errors.

Please either update the tool or remove it from the archive. This is now
5 years in unmaintained state.


-- System Information:
Debian Release: 9.6
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-8-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages closure-compiler depends on:
ii  default-jre-headless [java6-runtime-headless]2:1.8-58
ii  java-wrappers0.1.28
ii  libclosure-compiler-java 20130227+dfsg1-9
ii  openjdk-8-jre-headless [java6-runtime-headless]  8u181-b13-2~deb9u1
ii  oracle-java8-jdk [java6-runtime-headless]8u77

closure-compiler recommends no packages.

closure-compiler suggests no packages.

-- no debconf information