Re: [openssl-dev] who wants to fix travis builds?

[Alessandro Ghedini]

On Fri, Oct 16, 2015 at 10:56:43am +0200, Andy Polyakov wrote:
>  I've opened the following PR to add support for GCC v5 and
>  address sanitizer (not sure if we want valgrind as well...): 
>  https://github.com/openssl/openssl/pull/429
> > 
> > I've commented there on other -fsanitize options as well as about
> > option to execute them without --debug and/or --strict-warnings. But I
> > failed to recall all the details from last time the question was risen
> > in context of RT#3422 through 3324. -fsanitize=undefined is expected
> > to work only with --strict-warnings (or more specifically with
> > -DPEDANTIC) and I wouldn't be surprised if -fsanitize=memory works
> > only with -DPURIFY.
> 
> The main weakness of the endeavour is that testing is limited to x86
> hardware. I don't mean specifically -fsanitize, but in general. But
> let's concentrate on -fsanitize for a moment. Or more specifically why
> are there limitations for it, ones mentioned above. In the nutshell,
> remaining -fsanitize warnings were effectively about the fact that we
> sometimes rely on platform- or implementation-specific behaviour. But it
> is *conscious* choice and there always is platform-neutral fallback. So
> that above mentioned limitations are actually about nothing else but
> driving compiler toward these platform-neutral fallbacks. One can even
> take next step and say that in order to maximize -fsanitize utility, one
> should expose as much C code to -fsanitize as possible, or in other
> words adhere even to no-asm with -fsanitize. Incidentally this would
> also at least partially mitigate the main weakness, as -fsanitize should
> expose spots where platform-neutral fallback is not as platform-neutral
> as it should be, wouldn't it?

FWIW both gcc and clang support some sort of blacklist to exclude particular
functions from sanitizers. This would allow us to mark special cases manually
in order to avoid missing accidental errors in non-debug builds... but that's
work for some other time.

For now, I added ubsan debug-only builds for Travis at [0], and fixed a couple
of very minor issues (a test called memcmp() with a NULL pointer, and there was
a missing, but probably irrelevant, cast). I'm not sure if the fixes are
correct or not though.

Sort of related: the usefulness of sanitizers is directly related to the
coverage of the test suite, which, according to gcov, is currently around 50%
or so of OpenSSL's code. Would it be ok to steal^Wget inspiration from other
projects' test suites (e.g. BoringSSL and LibreSSL added some new tests) to try
to increse that?

One nice thing from BoringSSL's test suite is the Go-based test runner thingy.
It'd be interesting to see how good or bad OpenSSL does against it.

Cheers

[0] https://github.com/openssl/openssl/pull/445


signature.asc
Description: PGP signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] who wants to fix travis builds?

[Andy Polyakov]

 I've opened the following PR to add support for GCC v5 and
 address sanitizer (not sure if we want valgrind as well...): 
 https://github.com/openssl/openssl/pull/429
> 
> I've commented there on other -fsanitize options as well as about
> option to execute them without --debug and/or --strict-warnings. But I
> failed to recall all the details from last time the question was risen
> in context of RT#3422 through 3324. -fsanitize=undefined is expected
> to work only with --strict-warnings (or more specifically with
> -DPEDANTIC) and I wouldn't be surprised if -fsanitize=memory works
> only with -DPURIFY.

The main weakness of the endeavour is that testing is limited to x86
hardware. I don't mean specifically -fsanitize, but in general. But
let's concentrate on -fsanitize for a moment. Or more specifically why
are there limitations for it, ones mentioned above. In the nutshell,
remaining -fsanitize warnings were effectively about the fact that we
sometimes rely on platform- or implementation-specific behaviour. But it
is *conscious* choice and there always is platform-neutral fallback. So
that above mentioned limitations are actually about nothing else but
driving compiler toward these platform-neutral fallbacks. One can even
take next step and say that in order to maximize -fsanitize utility, one
should expose as much C code to -fsanitize as possible, or in other
words adhere even to no-asm with -fsanitize. Incidentally this would
also at least partially mitigate the main weakness, as -fsanitize should
expose spots where platform-neutral fallback is not as platform-neutral
as it should be, wouldn't it?

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] who wants to fix travis builds?

[Andy Polyakov]

>>> I've opened the following PR to add support for GCC v5 and
>>> address sanitizer (not sure if we want valgrind as well...): 
>>> https://github.com/openssl/openssl/pull/429

I've commented there on other -fsanitize options as well as about
option to execute them without --debug and/or --strict-warnings. But I
failed to recall all the details from last time the question was risen
in context of RT#3422 through 3324. -fsanitize=undefined is expected
to work only with --strict-warnings (or more specifically with
-DPEDANTIC) and I wouldn't be surprised if -fsanitize=memory works
only with -DPURIFY.

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] who wants to fix travis builds?

[Alessandro Ghedini]

On Tue, Oct 06, 2015 at 07:41:13pm +, Salz, Rich wrote:
> > I've opened the following PR to add support for GCC v5 and address sanitizer
> > (not sure if we want valgrind as well...):
> > https://github.com/openssl/openssl/pull/429
> 
> I've started the internal review.  Asan is awesome.

Ping?

Cheers


signature.asc
Description: PGP signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] who wants to fix travis builds?

[Salz, Rich]

> I opened the following PR to fix the builds in the 1.0.2 branch:
> https://github.com/openssl/openssl/pull/428

I've started the internal review.

> Now the 1.0.2 branch is all green as well. I haven't looked at 1.0.1 yet, and 
> for
> 0.9.8 we might want to just disable mingw builds completely, since they don't
> seem to work at all.

Yes, mingw is not supported in 0.9.8.  As both it and 1.0.0 are end-of-life in 
60 days, I would not worry about those two.

> I've opened the following PR to add support for GCC v5 and address sanitizer
> (not sure if we want valgrind as well...):
> https://github.com/openssl/openssl/pull/429

I've started the internal review.  Asan is awesome.
 
> I think we can just use that instead of adding support for v4.7, v4.8 and 
> v4.9.

Agreed.

This is great work, thank you!
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] who wants to fix travis builds?

[Richard Levitte]

In message <20151005222804.GA14709@kronk.local> on Tue, 6 Oct 2015 00:28:05 
+0200, Alessandro Ghedini  said:

alessandro> On a somewhat related note, I've noticed that the Travis failure 
messages are
alessandro> not actually sent to the mailing list. I suspect that this is due 
to some kind
alessandro> of filtering the mailing list does. Could the Travis messages be 
whitelisted or
alessandro> something? Or maybe just add a new "openssl-ci" mailing list 
dedicated to this?

Hi Alessandro,

I was just looking into this...  and I can't quite make heads or tails
of how travis notification works.  Can you help me figure it out?

What I need to know is, what do I need to do to have it send
notifications to the address configured in .travis.yml, and what will
the sender address be?

Right now, just from grepping for 'travis-ci' in the mail logs, or
even just 'travis', I'd say travis is giving us no sign of life, mail
wise.

Cheers,
Richard (please include my address when you answer...  I don't read
the lists very often...)

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] who wants to fix travis builds?

[Salz, Rich]

> With all the above patches applied, the Travis CI status for the master branch
> turned green for the first time in a while [0]. I think this is pretty 
> important,
> since even though none of the current failures are very important, they
> could potentially hide more severe failures in the future. So, could someone
> please have a look at my patches?

Yes, THANKS!
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] who wants to fix travis builds?

[Andy Polyakov]

 As for running tests in the context of query, i.e. mingw
 cross-compilation on Linux. It actually was possible to
 perform under 'wine' before and surely can be fixed now. Is
 'wine' an option in this case?
>>> 
>>> I don't know if it actually works, but we can configure Travis
>>> CI to install wine before starting the builds.
>> 
>> Can you test and figure out? As implied, currently new 'make
>> test' doesn't work with 'wine' yet, but you can replace 'make
>> test' with e.g. test/sha1test.exe alone. Just to figure out if it
>> works. It might happen that it's not sufficient to simply install
>> package, one might have to perform per-user config prior Win32
>> .exes can be executed.
> 
> It works!!! Well, sort of. It requires 3 patches [0] (including the
> changes to the Travis CI config) and there are 3 or so tests that
> fail (see log at [1]), but it's basically doable.
> 
> Cheers
> 
> [0] https://github.com/ghedo/openssl/commits/mingwci [1]
> https://travis-ci.org/ghedo/openssl/jobs/82727489

Thanks! I'm looking into it. On related note, you might notice a
number of mingw warnings addressed in master. I just want to say that
even more will be, i.e. it's work in progress.

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] who wants to fix travis builds?

[Alessandro Ghedini]

On Mon, Sep 28, 2015 at 08:49:12pm +0200, Andy Polyakov wrote:
> > FWIW, Travis CI allows you to define specific builds to be "non-fatal". The
> > failures would still be listed but they wouldn't affect the general state. 
> > See
> > for example: https://travis-ci.org/openssl/openssl/builds/82401235 (the last
> > two builds fail but are in the "Allowed Failures" section and the general 
> > build
> > state is green).
> > 
> > So we could add another debug-only configuration that is not allowed to 
> > fail,
> > and mark the current debug+strict-warnings builds on mingw as non-fatal. 
> > This
> > way the non-fatal builds are still run and someone can have a look at them
> > and try to fix them if they want.
> 
> --strict-warnings imply -Werror and then it's rendered all-or-nothing. I
> mean you can't ignore -Werror failure, because binary code is not
> generated. On the other hand generating warnings without -Werror is
> hardly meaningful in CI scenario, because you don't look at log unless
> there is problem. So it makes sense to bet on -Werror only if one is
> confident about it being representative, and the problem is that there
> is no guarantee that it's universally representative. Hence it can be
> exercised only is specific cases.

I think we are talking about two different things. What I meant is that due to
the debug+strict-warnings+mingw failures, the "global" state on Travis is shown
as "failed" https://travis-ci.org/openssl/openssl

To fix this, we could either drop those builds completely, or just mark them as
"Allowed Failures": they are still run, but even if they fail the Travis state
is not shown as "failed". But to do this we would have to add additional
debug-only (without --strict-warnings) builds that are *not* allowed to fail.

> >> As for running tests in the context of query, i.e. mingw cross-compilation 
> >> on
> >> Linux. It actually was possible to perform under 'wine' before and surely 
> >> can
> >> be fixed now. Is 'wine' an option in this case?
> > 
> > I don't know if it actually works, but we can configure Travis CI to install
> > wine before starting the builds.
> 
> Can you test and figure out? As implied, currently new 'make test'
> doesn't work with 'wine' yet, but you can replace 'make test' with e.g.
> test/sha1test.exe alone. Just to figure out if it works. It might happen
> that it's not sufficient to simply install package, one might have to
> perform per-user config prior Win32 .exes can be executed.

It works!!! Well, sort of. It requires 3 patches [0] (including the changes to
the Travis CI config) and there are 3 or so tests that fail (see log at [1]),
but it's basically doable.

Cheers

[0] https://github.com/ghedo/openssl/commits/mingwci
[1] https://travis-ci.org/ghedo/openssl/jobs/82727489


signature.asc
Description: PGP signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] who wants to fix travis builds?

[Andy Polyakov]

>> But I'd like to use this opportunity to challenge the choice of using
>> --strict-warnings in [all] CI scenarios. Two points.
>>
>> - Just like everything else warning system is subject to bugs and is a
>> changing field. For example -Wshadow complains about local variables
>> shadowing functions. It appeared in specific gcc version and then was
>> removed. Then mingw compiler complains about missing prototypes in a
>> number of *_asn1 modules. I fail to understand why only mingw compiler.
> 
> Regarding the missing prototypes, I think it's because (some?) Windows builds
> have OPENSSL_EXPORT_VAR_AS_FUNCTION defined, while normal builds don't. I
> haven't tried to build the code with normal GCC with that defined though so I
> don't know if that would fail on with non-mingw.

Yes, I've figured out that and a patch is submitted to internal system.
So in sense this becomes bad example to underline the point I was trying
to make. And the point is that we don't want to become hostages of bugs
elsewhere :-)

>> - While strict adherence to every letter of the standard is a good
>> thing, some code is (and always will be) system-specific and it might
>> be impractical to treat it otherwise. For example mingw compiler
>> complains about %I64i format string being non-standard. There is
>> nothing that can be done about it (except for implementing own
>> subroutine, but that would be definition of impractical).
> 
> We could use -Wno-pedantic-ms-format for that (disabling the warning
> completely).

Cool! Thanks for the hint!

> As you said, there's nothing we can do about it.
> 
>> Another > example is complain about assignment of getprocaddress to void *.
>> Well, it is meaningful warning and we do address it in other non-Win32
>> places. But how do you handle it in truly standard manner on 32-bit
>> Win32? When you can use GetProcAddress to pull references to either
>> cdecl or stdcall, per-definition implementation-specific thing?
> 
> The return value type of GetProcAddress is documented as being FARPROC, so
> using that may work. I actually fixed this warning in my famous patch using
> that, but I can't really say if the change was correct or not.

Technical solution/workaround is already submitted, but my comment was
more about *formal* impossibility to solve *all* possible problems
(GetProcAddress being *an* example) according to the letter of the
standard in true neutral way. Because there *is*
system-/implementation-specific code and we can't/shouldn't pretend that
there is none.

>> Note that I'm not saying that warnings should not be fixed. I'm saying
>> that it's impractical to treat all of them equally (not to mention that
>> there are legitimate false positives after all), and CI might be not the
>> right place to catch them. I would even say that on CI it is more
>> valuable to aim for running tests than to stop on warnings. Or maybe
>> it's not mutually exclusive?
> 
> FWIW, Travis CI allows you to define specific builds to be "non-fatal". The
> failures would still be listed but they wouldn't affect the general state. See
> for example: https://travis-ci.org/openssl/openssl/builds/82401235 (the last
> two builds fail but are in the "Allowed Failures" section and the general 
> build
> state is green).
> 
> So we could add another debug-only configuration that is not allowed to fail,
> and mark the current debug+strict-warnings builds on mingw as non-fatal. This
> way the non-fatal builds are still run and someone can have a look at them
> and try to fix them if they want.

--strict-warnings imply -Werror and then it's rendered all-or-nothing. I
mean you can't ignore -Werror failure, because binary code is not
generated. On the other hand generating warnings without -Werror is
hardly meaningful in CI scenario, because you don't look at log unless
there is problem. So it makes sense to bet on -Werror only if one is
confident about it being representative, and the problem is that there
is no guarantee that it's universally representative. Hence it can be
exercised only is specific cases.

>> As for running tests in the context of query, i.e. mingw cross-compilation on
>> Linux. It actually was possible to perform under 'wine' before and surely can
>> be fixed now. Is 'wine' an option in this case?
> 
> I don't know if it actually works, but we can configure Travis CI to install
> wine before starting the builds.

Can you test and figure out? As implied, currently new 'make test'
doesn't work with 'wine' yet, but you can replace 'make test' with e.g.
test/sha1test.exe alone. Just to figure out if it works. It might happen
that it's not sufficient to simply install package, one might have to
perform per-user config prior Win32 .exes can be executed.

Thanks!

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] who wants to fix travis builds?

[Alessandro Ghedini]

On Sun, Sep 27, 2015 at 10:32:11am +0200, Andy Polyakov wrote:
> >>> - mingw debug and shared builds in master.
> >> 
> >> While I can confirm problem with shared (fixable with attached
> >> patch, please double-check), I can't confirm problem with debug
> >> (please elaborate).
> > 
> > I just opened a pull request on GitHub [0] to add your patch for
> > mingw shared builds and another one to fix clang debug builds for
> > master. Let's see what Travis thinks of it.
> 
> The other modification was submitted by Emilia to internal system 4 days
> ago. Or in other words fixes will show up.
> 
> But I'd like to use this opportunity to challenge the choice of using
> --strict-warnings in [all] CI scenarios. Two points.
> 
> - Just like everything else warning system is subject to bugs and is a
> changing field. For example -Wshadow complains about local variables
> shadowing functions. It appeared in specific gcc version and then was
> removed. Then mingw compiler complains about missing prototypes in a
> number of *_asn1 modules. I fail to understand why only mingw compiler.

Regarding the missing prototypes, I think it's because (some?) Windows builds
have OPENSSL_EXPORT_VAR_AS_FUNCTION defined, while normal builds don't. I
haven't tried to build the code with normal GCC with that defined though so I
don't know if that would fail on with non-mingw.

> - While strict adherence to every letter of the standard is a good
> thing, some code is (and always will be) system-specific and it might
> be impractical to treat it otherwise. For example mingw compiler
> complains about %I64i format string being non-standard. There is
> nothing that can be done about it (except for implementing own
> subroutine, but that would be definition of impractical).

We could use -Wno-pedantic-ms-format for that (disabling the warning
completely). As you said, there's nothing we can do about it.

> Another > example is complain about assignment of getprocaddress to void *.
> Well, it is meaningful warning and we do address it in other non-Win32
> places. But how do you handle it in truly standard manner on 32-bit
> Win32? When you can use GetProcAddress to pull references to either
> cdecl or stdcall, per-definition implementation-specific thing?

The return value type of GetProcAddress is documented as being FARPROC, so
using that may work. I actually fixed this warning in my famous patch using
that, but I can't really say if the change was correct or not.

> Note that I'm not saying that warnings should not be fixed. I'm saying
> that it's impractical to treat all of them equally (not to mention that
> there are legitimate false positives after all), and CI might be not the
> right place to catch them. I would even say that on CI it is more
> valuable to aim for running tests than to stop on warnings. Or maybe
> it's not mutually exclusive?

FWIW, Travis CI allows you to define specific builds to be "non-fatal". The
failures would still be listed but they wouldn't affect the general state. See
for example: https://travis-ci.org/openssl/openssl/builds/82401235 (the last
two builds fail but are in the "Allowed Failures" section and the general build
state is green).

So we could add another debug-only configuration that is not allowed to fail,
and mark the current debug+strict-warnings builds on mingw as non-fatal. This
way the non-fatal builds are still run and someone can have a look at them
and try to fix them if they want.

> As for running tests in the context of query, i.e. mingw cross-compilation on
> Linux. It actually was possible to perform under 'wine' before and surely can
> be fixed now. Is 'wine' an option in this case?

I don't know if it actually works, but we can configure Travis CI to install
wine before starting the builds.

> > Mingw's debug builds are still broken, but now the following error
> > message is shown:
> > 
> >> cc1: error: command line option ‘-foutput-class-dir=-DL_ENDIAN’
> >> is valid for Java but not for C [-Werror]
> > 
> > The problem is that `-d` is a `./config` option, but in the case of
> > mingw it is passed directly to `./Configure` which thinks it's a
> > compiler flag so then gcc gets confused. A solution would be to
> > somehow detect the mingw cross compilation from `./config` so that
> > we would use it for mingw builds too, but I'm not sure what the
> > best way to do that would be (and on top of this we still have the 
> > mingw warnings problem).
> 
> I don't understand. Last modifications to .travis.yml switch from
> ./config to ./Configure on mingw, so that where does this ./config
> passing -d to ./Configure come from? I'd say that the switch is
> appropriate, because ./config was never meant and is hardly proper
> choice for cross-compiler cases.

Yeah, but now we pass -d to ./Configure for mingw builds. -d is a ./config-only
option, while --debug is the ./Configure one (which only works on master). I
think we should restore '--debug' for builds on master (where it worked 

Re: [openssl-dev] who wants to fix travis builds?

[Salz, Rich]

> But I'd like to use this opportunity to challenge the choice of using 
> --strict-
> warnings in [all] CI scenarios.

I think it would be fine if just the Linux gcc/clang builds had the strict 
warnings on.  IMHO.


--  
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] who wants to fix travis builds?

[Andy Polyakov]

>>> - mingw debug and shared builds in master.
>> 
>> While I can confirm problem with shared (fixable with attached
>> patch, please double-check), I can't confirm problem with debug
>> (please elaborate).
> 
> I just opened a pull request on GitHub [0] to add your patch for
> mingw shared builds and another one to fix clang debug builds for
> master. Let's see what Travis thinks of it.

The other modification was submitted by Emilia to internal system 4 days
ago. Or in other words fixes will show up.

But I'd like to use this opportunity to challenge the choice of using
--strict-warnings in [all] CI scenarios. Two points.

- Just like everything else warning system is subject to bugs and is a
changing field. For example -Wshadow complains about local variables
shadowing functions. It appeared in specific gcc version and then was
removed. Then mingw compiler complains about missing prototypes in a
number of *_asn1 modules. I fail to understand why only mingw compiler.

- While strict adherence to every letter of the standard is a good
thing, some code is (and always will be) system-specific and it might
be impractical to treat it otherwise. For example mingw compiler
complains about %I64i format string being non-standard. There is
nothing that can be done about it (except for implementing own
subroutine, but that would be definition of impractical). Another
example is complain about assignment of GetProcAddress to void *.
Well, it is meaningful warning and we do address it in other non-Win32
places. But how do you handle it in truly standard manner on 32-bit
Win32? When you can use GetProcAddress to pull references to either
cdecl or stdcall, per-definition implementation-specific thing? [BTW,
is it possible that above mentioned missing prototypes thing is
because of this?]

Note that I'm not saying that warnings should not be fixed. I'm saying
that it's impractical to treat all of them equally (not to mention that
there are legitimate false positives after all), and CI might be not the
right place to catch them. I would even say that on CI it is more
valuable to aim for running tests than to stop on warnings. Or maybe
it's not mutually exclusive? As for running tests in the context of
query, i.e. mingw cross-compilation on Linux. It actually was possible
to perform under 'wine' before and surely can be fixed now. Is 'wine' an
option in this case?

> Mingw's debug builds are still broken, but now the following error
> message is shown:
> 
>> cc1: error: command line option ‘-foutput-class-dir=-DL_ENDIAN’
>> is valid for Java but not for C [-Werror]
> 
> The problem is that `-d` is a `./config` option, but in the case of
> mingw it is passed directly to `./Configure` which thinks it's a
> compiler flag so then gcc gets confused. A solution would be to
> somehow detect the mingw cross compilation from `./config` so that
> we would use it for mingw builds too, but I'm not sure what the
> best way to do that would be (and on top of this we still have the 
> mingw warnings problem).

I don't understand. Last modifications to .travis.yml switch from
./config to ./Configure on mingw, so that where does this ./config
passing -d to ./Configure come from? I'd say that the switch is
appropriate, because ./config was never meant and is hardly proper
choice for cross-compiler cases.

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] who wants to fix travis builds?

[Alessandro Ghedini]

On Wed, Sep 23, 2015 at 03:57:18pm +0200, Andy Polyakov wrote:
> > - mingw debug and shared builds in master.
> 
> While I can confirm problem with shared (fixable with attached patch,
> please double-check),

Can confirm that your patch works.

> I can't confirm problem with debug (please elaborate).

The travis debug builds now also use --strict-warnings, which enables all
warnings and treats them as errors, and there's a bunch of warnings when
building with mingw.

I tried to fix some of them (see [0]) but it's kind of a lost battle.

Cheers

[0] https://github.com/ghedo/openssl/commit/0368a58


signature.asc
Description: PGP signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] who wants to fix travis builds?

[Andy Polyakov]

>>> - mingw debug and shared builds in master.
>>
>> While I can confirm problem with shared (fixable with attached patch,
>> please double-check),
> 
> Can confirm that your patch works.
> 
>> I can't confirm problem with debug (please elaborate).
> 
> The travis debug builds now also use --strict-warnings, which enables all
> warnings and treats them as errors, and there's a bunch of warnings when
> building with mingw.

I think it's appropriate to set pragmatic goals in this case. Fixing
warnings for non-primary[!] platform such as mingw in master is arguably
pragmatic, but not in all versions. So that in this case, i.e.
travis-ci.org, I'd argue for limiting testing to current working
de-facto status for all versions but master. Is it reasonable?

> I tried to fix some of them (see [0]) but it's kind of a lost battle.

What does "kind of a lost battle" mean in the context?

___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] who wants to fix travis builds?

[Salz, Rich]

> So that in this case, i.e.
> travis-ci.org, I'd argue for limiting testing to current working de-facto 
> status
> for all versions but master. Is it reasonable?

Yes, this makes a lot of sense; let's do it.

--  
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] who wants to fix travis builds?

[Alessandro Ghedini]

On Thu, Sep 24, 2015 at 04:23:52pm +0200, Andy Polyakov wrote:
> >>> - mingw debug and shared builds in master.
> >>
> >> While I can confirm problem with shared (fixable with attached patch,
> >> please double-check),
> > 
> > Can confirm that your patch works.
> > 
> >> I can't confirm problem with debug (please elaborate).
> > 
> > The travis debug builds now also use --strict-warnings, which enables all
> > warnings and treats them as errors, and there's a bunch of warnings when
> > building with mingw.
> 
> I think it's appropriate to set pragmatic goals in this case. Fixing
> warnings for non-primary[!] platform such as mingw in master is arguably
> pragmatic, but not in all versions. So that in this case, i.e.
> travis-ci.org, I'd argue for limiting testing to current working
> de-facto status for all versions but master. Is it reasonable?

Sure, that seems like a sensible strategy.

> > I tried to fix some of them (see [0]) but it's kind of a lost battle.
> 
> What does "kind of a lost battle" mean in the context?

Meaning that there actually are a lot of warnings and many of them are very
difficult (if not impossible) to fix. Fixing all of them would require quite a
bit of work and the result may be very ugly.

As an aside, the patch I previously posted is broken, so just ignore it.

Cheers


signature.asc
Description: PGP signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] who wants to fix travis builds?

[Alessandro Ghedini]

On Wed, Sep 23, 2015 at 10:06:24AM +0200, Andy Polyakov wrote:
> > Please see  https://travis-ci.org/openssl/openssl/jobs/81672180
> 
> --debug is not recognized by earlier ./Configures?

Yeah, it seems that earlier ./Configure only support the debug-$platform
arguments. For general travis debug builds (which use ./config), we can simply
change the $CONFIG_OPTS to use '-d' instead of '--debug', but that still leaves
the mingw builds out (they use ./Configure directly).

Another possibility is to backport '--debug' to older ./Configures.

> BTW, nor is there mingw64 in 098.

And the mingw build is broken anyway. Is this something worth fixing in a future
0.9.8 release? Otherwise the mingw builds could be simply removed from travis
for 0.9.8.

Other builds failing are:

- linux-gcc and mingw debug builds in 1.0.2 (I haven't tried to reproduce
  these yet).
- mingw debug and shared builds in master.


Cheers


signature.asc
Description: PGP signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] who wants to fix travis builds?

[Andy Polyakov]

> And the mingw build is broken anyway.

For the record, originally mingw was supported by itself, i.e. under
MSYS, and under cygwin (which is why you'll notice -mno-cygwin). Then is
was empirically confirmed that it works even with cross-compiler under
Linux. But it more than likely happened with 1.0, so that assuming that
0.9.8 would work was in fact a stretch.

> Is this something worth fixing in a future
> 0.9.8 release?

I'd vote against.

> Otherwise the mingw builds could be simply removed from travis
> for 0.9.8.
> 
> Other builds failing are:
> 
> - linux-gcc and mingw debug builds in 1.0.2 (I haven't tried to reproduce
>   these yet).

No comment at this point.

> - mingw debug and shared builds in master.

While I can confirm problem with shared (fixable with attached patch,
please double-check), I can't confirm problem with debug (please elaborate).

diff --git a/util/mkrc.pl b/util/mkrc.pl
index 83ee6a4..b61d73d 100755
--- a/util/mkrc.pl
+++ b/util/mkrc.pl
@@ -1,6 +1,6 @@
 #!/bin/env perl
 #
-open FD,"crypto/opensslv.h";
+open FD,"include/openssl/opensslv.h";
 while() {
 if (/OPENSSL_VERSION_NUMBER\s+(0x[0-9a-f]+)/i) {
 	$ver = hex($1);
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev