who wants to fix travis builds?

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

who wants to fix travis builds?

Salz, Rich

Please see  https://travis-ci.org/openssl/openssl/jobs/81672180

 

Etc.

 

 

-- 

Senior Architect, Akamai Technologies

IM: [hidden email] Twitter: RichSalz

 


_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: who wants to fix travis builds?

Andy Polyakov-2
> Please see  https://travis-ci.org/openssl/openssl/jobs/81672180

--debug is not recognized by earlier ./Configures? BTW, nor is there
mingw64 in 098.

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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

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

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: who wants to fix travis builds?

Andy Polyakov-2
> 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).


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

mingw-shared.diff (315 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 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

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

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: who wants to fix travis builds?

Andy Polyakov-2
>>> - 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
Reply | Threaded
Open this post in threaded view
|

Re: 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: [hidden email] Twitter: RichSalz


_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: who wants to fix travis builds?

Alessandro Ghedini
In reply to this post by Andy Polyakov-2
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

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

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: who wants to fix travis builds?

Alessandro Ghedini
In reply to this post by Andy Polyakov-2
On Wed, Sep 23, 2015 at 03:57:18PM +0200, Andy Polyakov wrote:

> > 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).
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.

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).

Cheers

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

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

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: who wants to fix travis builds?

Andy Polyakov-2
>>> - 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
Reply | Threaded
Open this post in threaded view
|

Re: 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: [hidden email] Twitter: RichSalz


_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: who wants to fix travis builds?

Alessandro Ghedini
In reply to this post by Andy Polyakov-2
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 fine),
and just disable mingw debug builds on older branches.

Cheers

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

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: who wants to fix travis builds?

Andy Polyakov-2
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: 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

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

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: who wants to fix travis builds?

Andy Polyakov-2
>>>> 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
Reply | Threaded
Open this post in threaded view
|

Re: who wants to fix travis builds?

Alessandro Ghedini
On Wed, Sep 30, 2015 at 10:48:01am +0200, Andy Polyakov wrote:

> >>>> 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.
So, I just opened a new pull request to:

- Fix a clang warning in the bn_dh.c file
- Fix a gcc bogus warning in the packettest.c file
- Revert the -d flag back to --debug in the travis script to make mingw debug
  builds run again
- Use -Wno-pedantic-ms-format with mingw to silence the ms-format warnings
- Mark mingw debug builds as "allowed failures" for the time being, until all
  the warnings have been fixed.

I don't know if any of you have already provided patches for any of this
internally, so just ignore any patch I proposed that duplicates other work.

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?

I'm going to look into the failures of other branches as well, but that will
probably involve just disabling various builds that are just not supported
(e.g. clang and mingw debug).

I'm also working into adding support for newer compilers like gcc-5 and
clang-3.8. This could allow us to build with address sanitizer and other
niceties.

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

Cheers

[0] https://travis-ci.org/openssl/openssl/builds/83787204

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

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: who wants to fix travis builds?

Alessandro Ghedini
On Tue, Oct 06, 2015 at 12:28:05AM +0200, Alessandro Ghedini wrote:

> On Wed, Sep 30, 2015 at 10:48:01am +0200, Andy Polyakov wrote:
> > >>>> 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.
>
> So, I just opened a new pull request to:
Btw, the pull request can be found at
https://github.com/openssl/openssl/pull/425

Cheers

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

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: who wants to fix travis builds?

Salz, Rich
In reply to this post by Alessandro Ghedini
> 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
Reply | Threaded
Open this post in threaded view
|

Re: who wants to fix travis builds?

Richard Levitte - VMS Whacker-2
In reply to this post by Alessandro Ghedini
In message <[hidden email]> on Tue, 6 Oct 2015 00:28:05 +0200, Alessandro Ghedini <[hidden email]> 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         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: who wants to fix travis builds?

Alessandro Ghedini
On Tue, Oct 06, 2015 at 09:46:17am +0200, Richard Levitte wrote:

> In message <[hidden email]> on Tue, 6 Oct 2015 00:28:05 +0200, Alessandro Ghedini <[hidden email]> 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?
I checked the documentation on the subject [0] and I think we had the wrong
configuration all along (my fault :/), so that's probably why the notifications
weren't received at all. I added another commit to my pull request to fix this,
so now a notification may have been sent (but it still didn't show up in the
openssl-commits archive). It should come from [hidden email] I think.

Cheers

[0] http://docs.travis-ci.com/user/notifications/#Email-notifications

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

signature.asc (836 bytes) Download Attachment
12