- Package:
- src:scrypt
- Source:
- src:scrypt
- Submitter:
- Sebastian Ramacher
- Date:
- 2025-03-04 22:27:02 UTC
- Severity:
- normal
- Tags:
Source: scrypt Version: 1.3.2-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: sramacher@debian.org https://buildd.debian.org/status/fetch.php?pkg=scrypt&arch=arm64&ver=1.3.2-1%2Bb3&stamp=1730541482&raw=0 make[2]: Leaving directory '/<<PKGBUILDDIR>>' ./tests/test_scrypt.sh . System scrypt not found. Running tests ------------- 01-known-values... SUCCESS! 02-decrypt-reference-file... SUCCESS! 03-encrypt-decrypt-file... SUCCESS! 04-force-resources... FAILED! File /<<PKGBUILDDIR>>/tests-output/04-force-resources-01.exit contains exit code 1. Test description: scrypt dec 1 second make[1]: *** [Makefile:2141: test] Error 1 Cheers
I am unable to reproduce this bug. It's a timing thing (fails if something is too fast), so might fail if the machine is too fast, or if the accounting on CPU time is off due to other threads and cache misses not being counted against the right thread, or something like that. In any case, I've lowered the severity because this seems much more likely to be a test jig issue than an actual bug.
(I'm the author of that test.) Interesting! Now that I think about it, that test makes the assumption that the CPU availability will be roughly equal. Namely, it: 1) creates a file which should take 10 seconds to decrypt 2) attempt to decrypt that file in only 1 second. If the system was very heavily loaded while it did step 1 but the load disappeared before step 2, then that timing could well fail. Attempting to create the file during the tests was supposed to make it platform-independent: the test should take a reasonable amount of time, regardless of whether it's being run on a desktop or a raspberry pi 2 (which was literally what I checked when I wrote the test in 2016!). I'm looking into lowering the "deliberately too slow to decrypt" time from 1 second to 0.1 seconds; so there would be a 100x difference between the encryption and decryption.
I believe that this was fixed in scrypt 1.3.3, which has already been packaged and is currently in Debian testing and unstable.