[Debian-med-packaging] Bug#920240: abyss fails to build on hurd due to missing header file

[Boud Roukema]

hi Andreas, Samuel,

On Wed, 23 Jan 2019, Samuel Thibault wrote:

> Andreas wrote:

>> Could you please adjust the severity?  Regarding the description[1]
>> important means:
>>
>>       a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone.
>>
>> I do not think that non-released architectures have a major effect on
>> the usability of a package.

> No, but it does have a major effect on the usability of the package on
> that architecture, that's why we are usually using that priority.

FTBFS for a released architecture would require an RC level severity.
Since hurd is not a released architecture, I agree that the severity should
be at sub-RC level (especially right now with the successive freeze stages
for a new stable release).

I also agree with Samuel that for a GNU/hurd user, FTBFS is a major
effect: Debian is supposed to provide binaries, not just sources that
should hopefully compile after a bit (or a lot) of user hacking. :)

More informally, in my brief interactions with debian-hurd people, I think
it's fair to say that responses have been rapid, efficient and friendly.
So it also seems reasonable to me to put an FTBFS as an important bug,
and my intention is to file the followup bug (that Samuel found) again
as "important". If there's community consensus to lower the severity, I won't
oppose it, of course.

>> That said I would also fix packages with any severity, but for the
>> moment I'm very busy with RC stuff and if you want this be fixed soon I
>> would need a patch I would apply as soon as possible.

I don't need this personally - I just wish to help by making sure that
the bug is in the system - and this now applies to the followup bug,
for which my suggested long-term fix (update to a newer googletest
release) would probably require a fair amount of work to see and
understand what has been updated.

> Here is one for the task_info issue. When g++ provides a full prototype
> for the missing function, it means the header was included outside
> extern "C" { }, and thus the symbol is mangled (see nm's output on the
> .o file).

OK. I haven't done much C++ - I'm more familiar with C vs fortran symbol mangling.

Though shouldn't it be 'include <mach.h>' ? The whole content of /usr/include/mach/mach.h
on exodar is:


/* Some old programs may expect to find <mach.h> in <mach/mach.h>.  */

#include <mach.h>



> Now, there is another build issue, with tests:
>
> Common/SAM.cc: In member function 'virtual void parseCigarDeath_invalid_cigar_Test::TestBody()':
> Common/SAM.cc:62:2: error: 'EXPECT_DEATH' was not declared in this scope
>  EXPECT_DEATH(SAMAlignment::parseCigar("20SS", false), "error: invalid CIGAR: `20SS'");
>  ^~~~~~~~~~~~

I'll post this as a separate bug in a moment. Unit testing is a good
thing, so better it be fixed when maintainers/developers (Andreas?)
have the time free to do it without being rushed. I'll post it as
"important", and leave it to e.g. an independent fourth person to judge if it's
justified to downgrade it...

Cheers
Boud