Skip to content
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

Work list for R 4.4/Bioconductor 3.19 builds #49778

Open
17 of 62 tasks
mfansler opened this issue Aug 3, 2024 · 11 comments
Open
17 of 62 tasks

Work list for R 4.4/Bioconductor 3.19 builds #49778

mfansler opened this issue Aug 3, 2024 · 11 comments

Comments

@mfansler
Copy link
Member

mfansler commented Aug 3, 2024

Preparation for R 4.4/Bioconductor 3.19

It looks like we'll cross the r-essentials milestone1 for building R 4.4 on Conda Forge this weekend. This seems like a good point to start thinking about the transition of Bioconductor packages here to v3.19. To expedite this, it would be useful to identify required dependencies that need work to migrate. This helps those of us working on Conda Forge to focus our efforts.

This list should now be comprehensive thanks to a helpful script from @aliciaaevans. However, feel free comment or check things off if you see they have completed. Updated info is available on the Conda Forge Status page.

Problematic R 4.4 Migrations

📢 Updated 2 September 2024 using missingCranPackages.py script.

Awaiting migration of 62 packages

In PR (20 packages)

NB: This is where the most help is needed!

Bot Error (4 packages)

Licenses have been packaged for these as of 9 Sept. and should start migration within ~24 hours.

  • r-rebus.unicode: bot error (bot CI job): main: Error running migrate-feedstock in container - JSON could not parse stdout:
  • r-rebus.datetimes: bot error (bot CI job): main: Error running migrate-feedstock in container - JSON could not parse stdout:
  • r-rebus.numbers: bot error (bot CI job): main: Error running migrate-feedstock in container - JSON could not parse stdout:
  • r-logr: bot error (bot CI job): main: Error running migrate-feedstock in container - JSON could not parse stdout:

Not Solvable (7 packages)

  • r-spdep: not solvable (bot CI job) @ main r-sf * cannot be installed because there are no viable options
  • r-magick: not solvable (bot CI job) @ main No candidates were found for imagemagick *.
  • r-gstat: not solvable (bot CI job) @ main r-sf >=0.7_2 cannot be installed because there are no viable options
  • r-rmpi: not solvable (bot CI job) @ main No candidates were found for openmpi 5.*.
  • r-transformr: not solvable (bot CI job) @ main r-sf * cannot be installed because there are no viable options
  • r-protolite: not solvable (bot CI job) @ main r-sf * cannot be installed because there are no viable options
  • r-tkrplot: not solvable (bot CI job) @ main No candidates were found for tcl *.

Awaiting Parents (31 packages)

  • r-fds: Awaiting parents ( r-hdrcde, r-locfit, r-rcurl, r-rainbow )
  • r-hdrcde: Awaiting parents ( r-locfit )
  • r-qdaptools: Awaiting parents ( r-rcurl )
  • r-summarytools: Awaiting parents ( r-magick )
  • r-gganimate: Awaiting parents ( r-transformr )
  • r-rebus: Awaiting parents ( r-rebus.unicode, r-rebus.datetimes, r-rebus.numbers )
  • r-tidytidbits: Awaiting parents ( r-extrafont, r-rttf2pt1 )
  • r-dicer: Awaiting parents ( r-infotheo )
  • r-gprofiler: Awaiting parents ( r-rcurl )
  • r-waffle: Awaiting parents ( r-extrafont, r-rttf2pt1 )
  • r-extrafont: Awaiting parents ( r-rttf2pt1 )
  • r-mvoutlier: Awaiting parents ( r-fds, r-fda, r-hdrcde, r-rcurl, r-locfit, r-robcompositions, r-rainbow )
  • r-opencpu: Awaiting parents ( r-protolite )
  • r-xml2r: Awaiting parents ( r-rcurl )
  • r-hrbrthemes: Awaiting parents ( r-extrafont, r-rttf2pt1 )
  • r-ggimage: Awaiting parents ( r-magick )
  • r-robcompositions: Awaiting parents ( r-fds, r-fda, r-hdrcde, r-rcurl, r-locfit, r-rainbow )
  • r-agricolae: Awaiting parents ( r-spdep )
  • r-plsvarsel: Awaiting parents ( r-msqc )
  • r-ggalt: Awaiting parents ( r-extrafont, r-rttf2pt1 )
  • r-survivalanalysis: Awaiting parents ( r-extrafont, r-tidytidbits, r-rttf2pt1 )
  • r-taxize: Awaiting parents ( r-bold )
  • r-gprofiler2: Awaiting parents ( r-rcurl )
  • r-ggrastr: Awaiting parents ( r-cairo )
  • r-cvxr: Awaiting parents ( r-scs )
  • r-animation: Awaiting parents ( r-magick )
  • r-rainbow: Awaiting parents ( r-hdrcde, r-locfit )
  • r-fda: Awaiting parents ( r-fds, r-hdrcde, r-locfit, r-rcurl, r-rainbow )
  • r-webchem: Awaiting parents ( r-rcurl )
  • r-varfrompdb: Awaiting parents ( r-xml2r, r-rcurl )
  • r-flatxml: Awaiting parents ( r-rcurl )

"How can I help?"

If you would like to help, you can either send PRs with fixes or make comments on the Conda Forge feedstocks about possible solutions.

Generally the three status categories correspond to different types of troubleshooting.

  • "In PR" - feedstocks with this are usually having compilation problems (mostly C++); typically the issue is not about compilation per se but rather getting linking working.
  • "Not solvable" - feedstocks with this usually indicate something about the packages they depend on is wrong; identifying those specific packages is the first step and then figuring out how to fix those upstream
  • "Bot error" - feedstocks with this usually mean something is substandard about the recipe itself and the migrator is crashing on it; anecdotally, this frequently involves license issues, such as not including an explicit license_file: entry in the meta.yaml

The "In PR" is often the most difficult and requires some knowledge of how code compilation is done in R; the "Not solvable" involves sleuthing around; and "Bot error" is more like review work - read the recipe and compare it one that works.


[1] The Conda Forge r-essentials package is a metapackage that represents common workflows used in R, such as Shiny, tidyverse, and Jupyter kernel support.

@mfansler
Copy link
Member Author

mfansler commented Aug 3, 2024

CC: @daler just a heads up

@aliciaaevans
Copy link
Contributor

conda-forge/r-clusterr-feedstock#25 seems like maybe the Travis build just needs to be re-triggered.

@mfansler
Copy link
Member Author

conda-forge/r-clusterr-feedstock#25 seems like maybe the Travis build just needs to be re-triggered.

Travis CI is failing for all linux-ppc64le jobs. There are some notes in the Status Issue about how to convert to either cross-compiling or emulation on Azure to get around this.

@danielnachun
Copy link

I took a pass through all the "In PR" failures (rerendering a handful whose logs had expired) and posted a comment for each one either extracting the error, or when possible proposing a fix. I will try to push fixes for the ones where I had a possible solution.

@mfansler One quick question - what do you think about just adding -pthread to PKG_LIBS for the handful of packages failing due to this? I think there only 3 affected by this in the above list:
conda-forge/r-pdftools-feedstock#48
conda-forge/r-strawr-feedstock#4
conda-forge/r-rmixmod-feedstock#17

I agree with the your suggestion in conda-forge/r-base-feedstock#325 to add -pthread to the Makeconf for Windows so that we don't have to keep adding this manually, but I'm not sure we need to wait for that be done for just 3 packages.

@mfansler
Copy link
Member Author

mfansler commented Sep 4, 2024

@danielnachun that's wonderful - thanks for spending time with this! ❤️

Unfortunately, I'm short on bandwidth today, but will try having a look as soon as I can.

RE: -pthread - yes, we can just manually override to expedite getting to Bioconductor 3.19.

@danielnachun
Copy link

The discussion in conda-forge/r-rcppalgos-feedstock#16 prompted me to check something I should have looked into sooner - among the packages that are only failing on Windows, which ones have never had a successful Windows build? It turns out these 6 packages have not, and they are some of the weirder or more difficult failures:

So as not to block the R 4.4 migration, I think we should consider skipping the Windows builds on these for now as they don't have obvious solutions and Windows users were never able to use them anyway.

@danielnachun
Copy link

@mfansler for packages that don't have a PR because of bot errors or unsolvable dependencies, is it sufficient just to rerender the feedstock with the necessary manual fixes? Or does the migrator make other manual changes (aside from re-enabling Windows if it was skipped)?

Also does the migrator automatically open PRs for packages that were previously blocked by a missing parent? Or does a PR need to be made to https://github.com/conda-forge/conda-forge-pinning-feedstock?

@mfansler
Copy link
Member Author

mfansler commented Sep 9, 2024

@danielnachun so far, I've adopted the practice that it is better, when possible, to fix the recipe without manually forcing a R 4.4/UCRT migration, so that the bot can start working normally. Specifically, to your question: Yes, the migrator will eventually notice fixed recipes and (AFAIK) will retry solving failed recipes every ~24 h.

When we manually migrate it, the problem often doesn't go away (e.g., downstream dependencies may encounter same issue) and technical debt accrues. However, there are exceptions that are unavoidable, so here are the different cases I see:

  1. bot error - all of these I've fixed to now have been driven by substandard recipes, typically involving the lack of a proper license file. Rerendering the recipe without adding R 4.4 migration, but fixing the substandard aspect will unlock the recipe and should make it so that recipe just works in future migrations.
  2. not solvable + CI error - some recipes come out as not solvable because one of their requirements made it through PR, but had a CI error that resulted in not uploading the build artifact. This is a matter of tracking down the problematic dependency.
  3. not solvable + missing platform - another scenario is that the recipe's dependency couldn't build a particular platform. Sometimes this can be an error (e.g., there was a selector on skip: true that the bot didn't recognize) and we should try to fix it; in other cases, it can really be intrinsic, and I think this case is what you're interested.

Manual Migration

For the case 3, manual migration is done by adding in the migration file (see example commit) and making some changes to the meta.yaml:

  • delete definition and uses of {{ native }} Jinja variable
  • bump build number
  • delete merge_build_host: true
  • remove any skips
  • add any stdlib if missing
  • if pkg-config is used, remove the {{ posix }} prefix from it

Then a rerender needs to be done.

I believe the bot will recognize that the package is now available, and downstream dependencies should start flowing. However, that will not be the case if you are still skipping platforms - the downstream dependencies will be not solvable.

@mfansler
Copy link
Member Author

@danielnachun FYI, any new PRs for R packages appear blocked at the moment: conda-forge/conda-forge-pinning-feedstock#6401

@danielnachun
Copy link

I was going to ask why things weren't restarting but that makes sense. Hopefully this gets figured out soon!

When we manually migrate it, the problem often doesn't go away (e.g., downstream dependencies may encounter same issue) and technical debt accrues.

This an important point for skipping Windows - if nothing depends on the package, then it doesn't propagate elsewhere. So we should put the most effort on fixing packages with dependents. Of the 6 I posted above, only r-magick and r-ttfpt1 seem to have a significant number of dependents, and we've now fixed r-ttfpt1 on Windows anyway. Getting imagemagick built on Windows may be a challenge but seems like it would resolve some issues

One other question - if a package is noarch: generic, does it still get count as being blocked by missing parents if one its dependencies is available for Linux but not Windows? I ask because noarch: generic packages are only built on Linux. Of course the package wouldn't be installable on Windows but that ideally shouldn't prevent its migration to a newer R.

@mfansler
Copy link
Member Author

@danielnachun correct, noarch builds won't be blocked by a parent that fails on win-64. The solver will only try a linux-64 solve.

For the 6 feedstocks you highlighted, I've fixed all but r-rcppalgos (merged with win-64 skipped) and r-primme (just haven't gotten to yet, but seems doable). The r-magick in particular I was able to use the vendored imagemagick rather than trying to get Conda Forge building that for win-64. For r-rmpi, I've addressed the not solvable aspect, but we will still need to adjust further once the migrator actually sends a PR.

Thanks for all the new reviews! 🤩 I may not have time today, but I will eventually get to them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants