-
-
Notifications
You must be signed in to change notification settings - Fork 11
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
Rebuild for Python 3.7, GCC 7, R 3.5.1, openBLAS 0.3.2 #18
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 ( |
Guess this needs some kind of |
Yeah but just copy the changes from our fork or do you want me to do that? https://github.com/AnacondaRecipes/freeglut-feedstock/blob/master/recipe/meta.yaml#L24 |
Hi! This is the friendly automated conda-forge-linting service. I wanted to let you know that I linted all conda-recipes in your PR ( Here's what I've got... For recipe:
|
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 ( |
@mingwandroid , had to add |
Sure thing. If it's needed then it's needed! |
Thanks, @mingwandroid ! @jakirkham , could you take a quick look and merge if looks OK? Not sure if it is appropriate for me to merge. |
I'm not sure if we should be using CDTs for X11 packages or conda-forge ones. Will defer to others. cc @conda-forge/core @pkgw |
@pkgw informs me that the x11 stack doesn't touch GL at all, so I'm not sure you have a choice. Even if you did provide Mesa it would be software only which is not good at all. I think CDTs for gl is best. |
It may be possible to make a Mesa that looks to the system GL then link that to X11, but I don't know how much effort that'd be or if it's even possible. |
Sorry for jumping on here, but if I'm packaging GLFW, a similar library that is used by glumpy, it seems that I should be using https://github.com/ramonaoptics/glfw-feedstock/blob/master/recipe/meta.yaml |
Nope, you should always prefer conda-forge packages to CDT |
- {{ cdt('libxfixes-devel') }} # [linux] | ||
- {{ cdt('mesa-libgl-devel') }} # [linux] | ||
- {{ cdt('xorg-x11-proto-devel') }} # [linux] | ||
- {{ cdt('libxxf86vm-devel') }} # [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.
@pkgw, can you please look over this list and check to see if these CDTs are still needed or if there are conda-forge X11 packages they can be replaced with?
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.
Untested, but:
libxfixes-devel
→xorg-libxfixes
xorg-x11-proto-devel
→xorg-xproto
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.
Thanks for the updates. We may need to make similar changes to qt
.
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.
It would also be good to come up with a list of acceptable X11 CDTs to use and add them to the docs with the rest coming from conda-forge X11 packages.
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.
Seems libxxf86vm-devel
was making use of xorg-x11-proto-devel
. So dropping that requirement caused the new Linux compiler build to fail. Have reverted that change, which fixes the issue.
Using xorg-libxfixes
worked fine. So that change has been made.
A similar change will be needed for Qt as well. Have raised issue ( conda-forge/qt-feedstock#85 ) about this.
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.
Yeah, we really need better documentation on it :/ I'm so confused about when to use what.
@conda-forge-admin, please re-render. |
These have either been added to the base image, included in the requirements, or added as CDTs. Regardless of the reason, they are no longer needed from `yum`. So go ahead and drop these `yum` dependencies and `yum_requirements.txt` altogether.
Now that the `yum` requirements have been dropped, re-render to update associated build files with this change.
This reverts commit 9f23561. It seems using the `conda-forge` package for `xorg-xproto` doesn't quite work as it appears it causes the CDT `libxxf86vm-devel` to miss a few headers it expects to find. As a result, the build fails with the new compilers. Reverting to the CDT in this case should fix the issue. ref: https://circleci.com/gh/conda-forge/freeglut-feedstock/97
It is likely this feedstock needs to be rebuilt.
Notes and instructions for merging this PR:
Please note that if you close this PR we presume that the feedstock has been rebuilt, so if you are going to perform the rebuild yourself don't close this PR until the your rebuild has been merged.
This package has the following downstream children:
simbody
And potentially more.
If this PR was opened in error or needs to be updated please add the
bot-rerun
label to this PR. The bot will close this PR and schedule another one.This PR was created by the cf-regro-autotick-bot.
The cf-regro-autotick-bot is a service to automatically track the dependency graph, migrate packages, and propose package version updates for conda-forge. If you would like a local version of this bot, you might consider using rever. Rever is a tool for automating software releases and forms the backbone of the bot's conda-forge PRing capability. Rever is both conda (
conda install -c conda-forge rever
) and pip (pip install re-ver
) installable.Finally, feel free to drop us a line if there are any issues!