Package: release.debian.org Severity: normal User: release.debian....@packages.debian.org Usertags: unblock
Please unblock package node-miller-rabin Hi all (one more time, sorry) According to #926720, node-miller-rabin FTBFS randomly. I fixed 2 things in version 4.0.1-5: - increase one test timeout because build failed on armhf [1] - remove one dubious test using patch given by Santiago Vila (#926720) Reverse dependencies: only node-diffie-hellman which has no reverse dependencies. Since nothing is changed in installed code, I think it is no risky to unblock node-miller-rabin. Cheers, Xavier [1]: https://tests.reproducible-builds.org/debian/rbuild/unstable/armhf/node-miller-rabin_4.0.1-4.rbuild.log.gz [#926720]: https://bugs.debian.org/926720 unblock node-miller-rabin/4.0.1-5 -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (600, 'testing'), (50, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
diff --git a/debian/changelog b/debian/changelog index 1cc5d79..22510b6 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,11 @@ +node-miller-rabin (4.0.1-5) unstable; urgency=medium + + * Team upload + * Update increase-timeout.patch for armhf (fixes debci) + * Add patch to fix FTBFS (Closes: #926720). Thanks to Santiago Vila + + -- Xavier Guimard <y...@debian.org> Tue, 09 Apr 2019 18:54:43 +0200 + node-miller-rabin (4.0.1-4) unstable; urgency=medium * Team upload diff --git a/debian/patches/fix-randomly-ftbfs.diff b/debian/patches/fix-randomly-ftbfs.diff new file mode 100644 index 0000000..48bdf9a --- /dev/null +++ b/debian/patches/fix-randomly-ftbfs.diff @@ -0,0 +1,29 @@ +Description: fix FTBFS randomly + The failure happens randomly. Sometimes it happens, sometimes it does not, + so the only recipe to reproduce it is to try many times. + AFAIK, this being a primality test, I assume the outcome is either + "not prime" or "maybe prime", so the only way to test the test is by + giving a known prime and expect "maybe prime" as output. + . + So: Why is the test calling mr.test with 221, which is not prime? (221 = 13 x 17) + . + And why this fails randomly? Does the test perform random calculations + internally and it's therefore not deterministic? Even in such case I + don't see how a non-prime like 221 may help to catch obvious errors in + a test suite for a primality test. +Author: Santiago Vila <sanv...@debian.org> +Bug-Debian: https://bugs.debian.org/926720 +Forwarded: no +Reviewed-By: Xavier Guimard <y...@debian.org> +Last-Update: 2019-04-09 + +--- a/test/api-test.js ++++ b/test/api-test.js +@@ -5,7 +5,6 @@ + describe('Miller-Rabin', function() { + it('should test number for primality', function() { + this.timeout(20000); +- assert(!mr.test(new bn(221))); + assert(mr.test(new bn(257))); + + var p = new bn('dba8191813fe8f51eaae1de70213aafede8f323f95f32cff' + diff --git a/debian/patches/increase-timeout.patch b/debian/patches/increase-timeout.patch index 2c6f03d..44fc19a 100644 --- a/debian/patches/increase-timeout.patch +++ b/debian/patches/increase-timeout.patch @@ -10,7 +10,7 @@ Last-Update: 2019-01-04 describe('Miller-Rabin', function() { it('should test number for primality', function() { -+ this.timeout(8000); ++ this.timeout(20000); assert(!mr.test(new bn(221))); assert(mr.test(new bn(257))); diff --git a/debian/patches/series b/debian/patches/series index 4e54818..6673523 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -1 +1,2 @@ increase-timeout.patch +fix-randomly-ftbfs.diff