-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to keep in sync with CRAN's settings? #10
Comments
FWIW I updated mine (still at https://github.com/rocker-org/r-devel-san-clang) and can reproduce with it. It would still be nice if we had a way to keep up with CRAN :-/ |
I recently encountered a similar situation where CRAN was getting significant warnings with R-devel and gcc 8, but this docker image had an older compiler so it wasn't immediately easy to reproduce. I agree that it would be nice to have a simple way to keep up with CRAN but it's not clear to me how. |
We could try to pool resources. Given non communicative "some of them" are, we may have to bite the bullet and build on fedora core (eeek). Come to think about it, maybe not. "Some of them" are clearly obsessive-compulsive and follow re-releases of compilers at times which we may not have time for. (Then again, there is an apt-get'able archive with pre-release compilers for IIRC gcc and clang too). Maybe start with an IFTT monitor of the Oxford page? What saved my bacon this time was that @krlmlr had done such fine work on my Dockerfile that I already had the special flags to ignore errors at buildtime -- so I "just" had to update to clang 7. With that the clang sanitizer reproduced on my package what they were howling about and a "fixed" package is now on CRAN. Sometimes I have hope to pin one them down and start a conversation about Dockerizing their resources. But then most often reality sets back ... So in short count me in "not clear to me how". Makes two of us. |
(Not sure this is a valid issue myself so feel free to close)
I once again got a love note from CRAN about UBSAN, and as has happened in the past cannot reproduce. It is a wee bit maddening that they expect us to jump over hoops, but don't really share their rope. Do you have any ideas / plans / suggestions / ... about we could do that better?
(My current case in point is RcppStreams which passes your
RDsan
andRDcsan
yet gets BDR's clang-san to yell at it over some issue deep down in Boost.)The text was updated successfully, but these errors were encountered: