Matplotlib 3.9.1

[tacaswell]

Attempt to merge the rc branch to main.

[conda-forge-webservices[bot]]

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.

[tacaswell]

@conda-forge-admin, please rerender

[tacaswell]

Looks like centOS installs are failing in the docker containers:

+ /usr/bin/sudo -n yum install -y libX11 libXau libxcb mesa-libGL
Loaded plugins: fastestmirror, ovl
Determining fastest mirrors
Could not retrieve mirrorlist http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=os&infra=container error was
14: curl#6 - "Could not resolve host: mirrorlist.centos.org; Unknown error"

 One of the configured repositories failed (Unknown),
 and yum doesn't have enough cached data to continue. At this point the only
 safe thing yum can do is fail. There are a few ways to work "fix" this:

     1. Contact the upstream for the repository and get them to fix the problem.

     2. Reconfigure the baseurl/etc. for the repository, to point to a working
        upstream. This is most often useful if you are using a newer
        distribution release than is supported by the repository (and the
        packages for the previous distribution release still work).

     3. Run the command with the repository temporarily disabled
            yum --disablerepo=<repoid> ...

     4. Disable the repository permanently, so yum won't use it by default. Yum
        will then just ignore the repository until you permanently enable it
        again or use --enablerepo for temporary usage:

            yum-config-manager --disable <repoid>
        or
            subscription-manager repos --disable=<repoid>

     5. Configure the failing repository to be skipped, if it is unavailable.
        Note that yum will try to contact the repo. when it runs most commands,
        so will have to try and fail each time (and thus. yum will be be much
        slower). If it is a very temporary problem though, this is often a nice
        compromise:

            yum-config-manager --save --setopt=<repoid>.skip_if_unavailable=true

Cannot find a valid baseurl for repo: base/7/x86_64

Due to the service being taken down upstream: https://lists.centos.org/hyperkitty/list/devel@lists.centos.org/thread/EGOA27SGN7W7ASFFFBNUZJ5BXSFT4NKX/ due to centos7 going EOL June 30, 2024 (yesterday).

[tacaswell]

attn @beckermr if I am reading this right I suspect this is going to be a problem for any feedstock that uses yum_requirements.txt.

[beckermr]

cc @conda-forge/core - apparently they are now no longer even serving the old rpms?

[beckermr]

We used cos6 like this for a long time and had no issues so fun!

[jakirkham]

Maybe we can use a different mirror source?

Looks like UC Irvine maintains one and it goes back quite a bit: https://mirrors.oit.uci.edu/centos/ (though that looks like it is missing something)

Alternatively we do the same thing we did with CentOS 6 and switch to the vault mirrors

[jakirkham]

Looks like @isuruf started a PR for the latter: https://github.com/conda-forge/docker-images/pull/271

[jakirkham]

We have since deployed a fix

Restarting failed CI builds to see if these issues clear up

[jakirkham]

Looks like it is passing! 🥳

[xhochy]

There is already a 3.9.0 build uploaded to conda-forge. Should that be marked broken? Where did that come from?

[fhoehle]

There is already a 3.9.0 build uploaded to conda-forge. Should that be marked broken? Where did that come from?

IIUC: There is a rc branch in this feedstock which successfully built it: CI run and PR and final commit

[h-vetinari]

The rc branch needs to have something like the following in recipe/conda_build_config.yaml:

channel_targets:
  - conda-forge matplotlib_rc

and then rerender.

[xhochy]

Filed a PR here: https://github.com/conda-forge/matplotlib-feedstock/pull/392

[tacaswell]

ah, I was wondering how the 3.9.0 files ended up on the main channel, we must have lost that config while trying to get the builds to work at all. We just did a 3.9.1 so moved this to draft until I get that updated.

[tacaswell]

Looks like azure has decided to not run in parallel....

[xhochy]

See https://github.com/conda-forge/status/issues/181

[akrherz]

@conda-forge-admin please restart ci

[jobovy]

Version 3.9.1 doesn't seem to have made it to the conda-forge channel, even though it seems like it should have? conda search matplotlib -c conda-forge still lists 3.8.4 as the latest version and the conda-forge/matplotlib website doesn't have 3.9.1 either (even though the more recent matplotlib_rc labeled version from #392 was uploaded there). In my tests, I'm hitting DeprecationWarning: backend2gui is deprecated since IPython 8.24, backends are managed in matplotlib and can be externally registered. due to (I think) a conflict between the latest IPython 8.26.0 and matplotlib 3.8.4 that seems to be resolved in 3.9.0 (I think resulting from this PR: https://github.com/matplotlib/matplotlib/pull/27948). I can get rid of this by pip installing 3.9.1, but would prefer to use the conda version. Thanks!

[larsoner]

Looking at the main branch builds I don't see an entry for this PR's merge:

https://dev.azure.com/conda-forge/feedstock-builds/_build?definitionId=617&_a=summary&repositoryFilter=605&branchFilter=211331

No idea why that would happen. Maybe we could bug the conda-forge folks about this (?) but as a naive attempted solution I'll open a blank PR that someone could merge if they wanted and we could see if that fixes things.

[h-vetinari]

Looking at the main branch builds I don't see an entry for this PR's merge:

The interop between github and azure pipelines is fragile; though it works 99+% of the time, there is stuff that breaks, one of them being the case here (no CI started after merge). In this scenario, if you're a regular maintainer, you could do

git checkout main  # make sure it's up to date
git commit --allow-empty -m "retrigger CI"
git push upstream main  # or whatever you named the remote corresponding to the feedstock

In case someone from core with access to our azure organisation is around, they can start it manually without that extra commit, which is what I've done now.