On Thu, Dec 11, 2014 at 6:41 AM, Lukas Tribus wrote:
>>> Many Lolz.. Lukas you just made my day..
>>>
>>> They've been misused that way, and more than once, by more than one
>>> project. This is why we really want it to be just a string, and
>>> strongly discourage people from using it in the
>> Many Lolz.. Lukas you just made my day..
>>
>> They've been misused that way, and more than once, by more than one
>> project. This is why we really want it to be just a string, and
>> strongly discourage people from using it in the way it has been
>> abused.
>>
>> ... we could always change
> >> A second reason is to prevent software from using the version number or
> >> string
> >> to test for features, which has been frequently misused and abused.
> >
> > Have strings really been misused this way? Yikes...
> >
>
> Many Lolz.. Lukas you just made my day..
>
> They've been misu
On Wed, Dec 10, 2014 at 6:27 PM, Stuart Henderson wrote:
> On 2014/12/10 22:57, Lukas Tribus wrote:
>> I get your point, but I don't believe its always that simple. Should we
>> really
>> exclusively care about users of the packaging systems provided by the OS,
>> nobody else?
>
> The standard wa
On 2014/12/10 22:57, Lukas Tribus wrote:
> I get your point, but I don't believe its always that simple. Should we really
> exclusively care about users of the packaging systems provided by the OS,
> nobody else?
The standard way to handle this for build-from-source is with
pkg-config. I haven't l
>> A second reason is to prevent software from using the version number or
>> string
>> to test for features, which has been frequently misused and abused.
>
> Have strings really been misused this way? Yikes...
>
Many Lolz.. Lukas you just made my day..
They've been misused that way, and mo
> Sorry if this is long-winded:
Dito :)
> One reason is that incrementing for sub-minor versions in the CVS source
> doesn’t mean anything, since the portable release schedule is independent in
> OpenBSD land.
Agreed that this doesn't make much sense for CVS source, for the -portable
tarballs
> On Dec 10, 2014, at 10:58 AM, Lukas Tribus wrote:
>
>>> I believe a not to be underestimated amount of applications #ifdef's
>>> certain functionality of openssl out, for example NPN
>>> (SSL_CTRL_SET_TLSEXT_HOSTNAME) or server preferential cipher ordering
>>> (SSL_OP_CIPHER_SERVER_PREFERENCE)
>> I believe a not to be underestimated amount of applications #ifdef's
>> certain functionality of openssl out, for example NPN
>> (SSL_CTRL_SET_TLSEXT_HOSTNAME) or server preferential cipher ordering
>> (SSL_OP_CIPHER_SERVER_PREFERENCE).
>
> That's rather different to checking using defines with
On Wed, 10 Dec 2014, Lukas Tribus wrote:
> > On 2014/12/09 07:37, Brent Cook wrote:
> >> If an app calls a function, it should probably check if that function
> >> exists during configuration time, rather than inferring if define A
> >> exists, function B and C must exist. Especially things that ar
> On 2014/12/09 07:37, Brent Cook wrote:
>> If an app calls a function, it should probably check if that function
>> exists during configuration time, rather than inferring if define A
>> exists, function B and C must exist. Especially things that are just
>> protocol constant definitions. If they
On 2014/12/09 07:37, Brent Cook wrote:
> If an app calls a function, it should probably check if that function
> exists during configuration time, rather than inferring if define A
> exists, function B and C must exist. Especially things that are just
> protocol constant definitions. If they are us
On Tue, Dec 9, 2014 at 6:18 AM, Stuart Henderson wrote:
> On 2014/12/09 12:30, Lukas Tribus wrote:
>> Hi,
>>
>> I'm linking haproxy (current git master) against libressl 2.1.2
>> portable on linux, but seeing 2 issues (not present in previous
>> libressl 2.1.1):
>>
>>
>> Issue number one (not sure
On 2014/12/09 12:30, Lukas Tribus wrote:
> Hi,
>
> I'm linking haproxy (current git master) against libressl 2.1.2
> portable on linux, but seeing 2 issues (not present in previous
> libressl 2.1.1):
>
>
> Issue number one (not sure what happens here):
>
> include/openssl/ssl.h:503:2: error: un
Hi,
I'm linking haproxy (current git master) against libressl 2.1.2
portable on linux, but seeing 2 issues (not present in previous
libressl 2.1.1):
Issue number one (not sure what happens here):
include/openssl/ssl.h:503:2: error: unknown type name ‘uint8_t’
uint8_t *tlsext_ecpointformatlist
15 matches
Mail list logo