Using 2020-10-01 as the fake timestamp will cause many test failures with /gnu/store/bfirgq65ndhf63nn4q6vlkbha9zd931q-openssl-1.1.1l.drv. I didn’t investigate why, but I guess because it’s before the test certificates were created. They expired in June 2022. I tried a month before that, which worked.
Also fixes layout of instructions.
Also fix layout of instructions.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
For detailed information about the code coverage, see the test coverage report.
See the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.
we don’t want to bump our Guix Time Machine commit just for that.
Actually our Time Machine commit is much more recent than I thought.
I presume openssl is used in the bootstrap chain, to bootstrap older software, so it probably can never be removed in a time machine bump?
If I remember correctly, I think that you can likely just patch OpenSSL here since it’s not a package that is “core” to Guix like GnuTLS was?
Yes, this is workaround 3, added in fad444f6e1b1ce5c1572c773db4a9a098c7a0b96.
“Workaround 3: Disable the tests in the Guix source code for this single derivation”
Disable the tests in the Guix source code for this single derivation
We already have that recommendation, but I think it’s better to offer an alternative. “Don’t worry about tests not passing” is something I prefer to only do when I really understand how everything works, which I don’t.
711-3. Set system time to 2020-10-01
712-4. guix build --no-substitutes /gnu/store/vhphki5sg9xkdhh2pbc8gi6vhpfzryf0-gnutls-3.6.12.drv
713-5. Set system time back to accurate current time
714-6. Turn NTP back on
715+
716+1. Turn off NTP
review ACK 8fee5355ee1d2f2b410c548bac9e85f2a21a696d
I didn’t test, but suggesting a data should be harmless, even if it is wrong.
3.x & 1.x), in which case, we should be able to remove any instructions about OpenSSL 1.x entirely (a patch could be opened against one of the release branches, where we might still be building 1.x, if relevant). I’m currently doing a no substitutes build to check.
Can someone confirm if this change is actually still relevant to master?
For all HOSTS except x86_64-w64-mingw32, we currently only build openSSL 3.x. For Windows, via NSIS, we currently depends on Python2 (nsis-x86_64 -> scons-python2 -> python2@2.7.18). This leads to an (indirect) dependency on OpenSSL 1.x and 3.x..
I think the next steps here are to fix NSIS, to use a more recent version of scons (and python3). Note that Python 3 (since ~3.7) has a hard dependency on OpenSSL (for urllib).
I think the next steps here are to fix NSIS, to use a more recent version of scons (and python3).
Landed a patch upstream to fix this https://git.savannah.gnu.org/cgit/guix.git/commit/?id=d428237642e1e4ac8fda4597205ffec89926c0ec.
I partially wiped guix on my (AMD) Ubuntu 24.04 system (sudo rm -rf /root/.cache/guix /var/guix /gnu/store).
0$ which guix
1/usr/local/bin/guix
2$ guix --version
3guix (GNU Guix) 1.4.0
4$ sudo --login guix pull --commit=efc26826400762207cde9f23802cfe75a737963c
This fails at /gnu/store/bfirgq65ndhf63nn4q6vlkbha9zd931q-openssl-1.1.1l.drv.
After the #30609 bump to --commit=7bf1d7aeaffba15c4f680f93ae88fbef25427252 it still tries to build this OpenSSL version.
So even though Bitcoin Core doesn’t need it anymore, Guix itself still does. Unless I did something wrong, which is entirely possible.
So even though Bitcoin Core doesn’t need it anymore, Guix itself still does
Would be nice to report this upstream, so that openssl-1.1.1l can be removed, but I guess the removal may not be trivial
Once openssl-1 stuff is gone, we can drop the GnuTLS workaround instructions along with it.
It had a similar problem in 3.6.12, but has been updated to 3.7.2. That was included in the Guix 1.4.0 release in late 2022.
(or I could reword the GnuTLS workaround text to refer to openssl 1)
Interesting, I haven’t tried deleting .cache/guix/checkouts as suggested in that thread.
I’m going to wait for guix pull to finish, then take a look at guix graph --type=reverse-package openssl-1.1.1l (reverse-bag?)
There is a good chance that a guix pull will build the current guix first, and then the pulled one, and the reply I linked to is just a wrong guess, but I am not a guix dev, and I don’t know if that’d be a bug.
However, if the build isn’t fixed with 1.5, then it should be a bug, last time I checked.
/usr/local/bin/guix from source on a recent master commit, and then try guix pull again. Then we can drop the workaround instruction after 1.5 is released.
@maflcko you theory might somewhat right.
When my /usr/local/bin/guix was at 0.4.0 the first thing it wanted to build was guile-3.0.7.
Now that I built the most recent master commit, it starts out building guile-3.0.9.
However under --list-generations I’m only seeing the version I pulled, not the one I built from source. I then did a guix pull on that commit, which ended up building a few more derivations.
So perhaps it’s only building guile or some other code component? cc @theuni
Anyway, I think we should merge the instructions in this PR - and then get rid of this whole timestamp workaround section once 1.5.0 is out.
ACK 8fee5355ee1d2f2b410c548bac9e85f2a21a696d
Going to merge this while we figure out whether openssl 1.x is still required.