Bug#796345: [Debian-ha-maintainers] Bug#796345: redhat-cluster/libdlm + lvm + perl transition

[Christoph Berg]

Re: Ferenc Wagner 2015-12-22 <874mfbfh6y@lant.ki.iif.hu>
> Emilio Pozuelo Monfort  writes:
> 
> > This is the last blocker for the perl transition. Packages should be
> > installable now in unstable. Please let us know if you make progress
> > with this or if you hit any blockers.
> 
> Short progress report: no blockers.
> 
> I encountered unexpected problems, but they are mostly solved by now.
> While waiting for the review of my sponsor, I'm doing QA tests.

pacemaker 1.1.13-1 is now in NEW.

Thanks to Feri for preparing this release!

Merry Christmas,
Christoph
-- 
c...@df7cb.de | http://www.df7cb.de/


signature.asc
Description: Digital signature

Bug#796345: [Debian-ha-maintainers] Bug#796345: redhat-cluster/libdlm + lvm + perl transition

[Ferenc Wagner]

Emilio Pozuelo Monfort  writes:

> This is the last blocker for the perl transition. Packages should be
> installable now in unstable. Please let us know if you make progress
> with this or if you hit any blockers.

Short progress report: no blockers.

I encountered unexpected problems, but they are mostly solved by now.
While waiting for the review of my sponsor, I'm doing QA tests.
-- 
Regards,
Feri.

Bug#796345: [Debian-ha-maintainers] Bug#796345: redhat-cluster/libdlm + lvm + perl transition

[Emilio Pozuelo Monfort]

On 17/12/15 14:09, Ferenc Wagner wrote:
> Ferenc Wagner  writes:
> 
>> Emilio Pozuelo Monfort  writes:
>>
>>> On 16/12/15 00:12, Ferenc Wagner wrote:
>>>
 Niko Tyni  writes:

> 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?

 No: the new DLM package depends on the new Pacemaker package.  I'm
 already testing them, there's only some cleanup remaining before they
 can be uploaded.  Both will go through NEW though, so it will take some
 time.
>>>
>>> I can speed things up if they block a transition... Got an eta for this?
>>
>> That sounds useful!  I expect to get pacemaker_1.1.13-1 ready for upload
>> today, taking some shortcuts.
> 
> Now the Perl transition is rolling and I can't build Pacemaker anymore,
> because some of its build dependencies are broken.  Is there still a
> reason to hurry the uploads?

This is the last blocker for the perl transition. Packages should be installable
now in unstable. Please let us know if you make progress with this or if you hit
any blockers.

Cheers,
Emilio

Bug#796345: [Debian-ha-maintainers] Bug#796345: redhat-cluster/libdlm + lvm + perl transition

[Emilio Pozuelo Monfort]

On 17/12/15 14:09, Ferenc Wagner wrote:
> Ferenc Wagner  writes:
> 
>> Emilio Pozuelo Monfort  writes:
>>
>>> On 16/12/15 00:12, Ferenc Wagner wrote:
>>>
 Niko Tyni  writes:

> 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?

 No: the new DLM package depends on the new Pacemaker package.  I'm
 already testing them, there's only some cleanup remaining before they
 can be uploaded.  Both will go through NEW though, so it will take some
 time.
>>>
>>> I can speed things up if they block a transition... Got an eta for this?
>>
>> That sounds useful!  I expect to get pacemaker_1.1.13-1 ready for upload
>> today, taking some shortcuts.
> 
> Now the Perl transition is rolling and I can't build Pacemaker anymore,
> because some of its build dependencies are broken.  Is there still a
> reason to hurry the uploads?

Yes, it'd be good to get this fixed ASAP, so that we can rebuild or remove
redhat-cluster.

The perl rdeps should be installable again at some point today, hopefully.

Cheers,
Emilio

Bug#796345: redhat-cluster/libdlm + lvm + perl transition

[Ferenc Wagner]

Emilio Pozuelo Monfort  writes:

> On 16/12/15 00:12, Ferenc Wagner wrote:
>
>> Niko Tyni  writes:
>> 
>>> 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?
>> 
>> No: the new DLM package depends on the new Pacemaker package.  I'm
>> already testing them, there's only some cleanup remaining before they
>> can be uploaded.  Both will go through NEW though, so it will take some
>> time.
>
> I can speed things up if they block a transition... Got an eta for this?

That sounds useful!  I expect to get pacemaker_1.1.13-1 ready for upload
today, taking some shortcuts.  I'll try to contact my usual sponsor, but
other interested parties can also step in. :)  If no serious issue
surfaces during this process, we can quickly repeat for DLM.

>> Then LVM will have to be rebuilt against the new DLM, and you
>> will be free to kick redhat-cluster out of the archive (I hope nothing
>> else depends on it).
>
> Checking reverse dependencies...
> # Broken Depends:
> gfs2-utils: gfs2-cluster [amd64 arm64 armel armhf i386 mips mipsel powerpc 
> ppc64el s390x]
> gfs2-utils [amd64 arm64 armel armhf i386 mips mipsel powerpc 
> ppc64el s390x]
> lvm2: clvm [amd64 arm64 armel armhf i386 mips mips64el mipsel powerpc ppc64el 
> s390x]
>
> # Broken Build-Depends:
> gfs2-utils: libccs-dev (>= 3.1.0)
> libcman-dev (>= 3.1.0)
> libdlm-dev (>= 3.1.0)
> libdlmcontrol-dev (>= 3.1.0)
> libfence-dev (>= 3.1.0)
> liblogthread-dev (>= 3.1.0)
> lvm2: libcman-dev (> 2)
>   libdlm-dev (> 2)
> ocfs2-tools: libdlm-dev
>  libdlmcontrol-dev

Thanks.  We will take care of gfs2-utils and ocfs2-tools soon, those are
also maintained by the HA team.
-- 
Regards,
Feri.

Bug#796345: [Debian-ha-maintainers] Bug#796345: redhat-cluster/libdlm + lvm + perl transition

[Ferenc Wagner]

Ferenc Wagner  writes:

> Emilio Pozuelo Monfort  writes:
>
>> On 16/12/15 00:12, Ferenc Wagner wrote:
>>
>>> Niko Tyni  writes:
>>> 
 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?
>>> 
>>> No: the new DLM package depends on the new Pacemaker package.  I'm
>>> already testing them, there's only some cleanup remaining before they
>>> can be uploaded.  Both will go through NEW though, so it will take some
>>> time.
>>
>> I can speed things up if they block a transition... Got an eta for this?
>
> That sounds useful!  I expect to get pacemaker_1.1.13-1 ready for upload
> today, taking some shortcuts.

Now the Perl transition is rolling and I can't build Pacemaker anymore,
because some of its build dependencies are broken.  Is there still a
reason to hurry the uploads?
-- 
Regards,
Feri.

Bug#796345: redhat-cluster/libdlm + lvm + perl transition

[Ferenc Wagner]

Niko Tyni  writes:

> 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?

No: the new DLM package depends on the new Pacemaker package.  I'm
already testing them, there's only some cleanup remaining before they
can be uploaded.  Both will go through NEW though, so it will take some
time.  Then LVM will have to be rebuilt against the new DLM, and you
will be free to kick redhat-cluster out of the archive (I hope nothing
else depends on it).

Actually, it would be possible to temporarily omit Pacemaker support
from DLM, but I'd like to avoid that if possible.
-- 
Regards,
Feri.

Bug#796345: redhat-cluster/libdlm + lvm + perl transition

[Emilio Pozuelo Monfort]

On 16/12/15 00:12, Ferenc Wagner wrote:
> Niko Tyni  writes:
> 
>> 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?
> 
> No: the new DLM package depends on the new Pacemaker package.  I'm
> already testing them, there's only some cleanup remaining before they
> can be uploaded.  Both will go through NEW though, so it will take some
> time.

I can speed things up if they block a transition... Got an eta for this?

> Then LVM will have to be rebuilt against the new DLM, and you
> will be free to kick redhat-cluster out of the archive (I hope nothing
> else depends on it).

Checking reverse dependencies...
# Broken Depends:
gfs2-utils: gfs2-cluster [amd64 arm64 armel armhf i386 mips mipsel powerpc 
ppc64el s390x]
gfs2-utils [amd64 arm64 armel armhf i386 mips mipsel powerpc 
ppc64el s390x]
lvm2: clvm [amd64 arm64 armel armhf i386 mips mips64el mipsel powerpc ppc64el 
s390x]

# Broken Build-Depends:
gfs2-utils: libccs-dev (>= 3.1.0)
libcman-dev (>= 3.1.0)
libdlm-dev (>= 3.1.0)
libdlmcontrol-dev (>= 3.1.0)
libfence-dev (>= 3.1.0)
liblogthread-dev (>= 3.1.0)
lvm2: libcman-dev (> 2)
  libdlm-dev (> 2)
ocfs2-tools: libdlm-dev
 libdlmcontrol-dev

Cheers,
Emilio

Bug#796345: redhat-cluster/libdlm + lvm + perl transition

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 15/12/15 21:27, Niko Tyni wrote:
> 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  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?

That's possible, in exceptional circumstances. Obviously I would prefer not to
do that.

> - 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?

Let's not do that.

> - reintroducing corosync v1 temporarily to get redhat-cluster to build
>   would work AFAICS but it's *very* ugly...

Let's not do that.

> - 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

Right. That shouldn't be necessary.

If redhat-cluster doesn't get fixed in time, I guess we'll just make libccs-perl
uninstallable.

Let's do this.

Cheers,
Emilio

Bug#796345: redhat-cluster/libdlm + lvm + perl transition

[Niko Tyni]

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  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

Bug#796345: redhat-cluster/libdlm + lvm + perl transition

[Bastian Blank]

Hi Ferenc

On Wed, Dec 16, 2015 at 12:12:18AM +0100, Ferenc Wagner wrote:
> No: the new DLM package depends on the new Pacemaker package.  I'm
> already testing them, there's only some cleanup remaining before they
> can be uploaded.

Can you give an ETA?  Otherwise I'm inclined to remove cluster support
from lvm2 completely and ask for temporarily removal of all the rest from
testing.  This will produce a large outcry.

>   Both will go through NEW though, so it will take some
> time.

Please don't argue with NEW.  The processing time of NEW differs widely,
from half an hour to years.

Bastian

-- 
Conquest is easy. Control is not.
-- Kirk, "Mirror, Mirror", stardate unknown

Bug#796345: redhat-cluster/libdlm + lvm + perl transition

[Dominic Hargreaves]

[adding redhat-cluster and lvm maintainers to thread. This discussion
is about trying to start the perl 5.22 transition, which has been
'about to happen' since August - so obviously those of us who care
about that are quite keen to see it happen sooner rather than later]

[take two with fixed addresses; please ignore the previous versions
of this message]

On Sun, Dec 13, 2015 at 11:14:20PM +0100, Emilio Pozuelo Monfort wrote:
> On 13/12/15 13:43, Dominic Hargreaves wrote:
> > As I already mentioned, redhat-cluster currently FTBFS, and has done
> > since August, so I don't think we should block on that.
> 
> We can't remove it from testing as lvm2 depends on it, so this really is a 
> blocker.

Ah, this is unfortunate (and it's especially unfortunate that we didn't
spot this blocking back in August..). It doesn't look like fixing
those[1] FTBFS bugs is easy, especially given that the redhat-cluster
package is quite a way behind where upstream are (and upstream have
completely reorganised these packages (as best I can tell as someone
who is not at all familiar with them).

>From [2] it appears that work is underway to fix all this, by including
libdlm as a separate package. Presumably at this point lvm2 would not
depend on redhat-cluster and it could be removed from testing?

As a more immediate fix - can the HA team comment on whether libccs-perl
has any value? If not then perhaps that should just be dropped from
the redhat-cluster package ASAP (its description[3], not to mention
its popcon of 3, implies it could be dropped without grave consequence).

Cheers,
Dominic.

[1] ,

[2] 

[3] 

Bug#796345: redhat-cluster/libdlm + lvm + perl transition

[Dominic Hargreaves]

[adding redhat-cluster and lvm maintainers to thread. This discussion
is about trying to start the perl 5.22 transition, which has been
'about to happen' since August - so obviously those of us who care
about that are quite keen to see it happen sooner rather than later]

On Sun, Dec 13, 2015 at 11:14:20PM +0100, Emilio Pozuelo Monfort wrote:
> On 13/12/15 13:43, Dominic Hargreaves wrote:
> > As I already mentioned, redhat-cluster currently FTBFS, and has done
> > since August, so I don't think we should block on that.
> 
> We can't remove it from testing as lvm2 depends on it, so this really is a 
> blocker.

Ah, this is unfortunate (and it's especially unfortunate that we didn't
spot this blocking back in August..). It doesn't look like fixing
those[1] FTBFS bugs is easy, especially given that the redhat-cluster
package is quite a way behind where upstream are (and upstream have
completely reorganised these packages (as best I can tell as someone
who is not at all familiar with them).

>From [2] it appears that work is underway to fix all this, by including
libdlm as a separate package. Presumably at this point lvm2 would not
depend on redhat-cluster and it could be removed from testing?

As a more immediate fix - can the HA team comment on whether libccs-perl
has any value? If not then perhaps that should just be dropped from
the redhat-cluster package ASAP (its description[3], not to mention
its popcon of 3, implies it could be dropped without grave consequence).

Cheers,
Dominic.

[1] ,

[2] 

[3] 

Bug#796345: redhat-cluster/libdlm + lvm + perl transition

[Dominic Hargreaves]

On Sun, Dec 13, 2015 at 11:56:41PM +, Dominic Hargreaves wrote:
> [adding redhat-cluster and lvm maintainers to thread. This discussion
> is about trying to start the perl 5.22 transition, which has been
> 'about to happen' since August - so obviously those of us who care
> about that are quite keen to see it happen sooner rather than later]
> 
> [take two with fixed addresses; please ignore the previous versions
> of this message]
> 
> On Sun, Dec 13, 2015 at 11:14:20PM +0100, Emilio Pozuelo Monfort wrote:
> > On 13/12/15 13:43, Dominic Hargreaves wrote:
> > > As I already mentioned, redhat-cluster currently FTBFS, and has done
> > > since August, so I don't think we should block on that.
> > 
> > We can't remove it from testing as lvm2 depends on it, so this really is a 
> > blocker.
> 
> Ah, this is unfortunate (and it's especially unfortunate that we didn't
> spot this blocking back in August..). It doesn't look like fixing
> those[1] FTBFS bugs is easy, especially given that the redhat-cluster
> package is quite a way behind where upstream are (and upstream have
> completely reorganised these packages (as best I can tell as someone
> who is not at all familiar with them).
> 
> >From [2] it appears that work is underway to fix all this, by including
> libdlm as a separate package. Presumably at this point lvm2 would not
> depend on redhat-cluster and it could be removed from testing?
> 
> As a more immediate fix - can the HA team comment on whether libccs-perl
> has any value? If not then perhaps that should just be dropped from
> the redhat-cluster package ASAP (its description[3], not to mention
> its popcon of 3, implies it could be dropped without grave consequence).

Just to add - 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?

Thanks,
Dominic.