#1086624 scrypt: FTBFS: 04-force-resources... FAILED!

Package:
src:scrypt
Source:
src:scrypt
Submitter:
Sebastian Ramacher
Date:
2025-03-04 22:27:02 UTC
Severity:
normal
Tags:
#1086624#5
Date:
2024-11-02 12:07:41 UTC
From:
To:
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

#1086624#10
Date:
2024-11-11 15:41:02 UTC
From:
To:
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.

#1086624#19
Date:
2024-12-21 03:15:53 UTC
From:
To:
(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.

#1086624#24
Date:
2025-03-04 22:18:46 UTC
From:
To:
I believe that this was fixed in scrypt 1.3.3, which has already been
packaged and is currently in Debian testing and unstable.