Re: [R-pkg-devel] URL woes at CRAN: Anaconda edition

[Dirk Eddelbuettel]

Thank you all -- expecially Aron and Ivan for the deep dive on the underlying
aspect of the hosting of that web property.  And of course to Uwe for
approving the package manually.

For my taste, life is too short for all this. So users be damned, and I have
now removed the badge.  At the end of the day it is better for Uwe et al (and
of course our side) to have these things autoprocess. If this kind of stuff
is in the way, I will just remove it as maintainer.

Thanks again to all.

Cheers, Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] URL woes at CRAN: Anaconda edition

[Ivan Krylov]

On Thu, 30 Nov 2023 10:49:36 -0600
Dirk Eddelbuettel  wrote:

>   Found the following (possibly) invalid URLs:
> URL: https://anaconda.org/conda-forge/r-tiledb
>   From: README.md
>   Status: 400
>   Message: Bad Request

The problem is that https://anaconda.org/conda-forge/PACKAGE fails to
answer to HEAD requests and only answers to GET requests. HEAD differs
from GET in that there is no need to send the actual content of the page
in response to the request; it is enough to say "200 OK" (and pass the
check) or, as it happens here, "400 Bad Request".

It may help to ask ContinuumIO to support HEAD requests by filing a bug
report for the Anaconda.org website at
. It may be worth
referencing RFC 9110, section 9.3.2
, in
particular:

>> The HEAD method is identical to GET except that the server MUST NOT
>> send content in the response.

>> The server SHOULD send the same header fields in response to a HEAD
>> request as it would have sent if the request method had been GET.

Arguably, the spirit of the standard is being violated here (if not the
letter, which only mentions headers).

-- 
Best regards,
Ivan

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] URL woes at CRAN: Anaconda edition

[Uwe Ligges]

On 30.11.2023 18:28, Aron Atkins wrote:

On Thu, Nov 30, 2023 at 11:49 AM Dirk Eddelbuettel  wrote:



And *of course* the same URL resolves fine for me in the browser without
any
apparent redirect.  Bit of a web newb here but is there anything I can do
short of deleteing the badge?



The badge you're referencing is hosted by a cloudflare CDN, which uses
"magic" to return error responses to non-humans.

You can see this behavior by running curl against the URL:

curl -I https://anaconda.org/conda-forge/r-tiledb
HTTP/2 400
server: cloudflare
...

I have seen this behavior for other resources, but generally have
experienced 403 responses.

This urlchecker issue discusses what I had seen:
https://github.com/r-lib/urlchecker/issues/26

I do not have guidance other than to either remove the URL or add a note
stating that the 400 errors are only presented to robots. Perhaps CRAN
occasionally adjusts its User-Agent to avoid some of these challenges? Not
sure.

Aron


This (status 400) underlies manual inspection and we let this pass.

Best,
Uwe Ligges

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] URL woes at CRAN: Anaconda edition

[Aron Atkins]

On Thu, Nov 30, 2023 at 11:49 AM Dirk Eddelbuettel  wrote:

>
> And *of course* the same URL resolves fine for me in the browser without
> any
> apparent redirect.  Bit of a web newb here but is there anything I can do
> short of deleteing the badge?


The badge you're referencing is hosted by a cloudflare CDN, which uses
"magic" to return error responses to non-humans.

You can see this behavior by running curl against the URL:

curl -I https://anaconda.org/conda-forge/r-tiledb
HTTP/2 400
server: cloudflare
...

I have seen this behavior for other resources, but generally have
experienced 403 responses.

This urlchecker issue discusses what I had seen:
https://github.com/r-lib/urlchecker/issues/26

I do not have guidance other than to either remove the URL or add a note
stating that the 400 errors are only presented to robots. Perhaps CRAN
occasionally adjusts its User-Agent to avoid some of these challenges? Not
sure.

Aron
-- 
email: aron.atk...@gmail.com
home: http://gweep.net/~aron/

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

[R-pkg-devel] URL woes at CRAN: Anaconda edition

[Dirk Eddelbuettel]

I added a badge to point to Conda builds for the work repo:

  
[![Anaconda](https://anaconda.org/conda-forge/r-tiledb/badges/version.svg)](https://anaconda.org/conda-forge/r-tiledb)


And as it goes with all good intentions I immediately got punished on the
next upload:

  Found the following (possibly) invalid URLs:
URL: https://anaconda.org/conda-forge/r-tiledb
  From: README.md
  Status: 400
  Message: Bad Request

And *of course* the same URL resolves fine for me in the browser without any
apparent redirect.  Bit of a web newb here but is there anything I can do
short of deleteing the badge?

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Troubleshooting Winbuilder Run Timeouts

[Andrew Robbins via R-package-devel]

Hi Ivan,

Thank you for giving my package check a run-through. You have it 
correct-every win-builder log hangs/halts in that exact example. The 
only other anomaly I notice on win-builder is that the elapsed time 
reported to Rcout is 0-which is clearly incorrect. DNDEBUG removing the 
assert calls would certainly make my life quite a bit easier when it 
comes time to maintain the package, so I'll definitely give that a try. 
Re: declared requirements, WindowsOverrides contains slightly modified 
copies of cmake locator files with patches that will likely be included 
in a later Rtools43 release. I'm fairly sure pkgbuild in rtools can be 
assumed present, but that's more of a Tomas question (and it may be 
worth declaring either way). Regardless, those files aren't intended to 
stick around for any longer than they need to. Any other suggestions are 
always welcome, but I do get the feeling that something is fishy on 
win-builder's end.



Best,

Andrew

On 11/30/2023 7:40 AM, Ivan Krylov wrote:

Hi Andrew Robbins,

В Mon, 27 Nov 2023 12:22:44 -0500
Andrew Robbins via R-package-devel 
пишет:


I'm currently attempting to submit a package to CRAN and am getting
timeouts during the "running examples" phase of the winbuilder tests
that I cannot reproduce locally or on the r-hub windows runner

Do I understand it correctly that in multiple win-builder tests, you
always get a timeout in the same inmf example? Or is it different
examples?

There doesn't seem to be a lot of code between Rcpp::Rcerr << "INMF
started, niter=" << niter << std::endl; and Progress p(niter, verbose);
to crash or hang in. I've tried to reproduce the problem myself, but it
doesn't happen to me either.

So far I only noticed minor things, like the build-time dependency on
pkgbuild (from tools/WindowsOverrides/hdf5/hdf5-config.cmake) that may
be worth declaring in your DESCRIPTION. I also think that your patch to
hwloc can be reduced by adding a -DNDEBUG somewhere instead of patching
out calls to assert(). I think that the C standard (e.g. C99, WG14 draft
version N1256, 7.4) requires assert() to expand to ((void)0) if NDEBUG
is defined.

The amount of systems engineering effort to do the right thing that
went into this package is really impressive; I'd hate to see it fail.


--
Andrew Robbins
Systems Analyst, Welch Lab
University of Michigan
Department of Computational Medicine and Bioinformatics



OpenPGP_signature.asc
Description: OpenPGP digital signature
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Troubleshooting Winbuilder Run Timeouts

[Ivan Krylov]

Hi Andrew Robbins,

В Mon, 27 Nov 2023 12:22:44 -0500
Andrew Robbins via R-package-devel 
пишет:

> I'm currently attempting to submit a package to CRAN and am getting 
> timeouts during the "running examples" phase of the winbuilder tests 
> that I cannot reproduce locally or on the r-hub windows runner

Do I understand it correctly that in multiple win-builder tests, you
always get a timeout in the same inmf example? Or is it different
examples?

There doesn't seem to be a lot of code between Rcpp::Rcerr << "INMF
started, niter=" << niter << std::endl; and Progress p(niter, verbose);
to crash or hang in. I've tried to reproduce the problem myself, but it
doesn't happen to me either.

So far I only noticed minor things, like the build-time dependency on
pkgbuild (from tools/WindowsOverrides/hdf5/hdf5-config.cmake) that may
be worth declaring in your DESCRIPTION. I also think that your patch to
hwloc can be reduced by adding a -DNDEBUG somewhere instead of patching
out calls to assert(). I think that the C standard (e.g. C99, WG14 draft
version N1256, 7.4) requires assert() to expand to ((void)0) if NDEBUG
is defined.

The amount of systems engineering effort to do the right thing that
went into this package is really impressive; I'd hate to see it fail.

-- 
Best regards,
Ivan

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel