logging-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominik Psenner <dpsen...@gmail.com>
Subject Re: [log4net] release 2.0.9
Date Sat, 20 Jan 2018 21:16:54 GMT
On 20 Jan 2018 9:29 p.m., "Stefan Bodewig" <bodewig@apache.org> wrote:

On 2018-01-20, Dominik Psenner wrote:

> On 20 Jan 2018 7:27 p.m., "Stefan Bodewig" <bodewig@apache.org> wrote:

>> Building .NET 2.0 (not standard or core, good old .NET framework) was
>> broken.

> I see. I wonder why the build worked on ci.

because there is no build step for compile-net-2.0 :-)

I'll try to add one.

> Btw, have you noticed that the head of develop failed in ci? I'm
> currently on my phone only and therefore cant figure out why.

The build ends with

| Could not update commit status, please check if your scan credentials
belong to a member of the organization or a collaborator of the repository
and repo:status scope is selected

I believe this is a warning message of the Jenkins github plugin and it can
be ignored for now. It means that jenkins github plugin was unable to store
the build outcome to the github page. I believe there is already an infra
ticket for this. It would still be good to double check.

| ERROR: script returned exit code 1
| Finished: FAILURE

That's the generic error message that always shows up when the build fails.

I have no idea what this means.

>> Not sure what "all targetted" frameworks means. The quote above is from
>> running the .NET Standard tests using .NET Core SDK 1.1.7 on Win7. I
>> tested this by changing into the log4net.tests dir and running "dotnet
>> test".

> That's roughly what the runtests-netstandard-1.3 target does, too.

Then maybe my fear that the test pass on Windows but fail on Linux is
warranted. In any case it doesn't necessarily need to stop us from
building the 2.0.9 release as the test used to pass on my Windows bix
and they still do.

I have looked at the assert that fails. For one there's a comment on it
saying that "on linux locking seems to not behave as one would expect".
Second the assert is wrapped in an #if !MONO || MONO_3_5 || MONO_4_0. Note
that this all comes from my memory and there might be an error here or
there. It however indicates a long known but badly documented issue related
to how log4net behaves on linux.

I really have a bad feeling to release something like that now that
netstandard has become a supported framework and therefore log4net will
most likely run more on linux machines.

How about if we configure ci to run our tests for both netstandard and mono
on linux and windows?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message