[R-sig-Fedora] Plans for R 4.1 in Fedora?
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 to have 4.1 in Fedora 34, my main interest is to have it in rawhide and later if we find it suitable to backport it to F34. FWIW since our last talk Octave (for version 7 at least) is starting by default to have the major version in the path for packages. :-) 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
[R-sig-Fedora] Normalize latex path
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 location?
Actually if you look into the spec file we are using a symbolic link. As far
as I can see the change is harmless.
Probably the %postun and %posttrans sections can be simplified.
Best regards,
--
José Abílio
___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
[R-sig-Fedora] R2spec woes
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 with the updated dependencies. What do you think of this? 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
Re: [R-sig-Fedora] Problem with the update to R 4.0.2 in the Fedora users' list
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. :-)
Does anyone knows if there is some kind of packages repository lint that could
catch this type of problems.
Those were the main points of this message.
What comes next it is just me thinking aloud since I am not proposing any,
immediate or medium term, change this are just what I have been thinking for a
long time.
One way to avoid this kind of errors would be to have the library directories
with R version like I suggested in May. Searching for this on the web I see
that users (mostly from windows and mac backgrounds) have some tips where the
directories that R version used to installed them is present in the name.
The recipes for upgrading were basically to take the names from installed
packages, save it into an external (csv) file and then with the new R version
to install those packages. In another context I do the same thing when I need
to install a new computer with Fedora and to have it working as soon as
possible:
in the previous computer
# rpm -qa --queryformat '%{name}\n' | sort | uniq > packages-list.txt
in the new computer
# dnf install $(cat packages-list.txt)
And voil� a new computer is ready will all the same packages as the previous
one.
I still think that this is a better naming scheme but looking briefly into the
installed packages I see that perl and ruby do not follow it.
End of thinking aloud...
--
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
[R-sig-Fedora] Problem with the update to R 4.0.2 in the Fedora users' list
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 as I can see the user had installed (as root) a package from cran and had installed the same package (R-here) from the Fedora repositories. Since the package were installed in different locations the package installed by the user appeared first and thus it won regarding the Fedora package. The only problem was that the other package was installed using R 3.6 and thus the user had the warning that seemed confusing. Are there any kind of tools to pick these cases or this is one of those corner cases that are not worth the trouble? Best regards, -- José Abílio ___ R-SIG-Fedora mailing list R-SIG-Fedora@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
Re: [R-sig-Fedora] R 4.0.0 rebuild status
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 constructs a directed graph and it
starts to remove the leave packages (pruning or trimming if you take a
gardening analogy).
The csv files has the dependency of the packages. It is always possible to go
to the packages that remain after the first stage and using a bootstrap mode
to remove most of the dependencies and then to run the code again.
This procedure was enough to process all the packages.
--
José Abílio# -*- coding: utf-8 -*-
"""
Process csv files removing several files outside of R modules:
R-devel
non R related packages
"""
# from pprint import pprint
import networkx as nx
RCORE = ['R', 'R-core', 'R-java', 'R-KernSmooth',
'R-MASS', 'R-Matrix', 'R-base', 'R-boot',
'R-class', 'R-cluster', 'R-codetools',
'R-compiler', 'R-datasets', 'R-foreign',
'R-grDevices', 'R-graphics', 'R-grid',
'R-lattice', 'R-methods', 'R-mgcv', 'R-nlme',
'R-nnet', 'R-parallel', 'R-rpart', 'R-spatial',
'R-splines', 'R-stats', 'R-stats4', 'R-survival',
'R-tcltk', 'R-tools', 'R-translations', 'R-utils',
'R-rpm-macros']
depnet = {};
DG = nx.DiGraph()
for line in open('r-packages-dependencies.csv'):
line = line[:-1];
fields = line.split(',');
package = fields[0];
DG.add_node(package)
pkgd = []
for pkg in fields[1:]:
if not pkg.startswith('R-'):
continue
pkg = pkg.split(' ')[0].replace('-devel', '')
if pkg in RCORE:
continue
pkgd.append(pkg)
DG.add_edge(package, pkg)
depnet[package]=pkgd
# pprint(depnet)
# Try to identify batches of builds
iter = 0
while True:
batch = [x for x in DG if len(DG[x]) == 0]
if len(batch) == 0: break
iter += 1
print(f'# round {iter}')
for x in sorted(batch):
print(x)
DG.remove_node(x)
if len(DG):
print("#Unresolved dependencies: {}".format(len(DG)))
print(list(DG))
print()
print("#Number of cycles {}".format(len(list(nx.simple_cycles(DG)
print("Cycles:")
print(list(nx.simple_cycles(DG)))R-AUC,R-devel,tex(latex)
R-AnnotationDbi,R-Biobase >= 1.17.0,R-BiocGenerics >= 0.29.2,R-DBI,R-IRanges-devel,R-RSQLite,R-S4Vectors-devel >= 0.9.25,R-devel >= 2.7.0,R-methods,R-stats4,R-utils,tetex-latex
R-AsioHeaders,R-devel,tex(latex)
R-BH,R-devel >= 3.0.0,tetex-latex
R-BSgenome,R-BiocGenerics >= 0.13.8,R-Biostrings-devel >= 2.47.6,R-GenomeInfoDb >= 1.23.9,R-GenomicRanges >= 1.31.10,R-IRanges-devel >= 2.13.16,R-Rsamtools,R-S4Vectors-devel >= 0.17.28,R-XVector-devel,R-devel >= 3.0.0,R-matrixStats,R-methods,R-rtracklayer >= 1.39.7,R-stats,R-utils,tex(latex)
R-Bessel,R-Rmpfr,R-devel,R-gsl,R-methods,R-sfsmisc,tex(latex)
R-Biobase,R-BiocGenerics >= 0.27.1,R-devel >= 3.4.0,R-methods,R-tkWidgets,R-utils,tex(latex)
R-BiocFileCache,R-DBI,R-RSQLite,R-curl,R-dbplyr >= 1.0.0,R-devel >= 3.4.0,R-dplyr,R-httr,R-knitr,R-methods,R-rappdirs,R-rmarkdown,R-rtracklayer,R-stats,R-testthat,R-utils,tetex-latex
R-BiocGenerics,R-devel >= 3.6.0,R-graphics,R-methods,R-parallel,R-stats,R-utils,tex(latex)
R-BiocParallel,R-BH-devel,R-devel >= 3.0.0,R-futile.logger,R-methods,R-parallel,R-snow,R-stats,R-utils,autoconf,automake,gcc,gcc-c++
R-Biostrings,R-Biobase,R-BiocGenerics >= 0.31.5,R-IRanges-devel >= 2.21.6,R-S4Vectors-devel >= 0.25.14,R-XVector-devel >= 0.27.2,R-crayon,R-devel >= 3.5.0,R-grDevices,R-graphics,R-methods,R-stats,R-utils,tex(latex)
R-BufferedMatrix,R-devel >= 3.4.0,R-methods,tex(latex)
R-Cairo,R-devel,R-grDevices,R-graphics,R-png,cairo-devel >= 1.2,libXt-devel,tex(latex)
R-DBI,R-devel >= 3.4.0,R-methods,texlive-latex
R-DelayedArray,R-BiocGenerics >= 0.31.5,R-BiocParallel,R-IRanges-devel >= 2.17.3,R-S4Vectors-devel >= 0.25.15,R-devel >= 3.4.0,R-matrixStats,R-methods,R-stats4,tetex-latex
R-DynDoc,R-devel >= 3.0.0,R-methods,R-utils,tex(latex)
R-FMStable,R-devel,tex(latex)
R-GenomeInfoDb,R-BiocGenerics >= 0.13.8,R-GenomeInfoDbData,R-IRanges-devel >= 2.13.12,R-RCurl,R-S4Vectors-devel >= 0.25.12,R-devel >= 3.1.0,R-methods,R-stats,R-stats4,R-utils
R-GenomeInfoDbData,R-devel >= 3.5.0,tetex-latex
R-GenomicAlignments,R-BiocGenerics >= 0.15.3,R-BiocParallel,R-Biostrings >= 2.47.6,R-GenomeInfoDb >= 1.13.1,R-GenomicRanges >= 1.37.2,R-IRanges-devel >= 2.15.12,R-Rsamtools-devel >= 1.31.2,R-S4Vectors-devel >= 0.23.19,R-SummarizedExperiment >= 1.9.13,R-devel >= 3.5.0,R-methods,R-stats,R-utils,tetex-latex
R-GenomicRanges,R >= 3.4.0,R-BiocGenerics >= 0.25.3,R-GenomeInfoDb >= 1.15.2,R-IRanges-devel >= 2.21.6,R-S4Vectors-devel >= 0.25.14,R-XVector-devel >= 0.27.2,R-devel,R-methods,R-stats,R-stats4,R-utils,tex(latex)
R-IRanges,R-BiocGenerics >= 0.25.3,R-RUnit,R-S4Vectors-devel >=
Re: [R-sig-Fedora] R 4.0.0 rebuild status
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: bodhi - 2020-07-14 04:47:02.353824 (karma: 0) This update has been submitted for stable by qulogic. Now I got another one saying: bodhi - 2020-07-14 16:11:38.021756 (karma: 0) This update has been submitted for stable by jamatos. Let us see if it works this time. :-) -- José Abílio ___ R-SIG-Fedora mailing list R-SIG-Fedora@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
Re: [R-sig-Fedora] R 4.0.0 rebuild status
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 respond in time.\n\n" -- 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
Re: [R-sig-Fedora] R 4.0.0 rebuild status
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 night (Western Europe time zone, and yes we are in the Summer and the days are larger) in time for the daily batch update. Regards, -- José Abílio ___ R-SIG-Fedora mailing list R-SIG-Fedora@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
Re: [R-sig-Fedora] R 4.0.0 rebuild status
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 Elliot. -- José Abílio ___ R-SIG-Fedora mailing list R-SIG-Fedora@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
Re: [R-sig-Fedora] R package RPMs for Fedora
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
Re: [R-sig-Fedora] R 4.0.0 rebuild status
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." > BTW, could we coordinate to merge this into stable when I finish > rebuilding stuff in Copr? Sure. I am in no rush to submit this to stable. :-) -- José Abílio ___ R-SIG-Fedora mailing list R-SIG-Fedora@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
Re: [R-sig-Fedora] R 4.0.0 rebuild status
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 (bodhi) update. I would like to add R-BiocFileCache and R-biomaRt to the update to finish the process. I see that Elliot added three new packages there (thank you) but when I edit the update I do not see any field to add new packages, or even to change the existing. -- 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
Re: [R-sig-Fedora] R 4.0.0 rebuild status
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, I believe everything is built and updated to the latest > versions. And of those packages, they're all ready to go when Fedora > infrastructure is working reliably again (the great datacenter migration > has started and I can no longer git push). I'll also push R 4.0.1 into the > tag when that's possible. In line with what we discussed here I have the updates for R 4.0.2 ready. The exception is R-BiocFileCache and in that line R-biomaRt. They have an asterisk in front of them because of that. The packages that were rebuilt are in the list attached, together with the respective build order. I pushed an update to updates-testing where I disabled the automatic push (both karma and time based). Report problems either here or on bodhi: https://bodhi.fedoraproject.org/updates/FEDORA-2020-4c0ce71810 Best regards, -- José Abílio # round 0 R R-rpm-macros rpy # round 1 R-AUC R-AsioHeaders R-BH R-BiocGenerics R-BufferedMatrix R-DBI R-DynDoc R-FMStable R-GenomeInfoDbData R-NISTunits R-R.methodsS3 R-R6 R-RColorBrewer R-RODBC R-Rcompression R-RhpcBLASctl R-Rhtslib R-Rsolid R-abind R-affyio R-argon2 R-ascii R-assertthat R-backports R-base64enc R-bit R-bitops R-brew R-car R-chron R-coda R-colorspace R-combinat R-crayon R-curl R-date R-dichromat R-digest R-disposables R-evaluate R-expm R-fansi R-fastmatch R-filehash R-fontBitstreamVera R-fontLiberation R-fortunes R-futile.options R-gamlss.dist R-gee R-generics R-ggplot2movies R-globals R-gmp R-gsl R-gss R-gtable R-gtools R-highlight R-import R-inline R-iterators R-jpeg R-labeling R-listenv R-lmodel2 R-mAr R-magrittr R-matrixStats R-measurements R-microbenchmark R-mime R-mlbench R-mnormt R-mvtnorm R-ncdf4 R-nws R-pbdRPC R-pbdZMQ R-pkgconfig R-png R-polyclip R-polynom R-praise R-preprocessCore R-prettyunits R-ps R-quadprog R-rematch R-remotes R-rlecuyer R-rstudioapi R-rsvg R-scatterplot3d R-sciplot R-sfsmisc R-snow R-sodium R-sourcetools R-sp R-stringi R-sys R-sysfonts R-tinytest R-tkrplot R-udunits2 R-unix R-uuid R-waveslim R-wavethresh R-wesanderson R-widgetTools R-withr R-xfun R-xmlparsedata R-xtable R-zoo # round 2 R-Cairo R-R.oo R-RCurl R-Rcpp R-Rmpfr R-S4Vectors R-V8 R-ape R-biglm R-bit64 R-caTools R-cli R-deldir R-foreach R-fts R-future R-getPass R-lmtest R-lokern R-maps R-markdown R-memoise R-msm R-poLCA R-processx R-rgdal R-rprojroot R-sandwich R-showtextdb R-statnet.common R-stringdist R-testit R-tikzDevice R-tkWidgets R-webp # round 3 R-Bessel R-Biobase R-R.utils R-RInside R-RM2 R-TH-data R-RcppCCTZ R-XML R-callr R-desc R-git2r R-here R-highr R-itertools R-mapproj R-multcomp R-orcutt R-qcc R-scales R-showtext R-plogr R-systemfit R-tinytex R-whisker # round 4 R-R.cache R-R.devices R-httr R-RUnit # round 5 R-IRanges R-R.rsp R-doParallel R-gdata R-timeDate R-yaml # round 6 R-GenomeInfoDb R-XVector R-timeSeries # round 7 R-Biostrings R-GenomicRanges R-glue (bootstrap) R-rprintf (bootstrap) R-rlang (bootstrap) # round 8 R-ellipsis R-pkgbuild # round 9 R-pkgload R-vctrs (bootstrap) # round 10 R-blob R-testthat # round 11 R-RSQLite R-acepack R-askpass R-bindr R-clisymbols R-cyclocomp R-errors R-farver R-fastmap R-htmltools R-igraph R-ini R-mockery R-munsell R-pingr R-plyr R-qtl R-rgeos R-simmer R-units R-utf8 R-xopen # round 12 R-AnnotationDbi R-bindrcpp R-debugme R-jsonlite R-openssl R-pillar R-prettycode R-qpdf R-quantities R-reshape R-sessioninfo R-tweenr R-xml2 # round 13 R-commonmark R-gh R-htmlwidgets R-pdftools R-rversions R-whoami # round 14 R-stringr # round 15 R-knitr R-reshape2 R-selectr # round 16 R-corpus R-data.table R-gplots R-hexbin R-littler R-lubridate R-rmarkdown # round 17 R-clipr R-diffobj R-formatR R-hms R-hunspell R-later R-lazyeval R-lifecycle R-nanotime R-packrat R-prettydoc R-purrr R-rcmdcheck R-systemfonts R-tufte R-viridisLite # round 18 R-gdtools R-lambda.r R-mockr R-progress R-promises R-repr R-rex R-roxygen2 R-spelling R-unitizer R-websocket R-zeallot # round 19 R-IRdisplay R-cliapp R-futile.logger R-httpuv R-jose R-jqr R-lintr R-rappdirs R-rvest R-svglite R-tibble # round 20 R-BiocParallel R-IRkernel R-cellranger R-fs R-readr R-rematch2 R-reticulate R-tidyselect R-webutils # round 21 R-DelayedArray R-Rsamtools R-dplyr (bootstrap) R-gargle R-parsedate R-readxl # round 22 R-SummarizedExperiment R-dtplyr R-foghorn R-ggplot2 R-gmailr R-nycflights13 R-rhub R-styler # round 23 R-GenomicAlignments R-dbplyr R-forcats R-gapminder R-qvalue R-shiny # round 24 R-haven R-miniUI R-reprex R-repurrrsive R-rsconnect R-rtracklayer # round 25 R-BSgenome R-BiocFileCache * R-pkgdown R-tidyr # round 26 R-biomaRt * R-broom R-usethis # round 27 R-devtools R-geepack R-modelr # round 28 R-profvis ___ R-SIG-Fedora
Re: [R-sig-Fedora] R 4.0.0 rebuild status
[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 caught a blind spot in my shell script. If there are no dependencies the script does not change line and thus R-rpm-macros and R-rprintf entries were merged. > R-devel depends on R-rpm-macros, and this is intended, in order to > pull in automated dependency generators. If anything else directly > requires R-rpm-macros, that is an error, and these are all in packages > I don't own. There are several Rccp related packages that require R-rpm-macros. Currently it is no-op so not a problem although it is unnecessary. Regards, -- José Abílio ___ R-SIG-Fedora mailing list R-SIG-Fedora@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
Re: [R-sig-Fedora] R 4.0.0 rebuild status
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 Bioconductor. An example of how this is done can be seen here: https://src.fedoraproject.org/rpms/R-glue/blob/master/f/R-glue.spec In this case the bootstrap mode is off to make it on it would be enough to change one from %bcond_with bootstrap to %bcond_without bootstrap And yes at first sight it looks like the it should be the other way around. The question is read it as _allow_ to build the file conditionally with/ without bootstrap. Since most of the packages do not need this I propose to only add this snippet where it is really needed and not everywhere as I have hinted initially. Or else the spec files becomes noisy unnecessarily. Regards, -- José Abílio ___ R-SIG-Fedora mailing list R-SIG-Fedora@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
Re: [R-sig-Fedora] R 4.0.0 rebuild status
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 implement the bootstrap in packages as described before. I intend to disable testing and building vignettes in bootstrap mode. After all the packages are rebuilt I will apply the same recipe but with the bootstrap mode disabled. Most of the version differences were minor and I have updated those package. The exceptions goes as you suggested to the dependences of vctrs. I pinned vctrs version in F32. The same should apply to all the dependences, I think that I made a mistake for some of the dependences that I will fix in the next stage, one example is haven were I have updated the spec to rawhide version. This mistake is harmless at this stage because those packages do not build since vectrs' version is unchanged. I will revert that in the next stage. Regards, -- José Abílio ___ R-SIG-Fedora mailing list R-SIG-Fedora@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
Re: [R-sig-Fedora] Error: rebuild R-data.table on F32 for R 4.0.2
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 mailing list R-SIG-Fedora@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
Re: [R-sig-Fedora] R 4.0.0 rebuild status
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
Re: [R-sig-Fedora] R 4.0.0 rebuild status
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 difference with bootstrap is that > "bootstrap" is recognized and a suffix ~bootstrap can be added > automatically to the resulting build. So the question is whether we > want that suffix or not. AFAIU the issue is that the bootstrap scheme does not requires to bump the release because with the suffix (~) is considered lower while changing from "%bcond_with check" to "%bcond_without check" requires to bump the release. The issue is that koji does not allow 2 builds with the same nvr. Since we should ensure the upgrade path that also requires to bump the release number in rawhide before applying it on f32 (in this particular case). -- José Abílio ___ R-SIG-Fedora mailing list R-SIG-Fedora@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
Re: [R-sig-Fedora] R 4.0.0 rebuild status
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: https://docs.fedoraproject.org/en-US/packaging-guidelines/#bootstrapping I am asking for curiosity since from now on we will need to do this dance once a year for the releases that we deem worth (I would expect that to be rawhide and the latest stable). Forgive me if the question does not make sense since I am still trying to make sense of this maze. :-) -- José Abílio ___ R-SIG-Fedora mailing list R-SIG-Fedora@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
Re: [R-sig-Fedora] R 4.0.0 rebuild status
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 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsZstd) <= 5.4.18-1 I guess that now R(ABI) and R-core are synonyms and thus we can remove the R- core requirement. Of course that this in minimal and mainly aesthetic. :-) -- José Abílio ___ R-SIG-Fedora mailing list R-SIG-Fedora@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
Re: [R-sig-Fedora] R 4.0.0 rebuild status
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 soon. I am doing the process manually to ensure that this does not happen. Basically my method is for a given package called appropriately pkg: cd R-pkg less R-pkg.spec # read file to ensure that it is safe to build it if it is safe then I run: $ fedpkg switch-branch f32 && git merge master && git push && fedpkg build -- target=f32-build-side-24797 && fedpkg switch-branch master; cd .. the idea, of course, is that if the merge fails then the case needs to be dealt manually. FWIW most of the credit goes to Tom (spot) since the heavy lifting was already done. :-) I will welcome your list as it becomes easier to find those cases. As I said before I am doing my best to avoid those cases. -- José Abílio ___ R-SIG-Fedora mailing list R-SIG-Fedora@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
Re: [R-sig-Fedora] R 4.0.0 rebuild status
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 R-acepack depends on R-testthat so I moved it the batch after R-testthat. :-) If I find a circular dependency I will need to do a bootstrap build. Fun lies ahead... :-) -- José Abílio ___ R-SIG-Fedora mailing list R-SIG-Fedora@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
Re: [R-sig-Fedora] R 4.0.0 rebuild status
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 ___ R-SIG-Fedora mailing list R-SIG-Fedora@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
Re: [R-sig-Fedora] R 4.0.0 rebuild status
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 the /usr/lib/rpm/R-deps.R script to add Requires: R(ABI)=4.0 I suggest to continue this as is and then implement that change in rawhide and bring it back to Fedora 32 as new updates are issued. What do you think? -- José Abílio ___ R-SIG-Fedora mailing list R-SIG-Fedora@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
Re: [R-sig-Fedora] R 4.0.0 rebuild status
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 does. I am doing the rebuild in side tag f32-build-side-24797. -- José Abílio ___ R-SIG-Fedora mailing list R-SIG-Fedora@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
Re: [R-sig-Fedora] R 4.0.0 rebuild status
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 replaced by the real builds? Because other than that it is business as usual. :-) -- 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
Re: [R-sig-Fedora] R 4.0.0 rebuild status
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 provenpackager so that I can drive the process. 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
Re: [R-sig-Fedora] R 4.0.0
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 is released and you want to do it using dnf while not having to de-install the current version, with all its libraries. Since the purpose is both to install and test both r-devel and the rpm packages the goal should be that the spec file should be as close as possible to the final spec file. What I am saying is that by experience it is easier to test and adapt a spec file if only a small number of conditionals are needed to use the current spec file. As far as I remember, from Miro's messages in fedora-devel, that is what is being done in the python packages. That is also what I have done for other packages, although not a language, like lyx. I hope that now it makes sense, -- José Abílio ___ R-SIG-Fedora mailing list R-SIG-Fedora@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
Re: [R-sig-Fedora] R 4.0.0
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 difference between theory and practice? :-) In theory they are equal but in practice... :-) > > > I mean, +1 to less boilerplate for packages, but changing the release > > > + the ABI specification is not a big deal and solves those issues. For > > > me, having a path with full version specification only makes sense if > > > there is more than one version installed at the same time, like > > > Python. > > > > That would also be a nice side effect. > > Are you suggesting that we should maintain several versions of R at > the same time? I don't think we want or should go down that path... No I am not suggesting that. :-) If we take the example from python where I have installed versions from python 3.4 to 3.9 (that is yet in alpha stage). # rpm -qf /usr/bin/python3.? python34-3.4.10-10.fc32.x86_64 python35-3.5.9-1.fc32.x86_64 python36-3.6.10-2.fc32.x86_64 python37-3.7.7-1.fc32.x86_64 python3-3.8.2-2.fc32.x86_64 python39-3.9.0~a6-1.fc32.x86_64 The only version where I have python packages installed is for 3.8 (since I am using Fedora 32 - as it can be seen above). That allows me to test the base version for python without having to compile every time and every where I want to use it. And although it was not my initial motivation but you probably saw the discussion today on R-devel (Rd) about people not testing the versions alpha, beta and rc from r-devel. A versioned system path would allow to test this more easily. -- José Abílio ___ R-SIG-Fedora mailing list R-SIG-Fedora@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
Re: [R-sig-Fedora] R 4.0.0
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 major.minor-1 path that are just junk. Or > the other way around: a bunch of packages updated under major.minor+1 > with a previous version of R. Honestly my point here was for consistency with the user settings. If you have per version directories for users why not to do the same for the system? > I mean, +1 to less boilerplate for packages, but changing the release > + the ABI specification is not a big deal and solves those issues. For > me, having a path with full version specification only makes sense if > there is more than one version installed at the same time, like > Python. That would also be a nice side effect. :-) -- José Abílio ___ R-SIG-Fedora mailing list R-SIG-Fedora@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
Re: [R-sig-Fedora] R 4.0.0
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
%{r_sitearch}
%{r_sitelib}
that expand with the R version being used and place them in R-rpm-macros and
change all the R srpms to use them. We can also contribute changes to srpm
generators like https://pagure.io/r2spec.
This is a one-time change.
Then when a new R version shows up it is enough to bump the release and
rebuild the package. With the added advantage that all the cobwebs and dust
are cleaned. :-)
Another advantage is that the boilerplate code required to create a srpm
package decreases. :-)
Regards,
--
José Abílio
___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
Re: [R-sig-Fedora] R 4.0.0
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 library. Most of the time, for many packages, it just
> works if you copy the old packages into the new folder, but many times
> things break and reinstallation is needed. And this may happen for
> compiled packages, but also for non-compiled ones (e.g.: "Packages
> defining S4 classes with the above S3/S4 classes as slots should be
> reinstalled", in R 3.3.0).
>
> So maybe we should streamline mass rebuild of R packages, and do it
> for all minor updates. The virtual provide you proposed will force us
> to do that, and will prevent breakages and complaints.
Something that I have been wondering for some time, previous to this thread,
is why is not this the default also for system installation and not just for
users installs.
With this I mean to have the system directories to be respectively:
%{__libdir}|%{__datadir}/R.
Is this due to inertia or are there other reasons. That would naturally solve
the need to rebuild for each minor release. The major point here is that would
apply not only to our packages but also for others installed using R itself.
Best regards,
--
José Abílio
___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
Re: [R-sig-Fedora] R package RPMs for Fedora
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 contact CRAN directly? > > [1] https://cran.r-project.org/bin/linux/redhat/README > > Regards, Hi I�aki, just tangentially related to this subject, what is the status of the copr that you have related with automatic build of R packages? 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
Re: [R-sig-Fedora] Fwd: Fedora 31 System-Wide change proposal: Automatic R runtime dependencies
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 affected packages would be all the packages with R subpackages. Or am I misunderstanding the details? BTW nice job. :-) Best regards, -- José Abílio ___ R-SIG-Fedora mailing list R-SIG-Fedora@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
Re: [R-sig-Fedora] R 3.4.0 RPMS
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. R is
> not able to establish the time zone inside the chroot and this triggers
> a regression tests which is new in R 3.4.0. Specifically, in file
> tests/reg-tests-1d.R this test fails:
>
> ## PR#17186 - Sys.timezone() on some Debian-derived platforms
> (S.t <- Sys.timezone())
> if(is.na(S.t) || !nzchar(S.t)) stop("could not get timezone")
> ## has been NA_character_ in Ubuntu 14.04.5 LTS
>
>
> The work-around is to set the environment variable TZ to any non-empty
> string before running make check, in the %check section of the SPEC
> file, e.g.
>
> TZ="Europe/Paris" make check
>
> best regards
> Martyn
Thank you Martyn. :-)
I am rebuilding R bumping the version since the previous version succeeded to
build on el6.
BTW Tom, it is probably time to get rid of the
%defattr(-, root, root, -)
after we are already in the Spring here in the North hemisphere. :-)
Regards,
--
José Abílio
___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
