Bringing R packages to Fedora is an Herculean task, especially considering the rate at which [CRAN](https://cran.r-project.org) grows nowadays. This is an attempt to maintain an RPM repo for most of CRAN in an automated way using Fedora Copr, while ensuring compatibility with the packages already in the official repos. Still under construction. Stay tuned.

This is a companion discussion topic for the original entry at https://copr.fedorainfracloud.org/coprs/iucar/cran/
1 Like

Please, stop spamming copr with thousands of builds at once.

You’re not the only one user of the copr service, respect other users.

1 Like

+1 I can’t build anything when this and this slows my fedora-review process. :smiley:

As i know there is dedicated server in Fedora for this.

Note that the long queue in Copr are not caused by Cran project. One user can block max 7 builders at the same time (out of 44). At the same time, if anyone submit big bulk of builds at once, it is highly recommended to use copr-cli build --background to lower your priorities and not block others.

Assuming that iucar/cran is not violating copr policies and that batches are sent correctly using --background to lower the noise of other users, question is: is it really needed to rebuild all CRAN repository? Is there a request behind this or is this building just for fun?

The CRAN builds are not submitted with --background. There are 0 builds with lower priority pending right now.

I’m also doing some “big” (a few hundred packages) batches of COPR builds regularly, and originally I used --background to do that, just to be a good “internet citizen”. But I had to stop using lower priority since all the CRAN builds started, or otherwise my builds would basically never get scheduled to run.

A new record has been taken - 14k pending builds :roll_eyes:

Sorry, guys, I wasn’t receiving notifications about these messages (does anyone know how to enable them?). Peak cancelled. As @msuchy explained, builders are distributed among users, so that a long queue for one user doesn’t hold all the resources. Anyway, I didn’t know about these “background” jobs (I think it should be better documented), so I’ll submit batches using the background flag from now on.

It would be great, though, if this wasn’t necessary. When the pending queue for a particular repo grows above some limit, builds could be automatically marked as background. The limit could depend on the number of builders available and the number of users submitting builds. Just an idea.

@sbonazzo: I was told that this was a fair use case when I started the project. I think that Copr should be able to deal with such projects (and the command line tools and APIs provided should be adequate to such projects; currently, they are not). At the very least, this project has served to identify some bugs and RFEs.

So is it really needed to rebuild all CRAN repository? I believe it is. CRAN provides binaries for Windows and MacOS, but not for Linux. This is why Debian/Ubuntu has had for years a similar initiative to maintain a non-official repo for most of CRAN. Fedora has only a few hundred R packages in the official repositories, and maintaining them is already a huge task. So this Copr repo is meant to fill this gap.

(Ok, I’ve seen the “watching” button; thanks, @msuchy)

I’m unable to submit background jobs. I’m using the “–background” flag as follows:

copr-cli build-package --nowait --background cran --name pkgname

and still they are being added to the regular queue. Is this a bug?

Thanks for explanation behind the building of CRAN binaries here. Seems a good enough motivation.
Also thanks for trying to use the background queue :slight_smile:

It’s working now, but using build from the SPEC. build-package has the option, but it’s not used. I’ll file a bug in Pagure.

@iucar Thanks for switching to low priority builds! I’ve done the same for my batch jobs now :slight_smile:

Also, judging by that I haven’t even noticed your 14k pending builds today, I’d say that submitting batch builds with lower priority definitely improves responsiveness for other users.