Mark arpack 3.6.1 as not broken

[jaimergp]

Guidelines for marking packages as broken:

• We prefer to patch the repo data (see here)
  instead of marking packages as broken. This alternative workflow makes environments more reproducible.
• Packages with requirements/metadata that are too strict but otherwise work are
  not technically broken and should not be marked as such.
• Packages with missing metadata can be marked as broken on a temporary basis
  but should be patched in the repo data and be marked unbroken later.
• In some cases where the number of users of a package is small or it is used by
  the maintainers only, we can allow packages to be marked broken more liberally.
• We (conda-forge/core) try to make a decision on these requests within 24 hours.

What will happen when a package is marked broken?

• Our bots will add the broken label to the package. The main label will remain on the package and this is normal.
• Our bots will rebuild our repodata patches to remove this package from the repodata.
• In a few hours after the anaconda.org CDN picks up the new patches, you will no longer be able to install the package from the main channel.

Checklist:

• I want to mark a package as broken (or not broken):

  • Added a description of the problem with the package in the PR description.
  • Pinged the team for the package for their input.

• I want to archive a feedstock:

  • Pinged the team for that feedstock for their input.
  • Make sure you have opened an issue on the feedstock explaining why it was archived.
  • Linked that issue in this PR description.
  • Added links to any other relevant issues/PRs in the PR description.

• I want to request (or revoke) access to an opt-in CI resource:

  • Pinged the relevant feedstock team(s)
  • Added a small description explaining why access is needed

Comes from conda/infrastructure#797. @barabo suggested to "unbreak" this package to fix the annoying 404 we get in the OCI mirror.

I can't find why this was marked as broken in this repo history, but then I found it's hardcoded in conda-forge-repodata-patches-feedstock since the begginning (see conda-forge/staged-recipes#6574).

So maybe this is not the way to "unbreak" it temporarily, but rather to comment it out in the repodata patches feedstock.

[jaimergp]

Fails with:

requests.exceptions.HTTPError: 404 Client Error: Not Found for url: https://conda.anaconda.org/conda-forge/osx-64/arpack-3.6.1-blas_openblash1f444ea_0.tar.bz2

Which is expected. But the checks are not run in main, so maybe it does work?

[jaimergp]

Just noticed there a total of five artifacts 404ing:

https://conda.anaconda.org/conda-forge/osx-64/arpack-3.6.1-blas_openblash1f444ea_0.tar.bz2
https://conda.anaconda.org/conda-forge/osx-64/lammps-2018.03.16-.tar.bz2
https://conda.anaconda.org/conda-forge/osx-64/sundials-3.1.0-blas_openblash0edd121_202.tar.bz2
https://conda.anaconda.org/conda-forge/osx-64/vlfeat-0.9.20-h470a237_2.tar.bz2
https://conda.anaconda.org/conda-forge/osx-64/xtensor-python-0.19.1-h3e44d54_0.tar.bz2

All of them part of https://github.com/conda-forge/conda-forge-repodata-patches-feedstock/blob/b816bc1c538459e9abdbe106ccb110973a2c1457/recipe/gen_patch_json.py#L93-L138.

[jaimergp]

@conda-forge/core, what do you think will happen if we mark them as not broken (comment them out) in conda-forge-repodata-patches temporarily so the CDN can sync them properly? This is preventing OCI mirroring too.

[jaimergp]

We don't need this anymore