Skip to content
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

Merged
merged 17 commits into from
Dec 31, 2018

Conversation

regro-cf-autotick-bot
Copy link
Contributor

It is likely this feedstock needs to be rebuilt.
Notes and instructions for merging this PR:

  1. Please merge the PR only after the tests have passed.
  2. Feel free to push to the bot's branch to update this PR if needed.

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!

@conda-forge-linter
Copy link

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 (recipe) and found it was in an excellent condition.

@jakirkham
Copy link
Member

Guess this needs some kind of cdt package. @mingwandroid, would you be able to advise here?

@mingwandroid
Copy link

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

@conda-forge-linter
Copy link

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 (recipe) and found some lint.

Here's what I've got...

For recipe:

  • Selectors are suggested to take a <two spaces>#<one space>[<expression>] form. See lines [27]

@conda-forge-linter
Copy link

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 (recipe) and found it was in an excellent condition.

@shadowwalkersb
Copy link
Contributor

@mingwandroid , had to add libxxf86vm in addition to the cdt packages in your fork. Is that OK?

@mingwandroid
Copy link

Sure thing. If it's needed then it's needed!

@shadowwalkersb
Copy link
Contributor

Thanks, @mingwandroid !

@jakirkham , could you take a quick look and merge if looks OK? Not sure if it is appropriate for me to merge.

@jakirkham
Copy link
Member

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

@mingwandroid
Copy link

@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.

@mingwandroid
Copy link

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.

@hmaarrfk
Copy link
Contributor

hmaarrfk commented Dec 11, 2018

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 cdt packages instead of conda-forge ones?

https://github.com/ramonaoptics/glfw-feedstock/blob/master/recipe/meta.yaml

@scopatz
Copy link
Member

scopatz commented Dec 11, 2018

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]
Copy link
Member

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?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Untested, but:

  • libxfixes-develxorg-libxfixes
  • xorg-x11-proto-develxorg-xproto

Copy link
Member

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.

ref: https://github.com/conda-forge/qt-feedstock/blob/a16262b187248038b8d2f14a9cb0416d107448a6/recipe/meta.yaml#L39

Copy link
Member

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.

Copy link
Member

@jakirkham jakirkham Dec 30, 2018

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.

Copy link
Contributor

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.

@jakirkham
Copy link
Member

@conda-forge-admin, please re-render.

conda-forge-admin and others added 3 commits December 30, 2018 09:29
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants