-
-
Notifications
You must be signed in to change notification settings - Fork 309
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot install on osx-arm64 due to ncurses issues #307
Comments
Duplicate of #255 |
Maybe not |
|
I've marked the latest release as a pre-release for now |
Verbose micromamba output: https://gist.github.com/xhochy/383f56ed5451c9bd81db82c0be56803e Interesting bit:
|
This also matches what is in the |
The now latest works again. |
micromamba is supposed to use the cache file which has the corrected dependencies, but is not. |
cc @wolfv, @chrisburr |
Do you have tokens in See also mamba-org/mamba#1575 |
Yes, I can reproduce with the tokens. |
I'll take a look at this today. I think instead of looking at the URL at all (in the package cache, to determine if we have to redownload) – we will rely on the SHA256 which should be a perfect indicator of the actual contents of the package. Although I also thought that we were already comparing "cleaned" (ie. cleaned of tokens) URLs. |
Hmm, I am looking at this issue and the other one (#255) and I am wondering how we want to tackle that. Shouldn't we rebuild the readline package to take into account the new ncurses pinning and use that inside the miniforge packages? It looks to me as if we're installing packages with "conflicting" metadata. Which Would be happy to fix this. We could also force to install from the |
There is a |
OK, got it ... that explains everything. We do use the token value to calculate the MD5 hash of the full URL (incl. token), so the hash is different with token. The idea was that that the repodata contents could be different depending on wether a user has permissions on certain packages or not. But since this seems to break constructor it's probably better to modify this behavior. |
Since constructor passes |
Maybe not, since that's going to break |
I think we can just ignore the token value to calculate the hash and people who rely on different packages based on token value need to clean their caches using |
I'll finish this tomorrow, but I think this PR should fix the issue: mamba-org/mamba#1696 |
Actually, we could use the That would also mean we could leave the hashing function in micromamba as it is. I think I can fix that tomorrow and make a release. |
Ping @xhochy |
As mentioned in #255 (comment), we have the same issue on Redhat RHEL 8.5 on x86-64 |
Solution to issue cannot be found in the documentation.
Issue
The bootstrapping process of
mambaforge
currently fails onosx-arm64
with the following message:Installed packages
Environment info
The text was updated successfully, but these errors were encountered: