RE: about build flavours

>From: Arturo Borrero Gonzalez [mailto:art...@debian.org] > >@Matthew, we are wondering whether hyperscan is able to detect SSE3 support at >runtime in a given machine. In Hyperscan v4.3 we don't have those cpuid tests. The next release (v4.4, due before the end of the year) will have these

Re: about build flavours

Thibaut Paumard writes ("Re: about build flavours"): > Exactly, plus a pair of symlinks with a default value and sysadmin > control. The standard way is using the alternatives system: > https://wiki.debian.org/DebianAlternatives This is good advice if there is no way to d

Re: about build flavours

On 30 November 2016 at 11:33, Paul Wise wrote: > On Wed, 2016-11-30 at 11:11 +0100, Arturo Borrero Gonzalez wrote: > >> I don't think hyperscan currently is able to detect SSE3 support at runtime. > > Sounds like a bug. > >> Do you think that the warning at install-time is not

Re: about build flavours

Hi Paul, >> Yes, the libhyperscan package alerts the user at pre-install time if >> SSE3 is not supported on the target system. That's one of the reasons >> why I think there should still be a version of suricata that works >> without Hyperscan. > > Sounds like they are doing it wrong. The

Re: about build flavours

On Wed, 2016-11-30 at 11:11 +0100, Arturo Borrero Gonzalez wrote: > I don't think hyperscan currently is able to detect SSE3 support at runtime. Sounds like a bug. > Do you think that the warning at install-time is not enough? Sounds like a reasonable workaround for the bug. -- bye, pabs

Re: about build flavours

On 30 November 2016 at 11:09, Paul Wise wrote: > On Wed, Nov 30, 2016 at 6:01 PM, Sascha Steinbiss wrote: > >> Yes, the libhyperscan package alerts the user at pre-install time if >> SSE3 is not supported on the target system. That's one of the reasons >> why I think there should

Re: about build flavours

On Wed, Nov 30, 2016 at 6:01 PM, Sascha Steinbiss wrote: > Yes, the libhyperscan package alerts the user at pre-install time if > SSE3 is not supported on the target system. That's one of the reasons > why I think there should still be a version of suricata that works > without Hyperscan. Sounds

Re: about build flavours

Hi Paul, [...] >> we are trying to create a build flavour for the suricata package [0], >> which we would like to link to hyperscan, which uses SSSE3. > > I hope it detects the presence of SSE3 at runtime. Yes, the libhyperscan package alerts the user at pre-install time if SSE3 is not

Re: about build flavours

On Tue, Nov 29, 2016 at 8:35 PM, Arturo Borrero Gonzalez wrote: > we are trying to create a build flavour for the suricata package [0], > which we would like to link to hyperscan, which uses SSSE3. I hope it detects the presence of SSE3 at runtime. -- bye, pabs

Re: about build flavours

Dear Sascha, Le 29/11/2016 à 15:24, Sascha Steinbiss a écrit : >>> >>> Then, we conflict the packages with each other and dpkg-divert the >>> /usr/bin/suricata file in suricata-hyperscan. >> >> If both packages conflict with each other, then you don't need >> dpkg-divert. > > One could think of

Re: about build flavours

Hi Raphael, thanks, here are a few more thoughts. >> Currently, our main idea is to create a suricata-hyperscan package >> which includes the dependency to hyperscan, and the binary is build >> linked to the library. >> >> We distribute two /usr/bin/suricata binaries in two binary packages: >>

Re: about build flavours

Hello, On Tue, 29 Nov 2016, Arturo Borrero Gonzalez wrote: > Currently, our main idea is to create a suricata-hyperscan package > which includes the dependency to hyperscan, and the binary is build > linked to the library. > > We distribute two /usr/bin/suricata binaries in two binary packages:

about build flavours

Hi, we are trying to create a build flavour for the suricata package [0], which we would like to link to hyperscan, which uses SSSE3. I've read several docs in our debian wiki regarding build flavours, but I couldn't find any proper document which describes best practices. Currently, our main