On 30 November 2016 at 18:28, Sascha Steinbiss <sa...@debian.org> wrote:
> Hi Arturo,
>
> [...]
>> I think the alternatives method discussed at debian-devel seems like
>> the way to go.
>>
>> @Sascha, would you handle the change or should I work on it?
>
> Done. Please see my 'hyperscan-with-alternatives' branch [1] for a
> version using alternatives. I'm now installing
> '/usr/bin/suricata.generic' and '/usr/bin/suricata.hyperscan'
> respectively, where the hyperscan-enabled variant has a higher priority
> to be preferred in automatic mode when installed.
>
Ok.
I think this is the way to go, thanks Sascha.
One more thing: do you think it's time for us to introduce the change
at this point in the release cycle of Stretch?
Perhaps we should wait until the release, some months ahead, so we
make sure suricata is well established into stable.
My plan is to upload suricata 3.2 today, and I would like to avoid NEW
and backports-NEW for this upload.
> BTW, the 'command5'autopkgtest in its original version failed for me in
> a recent sid LXC container:
>
> autopkgtest [17:48:01]: test command5: [-----------------------
> {"message": "stats not yet synchronized", "return": "NOK"}
> autopkgtest [17:48:01]: test command5: -----------------------]
> autopkgtest [17:48:01]: test command5: - - - - - - - - - - results - -
> - - - - - - - -
> command5 FAIL non-zero exit status 1
>
> I assume that this is a timing issue as I was able to fix it by simply
> waiting for a few more seconds before starting the test, see commit
> c70e8e8. I'm not too convinced that's a viable solution, but just wanted
> to let you know.
>
Ok, pushing this change now.
