[Debian-med-packaging] Bug#914483: Control: reassign -1 src:gdcm 2.8.7-2

[Mattia Rizzolo]

[ note how I removed 914347 from the recipients and kept only 914483 ]

On Fri, Nov 23, 2018 at 09:43:10PM +0100, Gert Wollny wrote:
> Am Freitag, den 23.11.2018, 20:14 +0100 schrieb Mattia Rizzolo:
> > Hi,
> > 
> > so, if you don't particularly mind, I'm happy to just take the least
> > and fix all the involved packages here, so src:vtk7 
> I just uploaded vtk7, I knew where to look because I did the changes
> that made the libraries go away, and the python thing was not so
> difficult after all.

Thanks, that one looks good to me.

> > Gert: you mention you gave up on symbols, but at least in gdcm's
> > changelog I don't see anything about that.  Had you had troubles
> > there as well?
> TBH I never tried with gdcm, I think I started to upload the package
> when it was already at version 2.4 and I didn't even note that there is
> a script for the symbols there (which points at 2.2).

regardless of that script (I don't particularly like
pkgkde-symbolshelper tbh, also I don't think that script is doing that
much to help…), I notice that the libgdcm2.8 library is indeed not
nice...

I tried to compared the symbols exported between several versions, and
they all differ.  And not just from some templates or stuff leaked from
the std library; for example between 2.8.7-1 and 2.8.7-2 stuff like this
disappered from libgdcmDSED.so.2.8:
    _ZN10gdcmstrict7DataSet6RemoveERKN4gdcm3TagE at Base
and many others...  I haven't looked deep so I couldn't quite understand
where that is coming from, but given that this happens quite frequently
but clearly nothing breaks badly all the time I guess it's just
something that shouldn't have been exported in the first place?

> When I started packaging some of my software (mia) that has lots of
> templates I just noted that getting symbols right there is kind of an
> infinite task because each arch would need its own file because of
> templates that on 64 bit use some types that are not available, and
> were not instanciated on 32 bit systems. Maybe the tools are better
> now, but at that time (2012) it was all kind of wired.

If it's only 32/64 bits difference, that's easy to do since there is an
arch-bits filter you can use.  But I acknowledge that for many c++
libraries where their developers don't explicitly try to keep their
exported ABI tidy is very easy to get a mess.

This line is from a diff between libgdcm2.8 2.8.7-2 vs 2.8.7-5:
- gdcm::Attribute<(unsigned short)32, (unsigned short)17, 512, 1>::GetAsDataElement() const at Base 2.8.7
+ gdcm::Attribute<(unsigned short)32, (unsigned short)19, 512, 1>::GetAsDataElement() const at Base 2.8.7

That's clearly something that shouldn't have leaked here...

But that kind of things make impossible even thoughts like "I'll keep a
.symbols only for amd64" (which is a valid idea to have).


At the same time, libvtkgdcm is much more tidy, so at least I will start
adding a .symbols file to that one...

> > What I would welcome your help with is explaining the camitk FTBFS on
> > i386.
> Just had as peek, my guess is that this will help: 
> 
> ifeq ($(DEB_BUILD_ARCH),i386)

Note that here you probably meant DEB_HOST_ARCH, not build arch.

>   export DEB_CXXFLAGS_MAINT_APPEND=-ffloat-store
> endif
> 
> The same was needed for ITK because they write tests with floating
> point values apparently comparing with high accuracy, and on i386
> optimizations can lead to the used of intermediate 80 bit floating
> point values that then result in test failures because the references
> were tuned for 64 bit floating point values. Adding above flag makes
> sure that intermediate results are not keps in these 80 bit FPU
> registers.

ACK, thanks.

-- 
regards,
                        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540      .''`.
more about me:  https://mapreri.org                             : :'  :
Launchpad user: https://launchpad.net/~mapreri                  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/debian-med-packaging/attachments/20181124/cc6f380a/attachment.sig>