Rebuild for flatbuffers 25.9.23 and revert cuda 12.9

[regro-cf-autotick-bot]

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

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/cf-scripts/actions/runs/20013687219 - please use this URL for debugging.}

[conda-forge-admin]

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/meta.yaml) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipe/meta.yaml:

• ℹ️ The recipe is not parsable by parser conda-souschef (grayskull). This parser is not currently used by conda-forge, but may be in the future. We are collecting information to see which recipes are compatible with grayskull.
• ℹ️ The recipe is not parsable by parser conda-recipe-manager. The recipe can only be automatically migrated to the new v1 format if it is parseable by conda-recipe-manager.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/21426191953. Examine the logs at this URL for more detail.}

[hmaarrfk]

@conda-forge-admin please rerender

[hmaarrfk]

how do we go about build OSX?

[h-vetinari]

IMO the only sane way is to do like conda-forge/pytorch-cpu-feedstock#429 and switch to cirun

[h-vetinari]

Ah, right, I keep forgetting; bazel is never easy. For pytorch, it was basically no work to switch from building things on osx-64 to building on osx-arm64. Here, it seems bazel will need some massaging. At least it should be the kind of issue we've already faced a bunch of times.

CC @xhochy in case bazel-toolchain needs some modifications for being able to compile osx-64 from osx-arm64.

[xhochy]

CC @xhochy in case bazel-toolchain needs some modifications for being able to compile osx-64 from osx-arm64.

It shouldn't but I never got osx cross-compiling for tensorflow in any direction to work.

[h-vetinari]

I'd already be happy with osx-arm64 to osx-arm64 native compilation, but that also runs into issues here

[hmaarrfk]

I tried osx-x86 two days ago and it failed then too. I attributed it to my old setup though and didn’t want to make noise

[hmaarrfk]

is there any way to move this forward? can we drop OSX for tensorflow?

[h-vetinari]

is there any way to move this forward? can we drop OSX for tensorflow?

It'll be painful for dependent feedstocks, but we don't have that many of them, so I say let's drop it. Someone will have to debug bazel (and bazel-toolchain probably) for native compilation on osx-arm64, but that can come whenever.

[hmaarrfk]

@conda-forge-admin please rerender

[h-vetinari]

Let's pick up the icu migration as well. Mind if I force-push?

[hmaarrfk]

Go for it.

[h-vetinari]

Let's wait with merging this until we've merged the pytorch 2.10 update.

[hmaarrfk]

I don’t understand why waiting help?

these builds are finicky, and if it works it just gives an other option for tensorflow users to merge as is without hurting PyTorch users

[h-vetinari]

I don’t understand why waiting help?

The single server we have backing the cirun queue on linux is very congested right now. The more CI runs are competing for resources, the longer it takes for any one feedstock to build out a full set of packages. That's why I'm asking to wait ~24h until this is through, then we can merge here. I'm asking the same for conda-forge/flash-attn-feedstock#44, and am likewise waiting with conda-forge/xformers-feedstock#67, as well as putting other work (e.g. tinygrad) on hold until things have cleared up a bit (though that'll take a while, because the pytorch PR will now cause a wave of py3.14 and CUDA 13.0 PRs...).

My planned order of operations is:

• build out pytorch
• merge this PR
• finish building flash-attn PR (though we may combine that PR with migrators for 3.14 / CUDA 13)
• rest

Obviously this plan gets refined as we go along. I also can't force anyone to keep to it, but I can pretty much assure that this is the fastest way to get out packages. My goal here is to utilise the scarce resources to their maximum effect, and prioritise according to impact (where clearly, in conda-forge, pytorch > tensorflow).

[hmaarrfk]

Ci congestion.

Got it!

[h-vetinari]

OK, all the remaining jobs for pytorch have now started; that leaves only 2 agents available for tensorflow (for now), but we can already start those at least.

[hmaarrfk]

Amazing. Thanks for working to manage the queue.

[h-vetinari]

3/4 have finished, last one started now, should be done in 8h.