Remove second URL for tzdata source which is not tzdata

conda-forge / tzdata-feedstock

A conda-smithy repository for tzdata.

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

1 stars 11 forks source link

Remove second URL for tzdata source which is not tzdata #27

Closed SylvainCorlay closed 3 months ago

SylvainCorlay commented 3 months ago

Thankfully the second URL was only used in case of failure with the first one.

conda-forge-webservices[bot] commented 3 months 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.

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

For recipe:

This recipe is using a compiler, which now requires adding a build dependence on {{ stdlib("c") }} as well. Note that this rule applies to each output of the recipe using a compiler. For further details, please see https://github.com/conda-forge/conda-forge.github.io/issues/2102.
You're setting a requirement on sysroot_linux- directly; this should now be done by adding a build dependence on {{ stdlib("c") }}, and overriding c_stdlib_version in recipe/conda_build_config.yaml for the respective platform as necessary. For further details, please see https://github.com/conda-forge/conda-forge.github.io/issues/2102.

SylvainCorlay commented 3 months ago

cc @ocefpaf

ocefpaf commented 3 months ago

My understanding is that we need tzcode to build and distribute tzdata.

mbargull commented 3 months ago

Thankfully the second URL was only used in case of failure with the first one.

That would be the

source:
  url:
    - main url
    - fallback url

case. The second source entry is indeed used here since, AFAIR, it contains zic's sources to compile the timezone data files. We could/should(?) merge the tzcode feedstock with this one or depend on tzcode here -- the latter might need some Makefile massaging, IIRC; so merging the feedstocks might even be easier. I currently don't have time to look into it, but can review things if someone wants to tackle it -- I you do, just make sure to compare the outputs to the current package to ensure it covers everything and has the same data formats etc.

ocefpaf commented 3 months ago

We could/should(?) merge the tzcode feedstock with this one or depend on tzcode here -- the latter might need some Makefile massaging, IIRC; so merging the feedstocks might even be easier.

Yes. That was the decision from our last meeting as far as I recall.

I currently don't have time to look into it, but can review things if someone wants to tackle it -- I you do, just make sure to compare the outputs to the current package to ensure it covers everything and has the same data formats etc.

Same. While inelegant, what we have now works and is correct. Having both in the same feedstock is desirable but not required.

SylvainCorlay commented 3 months ago

Okay, it was a misunderstanding on my end.