On 28 Jan 2018 11:43 a.m., "Stefan Bodewig" wrote:
On 2018-01-21, Dominik Psenner wrote:
> On 21 Jan 2018 11:28 a.m., "Stefan Bodewig" wrote:
>> Maybe, yes. See the other thread for my investigation so far. The
>> github issue I've linked and the source code for the Unix
>> implementation of F
On 2018-01-21, Dominik Psenner wrote:
> On 21 Jan 2018 11:28 a.m., "Stefan Bodewig" wrote:
>> Maybe, yes. See the other thread for my investigation so far. The
>> github issue I've linked and the source code for the Unix
>> implementation of FileStream state that FileShare.None is the only
>> th
On 21 Jan 2018 11:28 a.m., "Stefan Bodewig" wrote:
On 2018-01-20, Dominik Psenner wrote:
> 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
On 2018-01-20, Dominik Psenner wrote:
> 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 memor
On 20 Jan 2018 9:29 p.m., "Stefan Bodewig" wrote:
On 2018-01-20, Dominik Psenner wrote:
> On 20 Jan 2018 7:27 p.m., "Stefan Bodewig" 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 bu
On 2018-01-20, Dominik Psenner wrote:
> On 20 Jan 2018 7:27 p.m., "Stefan Bodewig" 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 on
On 20 Jan 2018 7:27 p.m., "Stefan Bodewig" wrote:
On 2018-01-20, Dominik Psenner wrote:
> On 20 Jan 2018 6:47 p.m., "Stefan Bodewig" wrote:
>> On 2018-01-15, Dominik Psenner wrote:
>
>>> 2018-01-15 10:22 GMT+01:00 Stefan Bodewig :
There still are lots of version conflicts that we probabl
On 2018-01-20, Dominik Psenner wrote:
> On 20 Jan 2018 6:47 p.m., "Stefan Bodewig" wrote:
>> On 2018-01-15, Dominik Psenner wrote:
>
>>> 2018-01-15 10:22 GMT+01:00 Stefan Bodewig :
There still are lots of version conflicts that we probably want to
reolve first. Unfortunately I have no
On 20 Jan 2018 6:47 p.m., "Stefan Bodewig" wrote:
On 2018-01-15, Dominik Psenner wrote:
> 2018-01-15 10:22 GMT+01:00 Stefan Bodewig :
>> Hi
>> by now I've dusted off the old VM that I used to build 2.0.8 (at leat
>> the Windows part of it), installed .NET Core SDK 1.1.7 in order to be
>> able
On 2018-01-15, Dominik Psenner wrote:
> 2018-01-15 10:22 GMT+01:00 Stefan Bodewig :
>> Hi
>> by now I've dusted off the old VM that I used to build 2.0.8 (at leat
>> the Windows part of it), installed .NET Core SDK 1.1.7 in order to be
>> able to deal with the csproj files (2.0.8 has been using
2018-01-15 10:22 GMT+01:00 Stefan Bodewig :
> Hi
>
> by now I've dusted off the old VM that I used to build 2.0.8 (at leat
> the Windows part of it), installed .NET Core SDK 1.1.7 in order to be
> able to deal with the csproj files (2.0.8 has been using json projects
> with .NET Core 1.0 preview3)
Hi
by now I've dusted off the old VM that I used to build 2.0.8 (at leat
the Windows part of it), installed .NET Core SDK 1.1.7 in order to be
able to deal with the csproj files (2.0.8 has been using json projects
with .NET Core 1.0 preview3).
After some tweaks I am able to build a distribution i
2018-01-13 16:40 GMT+01:00 Stefan Bodewig :
> On 2018-01-12, Dominik Psenner wrote:
>
> > I'm working on LOG4NET-566, hoping that we can get a release build
> > from our CI.
>
> CI won't be able to create the oldkey binaries unless we are willing to
> make the old key public (which defeats the rea
On 2018-01-12, Dominik Psenner wrote:
> I'm working on LOG4NET-566, hoping that we can get a release build
> from our CI.
CI won't be able to create the oldkey binaries unless we are willing to
make the old key public (which defeats the reason why the new key was
introduced in the first place.
>
I'm working on LOG4NET-566, hoping that we can get a release build from
our CI. The build currently gets stuck because of an unknown reason. It
would be great to get some help on finding out why the heck the
netstandard-1.3 tests behave as they do here:
https://builds.apache.org/job/logging-lo
Hi,
quite some time passed by since we last made a release and there are a few
issues that have been fixed and should be shipped as part of a release. So
this is my call for help.
There are a few things on the to do list:
- check jira for issues that can be closed as won't fix
- check jira for i
16 matches
Mail list logo
