Rebuild with introspection for gst-plugins-base

conda-forge / gstreamer-feedstock

A conda-smithy repository for gstreamer.

BSD 3-Clause "New" or "Revised" License

9 stars 28 forks source link

Rebuild with introspection for gst-plugins-base #22

Closed duncanmmacleod closed 5 years ago

duncanmmacleod commented 5 years ago

This PR rebuilds this feedstock with the added --enable-introspection flag for gst-plugins-base.

Fixes #21.

Checklist

[x] Used a fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase code>@<space/conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

conda-forge-linter commented 5 years ago

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.

duncanmmacleod commented 5 years ago

@conda-forge/gstreamer, this build is failing with:

/home/conda/feedstock_root/build_artifacts/gstreamer_and_plugins_1548180943066/work/plugins_base/gst-libs/gst/gl/tmp-introspect4lryvyh4/.libs/lt-GstGL-1.0: error while loading shared libraries: libGL.so.1: cannot open shared object file: No such file or directory

despite the fact that mesa-libgl CDT is being installed. So, I have no idea why this is failing, given that the dependencies are well-specified (AFAIK). The build passes when I run the .circleci/run_docker_build.sh script on my own machine. Can someone try and run this on another machine to reproduce the failure? Or just rerun the CI?

mingwandroid commented 5 years ago

Did you install the system libGL-providing packages too? You need to. CDTs are only for consumption by the static linker at build-time. They are proxies for real system libraries. To run software you linked against a CDT you need to provide the system libs in the expected system lib location at run-time.

duncanmmacleod commented 5 years ago

@mingwandroid, can you explain a little more? How would I go about installing system packages for the CI? Is that what yum_requirements.txt is for?

Can you explain how this could have worked on my own run of docker but not during CI?

And given that I didn't add the mesa-libgl-devel dependency, why has this not errored before?

So many questions; I'm sorry for my ignorance of how this builds, I'm just trying to build a downstream package and know that I need gst-plugins-base build with this new flag, but not much more than that.

mingwandroid commented 5 years ago

I am about to take off on a fight. It is documented though some or ask on gitter

duncanmmacleod commented 5 years ago

@conda-forge/gstreamer, I think this is ready, I added yum_requirements.txt to address the missing system package, I hope that's the right solution.

mingwandroid commented 5 years ago

Hi @duncanmmacleod, you don't need the -devel package and in general it's best to avoid them because the compiler and linker could find these instead of the cdt packages.

Probably you get away with it here though.

duncanmmacleod commented 5 years ago

@conda-forge/gstreamer, I think this is now ready for review, thanks.

duncanmmacleod commented 5 years ago

@mingwandroid, what's the procedure for duplicating this mod in gst-plugins-base from Anaconda?

mingwandroid commented 5 years ago

You can make a pr which syncs the AnacondaRecipes fork with this one.

If x11 is involved (I guess it is without having checked) we need to take care of the differences between cdt and cf-x11 - suggestions welcome - I believe we could each carry a different metapackage (but conda-build needs a small addition to allow transitive run_exports, pinging @msarahan who should be asleep ATM but apparently isn't!)

If x11 isn't involved then a complete sync should be ok/best. We want to minimize differences..