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 Mon, 29 Jun 2020 at 14:25, José Abílio Matos wrote: > > 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. But the mass rebuild process is very different, because releng doesn't follow any particular order (they don't need to, because nothing really changed). The question is whether there is any tool to resolve dependencies and generate a list of builds, as I do with the CRAN database, for an arbitrary list of RPMs. That would be perfect. In theory, this should be possible with dnf, but when I tried, I failed (or my script would theoretically work, but it would take ages to complete). I also took a look at releng's repos on Pagure, but I didn't find any tool to do this either. We should bring this to devel, maybe ask Miro and other Python folks who may have The Method(TM), as they are rebuilding stuff on a daily basis. -- Iñaki Úcar ___ 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] -specs=/usr/lib/rpm/redhat/redhat-hardened-ld woes
On Mon, 29 Jun 2020, Iñaki Ucar wrote:
On Mon, 29 Jun 2020 at 11:24, Iñaki Ucar wrote:
On Mon, 29 Jun 2020 at 10:21, Roger Bivand wrote:
In the rgdal package, configure.ac has had : ${LDFLAGS=`"${RBIN}" CMD
config LDFLAGS`} at least since 2012, so picking up LDFLAGS known to the R
version installed. Very recently, users installing rgdal from source with
R installed from RPM are seeing problems, such as those reported in this
thread: https://stat.ethz.ch/pipermail/r-sig-geo/2020-June/028251.html
The diagnosis by Bennet Fauber, that
LDFLAGS='-specs=/usr/lib/rpm/redhat/redhat-hardened-ld'
is the problem, that LDFLAGS='-Wl,-z,relro -Wl,--as-needed -Wl,-z,now'
works OK, and that the -specs= conflict with autoconf has not been
resolved seems accurate to me (see also
https://developers.redhat.com/blog/2018/03/21/compiler-and-linker-flags-gcc/,
https://bugzilla.redhat.com/show_bug.cgi?id=1343892).
I realise that the R RPM needs to follow RH/F standards, but has something
happened in the RPM ecosystem recently to poison the -spec/autoconf
relationship?
Did something change in rgdal's flags from 1.5-10 to 1.5-12? Because
the former installs fine. You can see in [1] that it fails since the
last update.
I see that rgdal changed to C++ recently. The issue is in rgdal,
because the configure script is missing:
CXXFLAGS=`"${R_HOME}/bin/R" CMD config CXXFLAGS`
as indicated in Writing R Extensions (note that CPPFLAGS are *not*
CXXFLAGS; I say this because it's a common mistake).
Thanks, added R-forge revision 1021. The problem was caused by the
addition of AC_LANG(C++) (about line 500, 11 June) in connection with
preparations for macOS static builds; without AC_LANG(C++) Fedora runs
configure OK. With AC_LANG(C++), Fedora needs CXXFLAGS set if using the R
rpm (otherwise and other systems not). CPPFLAGS were used for the C
pre-processor.
Roger
--
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; e-mail: roger.biv...@nhh.no
https://orcid.org/-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0J=en___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
Re: [R-sig-Fedora] -specs=/usr/lib/rpm/redhat/redhat-hardened-ld woes
On Mon, 29 Jun 2020 at 11:24, Iñaki Ucar wrote:
>
> On Mon, 29 Jun 2020 at 10:21, Roger Bivand wrote:
> >
> > In the rgdal package, configure.ac has had : ${LDFLAGS=`"${RBIN}" CMD
> > config LDFLAGS`} at least since 2012, so picking up LDFLAGS known to the R
> > version installed. Very recently, users installing rgdal from source with
> > R installed from RPM are seeing problems, such as those reported in this
> > thread: https://stat.ethz.ch/pipermail/r-sig-geo/2020-June/028251.html
> >
> > The diagnosis by Bennet Fauber, that
> >
> > LDFLAGS='-specs=/usr/lib/rpm/redhat/redhat-hardened-ld'
> >
> > is the problem, that LDFLAGS='-Wl,-z,relro -Wl,--as-needed -Wl,-z,now'
> > works OK, and that the -specs= conflict with autoconf has not been
> > resolved seems accurate to me (see also
> > https://developers.redhat.com/blog/2018/03/21/compiler-and-linker-flags-gcc/,
> > https://bugzilla.redhat.com/show_bug.cgi?id=1343892).
> >
> > I realise that the R RPM needs to follow RH/F standards, but has something
> > happened in the RPM ecosystem recently to poison the -spec/autoconf
> > relationship?
>
> Did something change in rgdal's flags from 1.5-10 to 1.5-12? Because
> the former installs fine. You can see in [1] that it fails since the
> last update.
I see that rgdal changed to C++ recently. The issue is in rgdal,
because the configure script is missing:
CXXFLAGS=`"${R_HOME}/bin/R" CMD config CXXFLAGS`
as indicated in Writing R Extensions (note that CPPFLAGS are *not*
CXXFLAGS; I say this because it's a common mistake).
--
Iñaki Úcar
___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
Re: [R-sig-Fedora] -specs=/usr/lib/rpm/redhat/redhat-hardened-ld woes
On Mon, 29 Jun 2020 at 10:21, Roger Bivand wrote:
>
> In the rgdal package, configure.ac has had : ${LDFLAGS=`"${RBIN}" CMD
> config LDFLAGS`} at least since 2012, so picking up LDFLAGS known to the R
> version installed. Very recently, users installing rgdal from source with
> R installed from RPM are seeing problems, such as those reported in this
> thread: https://stat.ethz.ch/pipermail/r-sig-geo/2020-June/028251.html
>
> The diagnosis by Bennet Fauber, that
>
> LDFLAGS='-specs=/usr/lib/rpm/redhat/redhat-hardened-ld'
>
> is the problem, that LDFLAGS='-Wl,-z,relro -Wl,--as-needed -Wl,-z,now'
> works OK, and that the -specs= conflict with autoconf has not been
> resolved seems accurate to me (see also
> https://developers.redhat.com/blog/2018/03/21/compiler-and-linker-flags-gcc/,
> https://bugzilla.redhat.com/show_bug.cgi?id=1343892).
>
> I realise that the R RPM needs to follow RH/F standards, but has something
> happened in the RPM ecosystem recently to poison the -spec/autoconf
> relationship?
Did something change in rgdal's flags from 1.5-10 to 1.5-12? Because
the former installs fine. You can see in [1] that it fails since the
last update.
[1] https://copr.fedorainfracloud.org/coprs/iucar/cran/package/R-CRAN-rgdal/
--
Iñaki Úcar
___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
