On Thu, Aug 8, 2019 at 9:12 AM Jeff Layton jlayton@poochiereds.net wrote:
On Wed, 2019-08-07 at 18:59 -0400, Alexander Bauer wrote:
Error: Package: lttng-ust-2.4.1-4.el7.x86_64 (epel) Requires: liburcu-cds.so.1()(64bit) Removing: userspace-rcu-0.7.16-1.el7.x86_64 (@epel) liburcu-cds.so.1()(64bit) Updated By: userspace-rcu-0.10.0-3.el7.x86_64
(centos-nfs-ganesha28)
~liburcu-cds.so.6()(64bit)
Error: Package: lttng-ust-2.4.1-4.el7.x86_64 (epel) Requires: liburcu-bp.so.1()(64bit) Removing: userspace-rcu-0.7.16-1.el7.x86_64 (@epel) liburcu-bp.so.1()(64bit) Updated By: userspace-rcu-0.10.0-3.el7.x86_64
(centos-nfs-ganesha28)
~liburcu-bp.so.6()(64bit)
You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest
Why is centos-nfs-ganesha28 repo providing its own userspace-rcu package? It seems like it ought to be picking that up from EPEL as well.
CentOS Storage SIG packages aren't built with EPEL packages, nor can they be. At least not at present AIUI. Thus I would claim, generally, that you should not mix CentOS SIG and EPEL on the same machine.
I believe there are plans afoot to more tightly integrate CentOS, EPEL, and Fedora, such that SIG packages would be able to use EPEL, but those haven't come to fruition yet, AFAIK. Maybe we will get a status update at the upcoming CentOS dojo in Boston in a couple of weeks.
I don't remember the timing of ganesha using userspace-rcu, but even Gluster has been shipping its own userspace-rcu. The ganesha-2.7 builds under gluster in the Storage SIG would have used it, if it was even using it all at.
If there is a need for it then it should probably provide lttng packages as well, as they typically require a certain version of urcu.
Centos, or more accurately, the Ceph builds in the Storage SIG, provide the lttng-ust packages that were (apparently) used to build ganesha. I say apparently because I don't see where else they could have come from. Looks like I need to tag those into the ganesha-28 repos.
--
Kaleb
On Thu, Aug 8, 2019 at 9:38 AM Kaleb Keithley kkeithle@redhat.com wrote:
If there is a need for it then it should probably provide lttng packages as well, as they typically require a certain version of urcu.
Centos, or more accurately, the Ceph builds in the Storage SIG, provide the lttng-ust packages that were (apparently) used to build ganesha. I say apparently because I don't see where else they could have come from. Looks like I need to tag those into the ganesha-28 repos.
Answering my own question, I just checked the BuildTarget for ganesha-2.8 does inherit from Ceph. But I think this makes a case that lttng-ust should now probably be a storage7-common-* thing instead of Ceph.
I have tagged the lttng-ust packages into the ganesha-2.8 repos. It will take a couple of days for the repos to update+sync.
--
Kaleb
On 8/8/19 4:01 PM, Kaleb Keithley wrote:
On Thu, Aug 8, 2019 at 9:38 AM Kaleb Keithley <kkeithle@redhat.com mailto:kkeithle@redhat.com> wrote:
If there is a need for it then it should probably provide lttng packages as well, as they typically require a certain version of urcu. Centos, or more accurately, the Ceph builds in the Storage SIG, provide the lttng-ust packages that were (apparently) used to build ganesha. I say apparently because I don't see where else they could have come from. Looks like I need to tag those into the ganesha-28 repos.
Answering my own question, I just checked the BuildTarget for ganesha-2.8 does inherit from Ceph. But I think this makes a case that lttng-ust should now probably be a storage7-common-* thing instead of Ceph.
sounds good to me and in that case we might untag it from the ceph repos
adding Ken on CC for him to review and ack/nack
On Thu, Aug 08, 2019 at 09:38:10AM -0400, Kaleb Keithley wrote:
On Thu, Aug 8, 2019 at 9:12 AM Jeff Layton jlayton@poochiereds.net wrote:
On Wed, 2019-08-07 at 18:59 -0400, Alexander Bauer wrote:
Error: Package: lttng-ust-2.4.1-4.el7.x86_64 (epel) Requires: liburcu-cds.so.1()(64bit) Removing: userspace-rcu-0.7.16-1.el7.x86_64 (@epel) liburcu-cds.so.1()(64bit) Updated By: userspace-rcu-0.10.0-3.el7.x86_64
(centos-nfs-ganesha28)
~liburcu-cds.so.6()(64bit)
Error: Package: lttng-ust-2.4.1-4.el7.x86_64 (epel) Requires: liburcu-bp.so.1()(64bit) Removing: userspace-rcu-0.7.16-1.el7.x86_64 (@epel) liburcu-bp.so.1()(64bit) Updated By: userspace-rcu-0.10.0-3.el7.x86_64
(centos-nfs-ganesha28)
~liburcu-bp.so.6()(64bit)
You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest
Why is centos-nfs-ganesha28 repo providing its own userspace-rcu package? It seems like it ought to be picking that up from EPEL as well.
CentOS Storage SIG packages aren't built with EPEL packages, nor can they be. At least not at present AIUI. Thus I would claim, generally, that you should not mix CentOS SIG and EPEL on the same machine.
I believe there are plans afoot to more tightly integrate CentOS, EPEL, and Fedora, such that SIG packages would be able to use EPEL, but those haven't come to fruition yet, AFAIK. Maybe we will get a status update at the upcoming CentOS dojo in Boston in a couple of weeks.
I don't remember the timing of ganesha using userspace-rcu, but even Gluster has been shipping its own userspace-rcu. The ganesha-2.7 builds under gluster in the Storage SIG would have used it, if it was even using it all at.
If there is a need for it then it should probably provide lttng packages as well, as they typically require a certain version of urcu.
Centos, or more accurately, the Ceph builds in the Storage SIG, provide the lttng-ust packages that were (apparently) used to build ganesha. I say apparently because I don't see where else they could have come from. Looks like I need to tag those into the ganesha-28 repos.
Similar problems have been reported before. Unfortunately it seems that userspace-rcu in EPEL is not really maintained anymore. If EPEL carries a compatible version, this problem would not happen :-/
See https://bugzilla.redhat.com/1410302 for reference (recent versions add support for ppc64le which is available for CentOS, not EPEL?).
HTH, Niels