Bug#989399: nauty FTCBFS -- multiple reasons

2021-06-03 Thread Étienne Mollier
Control: severity -1 important

Greetings everyone,

focusing on the baseline violation aspect…

Helmut Grohne, on 2021-06-02:
> The check does not want to know whether the compiler supports
> popcnt (which could be determined using AC_LINK_IFELSE), but whether the
> CPU does and AC_LINK_IFELSE does not suffice here.
> 
> Unfortunately such opportunistic use of the popcnt instruction violates
> the i386 baseline as it does not include SSE4 at this time. This is a
> serious bug. For Debian, such detection is not appropriate. Debian
> builds must pass --disable-popcnt for any-i386. If the package is deemed
> unusable without such performance optimizations, it should at least
> depend on the appropriate isa-support package likely sse4.2-support.

I have looked up the issue, and rebuilt the package on a popcnt
enabled CPU.  When disassembling the binary packages, I have
seen no traces of *cnt instructions, neither in the libraries,
nor in executable programs.  I do see the following in the build
log, which is quite concerning:

CC=gcc
CFLAGS=-g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security
MORECFLAGS= -mpopcnt -march=native
 ~

The -march=native would cause even worse baseline violations
than -mpopcnt, especially if the build occurs on very recent
hardware.  To eliminate both of these entries off the equation,
one would have to configure the build with both --disable-popcnt
and --enable-generic.


Fortunately, note that the MORECFLAGS variable does not make it
down to build options, although it is concatenated into CFLAGS
in makefile.in.  This seems to explain why I don't see baseline
violations in the resulting binary objects on my end.  Still,
standard Debian options are accounted for properly.  I believe
our dh build process never uses upstream's makefile.in template,
but an entirely autoreconf-ed one instead, which does not know
anything of MORECFLAGS, hence the proper result in spite of the
confusing options.

Since the compilation does seem to result in baseline clean
binaries, I dropped the severity to "important".  I prefer not
closing the bug, since I guess plans to adjust the logic for
cross buildability could, eventually, end up injecting such
option properly in the build process.  Of course, please feel
free to readjust the severity, if I missed an important thing in
the problem at play.

Hope this helps,
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/8, please excuse my verbosity.


signature.asc
Description: PGP signature


Processed: Re: Bug#989399: nauty FTCBFS -- multiple reasons

2021-06-03 Thread Debian Bug Tracking System
Processing control commands:

> severity -1 important
Bug #989399 [nauty] nauty: i386 baseline violation by using popcnt
Severity set to 'important' from 'serious'

-- 
989399: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989399
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems



Bug#989399: nauty FTCBFS -- multiple reasons

2021-06-03 Thread Andrius Merkys
Hi Nilesh,

On 2021-06-03 13:05, Nilesh Patra wrote:
> On Thu, 3 Jun 2021 at 13:10, Andrius Merkys  > wrote:
> On 2021-06-02 19:29, Nilesh Patra wrote:
> > Nauty fails to cross build due to two reasons:
> >
> > 1. It uses AC_RUN_IFELSE testing which cannot heppen during cross
> build
> >    Simply replacing it by AC_LINK_IFELSE does the trick. Please
> find the
> >    patch for this below, and consider applying
> 
> I have no experience with this, alas.
> 
> This patch that I suggested is actually wrong, as you might see in
> Helmut's message.
> But more importantly, we ended up discovering that this is a *Release
> critical*  bug instead.
> Please consider fixing it ASAP if you have some free cycles.

I am aware of Helmut's response and the severity of the problem.
However, I have no experience with fixing i386 baseline violation. I may
give a look, but I am not sure anything will come out of that.

> Indeed, help2man should not call the compiled executables. Nevertheless
> it may still be used to produce manpages from static text, see [2] for
> example.
> 
> This looks nice, there is also ronn and node-marked-man which can do
> similar stuff via README.

I was not aware of ronn and node-marked-man - thanks, I will give them a
look.

> But doing so isn't always possible because several times we have
> multiple binaries and we need separate manual page for each binary.
> In such a case, we need to maintain a maintainer manpage

True indeed.

> [2]
> 
> https://salsa.debian.org/debian/libemf2svg/-/blob/df56bd1149cf512b6a232052437d04310bd90982/debian/rules#L11
> 
> 

Best,
Andrius



Bug#989399: nauty FTCBFS -- multiple reasons

2021-06-03 Thread Nilesh Patra
Hello Andrius

On Thu, 3 Jun 2021 at 13:10, Andrius Merkys  wrote:

> Hi Nilesh,
>
> On 2021-06-02 19:29, Nilesh Patra wrote:
> > Nauty fails to cross build due to two reasons:
> >
> > 1. It uses AC_RUN_IFELSE testing which cannot heppen during cross build
> >Simply replacing it by AC_LINK_IFELSE does the trick. Please find the
> >patch for this below, and consider applying
>
> I have no experience with this, alas.
>

This patch that I suggested is actually wrong, as you might see in Helmut's
message.
But more importantly, we ended up discovering that this is a *Release
critical*  bug instead.
Please consider fixing it ASAP if you have some free cycles.

More details in Helmut's email[0] again

[0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989399#10

 >> [1]:
https://salsa.debian.org/med-team/community/helper-scripts/-/blob/master/createmanpages

> Indeed, help2man should not call the compiled executables. Nevertheless
> it may still be used to produce manpages from static text, see [2] for
> example.


This looks nice, there is also ronn and node-marked-man which can do
similar stuff via README.
But doing so isn't always possible because several times we have multiple
binaries and we need separate manual page for each binary.
In such a case, we need to maintain a maintainer manpage

createmanpages is a viable option too.
>
> [2]
>
> https://salsa.debian.org/debian/libemf2svg/-/blob/df56bd1149cf512b6a232052437d04310bd90982/debian/rules#L11
>

Nilesh


Bug#989399: nauty FTCBFS -- multiple reasons

2021-06-03 Thread Andrius Merkys
Hi Nilesh,

On 2021-06-02 19:29, Nilesh Patra wrote:
> Nauty fails to cross build due to two reasons:
> 
> 1. It uses AC_RUN_IFELSE testing which cannot heppen during cross build
>Simply replacing it by AC_LINK_IFELSE does the trick. Please find the
>patch for this below, and consider applying

I have no experience with this, alas.

> 2. It uses help2man during build, and the same has also been
>autotoolised - this isn't allowed during build. It looks like there's 
> particularly
>no good way to fix it, and probably compiling twice once for build
>arch, and once for host is un-needed extra work.
>I'd suggest removing the help2man invocations from autotools, not
>generate this during build, but simply maintain maintainer manpage,
>using for example createmanpages script[1]
>Talking to upstream and asking them to vendor their own manpages from
>next release can also be a nice option.
> 
>If it is too much hassle for you, I'm willing to do so myself and
>even maintain the package
> 
> [1]: 
> https://salsa.debian.org/med-team/community/helper-scripts/-/blob/master/createmanpages

Indeed, help2man should not call the compiled executables. Nevertheless
it may still be used to produce manpages from static text, see [2] for
example. createmanpages is a viable option too.

[2]
https://salsa.debian.org/debian/libemf2svg/-/blob/df56bd1149cf512b6a232052437d04310bd90982/debian/rules#L11

Best,
Andrius



Processed: Re: Bug#989399: nauty FTCBFS -- multiple reasons

2021-06-02 Thread Debian Bug Tracking System
Processing control commands:

> retitle -1 nauty: i386 baseline violation by using popcnt
Bug #989399 [nauty] nauty FTCBFS -- multiple reasons
Changed Bug title to 'nauty: i386 baseline violation by using popcnt' from 
'nauty FTCBFS -- multiple reasons'.
> severity -1 serious
Bug #989399 [nauty] nauty: i386 baseline violation by using popcnt
Severity set to 'serious' from 'normal'
> tags -1 - patch
Bug #989399 [nauty] nauty: i386 baseline violation by using popcnt
Removed tag(s) patch.

-- 
989399: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989399
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems