On Mon, 27 Jul 2020 at 09:09, Elliott Sales de Andrade
wrote:
>
> On Tue, 21 Jul 2020 at 11:05, José Abílio Matos wrote:
> >
> > 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?
>
On Tue, 21 Jul 2020 at 11:05, José Abílio Matos wrote:
>
> 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
On Tue, 21 Jul 2020 at 17:05, José Abílio Matos wrote:
>
> 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
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 Tue, 14 Jul 2020 at 18:24, José Abílio Matos wrote:
>
> 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
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 Tue, 14 Jul 2020 at 01:19, José Abílio Matos wrote:
>
> 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
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 Tue, 7 Jul 2020 at 16:15, Iñaki Ucar wrote:
>
> On Tue, 7 Jul 2020 at 15:58, José Abílio Matos wrote:
> >
> > 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
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 Tue, 7 Jul 2020 at 09:58, José Abílio Matos wrote:
>
> 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
On Tue, 7 Jul 2020 at 15:58, José Abílio Matos wrote:
>
> 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
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 Tue, 7 Jul 2020 at 12:38, José Abílio Matos wrote:
>
> 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
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
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
On Mon, Jul 6, 2020 at 10:40 AM José Abílio Matos wrote:
> On Tuesday, 9 June 2020 03.40.52 WEST Tom Callaway wrote:
> > Over the last several
On Mon, 6 Jul 2020 at 16:40, José Abílio Matos wrote:
>
> 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
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 Fri, 3 Jul 2020 at 13:03, José Abílio Matos wrote:
>
> On Monday, 29 June 2020 13.46.02 WEST Iñaki Ucar wrote:
> > 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
On Fri, 3 Jul 2020 at 19:03, José Abílio Matos wrote:
>
> On Monday, 29 June 2020 13.46.02 WEST Iñaki Ucar wrote:
> > 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
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 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
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 Fri, 26 Jun 2020 at 12:09, José Abílio Matos wrote:
>
> 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
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
Hi José,
On Thu, 25 Jun 2020 at 20:05, José Abílio Matos wrote:
>
> 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
On Fri, 26 Jun 2020 at 11:36, José Abílio Matos wrote:
>
> 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
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 Thu, 25 Jun 2020 at 19:01, José Abílio Matos 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
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
This work is already complete in rawhide.
Tom
On Thu, Jun 25, 2020, 1:12 PM José Abílio Matos wrote:
> 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
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 Wed, 24 Jun 2020 at 05:42, Iñaki Ucar wrote:
>
> Thanks, José and Elliott. I can help with reviews.
>
Thanks. I have a few open already:
- https://bugzilla.redhat.com/show_bug.cgi?id=1839451 - R-servr
- https://bugzilla.redhat.com/show_bug.cgi?id=1839456 - R-filelock
-
Oh, and maybe in this process we could add to all packages the
requirement on R(ABI) = 4 that Tom implemented.
On Wed, 24 Jun 2020 at 11:42, 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
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 Wed, 24 Jun 2020 at 11:35, Elliott Sales de Andrade
wrote:
>
> I could do
I could do so, but it wouldn't be until this weekend.
Also, Tom mixed in some version bumps to the rebuild, so we'd have to
check whether those would actually be okay in a released version. I
would also appreciate some review on new (mostly test) dependencies
for these bumps.
On Tue, 23 Jun 2020
There are a few of those, but not many.
On Tue, Jun 23, 2020 at 11:31 AM José Abílio Matos wrote:
> 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
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 Tue, 23 Jun 2020 at 17:01, José Abílio Matos wrote:
>
> 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
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
Maybe Elliott?
On Tue, 23 Jun 2020 at 15:01, Tom Callaway wrote:
>
> At this point, I simply don't have the time.
>
> Tom
>
> On Tue, Jun 23, 2020, 6:06 AM Iñaki Ucar wrote:
>>
>> On Tue, 9 Jun 2020 at 10:21, Iñaki Ucar wrote:
>> >
>> > > Given the huge amount of builds (and rebuilds) in this
At this point, I simply don't have the time.
Tom
On Tue, Jun 23, 2020, 6:06 AM Iñaki Ucar wrote:
> On Tue, 9 Jun 2020 at 10:21, Iñaki Ucar wrote:
> >
> > > Given the huge amount of builds (and rebuilds) in this process, I am
> > > strongly disinclined to attempt this work for Fedora 32 (the
On Tue, 9 Jun 2020 at 10:21, Iñaki Ucar wrote:
>
> > Given the huge amount of builds (and rebuilds) in this process, I am
> > strongly disinclined to attempt this work for Fedora 32 (the idea of
> > hundreds of bodhi overrides does not fill me with joy), but I would not
> > prevent someone else
On Tue, 9 Jun 2020 at 04:42, 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
On Sat, 16 May 2020 at 10:26, José Abílio Matos wrote:
>
> 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
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 Sat, 16 May 2020 at 00:49, José Abílio Matos wrote:
>
> 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
>
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 Fri, 15 May 2020 at 11:58, José Abílio Matos wrote:
>
> 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
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 Tue, 12 May 2020 at 12:13, Tom Callaway wrote:
>
> Okay, I'm convinced.
>
> https://github.com/rpm-software-management/R-rpm-macros/pull/1
>
I merged the PR and pushed it to dist-git as well. I have not built
anything though, since as I mentioned in the PR, I think builds should
be done in a
On Fri, 15 May 2020 at 00:23, José Abílio Matos wrote:
>
> 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
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 Thu, 14 May 2020 at 21:41, José Abílio Matos wrote:
>
> 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
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
Okay, I'm convinced.
https://github.com/rpm-software-management/R-rpm-macros/pull/1
Thanks,
Tom
On Mon, May 11, 2020 at 11:48 AM Iñaki Ucar wrote:
> On Mon, 11 May 2020 at 16:29, Tom Callaway wrote:
> >
> > Hmmm. That seems like a rather heavy dependency, given that I think we've
> > only
On Mon, 11 May 2020 at 16:29, Tom Callaway wrote:
>
> Hmmm. That seems like a rather heavy dependency, given that I think we've
> only been forced to do rebuilds for everything as a result of 4.0.0 and
> 3.4.0.
That's just coincidence, because if you browse old NEWS, you can see
"packages [doing
Hmmm. That seems like a rather heavy dependency, given that I think we've
only been forced to do rebuilds for everything as a result of 4.0.0 and
3.4.0.
Does anyone know if upstream has any sort of commitment to ABI here that we
could depend on (e.g. only breaking on major versions, never minor)
On Sat, 9 May 2020 at 05:46, Tom Callaway wrote:
>
> Thinking out loud here... do we want to have some macro magic to embed a
> dependency on an R(ABI) provides? Where R 4.0.0 would provide R(ABI) = 4
> and all R packages built against it would pick up Requires: R(ABI) = 4 ?
Note that
Thinking out loud here... do we want to have some macro magic to embed a
dependency on an R(ABI) provides? Where R 4.0.0 would provide R(ABI) = 4
and all R packages built against it would pick up Requires: R(ABI) = 4 ?
I don't suppose we need it, since the likelihood of someone installing R
module
On Mon, 4 May 2020 at 19:15, Tom Callaway wrote:
>
> Hi folks,
>
> As expected of a new major release of R, there is a break in compatibility
> for R packages. From the NEWS entry for 4.0.0:
>
>Packages need to be (re-)installed under this version (4.0.0) of R.
>
> This has two impacts on
68 matches
Mail list logo
