The value NIL is not of type NUMBER

[jg791]

I'm running into a weird bug. I haven't had time to put a PR yet because I don't have a definitive "why".

When installing anything (package does not matter), I am getting the following error: The value NIL is not of type NUMBER

The error is coming from extract-openssl-digest. Specifically, it is happening because extract-openssl-digest is called with an already-trimmed value, e.g., (ql-https:extract-openssl-digest "a708a8b6996a18c3aed1d9d909f9c52477c72fba"). This causes (position #\Space "a708a8b6996a18c3aed1d9d909f9c52477c72fba") to return nil, which causes the call to subseq to blow up.

Tracing it back, the troubled call is line 166 of content-hash.lisp:

(extract-openssl-digest (read-binary-line (uiop:process-info-output openssl))))))

Through debugging I've verified that OpenSSL on my system still does what you'd expect:

$ openssl dgst -sha1 install.sh
SHA1(install.sh)= 14ac9cec24cdafe66b11708a42463b1424a97581

I've also verified that (read-binary-line) is not clobbering it (everything after the space is missing in the stream passed to this function).

This means, for some reason, (uiop:process-info-output openssl) is returning a stream containing e.g. a708a8b6996a18c3aed1d9d909f9c52477c72fba instead of SHA1(install.sh)= a708a8b6996a18c3aed1d9d909f9c52477c72fba

Info:
OS: macOS Tahoe 26.6.2
Lisp: SBCL 2.6.7
OpenSSL: 3.6.3
QuickLisp/ql-https: Tested from a fresh install.

I've tried nuking and reinstalling everything, to no avail.

[rudolfochrist]

Oh boy,

Thanks for reporting this. Actually I have no idea why the output of uiop:process-info-output is different. GH Actions uses macOS 26.5.2 and it seems to work just fine. So, no clue 🤷‍♂️

I adjusted extract-openssl-digest to not subseq the output if there is no space found. Could you please checkout #32 and see if this solves the problem for you? Thank you very much!

[jg791]

Hey @rudolfochrist, thanks for the quick response and PR! I've checked out your branch and can confirm #32 immediately resolves the issue - I had actually tested something similar myself locally already.

I did not get a chance to dig into why uiop:process-info-output has a different value, unfortunately, but this solves the issue.

[rudolfochrist]

Great. I'll go and merge the quick fix (#32) into main. Knowing why uiop:process-info-output has different values may be an exercise for my future self if the the issue bubbles up again. 😅

I had actually tested something similar myself locally already

Please, go and submit PRs the next time! Even if we don't solve the root cause, I think this is still a valid fix.

[jg791]

@rudolfochrist You bet! I think so too, I was just stubborn about figuring out the underlying cause. 😂 Thanks again!