On Monday, 29 June 2020 12.35.35 WEST I�aki Ucar wrote:
> Yeah, sorry, that's a kind of bug in my script. I'm using CRAN names,
> and I forgot that some RPM packages change those names due to the dot
> to adhere to the guidelines. So TH-data is mistakenly dropped.

Thank you for feedback.
I am trying to make this process as automatic as possible.

> > I noticed it because multcomp depends on it and the compilation failed
> > because R-TH-data was not yet ported.
> > 
> > This questions is mainly directed to you, to Elliot and Tom, should we add
> > to the rpm- macros something that puts Provides(R-rname) or since the
> > naming is more or less the same we can add manually this for packages for
> > which the R-rname and the Fedora package diverge...
> > 
> > 
> > So in this case we would add, either directly or automatically,
> > 
> > Provides(R-TH.data)
> > 
> > What do you think?
> 
> Now, we have
> 
> $ sudo dnf repoquery --provides R-TH-data
> R(TH.data) = 1.0-10
> R-TH-data = 1.0.10-4.fc3
> 
> which is what you are looking for I guess?

You guessed right. :-)
Apologies for not verifying this before but while controlling the build 
processes my 
attention span becomes that of a toddler. :-)

I do not know if the process will succeed or not.
The extreme example was R-pbdZMQ that took more than a day building.

The issue was with the testing stage in s390x where a test with ports were 
stuck. I guess 
that there was a long timeout.


> I should be using that instead of the RPM package names.

Again you guessed right, that was the main idea. :-)
As I told above and to reiterate it, the idea of this work is to make it easier 
to automate the 
process. Similarly to how we do the mass builds for all the packages.

BTW your idea to separate the builds in batches is a very useful idea. The 
reason is that it 
takes some time for the builds to be added to the repository associated with 
the side tag. I 
had already three cases where the build failed because the new build of a 
dependent 
package was not yet in the repository and so the resolver took an older build 
(made with 
R-3.6).

Best regards,
-- 
Jos� Ab�lio

        [[alternative HTML version deleted]]

_______________________________________________
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora

Reply via email to