-
-
Notifications
You must be signed in to change notification settings - Fork 47
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
Rebase on top of cf #57
Conversation
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( I do have some suggestions for making it better though... For recipe:
|
cc @bgruening |
This should be interesting, I expect failures a few times round since I've been using our compilers since 3.4.0! |
@mingwandroid; With @ocefpaf and others we are considering to use R 3.5.1 as an POC for rebuilding with the new compilers. So if this fails maybe we can include a local |
You might need to build out the transitive c and c++ deps with them first.. shouldn't be too bad though? |
- {{native}}bzip2 1.0.* # [win] | ||
- {{native}}libjpeg-turbo # [win] | ||
- {{native}}libiconv # [win] | ||
- {{native}}libuuid # [linux] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you remove {{native}}
here? conda-build doesn't recognize that libuuid
is a used variable with {{native}}
in front.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then that is what needs to be fixed. Please consider a PR to conda-build to fix the real problem.
Why does it matter here though here since libuuid
is not part of a build matrix?
- {{native}}gmp # [win] | ||
- {{native}}fftw # [win] | ||
- {{native}}xz # [win] | ||
- {{native}}mpfr # [win] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be pinned.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No they should not, we use run_exports.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not going to infect my recipes with pinning.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are wrong here anyway, msys2 packages never need pinning, they use an epoch system instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are wrong here anyway, msys2 packages never need pinning, they use an epoch system instead.
Can you explain this please?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Every msys2 package depends on an epoch package and that is versioned at the date when the upstream rolling distribution packages were converted to conda packages. That is the only version constraint here because that's how rolling distributions work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Every msys2 package depends on an epoch package and that is versioned at the date when the upstream rolling distribution packages were converted to conda packages. That is the only version constraint here because that's how rolling distributions work.
Sure. How does the r-base package pin to that epoch package? Is it done by run_exports
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Transitively each msys2 dependency depends on the same epoch version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Future-wise, R upstream are now based on MSYS2 (and are thus more up to date than us) so we may want to consider just bundling all their static libs into a single package and using that. We'd also need to update our mingw-w64 toolchain (or provide the 'upstream' one, just for R).
New error: |
I guess this one is blocked by the epic rebuild of conda-forge. |
Sadly yes :-( |
Looks like the epic rebuild caught up to |
Caught up? Yay! conflicts, bah! Try to get this rebased tomorrow; we need to figure something out regarding CF X11 vs AD CDT/X11 for recipes. |
Hi @mingwandroid, are you planning on working on this soon? |
Sorry didn't get a chance. Maybe this weekend? Do you need it earlier? I'll try to find time soon if so. |
@mingwandroid Its blocking currently the conda-forge rebuild. I can also give it a try and rebase it at least, if you like. |
@mingwandroid I tried to rebase. Feel free to revert this commit. Lets see if this gets green :) |
@conda-forge-admin, please rerender |
number: 1 | ||
merge_build_host: True # [win] | ||
merge_build_host: True # [win] | ||
number: 0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
number: 0 | |
number: 2 |
cc @pkgw |
@pkgw, @jakirkham, what do we want to do with things like Qt? Is it being rebuilt now on cf CI? Is it using cf X11?
Is this more widespread? What's the official policy as regards OpenGL/mesa? End users need to install stuff here with their system package manger. Is |
Checklist
0
(if the version changed)conda-smithy
(Use the phrase@conda-forge-admin, please rerender
in a comment in this PR for automated rerendering)