Hi all,
what should be our plan for R 4.1 update in Fedora?
What are the pitfalls and the changes that we should be aware?
The second semester (with the corresponding induced pandemic chaos) is
dimming down around here so I have at least time to breath again. :-)
FWIW I am in no hurry
Hi,
due to an unrelated bug report in maxima I found out that some packages
install latex packages in /usr/share/texmf/tex/latex. Instead of using the
prefix %{_datadir}/texmf we can use the canonical %_texmf defined by texlive.
Is there any objection to change the location to the canonical
I tried R2spec to create the spec files necessary to have Rcpparmadillo.
I noticed that it has some issues, one example is that it placed some files
irrespectively if they were present in the tar or not.
One functionality that I think it would be nice to have would to update a
given spec file
On Tuesday, 21 July 2020 16.43.31 WEST Tom Callaway wrote:
> I'm inclined to agree. Users are expecting that things they install
> manually will override the system default (if any).
>
> Tom
FWIW I agree with both of you.
OTOH someone who never did that kind of error please raise your hand. :-)
There was a thread this weekend in the fedora users' mailing list where a user
had problems updating R 4.0.2:
"non-rpm R libraries not accessible now w R v 4.0.x"
https://lists.fedoraproject.org/archives/list/us...@lists.fedoraproject.org/
thread/2FFST3GWZCNM45SX53VKB255TO4LOV4C/
TLDR; as far
On Friday, 3 July 2020 18.36.17 WEST Iñaki Ucar wrote:
> Nice! What if we create a group "R" on Pagure and a repo
> "fedora-scripts" or something like that?
I would like to improve the scripts but FWIW here it comes a rough version of
the script I used.
The python script loads the csv file and
On Tuesday, 14 July 2020 09.47.55 WEST Iñaki Ucar wrote:
> Maybe it's due to the size of the update? File an issue here:
> https://github.com/fedora-infra/bodhi/issues
Before resorting to this I tried again and this time it worked.
Elliot before had already tried, I got an email message saying:
On Saturday, 11 July 2020 11.32.32 WEST Jos� Ab�lio Matos wrote:
> If I do not hear until then I will push the update Monday night (Western
> Europe time zone.
Well I tried but I did not succeeded both using the web interface and cli
interfaces:
b"504 Gateway Time-out\nThe server didn't
On Thursday, 9 July 2020 21.25.05 WEST Iñaki Ucar wrote:
> CRAN rebuilt on Copr. Ready to push to stable.
The update also has the karma necessary to be pushed to stable.
Does any one has any objection for this to be pushed to stable?
If I do not hear until then I will push the update Monday
On Thursday, 9 July 2020 08.41.39 WEST Elliott Sales de Andrade wrote:
> Note, if the side tag was turned into an update, you need to tag new
> builds into f32-updates-candidate first. I've done that for:
> * R-biomaRt-2.44.0-1.fc32
> * R-BiocFileCache-1.12.0-2.fc32
> * rpy-3.3.5-1.fc32
Thank you
On Tuesday, 7 July 2020 14.11.02 WEST Tom Callaway wrote:
> Nice work.
>
> Tom
I agree. :-)
--
José Abílio
___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
On Tuesday, 7 July 2020 11.44.48 WEST Iñaki Ucar wrote:
> Try with the CLI (see "man bodhi"):
>
> $ bodhi updates edit --addbuilds
I found that the best call in this case is instead of --addbuilds to use
--from-tag since then "this will update the builds to the latest ones in the
tag."
>
On Monday, 6 July 2020 21.08.53 WEST Tom Callaway wrote:
> R-BiocFileCache is now branched for f32 (finally). You should be able to
> build it if/when the PDC comes back up. Lotta random outages right now.
>
> Tom
I have re/built them using the side tag but I do not see how to add them to the
On Tuesday, 9 June 2020 03.40.52 WEST Tom Callaway wrote:
> Over the last several days, I've been working hard to get all of the Fedora
> R packages rebuilt against R 4.0 in rawhide (in the F33-R-4 side tag). With
> the exception of R-biomaRt, R-BSgenome, R-GenomicAlignments, and
> R-rtracklayer,
[Apologies if this message is a dupe but I do not find evidence of the other
message I wrote]
On Friday, 3 July 2020 23.06.43 WEST Elliott Sales de Andrade wrote:
> Your process must have an error, because R-rpm-macros only Requires
> R-core. It also BuildRequires nothing.
You are right.
This
On Friday, 26 June 2020 10.52.44 WEST Elliott Sales de Andrade wrote:
> glue1.4.1 1.3.2 - requires new vctrs; do not bump
This process takes time but I think that I am on the right track (to the abyss
?). :-)
I am now rebuilding packages that need bootstrap and/or from
On Friday, 26 June 2020 10.52.44 WEST Elliott Sales de Andrade wrote:
> Feel free to double-check these.
>
> Also, let me know if you need to stop building and I can do so.
The first round is ready. I built all the cran packages using Iñaki's order.
For the remainder those that failed I will
On Friday, 26 June 2020 12.36.07 WEST Iñaki Ucar wrote:
> It's erroring on CRAN too:
> https://cran.r-project.org/web/checks/check_results_data.table.html
The only other package affected by this failure is R-nanotime.
--
José Abílio
___
R-SIG-Fedora
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
On Friday, 26 June 2020 10.47.13 WEST Iñaki Ucar wrote:
> I used bcond locally and wrongly assumed that fedpkg build would
> support --with BCOND and --without BCOND. Instead, the way to activate
> it is to change to "%bcond_with check" and then revert to
> "%bcond_without check". The only
On Tuesday, 23 June 2020 16.48.53 WEST Tom Callaway wrote:
> There are a few of those, but not many.
Hi Tom,
I noticed that for example in R-assertthat you have used the bcond:
%bcond_with check
would not it be better to use bootstrap instead to take advantage of:
On Thursday, 25 June 2020 18.26.20 WEST Tom Callaway wrote:
> This work is already complete in rawhide.
>
> Tom
BTW I suspect that now we can simplify the requires generator.
As an example we have:
$ rpm -qp --requires R-AUC-0.3.0-8.fc32.noarch.rpm
R(ABI) = 4.0
R-core
On Friday, 26 June 2020 00.45.46 WEST Elliott Sales de Andrade wrote:
> Thanks for starting off builds. However, please be careful merging to
> master, as some packages were bumped and have incompatibilities that
> should not be put in stable releases. I will try to come up with an
> exact list
On Wednesday, 24 June 2020 10.42.10 WEST Iñaki Ucar wrote:
> Thanks, José and Elliott. I can help with reviews.
>
> I attach here a list of batches of CRAN packages to be rebuilt in
> order (batches separated by a blank line), and the script that
> generates it. Hope it helps.
>
> Iñaki
On Thursday, 25 June 2020 18.26.20 WEST Tom Callaway wrote:
> This work is already complete in rawhide.
>
> Tom
OK.
Building R-rpm-macros now and then untag and rebuild the modules already done.
After all this is an iterative procedure. :-(
Thank you for the remark. :-)
--
José Abílio
On Wednesday, 24 June 2020 10.44.14 WEST Iñaki Ucar wrote:
> Oh, and maybe in this process we could add to all packages the
> requirement on R(ABI) = 4 that Tom implemented.
For that we need to start with rawhide and then change the R-rpm-macros
package.
Probably it should be enough to change
On Wednesday, 24 June 2020 10.42.10 WEST Iñaki Ucar wrote:
> Thanks, José and Elliott. I can help with reviews.
>
> I attach here a list of batches of CRAN packages to be rebuilt in
> order (batches separated by a blank line), and the script that
> generates it. Hope it helps.
>
> Iñaki
Sure it
On Tuesday, 23 June 2020 16.10.07 WEST I�aki Ucar wrote:
> 3) For all packages, either merge master into F32 or just increase the
> release version and send builds to that side tag *in order*.
The part that worries me is the *in order*. :-)
Do we need to do bootstrap builds that are later
On Tuesday, 23 June 2020 14.01.39 WEST Tom Callaway wrote:
> At this point, I simply don't have the time.
>
> Tom
What needs to be done and how can the work be streamlined?
I asked this since this procedure will happen for other updates (in one year I
know but time flies).
I am a
On Saturday, 16 May 2020 00.38.34 WEST Iñaki Ucar wrote:
> Sorry, but I'm not sure I'm following you. How does having
> /usr/lib64/R/library as system library prevent you from testing
> r-devel?
First the context, we are speaking of srpms.
Use case: you want to test a pre-version of R before it
On Friday, 15 May 2020 11.33.26 WEST Iñaki Ucar wrote:
> The rationale behind the user settings is that the user dir is not
> controlled by the system, so versioning it is the only way to avoid
> breakage. For the system library, there are better tools to prevent
> that.
Do you know the
On Thursday, 14 May 2020 23.58.02 WEST Iñaki Ucar wrote:
> But we still have to rebuild the packages anyway, and this setup
> doesn't force us to actually rebuild them, nor the user to update
> them. So a user could end up with R major.minor and a bunch of
> packages installed in some
On Thursday, 14 May 2020 21.30.13 WEST Iñaki Ucar wrote:
> Mmmh... but then you have to change that in the packages' SPEC and
> rebuild them anyway when you update R. So... what's the advantage of
> this?
We already have other examples of how to do this with less steps. :-)
Create macros like
On Monday, 11 May 2020 16.47.55 WEST Iñaki Ucar wrote:
> AFAIK, there's this commitment only for patch versions. In fact, the
> path for the personal library is:
>
> ~/R/x86_64-redhat-linux-gnu-library/./
>
> so, when you install a new minor version, you don't have any package
> in your personal
On Monday, 4 May 2020 14.14.05 WEST I�aki Ucar wrote:
> Hi all,
>
> Three months ago, I wrote to Martyn Plummer (to his Warwick email) and
> offered my help to maintain and modernize this [1] rather updated
> README, but received no response. Does anyone know how to reach him,
> or maybe I should
On Thursday, 4 July 2019 10.35.18 WEST Elliott Sales de Andrade wrote:
> FYI, I plan on implementing this for F31 if no issues arise.
Are there are any R packages, other than those built in R itself, that are not
affected by this change? :-)
Because I think that in this case the list of
On Thursday, 11 May 2017 17.37.41 WEST Martyn Plummer wrote:
> Dear Tom,
>
> I see that RPMS for R 3.4.0 are not successfully built on Fedora, nor
> on RHEL 7.
>
> https://koji.fedoraproject.org/koji/packageinfo?packageID=1230
>
> When I build with mock on Fedora 25 I also get a build failure.
37 matches
Mail list logo
