[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Debian-med-packaging] Bug#911793: autopkgtest regression: Segmentation fault

Hi Emmanuel,

On 19-11-18 22:11, Emmanuel Promayon wrote:
> On 19/11/2018 19:32, Paul Gevers wrote:
>> If you comment on the RC bug that is triggering the autoremoval, then
>> the timer gets reset. Just explain there why it can't be fixed NOW. I
>> still agree with Mattia: "This is the signature of an ABI break not
>> correctly handled." so I believe that should be fixed first.
> The RC bug that triggered the autoremoval is #909120 [1] and (I hope it)
> should be fixed by camitk version 4.1.2-2 (now in unstable and
> struggling to get into testing). The bug was closed automatically by the
> upload ot 4.1.2-2.
> Just to make sure that I understand correctly about the autoremoval: if
> I comment on #909120  it should delay the autoremoval?


> I understand as well that it might not be the best thing to do first (I
> just like to understand a bit better).

Commenting on the bug is fine. You're working on a solution and that
issue is fixed in unstable. For reasons potentially outside your
control, the solution can't migrate to testing.

> About the ABI break: I am sorry to say that I don't really understand
> how to fix this.

I don't either, it needs deeper digging, and probably isn't a thing that
camitk should fix either. See further below.

> Is it possible that this ABI breaks comes from the fact camitk 4.1.2-1
> is based on vtk6 (which introduced #909120 in the first place when gdcm
>>= 2.8.7-2 moved from python2 to python3 and consequently from vtk6 to
> vtk7) while camitk-4.1.2-2 is based on vtk7 and gdcm >= 2.8.7-2?

I don't believe so. It is camitk that is broken, even when used with
vtk7 and gdcm >= 2.8.7-2.

> If yes, should I add a "Breaks: vtk6" in d/control of camitk?

That is not going to help, see below.

> And/or as
> you suggested earlier should I add "gdcm >= 2.8.8"? Or it is something
> (like "Breaks:vtk6") that should be done in gdcm or vtk7 instead?

I don't think so. I believe something in gdcm broke your package. If I
currently look at the autopkgtest results in unstable [2] I see that
your current version was fine for a while, until gdcm 2.8.8-1 was
uploaded. The error you receive is the same in unstable and testing now.
Note that all the versions of gdcm and vtk* you talked about in the past
are now in testing. The reason why the old gamitk keeps working is
because the old versions of the libraries stay around as long as needed
by a package.

I don't know about the internals of vtk and gdcm, but something seems
broken in there. I can't tell from here what it is.

> Thank you again for your message... and for your patience (and do not
> hesitate to refer me to some documentation or example, my packager
> training is far from being finished, as you can see!)

Neither is mine :).

> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909120


[2] https://ci.debian.net/packages/c/camitk/unstable/amd64/

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: