Debian Bug report logs - #819617
FTBFS: any-i386 - floating point idiosyncracies

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: "Aaron M. Ucko" <ucko@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: bcftools: FTBFS: test suite fails on several architectures

Date: Thu, 21 Jan 2016 22:29:16 -0500

Source: bcftools
Version: 1.2-1
Severity: important
Justification: Fails to build from source

Builds of bcftools for several architectures failed with test suite
errors, as detailed at

https://buildd.debian.org/status/logs.php?pkg=bcftools&ver=1.2-1

Specifically:

* On arm64, armel, and ppc64el, test_vcf_consensus* failed with usage
  errors(!).

* On i386 and kfreebsd-i386, 57 other test cases failed with output
  differences (perhaps related to floating-point unit idiosyncracies --
  it normally works with double-extended precision internally, rather
  than rounding at every step).

Could somebody please take a look?

Thanks!

Message #10 received at 812268@bugs.debian.org (full text, mbox, reply):

From: Afif Elghraoui <afif@ghraoui.name>

To: "Aaron M. Ucko" <ucko@debian.org>, 812268@bugs.debian.org

Subject: Re: [Debian-med-packaging] Bug#812268: bcftools: FTBFS: test suite fails on several architectures

Date: Thu, 21 Jan 2016 22:01:42 -0800

Hello,

على الخميس 21 كانون الثاني 2016 ‫19:29، كتب Aaron M. Ucko:
> 
> Builds of bcftools for several architectures failed with test suite
> errors, as detailed at
> 
> https://buildd.debian.org/status/logs.php?pkg=bcftools&ver=1.2-1
> 
[...]
> Could somebody please take a look?
> 

Hmm. Well, a new upstream release has been made while the package froze
in the NEW queue. We'll have to see whether this issue still exists
there. But that will also require packaging the latest htslib release.

Thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Message #15 received at 812268@bugs.debian.org (full text, mbox, reply):

From: ucko@debian.org (Aaron M. Ucko)

To: Afif Elghraoui <afif@ghraoui.name>

Cc: "Aaron M. Ucko" <ucko@debian.org>, <812268@bugs.debian.org>

Subject: Re: [Debian-med-packaging] Bug#812268: bcftools: FTBFS: test suite fails on several architectures

Date: Fri, 22 Jan 2016 11:10:38 -0500

Afif Elghraoui <afif@ghraoui.name> writes:

> Hmm. Well, a new upstream release has been made while the package froze
> in the NEW queue.

Sounds worth a try, particularly at this stage of the release cycle.

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?amu@monk.mit.edu

Message #22 received at 812268@bugs.debian.org (full text, mbox, reply):

From: Afif Elghraoui <afif@debian.org>

To: 812268@bugs.debian.org

Subject: bcftools - bug represents two separate problems

Date: Thu, 31 Mar 2016 00:40:57 -0700

Control: clone -1 -2
Control: retitle -2 FTBFS: any-i386 - floating point idiosyncracies
Control: retitle -1 FTBFS: arm64, armel, and ppc64el - usage errors in
test suite

These are actually two separate problems. One of them has already been
fixed upstream, and I'll prepare an upload to fix that particular
problem while the other one is still being investigated.

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Message #31 received at 819617@bugs.debian.org (full text, mbox, reply):

From: Christian Seiler <christian@iwakd.de>

To: 819617@bugs.debian.org

Cc: Afif Elghraoui <afif@ghraoui.name>, "Aaron M. Ucko" <ucko@debian.org>

Subject: Re: bcftools: FTBFS: test suite fails on several architectures

Date: Sun, 29 May 2016 13:42:44 +0200

[Message part 1 (text/plain, inline)]

On Thu, 21 Jan 2016 22:29:16 -0500 "Aaron M. Ucko" <ucko@debian.org> wrote:
> * On i386 and kfreebsd-i386, 57 other test cases failed with output
>   differences (perhaps related to floating-point unit idiosyncracies --
>   it normally works with double-extended precision internally, rather
>   than rounding at every step).

I don't have anything to do with the package, but saw the bug
referenced on debian-release, and know a bit about the x86 FPU.
You can actually set the x86 FPU to use double precision internally
(80bit long double calculations will not work as expected then,
though, because the coprocessor will always truncate them to 64bit),
by using:

static void set_fpu_mode()
{
#ifdef __i386__
  unsigned short cw;
  asm volatile ("fnstcw %0" : "=m" (cw));
  cw = (cw & ~0x100) | 0x200;
  asm volatile ("fldcw %0" :: "m" (cw));
#endif
}

(double extended precision is 0x300, double is 0x200 and single
is 0x0, in case you want to change it back. There are other
settings in the control word, so I would recommend touching only
the bits 0x100 and 0x200.)

Other platforms (including x86_64) shouldn't have this trouble,
because even if they support other floating point types, operations
with the double data type are always done in double precision.

(Alternatively, you could use -msse2 as a compiler flag on new
enough x86_32 processors, the compiler would then use the SIMD
instructions instead of the older FPU, but that has the problem
that the code then won't run on older processors, which are still
supported in Debian at the moment.)

Hope that helps.

Regards,
Christian

[signature.asc (application/pgp-signature, attachment)]

Message #36 received at 819617@bugs.debian.org (full text, mbox, reply):

From: Andreas Tille <tille@debian.org>

To: Christian Seiler <christian@iwakd.de>, 819617@bugs.debian.org

Cc: Afif Elghraoui <afif@ghraoui.name>, "Aaron M. Ucko" <ucko@debian.org>

Subject: Re: Bug#819617: bcftools: FTBFS: test suite fails on several architectures

Date: Sun, 29 May 2016 14:31:25 +0200

Hi Christian,

thanks for the hints.

On Sun, May 29, 2016 at 01:42:44PM +0200, Christian Seiler wrote:
> On Thu, 21 Jan 2016 22:29:16 -0500 "Aaron M. Ucko" <ucko@debian.org> wrote:
> > * On i386 and kfreebsd-i386, 57 other test cases failed with output
> >   differences (perhaps related to floating-point unit idiosyncracies --
> >   it normally works with double-extended precision internally, rather
> >   than rounding at every step).
> 
> I don't have anything to do with the package, but saw the bug
> referenced on debian-release, and know a bit about the x86 FPU.
> You can actually set the x86 FPU to use double precision internally
> (80bit long double calculations will not work as expected then,
> though, because the coprocessor will always truncate them to 64bit),
> by using:
> 
> static void set_fpu_mode()
> {
> #ifdef __i386__
>   unsigned short cw;
>   asm volatile ("fnstcw %0" : "=m" (cw));
>   cw = (cw & ~0x100) | 0x200;
>   asm volatile ("fldcw %0" :: "m" (cw));
> #endif
> }
> 
> (double extended precision is 0x300, double is 0x200 and single
> is 0x0, in case you want to change it back. There are other
> settings in the control word, so I would recommend touching only
> the bits 0x100 and 0x200.)
> 
> Other platforms (including x86_64) shouldn't have this trouble,
> because even if they support other floating point types, operations
> with the double data type are always done in double precision.
> 
> (Alternatively, you could use -msse2 as a compiler flag on new
> enough x86_32 processors, the compiler would then use the SIMD
> instructions instead of the older FPU, but that has the problem
> that the code then won't run on older processors, which are still
> supported in Debian at the moment.)

If you ask me the best solution would be to use -msse2 and just add some
code to throw an error if the machine has a to old FPU.  Typically
nobody will use those tools on old hardware anyway - so that's no
practical constraint.
 
> Hope that helps.

Yes, thanks for the hint

      Andreas. 




> _______________________________________________
> Debian-med-packaging mailing list
> Debian-med-packaging@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging


-- 
http://fam-tille.de

Message #41 received at 819617@bugs.debian.org (full text, mbox, reply):

From: Christian Seiler <christian@iwakd.de>

To: Andreas Tille <tille@debian.org>, 819617@bugs.debian.org

Cc: Afif Elghraoui <afif@ghraoui.name>, "Aaron M. Ucko" <ucko@debian.org>

Subject: Re: Bug#819617: bcftools: FTBFS: test suite fails on several architectures

Date: Sun, 29 May 2016 15:07:26 +0200

[Message part 1 (text/plain, inline)]

On 05/29/2016 02:31 PM, Andreas Tille wrote:
> If you ask me the best solution would be to use -msse2 and just add some
> code to throw an error if the machine has a to old FPU.  Typically
> nobody will use those tools on old hardware anyway - so that's no
> practical constraint.

Note that Adam Borowski plans to package something that you'll be able
to depend on that will show a nice error on package installation if
the processor doesn't support SSE2. So in the future you could just
have Depends: sse2-support [i386] in your package, and it wouldn't be
an issue. See Bug.#823672 for details. Unfortunately, that's not
packaged yet.

If you want to figure out if the CPU supports SSE2, you can use the
following piece of code:

int cpu_supports_sse2_or_is_not_x86()
{
#ifdef __i386__
  int mode = 1;
  int flags = 0;
#ifdef __PIC__
  /* Can't automatically clobber %ebx in PIC mode, so save value in
     %edi and clobber that. */
  asm volatile ("movl %%ebx, %%edi\n\t"
                "cpuid\n\t"
                "movl %%edi, %%ebx"
                : "=d" (flags) : "a" (mode) : "edi", "ecx");
#else
  asm volatile ("cpuid"
                : "=d" (flags) : "a" (mode) : "ebx", "ecx");
#endif
  return (flags & (0x1U << 26)) != 0;
#else
  /* either x86_64, which all support sse2, or non-x86, where this
   * isn't relevant */
  return 1;
#endif
}

Regards,
Christian

[signature.asc (application/pgp-signature, attachment)]

Message #46 received at 819617@bugs.debian.org (full text, mbox, reply):

From: Afif Elghraoui <afif@debian.org>

To: Christian Seiler <christian@iwakd.de>, 819617@bugs.debian.org

Subject: bcftools: FTBFS: test suite fails on several architectures

Date: Tue, 31 May 2016 01:41:31 -0700

على الأحد 29 أيار 2016 ‫04:42، كتب Christian Seiler:
> Hope that helps.

It's very much appreciated! I don't have the chance to try it out myself
for a while, but I've notified upstream about your suggestions. We'll
see how it goes.

Many thanks and regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Message #51 received at 819617@bugs.debian.org (full text, mbox, reply):

From: Afif Elghraoui <afif@debian.org>

To: 819617@bugs.debian.org

Subject: bcftools i386 - update on compiling with -msse2

Date: Sun, 26 Jun 2016 16:10:02 -0700

[Message part 1 (text/plain, inline)]

For the record here, building with -msse2 doesn't help on i386 (build
log attached). According to upstream discussion, the problem has to do
with NaNs.

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

[bcftools_1.3.1-2_i386.build.gz (application/gzip, attachment)]

Message #56 received at 819617@bugs.debian.org (full text, mbox, reply):

From: Chris Lamb <lamby@debian.org>

To: 819617@bugs.debian.org

Cc: "Aaron M. Ucko" <ucko@debian.org>

Subject: Re: FTBFS: any-i386 - floating point idiosyncracies

Date: Wed, 26 Oct 2016 22:09:58 +0100

Hi,

> FTBFS: any-i386 - floating point idiosyncracies

Out of interest, why is this not RC severity? :)


Regards,

-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby@debian.org / chris-lamb.co.uk
       `-

Message #61 received at 819617@bugs.debian.org (full text, mbox, reply):

From: ucko@debian.org (Aaron M. Ucko)

To: Chris Lamb <lamby@debian.org>

Cc: <819617@bugs.debian.org>, 834863@bugs.debian.org, 793844@bugs.debian.org, "Aaron M. Ucko" <ucko@debian.org>

Subject: Re: FTBFS: any-i386 - floating point idiosyncracies

Date: Wed, 26 Oct 2016 19:58:18 -0400

Chris Lamb <lamby@debian.org> writes:

>> FTBFS: any-i386 - floating point idiosyncracies
>
> Out of interest, why is this not RC severity? :)

Because that's normally reserved for regressions (or at least cases
where binNMUs would be expected to fail), and this package *never* built
on these architectures.  (Likewise for #834863 and #793844.)

Thanks for checking, and for looking into these bugs!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?amu@monk.mit.edu

Message #66 received at 819617@bugs.debian.org (full text, mbox, reply):

From: Chris Lamb <lamby@debian.org>

To: "Aaron M. Ucko" <ucko@debian.org>

Cc: 819617@bugs.debian.org, 834863@bugs.debian.org, 793844@bugs.debian.org

Subject: Re: FTBFS: any-i386 - floating point idiosyncracies

Date: Thu, 27 Oct 2016 20:22:47 +0100

Aaron M. Ucko wrote:

> this package *never* built on these architectures

Ah, of course. For some reason I never remember to think of this
for i386 and amd64 packages... :)


Regards,

-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby@debian.org / chris-lamb.co.uk
       `-

Message #71 received at 819617@bugs.debian.org (full text, mbox, reply):

From: Andreas Tille <andreas@fam-tille.de>

To: 819617@bugs.debian.org

Subject: Re: Bug#819617: bcftools: FTBFS: test suite fails on several architectures

Date: Fri, 28 Oct 2016 08:39:41 +0200

On Sun, 26 Jun 2016 16:10:02 -0700, Afif Elghraoui wrote:
> For the record here, building with -msse2 doesn't help on i386 (build
> log attached). According to upstream discussion, the problem has to do
> with NaNs.

So what can we actually do with this.  Bcftools has several reverse
(Build-)Dependencies and we need to decide whether we drop the failed
architectures for all these.

Alternatively we could consider to document that some tests are failing
on certain architectures and let those failed tests pass.

Kind regards

      Andreas.

-- 
http://fam-tille.de

Message #76 received at 819617@bugs.debian.org (full text, mbox, reply):

From: Afif Elghraoui <afif@debian.org>

To: Andreas Tille <andreas@fam-tille.de>, 819617@bugs.debian.org

Subject: Re: [Debian-med-packaging] Bug#819617: bcftools: FTBFS: test suite fails on several architectures

Date: Thu, 27 Oct 2016 23:54:21 -0700

Hi, Andreas,

على الخميس 27 تشرين الأول 2016 ‫23:39، كتب Andreas Tille:
> On Sun, 26 Jun 2016 16:10:02 -0700, Afif Elghraoui wrote:
>> For the record here, building with -msse2 doesn't help on i386 (build
>> log attached). According to upstream discussion, the problem has to do
>> with NaNs.
> 
> So what can we actually do with this.  Bcftools has several reverse
> (Build-)Dependencies and we need to decide whether we drop the failed
> architectures for all these.
> 

Upstream's planned solution to this requires some changes to their
format specification (details are in the upstream bug report). I think
we just have to wait.

> Alternatively we could consider to document that some tests are failing
> on certain architectures and let those failed tests pass.
> 

I don't know if this is a good idea. The tests fail because inaccurate
results, not crashes. If we let these through, users on these
architectures would unsuspectingly get wrong output.

If we /really/ want to, we could make a different package for pysam's
bcftools interface. Reverse-dependencies that only need the samtools
interface could then be untethered from this bug. I wouldn't volunteer
to do this, though.


regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Message #81 received at 819617@bugs.debian.org (full text, mbox, reply):

From: Andreas Tille <andreas@fam-tille.de>

To: 819617@bugs.debian.org

Subject: Re: Bug#819617: bcftools: FTBFS: test suite fails on several architectures

Date: Fri, 28 Oct 2016 09:18:30 +0200

Hi Afif,

On Thu, Oct 27, 2016 at 11:54:21PM -0700, Afif Elghraoui wrote:
> > On Sun, 26 Jun 2016 16:10:02 -0700, Afif Elghraoui wrote:
> >> For the record here, building with -msse2 doesn't help on i386 (build
> >> log attached). According to upstream discussion, the problem has to do
> >> with NaNs.
> > 
> > So what can we actually do with this.  Bcftools has several reverse
> > (Build-)Dependencies and we need to decide whether we drop the failed
> > architectures for all these.
> 
> Upstream's planned solution to this requires some changes to their
> format specification (details are in the upstream bug report). I think
> we just have to wait.

The question is how long we have to wait.  We need to get our packages
in testing into shape until the end of this year.  This bug is open for
quite some time which makes me wonder how long the waiting time might
be.
 
> > Alternatively we could consider to document that some tests are failing
> > on certain architectures and let those failed tests pass.
> 
> I don't know if this is a good idea. The tests fail because inaccurate
> results, not crashes. If we let these through, users on these
> architectures would unsuspectingly get wrong output.

Yes, that's perfectly true and not my prefered solution.  The question
was actually to those who have deeper insight and if its a matter of
NaNs which have a different representation this might be some quite
unusual corner case (on some rarely used architectures) and thus a
proper documentation might make sense (or not - as I said depending on
the expert insight into this issue).
 
> If we /really/ want to, we could make a different package for pysam's
> bcftools interface. Reverse-dependencies that only need the samtools
> interface could then be untethered from this bug. I wouldn't volunteer
> to do this, though.

Any other volunteer?  I think if the problem persists until our advent
bug squashing party I'll ask for removal of the packages for the
affected architectures. 

Kind regards

     Andreas.

-- 
http://fam-tille.de

Message #86 received at 819617@bugs.debian.org (full text, mbox, reply):

From: Afif Elghraoui <afif@debian.org>

To: 819617@bugs.debian.org

Subject: Re: [Debian-med-packaging] Bug#819617: bcftools: FTBFS: test suite fails on several architectures

Date: Fri, 28 Oct 2016 00:51:39 -0700

Hi, Andreas,

على الجمعـة 28 تشرين الأول 2016 ‫00:18، كتب Andreas Tille:
>> Upstream's planned solution to this requires some changes to their
>> format specification (details are in the upstream bug report). I think
>> we just have to wait.
> 
> The question is how long we have to wait.  We need to get our packages
> in testing into shape until the end of this year.  This bug is open for
> quite some time which makes me wonder how long the waiting time might
> be.
>  

I don't think it will be anytime soon. The planned changes seem to have
far-reaching consequences.


>>> Alternatively we could consider to document that some tests are failing
>>> on certain architectures and let those failed tests pass.
>>
>> I don't know if this is a good idea. The tests fail because inaccurate
>> results, not crashes. If we let these through, users on these
>> architectures would unsuspectingly get wrong output.
> 
> Yes, that's perfectly true and not my prefered solution.  The question
> was actually to those who have deeper insight and if its a matter of
> NaNs which have a different representation this might be some quite
> unusual corner case (on some rarely used architectures) and thus a
> proper documentation might make sense (or not - as I said depending on
> the expert insight into this issue).

I'm sorry about that. In this case, I think you should ask on the
upstream ticket (or see if the discussion between the upstream
developers there already answers your question).

>  
>> If we /really/ want to, we could make a different package for pysam's
>> bcftools interface. Reverse-dependencies that only need the samtools
>> interface could then be untethered from this bug. I wouldn't volunteer
>> to do this, though.
> 
> Any other volunteer?  I think if the problem persists until our advent
> bug squashing party I'll ask for removal of the packages for the
> affected architectures. 
> 

We'd need a new source package, not just a new binary package for the
pysam source code. I think you can expect for this bug not to be
resolved soon, so I see that it is either the pysam source-package copy
or the removal of rdeps on i386.

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Message #91 received at 819617@bugs.debian.org (full text, mbox, reply):

From: Afif Elghraoui <afif@debian.org>

To: 819617@bugs.debian.org

Subject: Re: [Debian-med-packaging] Bug#819617: Bug#819617: bcftools: FTBFS: test suite fails on several architectures

Date: Fri, 28 Oct 2016 01:02:03 -0700

على الجمعـة 28 تشرين الأول 2016 ‫00:51، كتب Afif Elghraoui:
> Hi, Andreas,
> 
> على الجمعـة 28 تشرين الأول 2016 ‫00:18، كتب Andreas Tille:
>>
>> Any other volunteer?  I think if the problem persists until our advent
>> bug squashing party I'll ask for removal of the packages for the
>> affected architectures. 
>>
> 
> We'd need a new source package, not just a new binary package for the
> pysam source code. I think you can expect for this bug not to be
> resolved soon, so I see that it is either the pysam source-package copy
> or the removal of rdeps on i386.

Come to think of it, this might not be the only hurdle. If bcftools
becomes available on i386, pysam might still not be able to build on it
because of #834856 -- that is a FTBFS on 32-bit platforms and it affects
the samtools interface. I hadn't forwarded that report to pysam upstream
because it was originally reported as a mips-specific problem. I can
probably forward that tomorrow.

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Message #96 received at 819617@bugs.debian.org (full text, mbox, reply):

From: Andreas Tille <andreas@an3as.eu>

To: 819617@bugs.debian.org

Subject: Re: Bug#819617: bcftools: FTBFS: test suite fails on several architectures

Date: Fri, 28 Oct 2016 11:31:40 +0200

On Fri, Oct 28, 2016 at 01:02:03AM -0700, Afif Elghraoui wrote:
> >> Any other volunteer?  I think if the problem persists until our advent
> >> bug squashing party I'll ask for removal of the packages for the
> >> affected architectures. 
> >>
> > 
> > We'd need a new source package, not just a new binary package for the
> > pysam source code. I think you can expect for this bug not to be
> > resolved soon, so I see that it is either the pysam source-package copy
> > or the removal of rdeps on i386.
> 
> Come to think of it, this might not be the only hurdle. If bcftools
> becomes available on i386, pysam might still not be able to build on it
> because of #834856 -- that is a FTBFS on 32-bit platforms and it affects
> the samtools interface. I hadn't forwarded that report to pysam upstream
> because it was originally reported as a mips-specific problem. I can
> probably forward that tomorrow.

Both of your mails let me think that its now time to ask ftpmaster to
remove the affected architectures.  Its better to do this now than later
since we need to make it through the whole chain of dependencies. Any
better idea?

Kind regards

     Andreas.

-- 
http://fam-tille.de

Message #101 received at 819617@bugs.debian.org (full text, mbox, reply):

From: Andreas Tille <andreas@fam-tille.de>

To: 819617@bugs.debian.org

Cc: 859090@bugs.debian.org, 859091@bugs.debian.org

Subject: Please upload fixed bcftools (Was: mapdamage is marked for autoremoval from testing)

Date: Fri, 7 Apr 2017 10:39:03 +0200

Hi,

as far as I can see the fact that bcftools is missing on i386 leads to a
missing python-pysam and thus mapdamage can not migrate.  Would you please
mind updating bcftools or do any action as you wrote in your last message
to enable fixing this chain of dependencies?

Kind regards

      Andreas.

On Fri, Apr 07, 2017 at 04:39:05AM +0000, Debian testing autoremoval watch wrote:
> mapdamage 2.0.6+dfsg-1 is marked for autoremoval from testing on 2017-04-22
> 
> It is affected by these RC bugs:
> 859090: mapdamage: mapdamage has incomplete patch to not always find seqtk
> 859091: mapdamage: Missing dependencies prevent proper functionality
> 

-- 
http://fam-tille.de

Send a report that this bug log contains spam.