[R] CRAN packaging checklist for version 20.0.0.1

[amoeba]

Packaging Checklist for CRAN Release

For a high-level overview of the Arrow release process see the Apache Arrow Release Management Guide.

Before the Arrow Release Candidate Is Created

• Create a GitHub issue entitled [R] CRAN packaging checklist for version X.Y.Z and copy this checklist to the issue.
• Review deprecated functions to advance their deprecation status, including removing preprocessor directives that no longer apply (search for ARROW_VERSION_MAJOR in r/src).
• Evaluate the status of any failing nightly tests and nightly packaging builds. These checks replicate most of the checks that CRAN runs, so we need them all to be passing or to understand that the failures may (though won't necessarily) result in a rejection from CRAN.
• Check current CRAN check results.
• Ensure the contents of the README are accurate and up to date.
• Run urlchecker::url_check() on the R directory at the release candidate.
  commit. Ignore any errors with badges as they will be removed in the CRAN release branch.
• Polish NEWS but do not update version numbers (this is done automatically later). You can find commits by, for example, git log --oneline <sha of last release>..HEAD | grep "\[R\]".
• For major releases, prepare content for social media highlighting new features.

Wait for the release candidate to be created.

After the Arrow Release Candidate Has Been Created

• Create a CRAN-release branch from the release candidate commit, name the new branch maint-X.Y.Z-r and push to upstream.

Prepare and Check Package That Will Be Released to CRAN

• git fetch upstream && git checkout maint-X.Y.Z-r && git clean -f -d.
• Run make build. This copies Arrow C++ into tools/cpp, prunes some unnecessary components, and runs R CMD build to generate the source tarball. Because this will install the package, you will need to ensure that the version of Arrow C++ available to the configure script is the same as the version that is vendored into the R package (e.g., you may need to unset ARROW_HOME).
• devtools::check_built("arrow_X.Y.Z.tar.gz") locally.

Wait for Arrow Release Vote

• Release vote passed

Generate R Package to Submit to CRAN

• If the release candidate commit updated, rebase the CRAN release branch on that commit.
• Pick any commits that were made to main since the release commit that were needed to fix CRAN-related submission issues identified in the above steps.
• Remove badges from README.md.
• Run urlchecker::url_check() on the R directory.
• Create a PR entitled WIP: [R] Verify CRAN release-X.Y.Z-rcX. Add a comment @github-actions crossbow submit --group r to run all R crossbow jobs against the CRAN-specific release branch.
• [ ]~~ Run Rscript tools/update-checksums.R <libarrow version> to download the checksums for the pre-compiled binaries from the ASF artifactory into the tools directory.~~
• Regenerate arrow_X.Y.Z.tar.gz (i.e., make build).

Check Binary Arrow C++ Distributions Specific to the R Package

• Upload the .tar.gz to win-builder (r-devel only) and confirm with Jon (who will automatically receive an email about the results) that the check is clean.
• Upload the .tar.gz to macOS Builder and confirm that the check is clean.
• Check install.packages("arrow_X.Y.Z.tar.gz") on Ubuntu and ensure that the hosted binaries are used.
• devtools::check_built("arrow_X.Y.Z.tar.gz") locally one more time (for luck).

Submit Package to CRAN

This step must be done by the current package maintainer.

• Upload arrow_X.Y.Z.tar.gz to the CRAN submit page.
• Confirm the submission email.

Wait for CRAN to Accept the Submission

• CRAN has accepted the submission.
• Tag the tip of the CRAN-specific release branch with r-universe-release.
• Add a new line to the matrix in the backwards compatability job.
• (patch releases only) Update the package version in ci/scripts/PKGBUILD, r/DESCRIPTION, and r/NEWS.md.
• (CRAN-only releases) Rebuild news page with pkgdown::build_news() and submit a PR to the asf-site branch of the docs site with the contents of arrow/r/docs/news/index.html replacing the current contents of arrow-site/docs/r/news/index.html.
• (CRAN-only releases) Bump the version number in r/pkgdown/assets/versions.json, and update this on the the asf-site branch of the docs site too..
• Review the packaging checklist template and update as needed.
• Wait for CRAN-hosted binaries on the CRAN package page to reflect the new version.
• Post already-prepared content to social media.
  • Use Bryce's script for contributor calculation.

PRs to cherry pick

To be cherry picked onto maint branch:

• GH-46394: [C++][R] gcc-UBSAN errors on CRAN  #46397
• GH-40756: [C++] Remove dead Boost urls #46452

Component(s)

R

[jonkeane]

Thanks for this! I think we should try to (re)submit with these two pulled in. We definitely don't need to make a C++ binary release, since the issues on CRAN are all runners that build from source regardless. Is there anything I can do to help with this? Those two patches should be relatively low risk.

[amoeba]

I'm happy to prep the release tarball, especially since it should be pretty quick. Thanks for catching and fixing the check failure and just generally being on top of that.

[amoeba]

I created maint-20.0.0.1-r from maint-20.0.0-r and cherry-picked the follow commits:

• 575cae6
• 12424cd

I'll make the checklist and verification PR a bit later today.

[amoeba]

Issue title/body updated, verification PR created.

[amoeba]

Hi @jonkeane. I submitted the wrong tarball to winbuilder at first but resubmitted with the correct one so you should see two emails. The correct tarball is at https://files.brycemecum.com/arrow_20.0.0.1.tar.gz. I also submitted to macbuilder (release, devel).

Once that's all clear we should be good to submit.

[amoeba]

Looks like both win/mac builder are good. Final tarball for submission is at https://files.brycemecum.com/arrow_20.0.0.1.tar.gz whenever you get a chance @jonkeane.

[jonkeane]

Thanks! I just submitted

[jonkeane]

Sigh, just got an email that we are failing on "special/gcc-san". The error is in installation, the full log is https://win-builder.r-project.org/incoming_pretest/arrow_20.0.0.1_20250521_003119/specialChecks/gcc-san/package/00install.out

I haven't (yet) figured out what it's complaining about, I'll keep looking, but @kou might see the issue quicker than I do.

I see a bunch of warnings, I can't tell if the issue is that those are being converted into errors here (though it doesn't look like it)?

But also at the end I see:

make[2]: *** [src/parquet/CMakeFiles/parquet_objlib.dir/build.make:499: src/parquet/CMakeFiles/parquet_objlib.dir/statistics.cc.o] Interrupt
make[2]: *** [src/parquet/CMakeFiles/parquet_objlib.dir/build.make:513: src/parquet/CMakeFiles/parquet_objlib.dir/stream_reader.cc.o] Interrupt
make[1]: *** [CMakeFiles/Makefile2:2359: src/parquet/CMakeFiles/parquet_objlib.dir/all] Interrupt
gmake: *** [Makefile:146: all] Interrupt
**** Complete build log may still be present at /home/hornik/tmp/scratch/Rtmp7K2SHS/working_dir/RtmpdYlOBX/file138ab23f05ef22.log 
ERROR: configuration failed for package ‘arrow’

Does that Interrupt indicate that the build itself was stopped by some external process? That's my first interpretation, but I'm not totally sure.

[kou]

You're right. The log is strange.

Can we retry with cmake --build --verbose?

diff --git a/r/inst/build_arrow_static.sh b/r/inst/build_arrow_static.sh
index fc3a173294..4c09575594 100755
--- a/r/inst/build_arrow_static.sh
+++ b/r/inst/build_arrow_static.sh
@@ -108,7 +108,7 @@ ${CMAKE} -DARROW_BOOST_USE_SHARED=OFF \
 -G "${CMAKE_GENERATOR:-Unix Makefiles}" \
 ${SOURCE_DIR}
 
-${CMAKE} --build . --target install -- -j $N_JOBS
+${CMAKE} --build . --target install --verbose -- -j $N_JOBS
 
 if command -v sccache &> /dev/null; then
 echo "=== sccache stats after the build ==="

[jonkeane]

Can we retry with cmake --build --verbose?

This is unfortunately on CRAN's machines, and I don't think they would re-run with different arguments for us 😕

Is there anything in there that you see that indicates something other than this being killed by an outside process? I'm not totally surprised that they might have a check on these processes and since it's compiling (a lot) with the sanitizer on it might have been killed after taking too long. But I want to make sure we're not missing something else before I ask them if the problem is on their machine.