Bug#970501: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"

[Paul Gevers]

Source: rhino, dojo
Control: found -1 rhino/1.7.7.2-1
Control: found -1 dojo/1.15.3+dfsg1-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debi...@lists.debian.org
User: debi...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of rhino the autopkgtest of dojo fails in testing
when that autopkgtest is run with the binary packages of rhino from
unstable. It passes when run with only packages from testing. In tabular
form:

pass fail
rhino from testing 1.7.7.2-1
dojo from testing 1.15.3+dfsg1-1
all others from testing from testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of rhino to testing
[1]. Due to the nature of this issue, I filed this bug report against
both packages. Can you please investigate the situation and reassign the
bug to the right package?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=rhino

https://ci.debian.net/data/autopkgtest/testing/amd64/d/dojo/7045098/log.gz
autopkgtest [01:52:16]: test shrinksafe: [-----------------------
js: "../../dojo/dojo.js", line 1321: exception from uncaught JavaScript
throw: TypeError: Cannot set property "dojo" of null to "[object Object]"

autopkgtest [01:52:18]: test shrinksafe: -----------------------]

[Paul Gevers]

Control: severity -1 important

Hi,

On Thu, 17 Sep 2020 13:29:24 +0200 Paul Gevers <elb...@debian.org> wrote:
> With a recent upload of rhino the autopkgtest of dojo fails in testing
> when that autopkgtest is run with the binary packages of rhino from
> unstable.

Unfortunately, there hasn't been any activity on this bug accept for bug
manipulation. rhino is a key package, so is not going to be autoremoved.
Let's fix this before the first freeze hits.

Paul

[Emmanuel Bourg]

Hi Paul

Le 15/12/2020 à 20:49, Paul Gevers a écrit :

> Unfortunately, there hasn't been any activity on this bug accept for bug
> manipulation. rhino is a key package, so is not going to be autoremoved.
> Let's fix this before the first freeze hits.

Do you know what version of Rhino does dojo use upstream?

Emmanuel Bourg

[Paul Gevers]

Hi Emmanuel,

I have no clue what dojo is or does. Let alone I know it's upstream.

Sorry I can't help there.

Paul

[Markus Koschany]

Control: reassign -1 shrinksafe
Control: severity -1 serious

Hi,

I uploaded a new version of rhino a while ago and it seems this bug is still
relevant. I have rebuilt dojo with rhino 1.7.14 and all shrinksafe tests pass.
However the same tests fail with autopkgtest and block the migration of rhino
to testing. Could you take a look at that please?

Regards,

Markus

[tony mancill]

On Tue, Feb 28, 2023 at 11:13:35PM +0100, Markus Koschany wrote:
> Control: reassign -1 shrinksafe
> Control: severity -1 serious
>

> I uploaded a new version of rhino a while ago and it seems this bug is still
> relevant. I have rebuilt dojo with rhino 1.7.14 and all shrinksafe tests pass.
> However the same tests fail with autopkgtest and block the migration of rhino
> to testing. Could you take a look at that please?

I'm not able to reproduce the autopkgtest failure locally running in
clean sid chroots. First, I build the dojo source package and ran the
autopkgtest against those binaries. When that didn't fail, I pulled the
binary packages from the archive and ran the autopkgtest against those.
Again, no failures.

I see the autopkgtest failure when I run against a bookworm chroot.

So it seems like the migration of rhino will resolve the test failure.
(Or I'm missing something fundamental.)

[Paul Gevers]

Hi,

On Wed, 01 Mar 2023 09:58:14 +0100 Markus Koschany <a...@debian.org> wrote:
> > I'm not able to reproduce the autopkgtest failure locally running in
> > clean sid chroots.

On ci.debian.net, the tests also fail in unstable.

https://ci.debian.net/packages/d/dojo/

Paul

[Markus Koschany]

Hi Graham,

Am Sonntag, dem 26.03.2023 um 19:28 +0200 schrieb Graham Inggs:
> Hi Markus
>
> On Sun, 26 Mar 2023 at 16:34, Markus Koschany <a...@debian.org> wrote:
> > 1. There is no transition needed because only shrinksafe is affected by the
> > new
> > rhino version.


> How did you determine this?

Rhino 1.7.14 was mostly API compatible meaning I only had to fix an issue in
closure-compiler. All other packages can be built from source without
modifications. I didn't find any other runtime / ABI issues so far.

>
> > 2. shrinksafe has no reverse-dependencies
>
> That is true, but src:dojo has ledgersmb and tt-rss as reverse-dependencies.

I used codesearch.debian.net and found only documentation or other minor
references of shrinksafe in affected packages.

https://codesearch.debian.net/search?q=shrinksafe&literal=1

Since all Java tests in dojo pass after the rebuild and almost all of the code
in dojo is Javascript anyway, I don't see how ledgersmb and tt-rss can be
affected by the new rhino version. Wouldn't those packages depend on rhino in
some way? To me it seems rhino is only required to build shrinksafe which can
be used for compressing Javascript files. But maybe the dojo maintainers can
chime in here.


Regards,

Markus

[Bastien ROUCARIES]

Yes shrinksafe is only used for compression.

Bastien

Regards,

Markus
--
Pkg-javascript-devel mailing list
Pkg-javasc...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

[Paul Gevers]

Control: tags -1 pending patch

On 06-04-2023 12:54, Paul Gevers wrote:
> I'm going to prepare NMU's for rhino and dojo and upload to DELAYED/5

Please find the debdiffs attached.

Paul

[Markus Koschany]

Hello,

Am Donnerstag, dem 06.04.2023 um 12:54 +0200 schrieb Paul Gevers:
> Hi,

>
> On Sun, 26 Mar 2023 16:26:00 +0200 Markus Koschany <a...@debian.org> wrote:
> > 1. There is no transition needed because only shrinksafe is affected by the
> > new
> > rhino version.
>

> I'm wondering how you know, did you test (without rebuilding) all the
> reverse dependencies? If so, how did you do that? (I'm worried we're
> missing cases like src:dojo).

I always rebuild all reverse-dependencies with ratt before I upload a Java
library package. From my Java experience I know this uncovers almost all
problems. Rhino is not some obscure C/C++ library. It is a Javascript engine
written in Java. You can install reverse-dependencies and run them against the
new rhino version. If the package works, then there is no further action
required. Could I have missed a corner case? Maybe. But there is always a risk
whenever you change something. Remember why we did the upgrade in the first
place. We did fix two RC bugs and just hit a special case with a leaf package
(shrinksafe)

From dojo developer documentation:

"Note that the linkage requires the same version of Rhino used to build the
shrinksafe.jar. In versions prior to Dojo 1.3, ShrinkSafe was bundled into
Rhino by way of patch, and shipped as custom_rhino.jar."

We can do a binNMU for all reverse-dependencies but I do not think it is
necessary.

>
> Also, given that shrinksafe is from a different source than rhino, this
> qualifies as a transition (it *needs* changes in different (binary)
> packages).

I cannot remember when we asked for a Java library transition in the past.
shrinksafe is, as I pointed out before, a special case. It was once part of the
rhino distribution and probably should have tightened the dependency on a
specific rhino version in the first place.

>
> > 2. shrinksafe has no reverse-dependencies
>

> So it can be easily removed, but that's not a great service to its users.

No, we don't want to remove neither shrinksafe nor any other package. Please
don't exaggerate the problem at hand.


> > 3. We had the exact same problem before [1]. Back then the fix was to
> > rebuild
> > the package and to fix the shrinksafe tests by setting a specific
> > Javascript
> > version. [2] Since just rebuilding dojo also fixes the problem, I assume
> > that
> > we don't have to change this option.
>
> Well, rebuilding without fixing the underlying issue is just papering
> over. I'd like to get a proper (future proof) solution in place, see
> below. (And yes, we can paper over for bookworm now).

The solution is to tighten the dependency on rhino and adjust the autopkgtest
accordingly.

> > 4. I have rebuilt all rhino reverse-dependencies successfully.
>
> Yes, normal transitions are handled that way, we (the Release Team)
> schedule binNMU's for those (albeit we can't do arch:all that way).

As I said this is standard procedure for Java libraries which I touch. It does
not imply a transition is needed.

> > 6. Regarding Openrefine: It does only work with rhino 1.7.14 in unstable.
> > Hence
> > why I tightened the dependency on rhino to 1.7.14. The current version of
> > rhino
> > in testing breaks the Javascript application.
>
> Suggesting even more that this is a real transition.

You are misunderstanding the problem. OpenRefine does not work with Rhino in
testing. The new rhino in unstable fixes the problem. Again, rhino 1.7.14 is
the solution, not the cause of the problem.
[...]

>



>
> I'm going to prepare NMU's for rhino and dojo and upload to DELAYED/5

> today, where I'll add an appropriate Breaks to src:rhino and an
> appropriate versioned Depends to src:dojo. Please let me know if you
> object or want to handle this yourself.

Fine with me and thanks!


Markus

[Paul Gevers]

Hi,

On 06-04-2023 14:50, Bastien ROUCARIES wrote:
>> On 06-04-2023 12:54, Paul Gevers wrote:
>>> I'm going to prepare NMU's for rhino and dojo and upload to DELAYED/5
>>
>> Please find the debdiffs attached.
>

> Go ahead

Thanks, I have rescheduled dojo to 0 days and it got accepted.

Paul