Fix the openssl crate by adding the ossl300 config flag
#297
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
A bit of history. The workspace shell started off as a quick solution to get overrides to express some of their side effects within the user's development shell. Because it didn't work closely with the actual mechanisms of mkShell, the chosen mechanism, from overrides to dev shell, was use of propagated inputs. This and some cargo culting had resulted in overrides mimicking other overrides, lots of use of propagatedNativeBuildInputs. First, workspace shell's overhaul is given the actual package set instead of the noBuild set that is used when running tests. (the tests themselves may need similar overhaul). The new shell has one simple job: Make everything required to build every crate, except rust crates themselves, expressed in environment and available from the store. This has to be done for the entire rust crate DAG. Second, once the workspace shell could correctly express dependencies and shell hooks etc without the abuse of propagated inputs, the overrides themselves could be made much more sensible, much more consistent with the rest of Nix. substractLists works fine for derivation filtering The issue that lead to using attrSets was using the wrong crate outputs to filter on. After that was fixed, it was no longer necessary to construct attrSets by keys. If complexity of a dependency set (n^2 because of lib.unique) becomes too high, the attrSet based implementation should become favored again. This won't really show up to users for n < 1000 where n is the immediate dependencies of crates that are not crates themselves. Apple frameworks must be propagated? Missing a setupHook?
Signed-off-by: Litchi Pi <[email protected]>
|
My mistake. Thanks for adding the 300 flag. You only saw the missing 300 because of unstable branch, correct? I am using 22.05 in development. I could add an extra nixpkgs version to CI to detect these issues sooner, but I might also put it behind a flag that just warns when it fails. |
|
Don't know what happened on CI. I'll let you have a shot at it until I make it back to this issue. |
|
Yes it only causes a problem on |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I don't really understand why the config flags were commented out, but I found that this setup works on nixos-unstable as of today.
For reminder, on
unstableof NixOS, the OpenSSL got bumped to version 3 per default, and the version1.1.*are available under the packageopenssl_1_1, which makes the compilation of the crate fail if we have the version 3 around