Anabasis: - binutils gets updated to 2.29 - libqb gets mass rebuilt, which fails [bug 1478089] due to the compatibility breaking linker version - pacemaker gets mass rebuilt with prior-rebuild version of libqb, which succeeds incl. executing its just-built executables in %build and %check, which goes just fine because the corosync packages present in buildroot (corosynclibs* ones provide the libraries the executables link against) are built with prior-rebuild version of libqb - I am trying to fix the mentioned FTBFS for libqb and basically using rawhide (pre-branching) for iterative development for integration - Adam Williamson rebuilds corosync without RDMA but already catching on the work in progresss libqb: https://koji.fedoraproject.org/koji/buildinfo?buildID=960725 - BAD THING: such mass-rebuilt pacemaker doesn't combine with such corosync build (some CLI executables will fail with assertion, propagating the problem further -- pcs cannot be built as it runs these programs during its %check) Hence after final freeze of f27, under normal circumstances, we are going to get: 1. WIP libqb 2. corosync linked against WIP libqb 3. unusable pacemaker Ad 1.: that should be fixed with libqb-1.0.2-11.fc27 as a matter of [bug 1478089] Ad 2.: is likely OK Ad 3.: can be resolved with rebuilding pacemaker with libqb per Ad 1. -- this is a subject of this bug, that was created mainly to ask for final freeze exception for this new rebuild
Actually this problem is not limited to CLI tools, daemons are affected alike. For the record, this is how such failure on start is manifested: $ crm_error -h > crm_error: utils.c:69: common: Assertion `0' failed. > Aborted (core dumped)
re [comment 0]: > 2. corosync linked against WIP libqb > [...] > Ad 2.: is likely OK No, it isn't at least with ppc64{,le} because, as mentioned, it was compiled with a WIP version of libqb that sadly lacked the guard for when the "callsite section" feature is not available and coincidentally we artificially disable it for powerpc platforms (perhaps valid in the past, now pretty debatable). In turn, libqb.so (which that corosync was linked against) was made to a linker script even it should not at such systems, and because definitions of QB_ATTR_SECTION_{START,END} were, in contrast, guarded properly in <qb/qblog.h>, these were taken as terminal (non-evaluated further) identifiers that are then demanded (because the linker script previously, when the libs were built on their own, instructed them to demand that later like that so as to keep unresolved symbols behind) in the link with the corosync libraries from corosync built per above. See also [bug 1487787] -- corosync needs to be rebuilt first with the said fix-complete libqb to allow for successfully building pacemaker even with ppc64{,le}.
corosync-2.4.2-6.fc27 libqb-1.0.2-11.fc27 pacemaker-1.1.17-2.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-810447425f
Asking for a final freeze exception for these intertwined bugs: - libqb [bug 1478089] - corosync [bug 1487787] - pacemaker [bug 1503843] <-- this one The respective builds are stacked in a single bodhi update: https://bodhi.fedoraproject.org/updates/FEDORA-2017-810447425f
corosync-2.4.2-6.fc27, libqb-1.0.2-11.fc27, pacemaker-1.1.17-2.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-810447425f
corosync-2.4.2-6.fc27, libqb-1.0.2-11.fc27, pacemaker-1.1.17-2.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.