add test: for openssl problem

[bernt-matthias]

xref galaxyproject/tools-iuc#4901

fix might be analogous to https://github.com/conda-forge/curl-feedstock/blob/641bda20ddba19e4ff3b2cf9e179e10842c52930/recipe/meta.yaml#L104

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

[conda-forge-webservices]

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.

[bernt-matthias]

Test is failing for linux_64_r_base4.1, linux_aarch64_r_base4.1, linux_ppc64le_r_base4.1, osx_64_r_base4.1 ..

I see curl 7.86.0 installed in failing tests and libcurl and curl (8.0.1) in successful tests. Not sure if its missing libcurl or a problem of 7.x (or something else).

[mfansler]

I'm not sure the openssl is justified (it doesn't link against it), however, the recipe is definitely missing a libcurl (for # [not win]) dependency and that might be the issue.

Also, rather than an ad hoc test against a KEGG link, it would be better to run the testthat tests in the package.

[bernt-matthias]

Thanks for the fast feedback.

it would be better to run the testthat tests in the package

Do you have an example where this is done?

[mfansler]

This recent recipe has the testthat tests: https://github.com/conda-forge/r-rgenoud-feedstock

Note that the build scripts need --install-tests added to the R CMD INSTALL.

[bernt-matthias]

Seems to be a curl problem. When I execute curl http://rest.kegg.jp/conv/ncbi-geneid/dme -L locally (I have 7.81) I get the same error on my local ubuntu.

Here it is suggested that this due to openssl 3 ..

It feels like this should be fixed at the curl feedstock, but I'm not sure if this is possible because they are already at version 8.x (which we can't use here because it conflicts with R 4.1) ... SNAFU :)

[mfansler]

My suspicion is that it all traces back to the fact that R 4.1 has not updated to the latest krb, which libcurl links against. This is what is triggering the solver to use an older version of libcurl and these maybe don't have correct upper bounds on the openssl. (everything should be solving to libcurl=8 as per the Conda Forge global pinnings)

It will take a bit to determine the proper solution here. Probably need to patch some metadata on libcurl to determine what the correct openssl constraints on the libcurl libraries should be. Also, we need to patch the metadata on this package to properly declare what versions of libcurl each build was linked against.

Forcing openssl=1 is not a proper solution for Conda Forge (though we could consider adding it as variant).

Unfortunately, I'm short on time, but could maybe get look into this over the weekend.

[mfansler]

BTW, anytime you change a library host requirement, you need to rerender:

@conda-forge-admin please rerender

[bernt-matthias]

Thanks for the detailed explanations. Let me know if I can help.

I will add the testthat testing and revert the pinning.. Let's see if this fails as well. Maybe that's a small step forward.

[bernt-matthias]

The testthat tests seem not to cover the openssl problems, but they show a problem with windows (meh).

[mfansler]

Maybe we just skip the testthat tests on Windows. As I suspected, everything else passes with the merge of conda-forge/r-base-feedstock/pull/236. We'll try it one more time, and if the Windows fails again we'll skip that test - seems to be only one failure on something minor anyway.

[mfansler]

@conda-forge-admin please rerender

[mfansler]

I opted to retain the testing in Windows, but let it pass even if it fails. That way, we can still observe where it fails and consider it "good enough".

If you want to switch this out of draft mode, I'll give it a final review then merge. I think this is good progress on improving the recipe, but people may still encounter issues until #22 is addressed (i.e., patching metadata on old builds).

[bernt-matthias]

Thanks for your time @mfansler. PR is now ready for review.

[mfansler]

@bernt-matthias thanks again for submitting this! Just as an afterthought, you may want to suggest directly adding a testthat test upstream in the curl package, since this uncovered a gap in the testing regime.

[bernt-matthias]

good idea jeroen/curl#298