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: -----------------------]
Hi, 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
Hi Paul Le 15/12/2020 à 20:49, Paul Gevers a écrit : Do you know what version of Rhino does dojo use upstream? Emmanuel Bourg
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
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
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.)
Hi tony, [...] 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.
Hi, On ci.debian.net, the tests also fail in unstable. https://ci.debian.net/packages/d/dojo/ Paul
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
Hello, On Sun, 26 Mar 2023 09:41:48 +0200 Graham Inggs <ginggs@debian.org> wrote: [...] 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
Hi Markus How did you determine this? That is true, but src:dojo has ledgersmb and tt-rss as reverse-dependencies. That's great, although we do have regular test rebuilds which should find FTBFS with the new rhino. 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
Hi Graham, Am Sonntag, dem 26.03.2023 um 19:28 +0200 schrieb Graham Inggs: 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. 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
Le dim. 26 mars 2023 à 21:39, Markus Koschany <apo@debian.org> a écrit : Yes shrinksafe is only used for compression. Bastien
Hi, 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). So it can be easily removed, but that's not a great service to its users. 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). 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). Suggesting even more that this is a real transition. 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/
Control: tags -1 pending patch Please find the debdiffs attached. Paul
Le jeu. 6 avr. 2023 à 11:24, Paul Gevers <elbrus@debian.org> a écrit : Go ahead
Hello, Am Donnerstag, dem 06.04.2023 um 12:54 +0200 schrieb Paul Gevers: 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. 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. No, we don't want to remove neither shrinksafe nor any other package. Please don't exaggerate the problem at hand. The solution is to tighten the dependency on rhino and adjust the autopkgtest accordingly. As I said this is standard procedure for Java libraries which I touch. It does not imply a transition is needed. 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. [...] Fine with me and thanks! Markus
We believe that the bug you reported is fixed in the latest version of dojo, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 977027@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Paul Gevers <elbrus@debian.org> (supplier of updated dojo package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmaster@ftp-master.debian.org) Format: 1.8 Date: Thu, 06 Apr 2023 12:59:48 +0200 Source: dojo Architecture: source Version: 1.17.2+dfsg1-2.1 Distribution: unstable Urgency: medium Maintainer: Debian Javascript Maintainers <pkg-javascript-devel@lists.alioth.debian.org> Changed-By: Paul Gevers <elbrus@debian.org> Closes: 977027 Changes: dojo (1.17.2+dfsg1-2.1) unstable; urgency=medium . * Non-maintainer upload * Add versioned (Build-)Depends on rhino/librhino-java (Closes: #977027) Checksums-Sha1: 9aa6800c2d29269a410e3217f90a18c89633d2b4 2122 dojo_1.17.2+dfsg1-2.1.dsc 2661cd3cee87fa51c4450948e903538022a27884 17508 dojo_1.17.2+dfsg1-2.1.debian.tar.xz Checksums-Sha256: 103d763376406455ff7a29e4af50fc8e067579e376882b4841cef7f7be0f3b7c 2122 dojo_1.17.2+dfsg1-2.1.dsc fef9482a459f3d3ede376c3ff9e5a23ebac2807dd0c98fa246218a330348f519 17508 dojo_1.17.2+dfsg1-2.1.debian.tar.xz Files: 377ceb305c0022405b53fe01d56d0630 2122 javascript optional dojo_1.17.2+dfsg1-2.1.dsc a0a4396944bf0cfd609dac8f90e721d4 17508 javascript optional dojo_1.17.2+dfsg1-2.1.debian.tar.xz -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAmQuqnAACgkQnFyZ6wW9 dQpJygf+II1h1WQPdAY00ALoUi/9qVVsp2GIDzgz9KL1eZ1ry1js7XsWpp0Az0YV SfB6m9pt9SOYg5WFB3N2dzyjVY8bi5snJVzGQI/GSnZiprmCDTRtbtEx7hplFJz9 8DHxSe8dLGlGbZAlciVDiWr2HOjyeZt4jY0Zj4H4zQ69lI5pZP704oYixemsiqDv uNEwNgspxmKbBA9tJbyffdkHM3dQk/6HMIGMy2v9OWgLP8aMuSIfNNUP9H3BloEk bK8/q8+71BsH4Hq/eSYqm7my7nQNtfaDPhjppiEsV+J59Lya/i8RUpKLEo+jF4Qx 4I0W0iIzjfTYYOoGDtUUlj0VFCQyeA== =SOuF -----END PGP SIGNATURE-----
Hi, Thanks, I have rescheduled dojo to 0 days and it got accepted. Paul
Hi Markus, Thanks for following-up. It further clarified pieces. 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. Thanks for that piece of info. Good to know, I wasn't particularly liking the idea. Ok, let's have the dojo maintainers tighten the relation then in their next upload. Well, autoremoval was about to do that in a few days if nobody intervened. If the dependency is tightened, autopkgtest will do the right thing. Yes, I typed this before I had further insights and forgot to review this piece. Indeed, you're right. I'll also reschedule rhino then. Thanks for your help and contributions for bookworm. Paul
We believe that the bug you reported is fixed in the latest version of rhino, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 977027@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Paul Gevers <elbrus@debian.org> (supplier of updated rhino package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmaster@ftp-master.debian.org) Format: 1.8 Date: Thu, 06 Apr 2023 13:10:20 +0200 Source: rhino Architecture: source Version: 1.7.14-2.1 Distribution: unstable Urgency: medium Maintainer: Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org> Changed-By: Paul Gevers <elbrus@debian.org> Closes: 977027 Changes: rhino (1.7.14-2.1) unstable; urgency=medium . * Non-maintainer upload * Add versioned Breaks on shrinksafe (Closes: #977027) Checksums-Sha1: 3844e5e0901376c699598f9ec92ede714624f215 1807 rhino_1.7.14-2.1.dsc 5047e73491da66101d422917accb3d7bdb69ef79 17188 rhino_1.7.14-2.1.debian.tar.xz Checksums-Sha256: 6e460c3b93d5b1fec093d48db2836cee8ad2d632a3ef8e3ac85c1c4fc9312d4a 1807 rhino_1.7.14-2.1.dsc 98412369a7733faa16cd30b8cfa14f51a48c8cb67606fc900469934e15952de6 17188 rhino_1.7.14-2.1.debian.tar.xz Files: 4d47652eccee894efb863762e4c423f8 1807 interpreters optional rhino_1.7.14-2.1.dsc 20a07018b182f557e50cda50d7f0dfc9 17188 interpreters optional rhino_1.7.14-2.1.debian.tar.xz -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEWLZtSHNr6TsFLeZynFyZ6wW9dQoFAmQuqf8ACgkQnFyZ6wW9 dQo5gQf+IZg6jDvpeEm5v4CStn0d+AdzOIZa/sS4w+KjRkV+wRwbNAh/r0BCZIGT 0OLzB9sozc4OacMgpi7MVafOAkEIpyIKM/VG4zhwmH3xcdDlgDqC45oi8rAPIV8t CEmY6MjN3tvu79/ouQGbFabOFjJ3Buuw8bbnMjNcpCmVwRPnpfGijxxKK4q7K1HN dRzqhua8Gc/6oeSbu+WbFkaZ9aE5e2CP5tHcc26ioBZQ45SQAeEWkFPyu2DtaRGO 2PIxbv4Ezth5hQVyt6PGCqjEN3yT1qBs/GHo/J0LQR+A0c2uucb5EdHoYpAi7Bjy lRBEQ4OXSAYQpxQjTHbWPeffB1Sw2A== =Hwv3 -----END PGP SIGNATURE-----