Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"
Hi Markus, Thanks for following-up. It further clarified pieces. On 06-04-2023 15:14, Markus Koschany wrote: 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. If you believe it to be a corner case (that you elaborate on later on), then I trust you on that. The corner case just looked like a transition from our side (Release Team) of the story. 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." Thanks for that piece of info. We can do a binNMU for all reverse-dependencies but I do not think it is necessary. Good to know, I wasn't particularly liking the idea. 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. Ok, let's have the dojo maintainers tighten the relation then in their next upload. 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. Well, autoremoval was about to do that in a few days if nobody intervened. The solution is to tighten the dependency on rhino and adjust the autopkgtest accordingly. If the dependency is tightened, autopkgtest will do the right thing. 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. [...] Yes, I typed this before I had further insights and forgot to review this piece. Indeed, you're right. 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! I'll also reschedule rhino then. Thanks for your help and contributions for bookworm. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#977027: [Pkg-javascript-devel] Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"
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 OpenPGP_signature Description: OpenPGP digital signature
Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"
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 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 signature.asc Description: This is a digitally signed message part
Bug#977027: [Pkg-javascript-devel] Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"
Le jeu. 6 avr. 2023 à 11:24, Paul Gevers a écrit : > > 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. Go ahead > > Paul > -- > Pkg-javascript-devel mailing list > pkg-javascript-de...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"
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
diff -Nru rhino-1.7.14/debian/changelog rhino-1.7.14/debian/changelog
--- rhino-1.7.14/debian/changelog 2023-02-18 00:46:00.0 +0100
+++ rhino-1.7.14/debian/changelog 2023-04-06 13:10:20.0 +0200
@@ -1,3 +1,10 @@
+rhino (1.7.14-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload
+ * Add versioned Breaks on shrinksafe (Closes: #977027)
+
+ -- Paul Gevers Thu, 06 Apr 2023 13:10:20 +0200
+
rhino (1.7.14-2) unstable; urgency=medium
* Team upload.
diff -Nru rhino-1.7.14/debian/control rhino-1.7.14/debian/control
--- rhino-1.7.14/debian/control 2023-02-18 00:46:00.0 +0100
+++ rhino-1.7.14/debian/control 2023-04-06 13:10:20.0 +0200
@@ -31,6 +31,7 @@
Section: java
Architecture: all
Depends: ${misc:Depends}
+Breaks: shrinksafe (<< 1.17.2+dfsg1-2.1~)
Suggests: rhino
Description: Libraries for rhino Java Script Engine
Rhino is an implementation of the JavaScript language written
diff -Nru dojo-1.17.2+dfsg1/debian/changelog dojo-1.17.2+dfsg1/debian/changelog
--- dojo-1.17.2+dfsg1/debian/changelog 2022-08-13 18:48:08.0 +0200
+++ dojo-1.17.2+dfsg1/debian/changelog 2023-04-06 12:59:48.0 +0200
@@ -1,3 +1,10 @@
+dojo (1.17.2+dfsg1-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload
+ * Add versioned (Build-)Depends on rhino/librhino-java (Closes: #977027)
+
+ -- Paul Gevers Thu, 06 Apr 2023 12:59:48 +0200
+
dojo (1.17.2+dfsg1-2) unstable; urgency=medium
* Add jdupes to build-dep
diff -Nru dojo-1.17.2+dfsg1/debian/control dojo-1.17.2+dfsg1/debian/control
--- dojo-1.17.2+dfsg1/debian/control2022-08-13 18:47:45.0 +0200
+++ dojo-1.17.2+dfsg1/debian/control2023-04-06 12:59:48.0 +0200
@@ -6,7 +6,7 @@
Bastien Roucariès
Build-Depends: debhelper-compat (= 13), nodejs,
javahelper
-Build-Depends-Indep: default-jdk, rhino, rsync , jdupes
+Build-Depends-Indep: default-jdk, rhino (>= 1.7.14), rsync , jdupes
Standards-Version: 4.6.1.0
Rules-Requires-Root: no
Homepage: https://dojotoolkit.org
@@ -63,7 +63,7 @@
Package: shrinksafe
Architecture: all
-Depends: ${misc:Depends}, ${java:Depends}, librhino-java
+Depends: ${misc:Depends}, ${java:Depends}, librhino-java (>= 1.7.14)
Description: JavaScript compression system
ShrinkSafe is a JavaScript compression system. It can typically reduce the
size of your scripts by a third or more, depending on your programming style.
OpenPGP_signature
Description: OpenPGP digital signature
Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"
Hi, On Sun, 26 Mar 2023 16:26:00 +0200 Markus Koschany 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). Also, given that shrinksafe is from a different source than rhino, this qualifies as a transition (it *needs* changes in different (binary) packages). 2. shrinksafe has no reverse-dependencies So it can be easily removed, but that's not a great service to its users. 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). 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). 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. 7. Summary: I recommend to rebuild dojo to fix the autopkgtests. I suggest to reconsider the current autopkgtest behavior. At least there should be a warning or a note for maintainers in the future that dojo requires a rebuild whenever rhino changes. In Debian we normally handle that by either real or virtual abi packages (although in your other message you mention you didn't know of the breakage, so I guess that wouldn't have helped in this particular case, but it would have given you the knob to fix it after the discovery of the breakage). We have a huge collection of examples in Debian for that. If rhino (the binary) were to Provides an abi, than dojo could Depends on that (with the right version inserted during the build). The Release Team tooling [1] would then pick up when the ABI is bumped such that binNMU's can be scheduled (or the appropriate people can be notified in case of arch:all). 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. Normally we would defer the new upstream version and transition at this stage of the release, but I want rhino to migrate to bookworm. Paul [1] https://release.debian.org/transitions/ OpenPGP_signature Description: OpenPGP digital signature
Bug#977027: [Pkg-javascript-devel] Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"
Le dim. 26 mars 2023 à 21:39, Markus Koschany a écrit : > 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 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=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. > Yes shrinksafe is only used for compression. Bastien > > > Regards, > > Markus > -- > Pkg-javascript-devel mailing list > pkg-javascript-de...@alioth-lists.debian.net > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel >
Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"
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 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=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 signature.asc Description: This is a digitally signed message part
Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"
Hi Markus On Sun, 26 Mar 2023 at 16:34, Markus Koschany wrote: > 1. There is no transition needed because only shrinksafe is affected by the > new > rhino version. How did you determine this? > 2. shrinksafe has no reverse-dependencies That is true, but src:dojo has ledgersmb and tt-rss as reverse-dependencies. > 4. I have rebuilt all rhino reverse-dependencies successfully. That's great, although we do have regular test rebuilds which should find FTBFS with the new rhino. > 7. Summary: I recommend to rebuild dojo to fix the autopkgtests. I suggest to > reconsider the current autopkgtest behavior. At least there should be a > warning > or a note for maintainers in the future that dojo requires a rebuild whenever > rhino changes. I wait to hear the opinion of the dojo maintainers, but if it does turn out that only dojo needs a rebuild, then dojo should be uploaded, adding a versioned dependency on librhino-java >= 1.7.14 and << 1.7.15 (or similar). Also, Rhino will need an upload, declaring a Breaks on shrinksafe << 1.17.2+dfsg1-3 (or similar). Regards Graham
Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"
Hello, On Sun, 26 Mar 2023 09:41:48 +0200 Graham Inggs wrote: [...] > To both the rhino and dojo maintainers, please investigate so we can > have this resolved for bookworm. Here are my investigations: 1. There is no transition needed because only shrinksafe is affected by the new rhino version. 2. shrinksafe has no reverse-dependencies 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. 4. I have rebuilt all rhino reverse-dependencies successfully. 5. I have tested yui-compressor, a similar tool, with rhino 1.7.14 and without rebuilding the existing package and this one works as expected. 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. 7. Summary: I recommend to rebuild dojo to fix the autopkgtests. I suggest to reconsider the current autopkgtest behavior. At least there should be a warning or a note for maintainers in the future that dojo requires a rebuild whenever rhino changes. Regards, Markus [1] https://bugs.debian.org/970501 [2] https://salsa.debian.org/js-team/dojo/-/commit/68e6a048b4c4386d0495e7faf11bd46bf0516604 signature.asc Description: This is a digitally signed message part
Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"
Control: reassign -1 src:rhino, src:dojo
Control: found -1 rhino/ 1.7.14-1
Control: found -1 dojo/ 1.17.2+dfsg1-2
It appears that dojo needs to be rebuilt against the new rhino, and
rebuilding dojo against the new rhino makes it incompatible with the
old rhino.
The changes that the new rhino makes to the shrinksafe binary package
can be seen by rebuilding dojo in testing and unstable, and comparing
the results with diffoscope. I attach the diffoscope output of my own
attempt to do that.
There seems to be some kind of transition here.
It is not clear how many of the 25 packages that build-depend on rhino
are affected, as only three of them have autopkgtests, and a fourth
(ckbuilder) has an autopkgtest that is never run. At least openrefine
seems affected, as it gained a versioned dependency on librhino-java
[1] to avoid a "silent error".
To both the rhino and dojo maintainers, please investigate so we can
have this resolved for bookworm.
Regards
Graham
[1]
https://salsa.debian.org/java-team/openrefine/-/commit/eb72e6639974335db42a627e06c83aabbdb5bbc5
--- testing-binnmu/shrinksafe_1.17.2+dfsg1-2_all.deb
+++ unstable-binnmu/shrinksafe_1.17.2+dfsg1-2_all.deb
├── file list
│ @@ -1,3 +1,3 @@
│ -rw-r--r-- 0004 2022-08-13 16:48:08.00
debian-binary
│ -rw-r--r-- 000 1916 2022-08-13 16:48:08.00
control.tar.xz
│ --rw-r--r-- 00087236 2022-08-13 16:48:08.00
data.tar.xz
│ +-rw-r--r-- 00087244 2022-08-13 16:48:08.00
data.tar.xz
├── control.tar.xz
│ ├── control.tar
│ │ ├── ./md5sums
│ │ │ ├── ./md5sums
│ │ │ │┄ Files differ
├── data.tar.xz
│ ├── data.tar
│ │ ├── file list
│ │ │ @@ -43,15 +43,15 @@
│ │ │ -rw-r--r-- 0 root (0) root (0) 42 2022-08-13
16:48:08.00 ./usr/share/doc/shrinksafe/api/tag-search-index.js
│ │ │ -rw-r--r-- 0 root (0) root (0) 363 2022-08-13
16:48:08.00 ./usr/share/doc/shrinksafe/api/type-search-index.js
│ │ │ -rw-r--r-- 0 root (0) root (0) 964 2022-08-13
16:48:08.00 ./usr/share/doc/shrinksafe/changelog.Debian.gz
│ │ │ -rw-r--r-- 0 root (0) root (0)20663 2022-08-13
13:50:32.00 ./usr/share/doc/shrinksafe/copyright
│ │ │ drwxr-xr-x 0 root (0) root (0)0 2022-08-13
16:48:08.00 ./usr/share/doc-base/
│ │ │ -rw-r--r-- 0 root (0) root (0) 259 2022-08-13
16:48:08.00 ./usr/share/doc-base/shrinksafe.shrinksafe
│ │ │ drwxr-xr-x 0 root (0) root (0)0 2022-08-13
16:48:08.00 ./usr/share/java/
│ │ │ --rwxr-xr-x 0 root (0) root (0)23469 2022-08-13
16:48:08.00 ./usr/share/java/shrinksafe-1.17.2.jar
│ │ │ +-rwxr-xr-x 0 root (0) root (0)23479 2022-08-13
16:48:08.00 ./usr/share/java/shrinksafe-1.17.2.jar
│ │ │ drwxr-xr-x 0 root (0) root (0)0 2022-08-13
16:48:08.00 ./usr/share/lintian/
│ │ │ drwxr-xr-x 0 root (0) root (0)0 2022-08-13
16:48:08.00 ./usr/share/lintian/overrides/
│ │ │ -rw-r--r-- 0 root (0) root (0) 239 2022-08-13
15:14:30.00 ./usr/share/lintian/overrides/shrinksafe
│ │ │ drwxr-xr-x 0 root (0) root (0)0 2022-08-13
16:48:08.00 ./usr/share/man/
│ │ │ drwxr-xr-x 0 root (0) root (0)0 2022-08-13
16:48:08.00 ./usr/share/man/man1/
│ │ │ -rw-r--r-- 0 root (0) root (0) 575 2022-08-13
16:48:08.00 ./usr/share/man/man1/shrinksafe.1.gz
│ │ │ lrwxrwxrwx 0 root (0) root (0)0 2022-08-13
16:48:08.00 ./usr/bin/shrinksafe -> ../share/java/shrinksafe.jar
│ │ ├── ./usr/share/java/shrinksafe-1.17.2.jar
│ │ │ ├── zipinfo {}
│ │ │ │ @@ -1,14 +1,14 @@
│ │ │ │ -Zip file size: 23469 bytes, number of entries: 12
│ │ │ │ +Zip file size: 23479 bytes, number of entries: 12
│ │ │ │ -rw 2.0 fat0 bx stor 22-Aug-13 16:48 META-INF/
│ │ │ │ -rw-r--r-- 2.0 unx 175 b- defN 22-Aug-13 16:48
META-INF/MANIFEST.MF
│ │ │ │ -rw 1.0 fat0 b- stor 22-Aug-13 16:48 org/
│ │ │ │ -rw 1.0 fat0 b- stor 22-Aug-13 16:48 org/dojotoolkit/
│ │ │ │ -rw 1.0 fat0 b- stor 22-Aug-13 16:48
org/dojotoolkit/shrinksafe/
│ │ │ │ --rw 2.0 fat17182 bl defN 22-Aug-13 16:48
org/dojotoolkit/shrinksafe/Compressor.class
│ │ │ │ +-rw 2.0 fat17210 bl defN 22-Aug-13 16:48
org/dojotoolkit/shrinksafe/Compressor.class
│ │ │ │ -rw 2.0 fat 534 bl defN 22-Aug-13 16:48
org/dojotoolkit/shrinksafe/DebugData.class
│ │ │ │ -rw 2.0 fat 1557 bl defN 22-Aug-13 16:48
org/dojotoolkit/shrinksafe/Main$IProxy.class
│ │ │ │ -rw 2.0 fat 7781 bl defN 22-Aug-13 16:48
org/dojotoolkit/shrinksafe/Main.class
│ │ │ │ -rw 2.0 fat 4714 bl defN 22-Aug-13 16:48
Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"
Hi, On Wed, 01 Mar 2023 09:58:14 +0100 Markus Koschany 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 OpenPGP_signature Description: OpenPGP digital signature
Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"
Hi tony, [...] > 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.) Strange. I downloaded the source package and ran the autopkgtests manually. I symlinked js.jar and shrinksafe.jar into util/shrinksafe and then I executed the runner.sh script. I got the same error message "Cannot set property "dojo" of null to "[object Object]". Anyway, are the autopkgtests really useful if they prevent rhino from migration to testing every time we update the package, even if everything works as expected? The same tests already run at build time. signature.asc Description: This is a digitally signed message part
Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"
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.) signature.asc Description: PGP signature
Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"
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 signature.asc Description: This is a digitally signed message part
Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"
Hi Emmanuel, On 16-12-2020 16:47, Emmanuel Bourg wrote: > 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? I have no clue what dojo is or does. Let alone I know it's upstream. Sorry I can't help there. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"
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
Bug#977027: rhino breaks dojo autopkgtest: Cannot set property "dojo" of null to "[object Object]"
Control: severity -1 important Hi, On Thu, 17 Sep 2020 13:29:24 +0200 Paul Gevers 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 OpenPGP_signature Description: OpenPGP digital signature
