Rebuild for gnuradio_core3100

[regro-cf-autotick-bot]

This PR has been triggered in an effort to update gnuradio_core3100.

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.

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. If you do not have permissions to add this label, you can use the phrase @conda-forge-admin, please rerun bot in a PR comment to have the conda-forge-admin add it for you.

_{This PR was created by the regro-cf-autotick-bot. The regro-cf-autotick-bot is a service to automatically track the dependency graph, migrate packages, and propose package version updates for conda-forge. Feel free to drop us a line if there are any issues! This PR was generated by https://github.com/regro/autotick-bot/actions/runs/1733919633, please use this URL for debugging.}

[conda-forge-linter]

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.

[daniestevez]

Hi,

The current stable release of gr-satellites (v4.4.0) will not work with GNU Radio 3.10. If I recall correctly, I think it will build, but tests won't pass and importing the satellites Python module will fail.

I had to fix a couple things to get it working in GNU Radio 3.10: 92b1581a06581836e0af1ed90753c763289fbc5e and 9b10208d38ca4213f230aece02e65182608c868d. These are already in master, and with this in place, the same code base can be used for GNU Radio 3.9 and 3.10.

I'm planning to release a new stable version (v4.5.0) soon (perhaps in a week) that will include these commits. So I think it's best to wait until this to rebuild against GNU Radio 3.10.

However, I wanted to ask if waiting is a reasonable thing. Since the conda GNU Radio package has been updated to 3.10, is the current gr-satellites package broken or just tries to pull GNU Radio 3.9 as a dependency?

[ryanvolz]

There's no problem waiting, and I had noticed that I might be able to get this to build but that it would be missing some important fixes to get it to actually work with 3.10. I kicked off the migration just to be able to see what work the various OOTs would need for 3.10. So we'll need to leave this open so conda-forge knows that the migration is pending, and when the new release comes we can merge that for 3.9 support and then the bot will close this and make a new PR automatically.

The current package depends specifically on 3.9.5.x, so it won't install with 3.10. Then with the upcoming release, even though it will build and run against both 3.9 and 3.10, I think we'll still need to make two separate packages because each will only load the 3.x.x soversion of the GR libs that it was compiled with. It's unclear how to best handle that as there are two options that I see:

1. Make a separate branch for building against 3.9 (much like for 3.8 currently) and then do the extra git work to keep that and the main branch in sync since they're both building the same gr-satellites version.
2. Expand the build matrix on the main branch to include both 3.9 and 3.10. This means less synchronization work for us, but it also means bypassing the global conda-forge pin so that we'd have to manually handle all GR dependency migrations.
3. Drop support for GR 3.9 and just force 3.10 for everything. This depends on how well the overall OOT ecosystem migrates, because it doesn't make sense unless almost everything supports 3.10.

I think conda-forge would expect (1) so that's probably the thing to do, I'm just not looking forward to having three branches for each OOT. But if we could then do (3) after a short period of time, it would easily be the simplest path. 🤞 that OOT authors migrate quickly to 3.10.

[daniestevez]

Hi @ryanvolz, just a heads up that I've released today new stable versions of gr-satellites. We have v3.12 for the GNU Radio 3.8 branch, and v4.5, which can be built against both GNU Radio 3.9 and 3.10.

For the time being I think the safest option is to have a separate branch in the feedstock for GNU Radio 3.9, though I agree that it increases the maintainer's workload (specially considering many OOTs). From what I've had to change in gr-satellites, I think that the transition from 3.9 to 3.10 should be quite simple in most cases, so it seems realistic to get everyone's OOTs to work under 3.10, even if we have to submit PRs to other people's OOTs. Trying to help push everything to 3.10 and drop 3.9 seems the option that will bring less work long term.

I'll try to get things going now in this feedstock, at lest handling the 3.8 branch manually and figuring out if I can do a 3.9 branch.

[daniestevez]

The 3.x branch (GR 3.8) is now sorted out. I merged #51.

On the other, for GR 3.9 and 3.10 I've tried doing some PRs to see if it builds (#52 and #53) and I'm getting build failures.

[daniestevez]

Apparently the root cause for the build failures with GR 3.9 and 3.10 is this error:

2022-02-19T12:38:26.1749447Z     from .satellites_python import *
2022-02-19T12:38:26.1750004Z ImportError: generic_type: type "ax100_decode" referenced unknown base type "gr::block"

I have previously encountered this in daniestevez/gr-satellites#303. In that case it was due to a mismatch between the pybind11 and gnuradio packages in the Ubuntu PPA. Could it be that the packages for Conda are broken in a similar way at the moment? It's interesting that #49 built fine a week ago.

[ryanvolz]

Hmm, I'm going to try installing the package locally from the Github artifact to see if I can figure out the issue. I haven't touched the gnuradio package since #49 built successfully last week so I don't yet know where the problem could be coming from.

By the way, what I've gone with in the other OOT recipes is to add an extra variable to conda_build_config.yaml:

gnuradio_extra_pin:
  - ""
  - "3.9.5"

and then put selectors on the gnuradio-core host requirement so that we get builds against both 3.9 and 3.10:

    - gnuradio-core  # [not gnuradio_extra_pin]
    - gnuradio-core {{ gnuradio_extra_pin }}.*  # [gnuradio_extra_pin]

I think that's going to be the easiest path forward so we only have to maintain one branch of gr-satellites 4.x.

[ryanvolz]

I just incidentally re-ran #49 (to undo adding the six dependency and then build on top of it for #54) and there the Linux builds of 4.4.0 succeed, even with the most recent pybind11. So there seems to be something specific about 4.5.0 that is causing this issue.

[ryanvolz]

I see nothing different of significance between 4.4.0 and 4.5.0. What I did find from diffing the build logs is that the successful build was with conda-forge's gcc 9.4 and the failing builds use gcc 10.3, a global pinning change which happened 2 days ago.

[ryanvolz]

Confirmed that it's the switch from GCC 9 to GCC 10 that causes the ImportError: generic_type: type "ax100_decode" referenced unknown base type "gr::block". I've rolled the build back to use GCC 9 so we can hopefully get the version update merged. After that I'll need to figure out whether it's a problem with GCC 10 specifically (unlikely) or just that pybind is sensitive enough to need not only a compatible pybind version for the build but also the same compiler (likely).

[daniestevez]

Thanks for looking into this. I agree that the changes between v4.4.0 and v4.5.0 wouldn't explain this. I don't think the problem is specifically with GCC 10, since I've been building gr-satellites and GNU Radio 3.9 in Gentoo with GCC 10 since a long ago (currently using GCC 10.2.0) and never had this problem. I'd put my money on some subtle ABI thing requiring both pybind11, GNU Radio and gr-satellites being built with the same GCC version.

[ryanvolz]

Yeah, that's what I figured. A rebuild of the gnuradio package is in order then, with GCC 10.