On Mon, 29 Jun 2020 at 13:19, Jos? Ab?lio Matos <jamatos at fc.up.pt> wrote:> > 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 > > Hi I?aki, > I noticed that you do not have TH.data, that in Fedora corresponds to R-TH-data in your > results.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.> 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? I should be using that instead of the RPM package names. -- I?aki ?car
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]]
On Mon, 29 Jun 2020 at 14:25, Jos? Ab?lio Matos <jamatos at fc.up.pt> 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