On Mon, Dec 14, 2015 at 06:26:34PM +0100, gregor herrmann wrote: > On Mon, 14 Dec 2015 11:15:03 +0100, Emilio Pozuelo Monfort wrote: > > > >> Dominic Hargreaves <d...@earth.li> writes: > > > >>> If not then perhaps that should just be dropped from the > > >>> redhat-cluster package ASAP [...] -- of course, since redhat-cluster > > >>> FTBFS, this would have to be done by the release team manually > > >>> removing (just) libccs-perl from testing. Is this feasible? > > > > Not really. At least not AFAIK, and it'd be hackish and ugly if it was > > possible. > > It'd be nice if the FTBFS got fixed instead. If it's too difficult to make > > it > > build with GCC 5 (I guess it isn't, but...) then as a temporary workaround > > you > > could make it build with GCC 4.9. > > The build doesn't even get that far, it fails due to the corosync > changes, cf. #804590.
Just so everyone is on the same page, the redhat-cluster FTBFS is now the only thing blocking a 500+ package Perl transition we've been working on for half a year. It looks to me like the corosync v1->v2 API changes are indeed significant enough that making redhat-cluster build again is non-trivial. So the proper way out seems to be a separate libdlm source package, as discussed in [1]. Ferenc, do I understand right that a new pacemaker package is a blocker for this? Is that because the current pacemaker would be broken by the libdlm update? FWIW I see Ubuntu already separated libdlm out back in 2013. Maybe that work helps a bit? Some other hackish and ugly things we've discussed: - is it technically possible to force the transition through and leave libccs-perl uninstallable in testing? Or do britney et al. enforce the installability so that it can't be overridden? - as clearly nobody cares about libccs-perl itself, would hijacking the libccs-perl binary package with a (more or less dummy) new source package work wrt. testing migration? - reintroducing corosync v1 temporarily to get redhat-cluster to build would work AFAICS but it's *very* ugly... - temporarily dropping the clvm binary package until libdlm can be built again seems doable, but as #697676 shows something like this was done for wheezy and had to reverted due to user demand, so presumably Bastian wouldn't be thrilled to try it again Other ideas would be welcome too. [1] https://lists.alioth.debian.org/pipermail/debian-ha-maintainers/2015-December/004615.html -- Niko Tyni nt...@debian.org
